Running Jujing OBSERVE on Xinchuang Stack: Kylin/UOS with Phytium/Kunpeng

Sort out the architecture before anything else

The detail most people miss in Xinchuang environments is the CPU instruction set. Phytium and Kunpeng are ARM64, Loongson is LoongArch, and Hygon and Zhaoxin are x86-compatible. The first step is to confirm the target machine's architecture, because each one needs a different set of binaries and base images. OBSERVE currently ships offline packages for ARM64 and x86, with LoongArch handled through source builds.

This matters because a surprising number of third-party libraries and container base images still assume x86. A Docker image built for amd64 will not run on Phytium without an ARM64 tag or emulation, and emulation is the slow path you do not want in production. Before deploying anything, run uname -m on every host and confirm that every component, collector, storage, database, and your own services, matches the architecture. What follows is what we saw on two real deployments: Kylin V10 on a Phytium S2500 and UOS on a Kunpeng 920.

Preparing the OS and dependencies

Kylin V10 is openEuler-based and UOS is Debian-based, so the package managers differ, but the preparation is the same in spirit: turn off SELinux/AppArmor, open the firewall ports, and sync the clock.

# Kylin V10 (openEuler family)
dnf install -y gcc gcc-c++ make openssl-devel libffi-devel
systemctl stop firewalld && systemctl disable firewalld

# UOS (Debian family)
apt-get update && apt-get install -y build-essential libssl-dev libffi-dev
systemctl stop apparmor && systemctl disable apparmor

Time sync is non-negotiable: tracing and alerting both rely on a single clock, and spans will drift apart if the hosts disagree. Set up Chrony on every host and point it at a local stratum in each data center rather than an external pool.

Swapping the database: MySQL to a domestic engine

OBSERVE's metadata store defaults to MySQL, which Xinchuang environments replace with a domestic database. We used Dameng DM8 on the Phytium host and openGauss on the Kunpeng host. Two things matter. First, export the DDL and convert dialects for the target engine: Dameng wants AUTO_INCREMENT turned into IDENTITY, and openGauss needs attention to case folding. Second, get the JDBC driver and pool settings right; the Dameng driver needs the schema named explicitly in the connection string.

storage:
  type: dm8
  host: 192.168.10.20
  port: 5236
  user: OBSERVE
  schema: OBSERVE
  driver: dm.jdbc.driver.DmDriver

After migration, run the platform's built-in db-check to verify tables and indexes before importing history. Never load everything at once; import in batches and watch the pool.

Installing the services and enabling autostart

Unpack the offline bundle and run bin/install.sh, which detects the architecture and picks the right binaries. Register the services with systemd and enable boot autostart, and make a point of confirming no component is loading an x86 prebuilt library on ARM64. Running file bin/observe-server should report aarch64, not x86-64. On a single Phytium S2500 with 128 GB RAM, we held 2,000 containers' worth of logs and metrics at a steady CPU load under 40%.

Verification checklist

After deployment, walk through this list before going live:

• Logs, metrics, and traces all render correctly in the UI;
• The Dameng/openGauss connection pool shows no leaks under load;
• After clock sync, trace timelines are continuous with no jumps;
• Core components restart cleanly and lose no data;
• SM2/SM4 HTTPS certificates handshake without browser warnings.

Gotchas we hit along the way

A few things cost us time and are worth writing down. First, the Dameng JDBC driver is not reliably on Maven Central; get the matching driver from the vendor, install it into the local repository, and pin the version. Second, some Kylin images ship with a low vm.max_map_count, which caused storage crashes under load, so bump it before going live. Third, in a multi-center setup, run local NTP per center rather than pointing every host at an external pool, because intra-center offset is what actually breaks trace timelines. In our Kunpeng deployment, hosts drifted by over a second during a maintenance window, and every span that crossed hosts showed negative durations until we brought up local NTP.

Xinchuang adaptation is not "it boots." Every item above maps to a real production failure mode, so run all of them before you ship.