When the conversation turns to the modern observability stack, three names come up again and again : OpenTelemetry, VictoriaMetrics, Grafana. Here is why this combination has become a credible (and often superior) alternative to all-in-one SaaS platforms.
OpenTelemetry: the unifying standard
OpenTelemetry (OTel) is the CNCF open-source standard for collecting, processing, and exporting telemetry data. Supported by nearly every vendor, it guarantees complete portability : by instrumenting your code with OTel, you can switch backends without changing the code.
The OpenTelemetry Collector is the most complete embodiment of the unified agent. Its pipeline architecture (receivers → processors → exporters) collects metrics, logs, and traces simultaneously, transforms them, and routes them to one or more backends—all in a single binary.
The key benefit: the end of agent sprawl
| Before: a fragmented landscape | After: a streamlined architecture |
|---|---|
| Agentless monitoring (PRTG via SNMP/WMI) Zabbix agent Centreon agent (legacy) Prometheus exporter Filebeat agent (logs) Fluentd agent (logs) Jaeger agent (traces) → Up to 6-7 components per machine | Agentless monitoring (unchanged) Centreon CMA (OTLP-based) OpenTelemetry Collector (metrics + logs + traces) → 2 to 3 components, clearly scoped |
VictoriaMetrics: the next-generation TSDB
VictoriaMetrics is an open-source time-series database (Apache 2.0) built for high performance and remarkable cost efficiency. Its ecosystem covers all three pillars :
| Component | Role | Strengths |
|---|---|---|
| VictoriaMetrics | Metrics | 7x+ compression, MetricsQL, native OTLP support |
| VictoriaLogs | Logs | Multi-source (Filebeat, OTel, Syslog), LogsQL, Grafana integration |
| VictoriaTraces | Traces | OTLP HTTP/gRPC, Grafana visualization |
| VM Anomaly Detection | Anomaly detection | AI on time series for proactive alerting |
| vmagent | Collection | Lightweight agent, faster than Prometheus Agent |
Documented results in production : Grammarly cut its costs by 10x after migrating from its previous stack. Spotify reports significantly improved Grafana performance. Zomato manages 2.2 billion active series. CERN uses VictoriaMetrics for real-time monitoring of the CMS detector.
Grafana: unified visualization
Grafana brings the data from both camps together in a single interface. Its data sources connect to VictoriaMetrics, VictoriaLogs, and VictoriaTraces, as well as PRTG and other monitoring tools through dedicated plugins.
For teams, this is a paradigm shift : no more juggling 5 tools to make sense of an incident. Everything is centralized, correlated, and within reach.
From normalization to correlation: the real promise
Normalization through OpenTelemetry is only the first step. The real promise is realized when an operator can move from an alert on a metric to the corresponding logs and then back up the trace, without ever leaving the interface.
- An abnormal metric automatically linked to the logs of the same service
- An error log tied to the trace through a correlation identifier (trace ID)
- A trace enriched with the metrics of the relevant service at the moment of execution
Without these capabilities, the three pillars remain three silos. The choice of backend absolutely must factor in this criterion.
Comparing the approaches
| Criterion | SaaS (Datadog…) | Grafana Stack | VM Stack |
|---|---|---|---|
| Model | Proprietary cloud | Assembled open-source | Unified open-source |
| Cost | High and variable | Infrastructure only | Infrastructure, highly optimized |
| Ops complexity | Low (managed) | High (4+ components) | Moderate |
| Data sovereignty | No (third-party cloud) | Yes | Yes |
| Vendor lock-in | Strong | Low | Low |
| Performance | Good | Variable | Excellent |
Our takeaway : the VictoriaMetrics + OpenTelemetry + Grafana stack offers the best trade-off today for organizations seeking observability that is performant, cost-effective, and under their own control.
In the next article, we will lay out the roadmap for building this stack step by step.
This article is drawn from our white paper “From Monitoring to Observability” (PDF, 2026).
