Root cause analyse na een clusterstoring

Wie kan cluster logs analyseren

De verzamelaar draait vanaf uw beheerserver, uitsluitend lezend. Per node leest hij over het incidentvenster de gebeurtenislogboeken uit: 29 kanalen, voor zover ze op uw cluster aan staan. De tijdlijnen van de nodes worden op elkaar gelegd en gecorrigeerd voor klokverschil, zodat zichtbaar wordt wat er in welke volgorde gebeurde en op welke machine het begon.

Voordat er ook maar één node wordt benaderd, toont de verzamelaar het plan van de run: welke nodes, welk tijdvenster, welke onderdelen aan staan, waar de uitvoer landt en per waarde waar die vandaan komt. Daaronder staat één ja-of-nee-vraag en dan pas begint de run. Tijdens de run meldt elke fase zijn verstreken tijd.

De verzamelaar is beproefd op clusters van zes tot zestien nodes en op een productiecluster van zes nodes over twee locaties, volledig vanaf de beheerserver.

Twee zware onderdelen kiest u per run

De clusterlog per node

Verreweg het grootste deel van de run. De omvang verschilt per omgeving; als voorbeeld:

Eerste veldrun · 828 MB ruwe log
Gecomprimeerd · 29,6 MB

Wie een tweede run over hetzelfde venster doet, slaat hem over.

Geheugendumps

Gevonden dumps worden altijd geregistreerd met vindplaats, tijdstip, grootte en hash. Hoe groot een dump is, hangt af van het type: een minidump blijft onder een paar megabyte, een kernel of active memory dump loopt op grote hosts in de gigabytes tot tientallen gigabytes en een volledige geheugendump is zo groot als het werkgeheugen van de node.

Daarom kiest u wat er meegaat: direct, of achteraf met een verkorte run die alleen de dumps van een eerdere run ophaalt en aan de hash controleert dat het nog hetzelfde bestand is.

Gaten zijn onderdeel van het bewijs

Een gebeurteniskanaal dat op een node is doorgerold of uitgeschakeld is, wordt als gat vastgelegd, met de reden. Reikt het clusterlog minder ver terug dan het gevraagde venster, dan staat dat er per node bij. Zo weet u bij het lezen van de analyse precies waar het bewijs ophoudt.

Aan het eind van de run staat daar een advies voor uw beheerder bij: welke kanalen aangezet moeten worden en of de clusterlogbuffer vergroot moet worden om een volgend incident wel volledig te dekken. De afweging staat erbij, want langer bewaren op hetzelfde logniveau kost schijfruimte en langer bewaren op een lager logniveau kost detail.

Daaruit volgt ook de regel achter elke conclusie: zolang bewijs ontbreekt, wordt de conclusie niet geschreven. Ontbrak een node bij de verzameling, dan telt een schoon beeld op de overige nodes niet als meting voor die ene.

Onderbouwing richting uw directie of uw leverancier

Een RCA-document: het incidentvenster, de tijdlijn over alle nodes, de vastgestelde oorzaak voor zover het bewijs die draagt, de gaten met naam en reden en het herstelwerk dat eruit volgt.

Sterker in combinatie met een nulmeting

Een oorzaakonderzoek is los bestelbaar. Maar een reconstructie is het sterkst wanneer de configuratie naast de gebeurtenissen kan worden gelegd, want een afwijkend firmwareniveau of een scheve netwerkinstelling is anders niet van toeval te onderscheiden.

Is het cluster nog nooit volledig gemeten, dan is het advies een oorzaakonderzoek te combineren met een nulmeting via ClusterTriage Assurance. Is de omgeving al Assurance-klant, dan leest het onderzoek ook mee in wat eerdere metingen al vaststelden.