Zum Inhalt

Downtime & Timeline

Überblick

Ein Downtime in der Polycrate API ist ein abgeschlossenes oder laufendes Ereignis, bei dem ein oder mehrere Objekte (z. B. K8sApps, Endpoints, Hosts, K8sCluster) nicht oder nur eingeschränkt verfügbar waren. Downtimes werden automatisch aus dem Endpoint-/Heartbeat-Monitoring erzeugt oder manuell angelegt (z. B. für geplante Wartungen).

Seit Polycrate API 0.15.0 werden Downtimes nicht mehr nur tabellarisch, sondern mit einem Timeline-Graph visualisiert, der über die gesamte Downtime hinweg zeigt, wie viele Objekte zu welchem Zeitpunkt betroffen waren.

Downtime-Objekt

Feld Beschreibung
Name Sprechender Titel (z. B. "Netzwerkausfall DC Frankfurt")
Start / End Zeitraum der Downtime (End=null → laufend)
Timeline Strukturiertes Log der Ereignisse innerhalb der Downtime
Affected Objects Anzahl und konkrete Liste betroffener Objekte
Severity info, warning, critical
Workspace / Organization Zuordnung

Timeline-Events

Die Timeline ist ein JSON-Feld, das chronologisch Ereignisse festhält:

  • object_affected (Objekt fällt aus)
  • object_recovered (Objekt erholt sich)
  • note (frei beschreibender Event-Eintrag)
  • escalation, root_cause_identified usw.

Jedes Event hat Timestamp, Typ, Payload und optional eine Verknüpfung zum betroffenen ManagedObject.

Timeline-Graph

Im Detail einer Downtime gibt es einen horizontalen Zeitreihen-Graph:

  • X-Achse: Zeit (Start bis Ende bzw. jetzt)
  • Y-Achse: Anzahl gleichzeitig betroffener Objekte
  • Annotationen: Visuelle Marker auf der Zeitachse für Timeline-Events
  • Hover: Event-Details mit Objektnamen

Der Graph ersetzt die frühere einfache HTML-Liste und macht auf einen Blick erkennbar:

  • Wann war der Höhepunkt der Downtime?
  • Gab es Recovery-Phasen (Dips)?
  • Wie entwickelt sich ein laufender Incident?

Technisch basiert der Graph auf dem Metric Functions Framework – die Downtime liefert eine synthetische Step-Function, die wie jede andere Metric gerendert wird.

Woher kommen Downtimes?

Quelle Verhalten
Endpoint Check Failure Mehrere konsekutive Failed-Checks öffnen eine Downtime, Recovery schließt sie
Heartbeat Missing Ausbleibender Heartbeat eines Agents/Hosts
Manuelle Anlage Administrator legt eine Downtime für geplante Wartung an (Severity info)
Aggregation Downtimes gleicher Ursache/Zeit können zu einer Sammel-Downtime gebündelt werden

Wartung vs. Downtime

Polycrate unterscheidet drei Arten von Terminen/Ereignissen, die in der Timeline gemeinsam sichtbar sind:

  • Wartung — ein geplantes Event mit Start/Ende (z. B. "Upgrade am Sonntag 02:00–04:00"). Informiert Benutzer proaktiv, unterdrückt ggf. Alerts während der angekündigten Zeit.
  • Wartungsfenster — eine wiederkehrende Policy ("jeden Sonntag 02:00–04:00"). Erzeugt selbst keine Events, definiert aber die Regeln, innerhalb derer eine Wartung geplant werden soll.
  • Downtimes — real eingetretene Verfügbarkeitsprobleme (Vergangenheit/jetzt), automatisch erzeugt oder manuell nachgetragen.

Eine Wartung kann, wenn während ihrer Dauer tatsächlich ein Ausfall auftritt, als Downtime innerhalb des Wartungs-Slots nachgezogen werden.

Wo sehe ich Downtimes?

  • Monitoring → Downtimes – globale Übersicht mit Filter nach Severity, Status, Scope
  • Objekt-Detail (z. B. K8sApp) → Tab Downtimes – nur Downtimes, die dieses Objekt betreffen
  • Dashboard – Aktuelle/neueste Downtimes als Widget

SLO & Availability

Downtimes fließen in die Availability-/SLO-Berechnung ein:

  • Pro Objekt wird available_time / total_time berechnet (abzüglich geplanter Wartungen)
  • Aggregation über Zeiträume (letzte 30/90 Tage) für Reports
  • Nutzbar in Audit & Compliance-Kontexten (Verfügbarkeitsberichte)

Siehe auch