Hands on with OpenTelemetry

In a microservice world, no one understands the full map. Learn how OpenTelemetry connects the dots, providing a standard for observing your entire system.

#1about 3 minutes

Defining observability as time to understanding

Observability is defined as the time it takes to understand a problem, which is crucial for reducing stress and resolving issues effectively.

#2about 4 minutes

Why modern microservice architectures are harder to observe

The shift from monolithic systems to complex microservice environments has made it more difficult to have a complete understanding of system behavior.

#3about 3 minutes

Introducing OpenTelemetry and its collector architecture

OpenTelemetry provides an open standard and tools, centered around a collector, to gather and process telemetry data from various services.

#4about 9 minutes

The three core signals: metrics, logs, and traces

An overview of the three pillars of observability, explaining how metrics provide high-level views, logs offer detailed events, and traces show request flows.

#5about 5 minutes

Managing the challenges of high cardinality data

High cardinality data, such as including user IDs in metric names, can explode storage costs and make it difficult to identify meaningful patterns.

#6about 4 minutes

Filtering telemetry data without changing application code

The OpenTelemetry collector allows for filtering sensitive or noisy data without requiring modifications to the application's source code.

#7about 5 minutes

Understanding the collector's processing pipeline

The collector uses a pipeline of receivers, processors, and exporters to ingest, transform, and send telemetry data to various backends.

#8about 3 minutes

How distributed tracing and baggage work together

Distributed tracing connects spans across services using propagated headers, and baggage allows for passing additional business context along with the request.

#9about 6 minutes

Understanding the scope of the OpenTelemetry project

OpenTelemetry focuses on data generation and collection, intentionally not providing data storage, dashboards, notifications, or synthetic monitoring.

#10about 1 minute

Customizing the collector's behavior with YAML configuration

The collector's YAML configuration file is used to define pipelines for filtering data, normalizing labels, and routing telemetry to different destinations.

#11about 3 minutes

Best practices for sending logs through the collector

When sending logs, consider managing log levels, routing logs to different backends, and decorating them with trace IDs for better correlation.

#12about 2 minutes

Discussing the downsides of OpenTelemetry

Potential downsides include varying quality of automatic instrumentation and vendor support, with features like the transform language (OTTL) still maturing.

#13about 5 minutes

Integrating OpenTelemetry with other monitoring tools

The collector can ingest data from various sources, but it is important to verify how well downstream tools actually support and display OpenTelemetry data.