El tablero es verde y, sin embargo, los clientes se quejan de que el proceso de pago no funciona. Si ha estado en esta posición, ya comprende la diferencia entre monitoreo y observabilidad. Tu seguimiento sólo comprobó lo que pensabas comprobar, y este fallo es algo nuevo.

Esta guía explica ambas ideas sin el lenguaje de marketing y sigue un incidente ficticio desde la alerta hasta la causa raíz. Los registros, trazas y números se inventan para ilustrar el proceso. También debe saber que los proveedores y los profesionales trazan esta línea de manera diferente y algunos la consideran en parte una distinción de marketing. Nos centramos en la parte práctica.

La respuesta corta

El seguimiento es una actividad. Usted decide de antemano qué mirar, como CPU, tasa de error o espacio en disco, y establece umbrales que activan alertas. Responde: “¿Está sucediendo lo que me preocupaba?”

La observabilidad es una propiedad de su sistema. El término proviene de la teoría del control, donde describe qué tan bien se puede inferir el estado interno de un sistema a partir de sus resultados externos. En la práctica, responde: “¿Qué está pasando y por qué, incluso en el caso de problemas que nunca anticipé?”

Piensa en un coche. Las luces de advertencia en el tablero están monitoreando. Cubren un conjunto de problemas conocidos. El puerto de diagnóstico completo de un mecánico, que permite a alguien hacer nuevas preguntas sobre cualquier parte del motor, está más cerca de ser observable.

Monitoreo versus observabilidad lado a lado

Esta no es una elección entre los dos. Aún necesita alertas que le indiquen cuándo mirar.

Por qué el seguimiento por sí solo no es suficiente

Con una aplicación en un servidor, la lista de cosas que pueden salir mal es bastante corta, por lo que puedes verlas todas. Un sistema moderno puede tener docenas de servicios, colas y API de terceros, además de contenedores que van y vienen. Los fallos se convierten en combinaciones que nadie predijo: una región, un tipo de cliente, una versión específica de la aplicación y una única dependencia lenta.

No puedes escribir un panel de antemano para una pregunta en la que no has pensado. Necesitas datos que te permitan preguntarlo después.

Registros, métricas y seguimientos

Estos tres tipos de telemetría suelen denominarse los pilares de la observabilidad. Cada uno responde a una pregunta diferente:

Métricas

http_requests_total{service="checkout", status="500"} 1832
http_request_duration_seconds{service="checkout", quantile="0.95"} 2.4

Las métricas son económicas de almacenar y rápidas de consultar, lo que las hace ideales para paneles y alertas. Tenga cuidado con las etiquetas de alta cardinalidad, como una identificación de usuario, en muchos sistemas métricos, porque pueden aumentar drásticamente los costos.

Rastros

Un seguimiento sigue a una solicitud entre servicios. Cada paso es un lapso con una hora de inicio y una duración:

POST /checkout                      2410 ms
├─ auth-service: verify token         18 ms
├─ cart-service: load cart            42 ms
├─ pricing-service: calculate       2290 ms   <-- slow
│  └─ SELECT coupons ...            2265 ms
└─ payment-service: not reached

Un rastro hace evidente un paso lento, lo cual es muy difícil de ver en registros separados de servicios separados.

Registros

Los registros proporcionan el detalle de lo que sucedió en un momento dado. En un momento veremos cómo hacerlos útiles.

Un recorrido por el incidente

Así es como encajan las piezas, en un ejemplo ficticio.

El monitoreo manejó el paso 1. Todo lo posterior fue observabilidad. Observe cómo cada pregunta surgió de la respuesta anterior. Nadie podría haber creado un panel de control con anticipación para la “consulta de cupones de aplicaciones móviles de la campaña de hoy”. Para la solución en sí, nuestra guía para la optimización de consultas SQL muestra cómo leer ese tipo de plan.

Mejores registros

Los registros de texto sin formato están diseñados para el ojo humano y son difíciles de consultar. Los registros estructurados utilizan campos que una máquina puede filtrar:

# Hard to search
ERROR Payment failed for user 42 after 3 tries

# Easy to search
{"level":"error","event":"payment_failed","user_id":"42",
 "attempts":3,"provider":"acme","trace_id":"a1b2c3","duration_ms":2410}

Con el segundo formulario, puedes preguntar inmediatamente “¿cuántas fallas por proveedor en la última hora?” El campo trace_id es especialmente valioso, ya que vincula una línea de registro a toda la solicitud, en todos los servicios que toca.

Nunca registres contraseñas, tokens o números de tarjetas, y ten cuidado con los datos personales. Como explica nuestra guía, cualquier persona que los lea de un registro puede reutilizar los JWT.

Las señales doradas

¿No estás seguro de qué monitorear? El libro Site Reliability Engineering de Google sugiere cuatro señales para los sistemas orientados al usuario:

Utilice percentiles para la latencia, ya que los promedios ocultan solicitudes lentas, como mostramos en pruebas de carga frente a pruebas de estrés.

Alertas en las que la gente confía

Si las alertas se activan todo el tiempo, la gente deja de leerlas. Los buenos siguen algunas reglas:

• Alerta sobre los síntomas que sienten los usuarios. “Errores de pago superiores al 2%” supera a “CPU al 85%”. Una CPU alta que no daña a nadie no debería despertar a nadie.
• Haga que cada alerta sea procesable. Si nadie necesita hacer nada, conviértalo en un elemento del panel o elimínelo.
• Enlace a un runbook. Dígale al respondedor dónde buscar y qué probar.
• Revíselas periódicamente. Elimine o corrija cualquier alerta que se haya ignorado el mes pasado.

Objetivos de nivel de servicio

Un SLO convierte “el sitio debe ser rápido y confiable” en un objetivo mensurable, como “el 99,9% de las solicitudes de pago se realizan correctamente en 30 días”. Esto permite aproximadamente el 0,1 % de los fallos, lo que se conoce como presupuesto de errores. Si le queda suficiente, puede realizar envíos más rápido y, si está casi agotado, puede priorizar la confiabilidad. Es una forma útil de resolver las discusiones entre la velocidad de entrega y la estabilidad.

OpenTelemetría y herramientas

OpenTelemetry es un estándar de código abierto y neutral para el proveedor para generar y exportar telemetría. Es un proyecto de la Cloud Native Computing Foundation. Instrumentarlo significa que puedes cambiar tu backend más adelante sin tener que volver a escribir tu código. No es un producto de almacenamiento o tablero en sí, por lo que puedes combinarlo con uno:

Verifique usted mismo las características y los precios actuales, ya que estos productos cambian con frecuencia. Los costos pueden crecer rápidamente con el volumen de datos, así que utilice muestreo y establezca límites de retención.

Cómo empezar

1. Comience con las señales doradas para su servicio más importante.
2. Agregue una o dos alertas sobre los síntomas que notan los usuarios.
3. Cambiar a registros estructurados, con un ID de solicitud en cada línea.
4. Agregue seguimiento a su recorrido de usuario principal con OpenTelemetry, ya que la instrumentación automática puede cubrir muchos marcos comunes.
5. Vincula las implementaciones a tus gráficos, para que puedas ver si una versión de tu canal de CI/CD provocó un cambio.
6. Aprenda de cada incidente. Después de cada uno, pregunte qué datos habrían agilizado su resolución y agréguelos.

Un equipo pequeño con un solo servicio no necesita una plataforma enorme. Las métricas básicas, buenos registros y algunas alertas pueden ser suficientes. El rastreo se gana la vida a medida que crece el número de servicios.

Errores comunes

• Comprar una herramienta y llamarla observabilidad. El valor proviene de una buena instrumentación y de cómo se utilizan los datos.
• Tratar tres pilares como una lista de verificación. Los datos separados sin forma de vincularlos te deja buscando entre pestañas. Las identificaciones compartidas son importantes.
• Recopilar todo. La telemetría sin filtrar se vuelve costosa y agrega ruido.
• Demasiados paneles. Algunas vistas confiables superan a cien que nadie abre.
• Pensando que reemplaza las pruebas. Aún necesitas pruebas antes del lanzamiento. Sin embargo, los lanzamientos de Canarias combinan bien con estas señales.

Conclusión

El monitoreo le indica que algo salió mal y la observabilidad le brinda los medios para descubrir por qué. La prueba práctica es simple: cuando aparece un problema desconocido, ¿puedes encontrar la causa sin enviar un código nuevo? La próxima vez que tenga un incidente, escriba todas las preguntas que no pudo responder. Esa lista es su hoja de ruta.

Preguntas frecuentes

sigue aprendiendo