Zum Inhalt

Acknowledgements

Ein Acknowledgement (ACK) heißt zunächst: „Ich habe das gesehen." Was danach passiert, entscheidet die Einstufung im Dialog:

  • Marked as error (Vorgabe, „wird behoben") — „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.
  • Marked as no error („wird nicht behoben") — 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
Fehlerübersicht, Host-Detail, Check-Detail Check-Zeile bzw. Kontextmenü → Acknowledge
Downtimes & ACKs Reiter ACKs → Neuer ACK → Tenant → Geräte → offene Probleme wählen

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

  • Einstufung (siehe oben) — Vorgabe „Marked as error".
  • 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). Darüber steht dieselbe Schnellauswahl wie bei Downtimes (15 Min bis 1 Monat, inklusive „Bis Tagesende" und „Bis morgen 08:00" — dieselbe Liste wie bei Downtimes); ein Klick setzt die Frist und schaltet die Befristung gleich mit ein.

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
  • Entwarnung, sofern der Alarm gemeldet wurde und der Kanal laut Kanal-Feinsteuerung Entwarnungen bekommt

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

In der Fehlerübersicht: mehrere Checks auswählen → Alle ACK (N) mit gemeinsamem Kommentar (inkl. Einstufung und Befristung). Schreibt ein ACK pro Check mit denselben Angaben. Alternativ auf der Seite Downtimes & ACKs über Neuer ACK.

ACK widerrufen

Check-Detail oder Seite Downtimes & ACKs → ACK aufheben (bei einem Sammel-ACK für alle seine noch offenen Checks auf einmal). Der Status bleibt unverändert, Benachrichtigungen laufen wieder, und die Eskalation geht bei der Stufe weiter, bei der sie stand — inzwischen fällig gewordene Stufen folgen nacheinander, sie beginnt nicht neu bei Stufe 1.

ACK-Verlauf

Jeder ACK bleibt erhalten — wer quittiert hat, warum, mit welcher Einstufung und Frist, wie schlimm der Check in dem Moment war und wie er endete:

Ende Bedeutung
Check wieder OK der Check hat sich erholt (Auto-Clear)
Status verschlimmert automatischer Bruch bei Verschlimmerung
Frist abgelaufen die Befristung ist erreicht
aufgehoben jemand hat ihn aufgehoben (Name steht dabei)
neu quittiert er wurde durch einen neuen ACK ersetzt
Check zurückgesetzt der Check wurde zurückgesetzt (z. B. wieder aktiviert)

Wo du ihn siehst:

  • Im Check (Check-Panel und Vollbild), Abschnitt ACKs & Downtimes — schon zugeklappt steht dort „3× quittiert, zuletzt vor 2 Tagen" und der letzte Grund.
  • Auf der Seite Downtimes & ACKs, Reiter ACKs, darunter die Reiter Offen und Abgeschlossen mit Anzahl und eigenem Blättern. Ein Sammel-ACK über viele Checks ist eine Zeile (aufklappbar). Filter wie bei Downtimes — dazu Einstufung (als Fehler / als kein Fehler) und im Reiter „Abgeschlossen" das Ende (z. B. nur „Frist abgelaufen").
  • Im Verlaufs-Graphen des Checks als Band am oberen Rand und in der Ereignisliste.

Wieder aufnehmen an einem beendeten ACK öffnet den ACK-Dialog mit demselben Grund, derselben Einstufung und derselben Frist-Dauer ab jetzt. Das geht nur für Checks, die gerade nicht OK sind — ein ACK auf einen OK-Check würde beim nächsten Ergebnis sofort wieder aufgehoben.

ACKs aus der Zeit vor dem Verlauf wurden aus dem Audit-Log rekonstruiert (so gekennzeichnet); ihr Ende ist abgeleitet.

Audit

Im Audit-Log: acknowledge, bulk_acknowledge und unacknowledge, jeweils mit Kommentar, Einstufung und Frist.

Permission

Permission alerts.acknowledge (ab Operator). Ohne sie sind die ACK-Knöpfe in Fehlerübersicht und Host-Detail gesperrt. Den Verlauf lesen darf, wer services.view hat — wie alle anderen Check-Daten.

Anschluss