AgentSentinel: A Multi-Agent Framework for Autonomous Root Cause Analysis and Self-Healing in Distributed Systems

Moderne software draait op een uitgestrekt, onderling verbonden web van kleine programma's die microservices worden genoemd. Deze componenten communiceren voortdurend met elkaar door gegevens en verzoeken door te geven, als een estafette. Wanneer één deel faalt, kan het probleem naar buiten toe uitdijen, waardoor andere services wankelen en uiteindelijk het hele systeem platleggen. Jarenlang waren de tools die deze systemen in de gaten hielden uitstekend in het afgaan van het alarm. Ze kunnen detecteren wanneer een server oververhit raakt of wanneer een database verstikt, en ze kunnen een bericht naar een menselijke ingenieur sturen. Maar op het moment dat het alarm afgaat, stopt de automatisering. Een persoon moet dan wakker worden, inloggen, door duizenden regels verwarrende tekstlogs lezen, uitzoeken welke specifieke component kapot is, en het handmatig repareren. Dit proces is traag, foutgevoelig voor menselijke fouten en kan bedrijven miljoenen dollars kosten voor elk uur dat het systeem uit de lucht is. De vraag die onderzoekers zich hebben gesteld is of een machine niet alleen het alarm kan horen, maar ook het verhaal erachter kan begrijpen en het probleem kan oplossen voordat een mens hoeft in te grijpen.

Een team van onderzoekers heeft een prototype-systeem gebouwd genaamd AgentSentinel om die vraag te beantwoorden. Het is geen enkel programma, maar een team van drie gespecialiseerde digitale werkers die samenwerken in een gesloten lus. De eerste werker, de Observer, houdt constant de gezondheid van het systeem in de gaten. Het controleert vier belangrijke tekenen van problemen: hoeveel rekenkracht er wordt gebruikt, hoeveel geheugen er gevuld is, hoe vaak er fouten optreden en hoe lang het duurt voordat verzoeken een reactie krijgen. Als deze tekenen een bepaalde grens overschrijden, slaat de Observer alarm en draagt het de zaak over aan de tweede werker, de Reasoning Agent. Deze agent wordt aangedreven door een groot taalmodel, een type kunstmatige intelligentie dat in staat is om natuurlijke taal en complexe patronen te begrijpen. In plaats van alleen naar de cijfers te kijken, leest de Reasoning Agent de foutlogs en raadpleegt het een kaart van hoe de verschillende softwareonderdelen met elkaar verbonden zijn. Deze kaart is cruciaal omdat het de AI helpt om onderscheid te maken tussen de werkelijke oorzaak van de fout en de symptomen die later verschijnen. Als bijvoorbeeld een database faalt, kunnen veel andere services direct daarna ook beginnen te crashen. Zonder de kaart zou een AI een van de crashende services de schuld kunnen geven; met de kaart weet de AI dat hij terug moet kijken naar de database als de werkelijke bron van het probleem.

Zodra de Reasoning Agent de schuldige heeft geïdentificeerd, geeft het een plan door aan de derde werker, de Repair Agent. Deze werker is degene die actie onderneemt, maar doet dit met uiterste voorzichtigheid. Voordat het de live systemen aanraakt, controleert het een strikte lijst van toegestane acties, zoals het herstarten van een specifieke service, het legen van een geheugencache of het toevoegen van meer rekenkracht om de belasting op te vangen. Het is geprogrammeerd om elke opdracht af te wijzen die gegevens zou kunnen vernietigen of de situatie zou kunnen verergeren. Als de actie veilig is, voert de Repair Agent deze uit op het draaiende systeem. Nadat de reparatie is toegepast, houdt het systeem nauwlettend in de gaten of het probleem echt is verdwenen. Als de statistieken weer normaal zijn, wordt het incident geregistreerd als een succes en gaat het systeem terug naar de waakstand. Als het probleem voortduurt, probeert het team een andere aanpak, en als drie pogingen mislukken, waarschuwt het een menselijke operator. Deze hele cyclus, van het moment dat een fout optreedt tot het moment dat het is opgelost, vindt automatisch plaats zonder menselijke tussenkomst.

De onderzoekers testten dit systeem in een gecontroleerde omgeving die de softwareopstelling van een klein bedrijf nabootste. Ze braken het systeem doelbewust op vijf verschillende manieren: het geheugen volmaken tot het crashte, een service abrupt afsluiten, een processor overbelasten, databaseverbindingen verbreken en het netwerkverkeer vertragen. In elk geval detecteerde het systeem het probleem, bepaalde het de grondoorzaak en repareerde het dit uit zichzelf. De gemiddelde tijd om het probleem te detecteren was iets minder dan twee seconden, en de gemiddelde tijd om het te repareren was ongeveer vijf en een half seconde. Tijdens de perioden dat het systeem normaal draaide, gaf het geen enkel vals alarm. Deze resultaten suggereren dat het combineren van snelle detectie met intelligente redenering en veilige, geautomatiseerde reparatie een levensvatbare manier is om software-infrastructuur te beheren. De auteurs merken echter voorzichtig op dat dit een bewijs van concept was, uitgevoerd op een kleine, eenvoudige testomgeving. Ze hebben het systeem nog niet getest op de enorme, complexe netwerken die door grote bedrijven worden gebruikt, waar duizenden services op onvoorspelbare manieren met elkaar interageren.

De studie benadrukt ook het belang van het "geheugen" dat het systeem bijhoudt. Na een succesvolle reparatie slaat het systeem de details op van wat er is gebeurd en hoe het is opgelost. Als een soortgelijk probleem later optreedt, kan het systeem die eerdere oplossing herinneren en deze sneller toepassen, net zoals een monteur zich herinnert hoe hij een specifie ofc probleem met een motor eerder heeft opgelost. Hoewel de onderzoekers deze geheugenfunctie hebben gebouwd, hebben ze nog niet precies gemeten hoeveel dit toekomstige reparaties versnelt. Ze erkennen ook dat hun huidige test geen scenario's bevatte waarbij meerdere fouten tegelijkertijd optreden, wat gebruikelijk is bij echte rampen. Het werk laat zien dat de architectuur werkt in een gecontroleerde omgeving, maar het is nog niet klaar voor de chaos van een productieomgeving. De volgende stappen voor het team bestaan uit het veel vaker uitvoeren van deze tests om ervoor te zorgen dat de resultaten consistent zijn, het testen van het systeem op grotere netwerken en het verfijnen van het geheugensysteem om te zien of het de AI echt helpt om te leren van zijn eerdere fouten. Voor nu staat AgentSentinel als een werkende demonstratie dat machines geleerd kunnen worden om niet alleen op zoek te gaan naar problemen, maar om ze ook te begrijpen en op te lossen.