Warum die CPU-Auslastung (normalerweise) keine kritische Warnung sein sollte.

Eine Frage, die sich bei der Überwachung häufig stellt, ist, wie Warnstufen und Eskalationen definiert werden und auf welcher Ebene verschiedene Warnungen festgelegt werden sollen – Kritisch, Fehler oder Warnung.

Angenommen, Sie haben Fehler und kritische Warnungen so eingestellt, dass Sie Teams per Pager / Telefon benachrichtigen, und kritische Warnungen mit einer kürzeren Eskalationszeit, hier sind einige einfache Richtlinien:

Kritische Warnungen sollten für Ereignisse gelten, die sich unmittelbar auf den Kunden auswirken. Beispielsweise fällt eine virtuelle Produktions-IP auf einem überwachten Load Balancer aus, da keine Dienste verfügbar sind, an die der Datenverkehr weitergeleitet werden kann. Die Seite ist down, also Seite alle.

Fehlerwarnungen sollten für Ereignisse gelten, die sofortige Aufmerksamkeit erfordern und die, wenn sie nicht gelöst werden, die Wahrscheinlichkeit erhöhen, dass ein produktionsbeeinträchtigendes Ereignis auftritt. Um mit dem Load Balancer-Beispiel fortzufahren, sollte ein Fehler ausgelöst werden, wenn die virtuelle IP nur über einen funktionierenden Backend-Server verfügt, an den der Datenverkehr weitergeleitet werden kann.

Warnungen, die normalerweise nur per E-Mail gesendet werden sollten, gelten für alle anderen Arten von Ereignissen. Der Verlust eines einzelnen Backend-Servers von einer virtuellen IP, wenn 20 andere Server funktionieren, garantiert nicht, dass jemand in der Nacht geweckt wird.

Berücksichtigen Sie bei der Entscheidung, welche Stufe Warnungen zugewiesen werden sollen, die Hauptfunktion des Geräts. Im Falle eines NetApp Storage Arrays besteht die Funktion des Geräts beispielsweise darin, Lese- und Schreib-E / A-Anforderungen zu erfüllen. Das Wichtigste für die Überwachung von NetApps sollte daher die Verfügbarkeit und Leistung (Latenz) dieser Lese- und Schreibanforderungen sein. Wenn ein Volume Anforderungen mit hoher Latenz (z. B. 70 ms pro Schreibanforderung) bedient, sollte dies eine Warnung auf Fehlerebene sein (in einigen Unternehmen kann dies als Warnung auf kritischer Ebene konfiguriert werden, aber normalerweise sollte eine kritische Leistungswarnung nur ausgelöst werden, wenn sich die Leistung der Endanwendung inakzeptabel verschlechtert.) Wenn die CPU-Auslastung der NetApp jedoch für einen bestimmten Zeitraum 99% beträgt, obwohl dies alarmierend klingt, würde ich vorschlagen, dass dies nur als Warnstufe behandelt wird. Wenn die Latenz nicht beeinträchtigt wird, warum sollten Menschen nachts geweckt werden? Senden Sie eine E-Mail-Benachrichtigung, damit das Problem untersucht werden kann. (Wenn Sie möchten, können Sie Ihre Warnungseskalationen so definieren, dass solche Bedingungen zu Seiten führen, wenn diese beispielsweise länger als 5 Stunden nicht korrigiert oder nicht bestätigt werden.)

Alarmüberlastung ist eine größere Gefahr für die meisten Rechenzentren, als die meisten Menschen erkennen. Der Gedanke ist oft “Wenn eine Warnung gut ist, muss mehr besser sein.” Konzentrieren Sie sich stattdessen darauf, die Hauptfunktionen von Geräten zu identifizieren – legen Sie Warnungen auf Fehlerebene für diese Funktionen fest und verwenden Sie Warnungen, um Sie über Bedingungen zu informieren, die diese Funktionen beeinträchtigen könnten, oder um die Fehlerbehebung zu unterstützen. (Wenn die Latenz auf einer NetApp hoch ist und die CPU-Last ebenfalls in Alarmbereitschaft ist, hilft dies offensichtlich bei der Diagnose des Problems, anstatt nach ungewöhnlichen Volumenaktivitäten zu suchen.)

Reservieren Sie kritische Warnungen für die Systemleistung und -verfügbarkeit als Ganzes.

Mit LogicMonitor Hosted Monitoring haben die Alarmdefinitionen für alle Rechenzentrumsgeräte ihre Alarmschwellen auf die oben genannte Weise vordefiniert – so helfen wir, eine aussagekräftige Überwachung in wenigen Minuten bereitzustellen.