Zum Inhalt

Acknowledgements

Ein Acknowledgement (ACK) heißt zunächst: „Ich habe das gesehen." Was danach passiert, entscheidet eine Checkbox im Dialog — „Ist ein Problem":

  • Angehakt (Default) — „In Arbeit": Der Check bleibt ein echtes Problem und zählt weiter in allen Rollups (Gesundheits-Balken, Problem-Zähler, Glocke). Es gehen nur keine weiteren Benachrichtigungen raus, solange du dich kümmerst.
  • Abgehakt — akzeptierte Ausnahme: Der Check bleibt sichtbar im Nicht-OK-Zustand (eigene Farbe „Accepted"), zählt aber in keinem Problem-Rollup mehr. Sinnvoll für bekannte, bewusst tolerierte Zustände — z. B. ein Testgerät, das dauerhaft einen abweichenden Wert liefert und niemanden mehr stören soll.

Im Gegensatz zur Downtime: ACK ist keine Erwartung im Voraus („das ist Wartung"), sondern eine Reaktion auf ein laufendes Problem.

ACK setzen

Wo Wie
Web-UI Host-Detail / Fehlerübersicht → Service-Zeile → Ack
Mobile-App Host-Detail → Service → Ack-Button

Pflichtfeld: Kommentar — was passiert gerade, wer kümmert sich. Dazu im selben Dialog:

  • Checkbox „Ist ein Problem" (siehe oben) — Default angehakt.
  • Optional „Befristet bis" — ein Ablaufzeitpunkt. Läuft die Frist ab, wird das ACK automatisch aufgehoben (Status geht zurück auf „Offen", Notifications/Eskalation laufen wieder normal).

Notifications (E-Mail, Slack, Teams, …) verlinken direkt auf den betroffenen Check — von dort quittierst du in der Vesana-Oberfläche; einen eigenen Ack-Button direkt in der Nachricht gibt es nicht.

Wirkung

  • Weitere Notifications dieser Alert-Rule sind unterdrückt
  • Eskalation pausiert
  • Status sichtbar im UI mit Ack-Badge + Author + Kommentar
  • SLA: Ack zählt nicht als Downtime — der Service ist weiter im Ausfall, das wird gewertet (Ausnahme: bewusst akzeptierte Checks tauchen dafür nicht mehr im Problem-Rollup auf, s. o.)

Automatischer Bruch bei Verschlimmerung

Wird ein quittierter oder akzeptierter Check schlimmer, als er zum Zeitpunkt des ACKs war (z. B. WARNING quittiert, dann CRITICAL), bricht die Markierung automatisch: der Check wird wieder ein echtes, unquittiertes Problem und Notifications laufen wieder an. Ein ACK auf WARNING-Niveau schützt dich also nicht davor, von einer echten Verschärfung überrascht zu werden.

Auto-Clear bei Recovery

Sobald der Service wieder OK ist:

  • ACK wird automatisch entfernt
  • Status zurück auf OK
  • Optional Recovery-Notification (channelweise einstellbar)

Springt der Service danach erneut auf CRIT (neues Problem oder Flapping), ist das ACK bereits weg — das neue Problem läuft als ganz normaler, frischer Alarm durch, inklusive eigener Wartezeit und Eskalation ab Stufe 1.

ACK + Downtime

Beide gleichzeitig möglich. ACK ist die Aktion eines Operators, Downtime ist die geplante Wartung. Ein Service kann acknowledged sein, während eine Downtime drüber gelegt wird.

ACK in Bulk

Im Error-Overview: mehrere Services auswählen → Ack alle mit gemeinsamem Kommentar (inkl. „Ist ein Problem" und Befristung). Schreibt ein ACK pro Service mit denselben Angaben.

ACK widerrufen

Service-Detail → Ack entfernen. Status bleibt unverändert kritisch, Notifications laufen wieder, Eskalation startet neu (Stufe 1).

Audit

ACKs werden mit track_change geloggt — Author, Service, Kommentar, Zeitpunkt. Filter im Audit-Log: action = ack.create / ack.clear.

Permission

Permission service.ack (Default für Operator+). Ohne diese Permission ist der Ack-Button ausgegraut.

Anschluss