Práctica: Correlacionar las cuatro señales de dos servicios auto-instrumentados

Lo que vas a aprender en este TP

• Auto-instrumentar todas las señales
• Garantizar un recurso común
• Navegar entre las señales

Introducción #

Lo que vas a aprender en esta sección

• Auto-instrumentar todas las señales
• Garantizar un recurso común
• Navegar entre las señales

Contexto. Una tienda de dos servicios devuelve errores de forma intermitente. Instrumentas sin tocar el código e investigas navegando de una señal a otra.

Requisitos previos: Docker y Python 3.10 o superior; la pila grafana/otel-lgtm (Collector, Tempo, Loki, Prometheus, Pyroscope y Grafana en un solo contenedor)  ·  Duración estimada: 50 min

Una causa encontrada en unos clics gracias a un recurso común y a los identificadores compartidos.

Puesta en práctica #

Pasos guiados, con su corrección.

1. 1. Arrancar la pila de observabilidad

   ¿Por qué? Una sola imagen proporciona un Collector OTLP y todos los backends: nos centramos en la señal.

   Lanza grafana/otel-lgtm, crea un entorno Python y apunta los exportadores al puerto OTLP/HTTP 4318.

2. 2. Escribir los dos servicios

   ¿Por qué? El código no contiene ninguna línea de OpenTelemetry: todo vendrá de la auto-instrumentación.

   Crea front.py (puerto 8001) que llame a stock.py (puerto 8002); el servicio de stock falla en el 15 % de las peticiones con un log de error.

3. 3. Arrancar con un recurso común

   ¿Por qué? Las mismas variables para las tres señales garantizan el mismo recurso: es la clave de la correlación.

   Lanza cada servicio con opentelemetry-instrument, los tres exportadores OTLP, la captura de logs y atributos de recurso comunes, y genera tráfico.

4. 4. Partir de la métrica

   ¿Por qué? La investigación empieza como una alerta: una métrica de errores procedente de las convenciones HTTP, idéntica para todos los servicios.

   En Prometheus, calcula la tasa de errores 5xx por servicio a partir del histograma http.server.request.duration (o su equivalente según la versión de instrumentación). Activa los exemplars y abre una traza desde un punto.

5. 5. De la traza a los logs

   ¿Por qué? La traza muestra qué servicio ha fallado; sus logs dicen por qué.

   En Tempo, busca las trazas con error, abre una, comprueba que el span servidor de stock está en 503 y usa Logs for this span para encontrar el mensaje «pool de conexiones agotado». Haz el camino inverso desde Loki.

6. 6. Mapa de servicios y métricas de spans

   ¿Por qué? Las métricas calculadas a partir de los spans dan ritmo, errores y duración por servicio y un mapa de dependencias.

   Abre la pestaña Service Graph de Tempo en Explore: comprueba la arista de front hacia stock y su tasa de error. Anota la línea de configuración (conector servicegraph o generador de métricas de Tempo) que lo hace posible.

7. 7. Romper y reparar la correlación

   ¿Por qué? Un recurso diferente basta para romper todos los enlaces: se comprueba para recordarlo.

   Reinicia stock con OTEL_LOGS_EXPORTER=none, genera tráfico de nuevo y comprueba que Logs for this span ya no devuelve nada. Restablece la configuración y detén todo.

Nivel de dificultad : ●●●○○ (3/5)