A full deployment walkthrough for OBSERVE on ARM-based domestic infrastructure — Kylin/UOS OS, DM8 database, and Phytium/Kunpeng CPUs — with a compatibility checklist and real gotchas.
Deploying observability on a domestic stack is not a matter of recompiling for a different OS. The whole environment changes at once: a Phytium or Kunpeng CPU means ARM, Kylin or UOS means a different package manager and security model, and DM8 or KingbaseES means SQL dialects and JDBC drivers that are not drop-in replacements for MySQL or PostgreSQL. A package that was "built for Linux" on x86 will not run on this hardware at all, and a database layer written only for MySQL will fail at the first connection. OBSERVE ships separate, tested builds for this stack rather than asking customers to figure out the gaps themselves.
In practice the adaptation work breaks into four pieces: native ARM binaries for both CPU vendors, packaging that respects Kylin and UOS's package managers and signing requirements, JDBC drivers and SQL compatibility for DM8 and KingbaseES, and regression tests that run the full stack on real hardware rather than emulation. Emulation is not enough — an ARM build tested only under qemu will miss the issues that show up on physical Phytium and Kunpeng boards.
OBSERVE has completed adaptation for the mainstream domestic software and hardware stack. The combinations verified in testing include:
Installation packages are published separately for x86 and ARM. Check your architecture first with uname -m — aarch64 means ARM. A package built for the wrong architecture fails immediately with an illegal-instruction error at startup, so this is the first easy mistake to avoid. If you are migrating an existing deployment from x86 to ARM, treat it as a fresh install followed by a data migration rather than an in-place upgrade, because the two architectures don't share a package or a data-format guarantee.
Install dependencies before deploying. On Kylin V10, for example:
# stop firewalld or allow ports 8080/9090/4317/4318
systemctl stop firewalld
# confirm glibc >= 2.28
ldd --version
# initialize the DM instance and create a database
dm_ini --initIn the database connection string, switch the driver to DM's JDBC driver DmJdbcDriver18 — do not keep the MySQL driver class name, or the connection pool fails on initialization with an error that is easy to misread as a missing jar. Also remember that DM's default port is 5236, not 3306, and that the database must be initialized and the schema created before the installer runs, because the installer will not create the database for you. A quick sanity check before running the installer: confirm the JDBC driver jar is present in the package and that java -version reports the OpenJDK 17 build you intend to use, not a leftover system JDK 8.
/opt/observe and edit the database connection and storage paths in config.yaml.scripts/install.sh to initialize; the script creates tables and seeds initial data automatically.systemctl start observe and watch the logs with journalctl -u observe -f, confirming there are no driver-related errors.Three issues we hit in practice: first, a wrong port in the DM connection string causes endless timeouts that look like a network problem, so check the port before you check the network; second, some older JDK 8 builds have compatibility issues on ARM, so standardize on OpenJDK 17; third, Kylin's security mechanisms occasionally block the listening port, requiring setenforce 0 or an explicit policy.
The migration is transparent to the business: the collection side stays unchanged, and only the backend storage and runtime are replaced. For air-gapped intranet environments, the ARM offline package bundles its dependencies and installs everything in one command, so you don't have to download each dependency over the network. That offline package is what most government and financial customers use, since their environments have no outbound internet access at all. For teams coming from x86, budget an extra day for the first deployment: setting up DM and Kylin from scratch takes longer than the OBSERVE install itself.