A deployment playbook for Jujing OBSERVE on the Xinchuang stack: compatibility matrix and adaptation steps across ARM chips, Kylin/UOS, and DM database, plus a migration checklist.
The biggest fear in Xinchuang (domestic IT) adoption is discovering halfway through installation that something isn't supported — so let's state the compatibility scope up front. Jujing OBSERVE's core services (collection, storage, query, alerting) have all completed domestic adaptation. Officially validated combinations: chips include Hygon, Kunpeng, Phytium, and Loongson, covering both x86 and ARM; operating systems include Kylin V10 (SP1/SP2/SP3), UOS 20/22, and openEuler; databases include DM8, KingbaseES V8, and OceanBase 4.x. Deployment packages ship in both amd64 and arm64, so there's no need to run x86 emulation on ARM — performance is uncompromised. If your exact OS patch level or CPU model isn't on the list, run the precheck first; it reports compatibility against the actual kernel and instruction set rather than against a name.
Compared to CentOS, deploying on Kylin or UOS mostly differs in dependency libraries and security policy. The suggested sequence: first disable or whitelist SELinux/security labels, extract the package to a dedicated directory, install the domestic builds of glibc, libstdc++, and openssl via the system package manager, then run the bundled precheck.sh for environment self-check — it inspects kernel version, CPU architecture, memory, and disk IO, and tells you exactly what's missing. On Kunpeng (ARM), watch the page size: some Kunpeng servers default to 64KB pages while the storage engine compiles for 4KB. If precheck reports a page-size warning, switch to a 4KB-page kernel or use the dedicated 64KB package. Many teams trip here; confirming early saves half a day of debugging. Another ARM gotcha: check that the JDK or runtime you bundle is itself an aarch64 build — an x86 JVM running under emulation will quietly destroy throughput.
The built-in database can be swapped for DM or KingbaseES without rewriting business SQL — the platform's query layer maps its dialect onto the target. Install the target database, create the schema and account, then in the deployment config change storage.backend from the built-in engine to dm or kingbase and fill in the connection string and credentials. On first startup the platform runs the schema script automatically and migrates metadata. For existing data, use the bundled migrate.sh, which supports time-batched migration with resume-from-breakpoint — the old store stays read-only and the new one takes writes, so business is uninterrupted. Run a small batch first and diff the row counts before migrating everything; a hash check on a sample of records is cheap insurance against silent truncation of character sets (GB18030 vs UTF-8) when moving from a legacy store. On the middleware side, the message queue and cache both offer domestic alternatives (e.g. RocketMQ, TongRDS) with identical external interfaces, so swapping them doesn't ripple into your applications.
Before going live, tick through this checklist. First, functional verification: exercise all three data flows — logs, metrics, and traces — and confirm one synthetic record of each is queryable. Second, performance verification: replay production-like load with a stress tool and check query latency and collection throughput against your baseline; ARM and x86 should be within a few percent of each other, and if they're not, look at page size and JVM builds before blaming the platform. Third, high-availability verification: kill a node manually and confirm a replica takes over with no data loss. Fourth, security and compliance: confirm password encryption, audit logging, and the relevant classified-protection settings are enabled. Only switch real traffic after all four pass. The crux of Xinchuang migration isn't "can it install," but "does it behave identically to the original environment after installation" — this checklist exists to guarantee that consistency.
A note on rollback: before switching to the domestic stack, snapshot the full configuration and keep the previous x86 deployment intact for at least one billing cycle. If a latent incompatibility surfaces under real load — typically in a rarely-exercised code path — you want the option to flip back without re-installing everything. Also plan capacity on the domestic hardware rather than assuming one-to-one parity: ARM servers with the same core count sometimes behave differently under the platform's compaction-heavy workload, so run the performance verification at your real peak, not a synthetic average.