Xinchuang isn't just 'does it run'—you must adapt across CPU architecture, domestic OS, database, and middleware. This post gives a complete deployment checklist for OBSERVE on an ARM64 domestic stack, with field-tested notes.
Many people reduce Xinchuang (domestic substitution) to recompiling from x86 to ARM64, but adaptation actually spans four layers: CPU architecture (Phytium and Kunpeng are both ARM64), operating system (Kylin, UOS), database (DM, KingbaseES, GaussDB, OceanBase), and middleware (TongWeb, BES). Incompatibility at any layer stalls the deployment. OBSERVE ships ARM64 builds for its collector, storage engine, and web console, with drivers adapted for mainstream domestic databases. Plan the matrix early and write it down—CPU × OS × database × middleware, with the exact versions you'll ship against. Vendors pass or fail acceptance on that matrix, and the last thing you want is discovering at UAT that your KingbaseES patch level isn't in the support list. Let's walk the checklist in order.
Recommended layout: three control-plane nodes, with the data plane scaled by log volume. Minimum per node is 8 cores / 32GB; production should start at 16 cores / 64GB with NVMe SSDs for data. Supported operating systems are Kylin V10 (SP1/SP2/SP3) and UOS 20 or later, all ARM64 kernels. Confirm architecture and version before you start:
uname -m # expect: aarch64
cat /etc/os-release # confirm Kylin or UOS versionIf you see x86_64, an x86 system image was installed—you need to reinstall the ARM64 image. This is the single most common blocker. On the storage side, the columnar engine is I/O-bound rather than CPU-bound, so prioritize NVMe over core count on data nodes. Phytium FT-2000+/D2000 and Kunpeng 920 both run the stack fine; the practical difference is kernel tuning—set the I/O scheduler to mq-deadline and raise vm.max_map_count to 262144 on data nodes before loading data. RAM sizing follows the same rule as x86: roughly 1GB per 10k lines/sec of sustained ingest, plus 30% headroom for compaction.
OBSERVE's metadata (users, alert rules, dashboards) supports DM8, KingbaseES V8, and GaussDB; just swap the JDBC driver and connection string in the config:
# 达梦 DM8 示例
jj.db.type=dm
jj.db.url=jdbc:dm://10.0.0.11:5236/OBSERVE
jj.db.username=observe
jj.db.password=******The primary store for logs and metrics doesn't rely on a traditional relational database—it uses an in-house columnar engine—so the database choice only affects the control plane, not collection or query performance. For high availability, configure the domestic database's own replication (DM's DataWatch, KingbaseES's RAC-like mode) rather than relying on the application layer, and keep the OBSERVE JDBC connection string pointed at the primary. On the middleware side, if you must run the web console behind TongWeb TAS, declare the port and context path explicitly in the config to avoid conflicts with the built-in proxy.
Air-gapped environments (common in Xinchuang intranets) install from packages: push the images and RPMs into a private registry, then run the installer. install.sh self-checks architecture and kernel parameters (file handle limits, memory mapping) and prints a report—fix anything flagged before proceeding. Plan storage up front: a common sizing rule is to reserve daily log volume × retention days × 1.3 for the data plane, and keep at least 20% of each data disk free to avoid compaction stalls. After installing, verify in order:
# 1. Processes and ports
systemctl status jj-observe
ss -lntp | grep -E '8080|4317|9090'
# 2. Push a test log and confirm it is queryable
curl -X POST http://localhost:4318/v1/logs -d @sample.json
# 3. Timezone and NTP (affects time-series and alerts)
timedatectl
chronyc trackingThree things tend to fail acceptance testing. First, Kylin V10 enables an SELinux-like mechanism by default—disable it or open the ports per the install guide, or the Collector can't connect. Second, some older JDK builds misallocate off-heap memory on ARM64; standardize Java collectors on the OpenJDK 17 ARM64 build. Third, domestic databases ship with low default connection-pool limits, which saturate when many alert rules run concurrently—raise the pool above 100 after deployment. Fourth, air-gapped machines often lack a working package repo, so dependencies resolved online during a trial install fail in production—bundle the offline repo (RPMs plus transitive dependencies) into the install package and test yum localinstall on a clean image before cutover. Xinchuang acceptance usually checks "stable operation + key features working + proof of domestic database adaptation"; walk the checklist once and you'll pass on the first try.