AI SRE für die Nachtschicht

Warum funktionierte BigQuery nicht mehr für uns?

Über Jahre hinweg stellten wir unseren Kunden umfassende Analytics für ihre Alarmierungen, Benachrichtigungen und Bereitschaftsaktivitäten bereit. So erhielten sie einen umfassenden Überblick darüber, wie ihre Teams und Services auf Incidents reagieren.

Diese Funktionen basierten auf einer separaten analytischen Datenbank, die auf Google BigQuery lief. Darin lagen die Zahlen hinter jedem Reporting-Dashboard in ilert. Und lange Zeit war das völlig ausreichend.

Dann wurden drei Probleme zu groß, um sie weiter ignorieren zu können:

• Es war die langsamste Anwendung auf unserer Plattform. Analytics-Dashboards liegen zwar nicht auf dem kritischen Pfad von ilert, waren aber spürbar träge: im Durchschnitt mehrere Sekunden und bei unseren größten Kunden bis zu zwanzig Sekunden. Das war nicht die Leistung, die wir bieten wollten.
• Wir zahlten pro Abfrage. BigQuery rechnet nach gescannten Bytes ab. Unser Workload besteht jedoch aus denselben wenigen Dashboards, die immer wieder ausgeführt werden. Dadurch zahlten wir wieder und wieder dafür, Fragen zu beantworten, die wir bereits gestellt hatten.
• Das Aktualisieren einzelner Zeilen war schwierig. Einige unserer Analytics sind nicht append-only. So ändern sich zum Beispiel der Status einer Alarmierung sowie die TTA (Time to Accept) und die TTR (Time to Resolve), wenn die Alarmierung bestätigt und gelöst wird. Die gespeicherte Zeile muss diese Änderungen entsprechend abbilden. BigQuery ist auf Appends und vollständige Neuschreibungen ausgelegt. Row-Level-Updates sind dort langsam und umständlich.

Und es gab einen zusätzlichen Bonus: BigQuery war zufälligerweise der letzte Workload, der uns noch auf Google Cloud hielt. Durch die Ablösung konnten wir einen ganzen Provider und zugleich einen Subprozessor aus unserem Tech Stack entfernen.

Also haben wir unsere Analytics auf ClickHouse umgestellt, betrieben auf unserer eigenen AWS-Infrastruktur. Abfragen, die früher rund zehn Sekunden dauerten, liefern ihre Ergebnisse jetzt in unter zwei Sekunden. Und so gingen wir vor:

Unser Workload

Unser Analytics-Workload besteht hauptsächlich aus:

1. Events: die rohen Alarmierungs-Events, die ilert aufnimmt und verarbeitet. Ein hochvolumiger, append-only Stream und die Quelldaten, auf denen alles Weitere aufbaut.

2. Statistiken: die Aggregationen hinter unseren Kernfunktionen: Alarmierungen, Benachrichtigungen und Bereitschaftsberichte

3. Entity state transitions: die Historie, wie sich unsere Kernentitäten durch ihren Lifecycle bewegen: Call Flows, Event Flows und Incidents. Wir protokollieren, was im Zeitverlauf passiert ist, wobei jede Transition als eigene, klar getrennte Zeile gespeichert wird: eine Zeile pro Entität und Änderung.

Diese drei Workloads prägten sowohl die oben genannten Probleme als auch das folgende Design. Was wir brauchten, war eine schnelle, spaltenorientierte Datenbank, optimiert für mandantenbezogene Lesezugriffe über bestimmte Zeiträume hinweg, mit einer Table Engine, die auch Mutationen verarbeiten kann. Auf der Shortlist standen außerdem Apache Druid, Apache Pinot, StarRocks und TimescaleDB. ClickHouse passte jedoch am besten zu unserem Zugriffsmuster. 

Und genauso wichtig: Es war kein riskantes Unterfangen. Wir hatten das Projekt seit Jahren verfolgt und beobachtet, wie es immer ausgereifter wurde. ClickHouse hat sich im Lauf der Zeit als etablierte Lösung für große Unternehmen wie Uber, Cloudflare und Cisco durchgesetzt.

Warum nicht einfach BigQuery optimieren?

Das ist eine berechtigte Frage und wir stellten sie uns als Erstes. BigQuery bietet echte Lösungen für langsame interaktive Dashboards: BI Engine, Reservations, Materialized Views. Jede dieser Optionen hätte bei der Geschwindigkeit geholfen, wahrscheinlich auch bei den Kosten. Aber jede davon hätte uns auf Google Cloud gehalten. Zu diesem Zeitpunkt war BigQuery unser einziger verbleibender GCP-Workload. Alles andere lief bereits auf unserer eigenen AWS-Infrastruktur.

Eine Optimierung von BigQuery hätte zwei unserer drei Probleme gelöst, gleichzeitig aber einen zweiten Cloud-Provider und einen zweiten Subprozessor dauerhaft in unserem Stack verankert. Den Workload stattdessen zu migrieren, ermöglichte uns, Geschwindigkeit und Kosten zu verbessern und zwei Provider auf einen zu reduzieren.

Das gab den Ausschlag: migrieren, anstatt zu optimieren.

Datenaufnahme mit Kafka als Zwischenschicht

Wie in der Branche üblich, sind unsere operativen und analytischen Datenspeicher entkoppelt und nur eventual consistent, mit einem zwischengeschalteten Buffer. Kafka nutzten wir bereits für diesen Buffer, daher war es auch die naheliegende Wahl, um Daten in ClickHouse einzuspeisen.

Der Realtime-Flow:

1. Source Services besitzen ihre operativen Daten weiterhin selbst, so wie bisher.
2. Ein dedizierter CDC-Service (Change Data Capture) liest Change Events und exportiert sie in Kafka Topics: ein logischer Stream pro Workload.
3. Consumer Worker lesen aus Kafka, bündeln die Zeilen clientseitig in Batches und schreiben sie in ClickHouse.

Der Backfill-Flow nutzte denselben Pfad, allerdings mit einer anderen Quelle:

1. Ein Export-Job liest die historischen BigQuery-Tabellen nacheinander aus und streamt die Zeilen in ein Kafka Topic.
2. Ein Backfill Consumer bündelt diese Zeilen in Batches und schreibt sie in ClickHouse, genauso wie es die Realtime Consumer tun.

Diese Consumer Worker mussten vor allem eines gut können: Zeilen effizient in ClickHouse schreiben. ClickHouse ist am schnellsten bei großen, weniger häufigen Inserts und langsam bei vielen kleinen. Deshalb bündelt jeder Consumer die Zeilen clientseitig in Batches und schreibt sie, sobald eines von zwei Kriterien erreicht ist: ein definierter Größenwert oder ein kurzer Timer.

Der Kafka Offset wird erst committet, nachdem der Batch erfolgreich geschrieben wurde. Offset und Insert bewegen sich gemeinsam. Andernfalls könnte ein Crash dazu führen, dass Zeilen bestätigt werden, die nie in der Tabelle angekommen sind.

Warum der Weg über Kafka statt Dual-Writing?

• Entkopplung: Die Source Services wissen nicht und müssen auch nicht wissen, dass ClickHouse existiert. Wenn der analytische Datenspeicher wegen Wartungsarbeiten nicht verfügbar ist, werden Events in Kafka in eine Queue geschrieben. Upstream wird dadurch nichts blockiert.
• Replayability: Während einer Migration kann es jederzeit passieren, dass ein Schema oder eine Transformation nicht auf Anhieb stimmt. Da der Stream in Kafka vorgehalten wird, können wir Offsets zurücksetzen und die Daten erneut in eine korrigierte Tabelle einlesen, statt jeden Source Service aufzufordern, seine Historie noch einmal zu senden.
• Backfill und Cutover parallel: Wir haben historische Daten in ClickHouse nachgeladen, während der Live-Stream weiterlief. Sobald beide Datenstände übereinstimmten, haben wir die Reads umgestellt.
• Natürliche Batching-Grenze: ClickHouse ist am schnellsten, wenn Daten in großen Batches und mit weniger Schreibvorgängen eingefügt werden. Ein Kafka Consumer ist der ideale Ort, um einen Batch aufzubauen und ihn dann zu flushen.

Erstellung des ClickHouse Schemas

Eine der wichtigsten Entscheidungen bei der Einführung von ClickHouse ist die Wahl der Table Engine. Im Kern läuft sie auf eine Frage hinaus: Können die Daten verändert werden und wenn ja, auf welche Weise? Neben der Engine folgen unsere Tabellen einigen gemeinsamen Konventionen. Jede Tabelle ist über den Cluster hinweg geshardet und zur Ausfallsicherheit repliziert. Sie ist nach Monaten partitioniert und erst nach Tenant, dann nach Zeit sortiert. So greift eine Datumsbereichsabfrage eines Tenants auf den kleinstmöglichen Datenausschnitt zu. Die Spalten werden mit typgerechten Codecs komprimiert. Außerdem hat jede Tabelle eine TTL, damit Daten gemäß ihrem jeweiligen Retention-Zeitplan automatisch entfernt werden, statt unbegrenzt weiter anzuwachsen.

Bei der Analyse unserer Use Cases gab es einen Fall, der eindeutig Mutability erfordert:

• Alert Analytics: Wenn sich eine Alarmierung von ausgelöst über bestätigt bis gelöst bewegt, fügen wir sie einfach erneut mit ihrem neuen Status ein. ClickHouse behält die neueste Version und entfernt die älteren beim Merge. Reads fragen den aktuellen Status mit FINAL ab, wodurch diese alten Versionen zur Query-Zeit entfernt werden. Das ist ReplicatedReplacingMergeTree.

Mit Blick auf den nötigen Backfill haben wir uns jedoch entschieden, die „Replacing“-Engine auch für alle anderen migrierten Tabellen zu verwenden.

Warum diese Struktur das sichere Beheben von Migrationsproblemen ermöglicht

Datenmigrationen sind selten sauber. Fast immer merkt man mitten im Prozess, dass eine Transformation subtil fehlerhaft war, und muss den gesamten Backfill noch einmal ausführen. Bei einer einfachen append-only Tabelle bedeutet ein erneuter Lauf, dass jede bereits eingefügte Zeile ein zweites Mal geschrieben wird. Das erneute Einlesen des Backfills wird dadurch zu einer Aufgabe nach dem Muster: Tabelle leeren und von vorn beginnen. Und das ist jedes Mal riskant.

Die „Replacing“-Engine ändert das. Da sie anhand des vollständigen ORDER BY-Tuples dedupliziert und die Zeile mit der höchsten Version Column behält, ersetzt das erneute Einlesen derselben logischen Zeilen aus dem Stream diese einfach. Zeilen, die beim ersten Mal fehlten, werden dabei ergänzt.

So ist das erneute Einlesen des Backfills keine Aufräumaktion mehr, sondern ein sicher wiederholbarer Prozess: Consumer zurücksetzen, laufen lassen, und die Tabelle landet im korrekten Zustand. Nichts wird dupliziert, nichts muss geleert werden, und FINAL liefert die bereinigte Sicht, noch bevor die Background Merges aufgeholt haben.

FINAL ist nicht kostenlos. Für uns ist der Overhead aber akzeptabel, weil keine der APIs, die auf diesen Tabellen basieren, auf einem Hot Path der Plattform liegt. In der Praxis ist der Mehraufwand daher vernachlässigbar.

Der knifflige Teil: die Queries portieren

Das Anlegen der Tabellen war der einfache Teil. Die analytischen Queries von BigQuerys SQL-Dialekt auf den von ClickHouse zu portieren, erforderte deutlich mehr Sorgfalt. Die gefährlichen Bugs waren dabei nicht die, die einen Fehler auslösten. Es waren die, die eine absolut plausible Zahl zurückgaben, die trotzdem falsch war.

Selbst mit Unterstützung von AI Assistants brauchten wir mehrere Iterationen, um jede Query sauber zu übertragen. Dabei haben wir uns auf unsere Testdaten gestützt, damit die neuen Queries funktional identisch zu den alten sind.

Fallstricke waren zum Beispiel:

• %M steht für den Monat, nicht für Minute: In formatDateTime gibt %M den vollständigen Monatsnamen aus, während %i für Minute steht. Schließlich verwendeten wir die bereitgestellten Shortcuts: %F = %Y-%m-%d, %T = %H:%i:%S 
• Nicht aggregierte Spalten: BigQuery erlaubt es, eine Spalte per SELECT abzufragen, die nicht im GROUP BY enthalten ist, solange sie funktional davon abhängig ist. ClickHouse lehnt das ab. Fügt man die Spalte einfach zum GROUP BY hinzu, werden Zeilen stillschweigend aufgeteilt und führen zu Double-Counting, sobald diese Spalte innerhalb der Gruppe variiert. Die richtige Lösung ist, sie mit Aggregaten wie any() oder min() zu umschließen.
• Indexing beginnt bei 1: Arrays und Tuples sind in ClickHouse 1-basiert. BigQuerys [OFFSET(0)] für das erste Element wird zu [1], und Tuple-Felder werden als t.1, t.2 angegeben. 
• Durchschnitt über „übersprungene“ Zeilen berechnen: In unseren Daten bedeutet eine TTA oder TTR von 0, dass die Alarmierung nie bestätigt oder gelöst wurde, nicht dass sie null Sekunden gedauert hat. Ein einfaches AVG würde diese Nullen mitzählen und den Wert nach unten ziehen. Deshalb mussten wir folgenden Ausdruck verwenden: COALESCE(ROUND(AVG(CASE WHEN x != 0 THEN x END)), 0).‍

Welche Kompromisse sind wir eingegangen?

ClickHouse selbst zu Hosten bringt eine eigene Komplexität mit sich, die wir bewusst in Kauf genommen haben:

• Wir betreiben ClickHouse jetzt selbst: Replikation, ZooKeeper, Server-Upgrades, Backups, Capacity Planning — all die Dinge, die BigQuery im Hintergrund übernommen hat, liegen heute bei unserem Team. Wir haben uns bewusst dafür entschieden. Das ist der Preis dafür, Performance kontrollieren und auf einen einzigen Provider konsolidieren zu können.
• Wir dimensionieren für Peak-Zeiten: Es gibt keine serverlose Elastizität. Der Cluster ist für unsere besonders ausgelasteten Zeiten vorgesehen und bleibt in der übrigen Zeit weniger stark genutzt. Für einen so vorhersehbaren Workload wie unseren ist das trotzdem günstiger als die Abrechnung pro Query.
  

Die Ergebnisse

Die Kennzahl, die für uns am wichtigsten war, hat sich genau so verbessert, wie wir es uns erhofft hatten: Die p95-Latenz der Dashboard-Queries sank von rund zehn Sekunden auf unter zwei Sekunden. ‍Das entspricht einer Beschleunigung um etwa das 5-Fache.

Alles Weitere ergab sich aus dem Design:

• Kosten: Die Abrechnung nach gescannten Daten pro Query entfällt und Stattdessen haben wir nun fixe, planbare Kosten für einen Cluster, der auf Hardware läuft, die wir ohnehin betreiben.
• Schlankeres Schema: Da wir das Alert-State-Feld über ReplacingMergeTree aktualisieren können, konnten wir auf ein kompakteres Tabellenlayout umstellen, statt die Append-and-Rewrite-Workarounds zu nutzen, die BigQuery erforderte.
• Operative Resilienz: Da Kafka die Ingestion puffert, ist ein ClickHouse-Wartungsfenster eine Queue, die später abgearbeitet wird, kein Datenverlust. Und eine fehlerhafte Transformation ist ein Replay, kein Incident.
• Eine Abhängigkeit weniger: BigQuery war unser letzter Workload auf GCP. Durch die Ablösung konnten wir einen kompletten Cloud-Provider aus unserem Tech Stack entfernen.
  

Alles in allem sind wir mit der Migration sehr zufrieden. Die oben genannten Verbesserungen waren das Ziel. Der größere Gewinn liegt aber darin, was sie möglich machen: Mit schnellen, bezahlbaren Realtime-Analytics als neuer Baseline lassen sich umfangreichere Reports und tiefere Insights plötzlich kosteneffizient umsetzen. 

In Kürze werden daher deutlich mehr Analytics-Funktionen auf der ilert-Plattform verfügbar sein.

Nicht alle Alarmierungen sind gleich. Einige können schnell von der Dienstbereitschaft gelöst werden. Andere weisen auf ein Problem hin, das schwerwiegend genug ist, um das gesamte Unternehmen zu beeinträchtigen. Sie erfordern die Koordination des gesamten Teams. Deshalb haben wir Incidents als dedizierten Workspace für die Koordination von Alarmierungen mit dem größten Business Impact neu konzipiert.

‍

Bisher wurden Incidents in ilert genutzt, um Status-Updates an Kunden und Stakeholder zu kommunizieren. Einen Incident zu erstellen bedeutete gleichzeitig, ihn auf der Statusseite zu veröffentlichen. Wir haben jetzt beides voneinander getrennt: Incidents bleiben intern – Status-Updates dienen weiterhin der externen Kommunikation. Sie werden nur veröffentlicht, wenn Sie sich aktiv dafür entscheiden.

‍

Innerhalb eines Incidents kann Ihr Team einen Incident Channel erstellen, parallele Eskalationen auslösen, die Timeline nachverfolgen, den Status verwalten und Postmortems erstellen. Kunden erhalten keine Informationen, bis ein Status-Update veröffentlicht wird.

‍

Hier ist ein Überblick darüber, was sich geändert hat und was neu ist.

Incidents als interner Workspace für die Koordination

Bisher bedeutete das Erstellen eines Incidents in ilert, dass direkt ein Update auf der Statusseite veröffentlicht wurde. Die Koordination des Incidents fand innerhalb der Alarmierungen statt, und Informationen wurden in dem Moment öffentlich, in dem ein Incident erstellt wurde.

‍

Das ist jetzt nicht mehr der Fall: Incidents bleiben intern. Nichts wird öffentlich, bis Sie ein Status-Update veröffentlichen. Beim Erstellen eines Incidents öffnet sich ein interner Workspace für das Response Team. Nichts gelangt auf die Statusseite, bevor Sie sich für die Veröffentlichung eines Status-Updates entscheiden. Beides ist jetzt vollständig entkoppelt.

Alarmierungen, Incidents und Status-Updates

Mit dieser Änderung gibt es in ilert jetzt drei klar voneinander getrennte Objekte, die jeweils einen eigenen Zweck erfüllen:

• • Alarmierungen haben sich nicht geändert. Sie weisen auf Probleme hin und benachrichtigen Ihr Team.
  • Incidents sind jetzt ein dedizierter interner Workspace für die Koordination der Incident Response. Sie sind nicht mehr mit der Statusseite verknüpft.
  • Status-Updates sind jetzt von Incidents getrennt. Über sie kommunizieren Sie mit Kunden und Stakeholdern, sobald Sie dazu bereit sind.

Bestehende Incidents werden automatisch zu Status-Updates migriert. Es werden keine Daten gelöscht.

Incidents mit Schweregrad und eigenem Channel deklarieren

Beim Deklarieren eines Incidents erscheinen zwei neue Felder: Schweregrad und Incident Channel.

Schweregrad

Mit dem Schweregrad lässt sich der Business Impact bereits beim Deklarieren eines Incidents klassifizieren. Das ist hilfreich für Routing, Reporting und klare Erwartungen im Team. Beim Deklarieren eines Incidents ist der Schweregrad standardmäßig auf SEV3 gesetzt und kann je nach Kontext geändert werden.

Incident-Kanal

Beim Deklarieren eines Incidents kann ein dedizierter KanalChannel erstellt werden. Bisher erfolgte dies über Alarmierungen. Jetzt ist der KanalChannel direkt im Incident verankert, wo der gesamte Kontext für die Incident Response an einem Ort gebündelt ist.

Ein vollständiger Incident-Response-Workspace: parallele Eskalationen, Incident Commander, Status, Timeline und Postmortems

Nach der Deklaration wird der Incident zum zentralen Ort, an dem das Team die Incident Response koordiniert.

Parallele Eskalationen

Mit parallelen Eskalationen lassen sich beim Deklarieren eines Incidents mehrere Teams und einzelne Personen gleichzeitig benachrichtigen. Ihr Team muss nicht warten, bis eine Eskalationskette Schritt für Schritt durchlaufen wurde, bevor die nächste ausgelöst wird.

‍
Folgendes kann gleichzeitig ausgelöst werden:

• eine Eskalationskette
• ein Dienstplan
• ein komplettes Team, bei dem alle Mitglieder gleichzeitig benachrichtigt werden
• ein bestimmter Nutzer direkt

Wird ein Team direkt benachrichtigt, stoppt das erste Teammitglied, das dem Incident beitritt, die Benachrichtigung für alle anderen. Diese erhalten eine „Page resolved“-Benachrichtigung.

Incident commander

Mit dem Incident Commander lässt sich ein bestimmtes Teammitglied zuweisen, das die Verantwortung für die Incident Response übernimmt. So hat das Team vom Deklarieren bis zur Lösung des Incidents eine zentral verantwortliche Person.

Incident-Status

Der Incident-Status kann während der Bearbeitung nachverfolgt und aktualisiert werden. So bleiben alle intern darüber informiert, wo die Incident Response gerade steht.

Incident-Timeline

Die Incident-Timeline zeichnet jede Aktion, jede Benachrichtigung und jede Änderung automatisch in Echtzeit auf. Das ist hilfreich, während der Incident läuft und unerlässlich beim Erstellen des Postmortems.

Postmortems

Postmortems wurden von Status-Updates zu Incidents verschoben – dorthin, wo der vollständige Verlauf tatsächlich erfasst wird. Wenn ein Incident gelöst wird, kann ein Postmortem erstellt werden, wobei Informationen aus der Timeline, Nachrichten aus dem Incident-Kanal und verknüpfte Alarmierungen mit einfließen.

Status-Updates: Kommunikation mit Stakeholdern

Was bisher auf der Statusseite als Incident bezeichnet wurde, heißt jetzt Status-Update. Die Funktionalität bleibt ansonsten unverändert. Status-Updates haben jetzt eine eigene dedizierte Seite in ilert.

Es gibt zwei Möglichkeiten, ein Status-Update zu erstellen:

Status-Update über die Status-Updates-Seite veröffentlichen

Die Status-Updates-Seite bietet eine dedizierte Ansicht aller veröffentlichten Updates. Sie können nach Service, Statusseite und Erstellungsdatum filtern und neue Updates direkt von dort aus veröffentlichen.

Status-Update über einen Incident veröffentlichen (empfohlen)

Bearbeiten Sie den Incident intern und veröffentlichen Sie ein Status-Update, sobald Sie bereit sind, extern zu kommunizieren. Das Status-Update wird mit dem Incident verknüpft, sodass interne Koordination und externe Kommunikation miteinander verbunden bleiben.

Kurz gesagt: Incidents dienen jetzt als interne Koordinationsebene mit dedizierten Tools, die Ihr Team während der Incident Response unterstützen. Status-Updates bleiben unverändert und dienen weiterhin als Kommunikationsebene, um Kunden und Stakeholder zu informieren.

‍

Bei Fragen oder wenn Sie Unterstützung bei dem neuen Set-up benötigen, wenden Sie sich gerne an Ihren Customer Success Manager oder kontaktieren Sie unser Support-Team.

‍

Die Änderungen werden ab Montag, dem 20. Juli, schrittweise ausgerollt. Wenn Sie schneller von den Aktualisierungen profitieren möchten, kontaktieren Sie uns unter support@ilert.com.

‍

Neu bei ilert? Incident-Management ist in allen Tarifen verfügbar. Probieren Sie es kostenlos aus und sehen Sie selbst, wie Ihr Team schneller koordiniert, wenn es darauf ankommt.

Von der neu gestalteten Navigation über den neuen ilert Marketplace bis hin zu dynamischem Service-Mapping und On-Premises-Zustellung von Alarmierungen: Hier ist ein Überblick über alle Neuerungen, die ilert in diesem Quartal ausgerollt hat.

Navigation

Die neue Art der Navigation in ilert

Wir haben die Navigation von ilert neu gestaltet, damit Ihre operative Arbeit im Mittelpunkt bleibt und der Rest der Plattform übersichtlicher wird. Die Ansichten, die im Arbeitsalltag am wichtigsten sind – Dashboard, Alerts, Incidents und My on-call – befinden sich jetzt in einer permanenten Top-Bar. Alles Weitere wurde in eine neue vertikale Seitenleiste verschoben, die drei Arbeitsweisen unterstützt: 

• Mit ausgeklapptem Menü, inklusive Labels und Überschriften.
• Eingeklappt, für mehr Platz auf dem Bildschirm.
• Mit dem Hamburger-Button können Sie zwischen beiden Ansichten wechseln.

Öffnen Sie Ihr Profilmenü und aktivieren Sie „New navigation“, um die neue Navigation auszuprobieren.

Alle Seiten in ilert sind jetzt durchsuchbar 

Jede Seite in ilert ist jetzt über die globale Suchleiste erreichbar. Klicken Sie einfach auf das Suchsymbol und beginnen Sie zu tippen: Alarmierungsquellen, Eskalationsrichtlinien, Heartbeat-Monitore, Audit-Logs  – und Sie landen in wenigen Sekunden an der richtigen Stelle.

Klicken Sie einfach auf das Suchsymbol, um es auszuprobieren. Mit der neuen Befehlspalette (⌘K / Strg+K) springen Sie per Tastenkürzel direkt zu jeder Seite oder Entität.

Alarmierung & Incident-Management

Dynamisches Service-Mapping

Das dynamische Service-Mapping ist da: Legen Sie fest, welche Felder einer Alarmierung Service-Informationen enthalten, zum Beispiel labels.service aus Grafana oder tags.service aus Datadog. ilert liest diese Werte automatisch aus und verknüpft die relevanten Services mit jeder eingehenden Alarmierung.

Manuelles Tagging ist damit nicht mehr nötig. Und wenn ein Service noch nicht existiert, können Sie die automatische Erstellung aktivieren. ilert legt den Service dann für Sie an, bereit zur anschließenden Prüfung.

Schneller Einstieg mit Vorlagen für Alarmierungen 

Eine Vorlage für Alarmierungen von Grund auf zu erstellen, bedeutete bisher: Sie mussten alle Variablen und Felder kennen und schon vorher wissen, wie sie angeordnet werden sollen, bevor überhaupt etwas Brauchbares zu erkennen war.  Wenn Sie jetzt eine Vorlage für eine unserer beliebtesten Integrationen einrichten, ist bereits eine Standardvorlage vorausgefüllt. Sie orientiert sich eng daran, wie ilert diese Alarmierungen standardmäßig formatiert. So starten Sie nicht mehr bei null, sondern mit einer funktionierenden Vorlage.

Bearbeiten Sie einfach die gewünschten Teile, lassen Sie den Rest unverändert und rollen Sie die Vorlage aus. Probieren Sie es aus, wenn Sie das nächste Mal eine Vorlage für eine Alarmierungsquelle erstellen oder bearbeiten.

Das richtige Wartungsfenster schneller finden

Die Liste der Wartungsfenster unterstützt jetzt dieselben Filter wie unsere API: Grenzen Sie Ergebnisse nach Service, Alarmierungsquelle und Datumsbereich ein – mit Auswahlfeldern für „von“ und „bis“. Ob Sie vergangene Wartungsfenster für einen bestimmten Service prüfen, geplante Wartungen für eine bestimmte Alarmierungsquelle ansehen oder alles aufrufen möchten, was nächste Woche ansteht: Sie gelangen mit wenigen Klicks zum gewünschten Ergebnis, statt sich durch die Liste scrollen zu müssen. Filter können kombiniert werden. Außerdem wird die URL beim Filtern automatisch aktualisiert, sodass Sie eine gefilterte Ansicht als Lesezeichen speichern oder mit Ihrem Team teilen können.

Öffnen Sie Alarmierung → Wartungsfenster, um es auszuprobieren.

Alarmierungsberichte unterstützen jetzt Filter nach Schweregrad 

Alarmierungsberichte unterstützen jetzt das Filtern nach Schweregrad. So können Sie Ihre Daten genauso analysieren, wie Ihr Team Alarmierungen einteilt. Filtern Sie nach einer beliebigen Kombination der Stufen 1–5 oder nach „None“ und kombinieren Sie den Schweregradfilter mit bestehenden Filtern für Teams, Quellen, Eskalationsrichtlinien, Responder, Priorität und Labels. Öffnen Sie die Parameter eines beliebigen Alarmierungsberichts und suchen Sie unter Filter nach der Schweregrad-Auswahl.

Konnektivität

Tools hinter der Firewall mit dem Edge Connector anbinden 

ilert-Alarmierungen können jetzt Tools hinter der Firewall erreichen. Der neue Edge Connector läuft innerhalb Ihres Netzwerks, ruft Events von ilert ab und stellt sie lokal an Ihre On-Premises-Systeme zu – ohne eingehende Ports und ohne Änderungen an der Firewall. Lesen Sie die Edge Connector-Dokumentation, um loszulegen.

Rechnungsstellung

Automatische Angebotserstellung, keine E-Mail-Anfrage nötig

Ein offizielles Angebot für Ihren Einkauf einzuholen, bedeutete bisher, dass Sie eine E-Mail an uns schreiben und dann warten mussten, bis jemand Ihr Angebot erstellt. Jetzt können Sie das selbst erledigen. Gehen Sie zu quotes.ilert.com, wählen Sie Ihren Tarif, legen Sie die Anzahl der Nutzer und Add-ons fest, entscheiden Sie sich für monatliche oder jährliche Abrechnung und geben Sie Ihre Unternehmensdaten ein. Anschließend erhalten Sie innerhalb weniger Sekunden ein professionell gebrandetes PDF-Angebot in Ihrem Posteingang. Dafür ist kein ilert-Konto erforderlich. So können Sie den Link einfach mit der Person teilen, die für die Kaufentscheidung zuständig ist.

Wenn Sie das Abonnement abschließen möchten, fügen Sie die Angebots-ID beim Checkout in das Feld „Haben Sie ein Angebot?“ ein. Tarif, Seats und Add-ons werden dann exakt wie im Angebot vorausgefüllt.

Enterprise-Angebote ab 50 Nutzern laufen weiterhin über sales@ilert.com, damit wir die Konditionen individuell auf Ihre Organisation zuschneiden können.

Marketplace

Der neue ilert Marketplace

Im ilert Marketplace finden Sie Apps, die den Funktionsumfang von ilert erweitern. Bis jetzt sind zwei Apps verfügbar, die für bessere Abdeckung und ein gesünderes Team sorgen:

Notification Preference Policy

Mit Notification Preference Policy können Sie die Einhaltung von Benachrichtigungsvorgaben in Ihrem Team prüfen. Definieren Sie die relevanten Richtlinien, zum Beispiel erforderliche Benachrichtigungskanäle und Eskalationsverzögerungen. ilert hebt anschließend sofort alle Nutzer hervor, deren Einstellungen Ihre Anforderungen an die Bereitschaftsabdeckung nicht erfüllen.

Wenn Lücken entstehen, bringt Auto-Fix die Einstellungen mit einem Klick wieder in Einklang mit den Vorgaben. So geht keine kritische Alarmierung verloren, nur weil jemand nicht korrekt eingerichtet war.

On-call Health

On-call Health macht aus Ihren Dienstplandaten aussagekräftige Insights. Analysieren Sie Bereitschaftsdienstpläne, um Health Metrics, Risikofaktoren und Trends teamübergreifend sichtbar zu machen, Burnout frühzeitig zu erkennen und datenbasierte Entscheidungen zu treffen, die die Qualität des Bereitschaftsdienstes verbessern. Dabei berücksichtigt On-call Health auch gesetzliche Vorgaben je nach Land. So bleiben Ihre Bereitschaftsrotationen mit den regionalen Arbeitszeitregelungen konform – unabhängig davon, wo Ihr Team arbeitet.

Beide Apps sind ab sofort verfügbar. Sie finden den Marketplace in Ihrem Profilmenü.

Neue Integrationen

Wazuh: Wazuh ist eine US-amerikanische Open-Source-Sicherheitsplattform. Sie vereint XDR- und SIEM-Funktionen, um Workloads in On-Premises-, virtualisierten, containerisierten und Cloud-Umgebungen zu schützen.

Uptime: Uptime ist eine cloudbasierte Website-Monitoring-Plattform, die Websites, APIs und Services von über 80 globalen Monitoring-Standorten aus auf Verfügbarkeit, Performance und Funktionalität prüft. Checks können dabei bis zu alle 30 Sekunden ausgeführt werden.

Sekoia: Sekoia ist das europäische Cybersicherheitsunternehmen, das die Cyber Operations Platform für das KI-Zeitalter entwickelt. Sekoia vereint Threat Detection and Response, Cyber Threat Intelligence, Exposure Management und agentische KI und baut Cybersicherheit damit von Grund auf neu.