Running an Observability Platform on UOS and KingbaseES

Picking the stack in a sovereign environment

When government and enterprise customers deploy an observability platform, three lines must all be domestic — hardware, operating system and database — and the data must stay on the internal network. The previous article covered Kylin V10 plus Dameng; this one covers another equally common but subtly different stack: UOS (ARM), Hygon or Kunpeng servers, and KingbaseES V8.

The first question is database compatibility. An observability platform is fundamentally a write-heavy, read-light workload: logs, traces and metrics put far more pressure on writes than on queries. Among domestic databases, both KingbaseES and Dameng offer a MySQL-compatible mode, but KingbaseES's PostgreSQL-compatible mode is more complete, so if your team already knows the PG ecosystem, KingbaseES is the smoother choice. That familiarity shows up in subtle ways — collation behavior, SQL dialect quirks, connection-pool tuning — and it saves real time during migration.

One more thing to pin down early: which CPU you will actually receive. Hygon and Kunpeng are both aarch64, but some deliveries still include x86_64 hosts for legacy workloads. Confirm the architecture before downloading binaries, or you will spend an afternoon chasing a segmentation fault that is just a wrong build.

It is also worth deciding early whether you want KingbaseES in PG or MySQL mode, because that choice is far cheaper to make before data is loaded than after. Both modes work with Observe, so let the rest of the estate drive the decision: if your other business systems already standardize on MySQL protocol, staying in MySQL mode keeps your DBAs working with one mental model instead of two.

Preparing dependencies and the database

• OS: UOS Server (aarch64)
• CPU: Hygon 7000 series or Kunpeng 920
• Database: KingbaseES V8 (either MySQL or PG compatibility mode)
• Time sync: NTP is mandatory — tracing is sensitive to clock skew

KingbaseES speaks the PG protocol by default. Observe uses standard SQL, so you pick a compatibility mode when creating the database and no application code changes:

CREATE DATABASE observe;
CREATE USER observe WITH PASSWORD 'Observe@2024';
GRANT ALL PRIVILEGES ON DATABASE observe TO observe;

A note on the compatibility mode: if you plan to switch databases later (say, from KingbaseES to OceanBase in MySQL mode), pick the mode that matches your target, because it affects collation and case-sensitivity behavior that is painful to change after logs are already indexed.

Startup and self-checks

Download the aarch64 single binary and manage it with systemd so it starts on boot and restarts on crash:

export DB_DRIVER=pg
export DB_HOST=10.0.0.20
export DB_PORT=54321
export DB_NAME=observe
export DB_USER=observe
export DB_PASSWORD='Observe@2024'
./observe --config ./env

After startup, do three checks: write a few test logs and confirm they are searchable, build a trace and confirm it links by trace id, and set a temporary alert rule and confirm it fires. All data stays on the internal network — nothing is sent out. If any of the three checks fails, fix it before you let the team depend on the platform; a half-working deployment is worse than none, because people will trust it anyway.

Tuning

ARM servers have weaker per-core performance than the equivalent x86, so tune for concurrency and memory:

1. Configure 2-4 worker processes to use the cores fully
2. Keep the KingbaseES connection pool modest and size it with a load test to avoid exhausting connections
3. Enable hot/cold tiering when log volume is high — hot data on SSD, cold on spinning disk
4. Track end-to-end latency from collection to searchability as your top-priority metric

Troubleshooting and acceptance

Common issues:

• Authentication failure against KingbaseES: confirm pg_hba.conf allows the application subnet and that the password method (md5 vs scram) matches the driver
• Inconsistent case in search results: check KingbaseES's case_sensitive and collation against the platform's expectations
• Broken traces: align NTP across all hosts to within milliseconds
• Segmentation faults: make sure you downloaded the aarch64 build, not x86_64

For acceptance, verify item by item against the cybersecurity assessment: least-privilege, audit-log retention and multi-tenant isolation. With those three in place you pass both the domestic-computing assessment and the security check — and, just as important, the platform is actually usable by the teams that will depend on it every day.