OTCA key terms

A vendor-neutral open source framework that provides APIs, SDKs, and tooling to generate, collect, and export telemetry data such as traces, metrics, and logs from software.

A distinct category of telemetry data that OpenTelemetry handles. The primary signals are traces, metrics, logs, and baggage, each with its own data model, API, and SDK components.

The normative document that defines data models, APIs, and protocol behavior that all OpenTelemetry implementations must follow to remain interoperable across languages and vendors.

The language-specific interface that application code calls to create telemetry. It defines the contract without prescribing how data is processed, sampled, or exported.

The language-specific implementation of the API that handles sampling, processing, batching, resource attachment, and export of telemetry to configured backends.

A do-nothing implementation of the OpenTelemetry API used when no SDK is registered, letting instrumented libraries run without overhead or configuration changes.

The component, either built into a library or added via an agent, that creates spans, metrics, or logs for a specific technology such as an HTTP client or database driver.

Metadata attached to emitted telemetry identifying the library or module that produced it, typically a name and version, used to group and filter data.

Telemetry generation performed without code changes, typically through language agents, bytecode injection, or wrapper libraries that hook common frameworks and clients.

Adding telemetry by explicitly calling the OpenTelemetry API in application code, giving precise control over span boundaries, attributes, and custom metrics.

The API object that creates spans. It is obtained from a tracer provider and is typically named for the instrumentation scope that uses it.

The factory and registry that supplies Tracer instances and holds SDK configuration such as span processors, samplers, and resource information.

A single named, timed operation representing a unit of work in a trace, carrying a start time, end time, attributes, events, status, and parent relationship.

A directed acyclic graph of spans sharing a common trace identifier, representing the end-to-end path of a request through a distributed system.

The immutable portion of a span that identifies it across process boundaries: the trace ID, span ID, trace flags, and optionally trace state.

A 16-byte globally unique identifier shared by all spans in the same trace, used to correlate spans collected from different services and hosts.

An 8-byte identifier unique to a single span within a trace, used together with the trace ID to reference parent-child relationships.

The span that directly encloses another span in a trace hierarchy. A root span has no parent and its parent span ID is zero or absent.

A classification of a span's role in a trace, such as server, client, producer, consumer, or internal, which informs how timing and relationships are interpreted.

A field on a span indicating whether the operation completed successfully, errored, or has an unset status, distinct from the span's attributes and events.

A timestamped annotation attached to a span, such as an exception or state change, carrying a name and optional attributes but no duration of its own.

A reference from one span to another span that is not its parent, used to express causal or batch relationships such as fan-in or asynchronous processing.

A key-value pair attached to telemetry such as spans, metrics, or logs, used to add dimensions for filtering, grouping, and analysis. Values are strings, numbers, or booleans.

A set of attributes describing the entity that produced telemetry, such as service name, host, or container, attached to all signals from that source.

Standardized names and value formats for attributes and resource fields, ensuring telemetry from different libraries and services is consistent and comparable.

The mechanism for carrying trace context and baggage across process, thread, and network boundaries so that spans in different services join the same trace.

A component that injects context into outgoing requests and extracts it from incoming requests, using formats such as W3C Trace Context or B3.

A W3C standard defining the traceparent and tracestate HTTP headers used to propagate trace identifiers and vendor-specific state between services.

A one-byte field in the span context whose least significant bit signals whether the trace is sampled, propagated in the traceparent header.

A set of key-value pairs propagated alongside trace context across service boundaries, allowing application-specific data to travel with a request without being stored in spans.

A numeric measurement of a system captured over time, such as a counter, gauge, or histogram, used for aggregation, alerting, and trend analysis.

A metric instrument that records a monotonically increasing sum, such as total requests served, and supports optional non-negative increments.

A metric instrument that records the distribution of values, such as request durations, into configurable buckets and reports count, sum, and bucket counts.

A sample measurement attached to a metric data point that references a trace or span, enabling correlation between aggregated metrics and individual requests.

The rule for how metric values are reported over time, either cumulative since start or delta since the last report, affecting backend interpretation and reset handling.

The SDK component that controls when metrics are collected and exported, such as on a periodic interval or on demand, connecting instruments to exporters.

A structured record of an event with a timestamp, severity, body, and attributes, which may be correlated to a trace and span via its span context.

A bridge that captures records from an existing logging framework and converts them into OpenTelemetry log records, adding trace correlation and resource data.

A decision component that determines whether a span is recorded and exported, using strategies such as always-on, ratio-based, or parent-based sampling.

A sampling approach applied after spans of a trace are collected, typically in the Collector, allowing decisions based on the whole trace such as errors or latency.

An SDK component that receives spans from the tracer and forwards them, either immediately or in batches, to exporters, and can modify or filter them.

A span processor that queues finished spans and exports them in batches on a schedule or when a size threshold is reached, reducing export overhead.

The SDK or Collector component that serializes telemetry and sends it to a backend, such as an OTLP endpoint, a file, or a vendor-specific protocol.

The OpenTelemetry Protocol, a standard wire format over gRPC or HTTP for transmitting traces, metrics, and logs between SDKs, Collectors, and backends.

A standalone, vendor-neutral service that receives, processes, and exports telemetry, decoupling applications from backends and centralizing processing such as batching and sampling.

A Collector component that accepts telemetry from external sources, listening on a protocol such as OTLP, Jaeger, or Prometheus, and passing it into pipelines.

A Collector component that transforms, filters, enriches, or batches telemetry as it passes through a pipeline before export, such as memory limiting or attribute modification.

A Collector configuration construct that connects a set of receivers to processors and exporters for one signal type, defining the path data takes through the Collector.

A Collector component that links two pipelines, acting as an exporter for one and a receiver for another, enabling cross-signal processing such as span metrics generation.

The Collector configuration section that enables pipelines, selects extensions, and defines telemetry about the Collector itself, tying components together at runtime.

A Collector component that adds capabilities outside the data pipeline, such as health checks, pprof endpoints, or service discovery providers.

A Collector instance run close to the workload, often as a sidecar or daemon, that collects local telemetry and forwards it to a central gateway.

A centralized Collector tier that receives telemetry from many agents or SDKs and performs heavy processing, sampling, and routing before sending to backends.

The number of unique attribute value combinations for a metric or dimension. High cardinality increases storage and query cost and can overload backends.

A component that automatically discovers and adds resource attributes, such as cloud provider, host, or container metadata, to telemetry produced by an SDK.

A metric instrument that records a value that can increase or decrease, such as active connections, without being tied to a cumulative total.