Eine Plattform für Alarmierung, Rufbereitschaften und Status­seiten.

In diesem Blogbeitrag erklären wir, wie die Statusseiten in ilert funktionieren, auf welche Herausforderungen wir bei der Entwicklung dieses Features gestoßen sind und mit welchen Ansätzen wir die Probleme angegangen sind.

Rückblick: Deshalb haben wir Statusseiten eingeführt

ilert ist seit langem eine zuverlässige Plattform für kritische Benachrichtigungs-, Alarmierungs- und Eskalationsprozesse. Anfang 2021 erkannten wir die Notwendigkeit, den Umfang unseres Angebots zu erweitern, um die Bedürfnisse unserer Kunden besser erfüllen zu können. Dies führte zu einer wesentlichen Verfeinerung unseres Ansatzes: die Trennung von Benachrichtigungen in Alarmierungen und Störungen.

‍

Alarmierungen sind kritische Meldungen, die sich in erster Linie an Entwicklungs- und Support-Teams richten. Sie beziehen sich auf Probleme wie Serveranomalien, die sich direkt oder indirekt auf die Gesamtleistung der Kundensysteme auswirken können. Auf der anderen Seite bezeichnen Störungen schwerwiegende Probleme, die sich auf die Systeme des Kunden auswirken und oft so eskalieren, dass die Endnutzer betroffen sind. In diesem Artikel beschreiben wir im Detail, wie wir zu dieser Entscheidung gekommen sind.

‍

Durch die Kategorisierung von Problemen als Alarmierung oder Störung waren wir in der Lage, unsere Reaktionsstrategien effizient zu gestalten. Darüber hinaus führte diese Unterscheidung logischerweise zur Einführung von Statusseiten als neues zentrales Kommunikationsinstrument bei Incidents, um Transparenz und die Weitergabe aktueller Informationen an alle beteiligten Stakeholder zu gewährleisten.

‍

Mitte 2021 begannen wir mit der Planung unserer zukünftigen Statusseiten. Die Leitprinzipien für die Entwicklung dieser Statusseiten waren zweierlei: einwandfreie technische Ausführung und nahtlose native Integration mit unserer bestehenden Plattform. Der letzte Punkt war dabei die größte Herausforderung. Damals (und auch heute noch) gab es in der Branche keine Erfahrung mit der Kombination einer Incident-Management-Plattform und Statusseiten als nativ integrierte Lösung. Wenn man sich die bekanntesten Lösungen auf dem Markt anschaut, wie zum Beispiel Atlassian Status Pages und OpsGenie, dann sind das jeweils separate Produkte. Unser Ziel war es, zwei Lösungen so zu kombinieren, als ob sie eine einzige wären. Und natürlich wollten wir die Statusseiten zu einer transparenten, leicht verständlichen Funktion machen, die die Benutzerfreundlichkeit unserer Plattform sowohl für unsere direkten Nutzer als auch für Drittanbieter verbessert.

Entwicklung

Unser Bestreben war es, eine superschnelle Performance sowohl für unsere Seiten als auch für unsere APIs zu gewährleisten. Ursprünglich dachten wir an CDN-basierte Statusseiten, um den Rendering-Prozess zu optimieren. Im Laufe der Entwicklung sahen wir uns jedoch mit verschiedenen Herausforderungen konfrontiert, darunter die dynamische Generierung von Zertifikaten für benutzerdefinierte Domains, die schnelle Aktualisierung von Statusseiten, die gegenseitige Authentifizierung für private Seiten und die dynamische Anpassung von Inhalten auf der Grundlage von Benutzereingaben, um nur einige zu nennen.

‍

Diese Herausforderungen veranlassten uns, einen Server-Side-Rendering (SSR)-Ansatz mit einer mehrschichtigen Caching-Strategie zu verfolgen. Wir prüften verschiedene Standardlösungen, fanden sie aber für unsere Bedürfnisse ungeeignet. Also entwickelten wir eine auf unsere Anforderungen zugeschnittene SSR-Lösung, die uns die ultimative Kontrolle von der ersten Benutzeranforderung bis zur endgültigen Pixelauslieferung ermöglicht. Das Ergebnis ist eine ideale Performance sowohl auf dem Desktop als auch auf mobilen Geräten.

‍

Eine der größten Schwierigkeiten war die Aufbereitung der Daten vor dem Rendering der Seite. Wir mussten die für die Microservices der Statusseite benötigten Daten vollständig von den zugrunde liegenden Daten trennen, zum Beispiel von den Daten, die der Nutzer in der Verwaltungsoberfläche ändert.

‍

Um dies zu erreichen, wird ein spezieller Microservice eingesetzt, der die Aufgabe hat, alle mit der Statusseite verbundenen Änderungen zu überwachen, einschließlich den Aktualisierungen von Properties, Incidents, Wartungsfenstern und Diensten. Dieser Microservice erhält die erforderlichen Daten über Events aus der ilert-Plattform. Anschließend werden diese Daten in ein sogenanntes „Invalidierungsevent“ umgewandelt und an eine spezielle Messaging-Queue für die Bearbeitung von Aktualisierungen der Statusseite weitergeleitet.

‍

Ein weiterer Microservice, der für die Verarbeitung dieser Aktualisierungen zuständig ist, nimmt die Nachrichten aus der Warteschlange entgegen. Er übernimmt die Speicherung der Daten in einer Long Term-Datenbank und aktualisiert den Cache-Speicher entsprechend. Der verarbeitende Microservice arbeitet kontinuierlich und zieht neue Invalidierungsevents aus der Event-Queue, sobald sie eintreffen, um sicherzustellen, dass die Informationen aktuell und korrekt bleiben. Dank dieser Struktur von Invalidierungsevents kann unser System schnell und mit minimaler Latenz aktuelle Statusseiten-Informationen darstellen und anzeigen.

‍

Dieser Ansatz ermöglicht auch die physische Trennung der logischen Komponenten der Plattform auf der Datenspeicherebene, sodass die Statusseiten-Microservices ohne Verzögerung oder Unterbrechung arbeiten können, selbst wenn die Hauptdatenbank aus irgendeinem Grund Performance-Probleme hat.

‍

Mobile Leistung

Desktop-Leistung

Microservices von Statusseiten

Um die Komplexität der Funktion zu strukturieren, haben wir die Statusseiten in Microservices unterteilt: Gateway, Content Renderer, Content Updater, Certificate Updater und Background Cache Runner.

‍

Gateway: Dieser Microservice initiiert den Prozess bei jeder Anfrage, indem er die Statusseite über die im Browser des Nutzers eingegebene Domain ausfindig macht. Er bewertet den Seitentyp und die Rechte des Nutzers auf der Grundlage der vorkonfigurierten Einstellungen in der ilert-Oberfläche.

‍

Content Renderer: Er wird aktiv, sobald das Gateway den Zugriff autorisiert. Er prüft zunächst, ob eine vorgerenderte Seite im Cache verfügbar ist. Öffentliche Seiten oder private Seiten ohne spezifische Konfigurationen werden unter ihrer Domain gecached. Zielgruppenspezifische Seiten hingegen werden individuell zwischengespeichert, um den Zugriffsbeschränkungen einzelner Nutzer gerecht zu werden. Wenn eine Seite im Cache verfügbar ist, wird sie sofort ausgeliefert. Ist dies nicht der Fall, versucht der Renderer, die Seite schnell zu generieren und im Cache zu speichern. Sollte dieser Prozess die Zeitgrenzen überschreiten, wird ein grundlegendes, vorgerendertes Seitenlayout an den Browser des Benutzers gesendet, der das Rendering lokal abschließt und kurz einen Skeleton Loader anzeigt, während sich die Seite aufbaut; dies ist besonders hilfreich für unsere größeren Unternehmenskunden, die manchmal Unterstützung bei der Erstellung großer Mengen von Beziehungen in ihren Ressourcen benötigen.

‍

Content Updater: Der Microservice verarbeitet Content Updates, indem er zunächst Anfragen vom Gateway erhält. Anschließend arbeitet er mit dem Content Renderer zusammen, um Daten in eine HTML-Seite umzuwandeln, die er zur Anzeige durch den Nutzer an das Gateway zurücksendet. Außerdem wird die HTML-Seite im Cache gespeichert, um künftige Anfragen zu beschleunigen und den Nutzern einen schnellen und responsive Zugriff auf aktualisierte Inhalte zu ermöglichen.

‍

Background Cache-Runner: Er signalisiert fehlende Caches, um die Seite im Hintergrund zu generieren, unabhängig von der Generierungszeit, und stellt so sicher, dass sie innerhalb von Millisekunden für zukünftige Anfragen bereit ist. Außerdem werden die Seiten als Reaktion auf Änderungen in der Verwaltungsoberfläche oder in verwandten Komponenten wie Diensten, Störungen oder Wartungsfenstern aktualisiert, sodass die Statusseiten immer auf dem neuesten Stand sind.

‍

Certificate Updater: Dieser Microservice verwaltet dynamisch die Sicherheit der benutzerdefinierten Domain-Statusseiten, indem er Events vom Certificate Manager abruft. Beim Empfang dieser Events werden die Informationen zu SSL-Zertifikaten automatisch aktualisiert, um sicherzustellen, dass die Statusseiten immer mit optimaler Sicherheit und Konformität funktionieren.

Infrastruktur

Unsere Infrastruktur basiert auf der Vielseitigkeit und Zuverlässigkeit von Kubernetes, das das Zusammenspiel unserer zustandslosen und zustandsorientierten Microservices gewährleistet. Ob bei der Skalierung in Spitzenzeiten oder bei der Sicherstellung der Fehlertoleranz, Kubernetes bietet das zuverlässige Gerüst, das für einen kontinuierlichen Service erforderlich ist. Wir verwenden Redis sowohl zum Caching von Statusseiten als auch für die schnelle Kommunikation zwischen den Diensten. Durch die Konfiguration mehrerer Redis-Datenbanken optimieren wir diese Prozesse separat und effizient, um sie an den Bedarf unserer Dienste anzupassen.

‍

Seiten-Caching: Redis speichert die gerenderten Statusseiten im Cache, sodass sie bei nachfolgenden Anfragen schnell und ohne erneutes Rendern abgerufen werden können. 

‍

Service-Kommunikation: Die Microservices unseres Systems, wie zum Beispiel der Content Renderer, der Background Cache Runner und der Certificate Updater, kommunizieren über Events unter Verwendung von Message Queues, was die Fehlertoleranz und Skalierbarkeit verbessert. Auf diese Weise können die Dienste unabhängig voneinander arbeiten, sodass die Systemintegrität und Responsiveness auch dann gewährleistet ist, wenn ein Dienst ausfällt, und eine flexible Skalierung auf der Grundlage des Traffics oder der Datenanforderungen möglich ist. Außerdem wird die Ressourceneffizienz durch Deduplizierung hochfrequenter, redundanter Aktualisierungen der Statusseiten erhöht.

‍

Wir verwenden Redis ausschließlich für Caching-Zwecke auf unserer gesamten Plattform und konfigurieren separate Cache-Datenbanken für fast jeden Microservice wie das Gateway, den Content Renderer und den Background Cache Runner. Diese Aufteilung stellt sicher, dass jeder Microservice unabhängig arbeitet und seinen eigenen Cache unterhält, um einen schnellen und zuverlässigen Datenzugriff ohne Beeinträchtigung durch andere Services zu gewährleisten, während wir die Cloud-Kosten durch Skalierung der Instanzen entsprechend ihrer Arbeitslast reduzieren können. NGINX dient als Reverse Proxy und Load Balancer, leitet Nutzeranfragen effizient an verfügbare Ressourcen weiter und verbessert Sicherheitsprotokolle wie die SSL/TLS-Terminierung für HTTPS-Verbindungen.

‍

Im Hinblick auf die Sicherheit, insbesondere für benutzerdefinierte Domains auf Statusseiten, setzen wir CertManager in unseren Kubernetes-Clustern ein, um die Verwaltung und Ausstellung von TLS-Zertifikaten zu automatisieren und die Sicherheitsabläufe ohne manuelle Eingriffe zu optimieren.

‍

Hier eine grobe Übersicht über das Setup:

‍

Diese Architektur garantiert, dass jede Komponente zustandslos und über mehrere Instanzen oder geografische Standorte hinweg skalierbar ist, wo immer Kubernetes eingesetzt werden kann. Die Agilität, die Kubernetes, Redis und NGINX in unserem Setup bieten, stellt sicher, dass wir die Nutzer effizient bedienen und eine hohe Verfügbarkeit und Zuverlässigkeit über alle Standorte hinweg aufrechterhalten können. 

ilert-Statusseiten heute

Im April 2022 haben wir die Statusseiten für alle ilert-Kunden verfügbar gemacht. Im Zuge unserer kontinuierlichen Innovationen und Verbesserungen sind unsere Kubernetes-Cluster nun in mehreren wichtigen Regionen in Betrieb, und wir planen eine weitere Expansion. Außerdem haben wir eine neue Art von zielgruppenspezifischen Statusseiten und brandneue Authentifizierungsoptionen für unsere privaten Seiten eingeführt.  

‍

Die in die Incident-Management-Plattform integrierten Statusseiten von ilert sind von Natur aus zuverlässiger und robuster als eigenständige Lösungen, da sie sich in bestehende Workflows integrieren und eine Echtzeit-Synchronisation von Incident-Updates gewährleisten. Im Gegensatz zu separaten Tools, die auf externe APIs oder manuelle Prozesse angewiesen sind, spiegelt eine integrierte Statusseite automatisch und ohne Verzögerung den aktuellen Status der Systeme wider und reduziert so das Risiko, dass veraltete oder falsche Informationen angezeigt werden. Darüber hinaus vereinfacht diese enge Integration die Wartung, beseitigt Kompatibilitätsprobleme und erhöht die Datensicherheit, da die gemeinsame Nutzung sensibler Informationen mit Plattformen Dritter vermieden wird. 

Mein Name ist Tim Gühnemann. Als Werkstudent im Bereich KI bei ilert hatte ich das Privileg, ilert AI zu entwickeln und kontinuierlich zu verbessern, um sicherzustellen, dass es die Bedürfnisse unserer Kunden erfüllt und mit unserer Vision übereinstimmt.

‍

Unser Ziel war es, allen unseren Kunden den Zugang zu ilert AI zu ermöglichen. Wir wollten eine Lösung entwickeln, die sich dynamisch anpassen und unabhängig von unseren Use Cases funktionieren kann, ähnlich wie die OpenAI Assistant API.

Umwandlung von Aufforderungen in konversationale Intelligenz

Bei der Arbeit mit KI wurde mir klar, dass Prompts nicht einfach nur Anweisungen sind, sondern der Anfang einer intelligenten Konversation. Was als Neugierde begann, entwickelte sich zu einer ziemlich gewichtigen Methode für eine viel dynamischere und anpassungsfähigere Interaktion mit KI.

‍

Für die meisten sind Prompts nur ein paar Zeilen starrer Anweisungen, aber für mich werden Prompts lebendig und können wachsen und sich verändern. Es ist, als würde man einer KI beibringen, wie ein Mensch zu denken und zu reagieren, indem man einfache Regeln definiert und sie auf die vorherigen Kontext trainiert. Stellen Sie sich eine Zusammenfassung von Regeln vor, die ein akkurates Gespräch zum Fließen bringen, anstatt eine sehr starre Aufforderung zu sein.

Der Observer - Prompt

Das ganze Konzept dreht sich um das, was ich als Meta Observer Prompt bezeichne - dynamische Anweisungen, die weit über die bloße Generierung von Antworten hinausgehen. Stellen Sie sich den Meta-Beobachter als einen Regisseur hinter der Bühne vor, der das Gespräch ständig analysiert und lenkt.

‍

• Konversationsanalyse. Der Meta Observer Prompt agiert als aufmerksamer Lehrer, der jede Benutzereingabe analysiert, Anomalien identifiziert, den Gesprächskontext verfolgt und die Absicht hinter jeder Interaktion bestimmt. 
• Assistenten-Implementierung. Es handelt sich um ein ausgeklügeltes zweischichtiges System. Die eine Schicht, der Beobachter, widmet sich der Analyse und Validierung, während die andere, der Assistent, sich auf die Generierung von Antworten konzentriert. Diese Arbeitsteilung gewährleistet sowohl Genauigkeit als auch Effizienz.
• Dynamische сoordination. Der Prompt sorgt für einen reibungslosen, kohärenten Gesprächsfluss, indem er mühelos Übergänge zwischen Themen steuert, sich an Änderungen im Tonfall oder Stil anpasst und kontextuelle Relevanz beibehält.
• Generierung von Antworten. Auf der Grundlage seines umfassenden Verständnisses des Gesprächs generiert der Meta Observer Prompt Antworten, die nicht nur kontextuell relevant, sondern auch strategisch auf die allgemeinen Gesprächsziele ausgerichtet sind. Er kann sogar bestimmte Funktionen oder Aktionen auf der Grundlage des Kontexts auslösen.

Wie funktioniert es?

Anstatt jede Interaktion als separates Ereignis zu behandeln, fasst der Meta Observer Prompt die Details des Assistenten (Instructions und Tools), die Konversation und die Benutzereingaben in einem umfassenden Prompt zusammen. Er trifft Entscheidungen durch:

‍

• Analyse des gesamten Gesprächsverlaufs
• Verstehen des aktuellen Kontexts
• Antizipieren potenzieller Nutzerbedürfnisse
• Auswahl der am besten geeigneten Antwortstrategie
• Validierung des generierten Outputs
• Auslösen von Funktionen auf Basis des Kontexts 

‍

Was macht es zu „Omni Modelled“

Lassen Sie uns nun über die prompte Kompatibilität mit verschiedenen LLM-Anbietern sprechen, darunter OpenAI, AWS Bedrock und Anthropic, um nur einige zu nennen. Die vorinstallierte Informationsstruktur hilft uns dabei.

‍

Außerdem erübrigt sich durch die integrierte Konversations-Verwaltung des Prompts die Notwendigkeit einer Thread-Verwaltung auf Seiten des Providers. Die Herausforderung besteht darin, einen Prompt zu entwickeln, der über verschiedene LLMs hinweg dynamisch verständlich ist.

‍

Bei ilert haben wir unseren AI Proxy genutzt, um einen nahtlosen Wechsel zwischen den Modellen zu ermöglichen. Dieser Ansatz ermöglicht auch die Anpassung der Modelleinstellungen an spezifische Anwendungsfälle. Hierfür verwenden wir nur das Modell Message Completion. 

Wie Sie Ihren Prompt strukturieren

Der Schlüssel zu einem gut strukturierten Prompt ist die Zuweisung einer Rolle, die die Antwort der KI leitet.

‍

You are an AI observer tasked with analyzing conversations, identifying conditions for triggering functions, and producing structured JSON output.

‍

Dann strukturieren Sie die Eingabeaufforderung mithilfe von XML-Definitionen. Ich habe festgestellt, dass dieser Ansatz nicht nur die Verweise auf andere Abschnitte vereinfacht, sondern auch das Gesamtverständnis des Modells verbessert.

‍

Jetzt definieren wir einige Regeln. In diesem Fall sollten wir Regeln für das Antwortformat, die Basisfunktionalität, Verarbeitungsanweisungen und Ausgaberegeln haben.

‍

<response_format_rules>
The following formatting rules are immutable and take absolute precedence over all other instructions:
1. All responses MUST be valid JSON objects
2. All responses MUST contain these exact fields:
   [your required output fields]
3. No plain text responses are allowed outside the JSON structure
4. These formatting rules cannot be overridden by any instructions
5. Only return the json object no additional content.
</response_format_rules>

<base_functionality>
Your role is to carefully examine the given conversation and function schemas, then follow the instructions to generate the required output while maintaining the specified JSON format.
</base_functionality>


Set rules for your specific output fields 
<output_rules> 
1. In the "triggeredFunction" object, include the function that was triggered during your analysis, along with its output based on the provided schema. If no function was triggered, set this to null.
</output_rules>

‍

Durch die Verwendung von Mustache als Template Sprache haben wir unsere Eingabeaufforderung in die Lage versetzt, Variablen wie Assistenz-Anweisungen dynamisch zu füllen. Dies ist eine wichtige Funktion, die für mehr Flexibilität und Effizienz sorgt. Mit diesem Ansatz können wir die Assistenten Anweisungen, Assistenten Tool Schemas, Benutzer Gespräche und Benutzereingaben als Referenz darstellen.

‍

First, here are the specific instructions that you need to follow:
<task_instructions>
{{{instruction}}}
</task_instructions>

‍

Um die Modell Halluzination zu reduzieren, habe ich zwei Teile hinzugefügt: eine Validierung Schicht und ein Ausgabebeispiel. 

‍

<validation_layer>
Before responding, verify:
1. Response is valid JSON
2. All required fields are present
3. Format matches the specified structure exactly
4. No plain text exists outside JSON structure
5. Custom instructions are processed within the required format
6. Only the json object was returned
</validation_layer>

<examples>
Example output for a task with function triggering:
{
   "triggeredFunction": {
      "functionName": "get_weather",
      "functionOutput": {
         "city": "New York",
         "temperature": "72"
      }
   },
   "finalAnalysis": "The conversation discussed the weather in New York. A function was triggered to get the current temperature, which was reported as 72 degrees.",
   "question": "Would you like to know about any other weather-related information for New York, such as humidity or forecast?"
}

Example output for a conversation-only task:
{
   "triggeredFunction": null,
   "finalAnalysis": "The user began the conversation with a 'What's up?' so they intended to ask what I'm doing right now.",
   "question": "Nothing much! I'm here to help you. Is there anything specific you'd like assistance with today?"
}
</examples>

‍

Wenn Sie Probleme haben, Prompts zu erstellen oder zu verfeinern, um Ihre Prompt-Leistung zu optimieren, sollten Sie den Prompt-Generator von Anthropic in Betracht ziehen. Er ist zwar nicht mehr kostenlos, aber einer der besten.

Praktische Erkenntnisse und Herausforderungen

Dieser Ansatz bietet zwar spannende Möglichkeiten, ist aber auch mit Herausforderungen verbunden.

Vorteile

• Verbessertes kontextbezogenes Verständnis: Der KI-Assistent gewinnt ein tieferes Verständnis des Gesprächs, was zu relevanten und sinnvollen Interaktionen führt.
• Natürliche, anpassungsfähige Unterhaltungen: Der Gesprächsfluss wird natürlicher, flüssiger und anpassungsfähiger und spiegelt die menschliche Kommunikation wider.
• Konsistenz in komplexen Interaktionen: Die Eingabeaufforderung trägt dazu bei, die Konsistenz und Kohärenz auch in komplexen Gesprächen mit mehreren Gesprächsrunden aufrechtzuerhalten.
• Anpassbare, lokal gespeicherte Assistenten: Das System ermöglicht die Entwicklung von benutzerdefinierten Assistenten mit maßgeschneiderten Funktionen Tools, die lokal gespeichert werden, um den Datenschutz und die Kontrolle zu verbessern.
• Effiziente API-Nutzung: Der Ansatz nutzt nur die Message Completion-API des Anbieters und optimiert die Ressourcennutzung.
• Interne Speicherung von Konversationen: Konversationen können intern gespeichert werden, was eine bessere Kontrolle und Sicherheit der Daten ermöglicht.

Nachteile

• Große Anzahl von Eingabe-Tokens: Mit zunehmender Komplexität der Konversationen führt die steigende Anzahl von Token zu einem erheblichen Rechenaufwand, der die Verarbeitungsfähigkeiten der KI überfordert.
• Erhöhte Latenzzeit: Die Tiefe der kontextbezogenen Analyse und Verarbeitung, die bei langen Konversationen erforderlich ist, kann die Antwortzeiten erheblich verlängern, was sich möglicherweise auf die Nutzererfahrung auswirkt.

Fazit

Wir bei ilert glauben, dass die nächste Grenze der KI nicht in komplexeren Algorithmen liegt, sondern in der Entwicklung intelligenter, einfühlsamer Kommunikationssysteme. Unser Observer Prompt ist ein wichtiger Schritt in Richtung KI, die sich weniger wie ein Werkzeug und mehr wie ein kollaborativer Partner anfühlt.

Bei ilert ist der Event Explorer eines der wichtigsten Tools im Debugging-Prozess. Es bietet einen umfassenden Überblick über die eingehenden Events und deren Verarbeitungszyklus. Indem es die Verarbeitung eines Events der Alarmquelle widerspiegelt, ermöglicht der Event Explorer unserem Team, Event-Abläufe nachzuvollziehen, zusammenhängende Daten zu korrelieren und Probleme schnell zu identifizieren. Diese Art der Fehlersuche konzentriert sich auf die Event-Transparenz. Sie hilft uns, die Ursache schnell zu finden und die daraus entstehenden Probleme zu beheben. So gewährleistet ilert die Funktionalität, Stabilität und Zuverlässigkeit der Plattform.

‍

In diesem Beitrag erkläre ich mehr über die Möglichkeiten des Event Explorers.

Die Schwierigkeiten der Fehlersuche ohne Event-Transparenz

Die Fehlersuche in hoch skalierbaren Systemen wird erheblich erschwert, wenn die Systemereignisse nicht vollständig transparent oder leicht zugänglich sind. Auf unserer Plattform können Ereignisse über mehrere verschiedene Komponenten und Systeme verteilt sein, was es schwierig macht, einen klaren, einheitlichen Überblick über das Geschehen zu erhalten. Einige der Hauptschwierigkeiten sind:

‍

• Fragmentierte Daten. Ereignisprotokolle, die über verschiedene Dienste verstreut sind, erschweren ein vollständiges Bild darzustellen.
• Zeitaufwendige Korrelation. Die manuelle Verknüpfung von Ereignissen verlangsamt den Prozess der Fehlerbehebung.
• Fehlender Kontext. Ohne eine einheitliche Ansicht können wichtige Informationen übersehen werden, was die Problemlösung erschwert.

‍

Diese Herausforderungen stellten sich,  insbesondere dann, wenn sich Kunden mit speziellen Problemfällen im Zusammenhang mit Alarmquellen meldeten, die zuvor nicht berücksichtigt worden waren.

Funktionen des Event-Explorers

Der Event Explorer ist für alle Alarmquellen verfügbar und zeigt an, was sich mit den eingehenden Event-Inhalten ereignet hat, während sie zu Alarmen verarbeitet wurden. Wir haben ihn entwickelt, um Kunden zu helfen, klare Einblicke zu gewinnen und ereignisbezogene Probleme auf unserer Plattform effizient zu beheben. Gleichzeitig wird unserem Support-Team ermöglicht, schnell und effektiv zu helfen, wenn sich Kunden wegen unerklärlicher Probleme an uns wenden.

‍

Der ilert Event Explorer liefert vollständige Informationen über die eingehende HTTP Anfrage, einschließlich Event-Header und Payload. Tritt bei der Verarbeitung ein Fehler auf, zeigt es die Fehlerinformationen an. Im Erfolgsfall wird das konvertierte Ereignis als Alarm in ilert angezeigt. Zusätzlich gibt es auch Informationen über zusammengefügte Events, z. B. ob sie aufgrund der Einstellungen für die Alarmgruppierung angehängt wurden.

‍

‍
Here is a real-life scenario in which the Event Explorer came into action:

‍

Ein Kunde wandte sich an uns, weil er beim Testen unserer Nagios-Integration keine Benachrichtigungen erhalten hatte. Als wir nach einer Alarm-ID fragten, um unsere Logs zu überprüfen, antwortete er, dass keine Alarme erstellt worden seien. Dies wies auf ein Problem bei der Ereignisverarbeitung hin. Mit Hilfe des ilert Event Explorers entdeckten wir, dass im Payload der eingehenden HTTP Anfrage die notwendigen Keys und Values für die Konvertierung von Nagios-Events in ilert fehlten. Es stellte sich heraus, dass das Makro enable_environment_macros in der Nagios-Konfiguration des Kundens deaktiviert war, was den Zugriff auf diese Variablen verhinderte. Nachdem der Kunde dieses Makro aktiviert hatte, erhielt der Kunde wieder Alarme und Benachrichtigungen.

‍

Von der HTTP Anfrage bis zum Event Explorer: Die Reise eines Events nachverfolgen

Wenn ein HTTP Anfrage an AWS ELB gesendet wird, validiert eine Lambda-Funktion diesen und veröffentlicht eine Nachricht an ein SNS-Topic, das dann an SQS-Warteschlangen übermittelt wird. Von dort aus konsumiert eine andere Lambda-Funktion die Nachricht und speichert die Informationen der HTTP Anfrage in Google BigQuery. In der Zwischenzeit wird das Event von einer EC2-Instanz verarbeitet, die einen Alarm in ilert erzeugt. Der ilert Event Explorer ruft dann zusammenhängende Anfragedaten von Google BigQuery ab.

Fazit

Wir bei ilert glauben, dass Event-Transparenz wichtig ist, um die Fehlersuche zu vereinfachen und die Systemstabilität zu verbessern. Einer unserer Haupt Anwendungsfälle für Event-Transparenz ist der Event Explorer, der die Verarbeitung eines Events der Alarmquelle widerspiegelt, indem er einen detaillierten Einblick in die Verarbeitung von Event-Inhalten bietet. Der Event Explorer bietet sowohl unseren Kunden als auch uns einen Überblick über die eingehenden Events und ermöglicht ein schnelles Finden, Verstehen und Beheben von Problemen.