Logging central que aguanta una revisión de incidente

La verdadera prueba del logging central no es si los mensajes llegan en una tarde tranquila. Es si, la mañana después de que algo haya ido mal, puede montar en pocos minutos una línea de tiempo completa y correctamente ordenada entre routers, firewalls, storage y servidores. Eso requiere un pipeline construido para ello. Así construimos el nuestro en Graylog, y esto es lo que puede copiar para el suyo.

Empiece por la pregunta que va a hacer

Cada decisión de diseño en un pipeline de logging debe servir a una pregunta: «¿qué pasó, en todas partes, entre estos dos instantes?». Esa pregunta falla de cuatro maneras predecibles. Faltan mensajes de parte de la ventana. El mismo dispositivo aparece con varios nombres, así que una búsqueda encuentra solo parte de su historial. Los relojes discrepan, así que los eventos caen en el orden equivocado. O todo está en un único montón indiferenciado, así que las líneas importantes quedan enterradas. Cada sección de abajo elimina uno de esos fallos.

Reenvíe de forma fiable, y guarde en disco

El syslog clásico sobre UDP es disparar y olvidar: el emisor nunca sabe si algo recibió el mensaje. Para servidores preferimos el reenvío por TCP con una cola asistida por disco, de modo que un reinicio del colector o un parpadeo de la red retrase los logs en lugar de perderlos. Una acción mínima de rsyslog:

action(type="omfwd" target="" port="514" protocol="tcp"
       template="RSYSLOG_SyslogProtocol23Format"
       queue.type="LinkedList" queue.filename="fwd_central"
       queue.maxDiskSpace="1g" queue.saveOnShutdown="on"
       action.resumeRetryCount="-1")

La plantilla envía mensajes estructurados RFC 5424 con marca de tiempo completa y nombre de host. La cola conserva en disco los mensajes no entregados y reintenta hasta que el colector vuelve. Valide con rsyslogd -N1 antes de reiniciar el servicio.

Los dispositivos de red suelen estar limitados a syslog plano, así que para ellos la protección es distinta: envíe al colector desde una dirección de origen y una instancia de enrutamiento que siempre puedan alcanzarlo, y compruebe esa ruta cada vez que cambie el enrutamiento del dispositivo.

Dé a cada dispositivo exactamente un nombre

Los fabricantes no se ponen de acuerdo sobre qué va en una cabecera syslog. Algunos dispositivos omiten su propio nombre de host, otros envían un nombre corto, otros envían una dirección, y el mismo dispositivo puede cambiar de formato tras una actualización de software. Si el colector almacena lo que llega, un router acaba repartido entre tres nombres de origen, y una búsqueda sobre él devuelve un tercio de su historial.

Nosotros lo arreglamos en la entrada. Una regla de pipeline de Graylog reescribe el origen de cada mensaje a un único nombre canónico de dispositivo, usando una tabla de consulta indexada por la dirección emisora:

rule "normalise source name"
when
  has_field("gl2_remote_ip")
then
  let name = lookup_value("device_names", to_string($message.gl2_remote_ip));
  set_field("source", name);
end

Mantenga la tabla de consulta al día con su inventario, de modo que un dispositivo nuevo reciba su nombre limpio el día en que se registra, no el día en que alguien nota que falta.

Ponga los relojes en hora

Cada dispositivo debería registrar en UTC o llevar un desplazamiento explícito. Mezclar hora local y UTC entre dispositivos es la manera clásica de hacer que un incidente parezca ocurrir en el orden equivocado. Dos comprobaciones rápidas en un host Linux:

chronyc tracking      # offset from the reference, should be tiny
timedatectl           # time zone and whether NTP is synchronised

En el equipamiento de red, compruebe el comando de estado equivalente y asegúrese de que la marca de tiempo del logging incluye la fecha, los milisegundos y la zona horaria. Los segundos no bastan cuando dos routers reaccionan al mismo evento.

Enrute los mensajes a streams por rol

Una sola manguera es ilegible. Nosotros enrutamos los mensajes a streams por rol: enrutamiento troncal, fabric del datacenter, firewalls, storage, hosts. Como cada origen tiene ya un nombre limpio, enrutar es cuestión de casar nombres o un campo de rol fijado por el mismo pipeline. Cada stream tiene como lectores naturales a las personas que operan esos sistemas, y cada uno puede tener su propia retención, diseñada para cumplir lo que exijan el servicio y cualquier auditor.

Alarme ante los problemas, y ante el silencio

Alarme ante lo que precede a los problemas

Una vez que los logs están limpios y en el lugar correcto, las líneas valiosas deberían llegar a una persona mientras aún importan. Definimos eventos para los mensajes que tienden a venir antes de una caída: una sesión BGP que cae, un enlace que oscila, BFD que declara muerta una ruta, sesiones de cifrado que se agitan en una troncal, un fallo de hardware, un error de Fibre Channel en un fabric de storage, un pool de direcciones que se agota. Van al ingeniero de guardia en el chat de operaciones según ocurren, de modo que el log se convierte en una alerta temprana en lugar de una autopsia.

Alarme también ante el silencio

Un dispositivo que deja de enviar se parece exactamente a un dispositivo que no tiene nada que decir. Así que alarme ante la ausencia: un evento que salta cuando un origen que normalmente habla lleva callado más de lo que jamás lo está. A los dispositivos naturalmente silenciosos, deles algo que decir, como una línea de heartbeat escrita por un temporizador cada hora, para que el silencio se convierta en señal. Después de cualquier cambio que pueda perturbar la ruta, envíe un mensaje de prueba y encuéntrelo en el otro extremo; nuestro equipo de red describe esa comprobación, y el resto de una autoprueba de monitorización, en Pruebe la ruta de la alarma, no el panel.

Compruebe su propio pipeline

• ¿Aparece algún dispositivo con más de un nombre de origen?
• ¿Qué pasa con los logs de un servidor si el colector está caído durante diez minutos?
• ¿Están todos los relojes sincronizados con las mismas fuentes, con zonas horarias explícitas?
• ¿Puede encontrar los mensajes de todos los firewalls en un solo stream?
• ¿Hay una alarma para un origen que se ha quedado callado?

Si quiere logs en los que pueda confiar durante una revisión de incidente, estaremos encantados de ayudarle a construir el pipeline y probarlo. Hable con un ingeniero

Related

Relacionado: Telemetría de red y energía, logging, detección de DDoS · Monitorización de flota y enrutado de alarmas