← Back to blog
Xinchuang 4 min read 炬鲸团队

Full-Stack Xinchuang: Deploying Jujing OBSERVE on Kunpeng + Kylin

A complete deployment record for Jujing OBSERVE on Kunpeng 920 + Kylin V10 + a domestic database: dependency swaps, ARM compatibility, storage and JVM tuning, plus three common pitfalls — a reusable checklist for Xinchuang teams.

The hard part of Xinchuang (domestic IT substitution) is not installation — it's making sure the system stays stable after it's up. This article records a complete deployment and tuning run for Jujing OBSERVE on Kunpeng 920 (ARM) + Kylin V10 + a domestic database, with the pitfalls flagged inline.

Environment and dependency swaps

Target environment: Kunpeng 920 CPU, Kylin V10 SP3 (kernel 4.19), DM8 (Dameng) as the metadata database, AArch64 architecture. Confirm three things before you start:

uname -m            # should be aarch64
cat /etc/kylin-release
ldd obs-observer    # check dynamic libraries are present

OBSERVE ships native AArch64 packages, so no QEMU translation is needed; both obs-observer and obs-collector are compiled for ARM. If an older release only gave you x86 binaries, don't force it through qemu-user — the collector takes a real performance hit — request the ARM packages instead.

Database and storage tuning

Metadata lives in DM8, which needs large pages enabled and the connection count adjusted. DM8 defaults to an 8K PAGE_SIZE; for OLTP workloads, migrate to a fresh database with 16K pages. Put the time-series data directory on SSD/NVMe:

# /etc/fstab example: data disk mount
/dev/nvme0n1p1  /data  xfs  defaults,noatime,nodiratime  0 2

noatime avoids a large volume of metadata writes; time-series writes are intensive, so add it at mount time. On the JVM side, when sizing the observer heap, note that compressed pointers are on by default under AArch64 — keep them if the heap stays under 32G, as they significantly cut memory use.

ARM compatibility on the collector

When deploying the log and metric collectors onto business hosts, check three things: the binary is aarch64, the OpenTelemetry collector uses an ARM build, and kernel eBPF features work on 4.19. Kylin V10 ships with security hardening enabled by default (SELinux/AppArmor-style policies), so before the collector can read /var/log and open network ports you must allow them:

setenforce 0    # temporary for debugging only; in production write allow rules instead of disabling

Three common pitfalls and acceptance criteria

First, clock sync: distributed tracing requires consistent time across nodes, so configure chrony/NTP and keep drift in the millisecond range. Second, the domestic database driver version is tightly bound to the DM8 minor version — upgrade the JDBC driver whenever you upgrade DM, or the connection pool will drop connections intermittently. Third, in mixed ARM/x86 clusters, normalize metric units (e.g. CPU core counts) to a single standard, or cross-architecture comparisons will be misleading.

Sizing and resource planning

ARM servers don't map one-to-one to x86 sizing, so don't reuse your old spec sheet. Kunpeng 920 cores run at lower clock speeds but you get more of them, so size by core count and memory bandwidth rather than by GHz. For a mid-size deployment ingesting a few terabytes of logs per day, a three-node observer cluster with 16 cores and 64 GB per node is a reasonable starting point — but measure your own ingest rate before committing.

Storage is the long-term cost driver. Use NVMe for hot time-series data and tier older data to slower disks or object storage; the noatime,nodiratime mount flags and 16K DM8 pages from earlier matter more than CPU here. Watch collector memory too: the ARM OpenTelemetry collector build is leaner than x86, but eBPF probes on the 4.19 kernel can grow kernel memory, so cap the probe count and keep an eye on slab usage.

Benchmark before you cut over. Run a one-week shadow ingest from a representative slice of production, compare query P95 and ingest throughput against the existing x86 stack, and only then move real traffic. The acceptance criteria above are the exit checklist for that shadow run.

Acceptance criteria: single-node throughput stays above 90% of the expected value, query P95 latency matches the x86 environment, and there are zero collection gaps over seven consecutive days — then the Xinchuang environment passes.