Deploying an Observability Platform on Phytium/Kunpeng with Kylin/UOS: Checklist and Benchmarking

Architecture first: go containerized

Domestic CPUs split mainly into Phytium and Kunpeng (ARMv8), plus Loongson (LoongArch) and Hygon/Zhaoxin (x86-compatible). When the same code has to run across several architectures, containers are the least painful path: build an image per architecture and distribute via a multi-arch manifest.

docker buildx build --platform linux/amd64,linux/arm64 \
  -t registry.local/observe:2.5 --push

Keep the application layer stateless. The data layer (storage and indexes) should use a domestic database or one that speaks the MySQL protocol, on bare metal or a dedicated instance so it never competes with the query layer for resources.

OS and dependency adaptation

Kylin and UOS are both domestic Linux distributions, so the real work is dependencies and runtimes:

| Item | Notes |
| --- | --- |
| glibc version | Older Kylin releases can ship a low glibc; build binaries against it or link statically |
| Java/Go runtime | Use the official ARM64 builds to avoid x86 emulation overhead |
| Time sync | Keep chrony synchronized; tracing is sensitive to clock drift |
| System libraries | Some libraries (e.g. libssl) differ across versions — bundle them |

Building for ARM is not just a flag flip. If your platform ships native binaries, build them on the target architecture or with a proper cross-toolchain rather than running x86 binaries under emulation, which quietly costs 30-50% of throughput. Where you must support an older glibc, statically link libc or build on a distribution that matches the oldest target you support — a binary built on a new glibc will refuse to start on an old Kylin.

One easily missed point: Kylin and UOS enable SELinux/AppArmor-style security modules by default, which can block the collection agent from reading logs or writing sockets. When "data is not arriving", check the security policy before file permissions and paths.

Benchmarking: do not settle for "it runs"

The gap between domestic platforms and x86 is not about features, it is the performance curve. Run a fixed set of benchmarks before going live:

• Ingest: push logs at a fixed rate and measure sustainable write QPS per node, plus whether it backs up at peak.
• Query: after loading realistic data volumes, measure search latency across 1-hour, 24-hour and 7-day ranges.
• Memory: memory pages and huge-page settings affect time-series databases noticeably on ARM — watch memory pressure during writes.

On the storage side, size for the write path, not the query path. Domestic ARM servers often pair fast NVMe with a modest number of drives, so check sustained write bandwidth rather than raw capacity. Time-series indexes are write-heavy during ingest and read-heavy during compaction, and the two overlap under load. Watch disk I/O wait during the benchmark, and if the store is the bottleneck, prefer more smaller nodes over one large one — smaller nodes keep compaction and queries from fighting over the same drives.

Compare the results against your existing x86 environment. If the gap exceeds expectations, isolate whether it is I/O, CPU or storage before deciding between adding nodes and tuning parameters.

Common pitfalls and a troubleshooting order

1. Wrong image architecture: an exec format error usually means the image arch does not match the node.
2. Agent not collecting logs: check the security policy first, then file permissions and paths.
3. Slow writes: look at disk I/O and memory; on ARM servers the usual culprit is storage that was not sized for the load.
4. Clock drift: if trace timestamps look scrambled, resync time first.

The acceptance bar for a domestic deployment does not change: no ingest backlog, no query timeouts, and traces that reconstruct end to end. The migration only truly lands when the platform runs steadily on domestic hardware.

A final note on the long tail: LoongArch and x86-compatible chips each have their own quirks, so keep one build per architecture and test on real hardware, not emulation. Emulators confirm the binary runs; they do not confirm it performs.

Finally, verify the surrounding tooling, not just the platform. Your container runtime, orchestration version, monitoring agents and backup scripts all need ARM builds too. Make a short checklist of every component in the stack and confirm an ARM64 artifact exists for each before the migration window opens — a single missing agent image can stall a cutover that was otherwise ready.