Deploy JJHub OBSERVE on domestic CPUs and operating systems: supported Kunpeng, Phytium, Hygon, and Loongson platforms, offline image migration, initialization with Dameng or KingbaseES, and resource planning for weaker single-core performance.
JJHub OBSERVE has been adapted and verified against mainstream domestic hardware and software stacks, including:
The server ships as container images. Core components built in Go and C++ are compiled separately for each architecture above, with no x86 emulation layer, so performance loss is negligible. The control console runs on standard Java, which is why TongWeb and Baolande BES appear in the middleware list—both are certified drop-in replacements for the console's servlet container.
Deployment is largely the same as on x86. Confirm three things first:
Domestic intranets are often offline, so use docker save / docker load for offline image migration:
# On an internet-connected machine
docker save jjhub/observe:2.5.0-arm64 | gzip > observe-2.5.0-arm64.tar.gz
# On the intranet
docker load -i observe-2.5.0-arm64.tar.gzAlways match the image tag to the target architecture (arm64 for Kunpeng/Phytium, loongarch64 for Loongson, amd64 for Hygon). Loading a mismatched image fails at docker run with an "exec format error".
After importing, run the official deployment script, which auto-detects the architecture and picks the right image:
./deploy.sh install --arch autoDuring initialization, choose Dameng or KingbaseES as the metadata database; the script creates the database account and schema for you. Connection string example:
jdbc:dm://<dm-host>:5236/OBSERVEOn Kylin V10 with mandatory access control (security labels) enabled, disable or whitelist OBSERVE processes before installing, or the service may fail to bind ports. This is the single most common install-time issue we see, and it shows up as a silent failure to listen rather than a clear error.
If you already run Dameng or KingbaseES, point OBSERVE at the existing instance rather than deploying a new one—just create a dedicated schema and account. Both databases support online backup, but test a restore before go-live; a backup you haven't restored is a hope, not a backup. On the middleware side, TongWeb and BES need a JDK 8 or 11 runtime and a servlet version of 3.1 or higher for the console to deploy cleanly. Keep the middleware logs handy—they're the first place to look if the console fails to start after a Kylin security patch.
Two recurring issues are worth knowing about before you hit them. The first is the exec format error covered above—almost always a wrong image tag for the architecture. The second is time sync: OBSERVE indexes by timestamp, so if the Kylin hosts' clocks drift, queries and alert windows will be off. Run NTP or chrony on every node and check for clock skew as part of the pre-flight. If ingest looks slow after installation, verify the data disk is actually NVMe and not a misconfigured storage tier—this single misconfiguration accounts for more "slow database" reports than any CPU bottleneck.
Domestic CPUs generally have weaker single-core performance than mainstream x86, so leave headroom when planning resources. For 100 million log lines per day:
In our benchmark, a 16-core Kunpeng node sustained roughly 70–80% of the ingest throughput of a comparable x86 node, and query latency was within 1.3×. Plan capacity with that ratio in mind. Before going live, run the built-in load test for write and query baselines, and tune query timeout thresholds to match domestic CPU performance instead of copying x86 defaults.
Before production, verify item by item: Dameng/KingbaseES backup and restore, Kylin security patch updates not disrupting the service, a clean console deployment on TongWeb, and data integrity under power and network failures. Once these pass, you can submit the adaptation report required for domestic-technology project acceptance.