Deploying Jujing OBSERVE on Domestic Platforms: Kylin, UOS, Kunpeng, and DM

Domestic (Xinchuang) environments differ meaningfully from a stock x86 + CentOS setup: the CPU moves to ARM (Kunpeng, Phytium), the OS to Kylin or UOS, and the database to Dameng or KingbaseES. Getting an observability platform running here means nailing those layers first—otherwise you'll stall halfway through on some unmet dependency, and finding ARM-specific packages mid-install is nobody's idea of a good afternoon.

Environment inventory and prep

We validated a typical Xinchuang stack with the following components:

| Component | Version / Model |
|-----------|-----------------|
| CPU | Kunpeng 920 (ARM64) |
| OS | Kylin V10 SP3 / UOS 1060 |
| Database | Dameng DM8 / KingbaseES V8 |
| Middleware | TongWeb 7 |

Confirm three things before you start: the kernel version, the glibc version, and glibc compatibility with the database client. On ARM, always download aarch64 packages—an x86 rpm will fail immediately with an architecture mismatch, and the error message often won't tell you that's the cause. If you're mirroring packages internally, double-check the mirror carries the aarch64 channel, since many mirrors default to x86_64 only.

Beyond architecture, three more things bite in practice. Some distro builds ship an older glibc that breaks the database client's native libraries, so pin your versions early and test the client before you commit to the OS image. Kernel page-size differences on certain ARM boards change JVM and GC behavior, so validate with the same GC flags you'll run in production rather than a throwaway config. And SELinux policies written for x86 install paths may need relabeling for your bundled install directory—a restorecon over the install tree usually fixes it.

Installation steps

1. Open the firewall ports you need (Collector 4317/4318, platform 443) and set SELinux to permissive;
2. Install base dependencies with the system package manager, then extract the OBSERVE bundle;
3. Initialize the database: create the schema and user in Dameng, then run the bundled DDL scripts. Note that Dameng is case-sensitive by default, so keep table and column names consistent across scripts; if you hit an error on a CREATE TABLE statement, the first thing to check is whether the script's casing matches the database's collation setting—switching the database to case-insensitive mode at creation is simpler than hand-fixing every identifier;
4. Edit the configuration with your database connection string, listen address, and alert channel, then start the service.

A Dameng connection string looks like this:

jdbc:dm://10.0.1.20:5236/OBSERVE?user=observe&password=***&compatibleMode=oracle

The compatibleMode=oracle flag is worth keeping: much existing SQL assumes Oracle-style semantics, and Dameng's compatibility mode smooths over the differences during migration.

Compatibility and performance tuning

ARM single-core performance differs from x86, so give the Collector and storage nodes more memory and cap per-instance usage with memory_limiter to avoid OOM kills. Batch log writes, and on the database side put Dameng's redo logs and data files on separate disks to lift write throughput. For larger log volumes, prefer ARM-compatible object storage or a time-series engine over pushing everything through the relational database—Dameng will happily handle metadata, but it shouldn't be your hot write path for raw logs.

If you must keep raw logs in Dameng, enable batch inserts and increase the commit interval; single-row commits are the fastest way to saturate its I/O. The same applies to KingbaseES—both handle bulk writes far better than row-at-a-time.

Migration and acceptance

When migrating off an old platform, import historical (cold) data first, then cut over live traffic—a one-shot full sync will saturate the network and starve the new platform before it's even live. Run acceptance in three tracks: functional (the four main paths—collection, search, alerting, tracing), compatibility (run the core cases on both Kylin and UOS, not just the one you deployed on), and performance (100,000 lines/minute ingest per node, query P95 under 3 seconds). Pass all three before going to production, and keep the old platform in read-only mode for a week as a rollback option. Document the exact OS image, kernel, and package versions you validated against, so the next deployment reproduces the result instead of rediscovering the same pitfalls.

For the performance track, run the test for at least two hours under sustained load rather than a five-minute spike—ARM nodes sometimes look great in a burst and then throttle under thermal or memory pressure.