Deploying OBSERVE on a Domestic Stack: Kunpeng, Kylin, and Dameng

Why domestic-stack deployment deserves its own guide

A xinchuang environment is not "swap the image and rerun". The CPU moves from x86 to ARM (Kunpeng/Phytium), the OS changes to Kylin or UnionTech UOS, and the database switches from MySQL to Dameng, KingbaseES, or OceanBase. Middleware and drivers all need re-adapting, and many upstream images have no ARM build at all. OBSERVE has treated domestic-stack adaptation as a first-class requirement since 2.0. Here is a real deployment walkthrough.

Environment

• Hardware: Kunpeng 920 (aarch64), 64 cores, 256GB RAM
• OS: Kylin Advanced Server V10 SP3
• Database: Dameng DM8
• Deployment: Kubernetes (Kylin container cloud, or K8s 1.27+)

Deployment steps

First, verify the image architecture. Every OBSERVE component (gateway, ingester, querier, storage) ships an -arm64 image. Run uname -m on Kylin to confirm aarch64, then pull those images—never mix in x86 ones.

Second, prepare Dameng. OBSERVE's metadata layer supports Dameng DM8. Drop the Dameng JDBC driver into the gateway classpath and set:

database:
  type: dm
  url: jdbc:dm://10.0.0.11:5236
  user: observe
  password: "***"

Dameng listens on port 5236 by default. Note its JDBC URL prefix is jdbc:dm:, not MySQL's jdbc:mysql:—this is where many people get stuck.

Third, data directories and storage. Log data goes to a local object store (the ARM build of MinIO), and index data goes to a self-developed columnar store. Neither relies on x86-specific instructions, so both run fine on ARM.

Fourth, verify. Run the official compatibility script ob-compat-check.sh, which checks CPU architecture, glibc version, database driver version, and timezone, then reports each item as passed or needing a downgrade.

Compatibility gotchas

The ARM move surfaces a few issues that don't exist on x86. First, glibc: Kylin V10 SP3 ships an older glibc than many upstream images expect; the OBSERVE arm64 images are built against a conservative glibc floor precisely to avoid this. Second, page size: some ARM servers use a 64KB page size, which breaks JVM versions that hard-code 4KB, so use the Kylin-bundled JDK rather than a hand-picked one. Third, timezone: Dameng stores timestamps in local time by default, so set the session timezone to Asia/Shanghai in the connection string, or you'll see logs shifted by eight hours. The ob-compat-check.sh script covers all three, so run it before handing the environment to production traffic.

Performance and stability

Measured on Kunpeng 920: a single ingester node ingests about 21,000 log lines per second, with query latency at the 99th percentile around 180ms. Compared with an equivalently sized x86 node, the gap is within 15%, driven mostly by single-core performance. Under a 72-hour sustained load test there was no memory leak, and GC pause P99 stayed at 25ms.

| Component | x86 (64c) | Kunpeng 920 (64c) |
|---|---|---|
| Ingest throughput | 24k lines/s | 21k lines/s |
| Query P99 | 155ms | 180ms |
| GC pause P99 | 22ms | 25ms |

Images and registry

All arm64 images are published to the same registry as the x86 builds, tagged with the -arm64 suffix and grouped under a manifest list so a single tag resolves per architecture. If your registry requires domestic mirroring, mirror only the arm64 tags you actually deploy to avoid pulling unused layers. On air-gapped environments, export images with docker save and load them onto the Kylin nodes—the compatibility script also verifies image digests, so you can confirm nothing was altered in transit.

Recommendations

• On xinchuang environments, prefer Kylin container cloud or UnionTech's offering; the kernel and K8s versions are matched for you.
• Dameng's default concurrent connection count is low—raise the metadata connection pool to avoid exhausting connections at peak.
• Keep an x86 reference environment for canary releases instead of cutting everything over at once, so you can roll back quickly.