Alerts und Benachrichtigungen
Erfahren, wenn ein Workload in Schwierigkeiten ist, und festlegen, wo diese Nachricht ankommt.
Auf dieser Seite
Zwei Hälften
Alerts entscheiden, wann etwas sagenswert ist, und werden pro Projekt eingestellt. Kanäle entscheiden, wo es gesagt wird, und gehören der Organisation, damit mehrere Projekte sich einen teilen können.
Ein Alert ohne Kanal erscheint trotzdem auf der Seite Alerts des Projekts, nur erfährt es niemand. Ein Kanal trägt mehr als Alerts: Deploys, Neustarts, Fehler und Abrechnungsereignisse aller Projekte der Organisation, gefiltert nach der Mindest-Severity, die du ihm gibst.
Einen Kanal einrichten
- Geh in der Organisation auf Notifications.
- Leg einen Kanal an: Slack, Microsoft Teams, E-Mail oder einen allgemeinen Webhook.
- Schick eine Testnachricht. Mach das jetzt, statt mitten in einer Störung festzustellen, dass die Webhook-URL falsch war.
E-Mails
Auch ohne Kanal bekommen Owner und Admins einer Organisation eine Mail, wenn eine App immer wieder abstürzt oder nicht startet, eine Domain eine Stunde nach dem Hinzufügen noch kein Zertifikat hat oder ein Backup scheitert, höchstens einmal pro Vorfall und Tag. Abschalten kannst du das für die Organisation unter Notifications, sobald ein Kanal die Vorfälle bekommt.
Welche Mails du selbst bekommst, wählst du unter Emails auf deiner Account-Seite: Einstiegstipps, Release Notes (höchstens einmal pro Woche) und Vorfälle haben je einen Schalter. Anmeldecodes, Einladungen, Sicherheitshinweise, Abrechnung und Support-Antworten kommen immer.
Schwellwerte wählen
Ein fester Satz Alerts ist immer aktiv: Crash-Loops, wegen Memory beendete Container, Pods, die 10 Minuten nicht bereit sind, gescheiterte Release Commands und Scheduled Jobs sowie Probleme mit PostgreSQL. Drei feuern auf anhaltenden Druck und nicht auf eine einzelne Spitze, und für sie setzt du einen Schwellwert:
| Alert | Feuert, wenn |
|---|---|
| CPU | Die Auslastung dauerhaft über dem Schwellwert bleibt, gemessen am CPU-Limit der App. Apps auf bezahlten Tarifen haben keines, der Alert greift also nur, wo eines gesetzt ist |
| Memory | Der Verbrauch dauerhaft über dem Schwellwert bleibt |
| Volume | Ein Volume über den Schwellwert hinaus volläuft |
Beim Volume lohnt sich Sorgfalt am meisten. Druck auf CPU und Memory macht einen Workload langsam. Eine volle Platte bringt ihn zum Stehen und nimmt oft die Daten mit.
Schwellwerte, auf die du nie reagierst, erziehen dich dazu, den Kanal zu ignorieren. Wenn ein Alert seit einem Monat wöchentlich feuert und niemand etwas tut, heb entweder den Schwellwert an oder repariere den Workload. Ein lauter Kanal ist schlimmer als keiner, weil er den einen verdeckt, auf den es ankommt.
Einstellungen im Überblick
| Einstellung | Standard | Was sie bewirkt |
|---|---|---|
| Aktiv | an | Ob dieses Projekt überhaupt Alerts sendet. |
| CPU-Schwellwert | 80 Prozent des Limits | Anhaltende CPU-Last darüber benachrichtigt. |
| Memory-Schwellwert | 80 Prozent des Limits | Anhaltender Verbrauch darüber benachrichtigt. |
| Volume-Schwellwert | 85 Prozent der Kapazität | Ein Volume, das darüber hinaus volläuft, benachrichtigt. |
| Kanal | alle Kanäle der Organisation | Feuernde Alerts gehen an jeden Kanal, dessen Mindest-Severity sie erreichen. Wird pro Organisation eingerichtet. |
Grenzen und Fallstricke
- Alerts gelten pro Projekt. Jedes neue Projekt startet mit eingeschalteten Alerts und den Standard-Schwellwerten. Du passt sie an, statt sie einzuschalten.
- Kanäle gelten pro Organisation. Wer einen entfernt, macht jedes Projekt stumm, das ihn benutzt hat.
- Das ist keine Verfügbarkeitsüberwachung. Alerts beschreiben deine Workloads von innen. Ob ein Besucher deine Seite erreicht, ist eine andere Frage, die eine externe Prüfung besser beantwortet.
- Es wird niemand angepiepst. Eine Nachricht landet in einem Kanal. Sie eskaliert nicht und weckt niemanden.
Verwandt
- Volumes, die Ressource, deren Alert am meisten zählt.
- Wenn etwas nicht läuft dazu, was zu tun ist, wenn einer feuert.