Une journalisation centrale qui tient lors d'une revue d'incident

Le vrai test de la journalisation centrale n'est pas de savoir si les messages arrivent un après-midi calme. C'est de savoir si, le lendemain matin d'un incident, vous pouvez assembler en quelques minutes une chronologie complète et correctement ordonnée à travers routeurs, firewalls, stockage et serveurs. Cela demande un pipeline construit pour cela. Voici comment nous construisons le nôtre sur Graylog, et ce que vous pouvez copier pour le vôtre.

Partez de la question que vous poserez

Chaque choix de conception dans un pipeline de journalisation doit servir une seule question : « que s'est-il passé, partout, entre ces deux instants ? » Cette question échoue de quatre façons prévisibles. Des messages manquent pour une partie de la fenêtre. Le même équipement apparaît sous plusieurs noms, donc une recherche ne trouve qu'une partie de son historique. Les horloges divergent, donc les événements tombent dans le mauvais ordre. Ou tout est dans un seul tas indifférencié, donc les lignes importantes sont enterrées. Chaque section ci-dessous supprime l'une de ces défaillances.

Transférez de façon fiable, et mettez en tampon sur disque

Le syslog classique en UDP, c'est « envoyer et oublier » : l'expéditeur ne sait jamais si quelque chose a reçu le message. Pour les serveurs, nous préférons le transfert TCP avec une file assistée par disque, pour qu'un redémarrage du collecteur ou une coupure réseau passagère retarde les logs au lieu de les perdre. Une action rsyslog minimale :

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

Le template envoie des messages structurés RFC 5424 avec un horodatage complet et le nom d'hôte. La file conserve les messages non livrés sur disque et réessaie jusqu'au retour du collecteur. Validez avec rsyslogd -N1 avant de redémarrer le service.

Les équipements réseau se limitent en général au syslog simple, donc pour eux la protection est différente : envoyez vers le collecteur depuis une adresse source et une instance de routage qui peuvent toujours l'atteindre, et vérifiez ce chemin chaque fois que le routage de l'équipement change.

Donnez à chaque équipement exactement un nom

Les constructeurs ne s'accordent pas sur ce qui va dans un en-tête syslog. Certains équipements omettent leur propre nom d'hôte, certains envoient un nom court, certains envoient une adresse, et le même équipement peut changer de format après une mise à jour logicielle. Si le collecteur stocke ce qui arrive, un routeur finit étalé sur trois noms de source, et une recherche à son sujet renvoie un tiers de son historique.

Nous corrigeons cela à l'entrée. Une règle de pipeline Graylog réécrit la source de chaque message en un nom d'équipement canonique, à l'aide d'une table de correspondance indexée sur l'adresse d'envoi :

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

Gardez la table de correspondance alignée sur votre inventaire, pour qu'un nouvel équipement reçoive son nom propre le jour où il est enregistré, pas le jour où quelqu'un remarque qu'il manque.

Mettez les horloges à l'heure

Chaque équipement doit journaliser en UTC ou porter un décalage explicite. Mélanger heure locale et UTC d'un équipement à l'autre est la façon classique de faire apparaître un incident dans le mauvais ordre. Deux vérifications rapides sur un hôte Linux :

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

Sur l'équipement réseau, vérifiez la commande d'état équivalente et assurez-vous que l'horodatage de journalisation inclut la date, les millisecondes et le fuseau horaire. Les secondes ne suffisent pas quand deux routeurs réagissent au même événement.

Routez les messages dans des flux par rôle

Un seul torrent est illisible. Nous routons les messages dans des flux par rôle : routage cœur, fabric du datacenter, firewalls, stockage, hôtes. Comme chaque source a désormais un nom propre, le routage est une affaire de correspondance de noms ou d'un champ de rôle défini par le même pipeline. Chaque flux a pour lecteurs naturels les personnes qui exploitent ces systèmes, et chacun peut avoir sa propre rétention, conçue pour correspondre à ce qu'exigent le service et tout auditeur.

Alarme sur le problème, et sur le silence

Alarme sur ce qui précède le problème

Une fois les logs propres et au bon endroit, les lignes précieuses doivent atteindre une personne tant qu'elles comptent encore. Nous définissons des événements pour les messages qui tendent à précéder une panne : une session BGP qui tombe, un lien qui bat, BFD qui déclare un chemin mort, des sessions de chiffrement qui se renouvellent en boucle sur un backbone, un défaut matériel, une erreur Fibre Channel sur un fabric de stockage, un pool d'adresses qui s'épuise. Ils vont à l'ingénieur d'astreinte dans le chat d'exploitation au moment où ils se produisent, pour que le log devienne une alerte précoce au lieu d'une autopsie.

Alarme sur le silence aussi

Un équipement qui cesse d'envoyer ressemble exactement à un équipement qui n'a rien à dire. Alors mettez une alarme sur l'absence : un événement qui se déclenche quand une source qui parle normalement est restée silencieuse plus longtemps qu'elle ne l'a jamais été. Pour les équipements naturellement silencieux, donnez-leur quelque chose à dire, comme une ligne de battement de cœur écrite par un timer toutes les heures, pour que le silence devienne un signal. Après tout changement susceptible de perturber le chemin, envoyez un message de test et retrouvez-le à l'autre bout. Notre équipe réseau décrit cette vérification, et le reste d'un autotest de supervision, dans Votre supervision est aussi un système : testez le chemin, pas le tableau de bord.

Vérifiez votre propre pipeline

• Un équipement apparaît-il sous plus d'un nom de source ?
• Qu'arrive-t-il aux logs d'un serveur si le collecteur est arrêté pendant dix minutes ?
• Toutes les horloges sont-elles synchronisées sur les mêmes sources, avec des fuseaux horaires explicites ?
• Pouvez-vous trouver les messages de chaque firewall dans un seul flux ?
• Existe-t-il une alarme pour une source devenue silencieuse ?

Si vous voulez des logs sur lesquels vous pouvez compter lors d'une revue d'incident, nous vous aiderons volontiers à construire le pipeline et à le tester. Parler à un ingénieur

Related

Voir aussi : Télémétrie réseau et électrique, logs, détection DDoS · Supervision du parc et routage des alarmes