Registros, métricas, seguimientos y eventos estructurados
Las señales de observabilidad se superponen, pero no son intercambiables. Elegir la señal más pequeña que responda a la pregunta mantiene la instrumentación comprensible y los costos bajo control.
Para qué es buena cada señal
Los registros de texto preservan el contexto de diagnóstico detallado para un proceso y un momento determinados. Son útiles para excepciones, ramas inusuales y mensajes de ciclo de vida legibles por humanos.
Métricas resumen una medición numérica a lo largo del tiempo. Los contadores, indicadores e histogramas son eficientes para las tendencias de tasas, saturación y latencia de todo el servicio, pero descartan intencionalmente el contexto a nivel de fila.
Los rastros conectan tramos a lo largo de una ruta de solicitud. Muestran qué servicio o dependencia consumió tiempo y son valiosos cuando una operación cruza múltiples sistemas.
Los eventos estructurados describen hechos comerciales o de aplicaciones completados como filas consultables. Funcionan bien para resultados laborales, entregas de webhooks, solicitudes de LLM, hitos de activación y errores que afectan al cliente donde SQL debe agruparse por cuenta, función, modelo, ruta o versión.
Empezar desde la investigación
Para "¿el servicio no está en buen estado?", una métrica y una alerta pueden ser suficientes. Para "¿dónde pasó el tiempo esta solicitud?", utilice un seguimiento. Para "¿qué falló exactamente en este proceso?", inspeccione los registros. Para "¿qué cuentas encontraron sincronizaciones fallidas después del lanzamiento?", consulte eventos estructurados.
Puede conectar señales sin copiar todos los atributos en todas partes. Coloque un request_id o trace_id seguro en el registro estructurado de eventos y diagnóstico. Mantenga la salud del servicio de baja cardinalidad en las métricas. Almacene el tiempo específico del intervalo en el seguimiento. Esto crea caminos entre sistemas preservando al mismo tiempo el propósito de cada uno.
Donde encaja Telemetry
Telemetry está diseñado alrededor de tablas de eventos estructuradas y SQL. Complementa, en lugar de reemplazar, las métricas de infraestructura o el seguimiento distribuido. Emita un evento en el límite donde un flujo de trabajo tiene un resultado útil y luego consulte esa tabla para obtener tasas, percentiles, cohortes y ejemplos recientes.
Por ejemplo, un rastro puede explicar por qué un pago tardó cuatro segundos. Un evento checkout_completed puede mostrar si la versión v2 aumentó la latencia p95 o los errores de pago en todos los clientes.
Antes de agregar identificadores, revise campos de alta cardinalidad y ID de correlación. Para conocer los patrones de implementación, comience con el guía de registro estructurado.