A complete walkthrough for deploying OBSERVE on Kylin V10 (Phytium/Kunpeng aarch64) with Dameng DM8 or KingbaseES, covering DB init, compatibility gotchas, and benchmark numbers.
The hard part of a Xinchuang deployment is not "will it run," it's the dependency chain. glibc versions, system libraries, database drivers, and the build toolchain can all differ from x86. The OBSERVE server is compiled in Go and ships as an aarch64 static binary with no runtime dependencies — copy it over and it runs. The Agent also has an arm64 build, so there's no compiling on site. That also means you don't need GCC or a Go toolchain on the target machine; a shell that can extract a tarball is enough. Most Xinchuang projects stall not on the application itself but on getting a working build environment on a locked-down host, so shipping static binaries removes that entire class of problem.
/usr/local/jjhub/, and create a run user with useradd -r -s /sbin/nologin jjhub;init-dm.sql / init-kingbase.sql scripts import directly;config.yaml to point at the database:database:
type: dm8
host: 127.0.0.1
port: 5236
user: jjhub
password: "******"systemctl daemon-reload && systemctl start jjhub, then check journalctl -u jjhub -f for errors.schema parameter in the connection string;timedatectl output matches your business timezone, or log timestamps will shift by 8 hours;firewall-cmd, or collected data won't get through.For production, plan on at least three nodes: the OBSERVE server in active-standby or cluster mode, and the database on Dameng or Kingbase's built-in replication. Collection Agents are distributed to each business host and report to the nearest gateway. A single 4-core/16 GB node handles millions of log lines per day; as volume grows, move storage to dedicated nodes and archive cold data to object storage. Keep the Agent count in mind too — hundreds of hosts each pushing logs will saturate a single gateway before the server does, so size the gateway tier separately.
On two 4-core/16 GB Phytium servers (one running OBSERVE, one running Dameng), single-node log ingest reached roughly 30,000 lines per second, and aggregate queries over a billion-log dataset returned with a P95 under 3 seconds. An observability platform runs fine on the Xinchuang stack — the key is picking the right architecture: aarch64 binaries plus domestic database adapters, not brute-force compiling x86 source on ARM. If your vendor only offers x86 packages, treat that as a red flag for how much pain the rest of the rollout will bring.
Two practical items often get missed in Xinchuang rollouts. First, network topology: domestic data centers frequently segment the management plane from the business plane, so decide early whether the OBSERVE server and its gateways sit in the same VLAN as the database. The database is usually the bottleneck, not the application, so co-locate them and keep the Agent-to-gateway path short. Second, make sure your vendor ships arm64 artifacts as a first-class product, not a one-off build. Ask for the exact glibc baseline their binaries target, and a statement on which Kylin/UOS patch levels they test against. A vendor that can't answer those two questions is one that will cost you a week of integration time the first time the OS pushes a security update.
One last note on verification: after the smoke test, run the exact same jjhub reindex and systemctl status jjhub sequence on one spare host before touching production, so the first real cutover is a repeat of a known-good procedure rather than a first attempt.