claude-botandClaude Opus 5
6a65a5982a
A dashboard first needed something to draw. Nothing scraped CrowdSec:
`up{namespace="crowdsec"}` returned zero series and Prometheus held no cs_*
metric at all, so the detection half of the ingress path was invisible —
including whether the agents were reading logs and whether any bouncer was
pulling decisions.
Both chart services already expose a `metrics` port on 6060 and the
crowdsec-ns CiliumNetworkPolicy already admits the monitoring namespace
without a port restriction. Only the ServiceMonitor was missing. One object
covers both services via matchExpressions, since they differ only in `app`.
Every panel query was written against label sets read off the live endpoints
rather than from the documentation:
cs_active_decisions{action,origin,reason}
cs_lapi_bouncer_requests_total{bouncer,method,route}
cs_bucket_overflowed_total{name}
cs_filesource_hits_total{acquis_type,datasource_type,source}
cs_node_wl_hits_ok_total{...,reason,...}
cs_parser_hits_ok_total / _ko_total
The bouncer panel is the one worth having: the LAPI counts requests per
bouncer, so a bouncer that stops pulling shows up as a line going to zero
rather than as nothing at all. It also makes the `<name>@<ip>` behaviour
visible — the LAPI registers a new entry per observed client address, and what
it observes is the netbird-ingress pod IP, so one logical bouncer appears
several times and gains new names as those pods roll.
The last panel is a text panel naming what the dashboard cannot show. The
bouncers' own metrics — fw_bouncer_active_decisions, dropped packets, their
view of the LAPI — sit on 127.0.0.1:60601 on public hosts with no metrics path
of any kind. So "Bouncer-Abholrate" proves a bouncer is asking, not that it
applied the answer. Better to say that on the dashboard than to let someone
read enforcement into a panel that does not measure it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
37 lines
1.3 KiB
YAML
37 lines
1.3 KiB
YAML
# Scrapes CrowdSec. Until this landed, nothing did: `up{namespace="crowdsec"}`
|
|
# returned zero series and Prometheus held no cs_* metric at all, so the
|
|
# detection side of the ingress path was invisible — including whether the
|
|
# agents were reading logs and whether any bouncer was pulling decisions.
|
|
#
|
|
# One monitor for both services. They carry the same shape (a `metrics` port on
|
|
# 6060) and differ only in `app`, so a matchExpressions selector keeps this to
|
|
# a single object rather than two near-identical ones:
|
|
#
|
|
# crowdsec-service the LAPI — decisions, bouncer + machine requests
|
|
# crowdsec-agent-service the agents — acquisition, parsers, scenarios
|
|
#
|
|
# The crowdsec-ns CiliumNetworkPolicy already admits the monitoring namespace
|
|
# without a port restriction, so no policy change is needed.
|
|
#
|
|
# `release: kube-prometheus-stack` is what the chart's Prometheus selects on.
|
|
apiVersion: monitoring.coreos.com/v1
|
|
kind: ServiceMonitor
|
|
metadata:
|
|
name: crowdsec
|
|
namespace: crowdsec
|
|
labels:
|
|
app.kubernetes.io/name: crowdsec
|
|
release: kube-prometheus-stack
|
|
spec:
|
|
selector:
|
|
matchExpressions:
|
|
- key: app
|
|
operator: In
|
|
values:
|
|
- crowdsec-service
|
|
- crowdsec-agent-service
|
|
endpoints:
|
|
- port: metrics
|
|
path: /metrics
|
|
interval: 30s
|