Observability tools and their roles
Choose the signals needed to investigate a real failure.
Grafana and Prometheus belong in the same observability category, but solve different parts of the problem. Prometheus collects and stores metrics and evaluates rules. Grafana queries data sources and provides dashboards, exploration and alerting. They commonly work together; a single score comparing one against the other would hide that relationship.
Sources reviewed: 2026-09-06. Versions and licenses below describe the reviewed upstream cores. These are editorial shortlists based on official documentation, not measured throughput, reliability or cost rankings.
At a glance
Rating (1–5): an editorial readiness score for the fit named in the same row, dated 2026-09-06. It adds five criteria worth 0, 0.5 or 1 point each: maintenance, open edition (what the open-source edition includes without a paid tier), maturity and community, operating scope and interoperability, with caps for archived, stale or prerelease projects. The breakdown sits under the table and the method on the Blog index. A rating is not a benchmark or a universal ranking; the workload sections still decide.
| Role | Reviewed components | Rating | Core license | What changes the decision |
|---|---|---|---|---|
| Metrics collection and local queries | Prometheus 3.14.0 | Apache-2.0 | Scrape coverage, active series, local retention and alert rules. | |
| Dashboards and exploration | Grafana 13.2.1 | AGPLv3 | Data-source permissions, plugins and the selected OSS or commercial edition. | |
| Long-term metrics | Mimir 3.2.0 | AGPLv3 | Multi-tenant metrics, object storage and distributed operation. | |
| Alternative metrics backend | VictoriaMetrics 1.151.0 | Apache-2.0 core | Single-node versus cluster deployment, query compatibility and enterprise boundaries. | |
| Global Prometheus queries and retention | Thanos 0.42.4 | Apache-2.0 | Existing Prometheus topology, deduplication and storage/query components. | |
| Logs | Loki 3.7.7 / OpenSearch 3.8.0 | AGPLv3 / Apache-2.0 | Label-based log exploration versus indexed search and its storage cost. | |
| Distributed traces | Tempo 3.0.3 / Jaeger 2.20.0 | AGPLv3 / Apache-2.0 | Trace investigation, sampling, storage and integration with the existing interface. | |
| Continuous profiling | Pyroscope 2.3.0 | AGPLv3 server | Language support, collection overhead and investigation of CPU or memory consumption. | |
| Collection and routing | OpenTelemetry Collector 0.160.0 / Alloy 1.19.2 | Apache-2.0 / Apache-2.0 | Receivers, processors, exporters and supported signals in the chosen distribution. | |
| Alert notification routing | Alertmanager 0.34.0 | Apache-2.0 | Grouping, deduplication, silences and delivery to the responsible team. | |
| Integrated observability application | SigNoz 0.140.0 | MIT core; enterprise exceptions | A shared investigation workflow, backend operation and the exact edition's controls. |
How each rating was computed
Five criteria worth 0, 0.5 or 1 point each. Caps: archived upstream 1, no stable release in 18 months 2, no general-availability release 2.5. "Open edition" scores what the open-source edition includes without a paid tier. Scored on 2026-09-06 from the official repository, releases and documentation; the method is on the Blog index.
| Project | Maintenance | Open edition | Maturity | Operations | Interoperability | Rating |
|---|---|---|---|---|---|---|
| Prometheus | 1 | 1 | 1 | 1 | 1 | 5 |
| Grafana | 1 | 0.5 | 1 | 1 | 1 | 4.5 |
| Mimir | 1 | 1 | 0.5 | 0.5 | 1 | 4 |
| VictoriaMetrics | 1 | 0.5 | 1 | 1 | 0.5 | 4 |
| Thanos | 1 | 1 | 1 | 0.5 | 1 | 4.5 |
| Loki | 1 | 1 | 1 | 0.5 | 1 | 4.5 |
| OpenSearch | 1 | 1 | 1 | 0.5 | 1 | 4.5 |
| Tempo | 1 | 1 | 0.5 | 0.5 | 1 | 4 |
| Jaeger | 1 | 1 | 1 | 0.5 | 1 | 4.5 |
| Pyroscope | 1 | 1 | 1 | 0.5 | 0.5 | 4 |
| OpenTelemetry Collector | 1 | 1 | 0.5 | 1 | 1 | 4.5 |
| Alloy | 1 | 1 | 0.5 | 1 | 1 | 4.5 |
| Alertmanager | 1 | 1 | 1 | 1 | 0.5 | 4.5 |
| SigNoz | 1 | 0.5 | 1 | 0.5 | 1 | 4 |
AGPL is an open-source license. Grafana's commercial distributions, enterprise directories and plugins can have different terms; a vendor name does not determine the license of every component. The Grafana licensing overview and each reviewed repository establish those boundaries.
Start with the incident
- A small service needs actionable metrics: start with Prometheus, Grafana and an explicit alert delivery path. Add retention infrastructure when the actual history, availability or scale requirement needs it.
- Several Prometheus installations need shared history: compare Thanos, Mimir and VictoriaMetrics using the current topology and representative queries. Include missing data, deduplication and tenant boundaries.
- Investigations begin with service labels and time ranges: shortlist Loki for logs. Include OpenSearch when indexed search across log content and fields is central to the workflow.
- A request crosses several services: compare Tempo and Jaeger with instrumented requests and a sampling policy. A storage backend cannot reconstruct spans that were never collected.
- The delay is inside a process: evaluate Pyroscope for profiling and connect the evidence to metrics and traces. Profiling and distributed tracing answer different questions.
- The team wants one investigation application: trial SigNoz alongside a composed Grafana stack. Compare the complete deployment and permission model, including the data backend and any commercial feature dependency.
Version and operating notes
Metrics — Prometheus, Mimir, VictoriaMetrics and Thanos
The Prometheus overview separates the server, exporters and Alertmanager. Its local time-series database and rules are useful without a distributed metrics service. It is monitoring data, not a complete per-request billing ledger.
Mimir adds long-term, multi-tenant metrics storage and querying. VictoriaMetrics offers single-node and cluster paths; verify the query and replication behavior of the selected deployment. Thanos can extend existing Prometheus installations with global queries and historical storage. Include its chosen components in recovery tests.
Logs — Loki and OpenSearch
Loki organizes log streams around labels; OpenSearch supplies a search and analytics engine with indexed fields.
Replay real investigations: known service and trace ID, unknown error text and a long time window. Measure ingestion, index or chunk storage, query latency and retention deletion. Keep user IDs and request IDs out of unbounded label sets; choose indexed fields intentionally.
Traces and profiles — Tempo, Jaeger and Pyroscope
Tempo and Jaeger support distributed tracing. Pyroscope's license boundary separates its AGPL server from client integrations under their own terms.
Trace a slow request through retries and asynchronous work. Confirm context propagation and which spans sampling discards. For profiles, measure collection overhead in the actual runtime and verify that the captured period includes the problem being investigated.
Collectors — OpenTelemetry Collector and Grafana Alloy
OpenTelemetry Collector receives, processes and exports telemetry. It is not the durable query backend. Component availability and stability depend on the selected distribution and signal.
Alloy is an OpenTelemetry Collector distribution with Prometheus pipelines and integrations for logs, traces and profiles. Choose by the components needed and the configuration the team can operate. Test buffering, retries, overload and attribute redaction before a backend receives data.
Dashboards and alerts — assign ownership explicitly
Grafana is the shared query and visualization interface in this site's platform stack. A dashboard does not replace the metric, log, trace or profile storage it queries.
Prometheus evaluates its alert rules; Alertmanager routes notifications. Grafana alerting can also evaluate rules across supported data sources. Choose which system owns each rule, silence and contact route. Rehearse a backend outage and verify notification delivery without relying on the dashboard being available.
Integrated platforms — compare the complete deployment
SigNoz brings telemetry investigation into one application. Its license uses MIT for the core with enterprise exceptions. Verify permissions, identities and retention in the edition actually being evaluated.
OpenObserve is another observability-oriented option, covered there alongside analytical storage. Compare the collection, storage and user workflow together; fewer visible services do not by themselves prove lower operating cost.
A trial that can change the decision
Use a service with one dependency, a failed deployment and a noisy tenant.
- Coverage: detect errors, latency and missing telemetry. A collector dropping data must not produce a misleadingly healthy dashboard.
- Investigation: follow an alert into a trace, relevant logs and a profile where available. Record evidence gaps and investigation time.
- Alert delivery: fail a backend and a notification receiver; check retries, grouping, silences and the independent failure signal.
- Recovery and access: restore configuration and retained data; test tenant separation, redacted attributes and expired credentials.
- Cost: measure active series, label cardinality, log volume, sampled spans, profile overhead, retention and operator effort under the same load.
Follow the data
The stack already separates platform observability from LLM observability with Langfuse, Helicone and Arize Phoenix. Model evaluation, token accounting and prompt traces add another application-specific layer; they do not establish infrastructure health by themselves.
Workflow orchestration and transformation also need freshness and correctness checks. BI serves business questions, while SLO budgets help turn service objectives into an operating decision. Choose the signals that answer those questions first.