Het verhaal schrijft zichzelf: om drie uur 's nachts gaat er een alert af, een agent leest de stack trace, en tegen de tijd dat iemand wakker wordt, staat er een pull request met de fix klaar. Dat hebben we gebouwd. Het meeste werk zat niet in het deel dat de fix schrijft. Het zat in bepalen wanneer hij níet moet starten, want een monitoringsysteem kan honderd alerts per minuut sturen, en elk daarvan is een verzoek om namens jou geld uit te geven.
Een alert wordt een bugtaak
Je voegt een alertbron toe aan een project en krijgt een ingest-URL met een token erin, dat je één keer te zien krijgt. Je monitoringtool post zijn JSON-alert naar die URL. Wij controleren het token en maken van de alert een bugfix-taak: de titel wordt de taaktitel, de melding en de stack trace gaan naar de velden van het bugrapport, en de volledige payload gaat mee, zodat de agent alles heeft wat de monitor wist. Is de bron aan een repository gekoppeld, dan verwijst de taak daarnaar.
Standaard houdt het daar op. De taak komt binnen als concept, net als elk ander bugrapport, zodat iemand ernaar kan kijken. Elk project heeft een tabblad Alerts met de taken die je monitoring aanmaakte en de laatste run van elk, zodat je ze niet in de takenlijst hoeft te zoeken.
Dezelfde alert, één keer
Een falende job stuurt elke paar minuten een alert tot iemand hem repareert. Zonder ontdubbeling is dat elke paar minuten een nieuwe taak. Elke alert krijgt een vingerafdruk: het eigen fingerprint-veld van de payload als die er een meestuurt, anders een hash van de titel, de service of omgeving en de eerste regel van de stack trace. Is er binnen het venster van de bron, standaard 24 uur, al een taak met dezelfde vingerafdruk aangemaakt, dan wordt de alert bij die taak gevoegd en ontstaat er niets nieuws.
Daarnaast accepteert elke bron een begrensd aantal alerts per uur. Boven die grens worden alerts stilletjes genegeerd in plaats van met een fout beantwoord, want een monitor die te horen krijgt dat hij het opnieuw moet proberen, maakt de vloed alleen groter. De grens is er net zo goed voor een uitgelekt token als voor een luidruchtige monitor.
De ernst bepaalt de prioriteit
Monitoringtools zijn het oneens over hoe je zegt hoe erg iets is. We lezen severity, level of priority uit de payload, of het severity-label zoals Alertmanager en Grafana het sturen, en vertalen die woorden naar de vier taakprioriteiten: critical, fatal of sev1 worden kritiek; error, major of p2 worden hoog; warning wordt gemiddeld; info, notice en debug worden laag. Een alert waarvan we de ernst niet herkennen, wordt gemiddeld.
Wanneer hij zelf mag starten
Je kunt een bron op auto-run zetten. Dat staat uit tot je het aanzet, en zelfs dan start een alert alleen een run als aan al deze voorwaarden is voldaan:
- De bron heeft auto-run aan en een uurlimiet boven nul.
- De alert is hoog of kritiek.
- Het project heeft een verify-commando. Als niets een slechte fix kan laten falen, openen we daar zonder toezicht geen pull request voor.
- De uurlimiet is niet bereikt. Die telt de runs die het afgelopen uur zijn gestart op taken die uit alerts in het project kwamen, en staat standaard op drie.
- De runlimieten van de organisatie staan nog een run toe.
- Je uitgavenbeheer staat hem toe zonder te vragen. Een run waarvan iemand de kosten zou moeten goedkeuren, is precies de run die niet moet starten terwijl niemand kijkt, dus "goedkeuring nodig" houdt hem net zo goed tegen als "geweigerd".
Zegt een vangrail nee, dan blijft de taak een concept en vertelt het antwoord aan de monitor welke vangrail het was. Zeggen ze allemaal ja, dan doet de run wat elke run doet: verificatie, self-review, een securityscan en een pull request. Hij merget nooit. We schreven eerder waarom de mergeknop van jou blijft, en een alert om drie uur 's nachts is daar het sterkste argument voor.
De vangrail die niets weigerde
Vanaf de eerste versie tot begin oktober deed de ernst-vangrail niets. De eerste versie van de intake zette de prioriteit op kritiek als de ernst critical, fatal of error was, en op hoog voor al het andere. Info, warning, geen ernst: allemaal hoog. Omdat de auto-run-vangrail hoog en kritiek doorlaat, liet hij elke alert door die hij ooit zag.
Niets sloeg alarm, omdat elk onderdeel op zichzelf klopte. De vertaling was een redelijke eerste gok en de vangrail controleerde precies wat hij beloofde. We vonden het toen we het helpartikel over alerts schreven en probeerden uit te leggen welke alerts niet vanzelf zouden starten. Het eerlijke antwoord was: geen enkele. De vertaling dekt nu alle vier de prioriteiten, inclusief het severity-label, en een onbekende ernst wordt gemiddeld. Dat is de veilige kant van een vangrail die bestaat om te voorkomen dat ruis geld uitgeeft.
De les die we eruit trokken: schrijf bij elke vangrail die je toevoegt één invoer op die hij moet weigeren, en controleer dat hij dat doet.
Wat het niet doet
- Er is geen aparte koppeling per monitoringtool. De vingerafdruk gebruikt de velden title, message, service en stack op het hoogste niveau van de payload. Staan die bij jouw tool ergens anders, stuur dan een fingerprint-veld mee, anders zien verschillende alerts er voor ons hetzelfde uit en komen ze in één taak terecht.
- Een ontdubbelde herhaling wordt genegeerd. Hij voegt geen teller of nieuw voorbeeld toe aan de bestaande taak.
- Een "resolved"-melding wordt niet herkend als iets wat een probleem afsluit. Hij wordt behandeld als elke andere alert, en de taak blijft open tot iemand hem afsluit.
- Een auto-run start vanuit de alert, niet vanuit een goedgekeurde specificatie. Het bugrapport stuurt de agent om het probleem eerst te reproduceren en dan pas te repareren, maar niemand heeft afgesproken hoe de fix eruit moet zien tot iemand de pull request reviewt.
Hoe we het zouden invoeren
Koppel één alertbron met auto-run uit en laat hem een week staan. Kijk dan op het tabblad Alerts: hoeveel taken, hoeveel samengevoegde herhalingen, welke prioriteiten. Kloppen de prioriteiten met wat jij gekozen zou hebben en heeft het project een verify-commando dat je vertrouwt, zet auto-run dan aan met de standaardlimiet. Voor problemen waarbij eerst een mens naar productie moet kijken, is een troubleshoot-sessie vaak een beter beginpunt dan een fix.