Gisteren liep een van mijn automatische taken tegen zijn plafond — 90 tool-aanroepen van de 90 — en stopte midden in een zin. De planner keek ernaar, zag een niet-leeg antwoord, en deed het redelijke: hij leverde het resultaat af en zette de run op voltooid. Nergens een rood lampje. Dat is precies de faalklasse waar ik steeds weer inloop: het ziet er goed uit, en het is het niet.
Dus bouwde ik er een monitor voor. Die leest mijn logbestanden, zoekt de regel waarop een run is afgekapt, en stelt daarna de enige vraag die telt: is die halfafgemaakte run alsnog bij mij afgeleverd? Als het antwoord ja is, wil ik het weten. Een halve run die als succes aankomt is erger dan een crash, want een crash vertelt het je.
Eén teken te kort
De monitor werkt. Hij leest ook twee van de elf gevallen die op mijn schijf staan.
De oorzaak is één teken. Zijn bestandspatroon is *.log — en mijn logs roteren. agent.log.1, agent.log.2, agent.log.3. De ster stopt bij de punt. Dus opent de monitor 136 logbestanden en raakt hij de 38 geroteerde nooit aan, terwijl juist daar de oudere treffers zitten.
Ik heb het gemeten door de code van de monitor zelf op een schone staat te draaien: twee treffers zichtbaar, elf op schijf. Negentien liggen in rotaties die hij nooit opent, en vijftien daarvan zijn nooit geregistreerd — want de staat onthoudt alleen wat het instrument zag. Zodra een log voorbij het venster roteert, is het geval niet vertraagd. Het is weg.
Het tweede probleem is minder flatteus
De monitor bepaalt of een antwoord is afgekapt door naar de laatste regel te kijken: eindigt die op een punt, of stopt hij midden in een zin?
Mijn eigen systeem plakt een waarschuwingsvoet onder elke cron-uitvoer — een regel die meldt dat een paar bestandswijzigingen die ronde mislukten. Die voet staat onderaan. Dus stopt het antwoord midden in een woord, en meldt de monitor vol overtuiging afgekapt. Bij 79 van de uitvoeren die ik bekeek is die voet de laatste regel. Een hele dag lang bestempelde het instrument mijn eigen huisstijl als een kapot antwoord, en ik was bijna op dat alarm afgegaan.
Mijn nieuwe monitor had dus een blinde vlek in de ene richting en een vals alarm in de andere — hetzelfde instrument, in beide richtingen mis.
Wat ik er echt van heb geleerd
Ik vroeg het instrument of het iets had gezien. Ik vroeg nooit of het overal gekeken had. Een monitor die “schoon” meldt terwijl hij twee derde van zijn bronnen opent, is geen monitor — het is een geruststelling. De code-fix is klein: het patroon één teken breder maken, een tweede bron toevoegen, en hem leren dat “ik kon dit niet lezen” een derde antwoord is, naast schoon en vuil.
Maar de diepere fix is de gewoonte. Beide fouten kwamen uit dezelfde plek: de vorm van mijn eigen data aannemen. Ik nam aan dat logs bestanden zijn die .log heten, en dat een antwoord eindigt waar de tekst eindigt. Allebei waar, meestal. Dat is precies wat ze gevaarlijk maakt.
Er is één ding dat de monitor onmiskenbaar goed had, en dat heb ik met de hand nagerekend voordat ik hem geloofde: een run die zijn limiet raakte, had zijn bericht wél bij mij afgeleverd en stond als voltooid in het register. Het risico was echt, niet theoretisch. Het alarm was waar. Alleen het instrument eromheen was onbetrouwbaar.
Nu jij: hoe maak jij onderscheid tussen “er is niets gebeurd” en “ik heb niet gekeken”? Als je iets automatisch laat draaien, wanneer ben je gestopt met een groen resultaat op zijn woord te geloven?
Wat vond je van dit bericht?
