Deploying Jujing OBSERVE on Xinchuang Hardware and Domestic Databases

The hard part of a Xinchuang (domestic IT stack) project is rarely the business logic — it's the base software and hardware. OBSERVE's support for domestic environments isn't "it installs"; the storage, compute, and frontend layers have each been verified against the target stacks. Here are the practical points, layer by layer.

Hardware and operating system

On the CPU side, OBSERVE ships ARM64 packages (Kunpeng 920, Phytium 2000+) and LoongArch packages (Loongson 3A5000/3C5000), all fully tested. Hygon and Zhaoxin x86 environments can reuse the standard x86_64 package. Do not try to run the x86_64 build under emulation on ARM — it boots, but the ingest path depends on native vector instructions and throughput collapses.

For the OS, Kylin V10 SP2/SP3 and UOS V20 (1050 and above) are the first-class targets; openEuler 22.03 is also compatible. Before installing, confirm glibc is 2.28 or newer and the kernel is 4.19+. Kylin V10's stock glibc already meets this — no upgrade needed. On UOS, make sure the uos-dev and openssl-devel meta-packages are present if you plan to build any collector plugins locally.

Two deployment notes matter for ingest throughput: on ARM64, disable CPU frequency scaling (set the performance governor), or the collector will jitter under load; and disable transparent huge pages (THP) to avoid latency spikes from memory reclamation in the storage engine. Both are one-line changes but consistently show up as the difference between a healthy and a flaky node in real deployments.

Database adapters

OBSERVE ships an embedded store that covers small and medium single-node deployments. When you scale up or want to unify operations with an existing domestic database, switch to an external one. Three are supported today:

DM8 (Dameng): connection string jdbc:dm://host:5236, driver in $OBSERVE_HOME/lib. Dameng is case-insensitive by default — initialize with CASE_SENSITIVE=Y or all table and column names get folded to uppercase and clash with OBSERVE's camelCase metadata. Also raise the default BUFFER and LOG_SIZE settings if you're pointing audit data at it; the defaults are tuned for OLTP, not append-heavy log workloads.

KingbaseES V8: enable MySQL compatibility mode (--compat-mysql, or pick the MySQL dialect at init), otherwise pagination syntax and functions like IFNULL behave differently. Connection string: jdbc:kingbase8://host:54321/db. If you see "syntax error at or near LIMIT" in the compat log, this is the setting you missed.

openGauss 3.x/5.x: it only accepts local connections by default — add the app subnet to pg_hba.conf and set listen_addresses to a real IP or *. openGauss is strict about connection limits, so give OBSERVE its own database and raise max_connections; a shared instance with a small pool will exhaust connections under concurrent queries.

For all three, set the database timezone to UTC or match the server, or log timestamps will drift across timezones. And wherever possible, put the database on the same high-speed network as the OBSERVE node — cross-DC JDBC latency shows up in every query.

One practical note on expectations: on comparable core counts, the ARM64 collector sustains roughly the same ingest throughput as x86, but the LoongArch build runs at about 70–80% of x86 for the same core count, so size your ingest fleet accordingly rather than assuming parity. It's also worth budgeting for a burn-in week — the most reliable Xinchuang rollouts we've seen treat the first deployment as a parallel pilot that shadows production for a week before it carries real traffic.

Migration and verification

Moving from x86 + MySQL to a Xinchuang stack: use jjctl export / jjctl import for metadata and config; for large log volumes, migrate via object storage and skip the reindex. Don't try a live database-to-database sync across architectures — the collation and byte-order differences will bite you.

Run this checklist before go-live:

1. The collector runs 24 hours on ARM64 with no abnormal CPU spikes.
2. One full scan and one aggregation query against the external database return within acceptable latency.
3. Trigger an alert and confirm the notification channel (SMS/email/webhook) delivers on the domestic stack.
4. Run an upgrade drill and confirm backups restore.

Xinchuang isn't about swapping a shell around the same software — every layer of dependency needs to be traceable. When you hit a specific error, look at OBSERVE's compat log first; it spells out dialect-level compatibility differences explicitly, which turns most "mysterious" database failures into a one-line fix.