Linux Foundation OpenTelemetry Certified Associate

Telemetry is only useful when different services describe things the same way. You learn semantic conventions, resource attributes that identify a service, and how consistent names make queries across teams possible.

• What semantic conventions define
• Resource attributes: service name, version and environment
• Attributes for HTTP, databases and messaging
• Naming your own attributes
• Schemas and convention changes over time
• Auditing a service’s attributes

You build An attribute standard for an organization, with a checked example from one service.

OpenTelemetry separates the API that code calls from the SDK that does the work. You learn that split, the data model behind each signal, and how providers, processors and exporters form the SDK pipeline.

• API and SDK: why they are separate
• The data model for each signal
• Providers and the global instance
• Processors, readers and exporters
• OTLP over gRPC and HTTP
• Writing library code that depends only on the API

You build A small program wired by hand with a provider, a processor and an OTLP exporter.

A trace tells the story of one request. You create spans by hand, add attributes, events and status, relate spans with links, and use sampling to keep tracing affordable.

• Traces and spans
• Span kinds, attributes, events and status
• Creating and nesting spans in code
• Links and asynchronous work
• Head sampling and its limits
• Recording errors and exceptions

You build A service with hand-written spans for a request path, sampled and viewed in a trace UI.

Traces span processes only if context travels with each request. You study how trace context and baggage cross HTTP and messaging boundaries, and how broken propagation shows up as fragmented traces.

• Context objects and how they flow in a process
• W3C Trace Context headers
• Baggage and what not to put in it
• Propagators for HTTP and messaging
• Async boundaries and lost context
• Diagnosing a fragmented trace

You build Two services whose requests produce one connected trace, plus a deliberately broken variant and its fix.

Metrics and logs complete the picture. You choose metric instruments, understand aggregation and temporality, bridge existing logging libraries, and connect logs to the traces that produced them.

• Counters, up-down counters, gauges and histograms
• Choosing the right instrument
• Aggregation, temporality and views
• The logs bridge and existing logging libraries
• Correlating logs with trace and span identifiers
• Controlling metric cardinality

You build A service that emits request metrics and trace-correlated logs through the same pipeline.

Many libraries can be instrumented without touching code. You attach agents and auto-instrumentation, configure them with environment variables, and decide where manual spans still add value.

• Zero-code instrumentation and how it works
• Language agents and auto-instrumentation libraries
• Configuring through environment variables
• What auto-instrumentation misses
• Mixing automatic and manual spans
• Overhead and compatibility

You build An existing application instrumented with no code changes, then extended with a few manual spans.

The SDK is configurable and extensible. You configure exporters, samplers, batching and resource detection, and write your own component where the defaults fall short.

• Environment variables and configuration files
• Samplers and their settings
• Batching and export timeouts
• Resource detectors
• Writing a custom processor or exporter
• Testing telemetry in unit tests

You build An SDK configuration with a custom span processor that redacts sensitive attributes.

The Collector receives telemetry, changes it and sends it on. You write its configuration, build pipelines per signal, use connectors and extensions, and transform data in flight.

• Collector architecture and distributions
• Receivers for OTLP and other formats
• Processors: batch, memory limiter, attributes, filter
• Exporters and fan-out to several backends
• Connectors and extensions
• Transforming and redacting data with the transform processor

You build A Collector configuration with separate pipelines that enrich, filter and export all three signals.

Where the Collector runs decides how it behaves under load. You compare agent and gateway deployments, run it on Kubernetes, and add queues, retries and load balancing so that data survives a spike.

• Agent, gateway and sidecar patterns
• Running the Collector on Kubernetes
• Sizing and memory limits
• Queues, retries and back pressure
• Load balancing by trace for tail sampling
• Upgrading the Collector safely

You build A two-tier Collector deployment with an agent per node and a scaled gateway, load tested.

Telemetry pipelines fail quietly. You use the Collector’s own telemetry and debugging tools to find dropped data, fix broken context, handle errors, and manage schema changes without losing continuity.

• The Collector’s internal metrics and logs
• The debug exporter and inspecting data in flight
• Finding dropped spans and metrics
• Error handling, retries and dead ends
• Schema changes and migrating conventions
• A checklist for a pipeline that has gone quiet

You build A runbook for diagnosing missing telemetry, tested against three injected faults.

Instrument a small system of several services, route its telemetry through a Collector, and use the result to find a planted performance fault. You document the conventions so that other teams can follow them.

• Planning signals and conventions
• Instrumenting services automatically and by hand
• Routing and processing through a Collector
• Finding a fault from traces, metrics and logs
• Documenting the setup for other teams

You build An instrumented multi-service application with a Collector pipeline and a written fault investigation.