DPF Alert Rule Examples
This page documents the reference PrometheusRule manifests covering DPF component health, DPUCluster control plane performance, and DPF operator self-health. The manifests live in deploy/helmfiles/prometheus-rules/; tune the thresholds for your environment before enabling paging.
These rules assume kube-prometheus-stack (or any Prometheus Operator deployment) is installed and configured to discover PrometheusRule resources in the dpf-operator-system namespace. The manifests already carry the release: kube-prometheus-stack label that the default kube-prometheus-stack ruleSelector matches; adjust or drop it in metadata.labels if your Prometheus instance selects rules differently.
[!NOTE] See Recording Rule Examples for the companion recording-rule manifests. The DPFDPUServiceReplicasNotHealthy, DPFDPUClusterAPIServerLatencyHigh, and DPFDPUClusterEtcdLatencyHigh alerts evaluate recorded series, so they never fire unless the matching recording rules are deployed as well.
Every rule carries labels.service: doca-platform-framework so DPF alerts and series can be filtered downstream (e.g. ALERTS{service="doca-platform-framework"} in Prometheus, an Alertmanager route matcher as shown in the Alertmanager example, or a Grafana alertName: "DPF" prefix filter).
Suggested threshold defaults, tune per environment:
|
Alert |
Threshold |
Default |
|---|---|---|
|
|
5xx req/s |
|
|
|
apiserver p99 (s) |
|
|
|
etcd p99 (s) |
|
|
|
workqueue depth |
|
|
|
reconcile error ratio |
|
|
|
reconcile p99 (s) |
|
|
|
restarts in 15m |
|
|
|
remaining fraction of token lifetime |
|
DPF Component Health
status.conditions.Ready alerts across the core DPF custom resources, exposed by kube-state-metrics through the customresourcestate configuration shipped in the operator chart. Each alert fires when the matching object stops reporting Ready=True for the configured duration, covering both Ready=False and Ready=Unknown. DPFDPUNotOperational fires when a provisioned DPU's runtime degrades, and DPFDPUNodeMaintenanceStuck catches maintenance windows that fail to converge in 30 minutes. Every expression aggregates with max by(namespace, name) so the alert identity only depends on the object; without that, a kube-state-metrics restart would change the scrape labels, reset the for: timers, and re-page for ongoing issues.
Manifest: dpf-component-health.yaml
|
Alert |
Severity |
For |
Fires when |
|---|---|---|---|
|
|
critical |
10m |
The singleton DPFOperatorConfig does not report |
|
|
warning |
15m |
A DPU does not report |
|
|
critical |
5m |
A provisioned DPU does not report |
|
|
critical |
10m |
A DPUCluster does not report |
|
|
warning |
10m |
A DPUDeployment does not report |
|
|
warning |
10m |
A DPUSet does not report |
|
|
warning |
10m |
A DPUService does not report |
|
|
warning |
30m |
A DPUNodeMaintenance has not reached |
|
|
warning |
10m |
A DPUNode does not report |
|
|
warning |
10m |
A DPUServiceChain does not report |
|
|
warning |
10m |
A DPUServiceInterface does not report |
|
|
warning |
10m |
A DPUServiceIPAM does not report |
|
|
warning |
10m |
A DPUVPC does not report |
|
|
warning |
10m |
A DPUVirtualNetwork does not report |
|
|
warning |
10m |
A DPUVolume does not report |
|
|
warning |
10m |
A DPUVolumeAttachment does not report |
DPF Replica Health
DPFDPUServiceReplicasNotHealthy watches the DaemonSet/Deployment desired-vs-ready replica diff per DPUService by reading the dpf:dpuservice:not_ready_replicas recorded series. It strictly requires the dpf-aggregates manifest from Recording Rule Examples: without it the series does not exist and the alert silently never fires.
Manifest: dpf-replica-health.yaml
|
Alert |
Severity |
For |
Fires when |
|---|---|---|---|
|
|
warning |
10m |
A DPUService workload (DaemonSet or Deployment) has fewer ready replicas than desired |
DPUCluster Control Plane
Health and performance of the Kubernetes control planes running on top of Kamaji (one per DPUCluster). DPU cluster control planes are scraped under the same job names as the management cluster (apiserver, kube-controller-manager), so the DPUCluster alerts filter with cluster!="management" to avoid firing for the management control plane under a misleading name. The two latency alerts read recorded series and require the dpucluster-control-plane-aggregates manifest from Recording Rule Examples.
Manifest: dpucluster-control-plane.yaml
|
Alert |
Severity |
For |
Fires when |
|---|---|---|---|
|
|
warning |
5m |
A DPUCluster apiserver returns more than 1 req/s of 5xx responses |
|
|
warning |
10m |
A DPUCluster apiserver p99 request latency exceeds 1s per verb |
|
|
warning |
10m |
A DPUCluster etcd p99 request latency exceeds 0.1s per operation |
|
|
warning |
10m |
A DPUCluster kube-controller-manager workqueue holds more than 100 items |
DPF Operator Self-Health
Alerts about the DPF operator pods and the metrics pipeline itself. When these fire, expect every other DPF alert to go stale: DPFOperatorMetricsAbsent catches the scrape job disappearing entirely (which up == 0 alone cannot), and DPFKubeStateMetricsDown catches the kube-state-metrics outage that silently mutes all component-health and lifecycle alerts. The pod alerts select by the stable dpf-operator-controller-manager-.* pod-name prefix, so they work with a default kube-state-metrics install (pod labels are only exported when explicitly allowlisted). The two controller-runtime alerts watch the reconcile behavior of every DPF controller scraped under job="doca-platform-framework" on the management cluster.
Manifest: dpf-operator-self.yaml
|
Alert |
Severity |
For |
Fires when |
|---|---|---|---|
|
|
critical |
5m |
The DPF operator pod is not Ready |
|
|
warning |
0m |
The DPF operator pod restarts more than 3 times in 15 minutes |
|
|
critical |
5m |
Prometheus cannot scrape a DPF controller-manager pod ( |
|
|
critical |
10m |
No scrape targets exist at all for |
|
|
critical |
5m |
kube-state-metrics is unreachable or has no scrape targets |
|
|
warning |
15m |
More than 10% of a DPF controller's reconciles fail |
|
|
warning |
10m |
A DPF controller's p99 reconcile time exceeds 30s |
DPF Lifecycle Stalls
Long-window alerts that catch DPUs, BFBs, and DPUClusters stuck in lifecycle phases, plus DPUService credentials approaching expiry. DPFDPUErrorPhase covers the terminal Error phase explicitly: a DPU stays there until fixed or deleted, so it always needs operator attention.
Manifest: dpf-lifecycle.yaml
|
Alert |
Severity |
For |
Fires when |
|---|---|---|---|
|
|
warning |
1h |
A DPU sits in a non-terminal phase (not |
|
|
warning |
15m |
A DPU is in the terminal |
|
|
warning |
1h |
A DPU sits in the |
|
|
warning |
30m |
A BFB sits in the |
|
|
warning |
1h |
A DPUCluster sits in the |
|
|
warning |
15m |
A DPUServiceCredentialRequest token has less than 10% of its lifetime left, meaning the automatic rotation (due at 20% remaining) is overdue |
Deploying
The manifests live in deploy/helmfiles/prometheus-rules/. The deploy/helmfiles/monitoring.yaml helmfile applies them automatically via a postsync hook on the kube-prometheus-stack release. To deploy them into an existing Prometheus Operator setup manually:
kubectl apply --server-side -f deploy/helmfiles/prometheus-rules/
Confirm Prometheus picked the rules up:
kubectl -n dpf-operator-system port-forward svc/kube-prometheus-stack-prometheus 9090:9090
# then visit http://localhost:9090/alerts and http://localhost:9090/rules
Filter active alerts by the common label every rule carries:
ALERTS{service="doca-platform-framework"}
Last updated: