A hands-on guide to deploying OBSERVE on UOS and Phytium ARM64: installing dependencies, registering the systemd service, adapting to domestic databases and certificates, and fixing common issues like startup crashes and garbled Chinese.
The hard parts of a domestic environment aren’t in application code — they’re underneath it. UOS’s glibc version, ARM64 instruction compatibility on Phytium chips, and differences in systemd units can all stop a program that runs perfectly on x86. This doc follows a real deployment order, so you can look things up as you hit them instead of guessing.
Confirm three things first:
uname -m # should print aarch64
cat /etc/os-release # confirm the UOS version
ldd --version # confirm the glibc versionOBSERVE ships ARM64 packages. Install the runtime dependencies before the package itself:
sudo apt install -y libc6 libssl3 liblz4-1 ca-certificates tzdataFT-2000/64 and D2000 both implement ARMv8. If you’re on the older FT-1500A, confirm the compiler target separately — don’t just force the aarch64 package onto it and hope. The CPU instruction set differences between FT generations are exactly the kind of thing that produces mysterious illegal instruction crashes at runtime.
Unpack the package to /opt/observe, then register OBSERVE as a systemd service:
[Unit]
Description=JuJing OBSERVE
After=network.target
[Service]
Type=simple
User=observe
ExecStart=/opt/observe/bin/observe-server --config /etc/observe/config.yaml
Restart=on-failure
RestartSec=5s
LimitNOFILE=65535
[Install]
WantedBy=multi-user.targetThree easy-to-miss points. First, LimitNOFILE must be raised — a log-collection service hits the default 1024 file-descriptor limit within minutes under real traffic. Second, don’t run as root; create a dedicated observe user for least privilege. Third, use Restart=on-failure rather than always, so a bad config becomes a visible failure instead of a silent restart loop.
Database. OBSERVE’s metadata layer supports DM8 and KingbaseES out of the box. To switch, change the driver in config.yaml to dm or kingbase. For DM8, use a UTF-8 character set and set LENGTH_IN_CHAR=1 so string lengths are counted in characters — otherwise Chinese text gets truncated mid-field and you’ll chase phantom bugs in the UI.
Time and certificates. Domestic environments are often on an isolated intranet, and unsynchronized NTP scrambles log timestamps and breaks alert triggers. Run ntpdate or configure chrony before deployment. Import self-signed certificates into the system trust store, or the HTTPS calls between OBSERVE’s internal components will fail with certificate errors that look nothing like a clock problem.
Performance. Phytium’s single-core performance trails mainstream x86. Log parsing is CPU-heavy, so lower concurrency, enable batching, and push parsing to the collection layer as pre-processing when you can, to cut server-side load. A few minutes spent profiling the parser on real Phytium hardware is worth more than any amount of tuning by guesswork.
A common mistake is to size Phytium hosts the same way you'd size x86. Give the collector and parser more cores than you would on x86, and enable batching early — it's a lot cheaper than re-architecting the pipeline mid-migration.
For teams planning a domestic migration, here's the concrete list of what gets swapped and what stays: the OS moves from CentOS or Ubuntu to UOS or Kylin, the CPU from x86 to Phytium or Kunpeng, the metadata database from MySQL to DM8 or KingbaseES, and the middleware from Tomcat to TongWeb or BES. OBSERVE's own binary is the part that stays the same, which is the whole point — you migrate the environment, not the tooling.
The migration order matters. Do the database first and point OBSERVE at it, because that's where the risk concentrates; the OS and CPU swap is mostly mechanical once the package matches the architecture. Keep a rollback snapshot of the metadata database until the health check passes on the new stack.
| Symptom | Cause | Fix |
| --- | --- | --- |
| Exits on startup | glibc too old | Upgrade UOS or use a static build |
| Wrong log timestamps | NTP not synced | Point chrony at an internal time source |
| Garbled Chinese | DB charset isn’t UTF-8 | Rebuild with LENGTH_IN_CHAR=1 |
| File descriptor exhaustion | LimitNOFILE not set | Add LimitNOFILE=65535 in systemd |
After deployment, run the bundled health-check script and confirm all three components — collection, storage, and query — register successfully before pointing real traffic at it. Getting this far on domestic hardware is a milestone; the health check is what tells you it’s a solid one.