For further definitions of OpenTelemetry concepts, see the OpenTelemetry documentation.
Key-value pair, usually attached to a span, resource, or event. Resource attributes are part of the metadata and will be carried across the whole trace, while span attributes are unique to each span. For more information, see Trace concepts.
Intended for indexing observability events in one service with attributes provided by a prior service in the same transaction. Establishes a causal relationship between events.
The Cloud Native Computing Foundation (CNCF) hosts critical components of the global technology infrastructure. CNCF brings together the world’s top developers, end users, and vendors and runs the largest open source developer conferences. CNCF is part of the nonprofit Linux Foundation.
Vendor-agnostic proxy that can receive, process, and export telemetry data. Can be deployed as an agent or gateway. For more information, see OpenTelemetry Collector.
Refers to metadata that is being collected, stored, and carried across API boundaries by various components within a distributed system. For more information, see Trace concepts.
Core concept of OpenTelemetry. Allows the context carried by data sources to be shared and enables, for example, traces to be connected along the execution flow of a request.
- Example for manual context propagation.
- For more information, see OpenTelemetry context propagation.
Process of tracking a single request (trace) as it traverses various services of an application. Such a trace is not bound by processes, networks, and so on. For more information, see Distributed tracing powered by PurePath® technology.
Human-readable message on a span that means “something happening” during its lifetime. It is therefore best suited to display information about errors.
Component to send data to one or more backends. An exporter can be part of a collector.
Record of an event, including timestamps and other data about the nature of the event. For more information, see OpenTelemetry basics.
Key-value pairs added to telemetry data. Metadata is represented as attributes on spans or events, as labels on metrics, and as fields on logs.
Record of a data point. A metric event consists of the measurement, the time it was captured, and associated metadata (labels). For more information, see OpenTelemetry basics.
Abbreviation for OpenTelemetry.
OpenTelemetry Protocol (OTLP) specification, which describes the encoding, transport, and delivery mechanism of telemetry data between telemetry sources, intermediate nodes such as collectors, and telemetry backends.
Component that decides what to do with the data received through the receiver. A processor can be used in process as well as in a collector. Though there are some recommended processors, they are optional.
Objects used to read and write context data to and from messages exchanged by the applications. They leverage context to inject and extract data, for example, for traces and baggage.
Protocol Buffers, a data format to serialize structured data. Google developed Protocol Buffers for internal use and provided the code later under an open-source license. Protobuf was designed to be smaller and faster than, for example, XML. As such, it is used for storing and interchanging information. It also serves as a basis for a custom RPC system that is used for inter-machine communication.
Component to receive data in various formats. A receiver can be part of a collector.
Immutable representation of any entity that generates telemetry data. All data sent to a backend must be associated with a resource to allow linking it with the appropriate entity.
Process used to reduce noise and overhead by controlling the amount of data exported. Often used with tracing.
Standard names and values of metadata. Standardization is crucial to provide vendor-agnostic data.
Single operation within a trace. A span contains metadata as well as the context to be carried over along the trace. Spans can be nested within a trace and have parent/child spans. For more information, see OpenTelemetry basics.
Relationship between the span, its parents, and its children in a trace. Possible span kinds are: Client, Server, Consumer, Producer; the default is Internal. For more information, see OpenTelemetry span kind.
Progression of a single request as it is handled by various services throughout an application. It contains a single root span and any number of child spans. For more information, see OpenTelemetry basics.
Component responsible for creating spans. A tracer should not be responsible for configuration (which is done by the tracer provider). For more information, see Trace concepts.
Component responsible for holding any configuration within an API implementation. Also allows access to the tracer.