An open source Kubernetes operator for Red Hat OpenShift automatically captures diagnostic data (must-gather logs) the moment a production incident begins, rather than relying on someone noticing and manually collecting logs afterward. It watches for Kubernetes Warning events on a hub cluster in multi-cluster/Red Hat Advanced Cluster Management setups, matches event messages against regex-based diagnostic rules, identifies the affected spoke cluster, and spins up a non-blocking job to run must-gather and store logs temporarily on RWX storage before automatic cleanup. It complements tools like Prometheus and logging operators by filling the gap right before a failure, and the project is available on GitHub for testing with OpenShift Local.
Table of contents
Event-based FIR collectorEvent-driven workflowReal-world scenarios: Why this mattersWhy this tool is differentEvent-driven pattern matchingTry it yourselfJoin the conversation, and what's nextQuestions this post answers
How does the event-driven diagnostic operator decide which must-gather image to run for a given failure?
It runs the Kubernetes event message through a Go template engine that maps predefined regex patterns to specialized must-gather images. For example, an event message matching the pattern for etcd database corruption triggers the must-gather image configured for ETCD Corruption, while a network CNI failure pattern triggers a different diagnostic job, all defined in the operator's internal/config/template.go rule set. Engineers building multi-cluster incident tooling can compare event-driven diagnostic patterns like this on daily.dev.
How does a Kubernetes operator identify which spoke cluster caused a warning event in a multi-cluster hub setup?
The operator uses a multi-strategy priority parser that first checks the event's InvolvedObject.Kind, then looks for a spoke- namespace prefix, and falls back to regex extraction if neither works. Once identified, it copies that spoke cluster's kubeconfig secret into its own namespace and launches an independent job to run diagnostics against it. Teams debugging multi-cluster failures can track approaches like this on daily.dev while designing their own tooling.