OpenTelemetry
Give your observability agents OTel-specific understanding of infrastructure metrics
OTEL SEMANTIC CONVENTIONS COVERAGE
Database
| postgresqlreceiver | π’ Semconv + Receiver | |
| mysqlreceiver | π’ Semconv + Receiver | |
| redisreceiver | π’ Semconv + Receiver | |
| mongodbreceiver | π’ Semconv + Receiver | |
| elasticsearchreceiver | π’ Semconv + Receiver | |
| sqlserverreceiver | π’ Semconv + Receiver | |
| oracledbreceiver | π’ Semconv + Receiver | |
| CCouchDB | couchdbreceiver | π’ Semconv + Receiver |
| mysqlreceiver shared | π‘ Shared receiver | |
| β | π΄ No receiver | |
| β | π΄ No receiver | |
| CCosmos DB | β | π΄ No receiver |
| HHBase | β | π΄ No receiver |
Messaging
| kafkareceiver | π’ Semconv + Receiver | |
| rabbitmqreceiver | π’ Semconv + Receiver | |
| GGoogle Cloud Pub/Sub | googlecloudpubsubreceiver | π’ Semconv + Receiver |
| AAzure Event Hub | azureeventhubreceiver | π‘ Event Hub only |
| β | π΄ No receiver | |
| AAWS SNS | β | π΄ No receiver |
| RRocketMQ | β | π΄ No receiver |
System & Containers
| k8sclusterreceiver +3 more | π’ Semconv + Receiver | |
| dockerstatsreceiver | π’ Semconv + Receiver | |
| SSystem (Host) | hostmetricsreceiver | π’ Semconv + Receiver |
| OOS Process | hostmetricsreceiver | π’ Semconv + Receiver |
| OOpenShift | β | π΄ Use k8s receivers |
HTTP & Web
| apachereceiver | π‘ Generic HTTP semconv | |
| nginxreceiver | π‘ stub_status metrics | |
| iisreceiver | π‘ Windows only | |
| HHTTP Check | httpcheckreceiver | π‘ Probes only |
FaaS
| awslambdareceiver | π’ Semconv + Receiver | |
| β | π΄ No receiver | |
| GGoogle Cloud Functions | β | π΄ No receiver |
Cloud Providers
GCP and Azure cloud provider conventions not yet defined in semconv.
| AAWS SDK | awsxrayreceiver +cloudwatch | π‘ Indirect alignment |
CI/CD
| githubreceiver | π‘ No provider-specific semconv | |
| gitlabreceiver | π‘ No provider-specific semconv | |
| β | π΄ No receiver | |
| β | π΄ No receiver |
Generative AI
All GenAI telemetry is app-side via OTel SDKs; data reaches the Collector via otlpreceiver.
| β | π΄ SDK instrumentation only | |
| β | π΄ SDK instrumentation only | |
| AAWS Bedrock | β | π΄ SDK instrumentation only |
| AAzure AI Inference | β | π΄ SDK instrumentation only |
Object Stores
| awss3receiver | π’ Semconv + Receiver | |
| AAzure Blob Storage | azureblobreceiver | π‘ No semconv sub-page |
| GGoogle Cloud Storage | β | π΄ No receiver |
RPC
All RPC instrumentation is app-side; data reaches the Collector via otlpreceiver.
| ggRPC | yanggrpcreceiver network devices only | π‘ Network devices only |
| CConnect RPC | β | π΄ No receiver |
| AApache Dubbo | β | π΄ No receiver |
| JJSON-RPC | β | π΄ No receiver |
GraphQL
| GGraphQL | β | π΄ SDK instrumentation only |
Feature Flags
| FFeature Flags | β | π΄ SDK instrumentation only |
OTel Collector Contrib v0.147.0 Β· Semconv v1.40.0 Β· March 2026
OpenTelemetry Observability
OpenTelemetry represents a paradigm shift in observability by providing a vendor-neutral, open-source framework for collecting, processing, and exporting telemetry data. What makes OpenTelemetry's approach to metrics unique is its unified semantic conventions and standardized instrumentation across the entire observability stack. Unlike proprietary solutions, OpenTelemetry's metrics specification defines a consistent data model that works seamlessly across traces, metrics, and logs, enabling SREs to correlate infrastructure performance with application behavior. The platform's collector architecture allows for flexible pipelines that can transform, filter, and route telemetry data before it reaches backend systems, reducing vendor lock-in while maintaining comprehensive visibility. This is particularly valuable for infrastructure monitoring, where automatic instrumentation libraries can capture metrics from databases like MongoDB, PostgreSQL, MySQL, and Redis without requiring code changes.
For SRE workflows, OpenTelemetry excels through its extensive ecosystem of receivers and exporters that support critical infrastructure technologies. The platform provides native integrations for message queues like Apache Kafka, search engines like Elasticsearch, and cloud-native platforms including AWS Lambda, AWS RDS, and GCP Cloud Run. This extensibility extends to modern data platforms like Snowflake and Databricks, enabling comprehensive observability across hybrid and multi-cloud environments. The standardized approach means SREs can build reusable dashboards, alerts, and runbooks that work consistently regardless of the underlying infrastructure components.
In the observability ecosystem, OpenTelemetry has emerged as the de facto standard, backed by the Cloud Native Computing Foundation and supported by major vendors including Datadog, New Relic, Dynatrace, and Grafana Labs. Unlike legacy monitoring tools that require proprietary agents, or newer platforms that offer comprehensive solutions but with vendor lock-in, OpenTelemetry provides the instrumentation layer that feeds multiple backends simultaneously through its multi-pipeline export capabilities. This positioning makes it complementary rather than competitive to existing observability platformsβorganizations can adopt OpenTelemetry instrumentation while maintaining flexibility in their choice of analysis and visualization tools, future-proofing their observability strategy as the technology landscape evolves.