OpenTelemetry Instrumentation and Collection
What the exam tests
OpenTelemetry Instrumentation and Collection tests the API/SDK split, auto- and manual instrumentation, resources and semantic conventions, context propagation, and Collector pipeline design.
Core rules
- The OpenTelemetry API is stable and safe to call without an SDK; it becomes a no-op. The SDK provides TracerProvider, MeterProvider, and LoggerProvider plus exporters and samplers.
- Auto-instrumentation covers common libraries and frameworks; manual instrumentation adds business spans, attributes, and events. Use both.
- Resources describe the emitting entity, at minimum service.name. Set them with OTEL_RESOURCE_ATTRIBUTES or SDK resource detectors.
- Semantic conventions standardize names such as http.request.method and http.response.status_code. Stable conventions beat custom names.
- OTLP is the native protocol, commonly gRPC on 4317 and HTTP on 4318. The Collector has receivers, processors, and exporters wired into service pipelines.
- The Collector can run as an agent near workloads or as a gateway for central processing. Processors include memory_limiter, batch, attributes, filter, probabilistic_sampler, and tail_sampling.
Worked example
A team wants only error traces and traces slower than 500 ms. Configure an OTLP receiver, then memory_limiter, then tail_sampling with policies status_code = ERROR and latency > 500 ms, then batch, then an OTLP exporter. Set decision_wait around 30 seconds and size num_traces for peak volume. Because tail sampling needs every span of a trace, route by trace ID to the same Collector instance using a load-balancing exporter or a gateway tier. A round-robin load balancer will split traces and break decisions.
Traps
Calling the API without registering an SDK produces no telemetry. Omitting service.name makes data hard to attribute. Tail sampling before trace-affinity routing drops or splits traces. High-cardinality span attributes inflate cost. Sampling before propagation decisions can hide errors.