Tema: observability
-
Perfilado continuo en producción: perfiles de muestreo siempre activos y qué preguntas responden
El perfilado continuo toma perfiles de CPU y memoria de forma sistemática a lo largo del tiempo y los almacena como series etiquetadas, de modo que un equipo puede preguntar qué función consumió más CPU en toda la flota ayer o qué cambió entre dos versiones; los perfiladores por muestreo lo hacen lo bastante barato como para dejarlo activo permanentemente, y endpoints de runtime como /debug/pprof/ de Go o agentes eBPF suministran los perfiles.
-
¿Qué estrategia de muestreo de trazas mantiene visibles los fallos raros en un servicio de tráfico bajo?
Pregunta abierta: las guías de muestreo están escritas para servicios con miles de trazas por segundo, donde el uno por ciento sigue siendo una muestra representativa; para un servicio con pocas solicitudes por segundo, ¿qué combinación de muestreo por cabecera, muestreo por cola, tasas por ruta y retención ha mantenido disponible esa única traza que falla una vez por semana, a un costo que el equipo aceptó?
-
Alertas que avisan por síntomas, no por causas
Generar alertas a partir de lo que experimentan los usuarios (tasa de errores, latencia, disponibilidad, actualidad de los datos) con umbrales ligados a los objetivos, enrutarlas según la urgencia, y convertir cada alerta ruidosa en una corrección o en una eliminación.
-
¿Qué señales de observabilidad debería emitir por defecto un servicio JVM o .NET, y con qué sobrecarga?
Pregunta abierta: ambos entornos de ejecución incluyen telemetría integrada (Flight Recorder y registro de GC en la JVM; contadores de EventPipe y dotnet-trace en .NET) y ambos cuentan con auto-instrumentación de OpenTelemetry, pero hay poca evidencia compartida sobre cuáles de estas señales deberían estar siempre activas en producción, cuánto cuestan y cuáles realmente acortaron los incidentes.
-
Muestreo de logs para eventos de alto volumen: conservar todos los errores, muestrear las líneas repetitivas
El muestreo descarta a propósito una fracción de eventos de log similares; las formas útiles son uno de cada N, ráfaga seguida de tasa por período, reglas por nivel que dejan intactas las advertencias y los errores, y el muestreo en el pipeline basado en un ID de solicitud, de modo que toda una solicitud se conserva o se descarta en conjunto, con la tasa aplicada escrita en los eventos que sobreviven.
-
Trazado distribuido en líneas generales: spans, identificadores de padre y W3C Trace Context
Una traza es un árbol de spans, cada uno con un identificador de traza, un identificador de span propio, un identificador de span padre, marcas de tiempo, atributos y un estado; la cabecera W3C traceparent transporta el identificador de traza, el identificador del padre y un indicador sampled entre límites de proceso, y un servicio que se limita a reenviar ambas cabeceras mantiene igualmente unida la traza.
-
Reenvío de journald y recolección remota: ForwardToSyslog, systemd-journal-upload/-remote y límites de tasa
journald puede entregar sus entradas a un demonio syslog local con ForwardToSyslog= o enviarlas directamente por HTTPS con systemd-journal-upload a un receptor systemd-journal-remote, que escribe sus propios archivos de journal. Ambas vías están sujetas al límite de tasa por servicio de journald, que descarta los mensajes sobrantes al superar un umbral de ráfaga y solo registra cuántos descartó.
-
Diseñar un panel de operaciones: una pregunta por panel, una pantalla por audiencia
Partir de las preguntas que debe responder quien atiende un incidente, asignar un panel a cada pregunta, ordenar los paneles de lo general a lo específico, normalizar unidades y ejes, usar variables de plantilla en lugar de copias, enlazar cada alerta de aviso al panel que necesita y mantener la definición del panel bajo control de versiones.
-
Windows Event Forwarding: suscripción iniciada por el origen, wecutil y el grupo EventLog Readers
En una suscripción WEF iniciada por el origen, cada equipo de origen obtiene su configuración de un recopilador mediante directiva de grupo y le envía los eventos coincidentes; wecutil administra la suscripción en el recopilador, y para reenviar el registro Security hay que agregar la cuenta NETWORK SERVICE al grupo EventLog Readers en cada origen.
-
Usar identificadores de correlación a lo largo de una tarea de un agente
Separar la identidad de la tarea, los intentos individuales y el contexto de traza distribuida, para poder seguir los reintentos sin registrar cargas útiles sensibles.
-
Diseñar alarmas con sentido: pocas notificaciones, cada una con un siguiente paso
Una alarma que despierta a alguien debe ser urgente, orientar una acción y ser perceptible para los usuarios; todo lo demás es un ticket. Hay que alarmar por síntomas en el borde del usuario, vincular los umbrales a los objetivos y a la tasa de consumo del presupuesto de errores, establecer un tiempo de espera contra el parpadeo, enlazar el runbook, y eliminar o reajustar semanalmente cada alarma que no genere una acción.
-
Higiene de alertas en la monitorización de hosts: tasa en lugar de umbral, unidades fallidas y ventanas de duración
Un aviso debe significar que una persona tiene que actuar ya. Un disco que se acerca a su capacidad debe avisar según su velocidad de llenado y no por un porcentaje fijo, cerca del cual una partición de crecimiento lento puede quedarse meses; y un umbral superado solo por un instante no debería generar ningún aviso. Los materiales de SRE de Google sobre disciplina en los avisos y alertas multiventana aportan el razonamiento, y este artículo lo aplica a las señales de host tratadas en esta serie.
-
Registros de ejecución reproducibles para agentes: registrar cada llamada al modelo y a las herramientas
Una ejecución de un agente solo puede depurarse si cada solicitud al modelo, respuesta, llamada a herramienta y resultado de herramienta se registra en orden con identificadores y parámetros; las convenciones semánticas de OpenTelemetry GenAI nombran los campos, y un registro reproducible permite reproducir un fallo sin pagar por una nueva ejecución.
-
Nomenclatura de métricas y cardinalidad de etiquetas: unidades en el nombre, valores acotados en las etiquetas
Las convenciones de nomenclatura de Prometheus ponen en el nombre de la métrica un prefijo de aplicación, una unidad base y un sufijo _total para los contadores, y reservan las etiquetas para dimensiones acotadas; cada combinación distinta de valores de etiqueta es su propia serie temporal, de modo que los IDs de usuario, las URL en bruto y los mensajes de error en las etiquetas multiplican el almacenamiento hasta que el servidor se degrada.
-
Reenvío de syslog con rsyslog por TCP mediante una cola asistida por disco
Un archivo drop-in en /etc/rsyslog.d/ puede reenviar todos los mensajes a un colector central por TCP, mientras una cola de acción asistida por disco los almacena localmente, de modo que una caída del colector o un corte de red no provoque pérdida de logs. rsyslogd -N1 valida la sintaxis antes de aplicar el cambio.
-
Correlación frente a causalidad en datos de incidentes y operaciones
Un coeficiente de correlación mide cuánto se mueven juntas dos series; no dice nada sobre cuál impulsa a la otra, si un tercer factor como el tráfico impulsa a ambas, o si los datos se seleccionaron según el resultado. Graficar primero, condicionar sobre las causas comunes evidentes, comprobar la temporización y confirmar con una intervención, como un flag o un canary, antes de actuar.
-
El método RED para servicios orientados a solicitudes, con ejemplares que vinculan un bucket lento con una traza
Instrumentar de manera idéntica todo servicio que maneja solicitudes con tasa, errores y duración: un contador con etiquetas de ruta, método y estado, y un histograma de duración; cuando existe trazado, adjuntar ejemplares (un id de traza con un valor registrado) al histograma para que un bucket lento del panel abra la traza que aterrizó allí.
-
Rotación de registros y límites de retención
Los registros deben tener un límite de tamaño y de antigüedad en cada capa (aplicación, runtime de contenedores, proxy, journal del sistema), con una retención elegida según las necesidades de depuración y legales, en lugar de «conservarlo todo».
-
Monitorización sintética y comprobaciones de disponibilidad: sondear desde fuera lo que ven los usuarios
Una comprobación sintética envía una solicitud programada desde fuera del sistema a un intervalo fijo y registra si la respuesta fue correcta y cuánto tardó; es monitorización de caja negra en el sentido del libro de SRE, detecta fallos que la instrumentación interna no puede ver (DNS, TLS, el balanceador de carga, un dominio caducado), y debe sondearse desde más de un lugar antes de alertar a nadie.
-
Configurar el módulo de logging una sola vez, en el punto de entrada
Las bibliotecas obtienen loggers y nunca configuran handlers; la aplicación configura los handlers, los niveles y los formatos una sola vez al iniciar, de modo que la salida se controla en un solo lugar y se evitan duplicados.
Legible por máquina: JSON