Zentrales Logging, das einer Incident-Nachbesprechung standhält

Die eigentliche Prüfung für zentrales Logging ist nicht, ob die Nachrichten an einem ruhigen Nachmittag ankommen. Sie ist, ob Sie am Morgen, nachdem etwas schiefgegangen ist, in wenigen Minuten eine vollständige, korrekt geordnete Zeitleiste über Router, Firewalls, Storage und Server zusammenstellen können. Das braucht eine Pipeline, die dafür gebaut ist. So bauen wir unsere in Graylog, und das können Sie für Ihre eigene übernehmen.

Beginnen Sie bei der Frage, die Sie stellen werden

Jede Designentscheidung in einer Logging-Pipeline sollte einer Frage dienen: «Was ist passiert, überall, zwischen diesen beiden Zeitpunkten?» Diese Frage scheitert auf vier vorhersagbare Arten. Nachrichten fehlen für einen Teil des Fensters. Dasselbe Gerät erscheint unter mehreren Namen, sodass eine Suche nur einen Teil seiner Geschichte findet. Die Uhren sind sich uneins, sodass Ereignisse in der falschen Reihenfolge landen. Oder alles liegt auf einem undifferenzierten Haufen, sodass die wichtigen Zeilen begraben sind. Jeder Abschnitt unten beseitigt einen dieser Fehler.

Leiten Sie zuverlässig weiter, und puffern Sie auf der Platte

Klassisches Syslog über UDP ist Senden und Vergessen: Der Absender erfährt nie, ob irgendetwas die Nachricht empfangen hat. Für Server bevorzugen wir TCP-Weiterleitung mit einer plattengestützten Warteschlange, damit ein Neustart des Collectors oder ein kurzer Netzwerkaussetzer Logs verzögert statt sie zu verlieren. Eine minimale rsyslog-Action:

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")

Das Template sendet strukturierte RFC-5424-Nachrichten mit vollständigem Zeitstempel und Hostname. Die Warteschlange hält nicht zugestellte Nachrichten auf der Platte und versucht es erneut, bis der Collector zurück ist. Validieren Sie mit rsyslogd -N1, bevor Sie den Dienst neu starten.

Netzwerkgeräte sind meist auf einfaches Syslog beschränkt, daher ist der Schutz für sie ein anderer: Senden Sie an den Collector von einer Quelladresse und einer Routing-Instanz aus, die ihn immer erreichen können, und prüfen Sie diesen Pfad, wann immer sich das Routing des Geräts ändert.

Geben Sie jedem Gerät genau einen Namen

Hersteller sind sich uneins darüber, was in einen Syslog-Header gehört. Manche Geräte lassen ihren eigenen Hostnamen weg, manche senden einen Kurznamen, manche eine Adresse, und dasselbe Gerät kann nach einem Software-Update das Format wechseln. Speichert der Collector, was auch immer ankommt, landet ein Router verteilt auf drei Quellnamen, und eine Suche nach ihm liefert ein Drittel seiner Geschichte.

Wir beheben das beim Eingang. Eine Pipeline-Regel in Graylog schreibt die Quelle jeder Nachricht auf einen kanonischen Gerätenamen um, über eine Lookup-Tabelle mit der sendenden Adresse als Schlüssel:

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

Halten Sie die Lookup-Tabelle mit Ihrem Inventar im Gleichschritt, damit ein neues Gerät seinen sauberen Namen an dem Tag bekommt, an dem es erfasst wird, nicht an dem Tag, an dem jemand bemerkt, dass es fehlt.

Bringen Sie die Uhren in Ordnung

Jedes Gerät sollte in UTC protokollieren oder einen ausdrücklichen Offset tragen. Lokale Zeit und UTC über Geräte hinweg zu mischen ist der klassische Weg, einen Vorfall in der falschen Reihenfolge erscheinen zu lassen. Zwei schnelle Prüfungen auf einem Linux-Host:

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

Auf Netzwerkgeräten prüfen Sie den entsprechenden Statusbefehl und stellen sicher, dass der Logging-Zeitstempel Datum, Millisekunden und Zeitzone enthält. Sekunden reichen nicht, wenn zwei Router auf dasselbe Ereignis reagieren.

Leiten Sie Nachrichten in Streams nach Rolle

Ein einziger Feuerwehrschlauch ist unlesbar. Wir leiten Nachrichten in Streams nach Rolle: Core-Routing, Rechenzentrums-Fabric, Firewalls, Storage, Hosts. Weil jede Quelle jetzt einen sauberen Namen hat, ist das Routing eine Sache des Abgleichs von Namen oder eines Rollenfelds, das dieselbe Pipeline setzt. Jeder Stream hat die Menschen, die diese Systeme betreiben, als natürliche Leser, und jeder kann seine eigene Aufbewahrung haben, ausgelegt auf das, was der Dienst und jeder Prüfer verlangen.

Alarmieren Sie bei Problemen, und bei Stille

Alarmieren Sie bei dem, was Problemen vorausgeht

Sobald die Logs sauber und am richtigen Ort sind, sollten die wertvollen Zeilen einen Menschen erreichen, solange sie noch zählen. Wir definieren Events für die Nachrichten, die einem Ausfall oft vorausgehen: eine BGP-Session, die abbricht, eine Leitung, die flattert, BFD, das einen Pfad für tot erklärt, Verschlüsselungssitzungen, die auf einem Backbone ständig neu aufgebaut werden, ein Hardwarefehler, ein Fibre-Channel-Fehler auf einer Storage-Fabric, ein Adresspool, der zur Neige geht. Sie gehen an den Ingenieur in Bereitschaft im Betriebs-Chat, während sie geschehen, sodass das Log zur Frühwarnung wird statt zur Obduktion.

Alarmieren Sie auch bei Stille

Ein Gerät, das aufhört zu senden, sieht genauso aus wie ein Gerät, das nichts zu sagen hat. Alarmieren Sie also bei Abwesenheit: ein Event, das auslöst, wenn eine Quelle, die normalerweise spricht, länger still war, als sie es je ist. Geben Sie von Natur aus stillen Geräten etwas zu sagen, etwa eine Heartbeat-Zeile, die ein Timer jede Stunde schreibt, damit Stille zum Signal wird. Senden Sie nach jeder Änderung, die den Pfad stören könnte, eine Testnachricht und finden Sie sie am anderen Ende. Unser Netzwerkteam beschreibt diese Prüfung, und den Rest eines Monitoring-Selbsttests, in Testen Sie den Alarmpfad, nicht das Dashboard.

Prüfen Sie Ihre eigene Pipeline

• Erscheint irgendein Gerät unter mehr als einem Quellnamen?
• Was passiert mit den Logs eines Servers, wenn der Collector zehn Minuten lang ausgefallen ist?
• Sind alle Uhren auf dieselben Quellen synchronisiert, mit ausdrücklichen Zeitzonen?
• Können Sie die Nachrichten jeder Firewall in einem Stream finden?
• Gibt es einen Alarm für eine Quelle, die verstummt ist?

Wenn Sie Logs möchten, auf die Sie sich in einer Incident-Nachbesprechung verlassen können, helfen wir Ihnen gern, die Pipeline zu bauen und zu testen. Mit einem Ingenieur sprechen

Related

Verwandt: Netzwerk- und Stromtelemetrie, Protokollierung, DDoS-Erkennung · Flotten-Monitoring und Alarmweiterleitung