PagerDuty Integration in Lucidworks Fusion

Warnmeldungen in Fusion

Das Versenden von Warnmeldungen ist keine neue Funktion für Fusion. Seit Version 1.4 können Fusion-Benutzer ein integriertes Nachrichtensystem verwenden, um E-Mail- oder Slack-Benachrichtigungen zu protokollieren oder zu versenden, wenn z.B. ein bestimmter Text in einem zu indizierenden Dokumentenstrom oder bei der Verarbeitung von Abfrage-Pipelines auftritt.

Wenn Sie mit Alerts nicht vertraut sind, finden Sie hier eine Einführung in die Alert- und Messaging-Architektur von Fusion. Die Fibel enthält auch praktische Anweisungen, wie Sie Fusion so einrichten, dass es während der Ausführung von Indizierungs- und Abfrage-Pipelines E-Mail- oder Slack-Benachrichtigungen versendet.

Mit der Veröffentlichung von Fusion Version 2.1 bietet Fusion zusätzlich zu den Logging-, E-Mail- und Slack-Benachrichtigungen auch eine Methode zum Senden von PagerDuty-Benachrichtigungen.

Was ist PagerDuty?

PagerDuty ist eine Plattform für das Incident Management, die IT-Fachleuten dabei hilft, die Zeit für die Behebung von Störungen zu verkürzen, die Transparenz der gesamten Infrastruktur zu verbessern und die Betriebsleistung zu steigern. PagerDuty sammelt Signale von mehr als 150 Überwachungstools und verbindet das Problem mit dem zuständigen Bereitschaftsingenieur per Telefon, SMS, Push-Benachrichtigung und E-Mail. Zusätzlich zu den Mitgliedern des IT-Betriebsteams bietet PagerDuty auch den Support-Teams eine einheitliche Sicht auf alle Systeme, unabhängig davon, welche Tools verwendet und welche Systeme überwacht werden.

Die PagerDuty Plattform für die Verwaltung von Vorfällen umfasst Kontaktinformationen für das Hausteam, einen Alarmierungs-Workflow, automatische Eskalationen, die Planung von Bereitschaftsdiensten und Analysen der System- und Teamleistung.

Die Fusion PagerDuty Integration

Die Integration ermöglicht es einem Fusion Benutzer, PagerDuty Vorfälle zu verwalten. Für jeden Vorfall sendet PagerDuty Warnmeldungen gemäß dem oben erwähnten Warn-Workflow. Fusion verwendet die Incident API von PagerDuty, um mit den PagerDuty Servern in Echtzeit zu kommunizieren, so dass die in Fusion erstellten Alarme buchstäblich in Sekundenschnelle an die entsprechenden Parteien gesendet werden.

Beispiele für solche Ereignisse sind das Vorhandensein eines bestimmten Textes in den Indizierungsströmen, Änderungen in den Daten, die Fusion verarbeitet oder verwaltet, oder Health Check-Ereignisse im Zusammenhang mit verschiedenen Problemen (z.B. wenn die Solr-Sammlung leer ist oder die Anzahl der kürzlich indizierten Dokumente geringer ist als erwartet usw.). Ähnlich wie bei der Slack- oder E-Mail-Benachrichtigung kann Fusion während der Verarbeitung einer Indizierungs- oder Abfrage-Pipeline eine PagerDuty-Benachrichtigung auslösen, die auf bestimmten, vom Benutzer konfigurierbaren Bedingungen basiert. Da PagerDuty sehr supportorientiert ist, ist es sinnvoll, es für alle Arten von Warnmeldungen im Zusammenhang mit dem Zustand der Fusion-Dienste und Datenverarbeitungs- oder Integritätsproblemen zu verwenden, die sofortige Aufmerksamkeit erfordern.

Beachten Sie, dass die Unterstützung von Fusion für PagerDuty es Benutzern nicht erlaubt, die Eskalationsrichtlinien zu sehen oder zu konfigurieren oder den Verlauf von Alarmen einzusehen. Wir erwägen jedoch, in Zukunft einen PagerDuty-Connector zu Fusion zu erstellen (so dass z.B. der Verlauf von PagerDuty-Alarmen in Fusion indiziert und durchsucht werden kann).

Integration einrichten

PagerDuty verwendet „Dienste“ zur Integration mit Überwachungstools. Jeder „Dienst“ hat seine eigenen Alarmierungs- und Eskalationsregeln, die sogenannten „Eskalationsrichtlinien“. Diese Funktion wird verwendet, um Alarme an die Personen weiterzuleiten, die am besten in der Lage sind, sie zu bearbeiten. Um die PagerDuty-Integration zu aktivieren, müssen Sie also zunächst einen mit Fusion verbundenen Dienst in Ihrem PagerDuty-Konto einrichten. Sobald dies geschehen ist, werden alle von Fusion generierten Alarme mit diesem Dienst verknüpft und ordnungsgemäß an Mitarbeiter weitergeleitet, die auf Fusion (und Fusion-bezogene Dienste wie Solr) spezialisiert sind.

Um einen Dienst in PD zu erstellen, müssen Sie zunächst die Eskalationsrichtlinie erstellen, die mit diesem Dienst verknüpft werden soll. Gehen Sie also zu Konfiguration → Eskalationsrichtlinien in Ihrem PagerDuty-Konto und erstellen Sie eine, die mit Fusion-bezogenen Vorfällen verwendet wird. Um einen neuen Dienst zu erstellen, wählen Sie die Schaltfläche Neue Eskalationsrichtlinie in der oberen rechten Ecke.

Sobald die Eskalationsrichtlinie konfiguriert ist (sagen wir, sie heißt „Fusion Support“), gehen Sie zum Menüpunkt Konfiguration → Dienste und erstellen einen neuen Dienst, der mit Ihrer Fusion-Instanz verknüpft und integriert wird. Verwenden Sie die Schaltfläche Neuen Service hinzufügen in der oberen rechten Ecke, um einen neuen Service zu erstellen. Damit gelangen Sie zum Bildschirm zum Hinzufügen eines neuen Dienstes. Füllen Sie die Details für Ihren neu erstellten Service aus. Beachten Sie, dass Sie für das Optionsfeld Integrationstyp die Option Unsere API direkt verwenden wählen sollten. Konfigurieren Sie die Richtlinien für die Dringlichkeit von Benachrichtigungen und das Verhalten bei Vorfällen wie gewünscht und schließen Sie die Erstellung des Dienstes mit der Schaltfläche Dienst hinzufügen ab. Das war’s!

Sehen Sie sich nun den wichtigen Schlüssel an, den Sie im Abschnitt Integrationseinstellungen des neu erstellten Dienstes finden:

Dies ist der eindeutige Service-Schlüssel, den Sie in Ihrer Fusion-Benutzeroberfläche eingeben müssen, um die PD-Integration zu konfigurieren.

So geht’s:

Gehen Sie in der Fusion-Benutzeroberfläche zu Anwendungen → System und wählen Sie die Messaging Services:

Wählen Sie aus dem Kombinationsfeld Messaging Service konfigurieren den Eintrag Pager Duty Message Service. Geben Sie nun den Integrationsschlüssel für den Dienst, den Sie in PagerDuty konfiguriert haben, in das Feld Pager Duty Service Key ein. Behalten Sie für die API-URL des Pager Duty-Dienstes einfach den Standardwert bei. Speichern Sie die Änderungen.

Das war’s. Die PD-Integration ist nun in Fusion konfiguriert und es ist an der Zeit, sie zu nutzen.

PagerDuty Message Stage Konfiguration

Der PagerDuty-Integrationscode in Fusion interagiert jedes Mal mit einem PagerDuty-Dienst, wenn eine PagerDuty-Nachricht senden-Stufe als Teil einer Pipeline ausgeführt wird. Der Name ist ein wenig irreführend – es werden keine Nachrichten an PagerDuty gesendet. Die Fusion-Phase verwendet einen http-API-Aufruf. Der eigentliche PagerDuty-Alarm könnte auch keine Nachricht sein. Diese Namensgebung spiegelt das allgemeine Konzept wider, das Fusion für den Umgang mit Alarmen verwendet – sie werden über ein Nachrichtensystem gesendet. In gewisser Weise könnten Sie denken, dass Fusion eine Alarmmeldung über PagerDuty sendet – ähnlich wie beim Versand von E-Mail-Nachrichten.

In dieser Phase wird ein PagerDuty Vorfall ausgelöst, bestätigt oder gelöst – ein Ereignis, das Aufmerksamkeit erfordert, bis es gelöst ist oder abläuft. Der Vorfall wird entweder von einem Menschen gelöst (über die PagerDuty Website oder die App, sobald die Arbeit an diesem Vorfall erledigt ist) oder er läuft ab und wird automatisch gemäß den konfigurierten PD-Zeitüberschreitungsregeln gelöst. Bis der Vorfall gelöst ist, sendet die PD weiterhin Benachrichtigungen gemäß der Eskalationsrichtlinie. Der Vorfall kann bestätigt werden, um anzuzeigen, dass bereits jemand an dem Problem arbeitet, und um die Alarme für eine gewisse Zeit zu unterdrücken. Wenn der Vorfall jedoch erneut mit demselben Vorfallschlüssel ausgelöst wird, wird der bereits geschlossene Vorfall erneut geöffnet.

Die Stufenkonfiguration legt zwei Dinge fest. Das erste sind die Details des Vorfalls – welche Daten und wie sie den Personen präsentiert werden, die sich mit dem Problem befassen, sobald sie die PagerDuty-Benachrichtigung erhalten. Die zweite ist die Bedingung, die erfüllt sein muss, damit die Stufe ausgeführt wird. Sie wird im Bedingungsskript der Stufe festgelegt. In der Regel handelt es sich dabei um die Auswertung von Fusion-Objekten, die zum Zeitpunkt der Verarbeitung im Stufenkontext verfügbar sind (für die Abfrage-Pipeline-Stufe – die Fusion/Solr-Abfrage Request und Response, und für die Index-Pipeline-Stufe – das Fusion-Pipeline-Dokument). Beispiele wären die Auswertung, ob die Abfrageantwort 0 Dokumente enthält oder ob das Pipeline-Dokument bestimmte Daten in einem Feld enthält (siehe unten).

Lassen Sie uns zuerst über die Details des Ereignisses sprechen und dann darüber, wie Sie die Ausführung der Phase abhängig vom Ergebnis des bedingten Skripts auslösen.

Einstellung der Vorfalldetails

Für diese Phase müssen 3 Felder konfiguriert werden – der Ereignistyp, die Beschreibung und der Vorfallsschlüssel. Der Ereignistyp ist einer von Auslösen, Bestätigen oder Auflösen. Damit wird festgelegt, ob die Nachricht den PagerDuty-Vorfall auslöst, bestätigt oder auflöst. Die Beschreibung selbst ist eine kurze Beschreibung des Ereignisses. Dieses Feld (oder eine gekürzte Version, da PD maximal 1024 Zeichen zulässt) wird bei der Erstellung von Telefonanrufen, SMS-Nachrichten und Alarm-E-Mails verwendet. Es wird auch in der Tabelle der Vorfälle in der PagerDuty-Benutzeroberfläche angezeigt. Und das Feld Incident Key identifiziert den Incident, auf den dieses Trigger-Ereignis angewendet werden soll. Wenn es keinen offenen (d.h. ungelösten) Vorfall mit diesem Schlüssel gibt, wird ein neuer erstellt. Wenn es bereits einen offenen Vorfall mit einem passenden Schlüssel gibt, wird dieses Ereignis an das Protokoll dieses Vorfalls angehängt. Mit dem Vorfallschlüssel können Sie also alle Vorfälle, die mit demselben Ereignis in Zusammenhang stehen, entdoppeln oder gruppieren.

Neben diesen 3 Feldern sind die übrigen Felder, die den Incident-Kontext definieren, optional

Das Feld Client ist ein optionales Feld, das den Namen des Überwachungsclients angibt, der dieses Ereignis auslöst, z.B. nur Fusion. Und das Feld Client-URL steht für die Callback-URL, die aufgerufen werden soll, um weitere Details über das Ereignis auf einer anderen Seite (als PagerDuty) zu sehen. Diese URL kann zum Beispiel eine Seite der Fusion-Benutzeroberfläche oder eine Seite Ihrer Suchanwendung öffnen, um das ursprüngliche Problem zu lösen.

Die Etappe kann auch eine Liste von Vorfalldetails enthalten, eine Liste von Name-Wert-Paaren beliebiger Daten. Sie ist Teil der Vorfallbeschreibung auf der PD-Site und wird in das Vorfallprotokoll aufgenommen. Dasselbe gilt für Incident Context Links und Incident Context Details: diese Listen enthalten beliebige Daten, die für die Bearbeiter des Vorfalls hilfreich sein können. Der Kontextlink ist ein Paar aus einer beliebigen URL (die in der PagerDuty-Benutzeroberfläche anklickbar ist) und dem Text, der die URL beschreibt. Context Image ist ein Satz von Feldern, die ein beliebiges anklickbares Bild definieren (die Bild-SRC-URL sollte ein sicheres Protokoll haben, d.h. mit https:// beginnen), das Teil des Vorfallkontextes ist, der für jemanden, der den Vorfall untersucht, sichtbar ist.

Alle Wertfelder für diese Listeneinträge können parametrisiert werden, d.h. die Werte für sie können durch String-Vorlagen dargestellt werden (siehe www.stringtemplate.org) und die tatsächlichen Werte werden von Fusion aus Objekten injiziert, die der Stufe im Moment der Ausführung zur Verfügung stehen. Zum Beispiel kann der Vorlagenausdruck <doc.id> im Feld Incident Detail value verwendet werden; der tatsächliche Wert ist die ID des Fusion-Pipeline-Dokuments, das die Stufe verarbeitet hat:

Wird auf der PagerDuty-Website als Teil des Vorfallkontexts angezeigt, genau wie hier:

Fusion Document Id: 345

Bedingungen für die Ausführung der Bühne festlegen

Lassen Sie uns nun darüber sprechen, wie wir die Stufe so konfigurieren, dass sie nur dann ausgelöst wird, wenn wir die PagerDuty-Stufe ausführen (und damit einen Vorfall auslösen oder lösen) wollen. Wir möchten auf keinen Fall für jedes von der Index-Pipeline verarbeitete Fusion-Pipeline-Dokument oder für jede von der Query-Pipeline ausgeführte Abfrage einen PagerDuty-Vorfall auslösen. Der Teil der Stufenkonfiguration – ein Feld für ein bedingtes Skript – definiert, wann die Stufe ausgeführt werden soll. Um den Schritt auszuführen, muss die Auswertung des JavaScript-Ausdrucks im Feld Conditional Script den Wert true (1) ergeben. Wird der Ausdruck als falsch (0) ausgewertet, wird der Schritt nicht ausgeführt.

Wir können diesen Schritt zum Beispiel nur ausführen, wenn wir ein Pipeline-Dokument mit dem Feld first_name mit dem Wert John sehen:

Der Ausdruck im Feld Bedingtes Skript prüft die Daten im Feld vorname :

Ähnlich verhält es sich mit der Stufe der Abfrage-Pipeline, wenn wir den PagerDuty-Alarm auslösen möchten, falls eine wichtige Abfrage keine Ergebnisse liefert (was normalerweise nicht passieren sollte). Das bedingte Skript für die Stufe PagerDuty-Nachricht senden der Query Pipeline sollte wie folgt aussehen:

Wenn die Beschreibung des Vorfalls und/oder der Schlüssel des Vorfalls so parametrisiert sind, dass <request.q> verwendet wird, wird der Vorfall in der Liste der PD UI-Vorfälle beschrieben (vorausgesetzt, der Abfrage-String ist nicht zu lang):

Beachten Sie, dass zur erfolgreichen Verarbeitung der response.initialEntity.query() im Feld Conditional Script der wt-Parameter für die Solr-Abfrage auf json gesetzt werden muss. Dies geschieht am besten in der Phase Set Query Params. Und natürlich sollte die Stufe Query Solr vor der Stufe Send Pager Duty Message in Ihrer Abfrage-Pipeline stehen.

Eine Solr-Abfrage wie fetchedDate_dt:[NOW-1HOUR TO NOW] in Kombination mit einem Conditional Script, das auf Null-Treffer prüft, wäre eine gute Prüfung für den konstanten Fluss der von Ihrer Fusion-Anwendung indizierten Dokumente, vorausgesetzt, die Abfrage-Pipeline wird regelmäßig ausgeführt (d.h. mit Fusion Scheduler registriert).

Mehrere Stadien in Pipelines

Die Stufe Send PagerDuty Message ändert die an die Stufe übergebenen Fusion-Objekte (d.h. Fusion-Pipeline-Dokumente oder Request-and-Response) nicht, sondern wertet sie nur aus und sendet die Nachricht an PagerDuty, wenn das bedingte Skript zu „true“ aufgelöst wird. Es ist also möglich, mehrere Send PagerDuty Message Phasen in derselben Fusion Pipeline zu haben. Sie können die Pipeline z.B. so konfigurieren, dass sie 2 PD-Stufen hat – eine löst den PD-Vorfall aus und die andere löst ihn auf der Grundlage bestimmter Pipeline-Dokumentdaten auf. Achten Sie darauf, denselben Incident Key zu verwenden und nicht mehrere doppelte Resolve PD-Nachrichten zu senden.

Für die Index-Pipeline können Sie auch die Stufe Eigenschaft setzen vor der Stufe PagerDuty Nachricht senden verwenden, um eine Eigenschaft des Pipeline-Kontextes oder des Pipeline-Dokuments zu setzen, damit das bedingte Skript von PagerDuty einfacher aussieht.

Fazit

Die Integration von PagerDuty ermöglicht es Fusion-Benutzern, die an der Überwachung von verwalteten Daten interessiert sind, ihren Suchanwendungen Benachrichtigungen und Alarmfunktionen hinzuzufügen. In der Regel werden PagerDuty-Ereignisse ausgelöst, wenn bei der Ausführung von Fusion-Indizierungs- oder Abfrage-Pipelines etwas Wichtiges entdeckt wird. Die Stufe PagerDuty Nachricht senden wird verwendet, um PagerDuty Dienste zu benachrichtigen. Für die Integration ist nur eine minimale Konfiguration auf Seiten von PagerDuty und Fusion erforderlich.