Running the OpenTelemetry Collector on Kylin V10 and Kunpeng

Why the collection layer is so often overlooked in domestic adoption

When teams migrate to domestic hardware and software, the application and the database get all the attention, and the collection layer slips through. But the components that gather logs, metrics and traces must also run on domestic CPUs and operating systems — otherwise the data egress point breaks the sovereignty story, and the very observability data you rely on for compliance leaves the network through a foreign binary.

The OpenTelemetry Collector is written in Go, cross-compiles to ARM64 easily, and ships as a small binary with few dependencies — a good fit for the collection layer in a domestic-computing environment. Because it's a static binary, it sidesteps the shared-library dependency hell that often blocks open-source tooling on Kylin or UOS, where the package repositories are often incomplete.

Obtaining the ARM64 binary

The official releases ship an otelcol_linux_arm64 binary. For production networks without internet access, download and verify it on an internal build machine, then distribute it through your artifact repository or configuration-management tool:

wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v0.100.0/otelcol_0.100.0_linux_arm64.tar.gz
sha256sum otelcol_0.100.0_linux_arm64.tar.gz

After verification, place otelcol under /usr/local/bin/. Keeping the checksum in a manifest means you can re-verify every deployment, which audit teams usually expect for sovereignty-sensitive infrastructure. Record the exact version too, so you can trace which binary is running on which host at any moment.

In air-gapped environments, bundle the binary and its config into your internal artifact repository (Nexus, Harbor, or a domestic equivalent) and pin the version in your CMDB. Resist the temptation to hand-copy binaries between hosts — a checksum-verified, versioned artifact is the only thing an audit will accept as reproducible.

Dependencies and deployment on Kylin V10

Kylin V10 is RPM-based, but many repositories for the ARM edition are incomplete, so installing via the OS package manager often fails for niche tools. The Collector is a static binary and needs almost no extra dependencies, so it runs directly:

chmod +x /usr/local/bin/otelcol
otelcol --config /etc/otelcol/config.yaml

Manage it with systemd so it survives reboots and restarts on crash:

[Unit]
Description=OpenTelemetry Collector
After=network.target

[Service]
ExecStart=/usr/local/bin/otelcol --config /etc/otelcol/config.yaml
Restart=always
RestartSec=5
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Tuning on Kunpeng

The Kunpeng 920 has many cores and a pronounced NUMA topology, so two settings matter:

• Pin CPU affinity: use taskset to bind the Collector to a single NUMA node and cut cross-node memory access, which shows up as higher tail latency under load. A process that hops between nodes pays a penalty on every memory access, and under sustained throughput that penalty compounds.
• Raise limit_mib and queue sizes: a Kunpeng core is slower per-clock than x86, so leave enough memory buffering to avoid dropping data under bursts. When the CPU can't drain the queue fast enough, the buffer is what keeps you from losing samples.

processors:
  memory_limiter:
    limit_mib: 1024
    spike_limit_mib: 256
  batch:
    send_batch_size: 16384
    timeout: 10s

Backing storage on domestic databases

Observe can store metadata and indexes on domestic databases. Because it speaks the MySQL protocol, DM8 (MySQL-compatible mode), OceanBase and TiDB all connect directly:

storage:
  type: mysql
  dsn: "user:pass@tcp(dm8:5236)/observe?charset=utf8mb4"

Swap the database and neither the application nor the collection layer changes a single line. This is what makes migrating from MySQL to a domestic database genuinely low-risk: the wire protocol is unchanged, only the connection string moves. It also means you can stage the migration — run on MySQL first, then point the same configuration at DM8 or OceanBase and re-verify.

Acceptance checklist

Before going live, work through this list:

• The Collector process is healthy and Restart=always works
• All three signals are queryable in the console
• No OOM and no data loss under load testing
• All data stays on the internal network with no outbound connections

Run the load test against the real ingestion path rather than a synthetic one — sovereignty audits care about what actually happens in production, not what a demo shows. Keep the results as evidence for the acceptance review. Also confirm the host OS and CPU are on the approved domestic list (for example Kylin V10 SP2+ and Kunpeng 920) and record their exact versions, since the audit will cross-check the stack against the approved catalog.