A tour of Jujing OBSERVE's core capabilities: unified logs, metrics, and traces, a SQL-like query language, hot/cold storage tiers, alert deduplication, and native OpenTelemetry support.
Jujing OBSERVE brings logs, metrics, and traces together on a single platform. Logs stop being files you only open after something breaks; metrics stop being isolated curves on a chart; traces stop being a standalone call graph. All three are joined through shared fields such as traceId, service, and host, so any given request can be followed back and forth across logs, metrics, and traces without ever switching tools.
The query layer uses a SQL-like syntax, which means operators and developers don't have to learn yet another DSL. To pull up request logs with status 500 from a service over the last ten minutes:
SELECT * FROM logs
WHERE service = 'order-service' AND status = 500
AND ts > now() - interval '10 minute'
ORDER BY ts DESC LIMIT 100;Full-text search, field-level filtering, regex, and aggregation are all supported. You can group errors by host, rank slow endpoints by P99, or count distinct error types over a day. Any query can be promoted to an alert rule with one click, so you never write a query twice, and commonly used queries can be saved as shared views for the whole team.
On the collection side, OBSERVE accepts Agent, Filebeat, Syslog, and Kubernetes container logs. Built-in parsing rules automatically recognize common formats such as JSON, Nginx access logs, and Java exception stacks, structuring fields so you can filter on them directly when searching. A multiline Java stack trace, for instance, is folded back into a single log event instead of scattering across dozens of lines, which is what makes field-level search actually usable on stack traces.
Storage is split into hot and cold tiers. Hot data sits on SSD for second-level retrieval over the recent window you are actively troubleshooting, while cold data is compressed and archived to object storage at a fraction of the cost. Retention periods are set per tenant and per application, so a compliance team can keep five years while a dev environment keeps fourteen days, all under one platform.
Metric collection is compatible with the Prometheus ecosystem. PromQL works as-is, existing exporters plug in without modification, and you can point Prometheus remote-write at OBSERVE if you already run a Prometheus fleet and want a single pane of glass. The alert engine supports multi-dimensional aggregation, sliding windows, silence periods, and alert grouping. If 100 containers on the same host go OOM at once, the on-call engineer receives a single merged alert instead of 100 pings.
Notification channels cover WeCom, DingTalk, Lark, email, and webhooks, with routing by severity so a P0 goes to phone or SMS while a P3 only lands in a channel. Every alert carries the query that produced it, so the person woken up at 3 a.m. can go from notification to the offending series in one click rather than reverse-engineering what the alert meant.
The tracing module speaks OpenTelemetry natively. Once connected, it builds the service topology automatically and shows P99 latency, error rate, and throughput in real time. Click any span and you can see the logs and host metrics tied to it, skipping the usual "check the dashboard, grep the logs, guess at the code" routine. A slow request can be pinned to a specific method call rather than stopping at the service boundary.
Sampling is configurable per service. You can keep head-based sampling for high-volume paths while forcing 100% retention on the endpoints that matter, checkout, login, and payment, so you never lose a trace from the requests you actually care about.
With the three data types under one roof, the investigation path gets shorter. Consider a 3 a.m. alert on a slow checkout API. You open the alert, follow it into the trace of the slow request, see that the inventory span took 900ms, open its logs, and find a lock wait on a database row. One continuous thread from notification to root cause, in the same tool. The platform partitions tenants and projects by team, keeping permissions, quotas, and retention isolated, so dozens of teams can share a single deployment without stepping on each other, cutting both operational overhead and the risk of data leaking across boundaries.
OBSERVE runs as a small set of services that can start as a single node for a pilot and scale horizontally as traffic grows, with collection, storage, and query each scaling independently. It ships offline install bundles for x86 and ARM64, which matters if your fleet includes Xinchuang hardware. A pilot environment can be standing in under an hour, and the same install path carries you to production.