Alarm! Alarm! Alarm! (Implementierung von Warnmeldungen in Lucidworks Fusion)

Wir leben in einer Welt des Streaming. Tweets, Updates, Dokumente, Protokolle usw. strömen ständig auf uns ein und fordern uns…

Wir leben in einer Welt des Streaming. Tweets, Updates, Dokumente, Protokolle usw. strömen ständig auf uns ein und fordern uns auf, auf alles zu reagieren, was an uns vorbeizieht. Gleichzeitig ist unsere Aufmerksamkeitsspanne begrenzt, so dass wir einen Weg brauchen, um die sprichwörtliche Spreu vom Weizen zu trennen, das Rauschen vom Signal, den Müll vom Gold.

Wir wissen seit langem, dass die Suche hervorragend dazu geeignet ist, wichtige Inhalte zu finden. Historiker, die sich mit der Informationsbeschaffung befassen, werden feststellen, dass bereits in den Anfängen der Suche ein Interesse an der Weiterleitung oder Filterung von Dokumenten bestand, um die eintreffenden Dokumente mit den bestehenden Suchanfragen abzugleichen. Bis vor kurzem jedoch, mit dem massiven Anstieg der von Suchmaschinen aufgenommenen Inhalte, wurde diesem Problem außerhalb einiger Nischenbereiche nicht viel Aufmerksamkeit geschenkt.

Um den Anforderungen von Streaming-Daten und Alerting gerecht zu werden, enthält unsere neueste Version von Lucidworks Fusion jetzt einen vollständig integrierten Messaging-Service sowie Pipeline-Stufen für die schnelle und einfache Einrichtung von Alerts sowohl zur Indexzeit als auch zur Suchzeit. Während Systeme wie Percolator (für Elasticsearch) und Luwak (für Solr) Techniken zur Verwaltung und Ausführung stehender (Alerting-)Abfragen verwenden (indem sie diese als Dokumente speichern), ermöglicht es unser Ansatz, nicht nur eingehende Datenströme mit stehenden Abfragen abzugleichen, sondern auch reguläre Ausdrücke, Datenbankabfragen und andere Kriterien einzubeziehen, um zu entscheiden, ob etwas Alert-würdig ist oder nicht. Da unser Warnmechanismus vollständig in unsere Pipeline-Architektur integriert ist, kann jede vorgelagerte Stufe beeinflussen, wie eine Warnmeldung gesendet wird. Derzeit wird Fusion mit Unterstützung für den Versand von E-Mails und Slack-Nachrichten ausgeliefert, aber die Unterstützung für andere Integrationen wird bald folgen.

Schauen wir uns die Funktionalität anhand einer Video-Demo genauer an und zeigen Ihnen dann, wie dies in Fusion funktioniert. Für diese Demo gehe ich davon aus, dass Sie Fusion heruntergeladen, entpackt und sich in der Verwaltungskonsole angemeldet haben.

Nachdem wir die Demo nun hinter uns gebracht haben, wollen wir uns ansehen, wie das System funktioniert.

Bauklötze

Fusion besteht aus einer Reihe von Diensten, die zusammenarbeiten, um Suche, Empfehlungen, Speicherung in großem Maßstab, Benachrichtigung und andere wichtige Dienste für anspruchsvolle Suchanwendungen zu ermöglichen. Diese Dienste werden in fast allen Fällen genauso eingesetzt wie Solr (weitere Einzelheiten finden Sie im Architekturdiagramm unten). Um die Alarmierung zu ermöglichen, haben wir einen neuen Dienst für die Übermittlung von Nachrichten, den Messaging Service, über einen oder mehrere Dienstanbieter sowie mehrere neue Pipeline-Stufen hinzugefügt, um die Alarmierung sowohl bei der Indizierung als auch bei der Abfrage zu ermöglichen.

Messaging-Dienst

Der Messaging Service bietet Implementierungen zum Senden von Nachrichten bestimmter Typen (z.B. Slack, E-Mail) an einen oder mehrere Empfänger. Er ermöglicht auch die Planung des Versands von Nachrichten durch die Integration mit dem integrierten Scheduler von Fusion. Darüber hinaus kann er sogar alle Nachrichten in Solr speichern, so dass sie später durchsucht werden können. Weitere Informationen zu diesen und anderen Konfigurationsoptionen finden Sie im Anhang zur Konfiguration des Nachrichtendienstes.

Der Messaging Service unterstützt derzeit drei Dienste: E-Mail, Protokollierung und Slack. Um den neuen Messaging Service zu nutzen, muss der Service zunächst eingerichtet werden. Dies kann über die Benutzeroberfläche von Fusion Admin (System->Messaging Services) erfolgen, wie in der folgenden Abbildung zu sehen ist, oder über die API. Mit einer konfigurierten Dienstinstanz (Hinweis: Der Protokollierungsdienst ist standardmäßig eingerichtet) können wir dann Nachrichten entweder über eine Pipeline-Stufe oder über die APIs versenden. Wir werden den API-Ansatz im nächsten Unterabschnitt und den Pipeline-Ansatz im folgenden Abschnitt über Pipeline-Stufen behandeln.

Senden einer Nachricht über die Messaging API

Die Messaging-API unterstützt das allgemeine Konzept einer Nachricht, die aus Attributen wie An, Von, Betreff, Textkörper und anderen Feldern besteht. Eine vollständige Auflistung der Attribute finden Sie im Abschnitt Nachrichtenattribute im Anhang unten. Jede Implementierung des Nachrichtendienstes ist dafür verantwortlich, die Bedeutung der Attribute im Kontext des eigenen Systems zu interpretieren. Zum Beispiel bedeutet „to“ im Kontext von Slack den Kanal, in dem die Nachricht gepostet wird, während to im Kontext von E-Mail (SMTP) eine E-Mail-Adresse bedeutet. Eine Slack-Nachricht könnte beispielsweise so aussehen:

[
  {
    "id": "this-is-my-id",
    "type": "slack",
    "subject": "Slackity Slack",
    "body": "This is a slack message that I am sending to the #bottestchannel",
    "to": ["bottestchannel"],
    "from": "bob"
  }
]

Eine SMTP-Nachricht könnte beispielsweise so aussehen:

[
  {
    "id": "foo",
    "type": "smtp",
    "subject": "Fusion Developer Position",
    "body": "Hi, I’m interested in the engineering posting listed at https://lucidworks.com/company/careers/",
    "to": ["careers@lucidworks.com"],
    "from": "bob@bob.com",
    "messageServiceParams":{
        "smtp.username": "robert.robertson@bob.com",
        "smtp.password": "XXXXXXXX"
    }
  }
]

Je nachdem, wie die Vorlage des Nachrichtendienstes eingerichtet ist, wird bestimmt, welche Aspekte der Nachricht gesendet werden. In der obigen Abbildung ist der Slack-Nachrichtendienst beispielsweise so eingerichtet, dass er den Betreff und den Text als : an Slack sendet, wie im Attribut Nachrichtenvorlage des Dienstes festgelegt.

Um dies alles zusammenzufassen, können wir die eigentliche Nachricht senden, indem wir das obige JSON an den Sende-Endpunkt POSTen, wie im Screenshot des Postman REST-Client-Plugins für Chrome gezeigt:

Das war’s! Sie verfügen nun über einen vollständigen Messaging-Dienst, den Sie nach Belieben nutzen können. Genau wie der Rest von Fusion können Sie den Zugriff auf den Nachrichtendienst sichern, so dass nur geeignete Anwendungen und Benutzer tatsächlich Nachrichten versenden können. Die Möglichkeit, beliebige Nachrichten zu versenden, ist zwar eine nette Sache, aber die Hauptanwendung des Nachrichtendienstes ist die Verwendung als Teil von Pipelines, also sehen wir uns an, wie er funktioniert.

Pipeline-Stufen

Lucidworks Fusion wird mit Pipelines für die Index- und Abfragezeit ausgeliefert, die eine einfache Verwaltung der dynamischen Verarbeitung von Dokumenten und Abfragen ermöglichen. Jede Pipeline besteht aus einer oder mehreren Stufen, und eine Anwendung kann mehrere Pipelines für verschiedene Szenarien einrichten, z.B. zum Testen verschiedener Dokumentenszenarien, A/B-Tests und mehr.

Im Zusammenhang mit der Alarmierung enthält Fusion 1.4 mehrere neue Pipeline-Stufen:

1. SMTP, Slack und Logging Messaging Phasen für die Zustellung von Nachrichten
2. Eine neue, leichtgewichtige, bedingte Indexstufe (genannt Set Property), die das Setzen von Eigenschaften ohne Javascript ermöglicht.

Wie Sie im Video gesehen haben, ermöglicht die Kombination dieser Phasen das Senden von Warnmeldungen, wenn bestimmte Bedingungen in der Anwendung erfüllt sind. Um komplexere Warnsysteme zu erstellen, müssen Sie wissen, welche Werte in der Pipeline verfügbar sind. Dies hängt davon ab, ob es sich um eine Abfrage-Pipeline oder eine Index-Pipeline handelt, die beide unten beschrieben werden.

Index-Pipeline-Datenstrukturen

Die Index-Pipeline verfügt über zwei wichtige Datenstrukturen: 1) das Pipeline-Dokument und 2) der Pipeline-Kontext. Ersteres ist, wie der Name schon sagt, das eigentliche Dokument, das von der Anwendung oder dem Konnektor übermittelt wurde, während letzteres ein anforderungsspezifisches Schlüssel/Wert-Paar ist, das Informationen enthält, die von vorgelagerten Stufen in das Dokument eingegeben wurden. Kontextelemente werden dem Dokument nicht automatisch hinzugefügt und werden bei der Indizierung nicht an Solr gesendet. Der Kontext ist die wichtigste Methode, um Flags und andere Werte für nachgelagerte Stufen verfügbar zu machen. Der beste Weg, um zu sehen, was sich im Dokument oder im Pipeline-Kontext befindet, ist die Verwendung der Logging Stage oder der UI-Index-Pipeline-Vorschau-Seite.

Datenstrukturen der Abfrage-Pipeline

Der Hauptunterschied zwischen der Index-Pipeline und der Query-Pipeline besteht darin, dass das Dokument durch den Zugriff auf die Anfrage, die Antwort und alle übergebenen Header ersetzt wird. Wie bei der Indizierung ist der Pipeline-Kontext verfügbar und hat die gleiche Semantik wie die Indizierungszeit, wenn auch mit anderen Daten darin. Um zu verstehen, was für Datenstrukturen zur Verfügung stehen, lesen Sie bitte die Abschnitte über Query Request Objects und Query Response Objects in der Dokumentation.

Nächste Schritte

Wenn Sie es bis hierher geschafft haben, haben Sie bereits eine Reihe neuer Funktionen in Aktion gesehen:

1. Eine kurze Demo zur Einrichtung eines Benachrichtigungssystems in Fusion
2. Versenden beliebiger Nachrichten über den Nachrichtendienst von Fusion
3. Einige Details darüber, wie all diese Dinge aufgebaut sind und wo Sie weitere Informationen finden können

Wir sind begeistert von dem, was 1.4 für die Benachrichtigung bietet, aber wir haben noch viel mehr vor. Zum Beispiel arbeiten wir derzeit an APIs für die Alarmierung auf höherer Ebene für diejenigen, die die Feinheiten der Pipeline-Phasen nicht kennen möchten, sowie an weiteren Integrationen von Nachrichtendiensten. Es ist noch etwas zu früh, um Letzteres anzukündigen, aber wir können schon einen Hinweis geben: Es geht um die Integration mehrerer weit verbreiteter Messaging-Systeme, die die Arten von Nachrichten, die Sie versenden können, drastisch erhöhen und diesen Nachrichten Workflow-Optionen hinzufügen werden. Außerdem werden wir in naher Zukunft ein SDK für den Messaging Service für diejenigen veröffentlichen, die ihre eigenen Messaging-Systeme in Fusion integrieren möchten. Wie immer, wenn es etwas gibt, das Sie gerne in Fusion sehen würden, können Sie uns gerne kontaktieren. Ansonsten wünschen wir Ihnen viel Spaß beim Alerting!

Anhang

Nachrichten-Attribute

Attribut Nachricht	Beschreibung
id	Eine anwendungsspezifische ID zur Nachverfolgung der Nachricht. Muss eindeutig sein. Wenn Sie nicht sicher sind, was Sie verwenden sollen, erzeugen Sie eine UUID.
Typ	Die Art der zu sendenden Nachricht. Ab 1.4 kann das sein: slack, smtp oder log. Senden Sie einen GET an http://HOST:PORT/api/apollo/messaging/, um eine Liste der unterstützten Typen zu erhalten.
zu	Ein oder mehrere Ziele für die Nachricht, als Liste.
von	Von wem/was die Nachricht stammt.
Thema	Der Betreff der Nachricht.
Körper	Der Hauptteil der Nachricht.
Zeitplan	Wenn die Nachricht zu einem späteren Zeitpunkt oder in regelmäßigen Abständen gesendet werden soll, geben Sie das Zeitplanobjekt an. Weitere Informationen finden Sie in der Scheduler-Dokumentation.
messageServiceParams	Übergeben Sie eine Map mit allen für den Nachrichtendienst spezifischen Parametern. Für den SMTP-Nachrichtendienst muss die Anwendung zum Beispiel den SMTP-Benutzer und das Kennwort übergeben.

Konfiguration des Nachrichtendienstes

Der Nachrichtendienst als System unterstützt zwei Attribute, die über die Konfigurations-API konfiguriert werden können. Die Attribute sind:

1. rateLimit – Die Zeit in Millisekunden, die zwischen dem Senden von Nachrichten pro Anfrage gewartet wird. Bitte beachten Sie, dass dies die Drosselung zwischen verschiedenen Anfragen nicht synchronisiert.
2. storeAllMessages – Boolesches Flag, das angibt, ob wir alle vom System gesendeten Nachrichten speichern/indizieren sollen. Standardmäßig werden nur geplante Nachrichten gespeichert, da diese zu einem späteren Zeitpunkt vom Planer abgerufen werden müssen. Die Speicherung aller Nachrichten kann für die Überprüfung des Systems nützlich sein, hat aber Auswirkungen auf den Speicherbedarf des Systems.

Ein Wort zu String-Vorlagen

Ein großer Teil des Systems ist mit der ausgezeichneten String Template Bibliothek von Terence Parr verwoben, die wir an mehreren Stellen verwenden, um die Leerstellen einer Vorlage mit tatsächlichen Werten aus dem Arbeitssystem zu füllen, wie z.B. dem Namen des Dokuments oder der Abfrage. Sie können dies bei der Einrichtung des Nachrichtendienstsystems in Aktion sehen, wo wir die Nachrichtenvorlage <subject>: <body> eingestellt haben, aber sie ist auch an vielen anderen Stellen verfügbar. Achten Sie einfach auf die Erwähnung von „Stringvorlagen“ und wissen Sie, dass Sie diese nach Belieben verwenden können.