Eva is applicatiebeheerder en verantwoordelijk voor de beschikbaarheid en performance van een bedrijfskritische applicatie. Door de tijd heen is deze applicatie gegroeid en waren er nooit klachten van de eindgebruikers. Tot voor kort. Regelmatig worden er incidenten gemeld met incomplete omschrijvingen van “het is traag” tot “als ik mijn dagelijkse werkzaamheden uitvoer zijn de gegevens niet beschikbaar”. Eva begint zich af te vragen of er geen manier is om de back-end waar haar applicatie op draait te monitoren gecombineerd met metingen vanuit het eindgebruikersperspectief op de front-end? Eva denkt bij zichzelf: “Dat zou toch wel de heilige graal kunnen zijn! Om grip en controle te krijgen en te houden op zowel mijn applicatie als de omgeving waar het op draait.”
Toelichting:
Ik zal eerst verder toelichten wat ik versta onder de anatomie van back-end (Bottom Up Monitoring) en front-end (Top Down Monitoring) monitoring met als voorbeeld onze eerder genoemde Eva die applicatiebeheerder is van project x.
Back-end:
Omdat Eva een bedrijf kritische applicatie onder haar beheer heeft besluit zij in al haar wijsheid om het landschap waar de applicatie op draait te monitoren. Zo wil zij tijdig op de hoogte gesteld worden als een server niet meer bereikbaar is, schijven (langzaam) vollopen, het berichtenverkeer een periode geen waardes doorgeeft en wat o.a. de langstdurende query’s zijn in de database. Eva is erg content wanneer alles ingericht is door middel van een open source tool voor het server en netwerkbeheer en een betaalde tool om de database-omgeving te monitoren. Een aantal keer ontvangt Eva terechte alerting waardoor zij voortijdig kan ingrijpen en hiermee fouten binnen de applicatie voorkomt. Echter blijven de gebruikers van haar applicatie terugkeren bij haar met klachten.
Front-end:
Om de gebruiker in 80% van de gevallen voortaan voor te zijn, besluit Eva ook de front-end te gaan monitoren op beschikbaarheid van de applicatie en inzicht te krijgen in de responstijden gemeten vanuit haar eindgebruikers. Dit wil zij doen door de meest applicatie-kritische onderdelen geautomatiseerd uit te laten voeren. Daarnaast richt zij deze scripts (geautomatiseerde stappen) zo in dat deze controleren op het laatst geladen onderdeel van de pagina. Zo verkrijgt Eva een realistische responstijd vergelijkbaar met de beleving van haar eindgebruikers. De URL- en pingmonitoring-tools schuift zij aan de kant en besluit voor een betaalde oplossing te gaan. Deze oplossing geeft keurig vanaf verschillende locaties de beschikbaarheid en responstijden van haar eindgebruikers weer.
Issue:
Eva is nu haar eindgebruikers voor en weet in meer dan 80% van de gevallen dat er wat mis is met de applicatie en waar de oorzaak ongeveer zit. Maar om te zien waar de mogelijke bottleneck precies zit moet Eva nu door de alerting heen spitten gegenereerd uit verschillende tooling, door minimaal 3 verschillende applicatie dashboards heen klikken. De kost teveel tijd, want haar eindgebruikers willen gewoon weer aan de slag kunnen gaan.
De heilige graal:
Eva besluit dat zij alle beschikbare informatie voortaan in één dashboard wil. Ze begint door een aantal KPI’s op te stellen zoals:
- Op een topologieplaat zichtbaar de status van de omgeving waar de applicatie op draait of wat de applicatie raakt;
- Trend inzicht in de responstijden van haar applicatie;
- Trend informatie omtrent de toe en of afname van gebruik
- De huidige status en responstijden van haar applicatie;
- Toename en afname van helpdeskcalls betreffende haar applicatie;
- Aantal bezoekers/gebruikers
Conclusie:
Eva besluit alle partijen aan tafel te brengen om haar idee te laten realiseren. Hier zal tijd en geld mee gemoeid zijn maar iedereen ziet hierin een kans om leverancier voor Eva te blijven evenals tezamen de handen ineen te slaan om een situatie te realiseren waarvan niemand het nog eerder werkend heeft gezien. De bovenstaande situatie is een utopie. De back-end partijen presenteren data op hun eigen wijze en de meeste front-end partijen zijn niet flexibel genoeg om realistische eindgebruikers monitoring te presenteren in combinatie met gegevens uit andere systemen.
Ik vraag me af, zou er al een softwareproduct in de markt zijn die voldoet aan Eva haar wensen? Zijn er misschien al partijen die de handen ineen hebben geslagen om samen een totale APM dekking te geven aan haar klanten?
Door Erik Visser – Perfomancetest specialist bij Computest