Deploying Observability on the Xinchuang Stack: Kylin, Kunpeng, and DM8

Three hurdles on the Xinchuang stack

Deploying an observability platform on the Xinchuang stack differs from a routine x86 + CentOS install in three fundamental ways. First, CPU architecture: Kunpeng and Phytium are ARM64, and many images and binaries ship amd64-only, so verify architecture before installing anything. Second, the operating system: Kylin and UOS are built on different kernel baselines, and glibc versions, systemd behavior, and security policies (SELinux, classified-protection hardening) all vary — a binary built against a newer glibc may simply fail to start on an older baseline. Third, the database: DM8 and KingbaseES are broadly SQL-compatible, but each has its own dialect for data types, functions, and pagination — copying MySQL or PostgreSQL DDL verbatim will very likely fail.

All three hurdles are really about 'confirm before you act', not about whether it can be done. Below I walk through them in deployment order.

Switching the database to DM8

Take DM8 as the example. Step one, create the instance, a dedicated user, and a tablespace with a UTF-8 character set:

CREATE TABLESPACE jjhub DATAFILE 'jjhub.dbf' SIZE 512 AUTOEXTEND ON;
CREATE USER jjhub IDENTIFIED BY 'Jjhub@2026' DEFAULT TABLESPACE jjhub;
GRANT RESOURCE, DBA TO jjhub;

Step two, in the Jujing OBSERVE config, switch the database from MySQL to DM8 and change a few key items: use the official DM JDBC driver (DmJdbcDriver), a jdbc:dm://host:5236 connection string, and change the dialect from mysql to dm:

database:
  driver: dm.jdbc.driver.DmDriver
  url: jdbc:dm://192.168.10.20:5236
  username: jjhub
  password: Jjhub@2026
  dialect: dm

Step three, migrate existing data. DM ships a DTS tool that extracts from MySQL and maps types — double-check the mapping for precision types like datetime(3) so millisecond timestamps are not truncated. Before switching production traffic, run the platform against DM8 in a staging environment for at least one full write cycle; the time-series tables are the ones most likely to expose dialect differences.

Performance tuning

A few points are easy to overlook on ARM64. First, the JVM: prefer BishengJDK or the aarch64 OpenJDK build on Kunpeng — GC behavior is noticeably better than the default setup. Second, tune DM8's buffer and redo parameters to your memory size; the defaults are conservative and leave a lot of throughput on the table. Third, storage: time-series ingestion is write-heavy, so put log and metric data on SSD or NVMe, not the system disk. One more practical switch: set DM8's COMPATIBLE_MODE to 2 (MySQL-compatible), which removes a lot of hidden SQL-dialect surprises when the platform runs queries originally written for MySQL.

Offline install and dependencies

Many Xinchuang environments are air-gapped, so plan for an offline install. Build a local RPM repository or a container image registry mirror on the internal network first, then ship everything on media. The dependency list to prepare ahead of time: the aarch64 glibc and libstdc++ runtime, a matching JDK (BishengJDK or OpenJDK aarch64), the DM8 JDBC driver jar, and any database client tools. Before assembling the bundle, confirm the exact kernel and glibc versions on the target host — a mismatch here is the most common reason an install fails on day one.

A second habit worth adopting: run a compatibility smoke test before production cutover. Start the platform with a clean DM8 schema, ingest a sample of real logs and metrics, and run the queries your team uses most. This catches dialect and collation issues in minutes rather than during a live migration.

Compatibility and common pitfalls

Finish with a checklist: kernel version, glibc version, JDK architecture and version, database version and patch level, and driver version — verify these five before you start, and you will avoid most rework. Three common pitfalls: forgetting the aarch64 libc dependencies and getting startup errors; DM8's default case-sensitivity, which means table and column names must match your DDL exactly; and hardened environments that restrict ports and file permissions — confirm ports like 4317 and 5236 are open with ops before you deploy. Finally, keep the DM8 JDBC driver pinned to the version the platform recommends; a mismatched driver is the most common source of cryptic connection errors.

Once the platform is up, monitor the deployment itself with the platform: watch CPU and GC on the ARM nodes, and DM8's slow-query log for any query the dialect translation handled poorly. A few days of this surfaces the handful of hot spots worth tuning instead of guessing at parameters up front. Finally, keep a known-good baseline config in version control — DM8 parameters, JDK flags, driver version — so a rebuilt host can be reproduced exactly rather than re-tuned from memory.