Accepting a Xinchuang Migration: Benchmarking Observability from x86 to Domestic ARM

Establish a Baseline Before You Migrate

When you move an observability platform from x86 to domestic ARM (Kunpeng/Phytium) plus Kylin/UOS, the most common mistake is declaring victory the moment it boots — then finding out after go-live that search is slower and ingestion is dropping data. The right approach is to record a baseline on the old x86 environment first: run a fixed load-test script and measure log-ingestion throughput, search latency, collector CPU/memory, and alert-evaluation latency. Those numbers become your acceptance reference.

Cover three dimensions in the baseline: ingestion (logs per second, metric-point throughput), query (P50/P99 search latency, aggregation cost), and resources (CPU/memory/disk for each platform component). Without a baseline, every "it feels slower" argument has no evidence to stand on, and you'll end up in meetings arguing about feelings instead of numbers. A baseline also protects the migration team: if search is slow after the move, you can tell whether it's the new hardware or a pre-existing problem that just got noticed.

Benchmarking: Three Metrics That Matter

After migrating, re-run the same script against the same data volume and focus on three numbers:

| Metric | x86 baseline | Domestic ARM | Verdict |
| --- | --- | --- | --- |
| Log ingestion | 120k/s | 110k/s | <10% delta, acceptable |
| Search p99 | 380ms | 410ms | acceptable |
| Collector CPU | 12% | 15% | worth watching |

A practical pass bar: within 15% on ingestion and query is fine; beyond 30% means you need to look at the architecture level — common causes are domestic JDK JIT behavior, storage engines not tuned for ARM, or page-size/memory-alignment issues. Don't just watch averages; p99 is what users actually feel, and a great average hiding a terrible tail is still a bad migration. Run the benchmark more than once and at a realistic load, not an empty lab.

Acceptance Checklist: Function, Performance, Security

Tick every box; missing one means the migration isn't done:

• Function: walk the whole path — log search, metric query, tracing, alert firing, notification delivery;
• Performance: the benchmarks above pass, plus a 7×24 stability watch with no memory leaks and no abnormal disk growth;
• Data: reconcile log/metric/trace counts before and after, and spot-check samples for missing content;
• Security: domestic crypto (SM2/SM3/SM4) enabled, audit trails and multi-tenant isolation verified for compliance;
• Domestication: confirm it runs on domestic CPU/OS and connects to domestic databases (DM, KingbaseES, OceanBase) without compatibility errors.

Write the checklist down before you start, not after. A checklist you invent mid-migration is how items quietly get skipped.

Gray Cutover and Rollback

Don't flip all traffic at once. Go in three steps:

1. Dual-write: run old and new in parallel for 1–2 weeks and compare data consistency and alert results;
2. Gray read: send 10% of query traffic to the domestic environment, watch latency and stability, then ramp up;
3. Full cutover + rollback plan: keep the old environment for at least 30 days and define a rollback trigger (e.g., search p99 exceeds the threshold for 30 consecutive minutes) with one-click switch-back.

Acceptance doesn't end at "it runs"; it ends at "it stays stable, and you can back out." The rollback path is as important as the migration path, and it's the thing most teams leave out until they need it at 2 a.m.

A final point on governance: put the acceptance sign-off in writing, with the benchmark numbers attached. When the platform has run on domestic hardware for six months and someone asks whether it's "actually as fast," you want the before/after table, not a memory. Also schedule a re-benchmark at the 90-day mark — domestic JDK and storage patches ship frequently, and a mid-life check often catches a regression early while it's still cheap to fix. Keep the old x86 baseline snapshot around too; it's the reference you'll diff against for every future change, not just this migration.