Full-Stack Xinchuang Support in OBSERVE: From CPU to Database

Coverage: From Silicon to the Data Layer

Xinchuang migration isn't swapping one machine — it's replacing the entire stack layer by layer. OBSERVE's current adaptation status across those layers:

• CPUs: Kunpeng 920, Phytium S2500, Hygon C86, and Loongson 3A5000, each with matching binaries and container images.
• Operating systems: Kylin V10 (SP1/SP2), UOS V20, and openEuler 22.03 LTS.
• Databases: DM8, KingbaseES V8, openGauss 3.0, and GBase 8a.
• Middleware: TongWeb and BES, verified as drop-in replacements for Tomcat.

Every row in that table has passed a full test matrix, not just a theoretical claim. We still recommend a smoke test against your own workload before go-live, because differences in domestic environments tend to surface in drivers and character sets.

Why You Replace Layer by Layer, Not All at Once

A lot of Xinchuang migrations fail because teams try to swap CPU, OS, and database in a single window, then can't tell which layer caused a problem. The right order is "one layer at a time, verify each": swap the CPU first (keeping an x86 OS), then the OS, then the database. Run a regression and a load test after each layer, and only move on once performance and functionality show no regression. OBSERVE's adaptation testing follows the same order, which is why you can mix layers individually instead of waiting for an entire Xinchuang environment to be ready in one shot.

Timeline and Resource Planning

For a mid-sized team (a few hundred machines, a few dozen services), a full-stack Xinchuang migration typically runs in three phases: evaluation and selection (2-4 weeks, running compatibility tests and choosing the database), gray migration (4-6 weeks, moving log storage first, then metadata, then the query nodes), and parallel operation (2-4 weeks, running old and new environments side by side and comparing search results and alert output). Budget 2-3 months overall. The database migration is the biggest variable — leave enough parallel-run time, because the pitfalls in a Xinchuang environment tend to surface only when real traffic hits it.

Swapping the Database in Three Steps

Using DM8, the most common choice, as the example, replacing the default storage repository works like this:

1. Prepare the database: create it with compatibility mode enabled. For DM8, set COMPATIBLE_MODE=4 (MySQL-compatible) to minimize SQL differences; for KingbaseES, choose the PostgreSQL-compatible mode instead.
2. Update the config: switch the driver and connection string in OBSERVE's storage.conf:

storage:
  driver: dm
  host: dm-host
  port: 5236
  user: observe
  password: "******"
  pool_max: 50

1. Verify and migrate: run the built-in jjhub-storage check to validate the connection and table-creation scripts, export the existing data and import it, then spot-check log search results to confirm nothing is lost.

Performance Notes and Tuning

On a typical Kunpeng 920 + Kylin V10 + DM8 stack, OBSERVE's log ingestion throughput is roughly on par with x86, while search latency runs about 10% higher. The gap that does exist comes from two places:

• On ARM, the JVM needs -XX:+UseG1GC with an explicit heap size to avoid frequent GC under default settings.
• DM8 range queries on partitioned tables require the time column to be the partition key — otherwise broad time-range searches degrade into full table scans.

For reference, our test cluster — Kunpeng 920 (64 cores) + DM8 + a three-node OBSERVE — sustains about 200,000 log lines per second of ingestion, with a P95 under 300ms for single-keyword searches over seven days of data. Your numbers will differ by workload, but the order of magnitude is a useful planning baseline.

Common Problems and Fixes

• Character-set mismatch: DM8 defaults to GB18030, which produces garbled text when mixed with UTF-8 collectors. Force UTF-8 at database creation time.
• Driver version: the JDBC driver bundled with Kylin V10 is old; if you see connection timeouts, upgrade to the latest official driver first.
• Permissions: domestic OSes ship with stricter default security policies. OBSERVE's data directory must be explicitly allowed, or writes fail with Permission denied.
• Clock sync: Phytium and Loongson boards have notable RTC drift. Enforce NTP across the cluster, or your log ordering will be wrong.

Migration Checklist

1. Confirm the CPU architecture and pull the matching image; double-check the uname -m output.
2. Finish the OS security baseline (the level-protection requirements) before installing the application.
3. Run the check script against the test database before cutting over.
4. When exporting the old environment's data, preserve the time zone and character set (force UTF-8).
5. After going live, keep an eye on three metrics: GC, connection pool usage, and disk IO.