Deploying JJHub OBSERVE on Xinchuang: Kylin, Kunpeng and DM8

Where Xinchuang projects get stuck

The hard part of a Xinchuang (domestic IT substitution) project is rarely the business system — it's the supporting platforms around it. Observability stacks for logs, monitoring and tracing have historically targeted x86 + CentOS + MySQL, and they fall over the moment they meet a domestic CPU or OS. JJHub OBSERVE was adapted for these environments from the architecture up; this article gives a verified deployment plan.

Adaptation isn't just "recompile it". Every layer needs separate treatment: binary dependencies under ARM64, SQL dialect differences in Dameng, the class-loading behavior of TongWeb. Any layer you haven't verified will bite you in production.

The target environment

This setup ran on a financial client's test cluster with the following stack:

| Component | Model / version |
| --- | --- |
| CPU | Kunpeng 920 (ARM64) |
| OS | Kylin V10 SP2 |
| Database | DM8 (Dameng) |
| Middleware | TongWeb (TongTech) |

OBSERVE ships ARM64 installers, so no cross-compilation is needed. The database layer adapts to Dameng over JDBC, and the middleware layer deploys onto TongWeb.

Install steps

Step one, unpack and initialize:

tar -xzf jjhub-observe-arm64.tar.gz
cd jjhub-observe
./setup.sh --db-type dm8   --db-host 10.0.0.12 --db-port 5236   --db-user observe --db-password '******'

The setup script detects the CPU architecture and OS version, swaps glibc dependencies as needed, and generates the Dameng schema script.

Step two, initialize the Dameng database. Hand the script to your DBA, or run it with dm's disql tool:

disql SYSDBA/******@10.0.0.12:5236 < schema_dm8.sql

Step three, start the service and health-check it:

./bin/observe-server start
curl -s http://127.0.0.1:8080/api/health

A response of {"status":"ok"} means you're up.

Three things to watch during adaptation

JDBC driver: the Dameng JDBC driver version must match the DM8 server version exactly; mixing them throws not support errors. Put the driver in lib/ and ignore the stale version in the Maven repository. Also, Dameng enables case sensitivity by default, so create tables and columns in uppercase — otherwise runtime SQL fails with "object not found".

Time fields: Dameng's TIMESTAMP defaults to second precision, but tracing needs millisecond timestamps. Declare TIMESTAMP(3) explicitly in the schema and add compatibleMode=oracle to the JDBC URL to avoid precision loss. This one is sneaky — data writes fine, but every span time rounds to the nearest second and nothing lines up when you're debugging.

Performance baseline: run a load calibration on ARM64. In practice a 16-core Kunpeng 920 sustains 30,000 TPS of log ingestion at about 60% CPU. Before going live, run ./bin/bench --write 30000 --duration 5m — don't just reuse x86 numbers.

Common errors and how to read them

A few errors come up constantly during Xinchuang deployments — worth knowing in advance:

• error while loading shared libraries: libc.so.6 — your binary and system glibc don't match. Confirm you're using the ARM64 package rather than x86, then check the Kylin version against the installer's glibc requirement.
• disql: command not found — the Dameng client tools aren't installed or aren't on PATH; they usually live under /dm8/bin.
• JDBC connection refused — first confirm Dameng's listener on port 5236 is reachable, then check dm.ini isn't bound to 127.0.0.1.
• TongWeb class conflict — when OBSERVE's dependency jars clash with TongWeb's own, use TongWeb's classloader policy to isolate the application into its own classloader.

None of these show up in x86 environments, which is why Xinchuang deployments need real integration time budgeted — don't schedule them on x86 assumptions.

Migration advice

When moving existing data from x86 to a Xinchuang environment, migrate data first and switch traffic second: export historical logs and metric snapshots to Parquet, import them into the new cluster, then point collectors at the new endpoint gradually. Run both clusters in parallel for two weeks during the gray rollout, and only retire the old one once metric curves and alert triggers match.

One more easy-to-miss point: the collector Agent also needs an ARM64 build. Once you move to Kunpeng hosts, running an x86 Agent through the compatibility layer wastes performance and tends to break the eBPF probe.

Xinchuang isn't "recompiling the software" — it's real validation of every layer, from database to middleware to OS. The plan above has been through real customer environments and can be followed as-is.