Deploying OBSERVE on a Full Domestic Stack: Kylin, Kunpeng, and DM

Target environment

The goal this time is a fully domestic stack: Kylin V10 SP3 (aarch64) as the OS, Kunpeng 920 as the CPU, Dameng DM8 as the database, and TongWeb as middleware. OBSERVE ships an ARM build and a Dameng initialization script, and the steps below were verified on a production test machine. We picked this exact combination because it is the most common one on the domestic-substitution lists for government and finance, which makes the pitfalls we hit the most reusable. Everything below assumes a fresh Kylin V10 SP3 install with the default repositories enabled and root access, which is the normal starting point for a brand-new observability node in a domestic datacenter.

Installation and initialization

Install system dependencies first. Kylin V10 ships with yum; remember to disable SELinux and open the ports:

yum install -y gcc gcc-c++ make libaio
sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config
firewall-cmd --permanent --add-port=8080/tcp && firewall-cmd --reload

After extracting the package, initialize the Dameng database. DM8 is highly Oracle-compatible, so run the init SQL with Dameng's own disql client:

CREATE TABLESPACE observe_ts DATAFILE '/dm8/data/OBSERVE/observe.dbf' SIZE 512 AUTOEXTEND ON;
CREATE USER observe IDENTIFIED BY "Observe@2024" DEFAULT TABLESPACE observe_ts;
GRANT DBA TO observe;

Then point the config file at the dm driver:

database:
  type: dm
  host: 127.0.0.1
  port: 5236
  user: observe
  password: Observe@2024
  pool_size: 50

Start the service and confirm the health check endpoint returns 200, and you are done.

ARM tuning

Kunpeng is an ARM platform, and a few details matter:

• Create the Dameng database with page_size=32K and enable Transparent Huge Pages — it gives a measurable write-throughput boost.
• Put log indexes on NVMe SSDs and separate the time-series write path from the query path so they do not fight over IO.
• Enable huge pages with echo 8192 > /proc/sys/vm/nr_hugepages and set USE_HUGE_PAGE=1 on Dameng.

One thing to watch on Kunpeng specifically: its NUMA topology differs from x86 servers. If you run OBSERVE across multiple sockets, pin the ingest and query processes to their local NUMA nodes — otherwise cross-socket memory access quietly eats a third of your throughput.

Compatibility verification

The classic fear on domestic stacks is "it installs but it doesn't perform". We ran three classes of verification:

1. Functional: log collection, SQL search, alert triggering, and trace display all pass.
2. Performance: 20,000 log lines per second ingested on a single node, with search P99 latency under 800ms.
3. High availability: kill one node and the cluster fails over automatically with no data loss.

Common errors

• libaio.so.1 not found: Dameng won't start without libaio; fix with yum install -y libaio first.
• Port 5236 blocked by the firewall: it is Dameng's default port, and initialization hangs at the connection step if it is not opened.
• Installer reports a GLIBC version too low: Kylin V10 SP3 ships glibc 2.28; if you hit this, upgrade the OS or use a statically linked build.

Performance expectations

On the single-node Kunpeng 920 box above, OBSERVE sustains roughly 20,000 log lines per second of ingest at about 60% CPU, and a trace query over a 24-hour window returns in under a second. Measure both numbers on your own hardware before go-live, because the aarch64 build's profile differs from x86 — it leans more on the vectorized scan path, which is why page size and huge pages matter more here. If you are coming from an x86 deployment, re-baseline rather than assuming parity.

Day-2 operations

Deployment is the easy part; keeping a domestic stack running is the real work. Two habits help. First, pin the Dameng and OBSERVE package versions together — the compatibility matrix is not always obvious, and a silent Dameng patch has broken the JDBC driver more than once. Second, keep the aarch64 build artifacts in an internal mirror, because public repos are the first thing to become unreachable in an air-gapped environment. Finally, schedule regular DM8 backups of the OBSERVE metadata tables — trace and log data is replicated across nodes, but configuration and alert rules live in the database and are the one thing a restore cannot reconstruct by hand.