/events

Der /events-Skill ruft aktuelle Kubernetes-Events ab und verdichtet sie zu einer kurzen, nach Schweregrad geordneten Liste — Warning-Events zuerst, dann alles Bemerkenswerte in Normal. Er ist schreibgeschützt und mutiert niemals den Cluster-Status.

Die Ausgabe ist bewusst begrenzt, sodass die erste Antwort günstig zu lesen und günstig über das Modell neu zu emittieren ist. Die vollständige Event-Liste wird in einen lokalen JSON-Cache geschrieben, aus dem der Agent bei Folgefragen liest, ohne die API erneut aufzurufen.

/events                            # snapshot (uses cache if fresh)
/events --refresh                  # force a fresh fetch
/events --ttl 5m                   # only re-fetch if older than 5m

Dieser Skill nimmt keine Positionsargumente. Folgefragen („only payments”, „events on pod/checkout-7c9”, „show me the suppressed Normal events”) werden aus dem Cache beantwortet — siehe Follow-ups unten.

---

Was er prüft

Checks

• Warning-Events über alle Namespaces, gruppiert nach (reason, involvedObject.kind, namespace)
• Normal-Events, die in der Regel bedeutsam sind — Killing, Preempting, NodeNotReady, Rebooted, FailedScheduling etc. — wobei die geschwätzigen (Pulled, Created, Started, Scheduled, SuccessfulCreate) in einer einzelnen Tail-Zeile zusammengefasst werden
• Für jede Gruppe: Anzahl, erster/letzter Zeitstempel, die neueste Nachricht und die betroffenen Objekte (abgeschnitten bei vielen)

Quellen: nur Kubernetes API — kubectl get events --all-namespaces (oder das Äquivalent gegen events.k8s.io/v1), server-seitig nach lastTimestamp sortiert.

---

Wie es funktioniert

Der Skill ruft Events für den Cluster in einem einzelnen Aufruf ab und schreibt die vollständige Liste als events.json in ein kontextspezifisches Cache-Verzeichnis. Aggregation und Schweregrad-Einstufung erfolgen Client-seitig auf diesem JSON, sodass wiederholte Ausführungen innerhalb des TTL-Fensters die API vollständig überspringen.

Der Zusammenfassungsblock sieht so aus:

Events: prod-us-east · last 1h · 2 warning groups, 1 notable

WARN  payments/Pod         BackOff             14×  2m ago   "Back-off restarting failed container server in pod checkout-7c9"
WARN  ingress/Pod          FailedScheduling    1×   38m ago  "0/12 nodes are available: 3 node(s) had untolerated taint…"
NOTE  kube-system/Node     NodeNotReady        1×   52m ago  "Node ip-10-0-3-14 status is now: NodeNotReady"

…and 412 Normal events (Pulled, Created, Started, Scheduled) suppressed.

Snapshot cached (TTL 5m). Ask to drill in — e.g. "only payments", "events on pod/checkout-7c9", "show suppressed".

Wenn das Fenster sauber ist, gibt der Skill eine einzelne Zeile aus, die bestätigt, dass es nichts zu melden gibt, und beendet sich.

---

Follow-ups

Die Zusammenfassung blendet geschwätzige Normal-Gründe und kürzt Pro-Objekt-Details bewusst ab, damit die erste Antwort klein bleibt. Wenn du nach mehr fragst — oder nach etwas, das aus der gecachten Event-Liste beantwortet werden kann — liest der Agent den Cache mit jq anstatt den Skill neu auszuführen:

❯ /events
[ summary... ]

❯ only payments
[ events filtered to namespace payments, from events.json ]

❯ show the suppressed Normal events
[ full Normal-event list, from events.json ]

❯ events on pod/checkout-7c9
[ filtered by involvedObject, walking owners one level up, from events.json ]

Für Daten, die nicht im Cache sind (Logs, YAML einer spezifischen Ressource, Root-Cause über mehrere Quellen), leitet der Agent an den richtigen Skill weiter — /logs oder /investigate — anstatt /events zu erweitern.

Sag „refresh” / „fetch again” / „re-check” und der Agent ruft den Skill mit --refresh erneut auf.

---

Was dem Agent mitgeteilt wird

Über das Abrufen der Event-Liste hinaus weist der Skill den Agent an, wie er sich bei Folgefragen verhalten soll:

• Lieber aus dem gecachten events.json mit jq antworten als den Skill neu aufzurufen.
• Den geschwätzigen Reason-Satz (Pulled, Created, Started, Scheduled, SuccessfulCreate) als einklappbar behandeln — nur anzeigen, wenn der Benutzer nach dem unterdrückten Satz fragt.
• Wenn der Benutzer nach „events on pod/X” fragt, Owner eine Ebene nach oben verfolgen (Pod → ReplicaSet → Deployment, Pod → Job → CronJob), damit Events, die gegen den Controller ausgelöst wurden, nicht übersehen werden.
• An /logs für die Container-Ausgabe hinter einem BackOff oder CrashLoopBackOff übergeben, und an /investigate, wenn eine einzelne Ressource in den Fokus rückt.

---

Optionen

--refresh

Cache umgehen und frische Daten von der API abrufen.

--ttl <duration>

Nur neu abrufen, wenn der gecachte Snapshot älter als dieser Wert ist (kubectl-Stil: 1m, 5m, 1h). Standard: 5m. Wird ignoriert, wenn —refresh gesetzt ist.

Globale Flags aus Übersicht gelten ebenfalls.