Überwachung und Alarmierung in die Praxis umsetzen

Während der Großteil des Überwachungssystems möglicherweise auf einem oder mehreren dedizierten Servern bereitgestellt wird, müssen Daten aus vielen verschiedenen Quellen in Ihrer gesamten Infrastruktur gesammelt werden. Zu diesem Zweck wird auf jedem einzelnen Computer im gesamten Netzwerk ein Überwachungsagent installiert, eine kleine Anwendung zum Erfassen und Weiterleiten von Daten an einen Erfassungsendpunkt. Diese Agenten erfassen Statistiken und Nutzungsmetriken auf dem Host, auf dem sie installiert sind, und senden sie an die zentrale Überwachungssoftware.

Agenten werden auf jedem Host im gesamten System als ständig aktive Daemons ausgeführt. Sie können eine Basiskonfiguration zur sicheren Authentifizierung beim Remote-Datenendpunkt, zur Definition der Datenfrequenz oder der Stichprobenrichtlinien und zur Festlegung eindeutiger Kennungen für die Hostdaten enthalten. Um die Auswirkungen auf andere Dienste zu verringern, muss der Agent nur minimale Ressourcen verwenden und mit wenig oder gar keiner Verwaltung arbeiten können. Im Idealfall sollte es einfach sein, einen Agenten auf einem neuen Knoten zu installieren und Metriken an das zentrale Überwachungssystem zu senden.

Überwachungsagenten erfassen in der Regel allgemeine Messdaten auf Host-Ebene. Es stehen jedoch auch Agenten zur Überwachung von Software wie Web- oder Datenbankservern zur Verfügung. Für die meisten speziellen Softwaretypen müssen Daten jedoch gesammelt und exportiert werden, indem entweder die Software selbst geändert oder ein eigener Agent erstellt wird, indem ein Dienst erstellt wird, der die Statusendpunkte oder Protokolleinträge der Software analysiert. Viele gängige Überwachungslösungen verfügen über Bibliotheken, mit denen Sie Ihre Dienste einfacher mit benutzerdefinierten Instrumenten ausstatten können. Wie bei der Agentensoftware muss darauf geachtet werden, dass Ihre benutzerdefinierten Lösungen möglichst wenig Speicherplatz beanspruchen, um die Integrität oder Leistung Ihrer Anwendungen nicht zu beeinträchtigen.

Bisher haben wir einige Annahmen zu einer Push-basierten Architektur für die Überwachung getroffen, bei der die Agenten Daten an einen zentralen Ort übertragen. Es sind jedoch auch Ausführungen auf Pull-Basis erhältlich. In Pull-basierten Überwachungssystemen sind einzelne Hosts dafür verantwortlich, Metriken in einem bekannten Format an einem zugänglichen Endpunkt zu sammeln, zu aggregieren und bereitzustellen. Der Überwachungsserver fragt den Metrikendpunkt auf jedem Host ab, um die Metrikdaten zu erfassen. Die Software, die die Daten über den Endpunkt sammelt und präsentiert, hat viele der gleichen Anforderungen wie ein Agent, erfordert jedoch häufig weniger Konfiguration, da sie nicht wissen muss, wie auf andere Computer zugegriffen werden soll.

Einer der beschäftigtsten Teile eines Überwachungssystems zu einem bestimmten Zeitpunkt ist die Metrik-Eingangskomponente. Da ständig Daten generiert werden, muss der Erfassungsprozess robust genug sein, um ein hohes Aktivitätsvolumen zu bewältigen, und mit der Speicherschicht koordiniert werden, um die eingehenden Daten korrekt aufzuzeichnen.

Bei Push-basierten Systemen ist der Messdateneingangsendpunkt ein zentraler Ort im Netzwerk, an den jeder Überwachungsagent oder Statistikaggregator seine gesammelten Daten sendet. Der Endpunkt sollte in der Lage sein, Daten von einer großen Anzahl von Hosts gleichzeitig zu authentifizieren und zu empfangen. Ingress-Endpunkte für Metrics-Systeme werden häufig aus Gründen der Zuverlässigkeit und um mit dem hohen Verkehrsaufkommen Schritt zu halten, Lastenausgleich oder Skalierung durchgeführt.

Bei Pull-basierten Systemen ist die entsprechende Komponente der Abfragemechanismus, mit dem die auf den einzelnen Hosts verfügbaren Metrikendpunkte abgerufen und analysiert werden. Dies hat einige der gleichen Anforderungen, aber einige Verantwortlichkeiten sind umgekehrt. Wenn einzelne Hosts beispielsweise die Authentifizierung implementieren, muss der Messwerterfassungsprozess in der Lage sein, die richtigen Anmeldeinformationen bereitzustellen, um sich anzumelden und auf den sicheren Endpunkt zuzugreifen.

Die Datenverwaltungsschicht ist für die Organisation und Aufzeichnung eingehender Daten von der Metrik-Eingangskomponente und die Beantwortung von Abfragen und Datenanforderungen von den Verwaltungsschichten verantwortlich. Metrikdaten werden normalerweise in einem Format namenstime series aufgezeichnet, das Wertänderungen im Laufe der Zeit darstellt. Zeitreihendatenbanken - Datenbanken, die auf das Speichern und Abfragen dieser Art von Daten spezialisiert sind - werden häufig in Überwachungssystemen verwendet.

Die Hauptaufgabe der Datenverwaltungsebene besteht darin, eingehende Daten so zu speichern, wie sie von Hosts empfangen oder gesammelt werden. Die Speicherebene sollte mindestens die Metrik, die gemeldet wird, den beobachteten Wert, die Zeit, zu der der Wert generiert wurde, und den Host, der ihn erstellt hat, aufzeichnen.

Für eine dauerhafte Speicherung über einen längeren Zeitraum muss die Speicherschicht eine Möglichkeit zum Exportieren von Daten bereitstellen, wenn die Sammlung die lokalen Einschränkungen für Verarbeitung, Speicher oder Speicherung überschreitet. Infolgedessen muss die Speicherschicht auch in der Lage sein, Daten in großen Mengen zu importieren, um bei Bedarf historische Daten erneut in das System aufzunehmen.

Die Datenverwaltungsschicht muss auch einen organisierten Zugriff auf die gespeicherten Informationen bereitstellen. Für Systeme, die Zeitreihendatenbanken verwenden, wird diese Funktionalität durch integrierte Abfragesprachen oder APIs bereitgestellt. Diese können für interaktive Abfragen und Datenexplorationen verwendet werden. Die Hauptkonsumenten sind jedoch wahrscheinlich die Datenpräsentations-Dashboards und das Warnsystem.

Auf der Datenverwaltungsebene sind die Schnittstellen aufgebaut, mit denen Sie interagieren, um die gesammelten Daten zu verstehen. Da es sich bei Metriken um Zeitreihendaten handelt, lassen sich Daten am besten als Diagramm mit der Zeit auf der x-Achse darstellen. Auf diese Weise können Sie leicht nachvollziehen, wie sich die Werte mit der Zeit ändern. Metriken können über verschiedene Zeitskalen hinweg visualisiert werden, um Trends über lange Zeiträume sowie die jüngsten Änderungen zu verstehen, die sich derzeit möglicherweise auf Ihre Systeme auswirken.

Die Visualisierungs- und Datenverwaltungsebenen tragen dazu bei, dass Daten von verschiedenen Hosts oder von verschiedenen Teilen Ihres Anwendungsstapels überlagert und ganzheitlich angezeigt werden können. Glücklicherweise bieten Zeitreihendaten eine konsistente Skala, mit deren Hilfe Ereignisse oder Änderungen, die gleichzeitig erfolgten, identifiziert werden können, auch wenn die Auswirkungen auf verschiedene Arten von Infrastrukturen verteilt sind. Durch die Auswahl der Daten, die interaktiv überlagert werden sollen, können Bediener Visualisierungen erstellen, die für die jeweilige Aufgabe am nützlichsten sind.

Häufig verwendete Grafiken und Daten werden häufig in gespeicherten Dashboards organisiert. Diese sind in einer Reihe von Zusammenhängen nützlich, entweder als fortlaufende Darstellung der aktuellen Zustandsmetriken für permanente Anzeigen oder als gezielte Portale zur Fehlerbehebung oder zum Tiefeneintauchen in bestimmte Bereiche Ihres Systems. Beispielsweise kann ein Dashboard mit einer detaillierten Aufschlüsselung der physischen Speicherkapazität in einer Flotte für die Kapazitätsplanung wichtig sein, für die tägliche Verwaltung muss jedoch möglicherweise nicht darauf verwiesen werden. Indem Sie das Erstellen von allgemeinen und fokussierten Dashboards vereinfachen, können Sie Ihre Daten leichter zugänglich machen und leichter umsetzen.

Diagramme und Dashboards sind zwar die wichtigsten Werkzeuge für das Verständnis der Daten in Ihrem System, sie sind jedoch nur in Kontexten nützlich, in denen ein menschlicher Bediener die Seite anzeigt. Eine der wichtigsten Aufgaben eines Überwachungssystems besteht darin, die Teammitglieder von der aktiven Überwachung Ihrer Systeme zu entlasten, damit sie wertvollere Aktivitäten ausführen können. Damit dies möglich ist, muss das System in der Lage sein, bei Bedarf um Ihre Aufmerksamkeit zu bitten, damit Sie sicher sein können, über wichtige Änderungen informiert zu werden. Überwachungssysteme verwenden dazu benutzerdefinierte Metrikschwellenwerte und Warnsysteme.

Das Ziel des Warnsystems ist es, Bediener zuverlässig zu benachrichtigen, wenn Daten auf eine wichtige Änderung hinweisen, und sie ansonsten in Ruhe zu lassen. Da dies erfordert, dass das System weiß, was Sie als signifikantes Ereignis betrachten, müssen Sie Ihre Alarmierungskriterien definieren. Warnungsdefinitionen bestehen aus einer Benachrichtigungsmethode und einem Messwertschwellenwert, den das System basierend auf eingehenden Daten kontinuierlich auswertet. Der Schwellenwert definiert normalerweise einen maximalen oder minimalen Durchschnittswert für eine Metrik über einen bestimmten Zeitraum, während die Benachrichtigungsmethode beschreibt, wie die Warnung gesendet wird.

Einer der schwierigsten Teile der Alarmierung besteht darin, ein Gleichgewicht zu finden, mit dem Sie auf Probleme reagieren können, ohne übermäßig alarmiert zu werden. Um dies zu erreichen, müssen Sie verstehen, welche Metriken die besten Anzeichen für echte Probleme sind, welche Probleme sofort behoben werden müssen und welche Benachrichtigungsmethoden für verschiedene Szenarien am besten geeignet sind. Um dies zu unterstützen, muss die Sprache für die Schwellenwertdefinition leistungsfähig genug sein, um Ihre Kriterien angemessen zu beschreiben. Ebenso muss die Benachrichtigungskomponente Kommunikationsmethoden anbieten, die für verschiedene Schweregrade geeignet sind.

Beginnend mit dem Alarmtyp mit der höchsten Priorität sindpages Benachrichtigungen, die versuchen, dringend auf ein kritisches Problem mit dem System aufmerksam zu machen. Diese Alarmkategorie sollte für Situationen verwendet werden, die aufgrund ihres Schweregrads eine sofortige Lösung erfordern. Für das Paging-System ist eine zuverlässige, aggressive Methode erforderlich, um Menschen zu erreichen, die für die Lösung des Problems verantwortlich und befugt sind.

Seiten sollten für kritische Probleme mit Ihrem System reserviert sein. Aufgrund der Art der Probleme, die sie darstellen, sind sie die wichtigsten Warnungen, die Ihr System sendet. Gute Funkrufsysteme sind zuverlässig, beständig und aggressiv genug, dass sie nicht vernünftigerweise ignoriert werden können. Um eine Antwort zu gewährleisten, enthalten Paging-Systeme häufig die Option, eine sekundäre Person oder Gruppe zu benachrichtigen, wenn die erste Seite nicht innerhalb einer bestimmten Zeitspanne bestätigt wird.

Da Seiten von Natur aus unglaublich störend sind, sollten sie sparsam verwendet werden: Nur wenn klar ist, dass ein betrieblich inakzeptables Problem vorliegt. Dies bedeutet häufig, dass Seiten mithilfe von Black-Box-Techniken an beobachtete Symptome in Ihrem System gebunden sind. Während es schwierig sein kann, die Auswirkung eines Back-End-Webhosts zu bestimmen, der die Verbindungen maximal nutzt, ist die Bedeutung Ihrer Domain, die nicht erreichbar ist, weniger zweideutig und erfordert möglicherweise eine Seite.

Der Schweregrad istnotificationswie E-Mails und Tickets. Diese sollen dauerhaft daran erinnern, dass die Betreiber eine sich entwickelnde Situation untersuchen sollten, wenn sie in der Lage sind, dies zu tun. Im Gegensatz zu Seiten weisen Benachrichtigungen nicht darauf hin, dass sofortige Maßnahmen erforderlich sind. Sie werden daher in der Regel von Mitarbeitern ausgeführt, anstatt einen Mitarbeiter auf Abruf zu benachrichtigen. Wenn in Ihrem Unternehmen nicht immer Administratoren arbeiten, sollten Benachrichtigungen an Situationen ausgerichtet werden, die bis zum nächsten Arbeitstag warten können.

Durch die Überwachung erzeugte Tickets und E-Mails helfen den Teams, die Arbeit zu verstehen, auf die sie sich konzentrieren sollten, wenn sie das nächste Mal aktiv sind. Da Benachrichtigungen nicht für kritische Probleme verwendet werden sollten, die sich derzeit auf die Produktion auswirken, basieren sie häufig auf White-Box-Indikatoren, mit denen sich auftretende Probleme vorhersagen oder identifizieren lassen, die in Kürze behoben werden müssen.

In anderen Fällen werden Benachrichtigungsalarme so eingestellt, dass sie dasselbe Verhalten wie Paging-Alarme überwachen, jedoch niedrigere, weniger kritische Schwellenwerte festlegen. Sie können beispielsweise eine Benachrichtigungswarnung definieren, wenn Ihre Anwendung über einen bestimmten Zeitraum hinweg eine geringfügige Zunahme der Latenz aufweist und eine entsprechende Seite gesendet wird, wenn die Latenz auf einen unangemessenen Wert ansteigt.

Im Allgemeinen sind Benachrichtigungen in Situationen am besten geeignet, in denen eine Reaktion erforderlich ist, die jedoch keine unmittelbare Gefahr für die Stabilität Ihres Systems darstellt. In diesen Fällen möchten Sie auf ein Problem aufmerksam machen, damit Ihr Teambeforeuntersuchen und abschwächen kann, die sich auf Benutzer auswirken oder sich in ein größeres Problem verwandeln.

Obwohl es sich technisch gesehen nicht um eine Warnung handelt, möchten Sie manchmal ein bestimmtes beobachtetes Verhalten an einem Ort feststellen, auf den Sie später problemlos zugreifen können, ohne dass jemand darauf aufmerksam gemacht wird. In diesen Situationen kann es nützlich sein, Schwellenwerte festzulegen, die lediglichlogInformationen enthalten. Diese können in eine Datei geschrieben oder zum Inkrementieren eines Zählers in einem Dashboard in Ihrem Überwachungssystem verwendet werden. Ziel ist es, schnell zusammengestellte Informationen für Ermittlungszwecke bereitzustellen, um die Anzahl der Abfragen zu verringern, die Operatoren zum Sammeln von Informationen erstellen müssen.

Diese Strategie ist nur für Szenarien sinnvoll, die eine sehr niedrige Priorität haben und keine eigene Reaktion erfordern. Ihr größter Nutzen besteht darin, verwandte Faktoren zu korrelieren und Zeitpunktdaten zusammenzufassen, auf die später als ergänzende Quellen verwiesen werden kann. Sie werden wahrscheinlich nicht viele Trigger dieses Typs haben, aber sie können in Fällen nützlich sein, in denen Sie bei jedem Auftreten eines Problems die gleichen Daten nachschlagen. Alternativen, die zum Teil dieselben Vorteile bieten, sind gespeicherte Abfragen und benutzerdefinierte Untersuchungs-Dashboards.

Wie bereits erwähnt, sind Warnungen, die auf Szenarien mit tatsächlichen Auswirkungen auf den Benutzer basieren, am besten geeignet. Dies bedeutet, dass Sie verschiedene Ausfall- oder Leistungsminderungsszenarien analysieren und verstehen, wie und wann sie zu Ebenen aufsteigen, mit denen Benutzer interagieren.

Dies setzt voraus, dass Sie die Redundanz Ihrer Infrastruktur, die Beziehung der verschiedenen Komponenten und die Ziele Ihres Unternehmens in Bezug auf Verfügbarkeit und Leistung genau kennen. Ihr Ziel ist es, die symptomatischen Kennzahlen zu ermitteln, mit denen aktuelle oder bevorstehende Probleme, die Auswirkungen auf den Benutzer haben, zuverlässig angezeigt werden können.

Nachdem Sie symptomatische Messwerte ermittelt haben, besteht die nächste Herausforderung darin, die geeigneten Werte zu ermitteln, die als Schwellenwerte verwendet werden sollen. Möglicherweise müssen Sie Trial-and-Error verwenden, um die richtigen Schwellenwerte für einige Metriken zu ermitteln.

Überprüfen Sie, falls verfügbar, die historischen Werte, um festzustellen, welche Szenarien in der Vergangenheit behoben werden mussten. Es empfiehlt sich, für jede Metrik einen "Notfall" -Schwellenwert zu definieren, der eine Seite auslöst, sowie einen oder mehrere "kanarische" Schwellenwerte, die mit Nachrichten mit niedrigerer Priorität verknüpft sind. Bitten Sie nach dem Definieren neuer Warnungen um Feedback, ob die Schwellenwerte zu aggressiv oder zu empfindlich waren, damit Sie das System optimal an die Erwartungen Ihres Teams anpassen können.

Durch die Minimierung der Zeit, die Antwortende benötigen, um Probleme zu untersuchen, können Sie sich schneller von Vorfällen erholen. Zu diesem Zweck ist es hilfreich, den Kontext innerhalb des Warnungstextes anzugeben, damit die Bediener die Situation schnell verstehen und mit den entsprechenden nächsten Schritten beginnen können.

In Warnmeldungen sollten die betroffenen Komponenten und Systeme, der ausgelöste Messwertschwellenwert und der Zeitpunkt, zu dem der Vorfall begann, klar angegeben werden. Die Warnung sollte auch Links enthalten, über die Sie weitere Informationen abrufen können. Dies können Links zu bestimmten Dashboards sein, die mit der ausgelösten Metrik verknüpft sind, Links zu Ihrem Ticketing-System, wenn automatisierte Tickets generiert wurden, oder Links zu der Warnseite Ihres Überwachungssystems, auf der ein detaillierterer Kontext verfügbar ist.

Ziel ist es, dem Bediener genügend Informationen zur Verfügung zu stellen, um seine erste Reaktion zu steuern und ihn dabei zu unterstützen, sich auf den jeweiligen Vorfall zu konzentrieren. Es ist weder erforderlich noch empfehlenswert, alle Informationen, die Sie über das Ereignis haben, anzugeben. Wenn Sie jedoch grundlegende Details mit einigen Optionen für den nächsten Schritt angeben, kann dies die anfängliche Erkennungsphase Ihrer Antwort verkürzen.

Warnungen sind nicht nützlich, wenn sie nicht umsetzbar sind. Ob eine Warnung umsetzbar ist, hängt häufig vom Kenntnisstand, der Erfahrung und der Berechtigung der antwortenden Person ab. Für Unternehmen einer bestimmten Größe ist die Entscheidung für die zu übermittelnde Person oder Gruppe in einigen Fällen unkompliziert und in anderen Fällen nicht eindeutig. Die Entwicklung einer Rotation auf Abruf für verschiedene Teams und die Ausarbeitung eines konkreten Eskalationsplans können einige der Unklarheiten bei diesen Entscheidungen beseitigen.

Die Bereitschaftsrotationen sollten genügend fähige Personen umfassen, um ein Ausbrennen zu vermeiden und Müdigkeit zu alarmieren. Am besten ist es, wenn Ihr Warnsystem einen Mechanismus zum Planen von Bereitschaftsschichten enthält. Andernfalls können Sie Verfahren zum manuellen Drehen der Warnkontakte basierend auf Ihren Zeitplänen entwickeln. Möglicherweise verfügen Sie über mehrere Rufbereitschaftsrotationen, die von den Eigentümern bestimmter Teile Ihres Systems ausgefüllt werden.

Ein Eskalationsplan ist ein zweites Tool, mit dem sichergestellt wird, dass Vorfälle an die richtigen Personen weitergeleitet werden. Wenn Ihre Systeme rund um die Uhr von Mitarbeitern besetzt sind, ist es am besten, vom Überwachungssystem generierte Warnungen an Mitarbeiter im Schichtdienst zu senden, und nicht an die Bereitschaftsdienst-Rotation. Die Antwortenden können dann selbst Abhilfemaßnahmen ergreifen oder sich dafür entscheiden, Bereitschaftsbetreiber manuell zu melden, wenn sie zusätzliche Hilfe oder Fachkenntnisse benötigen. Ein Plan, der festlegt, wann und wie Probleme eskaliert werden, kann unnötige Warnungen minimieren und das Gefühl der Dringlichkeit bewahren, das Seiten darstellen sollen.