cluster-events

Cluster Events Analysis

Use this flow to analyze cluster-wide events for identifying issues, patterns, and correlations across resources.

Scope: This skill is for analysis and diagnosis only. It helps you understand what is happening across the cluster by examining events. Do NOT attempt to fix issues directly — identify root causes and either use a specific diagnostic skill or report findings to the user.

Diagnostic Flow

0. Normalise the fields first — an event has two layouts

Event exists in two API groups with almost disjoint field names, and the v1 object additionally carries series for a continuing event. Reading only one layout loses half the events silently, so every query below opens with the same four definitions. Copy them as-is:

def pad: if test("Z$") | not
         then error("timestamps must be UTC and end in Z; got \(.) — convert the offset first")
         else capture("^(?<b>[^.Z]+)(\\.(?<f>[0-9]+))?Z$")
              | .b + "." + (((.f // "") + "000000")[0:6]) + "Z" end;   # fixed width, for comparison
def cut: sub("\\.[0-9]+";"");                                          # whole seconds, for display

active: (.series.lastObservedTime // .lastTimestamp // .deprecatedLastTimestamp // .eventTime)
start:  (.firstTimestamp // .deprecatedFirstTimestamp // .eventTime)
count:  (.series.count // .count // .deprecatedCount // 1)
object: (.involvedObject // .regarding // {})

Four things about these are load-bearing, and each was measured rather than assumed:

• series comes first in active and count. On a series event the v1 lastTimestamp and count are frozen at first write; series.* carries the truth.
• start has no series term. A series has no separate start.
• Compare padded, display cut. MicroTime values carry a fraction and "…09:00:00.500000Z" >= "…09:00:00Z" is false, because . sorts below Z.
• The window must be UTC. pad refuses an offset or a missing zone by name rather than mis-sorting it.