Casus probleem analyse

Deze casus geeft een praktijkvoorbeeld waarbij mijn technische kennis van diverse systemen, kan leiden tot een werkende data harvesting oplossing, waarna die data gebruikt wordt om een eerste analyse te doen, om richting een probleemoplossing te kunnen gaan werken.

Een organisatie heeft al langere tijd problemen met een systeem. Het systeem geeft geen foutmeldingen, en de fouten lijken volledig willekeurig voor te komen. Het betreft clients die met een enkele Windows server communiceren.

Ik heb een programma geschreven die de problemen, maar ook de successen vastlegt. Omdat het systeem geen foutmeldingen geeft, is het vaststellen van een foutsituatie ook niet direct eenvoudig. Door een beetje buiten de lijntjes te denken, heb ik het programma dit toch kunnen laten doen.

Wanneer je heel oppervlakkig kijkt, naar de ruim 380.000 logregels kijkt, die het script gegenereerd heeft, dan zal je er weinig uit op kunnen maken. Het is simpelweg teveel. Doormiddel van een reeks bewerkingen op de logdata is het al wel mogelijk een grafiek van de data te maken.

Uit de grafiek kun je al wel wat data halen. Om de grafiek leesbaar te houden is er hier gekozen voor een zogenaamde sample rate van 1 dag. Per dag worden dus alle gegevens verzameld, en worden deze gegevens uitgetekend in de grafiek.
Wat zien we nu precies?

  • In augustus is er een rustige periode met hoge foutpercentages, die snel afneemt.
  • Vanaf september tot november zie je een lichte stijging in de foutpercentages.
  • In october is er ook een rustige week, maar zonder de hoge foutpercentages van augustus.
  • Gemiddeld is er per dag zo’n 9 procent aan fouten. (oranje lijn)

Laten we er eens een willeukeurige werkweek uitnemen.

Nu zien we meer detail. De sample rate staat op 15 minuten om de grafiek gedetaileerder te maken. We hebben immers nu ook te maken met een veel kortere meetperiode.
Wat zien we nu precies?

  • Het plaatje per dag lijkt redelijk op het plaatje van een andere dag.
  • Op het begin van de werkdag zien we een piek in de fouten.
  • Verderop de dag zien we ook nog 2 pieken.

Nu lichten we woensdag 14 november er eens uit.

Wat zien we nu precies?

  • De eerste percentagepiek rond 8 uur in de ochtend is een vreemde. We hebben dan te maken met minder dan 20 successen, en minder dan 10 fouten. De belasting van het systeem zal dus nog niet zo hoog zijn.
  • Verderop de dag bijvoorbeeld rond 16 uur, hebben we een hogere belasting maar een lager percentage aan fouten.
  • De twee pieken aan het einde van de dag (die we bijna iedere dag terug zien) zijn niet te relateren aan een plotselinge verhoging van de load in dit systeem.
  • Kijkend naar deze details, is er niet direct een verband tussen de directe belasting van dit systeem en het foutpercentage. Eigenlijk is heel de tijd wanneer de load op zijn hoogst is, het aantal fouten op zijn laagst.
  • We moeten niet vergeten dat het foutpercentage natuurlijk een relatief getal is. Het daadwerkelijk aantal fouten (de rode lijn) is stabieler. Maar rond 8 en 9 uur zit hier ook een piek in.
  • Het feit dat een minimale belasting van minder dan 10, wel een foutpercentage van 0 op kan leveren, lijkt toch te wijzen in de richting van een bottleneck.

Hoe nu verder? Het is raadzaam eens te kijken naar bottlenecks in de onderliggende infrastructuur, maar ook de aanpalende servers. Lopen er tijdens de pieken in de foutpercentages wellicht belastende taken op andere systemen of op deze bewuste server, die deze casus wellicht negatief beinvloeden? Dat lijkt mij de eerste stap.

Gebruikte technologie voor data harvesting: Windows Powershell op de Windows client systemen.
Gebruikte technologie voor analyse: Python en Pandas op Linux.