gke-alert-configuration

Use the google_monitoring_alert_policy resource with condition_prometheus_query_language blocks containing PromQL queries. Declare variables for project_id, cluster_name, and namespace, and use grouping aggregations like by (cluster, namespace, pod) so one policy dynamically covers all resources.

A MWMBR alert evaluates error budget consumption across two simultaneous lookback windows, such as 5 minutes and 1 hour, and fires only when both exceed the burn rate threshold. For a 99% SLO, a fast-burn alert uses a 14.4x factor, eliminating false alarms from short error bursts.

Yes, kube-state-metrics metrics incur billable sample ingestion costs in Managed Service for Prometheus. Reduce costs by deploying a filtered PodMonitoring resource with metricRelabeling keep rules that allowlist only the specific kube_* metrics your alerts require.

When traffic drops to zero, Prometheus stops emitting the time series, so rate(...) == 0 evaluates to an empty vector and never fires. Use sum(rate(...[5m])) default 0 == 0 or absent(...) == 1 to reliably detect total traffic loss.

No, it is strictly scoped to GKE workloads using PromQL and Managed Service for Prometheus. For standalone Compute Engine VMs or Cloud Run services, use standard google_monitoring_alert_policy with condition_threshold and metrics like compute.googleapis.com/instance/cpu/utilization.

Queries with aggregated lookback windows like increase(...[15m]) already smooth transient spikes, so adding duration = "300s" only increases mean time to detect. Reserve longer durations for instantaneous gauge conditions such as kube_node_status_condition == 0.