--- sourceDocument: IT-Betriebsmanagement in Australien sourceDocumentLink: https://www.servicenow.com/docs/r/de-DE/australia/it-operations-management Release : - australia ft:locale : - de-DE ft:publication_title : - IT-Betriebsmanagement in Australien ft:clusterId : - itom bundleId : - itom workflow : - Technology --- # Warnungsübersicht # Eine Übersicht zu Warnungen für Ereignismanagement Operatoren {#ariaid-title1} Freigeben Version: Australia Aktualisiert 12. März 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 Minuten Lesedauer 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 in Ereignismanagement Tutorial. |-|-|-| | Lektion 1 | ![Übersichtssymbol]() | Eine Übersicht über Ereignisse und Warnungen | | Lektion 2 | ![Übersicht über BS-Symbol]() | [Eine Übersicht über Anwendungsservices](https://www.servicenow.com/docs/zsmpfOLtepot2Dw3qyIAlg "Als Ereignismanagement Operator, Sie müssen verstehen, was Anwendungsservices sind.") | | Lektion 3 | ![Symbol für Übersichtsoperator]() | [Ereignismanagement Operator-Arbeitsbereiche](https://www.servicenow.com/docs/4P~Wh5gn1vnb6VfF3GCY8Q "Als Ereignismanagement Operator, Ihre primäre Arbeitsumgebung ist der Dashboard „Servicevorgänge-Arbeitsbereich“.") | | Lektion 4 | ![Symbol „Übersicht darüber, was Operatoren tun“]() | [Was Operatoren tun](https://www.servicenow.com/docs/u8Ksx8oUfE7eyK7j2VsWbw "Als Ereignismanagement Operator, Ihr typischer Workflow umfasst drei Phasen: Analyse einer Warnung und ihrer Auswirkungen auf Anwendungsservices, Durchführung einer Art von Aktion und Sicherstellung, dass die Warnung endgültig geschlossen wird.") | [ ] {#operator-events-alerts__table_or3_vg3_3db} Ihre Organisation verfügt bereits über ein Ereignisüberwachungstool, z. B. Microsoft System Center Operations Manager (SCOM), Nagios, SolarWinds usw. Wenn in Ihrem Netzwerk ein Problem auftritt, z. B. ein Computer ausfällt oder ein Datenbankfehler, senden die Ereignisüberwachungstools Ereignisse An Ihr ServiceNow Instanz. Die Ereignismanagement Die Anwendung verarbeitet Ereignisse Entsprechend den Einstellungen, die Ihr Administrator konfiguriert und dann generiert hat Warnungen . Eine Warnung ist ein Indikator dafür, dass das Problem eine Art von Aktion erfordert. Abbildung : 1. Warnungsgenerierung Als Ereignismanagement Operator, Ihre Rolle besteht darin, Warnungen und anzuzeigen, je nachdem, wie Ereignismanagement Ist in Ihrer Organisation implementiert. Ergreifen Sie eine Aktion, um das zugrunde liegende Problem zu lösen, oder benachrichtigen Sie jemanden, der dies kann. Später in diesem Tutorial sehen Sie die Phasen eines typischen Warnungsverwaltungsprozesses. ## Warnungspriorität und -Schweregrad {#operator-events-alerts__section_jzt_gf1_gdb} Die beiden häufigsten Merkmale einer Warnung sind die Priorität und der 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 Punktzahl der Warnungspriorität. Ihr Ereignismanagement Administrator kann den Algorithmus konfigurieren, der verwendet wird Ereignismanagement Anwendung verwendet zum Berechnen der Priorität. * Die Schweregrad Einer Warnung ist ein Indikator dafür, wie schwerwiegend das zugrunde liegende Problem ist. Das Ereignisüberwachungstool in Ihrer Organisation sendet normalerweise Schweregradwerte mit dem Ereignis, die dann in die Warnung übertragen werden. Dies sind die Standardschweregradtypen, die in diesem Tutorial angezeigt werden: {#operator-events-alerts__table_egv_c31_gdb__entry__2} | Schweregrad | Beschreibung | |-|-| | ![Ressourcensymbol]() Kritisch | Die Ressource ist entweder nicht funktionsfähig, oder kritische Probleme stehen bevor. | | ![Funktionalitätssymbol]() Schwerwiegend | Wesentliche Funktionalität ist stark beeinträchtigt, oder die Leistung hat sich verschlechtert. | | ![Symbol „Nebenwert“]() Gering | Teilweiser, nicht kritischer Verlust der Funktionalität oder Leistungsverschlechterung ist aufgetreten. | | ![Warnsymbol]() Warnung | Aufmerksamkeit ist erforderlich, auch wenn die Ressource noch funktionsfähig ist. | | ![OK-Symbol]() OK | Kein Schweregrad. Eine Warnung wird erstellt. Die Ressource funktioniert noch. | | ![Symbol „Löschen“]() Löschen | Die Warnung erfordert keine Aktion mehr. | [ ] {#operator-events-alerts__table_egv_c31_gdb} {#operator-events-alerts__ul_jsq_3f1_gdb} ## Korrelierte Warnungen {#operator-events-alerts__section_emk_tzz_fdb} Einige Warnungen beziehen sich zueinander. Wenn beispielsweise ein Router ausfällt, können mehrere separate Warnungen generiert werden, eine für jeden mit dem Router verbundenen Server. Alle diese Warnungen beziehen sich auf oder Korreliert . Damit Sie korrelierte Warnungen verwalten können, Ereignismanagement Kann sie automatisch gruppieren und eine zweistufige Hierarchie mit einer Stammwarnung einrichten, die als bezeichnet wird Primäre Warnung , Oben und andere zugehörige Warnungen, aufgerufen Sekundäre Warnungen , Unter der primären Warnung. Wenn Sie Warnungen anzeigen, heben sich primäre Warnungen standardmäßig ab, damit Sie wissen, auf welche Warnung Sie sich konzentrieren sollen, ohne von den sekundären Warnungen abgelenkt zu werden. In unserem Beispiel ist, wenn ein Router in Ihrem Netzwerk ausfällt, die Netzwerkkommunikation auch für verbundene Server betroffen, vorausgesetzt, sie 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. Generierung sekundärer Warnungen Abhängig von den Ihrer Organisation Ereignismanagement Implementierung können Warnungen automatisch basierend auf Korrelationsregeln gruppiert werden, die Ihr Administrator eingerichtet hat. Ihre Instanz kann auch lernen, wie Sie die Korrelation von Warnungen basierend auf diesen Regeln verbessern können. Als Operator sollten Sie weiterhin die Richtigkeit der Korrelation überprüfen und bei Bedarf zusätzliche Warnungen manuell mit der primären Warnung korrelieren. Später im Tutorial erfahren Sie, wie Sie dies tun. In diesem Tutorial erfahren Sie, wie Sie Warnungen manuell korrelieren. ## Warnungsfluktuation {#operator-events-alerts__section_nz4_k5x_hdb} Eine Warnung kann fluktuieren, was bedeutet, dass mehrere offene/geschlossene Ereignisse in schneller Folge angezeigt werden. Fluktuationen zeigen das an Ereignismanagement Weiß nicht, ob die zugrunde liegenden Ereignisse echt sind oder nicht. Die Ereignisse können auf kleine Probleme mit der Konfiguration von CIs oder größere Probleme wie Netzwerkausfälle hinweisen. Abbildung : 3. Warnungsfluktuation Wenn beispielsweise ein Server, der einen Webservice hostet, zu viele aktive Prozesse hat, kann dies ein Ereignis über eine übermäßige CPU-Auslastung auslösen. Da die CPU-Auslastung abhängig von Webserviceanforderungen schnell fluktuieren kann, können mehrere Ereignisse ausgelöst werden, was dazu führt, dass die Warnung in den Fluktuationsstatus versetzt wird. Als Operator müssen Sie möglicherweise einen Incident erstellen, damit der Server neu gestartet wird, oder jemand muss die CPU neu konfigurieren oder möglicherweise eine Hardwareänderung am Gerät vornehmen. Betrachten Sie als weiteres Beispiel ein loses Netzwerkkabel, das kurzzeitige, wiederholte Netzwerkausfälle verursacht. Die von Ihrem Administrator konfigurierten Schwellenwerte sind möglicherweise nicht optimal für diese Art von Warnung und Ereignismanagement Betrachtet es als eine fluktuierende Warnung. ## Setzen Sie das Tutorial fort {#operator-events-alerts__section_rrw_zpx_hdb} Fahren Sie mit der nächsten Lektion fort: [Anwendungsservices für Ereignismanagement Operatoren](https://www.servicenow.com/docs/zsmpfOLtepot2Dw3qyIAlg "Als Ereignismanagement Operator, Sie müssen verstehen, was Anwendungsservices sind.").