Loading content
OpenTelemetry is an open standard and ecosystem for collecting, transporting, and configuring telemetry data (traces, metrics, logs). It enables vendor-neutral instrumentation of applications and provides SDKs, collectors, and exporters for cloud and on-premises operation. This improves diagnostics of performance issues, supports multiple languages and backe…
Use this profile to understand the building block briefly, place it in the model, and open related building blocks.
Technical building block: can be automated, integrated, or operated.
Concrete cog in the system that works inside larger relationships.
OpenTelemetry is an open standard and ecosystem for collecting, transporting, and configuring telemetry data—traces, metrics, and logs—via SDKs, a collector, and exporters.
OpenTelemetry evolved from the OpenTracing and OpenCensus projects and was created by merging those efforts into a shared observability approach. The resulting direction emphasizes vendor-neutral instrumentation: applications use a unified API/SDK surface, while telemetry destinations are selected through export configuration.
Picture OpenTelemetry as a telemetry “transport system” with three roles: (1) In the application, OpenTelemetry APIs/SDKs generate signals such as traces, metrics, and logs. (2) The OpenTelemetry Collector receives telemetry through its pipeline, applies processing like filtering/routing, and prepares it for delivery. (3) Exporters send data to one or more observability backends; for end-to-end analysis, shared context is propagated across service boundaries so that traces, metrics, and logs can be correlated along the request path.
The application is instrumented via a common API/SDK layer so backend choices remain interchangeable.
Traces, metrics, and logs can be related using context that flows across services.
The collector processes telemetry systematically (receive, filter/route) before exporting.
Exporters deliver telemetry to targets such as Jaeger, Prometheus, commercial systems, or your own solution.
Open specifications define the OTLP wire protocol used between OpenTelemetry components.
OpenTelemetry helps when you need consistent instrumentation across languages, platforms, or observability backends—and you want to change destinations without modifying application code. In practice, you still need to set up Collector/Exporter configuration correctly and ensure context propagation works across service boundaries to preserve correlation. The approach adds operational responsibility for the collector and its processing/export path(s).
Where this building block is located in the topic model.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.