← Back to blog
Xinchuang 4 min read 炬鲸团队

JJHub OBSERVE on Domestic Stacks: Full Validation on Loongson, Phytium, Kylin, and UOS

How JJHub OBSERVE was validated end-to-end on Loongson and Phytium CPUs with Kylin and UOS: architecture changes, dependency swaps, benchmark results, and migration advice for domestic IT environments.

Scope and Verdict

JJHub OBSERVE's backend services, collection agents, and console were validated end-to-end on the following combinations:

  • CPUs: Loongson 3A5000/3C5000, Phytium FT-2000+/D2000, Kunpeng 920, Hygon C86
  • OS: Kylin V10 (SP1/SP3), UOS 20, openEuler 22.03

The short version: the core path — log collection, search, alerting, and tracing — runs stably on all of them, and the gap versus x86 is within an acceptable range, as the benchmarks below show.

Architecture and Dependency Changes

The real work in domestic adaptation isn't business logic; it's the dependency layer. What we did:

  1. Storage: ClickHouse has official ARM support, so it works as-is. Where a customer mandates a domestic database, we swap in Dameng DM8 or KingbaseES and adapt the query layer for their SQL dialect.
  2. Message queue: Kafka can be replaced with Apache RocketMQ or Huawei DMQ; agents and backends speak standard protocols, so switching is a config change.
  3. Runtime: where OpenJDK underperforms on Loongson/Phytium, we use Bisheng JDK or a locally built OpenJDK, and tune GC parameters for ARM hugepages.
  4. Images: every artifact ships ARM64 and LoongArch64 images; docker pull picks the right architecture automatically.

The point worth stressing: none of this required touching the collection agents your teams already run. The changes are confined to the backend, so an agent fleet stays exactly as-is when the platform moves to domestic hardware.

Benchmark Results

On a Phytium D2000 (8 cores) with Kylin V10 SP3:

  • Log ingestion: 120,000 lines/sec per node, about 20% below the 150,000 we see on equivalent x86.
  • Search: an aggregate query (WHERE level='ERROR') over 100 million lines averages 1.8s versus 1.2s on x86.
  • Trace processing: 8,000 spans/sec per node — plenty for most small and mid-size workloads.

The takeaway: the single-core gap barely shows in compiled workloads; the real constraint is memory bandwidth. Size RAM at roughly 1.2x your x86 baseline on domestic platforms.

Deployment and Migration Tips

  1. When migrating from x86, move alerting and tracing first (smaller datasets); keep cold logs on the old cluster and avoid a big-bang migration.
  2. Prefer statically compiled agents so target hosts don't run into missing glibc dependencies.
  3. Kylin and UOS firewalls and SELinux policies will block ports — open 4317/4318 and your storage ports before deploying.
  4. Enable transparent_hugepage=always; it gives 10–15% throughput on JVM heaps and database buffers.

Domestic adaptation isn't about "does it run" — it's about whether it runs reliably and who owns the problem when it doesn't. We've open-sourced the adaptation report and benchmark scripts if you want to reproduce the numbers.