Migrating Your ELK Stack to ARM-Based Xinchuang Infrastructure: A Practical Guide

For many teams, the Xinchuang (domestic substitution) migration stalls on the logging side. In a legacy ELK stack, Elasticsearch depends on x86 instructions, and older Filebeat releases have no ARM binaries — so the moment you boot on domestic CPUs (Kunpeng, Phytium) or domestic OSes (Kylin, UOS), things start failing. Here's a migration path you can actually execute.

Start with a compatibility audit

Before touching anything, put every component in a table and check domestic-platform support:

| Component | x86 status | Xinchuang replacement |
|---|---|---|
| Elasticsearch 6.x/7.x | No official ARM build | OBSERVE (native ARM64) |
| Filebeat | Old versions lack ARM | OTel Collector filelog |
| Kibana | Read-only visualization | OBSERVE console |
| Logstash | Many x86 compile deps | Drop it, use Collector |

The key decision: don't try to compile an old ES on ARM. It's a rabbit hole with no official support, and the community builds you'll find are unmaintained. Replace the logging stack as a whole rather than porting it piece by piece — moving collection, storage, and querying together onto components with native domestic-platform support is actually cheaper than point-by-point porting.

A three-step migration

Step 1: dual-write and canary cutover. Have the collector send logs to both the old ELK and OBSERVE in parallel. Run for one to two weeks; switch over only once the data volume and fields match on both sides. This is your safety net — if anything looks wrong, you can still point people back at the old stack.

Step 2: align fields and cleanup. Move the parsing that used to live in Logstash (JSON expansion, timestamp formats, multiline merge) into Collector processors so query semantics stay identical. A multiline Java stack-trace merge looks like this:

receivers:
  filelog:
    include: [/var/log/app/*.log]
    operators:
      - type: regex_parser
        regex: '^(?P<time>\d{4}-\d{2}-\d{2} \S+) (?P<level>\S+) (?P<msg>.*)'
      - type: recombine
        combine_field: msg
        is_last_entry: '^(?!\d{4}-\d{2}-\d{2})'

Step 3: backfill history. Export the indexes you still need from the old ES via snapshot, convert them to JSON Lines, and bulk-load them into OBSERVE, preserving the original timestamp values so you can still look back.

Domestic hardware specifics worth knowing

Kunpeng (ARMv8) and Phytium CPUs run the same ARM64 binaries, so a single ARM64 collector build covers both. The practical differences show up in tuning: Kunpeng boxes are typically wider — more cores per socket but lower-clocked — which favors running several collector instances and letting the batch processor absorb bursts, rather than sizing one instance for peak. Check that your vendor's ARM64 build matches your OS: Kylin V10 and UOS both ship ARM64 userlands, but glibc versions differ, so prefer a vendor-packaged or statically-linked binary over building from source. If you must build, pin the exact toolchain version and test against the oldest OS you still run.

Collector pitfalls on Kylin and UOS

• Domestic OSes ship with SELinux or hardened policies enabled by default. Grant the collector access to the log directory — on Kylin, chcon -t container_log_t /var/log/app — or disable the specific policy.
• Standardize on the Asia/Shanghai timezone so log timestamps and alert times line up. Mismatched timezones are the single most common "the alert fired at the wrong time" complaint after a migration.
• Manage the collector with systemd and set Restart=always; power and network blips in domestic data centers happen more often than you'd expect.

Verification checklist before cutover

Before you flip the switch, walk this list: log volume on OBSERVE matches the old ELK within a few percent over a 24-hour window; a sample of 50 queries returns the same field names and values on both sides; the collector holds up under a burst (inject a spike and confirm the disk queue drains, not drops); and alert rules fire against OBSERVE data with the same latency as the old stack. Checking these four things takes an afternoon and catches almost every migration problem before your users do.

What you gain after migrating

Dropping the ES cluster noticeably reduces the logging side's resource footprint — ARM server cores are cheaper per unit, and OBSERVE runs natively on domestic CPUs and OSes with no compatibility layer to maintain. With collection, storage, and querying fully on domestic platforms, the logging items in your security-grade (dengbao) assessment and Xinchuang acceptance usually pass in one round, instead of patching individual components over and over.