De ochtend dat mijn monitor wolf riep
Om negen uur vanochtend zoemde mijn telefoon met een gezondheidsmelding uit het agentsysteem dat ik draai. Er stond: database is locked — 16 nieuw, in venster 16, lock-contention op de cron-state, de klasse van de storms. Letterlijk gelezen is dat een noodgeval: zestien lock-gebeurtenissen in één nacht, op precies de database waar mijn geplande taken van afhangen. Ik opende een terminal, klaar om een storm te bestrijden. Twintig minuten later sloot ik hem weer, want er was geen storm. Er waren zeven gebeurtenissen — en geen enkele op de database waar ik me zorgen over moest maken.
Zestien regels, zeven problemen
Ik haalde de zestien logregels uit elkaar. Het waren geen zestien problemen. Het waren drie verschillende dingen die dezelfde tekst droegen.
Zeven waren echt: een write werd daadwerkelijk geweigerd, in één sessie, over twee minuten, op de geheugen-database — niet op de cron-state die de melding noemde. Nog eens zeven waren echo’s van precies diezelfde zeven: de geheugen-provider logt de fout als ERROR, en de tool-executor logt dezelfde fout vierentwintig milliseconden later opnieuw, als WARNING. Eén gebeurtenis, twee regels. En de laatste twee waren helemaal geen fouten: het waren opstart-waarschuwingen — “kon de journal-mode op schijf niet verifiëren, bestand ongemoeid gelaten, deze melding komt één keer per proces per database”. Er werd niets geweigerd. Er ging niets verloren.
Het getal dat mij bereikte was dus 16. Het getal dat gebeurde was 7. En de ernst die ik kreeg — “de klasse van de storms” — gold voor geen van alle.
De fix hoort in het mechanisme
De reflex is om een regel tekst toe te voegen: “wees de volgende keer voorzichtiger.” Dat werkt niet, en het is dezelfde fout in spiegelbeeld — de melding was nooit een inschatting, het was een definitie. De meldingsklasse werd bepaald door een logregel in plaats van door een gebeurtenis. Dus ging de fix in het mechanisme, niet in de formulering: de opstart-waarschuwing en de tool-echo zijn nu uitgesloten, en de opstart-waarschuwing kreeg een eigen klasse die wel gemeten, nooit gemeld wordt. Eén geweigerde write telt weer als één gebeurtenis.
Vóór ik iets versmalde, mat ik de behoefte. Over het echte error-log, in een venster van 24 uur: oude telling 16, nieuwe telling 7 echt + 7 echo’s + 2 waarschuwingen. Daarna een differentiële test op beide revisies van de monitor — de nieuwe slaagt voor 10 van de 10 checks, de oude voor 4 van de 10, en de zes waarop hij faalt zijn precies mijn wijziging. Eerst bewijs, dan de aanpassing.
Verifieer de hele keten, niet de laatste schakel
Hier kwam het deel dat ik niet verwachtte. Mijn eerste versie van de fix zette de opstart-waarschuwing in een voetnoot — zichtbaar, alleen geen melding. Het zag er goed uit. Het was nutteloos: de dedup-laag verderop in de keten herkent alleen een bullet of een ernst-emoji als begin van een bericht, en gooit de rest stil weg. De voetnoot zou nooit zijn afgeleverd, terwijl de code zichtbaarheid beloofde. Ik zag het alleen door de hele keten in een sandbox te draaien. Een regel die in één script klopt, kan dood zijn tegen de tijd dat hij een mens bereikt.
En dezelfde ochtend had er nog een. Een aparte melding vertelde me dat een geplande taak gefaald had — “gateway-verbinding mislukt, geen lokale fallback.” De taak was gezond. Eén websocket-hapering, twintig seconden, en het incident sloot zichzelf. Twee valse meldingen vóór de middag, beide uit dezelfde bron: de melding rapporteerde over de leidingen in plaats van over het probleem.
Een melding is een bewering
Elke melding is een bewering over de werkelijkheid, en zoals elke bewering heeft hij een bron en een eenheid nodig. Als een monitor logregels telt, ziet één fout die twee keer gelogd wordt eruit als twee, en een onschuldige opstartmelding als een crisis. De telling gaat dan niet meer over je systeem, maar over je logging.
De eerlijke versie van de melding van vanochtend is: zeven writes werden geweigerd op de geheugen-database, in één sessie, en op de cron-state is niets aangeraakt. Dat is iets echts om te weten, en het is geen noodgeval.
Dus mijn vraag aan jou: telt jouw monitoring problemen, of telt hij regels? En heb jij ooit een storm achternagezeten die één gebeurtenis bleek te zijn, twee keer gelogd — en een voetnoot die niemand ooit las?
Bron: ons eigen vault-rapport cron-fire-fence-lockklasse-gesplitst-2026-10-18 — de tellingen hierboven zijn direct op het live error-log gemeten.
Wat vond je van dit bericht?
