Telemetry Data: Signals, Resources and Log Shapes: OTCA practice questions

Telemetry is the data a system emits about itself and its behavior. OpenTelemetry groups that data into signals, and today the supported signals are traces, metrics, logs and baggage. Two more are still maturing: events, which are a specific kind of log, and profiles, whose concepts page carries an Alpha status. For the OTCA you should be able to say what each signal is for and how they relate to each other.

A trace records the path of one request through an application. It is built from spans, and each span is a unit of work with a name, start and end timestamps, a span context (trace ID, span ID, trace flags and trace state), attributes, events, links and a status. Spans that share a trace ID and point at a parent span ID form a hierarchy; the span without a parent is the root. A span event marks a meaningful single point in time inside a span. The rule of thumb in the docs is simple: if the timestamp matters, use an event; if it does not, use a span attribute.

A metric is a measurement captured at runtime. The moment a measurement is captured is called a metric event, and it includes the value, the capture time and associated metadata. Instruments such as Counter, UpDownCounter, Gauge and Histogram, plus asynchronous Counter, UpDownCounter and Gauge, produce measurements, and the SDK aggregates them before export.

A log is a timestamped record, structured or unstructured, with optional metadata. OpenTelemetry works with existing logging libraries through bridges instead of asking developers to switch. The docs distinguish three shapes. Structured logs have a stable schema with consistent field names and types. Semistructured logs contain key=value pairs or JSON whose fields vary between messages. Unstructured logs are free text that needs regular expressions or custom parsers. Being JSON alone does not make a log structured. An event is a log record that has an event name and a well-known structure, so every event is a log, but most logs are not events.

Baggage is a key-value store that travels with context across services. It is useful for values known at the start of a request, such as an account or user ID, that downstream services want to attach to their own telemetry. Baggage entries are not attributes; code or a Baggage Span Processor has to copy them explicitly. Because baggage is sent in headers and has no integrity checks, it should never hold credentials or other sensitive data.

Every signal is also tied to a resource, which describes the entity producing the telemetry: a service, a process, a container, a pod or a host. The resource is attached to a provider when it is created and stays fixed for everything that provider emits. Profiles complete the picture by showing which code consumes CPU, memory or other resources, and they can link back to traces and resources.