Running an Observability Platform on Kylin and Kunpeng: A Practical Guide

The hard part of domestic deployments is the environment, not the app

The observability platform's own code is architecture-neutral; the real traps live in the runtime environment. On ARM, some dependencies ship no prebuilt binaries, kernel defaults are conservative, and domestic storage behaves differently from the x86 gear your team knows. This post turns what we hit on Kylin V10 with Kunpeng 920 and Phytium 2000 into a checklist.

Architecture and image selection

The first step is getting the architecture right. Confirm whether the CPU is ARM64 — Kunpeng and Phytium are ARM64, while Zhaoxin and Hygon are x86 — and match your images and binaries to it. Don't force an amd64 package onto ARM. Observe ships both amd64 and arm64 images, so pull the right tag for containerized deployments.

For deployment shape, a single-node containerized install is fine for a pilot. For production, prefer multiple replicas with local disks. An observability platform is write-heavy, and disk IOPS plus sequential write bandwidth are the main bottleneck. Put hot data on local NVMe rather than a slow shared volume — it's far more stable.

Dependencies and kernel parameters

On ARM, most problems are dependency problems. Containers sidestep a lot of system-library versioning issues, but the host still needs attention:

• Kernel parameter: vm.max_map_count defaults to 65530, which is too low for mmap-heavy logging and indexing components — raise it to 262144
• File handles: ulimit -n defaults to 1024; both collection and storage components need it at 65535
• Transparent Huge Pages (THP): disable it to avoid huge-page allocation stalls slowing writes

Whether the OS is UnionTech UOS or Kylin, the commands are essentially the same — edit /etc/sysctl.conf and /etc/security/limits.conf.

Storage and performance tuning

Domestic environments often pair with domestic disk arrays whose performance varies widely. Before going live, run a write benchmark with fio — 4K random writes and 1M sequential writes — and confirm the IOPS and bandwidth can absorb your projected write volume. If the numbers fall short, look at the array's cache policy and stripe width before blaming the software.

For the platform itself, tune in three directions:

• Batch reports on the collection side to reduce small writes to disk
• Size index shards to the node count — too few causes hot spots, too many causes fragmentation
• Pre-aggregate hot queries so dashboards don't rescan everything

Troubleshooting checklist

• GLIBC version mismatch: check whether x86 binaries got mixed in, or switch to a matching OS release
• Garbled Chinese logs: standardize on UTF-8 and keep the collection and processing sides on the same character set
• Timezone drift: align container and host timezones or the trace timeline will be wrong
• Domestic CPU power limits: Kunpeng throttles on some models, so if benchmarks come in low, check whether you've hit a power or thermal wall first

Domestic migration is more than swapping packages; every difference in the environment gets amplified at write peaks. Running through the checklist before go-live is a lot cheaper than debugging during an incident.