Deploy JUJING OBSERVE on Domestic ARM Servers with OceanBase

In a Xinchuang (domestic-stack) project, the first gate for an observability platform isn't features — it's whether it runs on domestic infrastructure. If your platform hard-depends on x86-only images or a JVM tuned for a particular distro, it stalls before the first log lands. JUJING OBSERVE's backend is a single Go binary with minimal dependencies and no JVM, which makes it a natural fit for ARM servers and domestic Linux. Here's a repeatable private-deployment walkthrough.

Cross-compile the ARM binary

The backend doesn't use CGO, so you can cross-compile a static binary that runs on any Linux:

cd backend
# domestic ARM servers (Kunpeng / Phytium)
GOOS=linux GOARCH=arm64 CGO_ENABLED=0 go build -o ob-log-backend-linux-arm64 .
# x86_64 (Hygon, etc.)
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o ob-log-backend-linux-amd64 .

For a container image, use the bundled Dockerfile — it runs the Go binary on a slim Linux base, not a JDK image, which keeps the footprint small enough to satisfy environments that scan images aggressively. On the OS side, Kylin V10, UnionTech UOS, and openEuler are supported; they're standard user-space Linux, so validation is organized around the customer's environment rather than a special build.

Connect OceanBase (MySQL mode)

JUJING OBSERVE speaks the MySQL protocol, so it can connect to OceanBase's MySQL compatibility mode without code changes. Configure the database before startup:

export DB_HOST=127.0.0.1
export DB_PORT=2881            # common OceanBase port
export DB_USER=root@sys        # adjust to your tenant account
export DB_PASS='******'
export DB_NAME=ob_log
export DB_PARAMS='charset=utf8mb4&parseTime=true&loc=Local&timeout=10s'
export LISTEN_ADDR=:8080
./ob-log-backend-linux-arm64

Two notes:

• Create the database in MySQL compatibility mode; startup auto-migrates the metadata tables. For the large service_log / tracing_log tables, plan indexes by tenant + time — the product already ships the relevant tenant_id + time index migrations, so the growth path is covered.
• Production and SaaS default to MySQL 5.7+ / 8.0. DM (Dameng) and Kingbase are "planned later" — dialect adaptation is scoped per project, not promised out of the box. Be explicit about this in procurement rather than discovering it during acceptance.

Frontend and overall architecture

The frontend is Vue3 + Element Plus. Run pnpm install && pnpm build and serve it via nginx or a domestic web server. In the overall architecture, ingestion goes through the X-Ingest-Token-authenticated HTTP API, while search, monitoring, and alerting all happen in the console — no dependency on Elasticsearch, Kafka, or other external middleware. Fewer moving parts means a smaller attack surface and lower self-operation cost, which is usually the point of going private in the first place.

Acceptance checklist

For a real project, validate in this order:

1. Start the backend on the target OS + ARM and log in as platform/admin;
2. Connect OceanBase MySQL mode, provision one tenant, and write one ingest record;
3. Verify the query-window limit and the storage/ingest quota alerts;
4. Verify the audit list and delegated (impersonation) login.

Also note: full SM2/SM3/SM4 cryptographic support, official Kylin/UOS compatibility certificates, and MLPS (等保) assessment are separate engagements, not part of the default delivery. The full Xinchuang support matrix lives in the docs center.

Support matrix at a glance

The delivery status for each layer, in one table:

| Layer | Options | Status |
|-------|---------|--------|
| CPU | Kunpeng / Phytium / Hygon (x86) | Deliverable — cross-builds for arm64 and amd64 |
| OS | Kylin V10, UOS, openEuler | Project-validated — standard user-space Linux |
| Database | OceanBase (MySQL mode), MySQL 5.7+/8.0 | Project-validated / deliverable |
| Database | DM (Dameng), Kingbase | Planned — dialect adaptation scoped per project |
| Crypto | bcrypt + JWT | Deliverable — SM series can be added per project |
| Deploy | Binary / container | Deliverable |

"Deliverable" means it's sustained for production projects. "Project-validated" means the protocol and architecture support it, but you should complete acceptance in the target environment. "Planned" means it needs a scoped engagement — don't put it on the default delivery contract. This distinction is worth carrying into procurement, because it's where most Xinchuang deals quietly slip.