Eine Übersicht zu Warnungen für Ereignismanagement Operatoren

Als Ereignismanagement Operator müssen Sie wissen, wie eine Warnung aus einem Event generiert wird, worauf Sie bei Warnungen achten müssen und wie Warnungen gruppiert werden können.

Dies ist die erste Lektion im Ereignismanagement Tutorial.

Lektion 1		Übersicht über Events und Warnungen
Lektion 2		Übersicht über die Anwendungsservices
Lektion 3		Ereignismanagement Operator-Arbeitsbereiche
Lektion 4		Was Operatoren tun

Ihre Organisation verfügt bereits über ein Tool für die Event-Überwachung, z. B. Microsoft System Center Operations Manager (SCOM), Nagios, SolarWinds usw. Wenn ein Problem in Ihrem Netzwerk auftritt, z. B. wenn ein Computer oder eine Datenbank ausfällt, senden die Event-Überwachungstools verschiedene Events an Ihre ServiceNow Instanz. Die Anwendung Ereignismanagement verarbeitet die Events gemäß den vom Administrator konfigurierten Einstellungen und generiert dann Warnungen. Eine Warnung ist ein Indikator dafür, dass Probleme eine Aktion erfordern.

Abbildung : 1. Warnungsgenerierung

Als Ereignismanagement-Bediener besteht Ihre Rolle darin, Warnungen anzuzeigen und je nachdem, wie Ereignismanagement in Ihrer Organisation implementiert ist, eine Aktion zur Behebung des zugrunde liegenden Problems durchzuführen oder jemanden zu diesem Zweck zu benachrichtigen. Später in diesem Tutorial werden die Phasen eines typischen Warnungsverwaltungsprozesses erläutert.

Warnungspriorität und Schweregrad

Die zwei häufigsten Merkmale einer Warnung sind Priorität und Schweregrad.

• Die Priorität einer Warnung ist eine Punktzahl, mit der Sie bestimmen können, wie wichtig die Auswirkung für Anwendungsservices ist. Mehrere Faktoren bestimmen die Prioritätspunktzahl der Warnung. Ihr Ereignismanagement Administrator kann den Algorithmus konfigurieren, den die Anwendung Ereignismanagement zur Berechnung der Priorität verwendet.
• Der Schweregrad einer Warnung ist ein Indikator dafür, wie schwerwiegend das zugrunde liegende Problem ist. Das Tool zur Event-Überwachung in Ihrer Organisation übermittelt normalerweise Schweregradwerte mit dem Event, die dann für die Warnung übernommen werden. Die folgenden standardmäßigen Typen von Schweregraden werden in diesem Tutorial vorgestellt:

  Schweregrad	Beschreibung
  Kritisch	Die Ressource funktioniert entweder nicht, oder kritische Probleme stehen unmittelbar bevor.
  Schwerwiegend	Wichtige Funktionalität ist schwer beeinträchtigt, oder die Leistung hat sich verschlechtert.
  Geringfügig	Ein partieller, nicht kritischer Verlust der Funktionalität oder eine Leistungsverschlechterung ist aufgetreten.
  Warnung	Aufmerksamkeit ist erforderlich, obwohl die Ressource noch funktionsfähig ist.
  OK	Kein Schweregrad Eine Warnung wird erstellt. Die Ressource ist weiterhin funktionsfähig.
  Löschen	Die Warnung benötigt keine Aktion mehr.

Korrelierte Warnungen

Einige Warnungen sind miteinander verknüpft. Wenn beispielsweise ein Router ausfällt, werden ggf. mehrere separate Warnungen generiert, eine für jeden mit dem Router verbundenen Server. Alle diese Warnungen sind miteinander verbunden oder korreliert. Um Sie bei der Verwaltung korrelierter Warnungen zu unterstützen, kann Ereignismanagement diese automatisch gruppieren. Dabei wird eine zweistufige Hierarchie eingerichtet, mit einer Stammwarnung, der so genannten primären Warnung, und anderen zugehörigen Warnungen, den sogenannten sekundären Warnungen. Wenn Sie Warnungen anzeigen, werden primäre Warnungen standardmäßig hervorgehoben. So wissen Sie immer sofort, auf welche Warnung Sie sich konzentrieren müssen, ohne von den sekundären Warnungen abgelenkt zu werden.

Wenn in unserem Beispiel ein Router in Ihrem Netzwerk ausfällt, ist die Netzwerkkommunikation auch für verbundene Server betroffen, vorausgesetzt, diese können keine anderen Router erreichen. Der Routerausfall wird zur primären Warnung, und die auf dem Server generierten Warnungen sind sekundäre Warnungen, die unter der Routerwarnung korreliert werden.

Abbildung : 2. Sekundäre Warnungsgenerierung

Abhängig von der Ereignismanagement-Implementierung in Ihrer Organisation werden Warnungen ggf. automatisch gruppiert, und zwar abhängig von den vom Administrator eingerichteten Korrelationsregeln. Ihre Instanz kann auch lernen, wie sie die Korrelation von Warnungen basierend auf diesen Regeln verbessern kann. Als Operator sollten Sie dennoch stets die Genauigkeit der Korrelation verifizieren und bei Bedarf zusätzliche Warnungen manuell mit der primären Warnung korrelieren. Später im Tutorial erfahren Sie, wie Sie dies tun können.

In diesem Tutorial erfahren Sie, wie Warnungen manuell korreliert werden.

Fluktuierende Warnung

Eine Warnung kann „flattern“, wobei sie in schneller Abfolge mehrere Ereignisse vom Typ „Öffnen“ / „Schließen“ erhält. Flattern weist darauf hin, dass Ereignismanagement nicht weiß, ob die zugrundeliegenden Events echt sind oder nicht. Die Events können auf kleine Probleme mit der CI-Konfiguration hindeuten, oder aber auf größere Probleme, z. B. einen Netzwerkausfall.

Abbildung : 3. Fluktuierende Warnung

Nehmen wir zum Beispiel einen Server an, der einen Webservice hostet. Wenn der Server zu viele aktive Prozesse aufweist, wird ggf. ein Event aufgrund übermäßiger CPU-Auslastung ausgelöst. Da die CPU-Auslastung je nach Web-Serviceanfragen schnell schwanken kann, werden eventuell mehrere Ereignisse ausgelöst, wodurch die Warnung in den Status „Fluktuierend“ versetzt wird. Als Operator müssen Sie möglicherweise einen Incident erstellen, um den Server neu zu starten; vielleicht muss auch die CPU neu konfiguriert oder eine Hardwareänderung am Gerät vorgenommen werden.

Ein weiteres Beispiel ist ein lockeres Netzwerkkabel, das vorübergehende, wiederholte Netzwerkausfälle verursacht. Die vom Administrator konfigurierten Schwellenwerte sind für diese Art von Warnung möglicherweise nicht optimal, daher geht Ereignismanagement von einer fluktuierenden Warnung aus.

Tutorial fortsetzen

Fahren Sie mit der nächsten Lektion fort: Anwendungsservices für -Operatoren Ereignismanagement ..