Skip to content

fix(kube-ovn): restore the datapath alerts — the metrics were never gone - #260

Merged
gurinderu merged 1 commit into
mainfrom
fix/restore-datapath-alerts
Sep 11, 2026
Merged

gurinderu merged 1 commit into
mainfrom
fix/restore-datapath-alerts

Conversation

@gurinderu

Copy link
Copy Markdown
Contributor

The metrics were never gone

#251 deleted the kube-ovn-datapath group on the grounds that the dp_* family had been dropped in 1.16 with no replacement. That was wrong.

They were absent from every exporter endpoint because the pinger could not collect them: ovs-dpctl dump-dps failed with the same stale-pidfile error that made it report OVS and ovn-controller down. #258 gave the pinger hostPID, and the family came back immediately — 78 series, under the kube_ovn_ prefix, with exactly the names the deleted rules used:

metric value on stage
kube_ovn_dp_flows_lookup_hit 4,884,614,762
kube_ovn_dp_flows_lookup_missed 128,981,846
kube_ovn_dp_flows_lookup_lost 100
kube_ovn_dp_masks_hit_ratio 6.24

The three rules are restored with prefixed names. The node label is hostname, not instance, which the annotations now use.

How this was got wrong

Worth recording, because the failure was in reasoning rather than in measurement.

An adversarial review raised this deletion twice, and it was rejected twice with growing confidence — on the strength of reading all three /metrics endpoints in full and finding no dp_* anywhere. The measurement was sound. The inference from it was not.

"The exporter does not expose this" and "the exporter cannot currently collect this" produce identical evidence at the endpoint, and only the second is reversible. The reviewer was right about the conclusion while being wrong about the stated reason, which made it easy to dismiss and easy to feel justified in dismissing.

Verification

All three expressions evaluate against the live stage cluster and return empty — the thresholds are not currently tripped, with mask hit ratio at 6.24 against a threshold of < 1. kubectl kustomize flux/apps/kube-system/kube-ovn/observability builds.

#251 deleted the kube-ovn-datapath group on the grounds that the dp_*
family had been dropped in 1.16 with no replacement. That was wrong, and
the reason it looked right is now understood.

The metrics were absent from every exporter endpoint because the pinger
could not collect them: `ovs-dpctl dump-dps` failed with the same stale-
pidfile error that made it report ovs and ovn-controller down. #258 gave
the pinger hostPID, and the family came back immediately — 78 series,
including exactly the names the deleted rules used, under the kube_ovn_
prefix:

  kube_ovn_dp_flows_lookup_hit     4884614762
  kube_ovn_dp_flows_lookup_missed   128981846
  kube_ovn_dp_flows_lookup_lost           100
  kube_ovn_dp_masks_hit_ratio            6.24

So the three rules are restored with the prefixed names. The label for the
node is `hostname`, not `instance`, which the annotations now use.

Worth recording how this was got wrong. An adversarial review raised the
deletion twice, and it was rejected twice with growing confidence, on the
strength of reading all three /metrics endpoints in full and finding no
dp_* anywhere. The measurement was sound; the inference from it was not.
"The exporter does not expose this" and "the exporter cannot currently
collect this" produce identical evidence at the endpoint, and only the
second one is reversible. The reviewer was right about the conclusion
while being wrong about the reason, which made it easy to dismiss.

Verified: all three expressions evaluate against the live stage cluster
and return empty, i.e. the thresholds are not currently tripped, with
mask hit ratio at 6.24 against a threshold of < 1.
@gurinderu
gurinderu merged commit 16532e1 into main Sep 11, 2026
1 check passed
@gurinderu
gurinderu deleted the fix/restore-datapath-alerts branch September 11, 2026 14:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant