Kubernetes Reliability Monitoring with SQL
Kubernetes creates many short-lived objects, so grouping raw observations by pod often produces a noisy report. Start at the workload boundary: cluster, namespace, Deployment or Job owner, application release, controlled transition, readiness outcome, and the customer-facing work that workload performs.
Separate transitions from gauges
Emit a container_restarted event when the observed restart counter increases. Keep the cumulative counter as context, but do not sum it across samples. Record readiness as a separate boolean observation. A planned rollout can replace healthy pods, while a crash loop produces repeated restart transitions and often sustained readiness loss.
Use bounded cluster, namespace, and workload names. Do not copy Kubernetes Secrets, environment variable values, complete manifests, container arguments, raw log messages, or customer payloads into the event.
Rank unstable workloads
The Kubernetes restart SQL recipe groups observations by workload, counts restart transitions, preserves the maximum observed counter, and calculates the not-ready rate. Its fixture demonstrates the difference between the transition count and cumulative restart state.
Investigate the result in this order:
- Confirm that the restart is repeated and not only a rollout replacement.
- Check whether readiness loss occurred during the same window.
- Compare release, node pool, cluster, and controlled reason categories.
- Join the timing with API failures, delayed jobs, or other product outcomes.
The infrastructure recipe collection adds resource saturation, heartbeats, and incident timing. Those signals help distinguish application failure from capacity pressure or a broader cluster problem.
Start with the Kubernetes integration guide when building the collector-to-event boundary and workload-owner normalization.
Alert on impact, not churn
A workload dashboard should keep restart transitions, readiness, rollout markers, and application error rate together. Page only after a reviewed sustained condition; one rescheduled pod or expected deployment replacement is usually not actionable.
The Kubernetes reliability use case provides a coding-agent prompt for the event contract. Validate synthetic restart, rollout, recovery, and delayed-event cases before using the query for production response.