In domestic replacement environments, both the collector and the backend must run on Phytium/Kunpeng chips with Kylin/UOS. Covers ARM64 image builds, glibc and dependency gaps, fd and performance tuning, and domestic browser compatibility.
Domestic IT replacement is not just about swapping the database — the chip and the operating system are an even more fundamental layer. The collector and backend must run on Phytium (ARM64) and Kunpeng (ARM64) chips, on Kylin and UOS systems, which is not the same as running on x86 plus CentOS. This article records how we moved the entire Jujing OBSERVE stack onto domestic chips and OSes, and the traps along the way.
The first step is producing ARM64 images. Both the backend and collector images must be rebuilt for arm64; you cannot reuse the x86 binaries. We standardized on multi-arch builds:
docker buildx build --platform linux/amd64,linux/arm64 -t ob-collector:v3.6.0 --push .The build-chain pitfalls outnumber what you'd expect. Some third-party libraries have no prebuilt arm64 package and must be compiled from source; others rely on hand-written assembly optimizations that target x86 only, so they work on arm64 but lose performance and must be evaluated one by one for replacement. We maintain a dependency list that separates libraries with official arm64 support from those without — the latter either get swapped for alternatives or we maintain our own build scripts.
Kylin and UOS are both Linux-based, but glibc versions, library paths, and system layouts differ from mainstream x86 distros. glibc causes the most trouble: a binary built in a newer build environment fails on a customer's older Kylin with a "version not found" error because symbols like GLIBC_2.34 don't exist there.
The fix is to lock a lower glibc baseline at build time — compile inside a container matching the target system, or statically link the critical dependencies. Also go through the dynamically linked dependencies with ldd one by one and fill whatever is missing. Don't assume "it's all Linux, so it should run."
Package management differs too. Kylin is rpm-based and UOS is deb-based (its V20 line), so the installation path — systemd units, log directories, config file locations — has to account for both. We keep two packaging targets and one shared config format, so the same collector config deploys unchanged on either OS; only the package and the unit-file path differ.
After it runs, performance is the next fight. ARM64 servers have weaker single-core performance than same-generation x86 but far more cores, so concurrency-bound collection and search tasks must size their threads to core count instead of copying x86 settings. We hit one trap here: the collector used a fixed 8 workers on x86, and on Kunpeng it opened too many file descriptors, tripping Kylin's default ulimit and halting collection entirely.
Two adjustments: compute worker count dynamically from CPU cores, and raise the open-files limit while periodically watching fd growth so leaks get caught early. On performance we did a comparison run: the same collection load on a Phytium S2500 reached about 70% of x86 throughput after tuning — good enough, and the key was matching concurrency to core count.
The console frontend also runs on domestic terminals, where the browser is often Qi'anxin Browser, 360 Safe Browser, or UOS's browser with an older engine. The frontend must avoid overly new JavaScript syntax and APIs, choose chart libraries with good compatibility, and regression-test critical paths like login and export on domestic browsers. We keep a "must-support browser list" and run through it before every release, so we don't discover a white screen at the customer site.
ldd confirms no missing dependencies.Adapting to domestic chips and OSes has no shortcut, but the pitfalls are fixed: architecture, glibc, package format, file descriptors, performance, browsers. Step on each once and turn it into a checklist; the next project saves most of the time by following it.