Logs, Metrics, and Traces in One Place: Inside JJHub Observe

Most observability stacks today are stitched together: ELK for logs, Prometheus for metrics, Jaeger for traces. The data lives in three separate systems, and when something breaks you bounce between dashboards, doing the correlation by hand — copy a timestamp out of one UI, paste it into another, and hope a trace_id shows up in a log line. JJHub Observe collects all three signals into one platform and connects them through a shared data model and a single search entry point. This article walks through each capability and the usage patterns that actually matter day to day.

SQL-Like Log Search

Logs are only useful if you can find the right ones fast. Our search accepts a SQL-like syntax, so you write conditions like status >= 500 AND service = 'order' instead of memorizing a query DSL. A typical query during an incident:

level = 'ERROR' AND service = 'payment' AND latency > 1000

The syntax supports the operators you would expect from SQL:

• Full-text fuzzy matching: content LIKE '%timeout%'
• Numeric range checks: latency BETWEEN 500 AND 2000
• Field-existence conditions: trace_id IS NOT NULL
• Boolean composition with AND, OR, and NOT

Results aggregate in one click: group by error_code to count occurrences, or bucket by time to see the distribution curve. When you expand a single log line, a "View Trace" button jumps straight to the corresponding trace — no more guessing trace_ids by hand.

On indexing, we recommend indexing three high-frequency fields: service, level, and trace_id. Hot/cold tiering is on by default: hot data sits on SSD for the last 7 days, cold data moves to object storage with retention up to 365 days, which keeps cost under control without sacrificing recent-search speed.

Metrics and Alerting

The metrics side speaks PromQL. If you already run Prometheus, point remote_write at JJHub Observe with zero code changes — no migration needed, and you can write to both in parallel while you evaluate. Alert rules follow the same shape as Prometheus alerting rules:

groups:
  - name: order-service
    rules:
      - alert: OrderErrorRateHigh
        expr: sum(rate(order_requests_total{status=~"5.."}[5m])) / sum(rate(order_requests_total[5m])) > 0.05
        for: 5m

Notifications go out via WeCom, DingTalk, Feishu, email, and webhook, with per-rule routing and severity grouping. One common mistake: a default "above threshold for 5 minutes" window misses burst failures. For error-rate metrics, use for: 1m with tiered thresholds; reserve the long window for slow-climbing signals like CPU or disk. Inhibition rules are available too, so a flood of alerts from one downed service doesn't drown out everything else.

Tracing

Tracing answers "where exactly did this request slow down?" JJHub Observe fully supports the OpenTelemetry protocol. Instrument with the Java/Go/Python/Node.js SDKs, and traces automatically link to logs and metrics: open a slow span and you see the logs from that time window plus the service's error-rate curve.

Flame graphs, upstream/downstream dependency topology, and cross-service latency rankings are built in and need no extra setup. We recommend focusing effort on sampling slow requests rather than capturing everything: sampling by latency > 500ms or error status covers roughly 95% of investigation scenarios at one-tenth the storage cost. If you follow the OpenTelemetry semantic conventions for span attributes (HTTP method, status code, DB statement), the platform builds service maps and latency baselines for you automatically.

RBAC and Multi-Tenancy

Production needs permissions. JJHub Observe supports RBAC down to project and service granularity, so a database team sees only the services it owns. Sensitive fields (phone numbers, ID numbers, card numbers) are automatically masked in logs and traces, in both display and export. Audit logs are stored separately and traceable for 180 days — who queried what, and when.

Once the three signals are linked, the investigation path becomes a straight line: alert → metric to locate the service → logs for context → trace for the call chain. We packaged all of this into a product so teams stop wasting time figuring out where their data actually lives.

A practical note for teams evaluating the platform: start with logs and traces first, because they share the same investigation flow, then layer in metrics. Most of the value comes from the cross-links — a metric that jumps to logs, a log that jumps to a trace — and those links are only as useful as the attributes you put on them. Spend a little time up front naming services consistently and tagging requests with business identifiers; it pays for itself the first time you search by order ID instead of digging through timestamps.