Deploying an Observability Platform on Domestic CPUs and Operating Systems

Xinchuang (domestic IT innovation) environments replace x86 with locally produced CPUs — Kunpeng, Phytium, Loongson — and run domestic operating systems such as Kylin and UnionTech UOS. For an observability platform, the first concrete problem is architectural: most public images only ship x86_64 builds, and pulling them on ARM yields a cryptic exec format error. The fix is simple once you know it — use a multi-arch image or the matching binary package. This post walks through the support matrix, deployment steps, and the tuning traps that catch x86 veterans.

Supported Chips and Operating Systems

Jujing OBSERVE publishes multi-arch images and binary packages covering the following combinations:

| CPU arch | Representative chips | Adapted OS |
| --- | --- | --- |
| ARM64 (aarch64) | Kunpeng 920, Phytium 2000 | Kylin V10, UOS 20 |
| LoongArch | Loongson 3A5000 | Kylin V10, Loongnix |
| x86_64 | Hygon, Zhaoxin | Kylin V10, UOS 20 |

Run uname -m on the target machine to confirm the architecture, then pick the matching package. If you're behind an air-gapped network — common in regulated and government environments — download the package on a connected machine and transfer it in, rather than trying to pull images on the target. The binary package is self-contained, which also avoids installing a Docker daemon on systems that don't ship one.

Deployment Steps

Binary deployment on Kylin V10 with a Kunpeng CPU:

# 1. Confirm architecture
uname -m   # outputs aarch64

# 2. Download the matching binary package
curl -LO https://ob.jjhub.cn/download/observe-2.4.0-linux-arm64.tar.gz

# 3. Extract and start
tar -xzf observe-2.4.0-linux-arm64.tar.gz
cd observe-2.4.0
./bin/observe start

Docker deployment is simpler since the image carries a multi-arch manifest:

docker pull jjhub/observe:2.4.0   # auto-selects the right arch
docker run -d -p 8080:8080 jjhub/observe:2.4.0

After startup, check the health endpoint and confirm the version string reports the correct architecture; a wrong-arch binary usually fails fast with exec format error, so a clean start is a good sign.

Tuning and Common Pitfalls

• Weaker single-core performance. Domestic ARM servers have many cores but weaker individual cores. Raise worker concurrency and drop CPU pinning rather than copying x86 tuning parameters, which are usually tuned for fewer, faster cores.
• Clock sync. Distributed tracing depends on precise clocks. Configure NTP or chrony on every node, or span timestamps will drift and your traces will appear out of order — a subtle problem that can look like a service bug.
• Storage mix. Mixing domestic SSDs with spinning disks is common. Do hot/cold tiering properly and keep hot data on NVMe; put retention data on cheaper spinning disks.
• Missing libraries. Some domestic distros ship older glibc; use ldd to find missing dependencies and prefer the platform's compatibility layer over compiling your own.
• Network policy. Many Xinchuang deployments sit in isolated networks with strict egress rules. Plan your OTLP and agent traffic paths up front rather than discovering the block mid-rollout.

Performance Expectations

Don't expect x86 numbers on domestic hardware — and don't be alarmed when you don't get them. On a Kunpeng 920, single-threaded ingestion is typically slower per core than a comparable x86 box, but the higher core count usually makes up for it once you scale workers horizontally. Measure your own baseline before go-live: run a fixed ingestion workload, watch CPU saturation and tail latency, then set alerting thresholds against those numbers rather than against your old x86 dashboard. This one step prevents most "the platform is slow after the migration" surprises, which almost always turn out to be copied tuning parameters rather than hardware limits.

A Short Compatibility Checklist

Before you schedule the cutover, walk through five items: confirm the CPU arch with uname -m; confirm the OS version against the support matrix; verify NTP/chrony is running on every node; confirm storage has room for both hot and cold tiers; and validate that the agent's egress path to the collector is open. Teams that check these five rarely hit surprises on launch day.

Deploying on Xinchuang hardware is mostly about matching architectures and re-checking assumptions you inherited from x86 — the platform itself runs unchanged once that's done.