Services en KPI's opzetten in Splunk ITSI

Begin bij de vraag wat gezond is

De meeste ITSI-trajecten lopen vast op dezelfde plek: er zijn genoeg data, maar niemand heeft vastgelegd wanneer een dienst goed werkt. Een KPI zonder afspraak over de normaalwaarde levert een dashboard op dat iedereen negeert.

Daarom begin ik bij de mensen die verantwoordelijk zijn voor de dienst. Bij een overheidsorganisatie heb ik voor meerdere ketens van diensten de KPI's samen met de betrokken teams en eigenaren bepaald. Vragen als "waar merkt een gebruiker het eerst dat iets misgaat?" en "welke waarde is voor u nog acceptabel?" leveren betere KPI's op dan een lijst met alle beschikbare metrics. Het resultaat is een service health score die de teams herkennen en vertrouwen.

De service tree en afhankelijkheden

In ITSI modelleert u een dienst als service. Een service kan afhankelijk zijn van andere services, zodat er een boom ontstaat: een bedrijfsdienst bovenaan, daaronder bijvoorbeeld een webapplicatie, een database en een loadbalancer. In de Service Analyzer ziet u die boom terug, met de gezondheid van elke service.

Houd de boom in eerste instantie klein. Modelleer de keten die het meest oplevert en breid daarna uit. Bij het opzetten van afhankelijkheden bepaalt u ook hoe zwaar de gezondheid van een onderliggende service meetelt voor de bovenliggende service. Voor vergelijkbare services werkt het gebruik van service templates goed, zodat u KPI's en instellingen op één plek beheert.

KPI's en base searches

Een KPI is een zoekopdracht die op een vast interval een waarde berekent, zoals de responstijd, het percentage foutmeldingen of het aantal verwerkte berichten. U kunt per KPI een losse zoekopdracht schrijven, maar bij meer dan een handvol KPI's is een KPI base search verstandiger. Eén base search haalt de data één keer op en levert meerdere metrics aan verschillende KPI's. Dat scheelt zoeklast en houdt de definities consistent.

Let bij elke KPI op het interval, de berekening (gemiddelde, maximum, aantal) en de periode waarover u kijkt. Een te kort interval op een bron die met vertraging binnenkomt, geeft schijnbare dalingen die niets met de dienst te maken hebben.

Entities: van dienst naar onderdeel

Entities zijn de onderdelen achter een service, zoals hosts, containers of applicatie-instanties. Met entity rules koppelt u entities aan een service en met het splitsen van een KPI per entity ziet u welke server de oorzaak is van een slechte score. Zonder entities weet u dat er iets mis is, met entities weet u ook waar.

Thresholds en adaptive thresholding

Per KPI stelt u thresholds in die een waarde vertalen naar een ernst, van normal tot critical. Statische thresholds werken goed voor harde grenzen, zoals een schijf die vol raakt. Voor waarden met een duidelijk dag- of weekpatroon zijn time-based thresholds nodig: om drie uur 's nachts is weinig verkeer normaal, op maandagochtend niet.

Adaptive thresholding berekent de grenzen op basis van historische data, bijvoorbeeld met standaarddeviatie of kwantielen. Dat is een prima aanvulling, maar geen vervanging van het gesprek met de eigenaar. Controleer de voorgestelde grenzen altijd en laat ze pas los op een KPI met voldoende historie.

De service health score

De health score van een service is een gewogen combinatie van de ernst van de KPI's. Met de importance van een KPI bepaalt u het gewicht. Een KPI met de hoogste importance werkt als minimale gezondheidsindicator: staat die op critical, dan staat de hele service op critical. Gebruik dat spaarzaam, voor de KPI die echt bepaalt of de dienst werkt.

Notable events, episodes en aggregation policies

Een slechte score is pas nuttig als er iemand op reageert. Correlation searches maken notable events aan, bijvoorbeeld wanneer de health score van een service onder een grens zakt. Met notable event aggregation policies groepeert ITSI samenhangende events tot episodes, zodat één storing leidt tot één episode in plaats van tientallen losse meldingen.

In een aggregation policy legt u vast welke events bij elkaar horen, wanneer een episode sluit en welke acties volgen, zoals het aanmaken van een ticket. Bij een IT-dienstverlener in de juridische sector heb ik deze episodes in twee richtingen gekoppeld aan TOPdesk. Node-RED-flows handelden daarbij gecorreleerde events automatisch af. De hersteltijd van de meeste incidenten daalde daardoor sterk.

Klein beginnen

Een werkbare volgorde voor een eerste inrichting:

• Kies één dienst waar storingen merkbaar zijn voor gebruikers.
• Bepaal met de eigenaar drie tot vijf KPI's en de grenswaarden.
• Bouw de KPI's op een gedeelde base search en koppel de entities.
• Laat de thresholds een paar weken meedraaien voordat u er meldingen aan hangt.
• Voeg daarna een aggregation policy toe en breid de service tree stap voor stap uit.