Running OBSERVE on Kylin and Phytium: Notes from a Domestic-Stack Deployment

Environment prep

The target environment for this deployment: Kylin V10 SP3 (arm64), Phytium FT-2000+/64 processors, and Dameng DM8 as the database, with OBSERVE running in containers. Confirm three things up front: the kernel supports your container runtime, storage IO can keep up with time-series writes, and time sync is healthy. Domestic stacks often run their own NTP or time server — align clocks first, or timestamps across logs and metrics will be skewed.

ARM dependency compatibility

Phytium is an ARM platform, so pull images with an arm64 tag, not the default amd64. Prefer arm64 base images published by Kylin or Dameng themselves; plenty of things run fine on x86 and break on ARM. Before deploying, run a dependency self-check on the target host:

uname -m            # confirm aarch64
ldd --version       # glibc version
cat /etc/os-release # OS release

If glibc is older than OBSERVE requires, either upgrade the OS or fall back to an older, compatible runtime. Most failures in domestic environments come down to mismatched library versions — listing dependencies up front and checking them one by one saves a lot of rework.

Dameng database adaptation

The metadata and config database moves from MySQL to Dameng DM8. The two things that matter are the driver and the connection string: use Dameng's official DmJdbcDriver, with a jdbc:dm://host:5236 URL. Dameng's SQL compatibility is decent, but expect to change a few things — auto-increment primary keys use IDENTITY, pagination syntax differs from MySQL, and some function names diverge. Run the full DDL against Dameng once and confirm it succeeds before switching over.

# database connection example
database:
  driver: dm.jdbc.driver.DmDriver
  url: jdbc:dm://10.0.0.12:5236
  username: observe
  password: change-me

Performance and migration

In our tests, 64 Phytium cores stay close to a comparable x86 at moderate write volume, though single-core peak is a bit lower — drop the concurrency one notch under load testing. When migrating from x86, don't expect to copy data files directly; formats and byte order differ, so use logical migration (export, then import). Before going live, run a full-chain load test and check whether write and query latency hold up at peak, then shift traffic over gradually.