A Unified Observability Platform That Connects Logs, Metrics, and Traces

One query entry for three kinds of data

What makes incident response slow is rarely the root cause itself; it's the switching between systems. Logs live in platform A, metrics in platform B, traces in platform C — timelines don't line up and fields don't match. JJHub OBSERVE puts logs, metrics, and traces into a single storage and query engine, with unified labels (app, env, instance) running through every record. Any one of the three can be followed through those labels back to the other two, so you stop stitching timelines together by hand.

SQL-style log search

The search box is not just for keywords. OBSERVE's log query supports SQL-like syntax, so filtering, aggregation, sorting, and paging happen in a single statement:

SELECT status, count(*) AS cnt
FROM access_log
WHERE path = '/api/order/create'
  AND ts > now() - interval 5 minute
GROUP BY status

Field types are detected at ingest time: timestamps, numbers, and strings get separate indexes, avoiding the storage bloat and slow queries that come from a blanket full-text index. Aggregations return in under a second, so you don't have to export tens of thousands of lines just to count error rates by hand.

Beyond the query, there's a parsing pipeline. The collection Agent ships JSON, regex, and Grok parsers that turn a messy Nginx or Java stack line into structured fields. Multi-line logs — exception stacks, for instance — can be merged by a first-line regex, so a single stack trace isn't chopped into hundreds of separate entries. You define the parsing rules once in the Agent config, and the structure is applied before the data lands in storage, so queries see clean fields rather than raw strings.

Alerting: reduce noise before notifying

Metrics support both Prometheus scraping and Agent push. Alert rules can be written in PromQL or in plainer threshold expressions. What really shapes the on-call experience is the noise-reduction logic:

• The same node and rule firing repeatedly within 5 minutes sends a single notification;
• Multiple alerts from the same source are folded into one event with a counter;
• Recovery notifications are delayed by default, so on-call engineers aren't woken up by "recovered" messages at 3 a.m.

Notification channels cover WeCom, DingTalk, email, and webhooks. On-call rotations run weekly, and every acknowledgment, escalation, and silence leaves a full audit trail. For teams already invested in Prometheus, the pull mode means you can point OBSERVE at your existing exporters and keep your rules instead of starting from scratch.

Traces and logs wired together in both directions

Traces come in via OpenTelemetry, with Span-level search and a flame graph view. The key design is correlation: every log line automatically carries trace_id / span_id, so from any Span in a trace you can jump straight to the logs it produced — and from a single error log you can reconstruct the whole call chain. Slow-request debugging no longer means "guess the machine, guess the time window." You start from the symptom, then walk the actual path the request took.

Dashboards and access control

Dozens of dashboard templates ship out of the box — service QPS, error rate, P99 latency, host resources — and a chart editor lets you build your own by drag and drop. Permissions are per project: logs, metrics, and traces are authorized independently, and an audit read-only role can view but not export, which covers multi-team collaboration and compliance review. This matters more than it looks: a contractor troubleshooting one service should not be able to read every team's logs.

How to roll it out

We recommend going in the order of logs, then metrics, then traces. Get log collection, search, and alerting working first; add metrics; wire up traces last. The correlation value only materializes once all three are in place. Storage defaults to hot/cold tiering: hot data on SSD, cold data auto-archived to object storage, so retention and query cost balance out. You can start on a single node; cluster mode scales out horizontally with storage and compute nodes separated, so you add nodes when capacity runs short.

Extensibility and ecosystem

OBSERVE is not a walled garden. It speaks OTLP natively, so anything that already exports OpenTelemetry data — a Go service using the OTel SDK, or a vendor's instrumented gateway — can feed it without a custom adapter. Prometheus exporters work as-is through pull mode. If you already run Grafana for visualization, you can keep it and point it at OBSERVE's query API; if you don't, the built-in dashboards are enough to start. Adopting OBSERVE shouldn't force you to rip out the monitoring you already have. You can migrate one team at a time, and the unified label model means the pieces still line up when you're done.