Core concepts
OpenTelemetry (OTel). A CNCF project that defines a vendor-neutral standard for application telemetry: traces, metrics, and logs. Includes language SDKs, a Collector, semantic conventions, and the OTLP wire protocol.
Telemetry. Anything an application emits about itself for observability purposes. In OpenTelemetry, telemetry consists of three signal types: traces, metrics, and logs.
Observability backend. The destination for telemetry. Telemtra is an OTLP-native observability backend; Jaeger and Tempo are tracing-only backends; Prometheus is metrics-only.
Resource. A set of attributes that describe the entity producing telemetry — for example service.name=checkout-api, deployment.environment=production, host.name=api-7b3. Resources are attached to every span, metric, and log record emitted by that entity and are the key to cross-signal correlation.
Semantic conventions. A registry of standardized attribute names and values (http.request.method, db.system.name, messaging.destination.name) so that telemetry from different libraries is queryable in the same way.
Signals
Span. A single named, timed operation within a trace — for example, "HTTP GET /orders" or "SELECT FROM orders." Spans have a start time, end time, status, attributes, events, and links.
Trace. A tree of spans that share a trace ID, representing the full path of a request through a system.
Trace ID and span ID. 128-bit and 64-bit identifiers respectively. The trace ID stays the same across every span in a trace; each span has its own span ID and references its parent.
Span event. A timestamped log-like message attached to a span, useful for "something happened mid-span" markers that do not warrant their own span.
Span link. A reference from one span to another, useful for tying together related but causally separate traces (for example, fan-out work that resumed later).
Span status. The outcome recorded on a span: Unset, Ok, or Error. Backends use it to compute error rates per operation; instrumentation sets it from HTTP status codes or caught exceptions.
Log record. A structured log line in OTLP form, with timestamp, severity, body, attributes, and optional trace and span IDs for correlation.
Metric. A numeric measurement over time. OpenTelemetry supports counters, up/down counters, gauges, and histograms.
Counter / UpDownCounter. A monotonically increasing or freely changing integer or float counter. Counter only goes up (orders placed); UpDownCounter can go up or down (active connections).
Gauge. A point-in-time measurement that is read rather than accumulated — CPU usage, queue depth, memory in use. Reported via an observable callback; only the latest value per collection interval matters.
Histogram. A distribution of values bucketed for percentile queries. OpenTelemetry supports explicit buckets and exponential buckets; the latter is more memory-efficient at high cardinality.
Exemplar. A trace ID attached to a metric data point so you can jump from a metric anomaly to a representative trace.
OTLP and transport
OTLP. The OpenTelemetry Protocol — the wire format used between SDKs, Collectors, and backends. Protobuf-encoded; carries spans, metric data points, and log records.
OTLP HTTP / OTLP gRPC. The two transport bindings for OTLP. HTTP uses HTTP/1.1 or HTTP/2 with protobuf or JSON bodies; gRPC uses HTTP/2 with native gRPC framing. See OTLP HTTP vs gRPC.
Endpoint. The URL or host:port the OTLP exporter sends to. Telemtra accepts https://ingest.telemtra.io for HTTP and ingest.telemtra.io:443 for gRPC.
Headers. HTTP headers added to OTLP requests, used for authentication. Telemtra expects x-api-key.
SDK and API
API vs SDK. The OpenTelemetry API is what application code uses (tracer.start_as_current_span, meter.create_counter). The SDK is the implementation that actually records, batches, and exports. Libraries depend on the API; applications depend on the SDK.
Tracer / Meter / Logger. The objects in the API that you use to record telemetry. Acquired by name from a TracerProvider, MeterProvider, or LoggerProvider.
Instrumentation scope. The name and version of the library that produced a piece of telemetry (for example opentelemetry.instrumentation.flask 0.47b0), attached to every span, metric, and log record so you can tell which instrumentation emitted what.
Auto-instrumentation. Library code that patches popular frameworks (Flask, Express, Spring) at import time so requests, queries, and outbound calls become spans without source changes.
Bridge. A glue library that connects a non-OTel system to OpenTelemetry — for example, the Micrometer-to-OTel bridge in Java or the slog bridge in Go.
Collector
OpenTelemetry Collector. A standalone binary that receives, processes, and exports telemetry. Decouples application code from backend-specific details.
Receiver. A Collector component that ingests telemetry. otlp is the most common; filelog, hostmetrics, kubeletstats, jaeger, and prometheus are also widely used.
Processor. A Collector component that transforms telemetry in flight. Common ones: batch, memory_limiter, k8sattributes, attributes, filter, tail_sampling.
Exporter. A Collector component that ships telemetry to a backend. otlphttp and otlp (gRPC) are the OTel-native exporters; backend-specific exporters exist too.
Pipeline. A defined chain of receivers → processors → exporters for a single signal type (traces, metrics, or logs).
Distribution. A build of the Collector that bundles a specific set of components. opentelemetry-collector-contrib is the wide one; opentelemetry-collector core is the minimal one.
Sampling and propagation
Sampler. A decision-maker that determines whether a span is recorded. AlwaysOn, AlwaysOff, TraceIdRatioBased, and ParentBased are the standard ones.
Head-based sampling. The sampling decision is made when the root span is created and inherited by all child spans. Cheap, predictable, but cannot make decisions based on what later happens in the trace.
Tail-based sampling. The sampling decision is made after all spans in a trace are collected (typically in a Collector with the tail_sampling processor). Lets you keep all error traces and a sample of successful ones.
Propagator. The format used to carry trace context across process boundaries. tracecontext (W3C) and baggage are the OTel defaults; b3 is the legacy Zipkin format; jaeger is the legacy Jaeger format.
Baggage. Key-value data that propagates with the trace context across processes. Useful for things like tenant ID or feature-flag identity that downstream services need to see.
Deployment patterns
Agent / sidecar Collector. A Collector running next to each app instance, used to offload batching and retry from the app.
Gateway Collector. A central Collector behind a Service or load balancer that receives from many agents and forwards to backends.
DaemonSet Collector. A Kubernetes-specific agent pattern: one Collector per node, collecting local pod logs and metrics.
Operator (OpenTelemetry Operator). A Kubernetes operator that manages Collector deployments via CRDs and can inject SDKs into application pods automatically.
If you found this useful, see What is OpenTelemetry? for a fuller introduction or the Collector quickstart for a working pipeline. Start a free Telemtra workspace to send your first span.