17c1dece48
The cilium chart renders templates/cilium-agent/service.yaml only when prometheus.enabled AND (prometheus.serviceMonitor.enabled OR prometheus.metricsService). infrastructure/cilium/helmrelease.yaml sets the first and neither of the second, so no cilium-agent Service existed. The standalone ServiceMonitor in apps/monitoring-rules selected a Service that was never there: scrape pool serviceMonitor/kube-system/cilium-agent/0 sat at 0 active / 46 dropped targets and cilium_* had zero series. Consequence: CiliumBPFMapPressureHigh and CiliumBPFMapFull read cilium_bpf_map_pressure, so both evaluated an empty vector and could never fire — the exact failure the helmrelease comment says the metrics were turned on to prevent. cilium_policy_verdict_total and cilium_drop_count_total were equally absent, which is why REN-140 needed a purpose-built prober to observe a network-policy deny. Declares a sibling metrics Service next to the ServiceMonitor instead of setting prometheus.metricsService in the HelmRelease. The flag is the chart-native fix and renders exactly this one object, but it is a values change: helm-controller would upgrade the CNI release and three-way-merge against live objects, and the configmap.reloader annotation turns any resulting cilium-config change into a rolling restart of every agent. A Service applied by the apps Kustomization cannot do that. Naming follows authentik-outpost-servicemonitors.yaml: distinct name plus app.kubernetes.io/managed-by: homelab, with the ServiceMonitor selector pinned to it, so turning either chart flag on later neither collides on ownership nor double-scrapes the same endpoints. The helmrelease.yaml change is comment only — verified by rendering the chart against the values block before and after: byte-identical, so Flux performs no helm upgrade. Co-Authored-By: Paperclip <noreply@paperclip.ing> Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>