fix(snmp): stop the pfsense module walking pfTablesAddrTable

[Gerrrt]

Symptom

morpheus reported down with context deadline exceeded at exactly 45.00s — Prometheus's scrape_timeout — while its SNMP community worked fine when tested directly from the monitoring host. The credential was never the problem; the walk simply could not finish.

Cause

The module walked 1.3.6.1.4.1.12325.1, commented # BEGEMOT-PF-MIB::begemotPf. The comment states the intent correctly — the OID is one level too high. begemotPf is 12325.1.**200**, so 12325.1 also swept in begemotSnmpd (12325.1.1).

The real cost is inside pfTables (.1.9), which holds two tables of wildly different size. Measured against morpheus:

OID	Table	Rows	Time
.1.9.1	pfTablesTblNumber	1	0.1s
.1.9.2	pfTablesTblTable	323	0.4s
.1.9.3	pfTablesAddrTable	50,917+	>20s, unfinished

pfTablesAddrTable is one row per address in every pf table — every entry of every blocklist. A full walk of 12325.1 returned 116,360 rows in 90s without completing, against ~1,800 rows for all of begemotPf otherwise. It grows with every blocklist added.

This could not be fixed by raising scrape_timeout: already 45s against a 60s scrape_interval, and the walk needed well over 90s.

Fix

Enumerate begemotPf's subtrees, descending into .1.9 to keep the table summaries while excluding the address table.

Nothing queries the dropped metrics — alerts use pfStatusRunning, pfStateTableCount, pfLimitsStates, pfCounterMemDrop; dashboards add pfSrcNodes* and pfStatusRuntime. All 21 pfTablesTbl* metrics are retained.

Note on the metric-count guard

make snmp-generate warns here:

metrics: 1805 -> 1792
warning: regeneration LOST 13 metric(s)

That is intended. The 13 are exactly the pfTablesAddr* set — verified by diffing the metric-name sets, not by trusting the count:

pfTablesAddrBytesInBlock   pfTablesAddrBytesInPass    pfTablesAddrBytesOutBlock
pfTablesAddrBytesOutPass   pfTablesAddrIndex          pfTablesAddrNet
pfTablesAddrNetType        pfTablesAddrPktsInBlock    pfTablesAddrPktsInPass
pfTablesAddrPktsOutBlock   pfTablesAddrPktsOutPass    pfTablesAddrPrefix
pfTablesAddrTZero

Result

Deployed and verified on the monitoring host:

Device	Before	After
morpheus	45.00s → timeout, up=0	0.19s, up=1

Metrics arriving: pfStatusRunning=1, pfStateTableCount=932, pfLimitsStates=3248000.

Deploy note

snmp.yaml is a bind-mounted file and snmp_exporter reads it at startup. docker compose up -d does not recreate a container when only a mounted file's contents change, so make up left the old config running in memory. docker compose restart snmp-exporter was required. Worth addressing separately — make up currently cannot apply a rendered-config change to this service.

Also explains SnmpScrapeSlow (network.rules.yaml:28) at its 30s threshold — the slowness was alerted on for a long time but never traced.

🤖 Generated with Claude Code