OpenTelemetry (OTel) is an open-source, vendor-neutral framework for generating, collecting and exporting observability data. It gives engineering teams a single standard for capturing metrics, logs and traces without locking instrumentation into one vendor.
Modern applications span microservices, containers and cloud infrastructure. When every tool uses its own proprietary agent and data format, connecting signals becomes slow and expensive.
OpenTelemetry solves this by standardising how telemetry is created and moved. Yet it is not an observability platform. It simply produces and routes data. Turning that data into reliable alerts and dashboards still requires strong engineering and governance.
How is it performing?
Standardised measurements of latency, error rates and resource usage across services.
What happened?
Structured event records linked to trace context to tie errors to specific requests.
Where did it happen?
Distributed request paths that expose bottlenecks and failing dependencies.
Services generate telemetry using OpenTelemetry APIs, language SDKs or automatic instrumentation. This reduces reliance on proprietary agents.
The OpenTelemetry Collector collects telemetry across your stack. It filters noise, masks sensitive fields and enriches metadata in one pipeline.
Processed data exports via the open OTLP protocol to platforms like Elastic. There, it is ready for storage, search, correlation and alerting.
Instrument your applications once using open standards. You can then route telemetry to your chosen backend without rewriting code.
Shared semantic conventions standardise how telemetry is structured. Services written in different languages describe hosts, requests and errors the exact same way.
Built-in context propagation tracks every request across service boundaries. It links logs, metrics and traces across complex microservice chains.
The OpenTelemetry Collector filters telemetry before it leaves your environment. You can sample traces and drop noisy records before ingestion bills grow.
Elastic is a major contributor to OpenTelemetry, offering native OTLP ingestion alongside dedicated tooling for self-managed and cloud environments:
ECS and OpenTelemetry Semantic Conventions: Elastic contributed the Elastic Common Schema (ECS) to OpenTelemetry to align both models into unified conventions. Because existing Elastic dashboards and security rules may still rely on ECS fields, careful schema mapping keeps legacy and modern pipelines working smoothly together.
Elastic Distributions of OpenTelemetry (EDOT): Elastic provides tested, supported OTel SDKs and Collector components integrated with Elastic Agent for streamlined deployment.
Elastic Self-Managed: Running gateway OpenTelemetry Collectors in front of self-managed Elastic clusters gives you open instrumentation standards with full control over data residency, security and infrastructure.
Adopting OpenTelemetry removes proprietary agent lock-in, but operational discipline remains essential:
Inconsistent service names and missing attributes weaken correlation across services.
Collecting every trace span without smart sampling quickly inflates storage bills.
Gateway Collectors are production infrastructure. They need active monitoring, scaling and upgrades.
Mixing legacy agents, ECS integrations and OTel pipelines takes clear mapping rules.
Someone must maintain SDKs, enforce naming rules and refine pipelines over time.
Observata helps organisations run OpenTelemetry with Elastic in your own infrastructure. We handle Collector architecture, schema alignment and daily operations while your engineers focus on core software.
Explore our approachTimestamped event records that detail application activity, errors and system state. Learn how structured logs turn raw data into reliable answers.
Read more about What are logs?Numerical measurements of latency, throughput and resource usage. Discover how metrics spot performance shifts before users feel them.
Read more about What are metrics?Distributed request paths that follow transactions across services and dependencies. See how traces pinpoint where delays and failures happen.
Read more about What are traces?