Ops teams often juggle three disconnected tools to troubleshoot. JJHub OBSERVE puts logs, metrics, and traces into one tagged data model. This post covers the data model, the correlation entry points, and practical rollout advice.
Most ops teams run three separate tools: ELK for logs, Prometheus for metrics, and Jaeger for traces. Each one is good at its own job, and each one is a silo. Investigating one production incident means hopping between three screens. You see CPU and error rate spike on the alerting dashboard, switch to the log system and page through logs by timestamp, then guess that some downstream call got slow and open the tracing tool hoping to find the right trace.
Once you finally pin down a trace, you go back to the logs for context and discover the two systems don't share labels — so you copy the trace ID by hand and run a fuzzy search. If the log tool finds nothing, you try yet another search with the request ID. Meanwhile the on-call chat fills with 'anyone see anything?' The time goes into aligning data, not fixing the problem. On a bad day, three engineers each look at their own slice of the picture and reach three different conclusions.
JJHub OBSERVE takes a simpler approach: put logs, metrics, and traces into one data model, joined by a shared timeline and tag system, so troubleshooting becomes a single-screen drill-down instead of a three-screen shuffle.
Internally the platform normalizes all telemetry into tagged event streams. Logs, metrics, and traces share the same label set: service, instance, environment, tenant. Logs belonging to a trace can be fetched directly via the trace_id tag, no second search needed. Metrics and logs align through host + service, so when an alert fires you can drill straight into the logs for that time window. Traces and metrics align through the service name, so a latency spike on a span can be matched to the corresponding metric series.
The key decision is making correlation a property of the labels, not of a query language. Once every record carries the same tags, joining them is a cheap index lookup rather than a manual hunt.
On the collection side everything runs through one OpenTelemetry Collector: a filelog receiver for logs, a prometheus receiver for metrics, and an otlp receiver for traces, all exporting to the same backend. A minimal configuration looks like this:
receivers:
otlp:
protocols: { grpc: {}, http: {} }
filelog:
include: [/var/log/app/*.log]
prometheus:
config:
scrape_configs:
- job_name: app
static_configs:
- targets: [localhost:8080]
exporters:
otlphttp:
endpoint: https://ob.jjhub.cn/otel
service:
pipelines:
traces: { receivers: [otlp], exporters: [otlphttp] }
logs: { receivers: [filelog, otlp], exporters: [otlphttp] }
metrics: { receivers: [prometheus, otlp], exporters: [otlphttp] }The filelog receiver tails application logs and attaches the same resource labels the agent sets, which is what keeps log-to-trace correlation working without extra plumbing.
All three entry points sit on the same tag index. A single correlation query typically returns in the low hundreds of milliseconds and doesn't degrade noticeably as volume grows, because the joins run on indexed tags rather than full-text search.
Don't rip out all three legacy tools on day one. Start with one core service, bring in logs and traces first, and after two weeks confirm the correlation queries cover about 80% of your day-to-day debugging before migrating metrics. Keep the old tools read-only during the transition as a fallback.
Mind the order: define the label standard first, then onboard the platform. Correlation only pays off once tags are consistent. If every team names its labels differently, no amount of data will stitch together. A short written spec — a one-page list of required tags and their allowed values — is worth more than any amount of tooling.