Deploying JJHub Observe on the Domestic Stack: Kylin, Phytium, and Dameng

The scariest part of a Xinchuang (domestic-stack) migration is not whether the app will start, but whether it will stay stable once it does. We've deployed JJHub Observe end to end — collection, storage, and console — on domestic hardware and OSes at several government and financial sites, and hit our share of problems. This article distills what's reusable.

Target Environment

• CPU: Phytium FT-2000+ / Kunpeng 920 (both ARMv8)
• OS: Kylin V10 SP2 (server edition)
• Database: Dameng DM8
• Middleware: Kingdee Apusic AS / TongWeb (optional)

Give the console and storage nodes at least 8 cores / 32 GB. The Collector can run on 2 cores / 4 GB; under load a single instance handles roughly 30,000 log writes per second. Storage is the real bottleneck — if you plan to retain more than 30 days of hot data, size storage nodes to 16C/64G and use NVMe rather than SATA SSD.

ARM Images and Kernel Tuning

The official registry ships linux/arm64 images. Specify the platform when pulling:

docker pull --platform linux/arm64 hub.jjhub.cn/observe/observe-server:2.6.0
docker pull --platform linux/arm64 hub.jjhub.cn/observe/observe-collector:2.6.0

If the site has no internet access, use the offline bundle observe-offline-2.6.0-arm64.tar.gz and run docker load -i — no recompilation needed.

One real pitfall: Kylin V10 defaults vm.max_map_count to 65530, which is too low for storage components like Elasticsearch/ClickHouse; they OOM or refuse to start. Set it before deploying, and raise a couple of related limits at the same time:

sysctl -w vm.max_map_count=262144
echo "vm.max_map_count=262144" >> /etc/sysctl.conf
echo "net.core.somaxconn=32768" >> /etc/sysctl.conf
echo "fs.file-max=1048576" >> /etc/sysctl.conf

Also raise the file-descriptor limit for the container runtime (ulimit -n 65535), or the Collector will run out of descriptors under heavy log ingest and drop connections silently. Silent dropping is the worst kind of failure — it looks like a data gap, not a crash.

Adapting to Dameng DM8

JJHub Observe stores metadata (users, projects, alert rules, audit logs) in MySQL by default; switch to Dameng DM8 for domestic environments. The console exposes a config option — no code changes:

storage:
  metadata:
    driver: dm8
    host: 10.0.0.20
    port: 5236
    username: OBSERVE
    password: "***"
    schema: OBSERVE

The heavy detail — trace attributes and raw log text — goes through the columnar storage layer, not Dameng, so DM never gets buried under high-volume data. Set DM8's compatibility mode at init time — COMPATIBLE_MODE=4 (Oracle-compatible syntax) or the MySQL-compatible mode per the official docs; changing it later means rebuilding the database. If you're migrating an existing MySQL metadata store, use the built-in export/import tool rather than hand-copying tables: DM data types differ (for example TEXT vs CLOB), and a manual copy will corrupt encodings on Chinese text.

Domestic Middleware and Security Baselines

To deploy the console on domestic middleware, upgrade web.xml in the WAR to a Servlet 4.0 declaration — both Apusic AS and TongWeb accept it. Some domestic middleware default to strict cookie flags that can break the console's WebSocket; enable the websocket module and allow origin matching. Common security-baseline items from security assessment (password complexity, login-failure lockout, operation auditing) can be toggled on under "System Settings → Security Policy", so you don't re-implement them at the application layer.

Post-Migration Smoke-Test Checklist

1. Ingest 10,000 log lines and confirm search latency stays under 2 seconds
2. Trigger one alert and confirm the WeCom/SMS channel delivers it
3. Run a full-path load test and keep Phytium CPU under 70%
4. Use Dameng's disql to verify metadata tables read and write correctly
5. Verify NTP time sync across nodes — tracing is useless if clocks drift, and ARM boards in air-gapped rooms are prone to clock skew

The payoff of a Xinchuang migration is more than "compliance" — domestic-stack procurement and maintenance cost less over the long run. The key is not to treat migration as a one-off project: think through the day-to-day (upgrades, backups, scaling) before you call it done.

A final operational point: after cutover, run the platform on the domestic stack for at least one full business cycle (a month, ideally a quarter-end for financial clients) before decommissioning the old stack. Most incompatibilities don't show up in the first smoke test; they surface under sustained load, during batch windows, or when a specific Dameng maintenance job runs. Keeping the old environment warm for one cycle gives you a rollback path that costs almost nothing.