Deploying JJH OBSERVE on Kylin + Kunpeng

Environment and Dependencies

This deployment is validated on Kylin Advanced Server V10 (ARM64) with Kunpeng 920 processors. Before you start, lock down the basics:

• Architecture: aarch64, 8 cores minimum; production recommends 32 cores + 64G RAM, with local NVMe SSD for the log hot tier
• OS: Kylin V10 SP2 or later, kernel 4.19+ — earlier SPs ship an older glibc that breaks some components
• Storage: local SSD for recent logs; attach object storage (MinIO, or a domestic S3-compatible service) for cold/hot tiering
• Runtime: the openEuler-family container runtime bundled with Kylin, or Docker 19.03+

All images ship arm64 builds, so there's no self-compilation. Run uname -m first and confirm aarch64 — pulling an x86 image on ARM is the single most common first-install mistake, and it fails in confusing ways.

Installation Steps

Air-gapped environments are the norm in Xinchuang intranets, so assume no outbound network. Three steps:

1. Copy the package and images to the target:

tar -xzf jjhub-observe-arm64.tar.gz
cd jjhub-observe-arm64
docker load -i images/jjhub-observe-arm64.tar

1. Edit config to set the data directory and ports:

# config.yaml
storage:
  data_dir: /data/jjhub
  retention_days: 30
server:
  http_port: 8080
  grpc_port: 4317

1. Start and initialize:

./install.sh --config config.yaml

install.sh self-checks architecture, disk space, and port conflicts, and exits with a clear error if anything is missing. After init, open http://<ip>:8080, log in with the default account, and change the password (forced on first login).

For a multi-node setup, run install.sh on each node with the same config and designate one node as the coordinator by setting role: coordinator — the script handles the rest.

Common Pitfalls and Debugging

Four issues come up more than anything else in real Xinchuang deployments:

1. glibc too old. Early Kylin V10 ships glibc 2.28, but some components need 2.31+. Upgrade to SP2 or apply the vendor patch before installing; the installer checks and refuses rather than failing silently later.
2. Missing tzdata on arm64. Some base images don't bundle tzdata, so the container errors and log timestamps drift by eight hours. Install tzdata in the image and mount /etc/localtime read-only.
3. NUMA on Kunpeng. The Kunpeng memory topology is more complex than x86; default binding can cross NUMA nodes and tank aggregation latency. Use numactl to pin CPU and memory to the same node for the query and storage services.
4. Domestic database compatibility. If you're using DM (达梦) or KingbaseES (人大金仓) for metadata storage, drop the vendor JDBC driver into the lib directory and use the vendor-specific connection string — it's not MySQL syntax.

Upgrades and Day-2 Operations

Once it's running, plan for the long term. Upgrades follow the same air-gapped pattern: load the new image, then run the in-place upgrade script, which backs up config and metadata and rolls the services one at a time so ingestion never stops. Keep at least two generations of the image tarball on disk before upgrading, in case you need to roll back offline.

Monitor the node with the same tools you use for the rest of the fleet. The two counters that matter most are disk IO wait on the storage directory and the ingest lag metric. If ingest lag starts climbing, check NUMA pinning first — cross-node memory access is the usual culprit on Kunpeng, not CPU headroom.

For backups, snapshot the metadata store daily and copy the config file to a second location. Log data itself usually doesn't need backing up since it's reproducible from source systems, but metadata and alert rules are not — losing them means rebuilding dashboards and alerts by hand.

Performance

On a single 32-core Kunpeng 920 with 64G RAM:

• Log ingest throughput: about 120K lines/sec at 200 bytes per line
• Single SQL aggregation over 1 billion logs: under 3 seconds
• Trace sampling and storage: 10K spans/sec with headroom

That comfortably covers most provincial-government and mid-size financial workloads. If you outgrow it, shard by region or business unit and put a unified query layer in front — the platform supports it without a schema change.

One caveat worth stating plainly: these numbers assume local NVMe and correct NUMA pinning. On spinning disks or with cross-node memory access, expect roughly a third of the throughput, which is still fine for smaller sites but worth planning around.