Deploying 炬鲸 on Kylin/UOS with DM and KingbaseES: A Field Guide

Compatibility matrix

The short version first: 炬鲸 OBSERVE has completed adaptation for the mainstream domestic hardware and software stack, and runs stably in production on the following combinations:

| Layer | Supported domestic products |
| --- | --- |
| CPU | Kunpeng 920, Phytium 2000/2500, Hygon C86 3xxx |
| OS | Kylin V10 (SP1/SP2/SP3), UOS 20/1050 |
| Database | DM8, KingbaseES V8, openGauss 3.x |
| Middleware | TongWeb, BES |

Deployment comes in two forms: an appliance (pre-installed, plug and play) and a software package you install into an existing domestic environment. This guide covers the software package, which is what most customers actually need.

Prerequisites and dependencies

On Kylin V10 (ARM64), install the runtime dependencies first. Note that domestic OS repos often carry older package versions, so prefer the system-provided ones and avoid pulling incompatible glibc from external repos:

# Kylin V10 SP3
yum install -y java-11-openjdk-devel libaio nss-softokn-freebl

炬鲸 requires JDK 11 or newer. On domestic CPUs, make absolutely sure you install the ARM64 build — uname -m should return aarch64. Database JDBC drivers go under lib/ in the install directory; download the driver matching your database version from the DM or KingbaseES site rather than using old artifacts from Maven Central, which trip over dialect differences.

Database initialization

For DM8, initialize an instance and create the database. Key parameters: 32K page size, UTF-8 charset, and case sensitivity per your convention (炬鲸 defaults to case-insensitive). Then create the application account:

CREATE USER jjhub IDENTIFIED BY "JjHub@2024";
GRANT DBA TO jjhub;

For KingbaseES the equivalent is CREATE USER plus GRANT, and you should confirm the compatibility mode. 炬鲸 recommends ORACLE compatibility mode under KingbaseES, which reuses more SQL syntax.

Configuration and startup

After extracting the package, edit the datasource in conf/application.yml:

datasource:
  driver: dm.jdbc.driver.DmDriver
  url: jdbc:dm://127.0.0.1:5236/JJHUB
  username: jjhub
  password: JjHub@2024

Start in init mode first so the program creates tables and seeds initial data:

./bin/start.sh --init

Then restart in normal mode. Table DDL has dialect differences across domestic databases; 炬鲸 ships a dialect adapter layer, so you shouldn't need to hand-edit SQL. If table creation fails, check that the driver version matches the database major version first.

Verification and common problems

After startup, verify in order: process is alive → ports listening (8080/4317/4318 by default) → console login → write one test log and search for it.

The three most frequent issues in the field:

1. Driver load failure — ClassNotFoundException: dm.jdbc.driver.DmDriver. Nine times out of ten the driver jar is in the wrong directory, or multiple driver versions conflict under lib/. Delete the old ones and keep a single version.
2. Charset errors during table creation — DM with the default 8K page size rejects some wide fields with a "record too long" error. Rebuild the instance with 32K page size.
3. x86 JDK installed on an ARM host — check file $(which java); an x86 build on aarch64 crashes at startup with SIGSEGV in the logs.

Middleware and performance notes

If you deploy behind TongWeb or BES instead of the embedded server, deploy the bundled war and give the JVM at least 4 GB of heap, passing -Dfile.encoding=UTF-8. On Kunpeng/Phytium hosts, enable the vendor's NUMA tuning and pin the database and the 炬鲸 process to the same socket where possible — cross-socket traffic measurably slows bulk log ingestion.

For storage, keep hot indices on local NVMe and offload cold data to object storage; domestic hardware tends to have fewer fast disks, so the hot/cold split matters more than it does on typical x86 deployments. One more thing: domestic environments are often air-gapped, so installation and upgrades rely on offline packages. 炬鲸 ships a full offline bundle (dependencies and drivers included). Run upgrades offline too, to avoid a mid-upgrade failure from an unreachable external repo.

Finally, keep a written record of driver and database patch versions in your runbook. Domestic database patches occasionally change JDBC behavior between minor releases, and a version log is the fastest way to spot that a recent patch broke something.