Logs-Überwachung

Ein Logs-Monitor zählt die Logs, die Ihre Dienste an Status200 senden und die zu Ihren Filtern passen – Text, Schweregrad, Dienst, Attribute –, über ein Zeitfenster. Erfüllt die Anzahl Ihre Kriterien, ändert er den Status des Monitors, erstellt eine Warnung oder eröffnet einen Vorfall. Damit erkennen Sie Fehlerspitzen, eine bestimmte Fehlermeldung oder einen Dienst, der keine Logs mehr schreibt.

So funktioniert es#

Jede Minute zählt Status200 die Logs, die zu den Filtern des Monitors passen und innerhalb seines Zeitfensters eingetroffen sind. Diese Anzahl prüft es von oben nach unten gegen die Kriterien des Monitors, und das erste passende Kriterium entscheidet, was geschieht. Passt keines, kehrt der Monitor zu seinem Standardstatus zurück.

Bevor Sie beginnen#

• Ihre Dienste senden Logs über OpenTelemetry (oder eine andere Log-Quelle, die Status200 aufnimmt) an Status200. Siehe OpenTelemetry.
• Um nach einem Wert innerhalb der Logzeile zu filtern oder zu gruppieren, etwa einem Tunnel- oder Benutzernamen, wandeln Sie ihn zuerst mit einer Log-Pipeline in ein Attribut um.

Einen Logs-Monitor erstellen#

1. Einen neuen Monitor beginnen#

   Gehen Sie zu Monitore und klicken Sie auf Monitor erstellen.

2. Logs wählen#

   Klicken Sie unter Monitortyp auf Weitere Monitortypen und wählen Sie Protokolle unter Telemetrie, oder tippen Sie logs in das Suchfeld. Geben Sie einen Name ein und klicken Sie dann auf Weiter.

3. Die zu zählenden Logs wählen#

   Legen Sie in Log-Monitor-Konfiguration die Felder Überwachungsprotokolle, die diesen Text enthalten, Überwachungsprotokolle für (time) und Protokollschweregrad fest. Ein leer gelassener Filter passt auf jedes Log. Protokollvorschau unter den Filtern zeigt die Logs, auf die sie gerade passen.

4. Weiter eingrenzen (optional)#

   Öffnen Sie Weitere Felder, um nach Telemetrie-Dienst, Infrastruktur-Entität oder Attribut zu filtern. Für eine Warnung pro Tunnel, Benutzer oder Schnittstelle statt einer für den ganzen Monitor fügen Sie das Attribut unter Group by Attributes hinzu – siehe Warnungen pro Gruppe.

5. Die Kriterien festlegen#

   Die Karte Monitor-Kriterien beginnt mit zwei Kriterien: offline, mit einem Vorfall, wenn kein Log passt; online, sobald mindestens eines passt. Ändern Sie sie so, dass sie das melden, was Sie wollen – siehe Kriterien.

6. Den Monitor erstellen#

   Klicken Sie auf Monitor erstellen. Der Monitor öffnet sich auf seiner Seite Übersicht, und seine erste Auswertung läuft innerhalb einer Minute.

Was er abfragt#

Alle Filter, die Sie festlegen, müssen passen, damit ein Log gezählt wird.

Log-Schweregrad#

Jedes Log wird mit einem von sieben Schweregraden gespeichert. Bei OpenTelemetry-Logs stammt er aus der Schweregradnummer des Logs; wählen Sie also den Schweregrad, nicht den Text, den Ihr Logger ausgegeben hat:

Wie er ausgewertet wird#

• Jede Minute. Ein Logs-Monitor wird nicht von Sonden geprüft, deshalb hat er kein Intervall zum Einstellen und keine Seite Sonden & Intervall.
• Eine Zahl pro Auswertung. Der Monitor zählt die Logs, die zu jedem Filter passen und innerhalb von Überwachungsprotokolle für (time) vor der Auswertung eingetroffen sind. Mit Letzte 5 Minuten blickt jede Auswertung fünf Minuten zurück, sodass sich die Fenster aufeinanderfolgender Auswertungen überlappen.
• Keine Logs ergeben die Anzahl 0. Ein Dienst, der keine Logs mehr schreibt, liefert 0 – genau darauf achtet das Standardkriterium für offline.
• Die eigene Ausfallzeit von Status200 ist keine Stille. Solange das Zeitfenster Zeit enthält, in der Status200 selbst keine Daten empfangen hat – weil es neu startete, aktualisiert wurde oder einen Rückstand aufholte –, wartet die Prüfung: Der Status ändert sich nicht, und kein Vorfall und keine Warnung wird eröffnet oder behoben. Siehe Wenn Status200 keine Daten empfängt.
• Kriterien von oben nach unten. Das erste passende Kriterium entscheidet; stellen Sie also das schwerwiegendste nach oben. Ein gruppierter Monitor arbeitet anders: Er prüft jedes Kriterium für jede Gruppe – siehe Die Auswertung der Kriterien unterscheidet sich.

Jede Statusänderung wird mit ihrem Grund in der Status-Zeitachse des Monitors festgehalten.

Kriterien#

Die Kriterien eines Logs-Monitors haben einen Filtertyp: Log Count, die Anzahl der Logs, die im Fenster gepasst haben. Wählen Sie eine Filterbedingung und, bei einer Schwellenwertbedingung, einen Wert.

Die Anomaliebedingungen haben keinen Wert. Wählen Sie eine Empfindlichkeit – Low, Medium (der Standard) oder High – und ein Baseline-Fenster von 14 (der Standard), 28, 60 oder 90 Tagen. Status200 rechnet die Anzahl in eine Rate pro Minute um und vergleicht sie mit derselben Stunde der Woche über dieses Fenster. Die Baseline umfasst nur die Dienste und Schweregrade des Monitors: Seine Text- und Attributfilter gehören nicht dazu. Solange diese Stunde der Woche nicht genug Verlauf hat, lernt das Kriterium noch und löst nicht aus.

Ein neuer Logs-Monitor beginnt mit diesen Kriterien:

Ein Beispiel: eine Fehlerspitze#

Sie wollen einen Vorfall, wenn der Checkout-Dienst in fünf Minuten mehr als 50 Fehler protokolliert:

• Protokollschweregrad: Fehler
• Überwachungsprotokolle für (time): Letzte 5 Minuten
• Nach Telemetrie-Dienst filtern: checkout
• Kriterium 1: Log Count Größer als 50 – den Monitor auf offline setzen und einen Vorfall eröffnen
• Kriterium 2: Log Count Kleiner als oder gleich 50 – den Monitor auf online setzen

Vier aufeinanderfolgende Auswertungen:

Weil sich die Fenster überlappen, hält ein einzelner Fehlerschub die Anzahl bis zu fünf Minuten nach seinem Ende hoch. Verwenden Sie ein kürzeres Fenster für einen Monitor, der sich schneller erholen soll.

Warnungen pro Gruppe (Group By)#

Group by Attributes teilt die Anzahl eines Logs-Monitors in eine Anzahl pro unterschiedlicher Kombination von Attributwerten auf – eine pro IPsec-Tunnel, pro VPN-Benutzer, pro Firewall-Schnittstelle – und wertet die Kriterien für jede Gruppe getrennt aus. Es ist das Gegenstück für Logs zum Group By eines Metriken-Monitors.

Eine Warnung pro Gruppe#

Ohne Group By ist ein Monitor, der auf beendete IPsec-Tunnel achtet, eine einzige Anzahl für den ganzen Monitor und löst eine Warnung für den ganzen Monitor aus. Solange diese Warnung offen ist, erzeugt ein zweiter ausfallender Tunnel nichts Neues – der Monitor warnt ja bereits.

Mit Group By auf dem Tunnelnamen eröffnet das Beenden des Tunnels HQ-Branch1 seine eigene Warnung, und das Beenden des Tunnels Branch2 zehn Minuten später eröffnet daneben eine zweite, separate Warnung.

Unabhängige Behebung#

Die Warnung oder der Vorfall jeder Gruppe wird für sich behoben. Sobald eine Gruppe die Kriterien nicht mehr erfüllt – HQ-Branch1 protokolliert innerhalb des Zeitfensters keine Beendigungen mehr –, wird ihre Warnung behoben, während die von Branch2 offen bleibt, bis auch Branch2 aufhört. Die Erholung einer Gruppe schließt nie die Warnung einer anderen.

Ein Logs-Monitor sieht Ereignisse, keinen Zustand: Die Warnung einer Gruppe wird behoben, sobald diese Gruppe ein ganzes Zeitfenster lang nichts protokolliert hat, das die Kriterien erfüllt – ob der Tunnel wieder da ist oder nicht, es sei denn, der Monitor nennt das Log, das seine Rückkehr meldet, wie unten beschrieben.

Durch ein Log behoben#

Ein Gerät, das einen Tunnel als ausgefallen meldet, meldet ihn in der Regel auch wieder als aktiv. Behoben durch Attribute benennt dieses Log: Ist es gesetzt, bleibt die Warnung oder der Vorfall einer Gruppe offen, bis ein Log mit diesen Attributen für dieselbe Gruppe eintrifft, statt behoben zu werden, wenn die Logs der Gruppe aufhören.

Nehmen Sie einen Monitor, der Logs mit event.name = vpn.tunnel_down zählt, gruppiert nach event.device und vpn.tunnel.name, mit Behoben durch Attribute gesetzt auf event.name = vpn.tunnel_up. Fällt der Tunnel HQ-Branch1 aus, öffnet das seine Warnung. Die Warnung bleibt über Nacht offen, obwohl die Firewall nichts mehr zu dem Tunnel protokolliert, und wird behoben, wenn die Firewall HQ-Branch1 als aktiv meldet. Bricht der Tunnel erneut ab, öffnet das eine neue Warnung.

• Das Feld erscheint, sobald Group by Attributes ein Attribut hat. Es nimmt bis zu 10 Attribute auf, und ein behebendes Log trägt sie alle.
• Ein behebendes Log gehört zu einer Gruppe, wenn es für die Group-by-Attribute die Werte der Gruppe hat; beide Arten von Logs müssen diese Attribute also tragen.
• Die Telemetriedienste und das Zeitfenster des Monitors gelten auch für behebende Logs. Seine Text- und Schweregradfilter nicht: Sie beschreiben das Problem.
• Eine Gruppe, deren neuestes Log ein behebendes ist, wird geschlossen. Eine, die das Problem danach erneut protokolliert hat, bleibt offen.
• Sie können eine Warnung weiterhin selbst beheben.

Netzwerkereignisse legt diese Monitore für Sie an, ein Klick pro Warnung.

Beispiel: eine Warnung pro Sophos-IPsec-Tunnel#

Dies setzt voraus, dass die Syslog-Zeilen der Firewall mit einem Key=Value-Parser ohne Zielpräfix in Attribute zerlegt werden, sodass der Tunnelname das Attribut con_name ist:

log_component="IPSec" con_name="HQ-Branch1" status="Terminated" message="IPSec Connection HQ-Branch1 between 10.171.4.117 and 10.171.4.118 for Child HQ-Branch1 terminated."

Jeder Tunnel, der eine Beendigung protokolliert, erhält nun seine eigene Warnung – IPsec tunnel HQ-Branch1 terminated, IPsec tunnel Branch2 terminated –, und jede wird für sich behoben.

Gruppenwerte in Titeln und Beschreibungen#

Der Wert jedes Group-By-Attributs ist eine Vorlagenvariable im Titel, in der Beschreibung und in den Hinweisen zur Behebung der Warnung oder des Vorfalls, genau wie die Labels einer Metrikreihe: Gruppieren nach con_name liefert {{con_name}}. Ein Schlüssel mit Punkten wird als Pfad gelesen, sophos.con_name also als {{sophos.con_name}}. Nennt der Titel die Gruppe noch nicht, wird sie angehängt (IPsec tunnel terminated - Con Name: HQ-Branch1), und {{seriesResourceSuffix}} und {{seriesResourceSummary}} funktionieren wie bei Metrik-Monitoren.

Wie Gruppen gezählt werden#

• Bis zu 10 Attribute. Jede unterschiedliche Kombination ihrer Werte ist eine Gruppe.
• Ein Log ohne ein Group-By-Attribut wird unter einem leeren Wert dafür gezählt; Logs ohne das Attribut bilden also eine eigene Gruppe, deren Warnung keinen Wert dafür nennt. Kommt jede Warnung ohne Gruppenwert an, prüfen Sie den Attributschlüssel – eine Log-Pipeline mit Zielpräfix speichert con_name als sophos.con_name.
• Gruppenwerte, die länger als 256 Zeichen sind, werden auf 256 gekürzt.
• Pro Prüfung werden höchstens 100 Gruppen ausgewertet: die 100 mit den meisten Logs. Passen mehr, werden die übrigen bei dieser Prüfung übersprungen und eine Warnung wird protokolliert – grenzen Sie die Filter des Monitors ein, um sie abzudecken.

Die Auswertung der Kriterien unterscheidet sich#

• Jedes Kriterium wird ausgewertet, wie bei einem gruppierten Metriken-Monitor, sodass verschiedene Gruppen zugleich verschiedene Kriterien erfüllen können. Eine Gruppe, die zwei Kriterien erfüllt, erhält trotzdem nur eine Warnung, vom ersten; ordnen Sie die Kriterien also mit dem schwerwiegendsten zuerst.
• Eine Gruppe existiert nur, wenn sie im Zeitfenster etwas protokolliert hat. Kriterien mit Gleich 0 und Kleiner als lösen daher nur für Gruppen aus, die mindestens einmal protokolliert haben; um zu warnen, wenn gar keine Logs mehr eintreffen, verwenden Sie einen Monitor ohne Group By.
• Anomalieerkennung (Anomalously High, Anomalously Low, Anomalous) wird nicht pro Gruppe ausgewertet – ihre Baseline umfasst den ganzen Monitor –, daher passen diese Filter bei einem gruppierten Monitor nie.
• Der Status des Monitors folgt dem ersten Kriterium, das irgendeine Gruppe erfüllt. Erfüllt keine Gruppe ein Kriterium, kehrt der Monitor zu seinem Standardstatus zurück.

Fehlerbehebung#

Nächste Schritte#