A field guide to deploying jjhub OBSERVE on the Xinchuang stack (KylinOS V10 + ARM + DM database), covering dependency adaptation, performance baselines, common pitfalls, and acceptance criteria.
A typical Xinchuang project runs on Phytium/Kunpeng ARM chips with KylinOS V10 or UOS, backed by a DM or KingbaseES database. OBSERVE ships an offline installer with all dependencies bundled, so it works in air-gapped intranets where pulling packages from the public internet isn't possible. A minimal deployment uses three nodes: one for the control plane and ingest gateway, two for time-series storage and search, with DM8 as the metadata and configuration store.
[ Control plane + gateway ] --- [ Search nodes x2 ] --- [ DM8 ]
| |
(ingest data) (log/metric/trace storage)The three-node layout is the smallest production-ready setup; smaller proof-of-concept deployments can run on a single node, but you lose redundancy, which matters in a sector where availability requirements are strict.
KylinOS V10 is derived from openEuler/CentOS, so most Linux skills carry over, but a few things deserve attention:
vm.max_map_count to 262144, otherwise the time-series engine repeatedly reports out of memoryjdbc:dm://host:5236 (default port 5236)DM's SQL dialect differs slightly from MySQL. OBSERVE's metadata layer already adapts to it, so choose "DM" when creating the schema — do not pick MySQL mode. Picking the wrong mode later surfaces as subtle query failures that are hard to trace back.
The move to ARM isn't just a procurement checkbox — it changes a few operational assumptions. Some older monitoring agents are x86-only binaries and won't run at all on Phytium/Kunpeng, so verify that every collector and exporter has an aarch64 build before you commit to the platform. Storage I/O also behaves differently: on ARM servers the default I/O scheduler and storage driver are often tuned for spinning disks, so double-check they're set for SSD to avoid silently capping throughput. If you're migrating from an existing x86 deployment, plan a parallel run — keep the old platform online while the new one backfills history, then cut over once dashboards and alerts match.
Measured on a single Phytium 2000+ (64 cores) node with 128G RAM, for capacity planning:
Capacity depends heavily on disk type. Use NVMe SSD for log and time-series data, and a regular SSD for metadata. On ARM hosts, also confirm the storage driver and I/O scheduler are configured for SSD rather than the spin-disk defaults, which can silently cap throughput.
Two pitfalls come up most often. First, a misconfigured local yum repo in the intranet breaks dependency installation — copy the offline bundle together with its dependencies rather than assuming the repo has everything. Second, DM's charset must be UTF-8; selecting GBK corrupts Chinese logs and can't be fixed smoothly later. A third, less obvious pitfall is clock drift between cluster nodes — if the search nodes' clocks drift from the ingest node, traces and logs appear out of order or missing entirely. Run chrony on every node and alert on clock offset, not just at install time but as an ongoing check.
For acceptance, focus on three things: 72 hours of continuous uptime without restart; alerts fire correctly and no data is lost under simulated disk-full and network-jitter conditions; end-to-end latency from collection to console display stays under 30 seconds. It's also worth verifying before go-live that the offline installer's package signatures match the vendor's published hashes, and that every collector and agent binary has a confirmed aarch64 build — catching either of these late in a Xinchuang project can push a launch back by weeks. Passing all three is a solid signal that the platform is ready for production in a Xinchuang environment.