How we got Torchwhale OBSERVE running on Kunpeng 920 + Kylin V10 + Dameng DM8: DM8 metadata configuration, aarch64 agent adaptation, kernel tuning, acceptance criteria, and the pitfalls we hit.
Running on a Xinchuang stack is more than swapping the CPU — storage, drivers, and kernel parameters all need attention. This article records what we did, and the pitfalls we hit, while getting Torchwhale OBSERVE running on Kunpeng 920 + Kylin V10 + Dameng DM8.
Every component ships an aarch64 package, so no cross-compilation is required. Before migrating, pin down the patch versions of both Dameng and Kylin — a few minor releases carry JDBC compatibility differences — and prefer the vendor's recommended stable release. If you keep Tomcat instead of moving to TongWeb, the platform works either way; TongWeb is only required when policy mandates it.
After installing Dameng, create a dedicated instance for the platform and set two parameters that matter in practice:
ALTER SYSTEM SET 'COMPATIBLE_MODE'=4; -- MySQL-compatible syntax
ALTER SYSTEM SET 'ENABLE_BLOB_CMP'=0;Use the DmJdbcDriver18 driver and add ?compatibleMode=mysql to the connection string. A working connection URL looks like this:
jdbc:dm://192.168.1.10:5236/OBSERVE?compatibleMode=mysqlCOMPATIBLE_MODE=4 is the setting that matters most for a schema that came from MySQL; without it, even basic statements like LIMIT and AUTO_INCREMENT behave differently and migrations fail in confusing ways. If you are migrating existing data, stop writes first and move it with logical export/import rather than raw files, which avoids binary format incompatibilities. After migration, sample and compare a few fields to confirm large blobs and Chinese text survived without corruption. Dameng ships its own logical export/import tools (dexp and dimp); use them rather than piping MySQL dumps straight in, because type mappings differ in non-obvious ways.
Both the log agent and the Collector need their aarch64 builds. On Kylin, file collection hits two OS limits worth fixing up front: the default file-handle limit is small, so raise nofile to 65535 in /etc/security/limits.conf; and the inotify watch limit in /proc/sys/fs/inotify/max_user_watches should go to 1048576, otherwise heavy log volume leads to missed files. Verify both with ulimit -n and cat /proc/sys/fs/inotify/max_user_watches after the change, because limits.conf only affects newly started processes — long-running agents keep their old limits until they restart. Confirm you actually have aarch64 binaries with file <binary>; an x86 build runs under emulation and appears to work until it hits the first heavy load, which can waste hours.
In order of frequency, the failures we actually saw were: file handles — the default nofile of 1024 is nowhere near enough for a busy log agent; inotify watch overflow, which drops files silently rather than erroring, so you only notice when searches come back empty; a JDBC version mismatch between the Dameng driver and the DM8 patch release, which surfaces as obscure errors on blob columns; and forgetting that limits.conf does not apply to already-running processes.
During load testing, watch Dameng's buffer pool and session count. Raise MEMORY_POOL and reserve enough MAX_SESSIONS for your connection count. On Kunpeng hosts, aarch64 builds sometimes differ in default heap sizes, so set the JVM heap explicitly for the platform services rather than relying on defaults. Acceptance criteria we use: 100,000 log lines per minute with no loss, search P95 under 3 seconds, and alert latency under 30 seconds. Run the acceptance test for at least an hour of sustained traffic, not a five-minute burst — the failures that matter tend to show up only after the system has been running for a while. Also load-test with a workload that mirrors production: a synthetic log generator will miss the large, slow-rotating files and bursty traffic that cause most of the inotify and file-handle problems.
The short version: in a Xinchuang migration, first make the minimal loop work end to end — collection → ingest → search → alert — before you think about scale.