← Back to blog
Xinchuang 4 min read 炬鲸团队

Deploying an Observability Platform on Domestic Stacks: Kylin, Phytium, and DM

A field report on adapting Jujing OBSERVE to domestic stacks — Kylin/UOS, Phytium/Kunpeng/Hygon CPUs, and DM/KingbaseES databases — with concrete commands, compatibility checks, and a list of pitfalls.

Why domestic stacks need their own port

A lot of teams assume domestic adoption is just swapping the OS. In practice it is four swaps at once: the chip (x86 to ARM), the OS (CentOS to Kylin/UOS), the database (MySQL to DM/KingbaseES), and the middleware. Each layer has subtle differences — ARM byte order, Kylin's glibc version, DM's SQL dialect. An observability platform ingests huge volumes of logs and metrics, so it is far more sensitive to CPU instructions and the storage engine. "It installs" is not enough.

Chip and OS adaptation

We build natively for both Phytium (ARM64) and Hygon (x86), and pass compatibility tests on Kylin V10 SP2 and UOS 20. The one deployment gotcha is glibc: Kylin V10 ships glibc 2.28 by default, so a collector compiled against a newer glibc fails with GLIBC_2.34 not found. The fix is static linking or a musl build — don't try to upgrade glibc at runtime.

# check glibc version
ldd --version | head -1
# check CPU architecture
uname -m   # should print aarch64 or x86_64

Database adaptation: DM and KingbaseES

OBSERVE's metadata and config store defaults to MySQL; for domestic environments we ship adapters for DM8 and KingbaseES V8. DM follows Oracle's dialect, and two differences need handling:

  1. Pagination syntax. DM supports Oracle-style pagination that differs from MySQL's LIMIT offset, count, so the ORM layer has to switch by dialect.
  2. Identifier case. DM upper-cases unquoted identifiers by default, so DDL must quote identifiers or use a consistent lowercase scheme — otherwise queries fail with "table not found."

Migrate with DM's built-in DTS tool for full + incremental sync from MySQL: structure first, then data, then cut over reads and writes.

Collectors on domestic middleware

The collector deploys via systemd on Kylin/UOS, and log ingestion works with rsyslog, journald, and domestic middleware — TongWeb, BES, and Apusic. Their log formats are close to Tomcat's but not identical, so collection configs need their own regexes rather than reusing the Tomcat template.

Verification checklist

Validate in this order and don't skip steps:

  1. Collector arch matches the OS, and systemctl status is healthy.
  2. The DM/KingbaseES connection pool connects and survives a load test without leaks.
  3. Logs, metrics, and traces all render in domestic browsers (Qi An Xin / 360 domestic editions) — these browsers run older kernels, so the frontend must degrade gracefully.
  4. Network-outage drill: when the database is briefly unreachable, the collector buffers locally and backfills after recovery, with no data loss.

Recommendations

Don't migrate in one leap. Run two environments in parallel (x86 + domestic), double-write the same logs, compare consistency, and only switch after a stable month. Database dialect and browser compatibility are the two most expensive hidden costs — POC them early.