Zo worden servicenormen meetbaar

Het maken van serviceafspraken over een ICT-service vereist dat de gestelde servicenormen gemonitord worden. In de loop van de tijd zijn hiertoe diverse monitoring methoden en technieken ontwikkeld. Elke oplossing heeft specifieke voor- en nadelen. Dit artikel geeft een overview van veel gebruikte oplossingen voor het monitoren van ICT-services.

Introductie monitoring

Er zijn vele tools op de markt om ICT-services te monitoren. Dit artikel bespreekt een vijftal veel voorkomende archetypes:

• Servicedesk monitoring: de gebruiker zelf is hierbij de monitor van verstoringen die een servicedesk medewerker in een servicedesktool administreert.
• Built-in monitoring: in de applicatie, die de basis vormt voor de ICT-service, wordt meetfunctionaliteit ingebouwd.
• Component based monitoring: het monitoren van de ICT-service op basis van de onderliggende infrastructuur– en applicatiecomponenten.
• End User eXperience monitoring (EUX): het monitoren op basis van een gebruiker-simulatie.
• Real User Monitoring (RUM): het monitoren op basis van het feitelijk gebruik van de ICT-service.

In dit artikel wordt per variant wordt een uitleg gegeven, inclusief een set van voor- en nadelen. Om een indruk te geven van de veelzijdigheid van meetinstrumenten wordt van elke variant een aantal specifieke kenmerken van een tool toegelicht. Om de tekst compact te houden zijn niet alle voor- en nadelen per variant beschreven. Aan het einde van het artikel is ter aanvulling een samenvatting gegeven met daarbij aanvullende voor- en nadelen. De servicedesk monitoring is algemeen bekend verondersteld en is alleen in de samenvatting opgenomen. Dit artikel sluit af met een conclusie.

Servicedesk monitoring

Bij veel organisaties vervult de servicedesk nog steeds een belangrijke monitorfunctie. De meting van de serviceverlening wordt hierbij door de gebruikers en DevOps engineers gedaan op basis van het aanmelden van incidenten bij de servicedesk. De rapportage van de servicedesk kan dan gebruikt worden om te bepalen of de serviceafspraken zijn nagekomen. In dat geval zijn de servicenormen meestal gericht op de oplostijd en soms ook wel de klanttevredenheid op basis van vragen die gesteld worden na afloop van een call naar de servicedesk.

Voordelen:

• De metingen zijn gericht op de perceptie van de gebruiker en de DevOps engineer.
• De metingen omvat alle aspecten van de serviceverlening waaronder de ervaring van de gebruiker zoals gebruiksgemak.
• De monitorvoorziening behoeft geen onderhoud omdat de gebruiker en de DevOps engineer de waarnemingen doen.
• De gebruiker en de DevOps engineers krijgen een persoonlijke afhandeling van hun calls.
• De servicedesk is relatief eenvoudig en snel in te regelen.

Nadelen:

• De servicedesk neemt niet alle verstoringen waar.
• Het afhandelen van een incident kan lang duren omdat niet altijd de locatie van de verstoring bekend is.
• De metingen van de servicedesk zijn niet nauwkeurig omdat er tijd verstrijkt tussen het incident en het registreren van het incident. Ook kunnen incidenten vaker worden aangemeld waardoor het lastig is om vast te stellen hoe lang de ICT-service niet beschikbaar is geweest.

Built-in monitoring

Tijdens de bouw van een applicatie kan de monitorfunctionaliteit vrij eenvoudig worden meegenomen door meetpunten te bepalen die de te bieden ICT-serviceverlening meetbaar maken. Deze moet dan wel op basis van requirements van de gebruikers- en serviceorganisatie worden gerealiseerd. Deze vorm van monitoring is al vrij oud. Voorbeelden zijn het bijhouden van tellingen in een complexe crossplatform batchverwerking en doorlooptijden van berichten door een keten. Er zijn ook leveranciers die in Common Of The Shelf (COTS) applicaties built-in monitorfaciliteiten meeleveren. De meetgegevens zijn te ontsluiten zodat deze aan de eigen monitorvoorziening kunnen worden doorgegeven.

Voordelen:

• De built-in monitor kan op diverse punten de interne werking van de applicatie meten. Veel van deze meetgegevens zijn vaak niet met reguliere monitortools te meten.
• De metingen kunnen gelogd worden inclusief nuttige analyse-informatie over de oorzaak van de verstoring.
• De kosten van deze metingen zijn vrij laag. Bij maatwerkapplicaties moet de functionaliteit al van meet af aan in het ontwerp zijn meegenomen.
• De metingen maken proactief beheer mogelijk doordat trends meetbaar zijn.
• De detectietijd van verstoringen is kort, waardoor de beschikbaarheid toeneemt.
• De meting geeft de locatie weer van de verstoring.

Nadelen:

• De oplossing geldt alleen voor maatwerkapplicaties, tenzij de aangekochte applicatie hierin voorziet.
• De metingen moeten in alle applicaties worden meegenomen.
• De meting omvat alleen de transacties die zichtbaar zijn in de applicatie. Als gebruikers de applicatie helemaal niet kunnen gebruiken, dan wordt dit niet geconstateerd.
• Wijzigingen aan de meetfunctionaliteit betekent een aanpassing aan de applicatie.
• De monitorfunctie is intrusive, dit wil zeggen dat de uitvoering van de meting ten koste gaat van de resources die aan de applicatie zijn toegekend.
• De monitorvoorziening is intern gericht, het is niet mogelijk om de performance van gekoppelde informatiesystemen te monitoren. Dit geldt ook voor infrastructurele services zoals het network-, storage- en identity management.

Component based monitoring

Een ICT-service kan uitéén worden gerafeld in infrastructuur- en applicatiecomponenten. Bijvoorbeeld aan de hand van de Component Failure Impact Analyse (CFIA) van IBM zoals deze binnen ITIL wordt beschreven. De som van deze componenten is bepalend voor de kwaliteit van de ICT-service. De SLA-normen van een ICT-service zijn dus te meten aan de hand van deze componenten. Figuur 2 geeft een schetst van deze monitorarchitectuur.

De monitorserver verzamelt de statusinformatie van de infrastructuur- en de applicatiecom-ponenten. Deze statusinformatie is velerlei en omvat zaken als: events die in logbestanden zijn weggeschreven, resourcebeslag van de infrastructuurcomponenten, de bereikbaarheid, beschik-baarheid en performance van infrastructurele en applicatieve services, alsmede ingestelde parameters en configuratieinformatie in het algemeen.

Deze informatie kan zowel middels een push- als een pullactie worden verzameld. Bij een pushactie worden actieve agents op een server gebruikt om de status van de betrokken componenten door te geven. Bij een pullactie verzamelt de monitorserver zelf de status van alle componenten door deze periodiek langs te lopen. Een best practice frequentie is één keer in de vijftien minuten. Op basis van de centraal verzamelde informatie van de componenten bepaalt de monitorserver welke actie wanneer moet worden genomen. Periodiek kan een SLA-rapportage worden aangemaakt over de resultaten. Hierbij wordt uiteraard rekening gehouden met de redundantie van componenten en dergelijke.

Voordelen:

• De meting geeft in veel gevallen precies weer welke locatie, en welk onderdeel van de infrastructuur of applicatie verstoord is. Afhankelijk van de gekozen tool kost dit weinig of veel configuratie-inspanning.
• In de registratie van de meting kan meegenomen worden voor welke oplosgroep het incident bestemd is.
• De meting geeft inzicht in zowel de beschikbaarheid, capaciteit, performance als de beveiliging van de ingezette componenten.
• De totale en beschikbare capaciteit van de infrastructuur is goed te bewaken op basis van het huidige verbruik. Door trendanalyse is ook het toekomstige verbruik te voorspellen ter ondersteuning van het capacity management proces (proactief probleem-beheer).
• Door de consolidatie kunnen events uitgefilterd worden. Zo kunnen events die betrekking hebben op dezelfde verstoring gebundeld worden.
• De monitoring geeft bij een verstoring aan welk core value stream / ICT-service geraakt is, mits de relaties binnen de CMDB goed zijn opgebouwd. Hierdoor kan snel en adequaat binnen de SLA-afspraken gereageerd worden.
• De metingen en rapportages worden verricht zonder dat er een menselijke handeling aan te pas komt. Dit is een belangrijk aspect voor auditing en/of verificatie met de service-deskregistratie.

Nadelen:

• Afhankelijk van de gekozen tool en de wijze waarop deze is ingesteld worden niet alle gebeurtenissen (events) gemonitord omdat dit er te veel zijn. Door het instellen van filters kan het dan voorkomen dat belangrijke events niet worden gecommuniceerd aan de beheerders, omdat deze niet door de ingestelde filters heen komen.
• Als er diverse tools worden ingezet die tezamen het totale beeld moeten schetsen, dan zijn er diverse factoren waardoor events misgelopen kunnen worden. Voorbeelden zijn de connectiviteit tussen de tools, het doorgeven van events met een verkeerd berichtformaat, verschillen in definitie van prestatie indicatoren en dergelijke.
• Het meten aan een ICT-service op basis van de onderkende componenten heeft altijd het gevaar dat componenten gemist worden en dat de som van de metingen afwijkt van de ervaring van de eindgebruiker.
• De meting is gericht op de componenten hetgeen niets zegt over de performance van een businesstransactie binnen de ICT-service.
• De componenten die door meer services worden ingezet kunnen een scheef beeld geven van het resourcegebruik van een service. Er zijn tools waarbij deze beeldvervorming met aanvullende metingen te corrigeren zijn.
• Bij de pullmethode kan sprake zijn van performanceverlies. De pushmethode vereist het beheer van agents op de te meten objecten.

EUX

Naast de component gebaseerde monitoroplossing zijn er ook oplossingen die ICT-services end-to-end (E2E) doormeten. In de praktijk zijn er twee hoofdstromen te onderkennen te weten de EUX- en de RUM-monitoroplossing. Het verschil tussen beide is dat de EUX-oplossing de ICT-service meet op basis van een simulatie van een gebruiker, terwijl de RUM-oplossing de transacties van de werkelijke gebruikers meet. Nu volgt eerst een uiteenzetting van de EUX-oplossing, daarna wordt de RUM-oplossing besproken.

De EUX-oplossing is gebaseerd op een simulatie van een gebruiker. Deze simulatie vindt plaats door het feitelijk gebruik van de applicatie door een gebruiker met een recorder op te nemen en de hierdoor verkregen scripts (synthetische transacties) periodiek af te spelen. Hiertoe wordt gebruik gemaakt van één of meer werkplekken (robots) die vaak in een afgesloten ruimte worden opgesteld.

De meeste leveranciers bieden een oplossing waarbij het beheer van de scripts op een centrale server plaatsvindt. Nieuwe of aangepaste scripts worden door de centrale server gedistribueerd naar de robots. Ook de scheduling van de door de robots af te vuren scripts wordt centraal ingeregeld. De resultaten van de robotmetingen worden centraal verzameld en vergeleken met de servicenormen. In geval van een normoverschrijding wordt een alert afgegeven. Figuur 3 toont een voorbeeld van een EUX-inrichting.

Er zijn diverse producten op de markt met totaal verschillende functionaliteit, kwaliteit en prijsstelling. Er zijn ook leveranciers die EUX-services aanbieden om internettoepassingen door te meten. Hierbij wordt de internet ICT-service vanaf diverse locaties op de wereld of Nederland gemeten, gealert en gerapporteerd. Deze serviceverlening kan al voor enkele tientallen euro’s per te monitoren transactie per maand afgenomen worden. Verder zijn er ook nog freeware tools beschikbaar op de markt. Ook met deze tools kunnen gebruikerstransacties gesimuleerd worden.

Belangrijke additionele faciliteiten zijn het back-tracen van de oorzaak van een verstoring. Dit kan tot op zekere hoogte door de robot zelf. Ook kan aan de hand van additionele metingen en analyses, als door koppelingen met andere tools extra informatie worden verzameld en analyses worden verricht.

Voordelen:

• De meting komt dicht in de buurt van wat de gebruiker ervaart.
• De meting vereist geen kennis van de diverse componenten die ten grondslag liggen aan de service.
• Metingen leveren een goede indicatie op van alle verstoringen die voor de gebruiker zichtbaar zouden kunnen zijn in de totale ICT-service ongeacht de geaardheid (infrastructuur, applicatief of werklast).
• De SAAS-metingen vereisen geen implementatie van monitoring software en kunnen snel ingezet worden.

Nadelen:

• De waarneming van de robots is beperkt tot een aantal tijdstippen, vanaf een beperkt aantal locaties, met een beperkt aantal functies en met een beperkte set van data.
• De meting levert beperkte informatie over de locatie van de verstoring (wel back tracing).
• De robot beïnvloedt het te monitoren systeem. Er moet dus heel goed gekeken worden naar het resourcebeslag (memory, diskcapaciteit et cetera) en vervuiling van de productie databases door de monitortool.
• De robot moet een account krijgen met een password. Iedereen die het account en password weet, heeft dezelfde rechten als de robot.
• Bij onderhoud aan de applicatie moet gecontroleerd worden of de robot nog werkt. Bepaalde aanpassingen aan de user interface van de applicatie zijn funest voor de juiste werking van de robot.

RUM

Real User Monitoring is het monitoren van het feitelijk gebruik van de ICT-service door gebruikers zonder invloed uit te oefenen op de ICT-service (non intrusive). Deze technologie meet op basis van het netwerkverkeer dat ten grondslag ligt aan de ICT-service wat de prestaties zijn die worden geleverd. Hiertoe worden de netwerkverkeerpakketten gekopieerd en op een monitorserver geanalyseerd.

Er zijn een aantal leveranciers op de markt die invulling hebben gegeven aan het meten van servicenormen op basis van het feitelijke netwerkverkeer (Netwerk Protocol Analyse (NPA). Er worden een aantal belangrijke RUM-functies aangeboden. Zo kunnen de gemeten gebruikers-transacties opnieuw afgespeeld worden. Met een RUM-oplossing wordt immers al het (HTML) transactieverkeer gelogd. Tevens is er een business intelligence functie beschikbaar waarmee niet alleen de beschikbaarheid en performance kan worden gemeten, maar ook het navigatie-gedrag van de gebruiker, de pagina-laadtijd, de voorraad van artikelen et cetera. De derde functie is de rootcause-analyse waarmee tot op zekere hoogte geanalyseerd kan worden welk onderdeel van de applicatie, zoals een winkelwagentje, de veroorzaker is van een verstoring.

Voordelen:

• De meting is non-intrusive, de meter beïnvloedt niet de meting en verbruikt geen resources die aan de applicatie zijn toegekend.
• De meting is gebaseerd op de werkelijke transacties, dus niet op simulaties of steek-proeven. Hierdoor is de meting objectief en betrouwbaar.
• De meting geeft inzicht in het werkelijke gedrag van het informatiesysteem.
• Gewijzigde applicaties worden automatisch ook gemeten. Er hoeven immers geen scripts aangepast te worden. Elke echte gebruikersactie wordt gemeten.
• Niet alleen normen zoals beschikbaarheid en performance zijn goed te meten, maar ook het gedrag van de gebruiker. Zo kan het navigatiegedrag van gebruikers in een webapplicatie bepaald worden. Op basis hiervan zijn marketinganalyses te verrichten.

Nadelen:

• De netwerkpakketten moeten genoeg informatie bevatten om deze te kunnen correleren aan de ICT-service. Dit kan zowel door tags toe te voegen aan een HTML request als op basis van een URL-structuur.
• Veelal zijn deze oplossingen sterk afhankelijk van het gevoerde protocol (http/https). Hierdoor kunnen vaak alleen webbased applicaties worden gemonitord.
• Wijzigingen in de applicatie moeten op impact beoordeeld worden. In de meeste gevallen worden alle gegevens nog steeds gemeten. Wel moeten de alert-rules en de rapportages nagelopen worden.
• De metingen bevatten productiegegevens die heel vertrouwelijk kunnen zijn. Er moeten maatregelen getroffen worden om deze te beveiligen. De meeste tools voorzien hier in.
• De locatie van de oorzaak van een verstoring is niet te achterhalen. Wel bieden veel leveranciers oplossingen om de RUM-monitorfunctionaliteit te koppelen aan analyse tooling.
• Het herkennen van de businesstransacties in de netwerkpakketten en het eventueel aanpassen van de applicatie om deze transacties te meten kan de nodige tijd kosten. Dit hangt mede af van de complexiteit van de business service.
• Het enorme vermogen van deze tooling heeft een big-brother-watching-you neveneffect. Er moeten goede afspraken gemaakt worden met de gebruikers van het informatie-systeem.
• De metingen zijn alleen bruikbaar indien er een baseline is van een goede performance. Bij een organisatie met 50 applicaties die elk 20 tot 30 verschillende type transacties hebben is zo’n baseline erg lastig vast te stellen.

Samenvatting monitoring

Tabel 1 geeft een overzicht van een aantal van de in dit artikel genoemde voor- en nadelen, aangevuld met een aantal extra punten. De invulling is alleen indicatief bedoeld, er zijn namelijk altijd wel mitsen en maren. Tevens vallen niet alle op de markt beschikbare tools precies binnen één klasse. Toch geeft deze tabel een aardige indicatie van de mogelijkheden en onmogelijk-heden van de gekozen oplossing. Elke in de tabel genoemde beperking is minstens een check van de gekozen oplossing waard.

			Servicedesk	Built-in		Compo-nent Based	EUX	RUM XE "RUM"
Meetbereik servicenormen XE “service:- norm”
– Beschikbaarheid XE "beschikbaarheid"
– Performance XE "Performance"
– Capaciteit XE "Capaciteit"
– Beveiliging XE "beveiliging"
– Navigatiegedrag XE "navigatiegedrag"
Bijzondere meetfunctionaliteit
– Automatische detectie XE "automatische detectie"
– Detectie zonder gebruikers XE "detectie zonder gebruikers"
– Proactief beheer (trendanalyse)
– Meting infrastructuur eventlog								*
– Metingen applicatie eventlog
– Meting foutmeldingen aan gebruiker XE "gebruiker"
Meetinformatie:
– Lokatie van de verstoring								**
– Betrokken componenten
– Indicatie oplosgroep
Meetbereik:
– Infrastructuurcomponenten
– Applicatiecomponenten								***
– Business transacties XE "transactie"
Flexibiliteit qua:
– Meetfrequentie
– Meetlokaties
– Meetfunctionaliteit
Meetbeinvloeding:
– Databases blijft onaangetast
– Non intrusive
Onderhoudbaarheid
Aanpasbaarheid
Ongevoelig voor applicatie aanpassingen								****
*) Wel via additionele tools die al dan niet als een geïntegreerde oplossing worden aangeboden. **) RUM XE "RUM"  kan de verstoring lokaliseren tot op client-, server- of netwerkgebieden. ***) Die applicatiecomponenten XE "applicatiecomponent"  die vanuit de gebruikersinterface waar te nemen zijn wel (bijvoorbeeld winkelwagentje), de interne componenten die niet af te leiden zijn van het netwerkverkeer niet. ****) Applicatiewijzigingen zijn in de huidige generatie van RUM XE "RUM" -tools transparant voor de monitortools XE “monitor:- tool"  doordat applicatie herkend worden op basis van URL-structuren. Eventueel benodigde tags ter herkenning van transacties XE "transactie"  kunnen vanuit een Content Management Systeem (CMS) worden toegevoegd.
Legenda
Ja	Deels	Beperkt	Nee

Tabel 1, Voor- en nadelen per monitoroplossing.

Om de diverse oplossingen nog beter te vergelijken is in tabel 2 een overzicht gegeven van de enkele karakteristieke metingen per oplossing.

	Karakteristieke metingen
Servicedesk	Incidenten en wijzigingen.
Built-in	Aantal transacties, doorlooptijd transacties, fouten per applicatiemodule.
Component based	Afgeleide beschikbaarheid en performance van de ICT-service op basis van verstoring aan componenten. Hiervoor worden resource metingen verricht zoals CPU belasting, memory verbruik, netwerkbandbreedte verbruik. Verder eventmetingen zoals logbestanden van MS Windows, z/OS, Linux et cetera. En tenslotte servicemetingen zoals Apache webservers, MS IIS, Printservices et cetera.
EUX	Beschikbaarheid en performance van synthetische transacties van applicatiefuncties. De metingen betreffen de doorlooptijd, beschikbaarheid (http-statuscodes), et cetera.
RUM	Beschikbaarheid en performance van business transacties. De metingen betreffen doorlooptijd, beschikbaarheid, webpagina laadtijd, navigatiegedrag (klikpaden), verkoop artikelen, foutboodschappen et cetera.

Tabel 2, Karakteristieke metingen.

Conclusie monitoring

Elke monitorarchitectuur heeft voor- en nadelen. Er zal voor een goede monitoring van een ICT-service altijd een combinatie nodig zijn van monitortools. Idealiter worden de servicenormen E2E gemeten met een EUX- en/of RUM-oplossing, zodat de meting zo dicht mogelijk in de buurt komt van wat de gebruiker ervaart. Met alleen een inrichting van een EUX- en/of RUM-oplossing kan niet volstaan worden. Er zal altijd een component-based monitoroplossing nodig zijn voor de lokalisatie van een verstoring.

Boeken:

Continuous Monitoring, ISBN:978 94 92618 498

Prestatie Indicatoren, ISBN:9789071501470

Masterclass Continuous Monitoring ITMG.