{"id":10875,"date":"2021-04-09T16:32:04","date_gmt":"2021-04-09T14:32:04","guid":{"rendered":"https:\/\/www.derdack.com\/de\/?p=10875"},"modified":"2021-04-09T16:39:59","modified_gmt":"2021-04-09T14:39:59","slug":"alarmierungsrichlinien-optimieren-dynamische-parameter","status":"publish","type":"post","link":"https:\/\/www.derdack.com\/de\/alarmierungsrichlinien-optimieren-dynamische-parameter\/","title":{"rendered":"Alarmrichtlinien mit dynamischen Parametern optimieren"},"content":{"rendered":"

Zielgenaue und zuverl\u00e4ssige Benachrichtigungen sind das Herzst\u00fcck jeder Alarmierungsl\u00f6sung.\u00a0 Das Versenden von E-Mails an Gruppen von Mitarbeitern mag gut f\u00fcr die Quantit\u00e4t sein, f\u00fchrt aber zu enormen Problemen, insbesondere in Hinblick auf eine rechtzeitige Reaktion auf kritische St\u00f6rungen („Broadcast Dilemma“). Enterprise Alert konzentriert sich auf die Qualit\u00e4t, d. h. die Benachrichtigung der richtigen Personen zur richtigen Zeit.\u00a0 Wir sehen oft, dass Monitoring- und Ticketing-L\u00f6sungen einen Vorfall erstellen und sich dann darauf verlassen, dass der Empf\u00e4nger der E-Mail nicht nur den Vorfall identifiziert und bearbeitet, sondern auch das Ticket abschlie\u00dft, das erstellt wurde.\u00a0 Diese Methode ist mit viel Aufwand verbunden, geht oft \u00fcber mehrere Systeme hinweg, und wir h\u00f6ren immer wieder, dass Tickets nicht ordnungsgem\u00e4\u00df geschlossen werden, nachdem ein Vorfall behoben wurde.<\/p>\n

Warum ist die Nutzung dynamischer Ereignisparameter sinnvoll?<\/strong><\/h3>\n

In Enterprise Alert kann es u.U. mehrere Workflows, also Alarmierungsrichtlinien, erfordern, um die Benachrichtigung an zust\u00e4ndigen Experten zu leiten, teilweise ist es auch n\u00f6tig mehrere Workflows f\u00fcr ein eingehendes Ereignis zu definieren.<\/p>\n

Was w\u00e4re, wenn es eine einfachere M\u00f6glichkeit g\u00e4be, nicht nur die Anzahl der zu pflegenden Alarmierungsrichtlinien in Enterprise Alert zu reduzieren, sondern auch das Ziel dynamisch zu definieren?<\/p>\n

Das Erstellen von Alarmierungsrichtlinien aus eingehenden Ereignissen ist etwas, mit dem die meisten EA-Administratoren vertraut sind.\u00a0 Wir erhalten Ereignisse von beliebigen Drittsystemen auf vielf\u00e4ltige Weise.\u00a0 In unseren Kundengespr\u00e4chen h\u00f6ren wir oft, dass mehrere Richtlinien erstellt werden, wobei nur eine Bedingung ge\u00e4ndert wird, n\u00e4mlich das Zielteam, das der Alarmbedingung entspricht.\u00a0 Um die Anzahl der Richtlinien, die Administratoren erstellen m\u00fcssen, zu reduzieren, k\u00f6nnen wir die dynamischen Parameter des eingehenden Ereignisses verwenden, um festzulegen, an wen die Meldung gesendet werden soll.<\/p>\n

Wie geht das?<\/strong><\/h3>\n

Unser Beispiel basiert auf der Integration in ServiceNow. Hier sehen wir ein in ServiceNow erstelltes Ticket. Der Benachrichtigungstext f\u00fcr die Alarmrichtlinie wird in der Regel dynamisch importiert, um das Problem wiederzugeben, ohne dass der EA-Administrator eine spezifische Nachricht eingeben muss.
\n\"\"<\/a><\/p>\n

Aber warum dort aufh\u00f6ren?\u00a0 Lassen Sie uns die empfangenen Ereignisparameter aus ServiceNow verwenden, um die Benachrichtigung f\u00fcr diese Richtlinie automatisch weiterzuleiten.\u00a0 Um das zu tun gehen wir in den „Alerting“ Tab. Oft sehen wir hier, dass hier bestimmte Teams angesprochen werden.\u00a0 Das bedeutet, dass die Benachrichtigung an mehrere Richtlinien weitergeleitet wird.\u00a0 Zum Beispiel eine Richtlinie, die auf das Sicherheitsteam abzielt, und dann eine weitere Richtlinie mit denselben Bedingungen, die auf das Anwendungsteam abzielt. Um dies zu vereinfachen, verwenden wir hier die Option „Ereignisparameter“ und setzen sie auf ein Feld, das das Zielteam enth\u00e4lt, das in Enterprise Alert existiert.<\/p>\n

\"\"<\/a><\/p>\n

Wenn nun ein neues Event eintrifft, wird die in ServiceNow eingestellte „assignment group“ automatisch auf das entsprechende Team in Enterprise Alert gemappt. Das ist der entscheidende Punkt! Und so wird aus X Alarmierungsrichtlinien in Enterprise Alert nur eine einzige.
\n\"\"<\/a>
\n\"\"<\/a><\/p>\n

Dieses Beispiel zeigt Incidents, die in ServiceNow ausgel\u00f6st wurden, das gleiche Prinzip gilt aber f\u00fcr jedes 3rd-Party-System.\u00a0 Die einzige Voraussetzung hier ist, dass der Name des Ereignisparameters mit einem entsprechenden Teamnamen in Enterprise Alert \u00fcbereinstimmen muss. Die Optimierung des Alert-Ziels auf diese Weise kann die Anzahl der zu pflegenden Richtlinien reduzieren und bietet dynamische Routing-Funktionen aus einem einzigen Ereignis.<\/p>\n

Hier ist das Ganze in einem Video gezeigt (englisch):<\/p>\n

<\/div><\/div>
<\/div>
<\/div>
<\/div><\/div><\/div>