Migrating Your Observability Stack to Domestic ARM: A Field Checklist

Before you move: nail down compatibility

The most common way a domestic-computing migration goes sideways isn't the technology — it's starting without a compatibility checklist. An observability stack has far more moving parts than it looks: collection agents, the storage engine, the query layer, alerting and the UI. If any single one has no ARM build, the migration stalls halfway, and you discover the gap only after you've already begun decommissioning the old stack.

Start with a table that lists the support status of every component in the target environment:

| Component | x86 status | Domestic / ARM support | Verdict |
| --- | --- | --- | --- |
| Log collection | Filebeat | Observe's built-in agent (Go single binary) | Drop-in replacement |
| Storage engine | Elasticsearch | MySQL 8 / OceanBase / DM | Protocol-compatible |
| Query layer | Kibana | Observe console | SQL-like search |
| Alerting | In-house scripts | Built-in alert rule engine | Migrate the rules |

Observe is written in Go and ships as a single binary that compiles and runs directly on ARM, with no JVM-style heavy runtime. This step is usually the smoothest part of the whole move — but it's exactly the part people skip, because they assume "it's just a binary". Compile it once for the target architecture and verify it starts under Kylin V10's hardened kernel before you commit.

One practical shortcut: maintain a small matrix of "component / x86 version / ARM build status" and update it as the migration progresses, so the go/no-go decision at each milestone is based on facts, not memory.

Storage swap: from Elasticsearch to a domestic database

Replacing Elasticsearch is the core of the migration. Observe's storage layer speaks the MySQL protocol and can target MySQL 8, OceanBase (MySQL mode) or DM with zero application changes — you only swap the connection string:

# Observe needs only an env change
DB_HOST=10.0.0.12
DB_PORT=2881          # OceanBase MySQL-mode port
DB_NAME=observe
DB_USER=observe
DB_PASSWORD=********

When you pick OceanBase or DM, watch two things: use utf8mb4 everywhere so Chinese text and emoji in logs don't turn into mojibake, and confirm the compatibility mode (choose MySQL mode for OceanBase) instead of mixing in Oracle mode, which will break SQL dialects. Also plan capacity early: domestic databases size and scale differently from Elasticsearch, so run a load test against the new storage before you migrate any real data.

Data migration and parallel validation

A hard cutover is too risky. Prefer parallel validation: bring the new stack up first and let it receive a mirrored copy of traffic alongside the old one, then compare results.

1. Configure dual send at the collection layer: the agent forwards the same logs to both the old ELK and the new Observe
2. Run a week-long comparison: pick identical trace_ids and query conditions and check that both sides agree
3. Once key metrics line up, move read-only traffic to the new stack, then gradually shift write traffic
4. Keep the old stack around for 30 days as a rollback path, and decommission it only after things are proven stable

Do you migrate historical logs? Only bring over the last 90 days of hot data. Keep older cold data as archived files instead of paying migration cost for data almost nobody reads. Export the archives in a portable format so they remain searchable if an audit ever requires it.

Acceptance checklist

After the migration, verify these items one by one:

• Log search, tracing and alerting all pass self-checks
• All data stays on the internal network, with no outbound requests (confirm by packet capture)
• Permissions, audit and multi-tenant isolation meet security and domestic-computing compliance requirements
• Load test on the domestic database: 10,000 TPS of log writes per tenant with acceptable query P99 latency
• The rollback plan is in place and the old stack can be switched back at any time

Where possible, involve the security team in the packet-capture step — they are the ones who will sign off on the "no outbound traffic" requirement, and their sign-off carries weight at the acceptance review.

A domestic-computing migration isn't a one-shot event but a loop of "assess — run in parallel — switch — accept". Complete the checklist and you get both uninterrupted business and the sovereignty you need.