Picking an Observability Platform for Domestic Stack: A Compatibility Checklist

Compatibility is a hard gate in domestic-stack projects

An observability platform is rarely the core system in a Xinchuang (domestic-computing) project, but it is the one inspected during compliance acceptance and the one you reach for when something breaks. If the platform only runs on x86, only talks to MySQL and depends on a stack of foreign components, it will stall at acceptance. Asking about compatibility item by item during vendor selection costs far less than reworking after go-live — because by then the servers are bought and the schedule is set.

CPU and operating system

• CPU: Kunpeng 920, Phytium 2000+/S2500, Hygon, Loongson. Confirm the vendor ships installers for the matching architecture. ARM64 is the key point — an x86-only binary means no adaptation at all, regardless of what the brochure says.
• OS: Kylin V10 (SP1/SP2), UnionTech UOS Server, openEuler. Watch kernel-version differences. If the platform uses eBPF for non-intrusive collection, verify the target kernel supports it up front, or the agent will not start and every troubleshooting session begins with "no data."

Ask the vendor for a matrix of supported CPU × OS combinations rather than a vague "supports domestic platforms." A matrix tells you where the testing actually happened.

Database

Common databases in domestic-stack environments are OceanBase, TiDB (domestic distributions), DM (Dameng), KingbaseES and GaussDB. Check each storage concern of the platform one by one:

1. Does it support the MySQL protocol? OceanBase and TiDB mostly do, which keeps changes small.
2. Does it ship adapters for DM and KingbaseES, which speak domestic SQL dialects?
3. What engine stores the time-series data, and does it run on domestic hardware?

Put "database type + version + deployment form" into the technical agreement explicitly, so acceptance does not reveal that only one database was ever adapted. If you can, run a proof of concept on the actual target database before signing.

Middleware and deployment form

• Offline deployment: domestic intranets usually have no public internet. The installer must bundle every dependency, otherwise images cannot be pulled and nothing installs. Verify an air-gapped install in a clean VM as part of the evaluation.
• Message queue: if the ingestion path depends on Kafka, confirm compatibility in the domestic environment — open-source Kafka works, or a domestic packaging of it.
• Container runtime: if Kubernetes is involved, confirm support for iSulad and Containerd rather than assuming Docker.

Performance on domestic ARM

Compatibility is only the first hurdle; performance is the second. Domestic ARM chips have plenty of cores but differ in single-thread performance and in the availability of SIMD and crypto extensions. When evaluating an observability platform on Kunpeng or Phytium, test the workloads that will actually run: sustained log ingestion rate, query latency over a few hundred gigabytes of logs, and the CPU overhead of the collector on a busy host. Ask for numbers measured on ARM64, not x86 — results from an Intel benchmark do not transfer.

One more practical step: insist on a reference environment. Have the vendor stand up the platform on your exact CPU, OS and database for a week and run a representative load. A compatibility checklist is a filter; a reference environment is the proof. Most acceptance disputes happen because the checklist passed but the real environment did not.

A checklist you can reuse directly

| Item | Must ask | Pass criterion |
| --- | --- | --- |
| CPU architecture | ARM64 installer | Installs on Kunpeng/Phytium |
| Operating system | Kylin/UOS support | Starts and collects normally |
| Database | OceanBase/DM | Metadata persists |
| Offline install | No public network | Installs air-gapped |
| Collector | Kernel compatibility | Logs and metrics flow |

Write these five lines into the technical agreement during selection, then tick them off one by one at acceptance. The core question in domestic-stack selection is not "can it run", but "can it run, collect and query in the target environment". Use the checklist to force vendors to give a definite answer instead of a "should be fine" — the difference shows up the first time you hit a real kernel, a real database and no internet.