How JJWhale OBSERVE was adapted for Phytium and Kunpeng ARM64 platforms running UnionTech UOS and Kylin V10, covering builds, dependency swaps, performance checks, a compatibility checklist, and rollout advice.
The hard part of xinchuang environments is the sheer number of hardware and software combinations, each with its own quirks. We got JJWhale OBSERVE fully running on Phytium and Kunpeng (ARM64) paired with UnionTech UOS and Kylin V10. Here is the record of that effort, for teams facing the same requirement.
JJWhale OBSERVE's storage layer is written in C++, the collection agents in Go, and the frontend is pure static assets. The first task when targeting ARM64 is recompiling every binary and confirming that each third-party library has an official or reliable ARM port. Domestic OS distributions tend to ship older glibc and OpenSSL versions, so build against dependencies matching the target platform rather than cross-compiling on an x86 box and copying the result over — the latter routinely produces mysterious crashes from runtime ABI mismatches.
Always build natively on the target platform to avoid ABI mismatches from cross-compilation:
cmake -DCMAKE_BUILD_TYPE=Release -DTARGET_ARCH=aarch64 ..
make -j$(nproc)For libraries that are missing or too old on domestic OS images, replace them one by one with domestic or self-compiled builds: zstd for compression, and the SM family for cryptography (via OpenSSL's SM extension or GmSSL). After each swap, run the full unit test suite and load tests to confirm no regressions. Record the version and the reason for every replacement, producing a reproducible build manifest that also makes later upgrades and audits easier.
Most of the problems were not about ARM itself but about assumptions baked into x86 code. The recurring ones:
Each of these was caught by unit tests rather than in production, which is the main reason we insist on running the full suite after every dependency swap.
Load testing on a 64-core Kunpeng 920 sustained several hundred thousand log lines per second per node, with query latency on par with x86. CPU usage and memory curves stayed flat, which tells you the ARM port didn't cut corners. The key areas to verify are write amplification under multi-core concurrency and index build time, since these are the two places ARM ports most often regress. Also run the same query over identical datasets on x86 and ARM and compare results, so you confirm the port is not just "runnable" but actually correct.
Before going live, verify the following:
Run this checklist against your exact hardware and OS build, not just the family name — a Phytium D2000 and a Kunpeng 920 behave differently under load, and "UOS V20" spans several patch levels with meaningful differences. Treat each combination as its own supported platform.
Don't migrate to xinchuang all at once. Pick a low-risk business as a pilot, run the full ingest-store-query path end to end, then switch over the rest. Keep old and new environments running in parallel during migration, use dual-write to compare data consistency, and retire the old environment only once things have been stable for a while. Finally, have someone on the team track the domestic OS patch cadence over the long term — domestic distributions change more frequently and with more compatibility shifts than mainstream ones, and staying ahead of those changes saves a lot of pain.