Frontend-alerting en een AI-ondersteunde triagebot
Alerting op relatieve veranderingen in telemetrie plus een chatbot met LLM-ondersteuning die van een alert een waarschijnlijke oorzaak maakt, in de thread waar het team al werkt.
- Stack
- SQL · Alerting service · LLM API · Kubernetes · Internal chat bot
Het probleem
Stille uitval bij overdrachten aan derde partijen werd dagen later via de klantenservice ontdekt. De alerts waren gebaseerd op vaste drempels en luidruchtig, waardoor mensen ze waren gaan negeren.
De aanpak
- Relatieve baselines, geen vaste drempels. De alertingdienst voert SQL uit op de telemetrieopslag en vergelijkt elke metric met hetzelfde uur van vorige week. Een daling van 20% betekent iets om 3 uur 's nachts in de ene regio en 's middags in een andere, en wereldwijde verkeersschommelingen veroorzaken geen vals alarm meer.
- Een alert die met context aankomt. Wanneer een alert afgaat, verschijnt er een incidentkaart in de teamchat. Een achtergrondworker verzamelt dan recente frontendfouten, de actieve configuratieversie en deploymentlogs en stuurt die als gestructureerde prompt naar een LLM-API.
- Een samenvatting in de thread. De bot antwoordt met een waarschijnlijke oorzaak, bijvoorbeeld: de conversie van één stap daalt in één regio, er zit een null-pointerfout in een native wrapper, een configuratiewijziging ging 15 minuten eerder live en een downstreamdienst loopt tegen timeouts aan.
Het resultaat
De tijd tot detectie daalde van uren of dagen naar minuten, de tijd tot mitigatie werd korter en de alerts werden alerts waar mensen op vertrouwen. Ik hield ook de signaal-ruisverhouding van alerts bij (het aandeel dat bij echte incidenten hoort) en de gemiddelde tijd tussen storingen voor frontendmodules.
Waarom zo
Een gewone alert vertelt dat er iets kapot is. De gegevens automatisch verzamelen en samenvatten dicht de kloof tussen een metric en een mens die het begrijpt, en daar ging het grootste deel van de reactietijd verloren.