Deploying an observability platform on domestic CPUs, Kylin/UOS operating systems, and domestic databases poses architecture and dependency challenges. This post offers a selection checklist, Observe’s compatibility matrix and benchmarks, plus a phased rollout plan.
A domestic (xinchuang) environment isn’t just “swapping the OS”—it changes three things at once.
Three real constraints of a domestic stack
- CPU architecture: from x86 to ARM (Phytium, Kunpeng) or LoongArch (Loongson), every binary that depends on native code has to be recompiled and re-verified.
- Operating system: Kylin and UnionTech UOS, based on openEuler or Debian—package management, kernel parameters, and systemd behavior all differ from CentOS.
- Database and middleware: from MySQL/Oracle to DM, KingbaseES, GaussDB. Ecosystem, drivers, and migration cost all need evaluation.
For an observability platform, the direct challenge is that all three layers—collection agent, storage engine, and web service—must run on these combinations without a performance penalty.
A checklist for evaluating vendors
When picking an observability platform for a domestic stack, treat these four as hard requirements:
- Native architecture support: are ARM64 / LoongArch packages or images provided, or just an x86 tarball you’re expected to figure out yourself?
- Dependency containment: does it pin a glibc version or bundle x86-only libraries? A single static binary eliminates most “missing .so” problems.
- Database compatibility: does the metadata store support DM/KingbaseES, or only MySQL? This decides your migration cost.
- Performance validation: is there a benchmark on Phytium/Kunpeng hardware, comparing throughput and latency against x86?
Observe’s compatibility matrix
Observe OBSERVE’s current coverage on domestic stacks:
| Component | Support |
| --- | --- |
| CPU | Phytium FT-2000+/D2000, Kunpeng 920, Hygon C86, Loongson 3A5000 |
| OS | Kylin V10 (ARM/LoongArch), UnionTech UOS 20/1060 |
| Database | DM8, KingbaseES V8, openGauss |
| Deployment | Bare metal, KubeSphere, cloud-native (ARM64 images) |
The collection agent ships as static x86 and ARM64 binaries with no runtime dependencies, managed directly by systemd.
Reference performance numbers
On a single Phytium FT-2000+ (64-core) box, we measured a baseline worth citing for evaluation:
- Log collection throughput: 60k lines/sec on one node, within 8% of an equivalent x86 box.
- Search query P95: 2.1s for a single-table aggregation over a billion rows, versus 1.8s on x86.
- Disk write amplification: roughly 1/8 of raw log size after columnar compression.
These figures are from a single-node deployment; a three-node cluster scales writes roughly linearly and improves query latency further. The takeaway: domestic hardware has no fundamental weakness for observability workloads. The gap is mostly single-core performance, which horizontal scaling makes up for.
Rollout: from single-node pilot to cluster
Don’t replace production wholesale on day one. A sensible cadence:
- Single-node pilot (week 1): install server + agent on one Phytium or Kunpeng box, attach one non-critical service’s logs and metrics, and validate the full collect-store-query path.
- Load test (week 2): replay real traffic, focusing on write throughput, query latency, and disk usage, and compare against an x86 baseline.
- Gradual migration (weeks 3–6): move logs and traces in order of service importance, low to high, keeping the old system read-only as a fallback.
- Full cutover + backup (after week 6): retain data export to meet acceptance and audit requirements.
Three things people forget when migrating
- Config, not just data: alert rules, dashboards, and collection templates must be exported and re-imported. Migrating data but not config means you find out the moment alerts stop firing.
- Historical data: migrate only the last N days of hot data and keep the rest read-only in the old system—it saves both disk and time.
- People: Kylin/UOS habits differ from CentOS. Give ops time to adapt before cutover day, or you’ll discover on the day that nobody knows how to restart a service.
Two easy traps to hit
- Time sync: domestic machines often have NTP unconfigured or misconfigured, causing timestamp drift that breaks search and trace ordering. Fix NTP before going live.
- Kernel parameters: Kylin/UOS defaults for
vm.max_map_count and file handles are low; high-concurrency collection hits too many open files. Raise them per the deployment guide before load testing.
The question with a domestic stack isn’t “can it run,” but “does it run stably, and how painful is the migration.” Validating compatibility up front saves a lot of rework later.