Ereignismanagement Konfigurationseinstellungen

Bevorzugte Einstellungen von Eigenschaften und allgemeine Konfiguration.

Verwenden Sie Known Error-Portal Und Community Um Ihnen weiter bei der Suche nach Informationsproblemen zu helfen.

Allgemeine Einstellungen

Selbstgesundheit

Standardmäßig ist die Selbstintegritätsüberwachungsfunktion nicht aktiviert. Navigieren Sie zum Aktivieren zu Ereignismanagement > Einstellungen > Eigenschaften Und wählen Sie aus Ja Für Enable Event Management self-health monitoring(evt_mgmt.self_health_active)-Eigenschaft. Verwenden Sie diese Funktion, um viele zu überwachen und nachzuverfolgen EreignismanagementFunktionen.

Hinweis:

CIs, die im SelfHealth-Service verwendet werden, werden in der CMDB erstellt.

Verwenden Sie die folgenden Einstellungen, um eine Verschlechterung der Leistung zu verhindern.

Thema	Details
Geschäftsregeln	Vermeiden Sie das Schreiben von Business-Regeln für Ereignis-[em_event]-Tabellen, da sie nicht in der aktuellen Standard-REST-URL ausgeführt werden, die für die Ereigniseinschleusung verwendet wird. Business-Regeln, die für Warnungstabellen [em_Alert] geschrieben werden, müssen hocheffizient sein, da sie andernfalls zu einer Verschlechterung der Leistung führen können. Anstatt eine Business-Regel zu schreiben, überlegen Sie, ob es angemessener ist, einen Auftrag zu schreiben. Eine ineffiziente Business-Regel kann dazu führen, dass die Incident-Erstellung fehlschlägt, wenn eine Warnung fehlschlägt und die Berechnung der Warnungsauswirkung fehlschlägt. Schreiben Sie keine asynchronen Business-Regeln für Warnungstabellen. Business-Regeln dürfen nicht ändern Kategorie Feld in Ereignistabellen [em_event].
Hochskalieren	Überprüfen Sie die durchschnittliche Ereignisverarbeitungszeit, bevor Sie den Ereignisdurchsatz erhöhen, wenn Sie mit beginnen Ereignismanagement. Führen Sie diese Prüfung durch, nachdem ein anfänglicher Flow von Ereignissen und alle Regeln vorhanden sind. Wenn die Verarbeitungszeit pro Ereignis einige Millisekunden dauert, bestimmen Sie die Ursache für die Verlangsamung der Verarbeitung, bevor Sie mit der Skalierung fortfahren. Die Leistungsdauer kann in der Tabelle „Leistungsstatistiken“ [sa_Performance_statistics] überprüft werden.
Konfigurieren Sie für große Umgebungen	Legen Sie fest Aktivieren Sie die Ereignisverarbeitung mit mehreren Knoten ( evt_mgmt.event_processor_enable_multi_node)-Eigenschaft bis Ja . Aktivieren Sie mehrere Knoten in Produktionsumgebungen, und legen Sie Werte basierend auf der Größe der Bereitstellung und der erwarteten Ereignisrate fest. Legen Sie fest Anzahl der geplanten Aufgaben, die Ereignisse verarbeiten ( evt_mgmt.event_processor_job_count)-Eigenschaft bis 4 . Wenn Sie Ereignisse aus einer anwenderdefinierten Quelle senden, überprüfen Sie, ob Ereignisse haben Nachrichtenschlüssel Oder Quelle , Knoten , Typ , Und Ressource Daten.
Latenzprobleme für den Empfang von Ereignissen	Überprüfen Sie die folgenden Einstellungen: Überprüfen Sie, ob Bucket Feld in der Tabelle „Ereignis“ [em_event] ist auf einen Wert festgelegt, der größer als null ist ( 0). Navigieren zu Systemzeitplaner > Geplante Aufgaben Und suchen nach - process events*. Überprüfen Sie das alles - process events*Aufträge sind gemäß vorhanden Anzahl der geplanten Aufgaben, die Ereignisse verarbeiten ( event_processor_job_count) Eigenschaftskonfiguration. Überprüfen Sie, ob Status Ist RunningOder Ready. Wenn der Status ist QueuedOder Error, Legen Sie den Auftragsstatus auf fest Ready.
Ereignisse archivieren	Vermeiden Sie es, die standardmäßige Aufbewahrungszeit für Ereignisse zu ändern. Um Ereignisse länger zu protokollieren, erstellen Sie eine Archivtabelle und einen Auftrag, der neue Ereignisse darin kopiert. Planen Sie dazu einen Auftrag, um Ereignisse [em_event] regelmäßig in einer anwenderdefinierten Tabelle zu sichern. Erweitern Sie die Tabellenrotation nicht, indem Sie weitere Tage hinzufügen.

Ereignisintegration

SNMP-Traps

• Verwenden Sie ein Überwachungstool, um SNMP-Traps zu senden, anstatt sie direkt von Geräten zu senden.
• Um zu vermeiden, dass Ereignisregeln neu geschrieben werden müssen, laden Sie MIBs hoch, bevor Sie die Ereignisregeln definieren.

Webservice-API

• Die Verwendung einer Webservice-API für die Integration kann die Anzahl der erforderlichen Ereignisregeln reduzieren. Mit dieser Aktion wird vermieden, dass Ereignisse transformiert werden müssen (vorbereitete Daten werden in einem Ereignis an die Instanz gesendet).
• Verwenden Sie dedizierte Anmeldeinformationen für die Integration. Legen Sie optional Anmeldeinformationen fest, die für jede Ereignisquelle spezifisch sind.

CloudWatch

Verwenden Sie dedizierte Anmeldeinformationen für die Integration von CloudWatch mit ServiceNow.

E-Mail

Verwenden Sie E-Mail nur, wenn die Quelle ein geringes Volumen hat und andere Optionen nicht verfügbar sind, z. B. das Ausführen eines Skripts oder das Weiterleiten eines SNMP-Traps.

Ereignisregeln

Konfigurationseinstellungen beim Erstellen von Ereignisregeln:

• Schreiben Sie Ereignisregeln, die auf die größtmögliche Anzahl von Ereignissen angewendet werden sollen. Spezifischere Regeln können dann nach Bedarf erstellt werden und sollten einen niedrigeren Wert verwenden.
• Wenn eine allgemeinere Regel dasselbe Ergebnis erzielen kann, vermeiden Sie das Schreiben von Ereignisregeln, die nur für eine bestimmte Teilmenge von Ereignissen gelten.
• Wenn Ereignisregeln auf Ereignisse angewendet werden, werden keine Änderungen am ursprünglichen Ereignis vorgenommen. Die gesamte Verarbeitung erfolgt im Arbeitsspeicher. Verwenden Sie daher Verarbeitungsnotizen Feld und/oder verwenden Überprüfen Sie den Prozess des Ereignisses UI-Aktionslink zur Problembehandlung.
• Wenn Sie eine Regel/Transformation ändern, die über vorhandene Zuordnungsregeln verfügt, sollten Sie Ereignisse überprüfen und erneut testen, die entweder tatsächlich oder simuliert sind.
• Stellen Sie sicher, dass Von Der Feldwert stimmt genau mit einer Zeichenfolge in der JSON in überein additional_infoFeld eines Ereignisses. Dieser Abgleich erfolgt, wenn eine Regel basierend auf Informationen in einer MIB-Datei konfiguriert wurde. Wenn die MIB-Datei nicht hochgeladen wird, zeigt die JSON für die SNMP-Trap Varbinds (Variablenbindung) mit Punktnamen anstelle des übersetzten Namens in der MIB an. Die Ereignisfeldzuordnungsregel kann dann nicht angewendet werden.
• Richten Sie eine konsistente Benennungskonvention ein. Eine allgemeine Konvention ist: <customer acronym>.<Event Source>.<Description>. Beispiel: ACME.OEM.Normalize
• Wenn für zwei Ereignisregeln ähnliche Bedingungen festgelegt sind, verwenden Sie Reihenfolge Feld, um zu steuern, welche Ereignisregel ausgeführt wird.
• Verwenden Sie Ereignisregeln, um eine Warnung einem CI zuzuordnen.

Zusätzliche Einstellungen zum Erstellen von Ereignisregeln:

Gewünschtes Ergebnis	Erforderliche Aktivität
Effektive Deduplizierung und effiziente parallele Ereignisverarbeitung	Füllen Sie aus Quelle , Knoten , Typ , Ressource , Metrikname Felder.
CI-Bindung	An Host binden – durch Ausfüllen von Knoten Feld und optional CI-Bezeichner . Bindung an Anwendung und/oder Gerät – durch Ausfüllen von CI-Bezeichner Feld und Zusätzliche Informationen Feld.
Warnungskorrelation mit Warnungszusammenfassung	Füllen Sie aus Ressource Und Metrikname Felder. Hinweis: Wenn auch CI gebunden ist, wird die Warnungskorrelation verbessert.

Anwenderdefinierte Ereignisfelder

Schließen Sie zusätzliche Felder in ein Zusätzliche Informationen Nur Feld des Ereignisses.

Fügen Sie einem Ereignis keine zusätzlichen Felder hinzu, indem Sie der Ereignistabelle [em_event] ein anwenderdefiniertes Feld hinzufügen.

Fügen Sie der Ereignistabelle [em_event] keine Spalten hinzu.

Informationen zum Einfügen zusätzlicher Felder in Ereignisse finden Sie unter Anwenderdefinierte Warnungsfelder.

Deduplizierung

Konfigurationseinstellungen für Deduplizierung.

• Die Message_key Feld wird für die Deduplizierung verwendet. Wenn dem Quellereignis keine zuverlässigen Nachrichtenschlüsselwerte bereitgestellt werden, ist ein klar definierter Plan zum Erstellen dieser Bezeichner wichtig.
• Wenn der Nachrichtenschlüssel nicht definiert ist, ist der Standardnachrichtenschlüssel <Source + Node + Type + Resource + Metric Name> .
• Die Richtlinie besteht darin, dass die Ereignisquelle ausfüllt <Source + Node + Type + Resource + Metric Name>Sofort einsatzbereite Felder und füllen den Nachrichtenschlüssel aus. Diese Aktion ermöglicht eine bessere Verteilung der Ereignisverarbeitung auf Instanz-Worker und Knoten.
• Wenn das Quellereignis keine Werte für diese Felder enthält, stellen Sie sicher, dass Sie sie mit Transformationsregeln ausfüllen. Diese Aktion wirkt sich nicht auf die Ereignisverarbeitung aus, wird jedoch für die Deduplizierung verwendet. Füllen Sie so viele dieser Felder wie möglich aus, bevor sie an die Instanz gesendet werden. Diese Aktion bietet eine bessere Verteilung von Ereignissen über die Prozessor-Worker und somit einen besseren Durchsatz und eine bessere Skalierung.

CI-Bindung

• Versuchen Sie nach Möglichkeit immer, eine Warnung an ein CI zu binden.
  Hinweis:

  Obwohl Ereignisregeln für Ereignisse definiert sind, sind CIs an Warnungen gebunden, die sich aus diesen Ereignissen ergeben, und sind nicht an das Ereignis gebunden.
• Füllen Sie das Ereignis aus, um einen Host, einen Computer oder ein beliebiges Gerät mit einer IP zu binden Knoten Feld mit einem eindeutigen Hostnamen, FQDN, IP oder MAC-Adresse. Wenn andere Bezeichner erforderlich sind, um einen Host zu identifizieren, füllen Sie das Feld „ci_Identifiers“ im JSON-Format aus. Das JSON-Format muss enthalten CMDB Feldname und -Wert, um die Übereinstimmung durchzuführen.
  Hinweis:

  Das Ereignis Knoten Das Feld muss aus einer Ereignisregel oder mit einem eindeutigen Hostnamen aus der Quelle ausgefüllt werden, bevor das Ereignis eingefügt wird.
• Die primäre Bindungsstrategie besteht in der Verwendung von Knoten Feld. Wenn Knoten Feld ist im Ereignis nicht vorab ausgefüllt. Es kann mit Ereignisregeln ausgefüllt werden.

Warnungseinstellungen

Warnungslebenszyklus

Allgemeine Warnungsfunktionalität:

• Eine Warnung wird geöffnet, wenn ein Ereignis nicht ignoriert wird oder sein Schwellenwert von einer Ereignisregel überschritten wird, und durch die Deduplizierung wird das Ereignis nicht als zu einer vorhandenen Warnung gehört.
• Eine Warnung wird geschlossen, wenn ein Abschlussereignis über denselben Nachrichtenschlüssel gesendet wird, oder die Warnung wird manuell geschlossen.
• Eine Warnung wird erneut geöffnet, wenn eine Eröffnungswarnung mit demselben Nachrichtenschlüssel innerhalb des in den Eigenschaften definierten Zeitrahmens gesendet wird (Standard ist eine Stunde).
• Wenn eine Warnung mit hoher Geschwindigkeit geöffnet und geschlossen wird, wie in den Eigenschaften definiert, wird sie fluktuierend. Wenn diese Eröffnungs- und Abschlussrate endet, verlässt die Warnung den Status „Fluktuation“.
• Wenn ein Incident über eine Warnung geöffnet wird, bleibt diese Warnung offen, solange der Incident offen bleibt. Standardmäßig wird auch der andere geschlossen, wenn entweder der Incident oder die Warnung geschlossen wird. Dieses Verhalten kann mithilfe von Eigenschaften konfiguriert werden.
• Schließen Sie keine Warnung, wenn Sie einen entsprechenden Incident erstellen.
• Löschen Sie keine offene Warnung. Schließen Sie zuerst eine Warnung, und löschen Sie sie dann.
• Verwenden Bestätigen Um anzugeben, dass die Warnung bekannt ist und vorübergehend ignoriert werden kann.
• Nicht verwenden Bestätigen Zum Markieren einer Warnung als Handlungsbedarf.
• Erstellen Sie keine Warnungen in einem der folgenden status:
  • Geschlossen
  • OK
  • Offen
• Die evt_mgmt.alert_auto_close_interval Eigenschaft schließt Warnungen automatisch nach dem angegebenen Zeitraum. Geben Sie nicht 0 an, da dieser Wert die Funktion deaktiviert und zu einer Verschlechterung der Leistung führen kann.
• Erstellen Sie keine Warnungen in OK status. In einigen Überwachungssystemen OK Gibt an, dass ein Problem in anderen Überwachungssystemen gelöst wurde OK Wird verwendet, um Ereignisse anzugeben, die nicht von operativer Bedeutung sind. Verwenden Sie für den vorherigen Fall Löschen Anstelle von OK Verwenden einer Zuordnungsregel. Für den letzteren Fall ist eine Regel zum Ignorieren vorhanden, es sei denn, die Ereignisse haben einen bestimmten Wert.

Warnungsaktionsregeln

• Eine geplante Aufgabe wendet Warnungsaktionsregeln alle 11 Sekunden auf neue Warnungen an. Wenn eine Warnungsregel nicht sofort startet, warten Sie 10 bis 15 Sekunden, bevor Sie mit der Fehlerbehebung beginnen.
• Verwenden Sie Reihenfolge Feld, um zu steuern, welche Warnungsregel ausgeführt wird, wenn für zwei Warnungsregeln ähnliche Bedingungen festgelegt sind.
• Verwenden Sie Warnungsaktionsregeln mit Aufgabenvorlagen, um statische Werte in einem Incident auszufüllen. Verwenden Sie das Populator-Skript, um dynamische Werte im Incident zuzuweisen. Das Populator-Skript kann einen Wert von zurückgeben Falsch Zum Abbrechen der Incident-Erstellung.
• Erstellen Sie einen Anwender namens Ereignismanagement(Oder ein ähnlicher Name). Dann die Erstellt von Feld in einer Aufgabenvorlage (z. B. Incident ) Kann festgelegt werden, um anzugeben, dass der Anwender die Quelle der Aufgabe war.
• Verwenden Sie zum Durchführen einer dynamischen Wertzuweisung oder zum Überschreiben der dynamischen OOB-Wertzuweisung EvtMgmtCustomIncidentPopulator Skripteinbindung.

Fehlerkorrektur

• Legen Sie Orchestration-Workflow-Eigenschaften immer auf die Tabelle „Korrekturaufgabe“ [em_Remediation_Task] fest.
• ECC-Warteschlange und verwenden Workflow > Live-Workflow > Alle Kontexte Um detailliertere Informationen zu Korrekturaktivitäten zu erhalten.

Geschäftsregeln

• Business-Regeln, die in Warnungstabellen erstellt werden, dürfen nicht länger als einige Millisekunden dauern. Überlegen Sie anstelle einer Business-Regel, ob die gleiche Funktionalität mit einem Auftrag erreicht werden kann.
• Verwenden Sie keine Business-Regeln, um eine Warnung einem CI zuzuordnen. Verwenden Sie Ereignisregeln, um eine Bindung durchzuführen, anstatt Business-Regeln zu verwenden.

Planung

• Organisieren Sie die Ereignisquellenkonfiguration von Filtern, Modulen usw. in mehreren parallelen Maßnahmen anstatt in serieller Reihenfolge.
• Validieren Sie verarbeitete Ereignisformate, um sicherzustellen, dass die analysierten Daten an den gewünschten Ergebnissen ausgerichtet sind.
• Testen Sie Produktionsereignisse in einer nicht-Produktionsumgebung. Integration mit nicht-Produktions-Elementmanagern und ServiceNowInstanzen. Wenn nicht-Produktions-Elementmanager verfügbar sind, senden Sie Ereignisse von Elementmanagern an Produktions- und nicht-Produktionsumgebungen.

Services und Dashboard

• Verwenden Sie Servicegruppen, um Services in logische Gruppen zu gruppieren, um die Anzahl der im Dashboard „Serviceintegrität“ angezeigten Services zu reduzieren.
• Importieren Sie manuell erstellte Servicezuordnungen.

Metrikdaten Sammlerprotokolle und -Dateien

MetrikdatenSammlerprotokolle und -Dateien befinden sich unter dem Pfad $(MID_SERVER_DIR)/AGENT . Verwenden Sie diese Protokolle und Dateien für Problembehandlungs- und Überwachungszwecke.

Tabelle : 1. Standort von MetrikdatenSammlerprotokolle und -Dateien

Protokoll oder Datei	Pfad
PowerShell-Metriksammler-Protokolldatei	Logs/Retrieve_metrics{Connector-Instanz-ID}.log
PowerShell-Ausgabedatei	Work/metrics/metrics_output_{Connector-Instanz-ID}.txt
PowerShell-Eingabedatei	Arbeit/Metriken/Parameter_{Connector-Instanz-ID}.txt

MetrikdatenDie Leistung kann in überprüft werden MID-ServerProtokolldatei, wenn mid.log.level MID-ServerParameter befindet sich im Debug-Modus.

Metrikdaten Leistungsnummern sind in der Tabelle „Leistungsstatistiken“ [sa_Performance_statistics] verfügbar. Um die Leistungsnummern anzuzeigen, filtern Sie die Liste „Leistungsstatistiken“ nach Metriksammler .

Zugehörige Konzepte

• Rotieren Sie Ereignistabellen und Bereinigung der Warnungstabelle