Deploying an Observability Platform on Kylin V10 and Dameng Database

The hard requirements of a sovereign environment

Government and enterprise customers impose two hard requirements on an observability platform: data must stay on-premise, and the whole stack — ARM servers, Linux distribution and database — must be domestically sourced. An observability platform carries sensitive operational data such as logs, traces and alerts; if that data leaks out or the platform depends on foreign components, it becomes a hard failure in both the cybersecurity and domestic-computing assessments.

Observe is built on a lightweight Go architecture with few dependencies and ships as a single binary, which makes it a natural fit. This article walks through one real combination: Kylin V10 (ARM), Kunpeng 920 and the Dameng database DM8.

Environment and dependency preparation

• Servers: Kunpeng 920 or Phytium 2000+ (aarch64)
• OS: Kylin V10 SP2 or later (ARM edition)
• Database: Dameng DM8 (or MySQL 8 / OceanBase in MySQL mode)
• Time sync: configure NTP on every host — distributed tracing is sensitive to clock skew, and offsets above a few tens of milliseconds cause span misalignment

Dameng speaks the MySQL protocol, and Observe uses standard SQL, so you only need a dedicated account and schema — no application code changes. This matters a great deal in migration: often the resistance to going domestic is not the platform itself but the business systems that would have to change code to fit a new database.

Choosing a database: Dameng, OceanBase or MySQL

In a sovereign environment the database choice comes down to three things: assessment requirements, existing operational capability and data volume.

• Dameng DM8: on the domestic-computing catalog, a mature ecosystem, the most common choice in government projects, with a stable MySQL-compatible mode
• OceanBase: MySQL mode with strong distributed capability, a good fit when log volume is very large
• MySQL 8 (a domestic distribution): the lowest operational barrier if the assessment allows it

For Observe all three are standard SQL, so switching only changes the connection string. If unsure, start with Dameng — it is the safest default in domestic-computing projects.

Creating the database and initializing

Create a dedicated tablespace and account in Dameng, and enable compatibility mode so string collation and case behavior match MySQL — otherwise log search results can come back in the wrong order:

CREATE TABLESPACE observe_ts DATAFILE 'observe.dbf' SIZE 512;
CREATE USER observe IDENTIFIED BY "Observe@2024" DEFAULT TABLESPACE observe_ts;
GRANT DBA TO observe;

At startup, point Observe at the Dameng instance with its connection parameters:

export DB_DRIVER=dm
export DB_HOST=10.0.0.12
export DB_PORT=5236
export DB_NAME=OBSERVE
export DB_USER=observe
export DB_PASSWORD='Observe@2024'

Startup and self-checks

Download the aarch64 binary and run it under systemd, so it starts on boot and restarts automatically after a crash:

chmod +x observe
./observe --config ./env

After startup, run three self-checks: can log search return data, can tracing assemble a call chain from a trace id, and can alert rules fire. All data stays on the internal network with no outbound traffic.

Performance tuning advice

ARM servers usually have weaker single-core performance than same-generation x86, so tuning focuses on concurrency and memory:

• Give Observe 2-4 worker processes to make full use of the cores
• Do not oversize the database connection pool — Dameng has a limited default connection count, so load-test before deciding
• When log volume is high, enable hot/cold index tiering: hot data on SSD, cold data on spinning disks
• Treat end-to-end latency from ingestion to the platform as your top-priority metric and watch it continuously

Troubleshooting notes

1. Driver missing when connecting to Dameng: confirm DB_DRIVER=dm and that the driver is in the runtime directory, or switch to Dameng's MySQL-protocol port (5236 by default)
2. Case mismatches in search results: check the CASE_SENSITIVE setting and collation of the Dameng instance against what the platform expects
3. Broken traces from clock skew: keep all hosts on NTP with drift in the millisecond range
4. Occasional segfaults on ARM: make sure you downloaded the aarch64 build rather than x86_64, and verify the Kylin kernel version matches the binary's compile target

Acceptance checklist

Check each item against the compliance requirements: least-privilege permissions (the platform runs only necessary processes and the database account holds minimal grants), audit logging (login, query and export are all recorded) and multi-tenant isolation (departments cannot see each other's data). Only when all three are in place is the deployment truly done. Put the acceptance items into a checklist and tick them off before go-live, so nothing is discovered missing at the final review.