Deploying Observability on Kylin OS and DM Database: A Field Guide

Why domestic-stack adaptation is its own project

The hard part of a domestic-stack (xinchuang) environment isn't the application — it's the foundation. The OS switches from CentOS to Kylin (or UOS), the CPU from x86 to ARM or Loongson, the database from MySQL to DM or KingbaseES, and sometimes the middleware too. An observability system has to touch the underlying layer to collect logs, metrics, and traces, so these differences show up directly in installation, drivers, and performance. A binary that 'just works' on x86 CentOS will not necessarily even start on an ARM Kylin box.

This post walks through a reproducible deployment on Kylin V10 (ARM) with DM8, and flags the spots where people typically lose a day or two.

CPU and OS architecture adaptation

Confirm the architecture first — using the wrong package is the most common mistake:

uname -m        # prints aarch64 or x86_64
cat /etc/os-release

Kylin V10 ships a Server edition and a Desktop edition; production must use the Server edition. The Desktop edition pulls in a graphical stack you don't want on a server and is patched on a different schedule. On ARM, the Collector and every exporter need aarch64 binaries. Download the matching builds from the official release pages — don't run x86 packages through translation layers, performance drops by an order of magnitude and you'll chase mysterious slowness forever. Run a dependency check before installing:

ldd ./otelcol-contrib

Any library reported as not found (usually libsystemd or a glibc version gap) must be installed from the Kylin repository, otherwise the binary downloads fine but won't start. Sort out the dependencies before the firewall, repo mirror, and approval processes slow you down — you don't want to discover a missing library at 2am.

Swapping in the DM database driver

If platform metadata lands in DM, the driver is the biggest chunk of work. DM provides the JDBC driver DmJdbcDriver18.jar. Three things to do:

1. Drop the driver into the application's lib directory, replacing the default MySQL/PostgreSQL driver.
2. Change the connection string to DM format: jdbc:dm://host:5236?schema=SYSDBA — note the default port is 5236 and the schema name is case-sensitive.
3. Rewrite DDL: MySQL's ENGINE=InnoDB and AUTO_INCREMENT become DM's IDENTITY and default tablespace.

DM can run in MySQL compatibility mode (COMPATIBLE_MODE), which saves some rewriting, but don't expect it to be painless — index and pagination syntax still need verification one by one. A practical approach is to run the application's test suite against DM and triage every SQL failure individually; most turn out to be three or four recurring patterns rather than dozens of unique problems. KingbaseES follows the same pattern: swap the driver and the SQL dialect.

Tuning collection and storage performance

Domestic hardware usually has lower single-core performance than same-generation x86, so keep collection resource usage in check. Enable the batch and memory_limiter processors on the Collector:

processors:
  batch:
    timeout: 5s
    send_batch_size: 1000
  memory_limiter:
    check_interval: 1s
    limit_mib: 512

memory_limiter is the important one: it caps the Collector's memory so a burst of telemetry can't take the box down. batch reduces the number of write requests. If storage runs on local disks, Kylin's default I/O scheduler is unfriendly to SSDs — switch to none or mq-deadline. Mount the DM tablespace on a separate disk from the system partition so log writes and queries don't fight over I/O. On slower ARM storage, this single change often matters more than any application-level tuning.

Summary and a pitfall checklist

The Kylin + DM path works, but budget extra adaptation time rather than scheduling it with x86 estimates. The checklist: use the right ARM binaries, remember DM schema case sensitivity, don't treat compatibility mode as zero rewriting, tune the SSD scheduler, and mount the tablespace separately. Most of these only cost a few minutes when caught early — and hours when caught during a 2am incident.

One final note: many teams treat the driver swap as a one-time task, but it's worth re-verifying after every platform upgrade. DM minor releases occasionally change reserved words or default behaviors, and a driver that works on DM8.0.2 may behave differently on DM8.1. Pin the database version in your deployment notes and re-run the smoke tests when it changes.