A practical Xinchuang migration walkthrough: ARM collectors on Kunpeng/Phytium, replacing Elasticsearch with domestic storage, a middleware checklist, and post-migration verification.
A Xinchuang (domestic IT) migration isn't just "reinstall on new hardware" — the hard part is compatibility with existing components and data. Before starting, inventory three things: what CPU architecture your current collectors run on (x86 or ARM), which databases and middleware your backend depends on, and how much historical log and metric data you have. These three determine your migration plan and downtime window. Skipping the inventory is how migrations turn into week-long firefights.
OBSERVE's Agent and Collector ship both amd64 and arm64 binaries, covering mainstream domestic CPUs like Kunpeng 920 and Phytium. On Kylin V10 or UOS:
curl -fsSL https://ob.jjhub.cn/agent/install.sh | ARCH=arm64 bash -s -- --tenant platform --token <token>The installer detects the glibc version and picks the matching build. On hardened domestic kernels, disable SELinux or allow the Agent's ports through policy — a blocked port is the most common first-run failure, and the symptom (silently no data) looks identical to a broken binary, which wastes hours if you don't check it early.
Many teams historically store logs in Elasticsearch. In a Xinchuang environment you can switch to OBSERVE's built-in distributed storage — Dameng or TiDB for metadata, a proprietary columnar engine for the log body. Migration happens in three steps:
jjhub-tools export;jjhub-tools import, which maps field types and corrects time zones automatically;keyword fields in index templates map to equivalent dictionary-encoded columns, so aggregation query syntax stays the same. The two things to watch are timestamp precision (ES stores millis in several places) and multi-field mappings, where one source field fans out into several typed columns.
Cutovers rarely happen all at once. For the transition period you'll run some collectors on x86 and some on ARM, and the backend must treat both as first-class. The arm64 and amd64 binaries share the same config schema and data schema, so a mixed fleet is transparent on the query side — nothing about your dashboards or alerts changes. The one thing to standardize is the installer invocation: pin ARCH explicitly in your provisioning scripts instead of letting the script guess, so a template applied to the wrong host fails loudly rather than installing a subtly wrong binary.
The usual pitfalls live in middleware: swap OpenJDK for Bisheng JDK or Kylin's bundled OpenJDK; after replacing Redis with a domestic-compatible build, watch the serialization protocol version; if you move from Kafka to a domestic MQ, reconfigure the Collector's exporter. Maintain a dependency checklist with each item marked "verified / needs replacement / unsupported", and review it before every cutover — a single unverified dependency is usually the thing that breaks at 2 a.m.
A migration that succeeds but runs 3x slower than the old stack is a failure nobody notices until peak traffic. Include throughput and latency comparisons in your smoke test: replay a captured workload against both clusters and compare ingest rate and P99 query latency. Domestic ARM chips have different single-thread performance profiles, so the right comparison is per-core and per-dollar, not a raw spec sheet. If ingest throughput on the new stack can't match the old at your peak rate, fix it before cutover — adding capacity after go-live under load is exactly when migrations go wrong.
After migration, run a smoke test: trigger an alert, stress-test write throughput, and check query latency on historical data. Pay special attention to time zones and character sets — domestic environments often have a different default locale than the old one, which causes shifted log timestamps or garbled Chinese. Script these checks and add them to the regression list for every upgrade. Keep a rollback window ready: retain the old ES cluster read-only for a week until the new one has proven itself under a full business cycle.