Observability and OpenTelemetry
Design of open source observability systems for logs, metrics and traces: OpenTelemetry introduced one step at a time, starting from what is already there, a backend without lock-in, alerts managed as code, and data ready for people and AI agents alike.
What observability is, and why OpenTelemetry
Observability means being able to understand what is happening in your systems from the data they produce: logs, metrics and traces. When something breaks, it lets you trace the problem back to its cause instead of going by trial and error. When everything runs smoothly, it tells you where time and resources go.
For years every tool had its own agents and its own formats, and the result was tying companies to a vendor and multiplying costs. OpenTelemetry changed that: today it is the de facto standard for collecting telemetry, and it is where I start in every observability infrastructure I design.
What OpenTelemetry is
OpenTelemetry (OTel) is a framework designed to collect logs, metrics, traces and other signals. It includes a set of SDKs, semantic conventions, a protocol (OTLP) and an agent, the OpenTelemetry Collector, essentially a modular pipeline for processing data and routing it where it is needed.
OpenTelemetry isn't a backend, a database or a visualization system: you send the data to Elastic, Grafana, ClickHouse, Datadog or whatever else fits your stack. The goal is to eliminate vendor lock-in and unify how telemetry is collected and transported. The most concrete promise is this: being able to swap the observability database or console without re-instrumenting everything.
Why adopt it, and what to watch out for
Its main strengths are vendor neutrality, a single instrumentation for everything and the freedom to switch backends. In an enterprise project I replaced a proprietary observability solution with an open source platform based on OpenTelemetry, spread across on-premises datacenters and cloud providers: licensing costs went to zero, and logs and metrics are now managed uniformly.
There are also limitations worth knowing: significant complexity, committee-driven evolution, and maturity that varies from component to component. Third-party distributions, moreover, simplify integration but sometimes bring extra bloat and a push toward a vendor, the opposite of the neutrality OTel is chosen for. That is why adoption needs to be planned.
Incremental adoption
In real projects, the approach I have seen work proceeds in stages:
- The collection infrastructure. Collectors configured as code, resilient (sending queues persisted on disk, retries, batching) and monitored in turn.
- The telemetry that already exists. Logs and metrics from virtual machines and Kubernetes clusters, collected without touching the applications: immediate value, minimal risk.
- Zero-code instrumentation. Auto-instrumentation adds application traces and metrics without anyone having to modify the code.
- Code-based instrumentation. Where more detail is needed, the SDKs go directly into the applications.
- Fostering adoption. Documentation, conventions and working alongside the teams, so that the tool actually gets used.
I talked about this at containerday 2025 in the talk Incremental Strategies for OpenTelemetry Adoption and on my blog: OpenTelemetry Incremental Adoption Strategies.
Backend and alerting with Prometheus and Alertmanager
As a backend, my current starting point is ClickStack: it keeps logs, metrics and traces in a single database, ClickHouse, without having to integrate three different products with three different query languages.
OpenTelemetry doesn't do alerting, by design. For that part I use the classic pairing of Prometheus and Alertmanager: the collector sends metrics to Prometheus, used as a rule engine, and Alertmanager handles grouping, routing and silencing of alerts. Rules and routing are one hundred percent Infrastructure as Code.
Observability for people and AI agents
With an AI agent that knows how to query the data, the graphical interface matters less and less: what matters is that the data is well organized in a suitable database, and that the agent has access to it in its harness, for instance through an MCP server. From there, when there is a problem, the agent runs the queries it needs and gets to the cause, often faster than a manual analysis.
A well-built OpenTelemetry infrastructure is the foundation of this way of working.
Frequently asked
What is the difference between monitoring and observability?
Monitoring checks conditions decided in advance: the service responds, a threshold has been crossed. Observability also works for the problems nobody had anticipated, because it lets you query logs, metrics and traces correlated with one another. You need both: alerts tell you something is wrong, observability helps you understand why.
Does OpenTelemetry replace Datadog, Elastic or Grafana?
No. OpenTelemetry collects and transports the signals, but it is neither a backend nor a console. You send the data to the backend you prefer, commercial or open source, and above all you can switch backends later without re-instrumenting.
Do we have to redo all the instrumentation?
No. I recommend an incremental approach: you start by collecting the telemetry that already exists, from virtual machines and Kubernetes clusters, and only later move to native instrumentation, first without touching the code and then in the code, where it really matters.
Which backend do you recommend?
It depends on the context, but today my starting point is ClickStack: logs, metrics and traces live in a single database, ClickHouse, and there is no need to integrate three different products. For alerts I use Prometheus and Alertmanager.
Does OpenTelemetry handle alerts too?
No, and that is a design choice: alerts are left to the backend. In an OpenTelemetry stack I still prefer Prometheus and Alertmanager, because rules and routing are text files and are managed as code.
Is OpenTelemetry mature enough?
Yes. For logs, metrics and traces it is now mature and complete enough to be the right choice. It remains a complex project, though, with components at different levels of maturity: that is why it is best adopted by following a plan.
Other services
- Kubernetes ConsultingKubernetes consulting: design, adoption and operation of clusters in the cloud, in the datacenter and at the edge, with a team ready to run them.
- Cloud ConsultingCloud consulting: architecture and infrastructure on AWS and Google Cloud, hybrid setups, incremental migrations and cloud repatriation.
- Platform EngineeringPlatform engineering: building a self-service, declarative and observable platform that people and AI agents can change safely.
- DevOps ConsultingDevOps consulting: reliable releases, infrastructure as code, cloud costs under control and a platform ready for AI agents.