Tema: monitoring
-
Vigilar la caducidad de certificados TLS en todos los endpoints, no solo en el sitio web principal
Un certificado caducado es una interrupción con un momento exactamente predecible; sondear la fecha notAfter de cada certificado realmente servido (web, API, correo, paneles internos, balanceadores de carga) desde el exterior, alertar con antelación suficiente para renovar a mano, y comprobar los intermedios además del certificado hoja.
-
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.
-
Las comprobaciones de frescura y de número de filas en las tablas de origen en bruto detectan la mayoría de los incidentes de un pipeline antes que las pruebas a nivel de columna aguas abajo
Hipótesis: en un almacén de datos con modelos por capas, la mayoría de los incidentes que terminan siendo visibles para quienes consumen los informes se manifiestan primero como una carga de origen en bruto obsoleta o de tamaño insuficiente, de modo que las comprobaciones de frescura y de volumen en la capa de origen los detectan antes que las pruebas de no nulo, unicidad y valores aceptados sobre los modelos aguas abajo; se propone una comparación sobre incidentes registrados.
-
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.
-
Comprobaciones de calidad de datos: actualidad, volumen, nulos y unicidad como conjunto mínimo de pruebas
Cuatro comprobaciones económicas detectan la mayoría de las cargas rotas: la fuente se actualizó con suficiente frecuencia (actualidad), el intervalo entregó un número plausible de filas (volumen), las claves y las medidas obligatorias no son nulas, y la granularidad declarada es única. Expresar cada una como una consulta que devuelve las filas que fallan, ejecutarla después de cargar y antes de publicar, y separar las advertencias de los errores bloqueantes.
-
¿Cuántas ubicaciones de sondeo externas y qué umbral de fallo hacen fiables las alertas de disponibilidad de un sitio pequeño?
Pregunta abierta: una única ubicación de sondeo genera alertas por los propios problemas de red del sondeo, mientras que exigir acuerdo entre muchas ubicaciones retrasa las alertas reales; para un sitio pequeño con un único origen, ¿qué combinación de ubicaciones, intervalos y reglas de confirmación ha mantenido bajas las falsas alarmas sin dejar de detectar interrupciones reales, y cómo se contabilizaron ambos tipos?
-
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.
-
Comprobación del estado de NFS, Samba, chrony, Unbound y Kea desde la línea de comandos: lista de verificación
Un repaso de cinco minutos por línea de comandos para confirmar que cada servicio de infraestructura funciona y responde bien: rpcinfo -p y showmount -e para NFSv3 (exportfs -v y sockets conectados en un servidor solo NFSv4), smbstatus para Samba, chronyc tracking y chronyc clients para la hora, unbound-control status para el resolvedor y el archivo de concesiones de Kea o kea-shell para DHCP.
-
SNMPv3 en Linux con net-snmp: usuario SHA/AES con nivel de seguridad priv y community strings retiradas
El demonio snmpd de net-snmp admite el modelo de seguridad USM de SNMPv3, con autenticación y cifrado por usuario, que se configura con createUser y se exige con el nivel de seguridad priv en rouser/rwuser. Eliminar todas las líneas rocommunity/rwcommunity y cualquier asignación com2sec cierra la vía de community strings en texto plano de SNMPv1/v2c que USM está pensado para sustituir.
-
Monitorización de un modelo desplegado para detectar deriva: entradas, salidas y etiquetas tardías
La puntuación offline de un modelo deja de ser válida cuando cambia la distribución de las entradas, la de las etiquetas o la relación entre ambas. Para detectarlo, compara las distribuciones de características y predicciones con una referencia de entrenamiento, registra las características servidas para detectar el sesgo entre entrenamiento y servicio, y une las etiquetas tardías para calcular la métrica real con retraso.
-
Vigilar la salud del disco con smartctl, nvme smart-log y autopruebas programadas con smartd
smartctl -H da un veredicto rápido de salud (correcto o fallo) y -a la tabla completa de atributos SMART en unidades ATA/SCSI; nvme smart-log hace lo equivalente en dispositivos NVMe, y smartd.conf programa autopruebas periódicas y alertas por correo para que un disco defectuoso se notifique en lugar de descubrirse tras perder datos.
-
¿Qué métrica de memoria deben usar las alertas y los autoscalers en un servicio en contenedores: RSS, PSS, working set o memory.current de cgroup?
Pregunta abierta: el RSS de un proceso cuenta las páginas compartidas en cada proceso, memory.current de cgroup incluye la page cache y la memoria del kernel, y Kubernetes informa un working set heurístico. ¿Cuál se ha usado como señal de alerta y escalado en un servicio de larga duración sin generar avisos por cache recuperable ni pasar por alto la cercanía al límite de OOM?
-
Comprobar la sincronización horaria de los servidores: timedatectl, chronyc tracking y qué alertas configurar
La deriva del reloj rompe sin avisar la validación de certificados, la caducidad de tokens, la correlación de logs y los arrendamientos de bloqueos. En cada host, comprueba que haya un servicio de hora activo y sincronizado, lee el offset, el stratum y el estado de leap desde el demonio, alerta cuando no esté sincronizado o el offset supere un límite definido localmente, y repite la comprobación tras reinicios y reconstrucciones de imagen.
-
Comprobación del estado del host antes y después de un cambio, ejecutable por un agente en Linux y Windows
Antes y después de cualquier cambio en un servidor en ejecución, un agente puede capturar en ambos sistemas operativos la misma instantánea de cuatro puntos (servicios fallidos o detenidos, puertos en escucha, margen de disco y memoria, y errores recientes en los registros) y compararlas para ver exactamente qué ha alterado el cambio, con independencia de lo que este debía hacer.
-
Las alertas con enlace a un runbook se reconocen antes y se silencian menos que las alertas sin él
Hipótesis: según la documentación de Prometheus, las reglas de alerta admiten anotaciones como descripciones o enlaces a runbooks. Se propone que, dentro del mismo equipo y del mismo periodo, los avisos de reglas con un enlace a runbook funcional se reconocen y resuelven antes, y se silencian o desactivan con menos frecuencia que los de reglas sin él.
-
Submuestreo y niveles de retención para datos de series temporales
Conserva las muestras en bruto durante un periodo corto, agrégalas en intervalos fijos con count, sum, min y max para un periodo más largo y elimina por partición cuando caduque un nivel; elige agregados que puedan volver a agregarse, alinea los intervalos a un origen fijo y ejecuta la agregación solo cuando hayan llegado los datos tardíos del intervalo.
Legible por máquina: JSON