Aanbevolen procedures voor bewaking en diagnose

Gedistribueerde toepassingen en services die in de cloud worden uitgevoerd, zijn complexe softwareonderdelen die bestaan uit veel bewegende onderdelen. In een productieomgeving is het belangrijk om bij te houden hoe klanten uw systeem gebruiken, resourcegebruik traceren en de status en prestaties van uw systeem bewaken. U kunt deze informatie gebruiken om problemen te detecteren en op te lossen en potentiële problemen te ondervangen voordat ze optreden.

Scenario's voor bewaking en diagnose

U kunt bewaking gebruiken om inzicht te krijgen in hoe goed een systeem functioneert. Bewaking is een cruciaal onderdeel van het handhaven van QoS-doelen (Quality of Service). Bewakingsgegevens verzamelen voor de volgende veelvoorkomende scenario's:

• Zorg ervoor dat het systeem in orde blijft.

• Houd de beschikbaarheid van het systeem en de bijbehorende onderdelen bij.

• Behoud de prestaties om ervoor te zorgen dat de doorvoer van het systeem niet onverwacht afneemt naarmate het werkvolume toeneemt.

• Garantie dat het systeem voldoet aan serviceovereenkomsten (SLA's).

• Bescherm de privacy en beveiliging van het systeem, gebruikers en hun gegevens.

• Controle- of regelgevingsbewerkingen bijhouden.

• Bewaak het dagelijkse gebruik van het systeem en los trends op die tot problemen kunnen leiden.

• Houd problemen bij die zich voordoen, van het eerste rapport tot analyse van mogelijke oorzaken, correctie, software-updates en implementatie.

• Volg activiteiten en debug softwarereleases.

In de volgende secties worden deze scenario's gedetailleerder beschreven.

Gezondheidsmonitoring

Een gezond systeem draait en kan aanvragen verwerken. Gebruik statuscontrole om een momentopname te genereren van de huidige status van het systeem, zodat u kunt controleren of alle onderdelen werken zoals verwacht.

Waarschuwingen instellen

Het systeem moet binnen enkele seconden een waarschuwing genereren als een onderdeel niet in orde is. Waarschuwingen kunnen de systeemstatus markeren via verkeerslichtsignalen:

• Rood voor niet gezond (het systeem is gestopt)
• Geel voor gedeeltelijk gezond (het systeem wordt uitgevoerd met verminderde functionaliteit)
• Groen voor gezond

Een uitgebreid systeem voor statuscontrole toont u de status van elk subsysteem en onderdeel, zodat u kunt bepalen welke onderdelen normaal functioneren en welke onderdelen problemen ondervinden.

Gezondheidsgegevens verzamelen

De volgende bronnen kunnen de onbewerkte gegevens genereren die nodig zijn om statuscontrole te ondersteunen:

• Traceer de uitvoering van gebruikersaanvragen. U kunt deze informatie gebruiken om te bepalen welke aanvragen slagen of mislukken en om te meten hoe lang elke aanvraag duurt.

• Synthetische gebruikers bewaken. Dit proces simuleert de acties die een gebruiker uitvoert en volgt een vooraf gedefinieerde reeks stappen. Leg de resultaten van elke stap vast.

• Logboek uitzonderingen, fouten en waarschuwingen. U kunt deze informatie vastleggen uit traceringsinstructies die zijn ingesloten in de toepassingscode en uit de gebeurtenislogboeken van services waarnaar het systeem verwijst.

• Controleer de status van niet-Microsoft-services die het systeem gebruikt. Mogelijk moet u statusinformatie ophalen en parseren die door deze services wordt verstrekt.

• Eindpunten bewaken.

• Verzamel informatie over omgevingsprestaties, zoals cpu-gebruik op de achtergrond of I/O-bewerkingen (input/output), waaronder netwerkactiviteit.

Statusgegevens analyseren

De primaire focus van gezondheidsbewaking is snel aan te geven of het systeem draait. Dynamische analyse van directe gegevens kan een waarschuwing activeren als een kritiek onderdeel niet in orde is.

Een geavanceerder systeem kan een voorspellend element bevatten dat een koude analyse uitvoert ten opzichte van recente en huidige workloads. Een koude analyse kan trends identificeren en bepalen of het systeem waarschijnlijk in orde blijft of meer resources nodig heeft. Baseer dit voorspellende element op de volgende kritieke prestatiegegevens:

• Het aantal aanvragen dat is gericht op elke service of elk subsysteem
• De reactietijden van deze aanvragen
• Het volume aan gegevens dat van en naar elke service stroomt

Als de waarde van een metrische waarde een gedefinieerde drempelwaarde overschrijdt, kan het systeem een waarschuwing genereren om omhoog te schalen. U kunt ook resources toevoegen, mislukte services opnieuw opstarten of aanvragen met een lagere prioriteit beperken om de systeemstatus te behouden.

Beschikbaarheidsbewaking

In een gezond systeem zijn alle onderdelen en subsystemen beschikbaar. Beschikbaarheidsbewaking is nauw gerelateerd aan statuscontrole. Statuscontrole biedt een direct overzicht van de huidige status van het systeem. Beschikbaarheidsbewaking houdt de beschikbaarheid van het systeem en de bijbehorende onderdelen bij om statistieken over uptime te genereren.

In veel systemen worden sommige onderdelen, zoals databases, geconfigureerd met ingebouwde redundantie om snelle failover mogelijk te maken als er een ernstige fout of verlies van connectiviteit optreedt. Verzamel zoveel mogelijk informatie over deze fouten om de oorzaak te bepalen en corrigerende acties uit te voeren om terugkeerpatroon te voorkomen.

De gegevens die nodig zijn om de beschikbaarheid bij te houden, zijn mogelijk afhankelijk van meerdere factoren op lager niveau die specifiek zijn voor de toepassing, het systeem en de omgeving. Een effectief bewakingssysteem legt de beschikbaarheidsgegevens vast die overeenkomen met deze factoren op laag niveau en aggregeren ze vervolgens om een algemeen beeld van het systeem te bieden. In een e-commercesysteem kan de bedrijfsfunctionaliteit waarmee een klant orders kan plaatsen bijvoorbeeld afhankelijk zijn van de opslagplaats waarin ordergegevens worden opgeslagen en het betalingssysteem waarmee monetaire transacties worden verwerkt. De beschikbaarheid van de functie voor orderplaatsing is afhankelijk van de beschikbaarheid van de opslagplaats en het betalingssubsysteem.

De oplossing voor beschikbaarheidsbewaking biedt actuele en historische weergaven van de beschikbaarheidsstatus van elk subsysteem. Er wordt snel een waarschuwing weergegeven wanneer een of meer services mislukken of wanneer gebruikers geen verbinding kunnen maken met services. Gebruik deze informatie om trends te identificeren die ertoe kunnen leiden dat subsystemen mislukken. U kunt bijvoorbeeld beschikbaarheidsgegevens gebruiken om te detecteren welke services mislukken tijdens piekuren.

Beschikbaarheidsgegevens verzamelen

Bewaak synthetische gebruikers, logboek uitzonderingen, fouten en waarschuwingen en bewaak eindpunten om de onbewerkte gegevens te genereren die nodig zijn om beschikbaarheidsbewaking te ondersteunen. De toepassing kan een of meer health-eindpunten blootleggen die elk de toegang tot een functioneel onderdeel binnen het systeem testen. Het bewakingssysteem volgt een gedefinieerd schema om elk eindpunt te pingen en de resultaten te verzamelen, zoals geslaagd of mislukt.

Noteer alle time-outs, netwerkverbindingsfouten en pogingen tot opnieuw proberen van de verbinding en tijdstempel van alle gegevens.

Beschikbaarheidsgegevens analyseren

Aggregeren en correleren van de gegevens ter ondersteuning van de volgende typen analyse:

• De onmiddellijke beschikbaarheid van het systeem en de subsystemen.

• De beschikbaarheidsfoutpercentages van het systeem en de subsystemen. Correleert fouten met specifieke activiteiten om inzicht te hebben in de oorzaken van systeemfouten.

• Een historisch overzicht van foutpercentages gedurende een opgegeven periode en de belasting van het systeem, zoals het aantal gebruikersaanvragen, wanneer er een fout optreedt.

• De redenen voor niet-beschikbaarheid van het systeem of de subsystemen. Deze redenen omvatten onder meer dat de service niet wordt uitgevoerd, dat de verbinding is verbroken, time-outs of reacties met foutcodes.

U kunt de beschikbaarheidspercentages van een service gedurende een bepaalde periode berekenen met behulp van de volgende formule:

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

Gebruik deze formule voor SLA-bewaking. De definitie van downtime is afhankelijk van de service. De Azure DevOps buildservice definieert bijvoorbeeld downtime als de periode, in het totale aantal geaccumuleerde minuten, waarin de buildservice niet beschikbaar is. De service wordt één minuut als niet beschikbaar beschouwd als alle continue HTTP-aanvragen tijdens die minuut resulteren in een foutcode of geen antwoord retourneren.

Prestatiebewaking

Naarmate het volume van gebruikers toeneemt, neemt de grootte van de gegevenssets die gebruikers openen toe en wordt de kans op fouten van een of meer onderdelen waarschijnlijker. Prestatievermindering treedt vaak op voordat onderdeelfouten optreden. Als u degradatie kunt detecteren, kunt u proactieve stappen ondernemen om fouten te voorkomen.

Systeemprestaties zijn afhankelijk van meerdere factoren. Doorgaans meet u elke factor via KPI's (Key Performance Indicators), zoals het aantal databasetransacties per seconde of het aantal netwerkaanvragen dat in een opgegeven tijdsbestek is verwerkt. Sommige van deze KPI's zijn mogelijk beschikbaar als specifieke prestatiemetingen, terwijl andere KPI's kunnen worden afgeleid van een combinatie van metrische gegevens.

Vereisten voor prestatiebewaking

Voor het evalueren van systeemprestaties hebt u doorgaans de volgende informatie nodig:

• De responspercentages voor gebruikersaanvragen
• Het aantal gelijktijdige gebruikersaanvragen
• Het volume van netwerkverkeer
• De tarieven waarmee het systeem zakelijke transacties voltooit
• De gemiddelde verwerkingstijd voor aanvragen

Gebruik hulpprogramma's waarmee u de volgende correlaties kunt identificeren:

• Het aantal gelijktijdige gebruikers versus latentietijden van aanvragen of hoe lang het duurt om een aanvraag te verwerken nadat de gebruiker deze heeft verzonden

• Het aantal gelijktijdige gebruikers versus de gemiddelde reactietijd, of hoe lang het duurt om een aanvraag te voltooien nadat de verwerking is gestart

• Het aantal aanvragen versus het aantal verwerkingsfouten

Samen met deze functionele informatie op hoog niveau krijgt u een gedetailleerde weergave van de prestaties voor elk onderdeel in het systeem. Prestatiemeteritems op laag niveau bieden deze gegevens doorgaans. Ze volgen de volgende informatie:

• Geheugengebruik
• Aantal threads
• CPU-verwerkingstijd
• Lengte van aanvraagwachtrij
• I/O-frequenties en fouten van schijf of netwerk
• Aantal bytes geschreven of gelezen
• Middleware-indicatoren, zoals de lengte van de wachtrij

Met alle visualisaties kunt u een periode opgeven. De weergegeven gegevens kunnen een momentopname zijn van de huidige situatie of een historisch overzicht van de prestaties. Het systeem moet waarschuwingen genereren op basis van elke prestatiemeting voor een opgegeven waarde tijdens een opgegeven tijdsinterval.

Prestatiegegevens verzamelen

Verzamel prestatiegegevens op hoog niveau, zoals doorvoer, het aantal gelijktijdige gebruikers, het aantal zakelijke transacties en foutpercentages door de voortgang van aanvragen van gebruikers te controleren. Traceringsinstructies en tijdsinformatie opnemen op belangrijke punten in de toepassingscode. Leg alle fouten, uitzonderingen en waarschuwingen vast met voldoende gegevens en correleert deze met de aanvragen die ze hebben veroorzaakt.

Leg, indien mogelijk, prestatiegegevens vast voor externe systemen die door de toepassing worden gebruikt. Deze externe systemen bieden mogelijk hun eigen prestatiemeteritems of andere functies voor het aanvragen van prestatiegegevens. Als deze methode niet mogelijk is, registreert u informatie zoals de begin- en eindtijd van elke aanvraag naar een extern systeem en de geslaagde, mislukte of waarschuwingsstatus van de bewerking.

Prestatiegegevens op laag niveau voor afzonderlijke onderdelen in een systeem zijn mogelijk beschikbaar via functies en services zoals Windows prestatiemeteritems die de Azure Monitor Agent verzamelt.

Prestatiegegevens analyseren

De meeste analyse voegt prestatiegegevens samen op gebruikersaanvraagtype of op het subsysteem of de service waarnaar elke aanvraag wordt verzonden. Een voorbeeld van een gebruikersaanvraag is het toevoegen van een item aan een winkelwagen of het afrekenproces in een e-commercesysteem.

Een andere algemene vereiste is het samenvatten van prestatiegegevens in percentielen. U kunt bijvoorbeeld de reactietijden voor 99% aanvragen, 95% aanvragen en 70% aanvragen bepalen. U kunt SLA-doelen of andere doelen instellen voor elk percentiel. Rapporteer doorlopende resultaten in bijna realtime om problemen onmiddellijk te helpen detecteren. Voeg resultaten in de loop van de tijd samen voor statistische doeleinden.

Latentieproblemen kunnen ook van invloed zijn op de prestaties. Als u snel de oorzaak van knelpunten wilt identificeren, evalueert u de latentie van elke stap die door elke aanvraag wordt uitgevoerd. De prestatiegegevens moeten een manier bieden om prestatiemetrieken te correleren voor elke stap om deze te koppelen aan een specifieke aanvraag.

Afhankelijk van uw visualisatievereisten kan het handig zijn om een gegevenskubus te genereren en op te slaan die weergaven van de onbewerkte gegevens bevat. Deze gegevenskubus kan complexe, ongeplande query's en analyse van prestatiegegevens toestaan.

Controleren van beveiliging

Alle commerciële systemen met gevoelige gegevens moeten een beveiligingsstructuur implementeren. De gevoeligheid van de gegevens bepaalt doorgaans hoe complex het beveiligingsmechanisme is. Noteer de volgende informatie in een systeem waarvoor gebruikers moeten worden geverifieerd:

• Alle aanmeldingspogingen en of ze mislukken of slagen

• Alle bewerkingen die worden uitgevoerd door een geverifieerde gebruiker en de details van alle resources waartoe ze toegang hebben

• Wanneer een gebruiker een sessie beëindigt en zich afmeldt

Bewaking kan helpen bij het detecteren van aanvallen op het systeem. Een aantal mislukte aanmeldingspogingen kan bijvoorbeeld duiden op een brute-force-aanval. Een onverwachte piek in aanvragen kan het gevolg zijn van een DDoS-aanval. Wees voorbereid om alle aanvragen voor alle resources te bewaken, ongeacht de bron. Een systeem met een beveiligingsprobleem met aanmelding kan per ongeluk resources beschikbaar maken zonder dat een gebruiker zich hoeft aan te melden.

Vereisten voor beveiligingsbewaking

De gegevens die door beveiligingsbewaking worden vastgelegd, kunnen u helpen:

• Detecteer pogingen tot inbraak door een niet-geverifieerde entiteit.

• Identificeer pogingen van entiteiten om bewerkingen uit te voeren op gegevens waartoe ze geen toegang hebben.

• Bepaal of een niet-geverifieerde gebruiker of een kwaadwillende geverifieerde gebruiker probeert het systeem aan te vallen.

Ter ondersteuning van deze taken moet het systeem waarschuwingen verzenden als:

• Eén account maakt herhaalde mislukte aanmeldingspogingen binnen een opgegeven periode.

• Eén geverifieerd account probeert herhaaldelijk toegang te krijgen tot een verboden resource gedurende een opgegeven periode.

• Een groot aantal niet-geverifieerde of niet-geautoriseerde aanvragen vindt plaats tijdens een opgegeven periode.

Stel waarschuwingen in om het hostadres van de bron voor elke aanvraag op te nemen. Als er regelmatig beveiligingsschendingen optreden vanuit een specifiek adresbereik, kunt u deze hosts blokkeren.

Een belangrijk onderdeel van het onderhouden van de beveiliging van een systeem is de mogelijkheid om snel acties te detecteren die afwijken van het gebruikelijke patroon. U kunt informatie zoals het aantal mislukte of geslaagde aanmeldingsaanvragen visueel weergeven om pieken in activiteit op ongebruikelijke momenten te detecteren. U kunt deze informatie ook gebruiken om automatisch schalen op basis van tijd in te stellen. Als u bijvoorbeeld ziet dat veel gebruikers zich regelmatig op een bepaald moment aanmelden, kunt u extra verificatieservices starten om het werkvolume af te handelen. Sluit deze services af nadat de piek is verstreken.

Beveiligingsgegevens verzamelen

Beveiliging is een allesomvattend aspect van de meeste gedistribueerde systemen en bewaking genereert relevante gegevens op meerdere punten in het hele systeem. Gebruik een SIEM-benadering (Security Information and Event Management) om informatie te verzamelen die het gevolg is van gebeurtenissen die zijn gegenereerd door de toepassing, netwerkapparatuur, servers, firewalls, antivirussoftware en andere elementen voor inbraakpreventie.

Beveiligingsbewaking kan gegevens van hulpprogramma's buiten uw toepassing bevatten. Deze hulpprogramma's omvatten hulpprogramma's waarmee activiteiten voor poortscans door externe instanties en netwerkfilters worden geïdentificeerd die pogingen detecteren om niet-geverifieerde toegang te krijgen tot uw toepassing en gegevens. In sommige gevallen vormen hulpprogramma's voor continue integratie en continue levering (CI/CD) een belangrijk onderdeel van de levenscyclus van de toepassing. Deze hulpprogramma's moeten ook afwijkend gedrag markeren.

Beveiligingsgegevens analyseren

Een belangrijke functie van beveiligingsbewaking is dat er gegevens uit veel bronnen worden verzameld. De verschillende indelingen en detailniveaus vereisen vaak complexe analyses om de gegevens samen te stellen in een coherente thread met informatie. U kunt mislukte aanmeldingen of herhaalde pogingen detecteren om onbevoegde toegang te krijgen tot resources, maar complexe geautomatiseerde verwerking van beveiligingsgegevens is mogelijk niet haalbaar. In dit scenario moet u de gegevens een tijdstempel geven en naar een beveiligde opslagplaats schrijven in de oorspronkelijke vorm voor handmatige analyse van experts.

SLA-bewaking

Commerciële systemen die klanten ondersteunen, doen toezeggingen over systeemprestaties in de vorm van SLA's. SLA's geven aan dat het systeem binnen een overeengekomen tijdsbestek een gedefinieerd volume aan werk kan verwerken en zonder kritieke informatie te verliezen. SLA-bewaking zorgt ervoor dat het systeem voldoet aan meetbare SLA's.

Met de volgende metrische gegevens worden SLA's gedefinieerd:

• Algemene beschikbaarheid van het systeem. Een organisatie kan zich bijvoorbeeld ertoe verbinden dat het systeem 99,9% van de tijd beschikbaar is. Dit percentage is gelijk aan maximaal negen uur downtime per jaar of ongeveer 10 minuten per week.

• Verwerkingssnelheid. Dit aspect wordt vaak uitgedrukt als een of meer hoogwatermarkeringen, zoals een toezegging die het systeem kan ondersteunen tot 100.000 gelijktijdige gebruikersaanvragen of 10.000 gelijktijdige zakelijke transacties kan verwerken.

• Operationele reactietijd. Het systeem moet mogelijk ook aanvragen verwerken met een gedefinieerd tarief. 99% van alle zakelijke transacties moet bijvoorbeeld binnen 2 seconden worden voltooid en er duurt geen enkele transactie langer dan 10 seconden.

Vereisten voor SLA-bewaking

U moet snel kunnen bepalen of het systeem voldoet aan een SLA. Als deze niet voldoet aan de SLA, moet u de onderliggende factoren evalueren om de oorzaak van de ondermaatse prestaties te vinden.

U kunt de volgende indicatoren op hoog niveau visueel weergeven:

• Het uptimepercentage van de service

• De doorvoer van de toepassing, gemeten in termen van geslaagde transacties of bewerkingen per seconde

• Het aantal geslaagde of mislukte toepassingsaanvragen

• Het aantal toepassings- en systeemfouten, uitzonderingen en waarschuwingen

Zorg ervoor dat u al deze indicatoren kunt filteren op een opgegeven periode.

Uw cloudtoepassing bestaat waarschijnlijk uit meerdere subsystemen en onderdelen. U moet een indicator op hoog niveau kunnen selecteren, zoals de algehele uptime van het systeem en bepalen welke onderliggende elementen van invloed zijn op de status ervan.

Voor waarschuwingsdoeleinden moet het systeem een gebeurtenis genereren als een van de indicatoren op hoog niveau een opgegeven drempelwaarde overschrijdt. Maak de details op een lager niveau beschikbaar voor het waarschuwingssysteem als contextuele gegevens.

SLA-gegevens verzamelen

Voer de volgende acties uit om de onbewerkte gegevens vast te leggen die vereist zijn voor SLA-bewaking:

• Eindpuntbewaking uitvoeren.
• Logboek uitzonderingen, fouten en waarschuwingen.
• Traceer de uitvoering van gebruikersaanvragen.
• Bewaak de beschikbaarheid van alle niet-Microsoft-services die door het systeem worden gebruikt.
• Prestatiegegevens en tellers gebruiken.

Alle gegevens moeten getimed en gestempeld worden.

SLA-gegevens analyseren

Aggregeren de SLA-gegevens om een beeld te genereren van de algehele prestaties van het systeem. U moet ook geaggregeerde gegevens kunnen inzoomen om onderliggende subsystemen te evalueren. U moet bijvoorbeeld de volgende taken kunnen uitvoeren:

• Bereken het totale aantal gebruikersaanvragen gedurende een opgegeven periode en bepaal het succes- en foutpercentage van deze aanvragen.

• Combineer de reactietijden van gebruikersaanvragen om een algemene weergave van de reactietijden van het systeem te genereren.

• Analyseer de voortgang van gebruikersaanvragen om de totale reactietijd op te splitsen in de reactietijden van afzonderlijke werkitems in de aanvraag.

• Bepaal de algehele beschikbaarheid van het systeem als een percentage uptime voor een specifieke periode.

• Analyseer de beschikbaarheidspercentages van de afzonderlijke onderdelen en services in het systeem. Mogelijk moet u logboeken parseren die niet Microsoft-services genereren.

Commerciële systemen moeten werkelijke prestatiecijfers rapporteren ten opzichte van SLA's gedurende een bepaalde periode. U kunt deze informatie gebruiken om tegoeden of andere vormen van terugbetalingen voor klanten te berekenen als u gedurende die periode niet aan SLA's voldoet. U kunt de beschikbaarheid voor een service berekenen met behulp van de techniek die wordt beschreven in Beschikbaarheidsgegevens analyseren.

Voor interne doeleinden kan een organisatie ook het aantal en de aard van incidenten bijhouden waardoor services mislukken. Leer hoe u deze problemen snel kunt oplossen of elimineren, zodat u downtime kunt verminderen en aan SLA's kunt voldoen.

Auditing

Afhankelijk van de aard van de toepassing kunnen wettelijke voorschriften vereisten opgeven voor het controleren van de bewerkingen van gebruikers en het vastleggen van alle gegevenstoegang. Controle kan bewijs leveren waarmee klanten worden gekoppeld aan specifieke aanvragen. Nonrepudiation is een belangrijke factor in elektronische bedrijfssystemen om vertrouwen te behouden tussen een klant en de organisatie die verantwoordelijk is voor de toepassing of service.

Vereisten voor controle

U moet de volgorde van bedrijfsactiviteiten kunnen traceren die gebruikers uitvoeren, zodat u de acties van gebruikers kunt reconstrueren. Deze record kan nodig zijn voor documentatiedoeleinden of als onderdeel van een forensisch onderzoek.

Controlegegevens zijn zeer gevoelig. Het bevat waarschijnlijk gegevens die systeemgebruikers en de taken identificeren die ze uitvoeren. Daarom is controlegegevens waarschijnlijk alleen beschikbaar voor vertrouwde analisten, in plaats van als onderdeel van een interactief systeem. De analist genereert een reeks rapporten zoals de volgende voorbeelden:

• Rapporten met alle activiteiten van alle gebruikers gedurende een opgegeven tijdsbestek

• Rapporten die de chronologie van de activiteit voor één gebruiker beschrijven

• Rapporten met een lijst van de volgorde van bewerkingen die worden uitgevoerd op een of meer resources

Controlegegevens verzamelen

De primaire informatiebronnen voor controle zijn onder andere:

• Het beveiligingssysteem waarmee gebruikersverificatie wordt beheerd.
• Tracelogboeken die gebruikersactiviteit registreren.
• Beveiligingslogboeken die alle identificeerbare en niet-identificeerbare netwerkaanvragen bijhouden.

Wettelijke vereisten kunnen de indeling van de controlegegevens bepalen en hoe u deze opslaat. Als u volgens regelgeving de gegevens in de oorspronkelijke indeling moet vastleggen, kunt u de gegevens mogelijk niet opschonen. Als gevolg hiervan moet de toegang tot de opslagplaats waarin deze wordt opgeslagen, nauw worden beveiligd om manipulatie te voorkomen.

Controlegegevens analyseren

U moet toegang hebben tot onbewerkte gegevens in zijn geheel en in de oorspronkelijke vorm. Afgezien van de vereiste voor het genereren van algemene controlerapporten, zijn de hulpprogramma's voor het analyseren van deze gegevens waarschijnlijk gespecialiseerd en worden ze buiten het systeem bewaard.

Gebruik bijhouden

Met gebruikscontrole wordt bijgehouden hoe klanten de functies en onderdelen van een toepassing gebruiken. U kunt de gegevens gebruiken om het volgende te doen:

• Identificeer populaire functies en potentiële hotspots in het systeem. Elementen met veel verkeer kunnen baat hebben bij functionele partitionering of replicatie om de belasting gelijkmatiger te verdelen. U kunt deze informatie ook gebruiken om te bepalen welke functies niet vaak worden gebruikt en mogelijke kandidaten zijn voor buitengebruikstelling of vervanging in een toekomstige versie van het systeem.

• Verkrijg informatie over de operationele gebeurtenissen van het systeem onder normaal gebruik. Op een e-commercesite kunt u bijvoorbeeld statistische informatie vastleggen over het aantal transacties en het aantal klanten dat voor hen verantwoordelijk is. U kunt deze informatie gebruiken voor capaciteitsplanning naarmate het aantal klanten groeit.

• Detecteer de tevredenheid van gebruikers met de prestaties en functionaliteit van het systeem. Als veel klanten in een e-commercesysteem bijvoorbeeld regelmatig hun winkelwagens verlaten, is er mogelijk een probleem met de kassafunctionaliteit.

• Factureringsgegevens genereren. Een commerciële toepassing of multitenant-service kan klanten kosten in rekening brengen voor de resources die ze gebruiken.

• Quota afdwingen. Als een gebruiker in een systeem met meerdere tenants het betaalde quotum voor verwerkingstijd of resourcegebruik gedurende een bepaalde periode overschrijdt, kunt u de toegang beperken of de verwerking beperken.

• Problemen met luidruchtige buren detecteren. Om foutonderzoeken of productbeslissingen te stimuleren, bepaalt u of verkeer gelijkmatig wordt verspreid of als een kleine set gebruikers het grootste deel van het verkeer genereert. Als één gebruiker aanzienlijk verkeer genereert, moet de functie mogelijk prestaties afstemmen. U kunt ook besluiten extra quota op te leggen om het verkeer te verminderen.

Vereisten voor gebruikscontrole

Als u het systeemgebruik wilt evalueren, hebt u doorgaans de volgende informatie nodig:

• Het aantal aanvragen dat elk subsysteem verwerkt en naar elke resource leidt

• Het werk dat elke gebruiker uitvoert

• Het volume aan gegevensopslag dat elke gebruiker in beslag neemt

• De resources waartoe elke gebruiker toegang heeft

U moet ook grafieken kunnen genereren. Veelvoorkomende voorbeelden zijn grafieken van gebruikers die de meeste resources en de meest gebruikte resources of systeemfuncties gebruiken.

Gebruiksgegevens verzamelen

U kunt het bijhouden van gebruik op hoog niveau uitvoeren door de begin- en eindtijden van elke aanvraag en de aard van elke aanvraag, zoals lezen of schrijven, te noteren. Ga als volgt te werk om deze informatie vast te leggen:

• Gebruikersactiviteit traceren.
• Leg prestatiemeteritems vast waarmee het gebruik voor elke resource wordt gemeten.
• Bewaak het resourceverbruik van elke gebruiker.

Voor metingdoeleinden moet u ook bepalen welke gebruikers welke bewerkingen en de resources die door deze bewerkingen worden gebruikt, uitvoeren. Zorg ervoor dat de informatie die u verzamelt gedetailleerd genoeg is om nauwkeurige facturering te ondersteunen.

Problemen bijhouden

Klanten en andere gebruikers kunnen problemen melden als er onverwachte gebeurtenissen of gedrag optreden in het systeem. Problemen bijhouden beheert deze problemen, koppelt problemen aan pogingen om ze op te lossen en informeert klanten over oplossingen.

Vereisten voor het bijhouden van problemen

Als u problemen wilt bijhouden, gebruikt u een afzonderlijk systeem waarmee u de details van problemen kunt vastleggen en rapporteren die gebruikers melden. Deze details omvatten de geprobeerde taken, symptomen van het probleem, de volgorde van gebeurtenissen en foutberichten of waarschuwingsberichten.

Gegevens voor het bijhouden van problemen verzamelen

De eerste gegevensbron voor gegevens over problemen bijhouden is de gebruiker die het probleem rapporteert. Deze gebruiker kan mogelijk de volgende gegevens opgeven:

• Een crashdump als de toepassing een onderdeel bevat dat wordt uitgevoerd op het bureaublad van de gebruiker

• Een momentopname van een scherm

• De datum en tijd waarop de fout is opgetreden en andere omgevingsinformatie, zoals de locatie van de gebruiker

Gebruik deze informatie om het systeem te debuggen en een backlog op te stellen voor toekomstige software-releases.

Gegevens van issuetracking analyseren

Verschillende gebruikers kunnen hetzelfde probleem melden en het systeem voor het bijhouden van problemen moet algemene rapporten koppelen.

Noteer de voortgang van de foutopsporing voor elk rapport. Wanneer u het probleem oplost, informeert u de klant over de oplossing.

Als een gebruiker een probleem meldt met een bekende oplossing in het systeem voor het bijhouden van problemen, kunt u de gebruiker onmiddellijk informeren over de oplossing.

Bewerkingen traceren en softwareversies debuggen

Wanneer een gebruiker een probleem rapporteert, is deze doorgaans alleen op de hoogte van het onmiddellijke effect dat het heeft op hun bewerkingen. De gebruiker kan alleen de resultaten van hun eigen ervaring rapporteren. Deze ervaringen zijn meestal een zichtbaar symptoom van een of meer fundamentele problemen. In veel gevallen moet een analist de chronologie van de onderliggende bewerkingen analyseren om de hoofdoorzaak van het probleem vast te stellen. Dit proces wordt hoofdoorzaakanalyse (RCA) genoemd.

Vereisten voor tracering en foutopsporing

Om onverwachte gebeurtenissen en andere problemen te traceren, moeten de bewakingsgegevens voldoende informatie verstrekken om een analist de oorsprong van het probleem te laten vinden en de volgorde van gebeurtenissen te reconstrueren. Vervolgens kan een ontwikkelaar wijzigingen aanbrengen om te voorkomen dat het probleem opnieuw optreedt.

Tracerings- en foutopsporingsgegevens verzamelen

Als u problemen wilt oplossen, traceert u alle methoden en de bijbehorende parameters die zijn aangeroepen als onderdeel van een bewerking. Maak vervolgens een structuur die de logische stroom door het systeem weergeeft wanneer een klant een specifieke aanvraag indient. Uitzonderingen en waarschuwingen vastleggen en registreren die door het systeem worden gegenereerd als gevolg van deze flow.

Ter ondersteuning van foutopsporing biedt het systeem hooks die u kunt gebruiken om statusinformatie vast te leggen op cruciale punten in het systeem. Of het systeem kan gedetailleerde stapsgewijze informatie leveren naarmate geselecteerde bewerkingen vorderen. Het vastleggen van gegevens op dit detailniveau kan de belasting van het systeem verhogen en moet een tijdelijk proces zijn. Gebruik dit proces wanneer ongebruikelijke en moeilijk te repliceren gebeurtenissen plaatsvinden of wanneer voor een nieuwe release zorgvuldige bewaking is vereist om ervoor te zorgen dat de elementen werken zoals verwacht.

De pijplijn voor bewaking en diagnose

Het bewaken van een grootschalig gedistribueerd systeem vormt een aanzienlijke uitdaging. U moet niet per se rekening houden met elk van de scenario's die in de vorige secties in isolatie worden beschreven. De bewakings- en diagnostische gegevens die vereist zijn voor elke situatie overlappen, maar mogelijk moet u deze gegevens op verschillende manieren verwerken en presenteren. Hanteer om deze redenen een holistische kijk op monitoring en diagnostiek.

U kunt zich het hele bewakings- en diagnoseproces voorstellen als een pijplijn die bestaat uit de fasen die in het volgende diagram worden weergegeven.

In het diagram ziet u hoe bewakings- en diagnostische gegevens afkomstig zijn van verschillende bronnen. De instrumentatie- en verzamelingsfasen helpen u bij het identificeren van de gegevens die u moet vastleggen, waar en hoe u deze vastlegt en hoe u de gegevens opmaken, zodat u deze eenvoudig kunt analyseren. De analyse- en diagnosefase neemt de onbewerkte gegevens en gebruikt deze om zinvolle informatie te genereren die u kunt gebruiken om de status van het systeem te bepalen. U kunt deze informatie gebruiken om te bepalen welke mogelijke acties moeten worden ondernomen en vervolgens de resultaten weer in de instrumentatie- en verzamelingsfasen te voeren. De visualisatie- en waarschuwingsfase geeft een bruikbare weergave van de systeemstatus weer. Het kan informatie bijna in realtime weergeven met behulp van een reeks dashboards. Het kan rapporten, grafieken en grafieken genereren om een historisch overzicht te bieden van de gegevens waarmee u trends op de lange termijn kunt identificeren. Als informatie aangeeft dat een KPI waarschijnlijk de acceptabele grenzen overschrijdt, kan deze fase ook een waarschuwing activeren. In sommige gevallen kan een waarschuwing ook een geautomatiseerd proces activeren dat probeert corrigerende acties uit te voeren, zoals automatisch schalen.

Deze stappen vormen een proces voor continue stroom waarin de fasen parallel worden uitgevoerd. In het ideale geval moeten alle fasen dynamisch worden geconfigureerd. Op sommige punten, met name wanneer een systeem nieuw is geïmplementeerd of problemen ondervindt, moet u mogelijk vaker uitgebreide gegevens verzamelen. Op andere momenten kunt u belangrijke informatie op hoog niveau blijven vastleggen om te controleren of het systeem goed functioneert.

Behandel het hele bewakingsproces als een live, doorlopende oplossing die op basis van feedback moet worden afgestemd en verbeterd. U kunt bijvoorbeeld beginnen met het meten van veel factoren om de systeemstatus te bepalen en uw analyse na verloop van tijd te verfijnen om metingen te negeren die niet relevant zijn.

Bronnen van bewaking en diagnostische gegevens

De informatie die door het bewakingsproces wordt gebruikt, kan afkomstig zijn uit verschillende bronnen. Op toepassingsniveau is informatie afkomstig van traceringslogboeken die u in de systeemcode opneemt. Ontwikkelaars moeten een standaardbenadering volgen voor het bijhouden van de controlestroom via hun code. Een vermelding naar een methode kan bijvoorbeeld een traceringsbericht verzenden dat de naam van de methode, de huidige tijd, de waarde van elke parameter en andere relevante informatie aangeeft. Mogelijk wilt u ook de invoer- en afsluittijden vastleggen.

Leg alle uitzonderingen en waarschuwingen vast en zorg ervoor dat u de volledige traceerinformatie van alle geneste uitzonderingen en waarschuwingen bewaart. Leg informatie vast die de gebruiker identificeert die de code- en activiteitcorrelatiegegevens uitvoert om aanvragen bij te houden wanneer ze het systeem passeren. Registreer pogingen om toegang te krijgen tot alle bronnen, zoals berichtenwachtrijen, databases, bestanden en andere afhankelijke diensten. U kunt deze informatie gebruiken voor meet- en controledoeleinden.

Veel toepassingen gebruiken bibliotheken en frameworks om algemene taken uit te voeren, zoals toegang tot een gegevensarchief of communicatie via een netwerk. U kunt deze frameworks mogelijk configureren om hun eigen traceringsberichten en onbewerkte diagnostische gegevens te bieden, zoals transactiesnelheden en geslaagde gegevensoverdrachten en fouten.

Het besturingssysteem waarop de toepassing wordt uitgevoerd, kan een bron zijn van informatie op laag niveau, systeembreed, zoals prestatiemeteritems die I/O-frequenties, geheugengebruik en CPU-gebruik aangeven. Het kan ook fouten van het besturingssysteem melden, zoals de fout om een bestand correct te openen.

Houd ook rekening met de onderliggende infrastructuur en onderdelen waarop uw systeem wordt uitgevoerd. Virtuele machines (VM's), virtuele netwerken en opslagservices kunnen allemaal bronnen zijn van belangrijke prestatiemeteritems op infrastructuurniveau en andere diagnostische gegevens.

Als uw toepassing gebruikmaakt van andere externe services, zoals een webserver of databasebeheersysteem (DBMS), kunnen deze services hun eigen traceringsgegevens, logboeken en prestatiemeteritems publiceren. Dynamische beheerweergaven (DMV's) in SQL Server houden bijvoorbeeld bewerkingen bij die op een SQL Server-database worden uitgevoerd. Application Insights traceert logboeken voor het vastleggen van aanvragen naar Azure App Service.

Wanneer u systeemonderdelen wijzigt en nieuwe versies implementeert, is het belangrijk dat u problemen, gebeurtenissen en metrische gegevens aan elke versie kunt toewijzen. Koppel deze informatie aan de release-pijplijn, zodat u snel problemen met een specifieke versie van een onderdeel kunt bijhouden en oplossen.

Gebruik de volgende strategieën om bewakings- en diagnostische gegevens te verzamelen:

• Toepassings- en systeembewaking maakt gebruik van interne bronnen binnen de toepassing, toepassingsframeworks, besturingssysteem en infrastructuur. De toepassingscode kan zijn eigen bewakingsgegevens genereren op belangrijke punten tijdens de levenscyclus van een clientaanvraag. De toepassing kan traceringsinstructies bevatten die u indien nodig kunt in- en uitschakelen. U kunt ook dynamisch diagnostische gegevens injecteren met behulp van een diagnostisch framework. Deze frameworks bieden doorgaans invoegtoepassingen die zijn gekoppeld aan verschillende instrumentatiepunten in uw code en traceringsgegevens vastleggen op deze punten.

  Uw code of de onderliggende infrastructuur kan ook gebeurtenissen genereren op kritieke punten. Bewakingsagents die zijn geconfigureerd om naar deze gebeurtenissen te luisteren, kunnen de gebeurtenisgegevens vastleggen.

• Echte gebruikersbewaking registreert de interacties tussen een gebruiker en de toepassing en bekijkt de stroom van elke aanvraag en reactie. Gebruik deze informatie om het gebruik van elke gebruiker te meten en te bepalen of gebruikers een geschikte QoS ontvangen, waaronder snelle reactietijden, lage latentie en minimale fouten. U kunt de gegevens gebruiken om gebieden te identificeren waar fouten het vaakst optreden. U kunt de gegevens ook gebruiken om gebieden te identificeren waar het systeem vertraagt vanwege hotspots in de toepassing of andere knelpunten. Als u deze aanpak zorgvuldig implementeert, kunt u mogelijk de stromen van gebruikers reconstrueren via de toepassing voor foutopsporing en testdoeleinden.

  Important

  Behandel gegevens die zijn vastgelegd door echte gebruikersbewaking als zeer gevoelig, omdat dit mogelijk vertrouwelijk materiaal bevat. Als u vastgelegde gegevens opslaat, slaat u deze veilig op. Als u de gegevens wilt gebruiken voor prestatiebewaking of foutopsporing, verwijdert u eerst alle persoonlijke gegevens.

• Synthetische gebruikersbewaking vereist dat u uw eigen testclient schrijft die een gebruiker simuleert en een configureerbare maar typische reeks bewerkingen uitvoert. U kunt de prestaties van de testclient bijhouden om de status van het systeem te bepalen. U kunt ook meerdere exemplaren van de testclient gebruiken als onderdeel van een belastingtestbewerking om te bepalen hoe het systeem reageert onder stress en de bewakingsuitvoer die door deze voorwaarden wordt gegenereerd.

  Note

  U kunt echte en synthetische gebruikersbewaking implementeren door code op te geven die de uitvoering van methodeaanroepen en andere kritieke onderdelen van een toepassing traceert en keert.

• Profilering helpt u bij het bewaken en verbeteren van de prestaties van toepassingen. In tegenstelling tot echte gebruikersbewaking en synthetische gebruikersbewaking, die op functioneel niveau werken, legt profilering informatie op lager niveau vast terwijl de toepassing wordt uitgevoerd. Implementeer profilering door periodiek een steekproef te nemen van de uitvoeringsstatus van een toepassing of door te bepalen welk stukje code de toepassing op een bepaald tijdstip uitvoert. U kunt ook instrumentatie gebruiken die sondes in de code invoegt op belangrijke punten, zoals aan het begin en einde van een methodeaanroep. De tests registreren welke methoden de aanroep heeft aangeroepen, op welk moment en hoe lang elke aanroep duurt. Vervolgens kunt u deze gegevens analyseren om te bepalen welke onderdelen van de toepassing prestatieproblemen kunnen veroorzaken.

• Eindpuntbewaking maakt gebruik van een of meer diagnostische eindpunten die de toepassing specifiek beschikbaar maakt om bewaking mogelijk te maken. Een eindpunt biedt een pad naar de toepassingscode en kan informatie retourneren over de status van het systeem. Verschillende eindpunten kunnen zich richten op verschillende aspecten van de functionaliteit. U kunt uw eigen diagnostische client schrijven die periodieke aanvragen naar deze eindpunten verzendt en de antwoorden assimileert. Zie het patroon voor bewaking van gezondheidseindpunten voor meer informatie.

• Gebruikersfoutdumps zijn afhankelijk van de toepassing om een manier te bieden om een momentopname van de toepassingsstatus te verzamelen als deze niet kan worden hersteld. Gebruikers moeten die momentopname ook vrijwillig delen. U kunt niet garanderen dat een foutdump wordt uitgevoerd, maar u kunt de gegevens op laag niveau gebruiken die het biedt om de hoofdoorzaak van fouten te bepalen. Dit scenario is gebruikelijk als de fouten niet regelmatig optreden of als er alleen fouten optreden in een niet-gebruikte toepassingsfunctie.

Voor maximale dekking moet u een combinatie van deze technieken gebruiken.

Een toepassing instrumenteer

Instrumentatie is een essentieel onderdeel van het bewakingsproces. U moet gegevens vastleggen waarmee u zinvolle beslissingen kunt nemen over de prestaties en status van uw systeem. Gebruik instrumentatie om voldoende informatie te verzamelen om de prestaties te beoordelen, problemen te diagnosticeren en beslissingen te nemen zonder u aan te melden op een productieserver op afstand om handmatig te traceren en te debuggen. Instrumentatiegegevens bestaan doorgaans uit metrische gegevens en informatie die naar traceringslogboeken wordt geschreven.

Een traceerlogboek kan tekstgegevens bevatten die door de toepassing worden geschreven of binaire gegevens die door een tracerings gebeurtenis worden gemaakt, als de toepassing gebeurtenistracering gebruikt voor Windows (ETW). Systeemlogboeken die gebeurtenissen registreren die zich voordoen vanuit onderdelen van de infrastructuur, zoals een webserver, kunnen ook traceringslogboekinhoud genereren. Tekstuele logboekberichten zijn vaak leesbaar voor mensen, maar schrijf ze in een indeling die een geautomatiseerd systeem ook eenvoudig kan parseren.

Categoriseer ook logboeken. Schrijf niet alle traceringsgegevens naar één logboek. Gebruik afzonderlijke logboeken om de traceringsuitvoer van verschillende operationele aspecten van het systeem vast te leggen. Vervolgens kunt u logboekberichten snel filteren door het desbetreffende logboek te lezen in plaats van één lang bestand te verwerken. Schrijf nooit gegevens met verschillende beveiligingsvereisten, zoals controlegegevens en foutopsporingsgegevens, naar hetzelfde logboek.

Metrische gegevens zijn over het algemeen een meting of telling van een bepaald aspect of resource in het systeem op een bepaald moment, met een of meer bijbehorende tags of dimensies, ook wel een voorbeeld genoemd. Eén exemplaar van een metrische waarde is niet nuttig in isolatie. Leg in plaats daarvan metrische gegevens vast in de loop van de tijd. Bedenk welke metrische gegevens moeten worden vastgelegd en hoe vaak. Het genereren van gegevens voor metrische gegevens kan te vaak te veel belasting op het systeem brengen. Maar als u niet genoeg gegevens vastlegt, loopt u mogelijk de omstandigheden mis die tot een significante gebeurtenis leiden. De overwegingen verschillen van metrische gegevens tot metrische gegevens. Het CPU-gebruik op een server kan bijvoorbeeld variëren van seconde tot seconde, maar een hoog gebruik wordt alleen een probleem als het enkele minuten blijft bestaan.

Informatie voor het correleren van gegevens

U kunt eenvoudig afzonderlijke prestatiemeteritems op systeemniveau bewaken, metrische gegevens voor resources vastleggen en toepassingstraceringsgegevens ophalen uit verschillende logboekbestanden. Voor sommige vormen van bewaking is echter de analyse- en diagnosefase in de bewakingspijplijn vereist om gegevens te correleren die zijn opgehaald uit verschillende bronnen. Deze onbewerkte gegevens kunnen verschillende vormen aannemen en het analyseproces moet over voldoende instrumenteringsgegevens beschikken om deze verschillende vormen in kaart te brengen. Op het niveau van het toepassingsframework kan een thread-id bijvoorbeeld een taak identificeren. Binnen een toepassing kan hetzelfde werk worden gekoppeld aan de gebruikers-id voor de gebruiker die die taak uitvoert.

Er bestaat waarschijnlijk geen een-op-een-toewijzing tussen threads en gebruikersaanvragen, omdat asynchrone bewerkingen dezelfde threads mogelijk opnieuw gebruiken om bewerkingen voor meer dan één gebruiker uit te voeren. Meerdere threads kunnen ook één aanvraag verwerken wanneer de uitvoering door het systeem loopt. Koppel indien mogelijk elke aanvraag aan een unieke activiteits-id die via het systeem is doorgegeven als onderdeel van de aanvraagcontext. De techniek voor het genereren en opnemen van activiteit-id's in traceringsgegevens is afhankelijk van de technologie die u gebruikt om de traceringsgegevens vast te leggen.

Voorzie alle monitoringgegevens op dezelfde manier van een tijdstempel. Noteer voor consistentie alle datums en tijden met behulp van UTC. Met deze methode kunt u eenvoudiger reeksen gebeurtenissen traceren.

Informatie die moet worden opgenomen in de instrumentatiegegevens

Houd rekening met de volgende punten wanneer u besluit welke instrumentatiegegevens moeten worden verzameld:

• Zorg ervoor dat informatie die is vastgelegd door traceringsgebeurtenissen, machineleesbaar en door mensen kan worden gelezen. Gebruik goed gedefinieerde schema's voor deze informatie om geautomatiseerde verwerking van logboekgegevens in systemen te vergemakkelijken en consistentie te bieden aan de operationele en technische medewerkers die de logboeken lezen. Neem omgevingsinformatie op, zoals de implementatieomgeving, de computer waarop het proces wordt uitgevoerd, de details van het proces en de aanroepstack.

• Schakel profilering alleen in wanneer dat nodig is, omdat dit aanzienlijke overhead aan het systeem kan toevoegen. Profilering met instrumentatie registreert een gebeurtenis, zoals een methodeaanroep, telkens wanneer deze plaatsvindt, terwijl bij steekproeven alleen geselecteerde gebeurtenissen worden geregistreerd. De selectie kan op tijd zijn gebaseerd, eenmaal per n seconden of op basis van frequentie, één keer per n aanvragen. Als gebeurtenissen vaak optreden, kan profilering door instrumentatie te veel last veroorzaken en de algehele prestaties beïnvloeden. In dit geval verdient de steekproefbenadering de voorkeur. Als de frequentie van gebeurtenissen echter laag is, kunnen steekproeven deze missen. In dit geval is instrumentatie misschien de betere aanpak.

• Geef voldoende context op zodat een ontwikkelaar of beheerder de bron van elke aanvraag kan bepalen. Deze context kan een activiteits-id bevatten die een specifiek exemplaar van een aanvraag of informatie identificeert die een activiteit correleert met het uitgevoerde rekenwerk en de gebruikte resources. Dit werk kan proces- en machinegrenzen overschrijden. Voor het meten moet de context ook rechtstreeks of indirect via andere gecorreleerde informatie een verwijzing bevatten naar de klant die de aanvraag indient. Deze context biedt waardevolle informatie over de toepassingsstatus wanneer u bewakingsgegevens vastlegt.

• Noteer alle aanvragen en de locaties of regio's van waaruit deze aanvragen worden gedaan. Met deze informatie kunt u bepalen of er locatiespecifieke hotspots bestaan. Het kan u ook helpen bepalen of u een toepassing of de gegevens die door deze toepassing worden gebruikt, opnieuw wilt partitioneren.

• Noteer en leg de details van uitzonderingen zorgvuldig vast. Kritieke foutopsporingsgegevens gaan vaak verloren als gevolg van slechte verwerking van uitzonderingen. Leg de volledige details vast van uitzonderingen die de toepassing genereert, inclusief eventuele interne uitzonderingen en andere contextinformatie. Neem indien mogelijk de aanroepstack op.

• Wees consistent in de gegevens die door de verschillende elementen van uw toepassing worden vastgelegd. Consistentie kan u helpen gebeurtenissen te analyseren en deze te correleren met gebruikersaanvragen. Overweeg het gebruik van een uitgebreid en configureerbaar logboekregistratiepakket om informatie te verzamelen, in plaats van afhankelijk van ontwikkelaars om dezelfde benadering te gebruiken als bij het implementeren van verschillende onderdelen van het systeem. Gegevens verzamelen uit belangrijke prestatiemeteritems, zoals I/O-volume, netwerkgebruik, aantal aanvragen, geheugengebruik en CPU-gebruik. Sommige infrastructuurservices bieden mogelijk hun eigen prestatiemeteritems, zoals het aantal verbindingen met een database, de snelheid waarmee het systeem transacties uitvoert en het aantal transacties dat slaagt of mislukt. Toepassingen kunnen ook hun eigen specifieke prestatiemeteritems definiëren.

• Registreer alle aanroepen naar externe services, zoals databasesystemen, webservices of andere services op systeemniveau die deel uitmaken van de infrastructuur. Noteer informatie over de tijd die nodig is om elke aanroep uit te voeren en of de aanroep slaagt of mislukt. Leg, indien mogelijk, informatie vast over alle nieuwe pogingen en fouten voor eventuele tijdelijke fouten die optreden.

Compatibiliteit met telemetriesystemen garanderen

In veel gevallen wordt de informatie die instrumentatie produceert gegenereerd als een reeks gebeurtenissen en doorgegeven aan een afzonderlijk telemetriesysteem voor verwerking en analyse. Een telemetriesysteem is doorgaans onafhankelijk van specifieke toepassingen of technologieën, maar verwacht dat informatie een specifieke indeling volgt die is gedefinieerd door een schema. Het schema geeft een contract op dat de gegevensvelden en typen definieert die het telemetriesysteem kan opnemen. Generaliseer het schema om gegevens van verschillende platforms en apparaten toe te staan. Een voorbeeld van een veelgebruikt framework en schema is OpenTelemetry.

Een algemeen schema moet velden bevatten die alle instrumentatie-gebeurtenissen gemeen hebben, zoals de gebeurtenisnaam, de gebeurtenistijd, het IP-adres van de afzender. Het moet ook de details bevatten die nodig zijn voor het correleren met andere gebeurtenissen, zoals een gebruikers-id, een apparaat-id en een toepassings-id. Houd er rekening mee dat een willekeurig aantal apparaten gebeurtenissen kan genereren, dus het schema mag niet afhankelijk zijn van het apparaattype. Daarnaast kunnen verschillende apparaten gebeurtenissen genereren voor dezelfde toepassing en kan de toepassing roaming of een andere vorm van distributie tussen apparaten ondersteunen.

Het schema kan ook domeinvelden bevatten die relevant zijn voor een bepaald scenario dat gebruikelijk is in verschillende toepassingen. Deze scenario's omvatten informatie over uitzonderingen, begin- en eindevenementen van toepassingen en succes of mislukking van API-aanroepen van webservices. Alle toepassingen die dezelfde set domeinvelden gebruiken, moeten dezelfde set gebeurtenissen verzenden om een set algemene rapporten en analyses te maken.

Ten slotte kan een schema aangepaste velden bevatten voor het vastleggen van de details van toepassingsspecifieke gebeurtenissen.

Best practices voor het instrumenteren van toepassingen

De volgende lijst bevat een overzicht van aanbevolen procedures voor het instrumenteren van een gedistribueerde toepassing die in de cloud wordt uitgevoerd:

• Maak logboeken gemakkelijk te lezen en te parseren. Gebruik waar mogelijk gestructureerde logboekregistratie. Beknopt en beschrijvend zijn in logboekberichten.

• Identificeer in alle logboeken de bron en geef context- en tijdsinformatie op wanneer elke logboekrecord wordt geschreven.

• Gebruik dezelfde tijdzone en notatie voor alle tijdstempels. Deze procedure helpt gebeurtenissen te correleren voor bewerkingen die betrekking hebben op hardware en services die worden uitgevoerd in verschillende geografische regio's.

• Categoriseer logboeken en schrijf berichten naar het juiste logboekbestand.

• Openbaar geen gevoelige informatie over het systeem of persoonlijke informatie over gebruikers. Verwijder gevoelige gegevens uit deze informatie voordat u deze registreert in een logbestand, maar zorg ervoor dat u de relevante details behoudt. Verwijder bijvoorbeeld de id en het wachtwoord uit databaseverbindingsreeksen. Schrijf de resterende informatie naar het logboek, zodat u kunt bepalen of het systeem toegang heeft tot de juiste database. Meld alle kritieke uitzonderingen aan, maar laat de beheerder logboekregistratie in- en uitschakelen voor lagere niveaus van uitzonderingen en waarschuwingen. Leg ook alle informatie over retry-logica vast en log deze. U kunt deze gegevens gebruiken om de tijdelijke status van het systeem te bewaken.

• Traceer out-of-process-aanroepen, zoals aanvragen voor externe webservices of databases.

• Combineer logboekberichten niet met verschillende beveiligingsvereisten in hetzelfde logboekbestand. Schrijf bijvoorbeeld geen foutopsporings- en controlegegevens naar hetzelfde logboek.

• Start logboekregistratie-aanroepen die autonoom blijven werken. Deze typen bewerkingen blokkeren de voortgang van bedrijfsactiviteiten niet. Controle-gebeurtenissen zijn een uitzondering omdat ze essentieel zijn voor het bedrijf. Classificeer ze als een fundamenteel onderdeel van bedrijfsactiviteiten.

• Zorg ervoor dat logboekregistratie uitbreidbaar is en geen directe afhankelijkheden heeft van een concreet doel. In plaats van informatie te schrijven met system.Diagnostics.Trace, definieert u bijvoorbeeld een abstracte interface, zoals ILogger, waarmee logboekregistratiemethoden beschikbaar worden gemaakt en die u op elke geschikte manier kunt implementeren.

• Zorg ervoor dat alle logging fail-safe is en nooit kettingfouten veroorzaakt. Logboekregistratie mag geen uitzonderingen veroorzaken.

• Behandel instrumentatie als een doorlopend iteratief proces en controleer logboeken regelmatig, niet alleen wanneer er een probleem optreedt.

Gegevens verzamelen en opslaan

De verzamelingsfase haalt de informatie op die door instrumentatie wordt gegenereerd, formatteert deze gegevens om het gemakkelijker te maken tijdens de analyse- en diagnosefase en slaat de getransformeerde gegevens op in betrouwbare opslag. U kunt de instrumentatiegegevens die u verzamelt uit verschillende delen van een gedistribueerd systeem opslaan in verschillende locaties en indelingen. Uw toepassingscode kan bijvoorbeeld traceringslogboekbestanden en toepassingslogboekgegevens genereren. Andere technologieën kunnen prestatiemeteritems vastleggen die belangrijke aspecten bewaken van de infrastructuur die uw toepassing gebruikt. Alle niet-Microsoft onderdelen en services die door uw toepassing worden gebruikt, kunnen instrumentatie-informatie in verschillende indelingen bieden met behulp van afzonderlijke traceringsbestanden, blobopslag of zelfs een aangepast gegevensarchief.

Een verzamelingsservice die autonoom wordt uitgevoerd vanuit de toepassing die de instrumentatiegegevens genereert, verzamelt doorgaans de gegevens. In het volgende diagram ziet u een voorbeeld van deze architectuur en wordt het subsysteem voor instrumentatiegegevensverzameling gemarkeerd.

In dit diagram ziet u een vereenvoudigde weergave van gegevensverzameling. De verzamelingsservice bestaat doorgaans uit veel onderdelen die op verschillende computers worden uitgevoerd. Als u telemetriegegevens snel wilt analyseren, gebruikt u lokale onderdelen die buiten de verzamelingsservice werken. Na analytische verwerking verzenden de onderdelen de resultaten rechtstreeks naar het subsysteem voor visualisaties en waarschuwingen. Gegevens die onderhevig zijn aan warme of koude analyse, worden opgeslagen terwijl ze wachten op verwerking. Zie Ondersteuning voor dynamische, warme en koude analyses voor meer informatie.

Voor Azure toepassingen en services die worden uitgevoerd op virtuele machines, biedt de Azure Monitor Agent een oplossing voor het vastleggen van gegevens. U definieert regels voor gegevensverzameling (DCR's) waarmee de gegevens worden opgegeven die moeten worden verzameld van elk rekenknooppunt en de Log Analytics werkruimte in Azure Monitor waarnaar u deze wilt verzenden. De agent kan gegevens verzamelen uit de volgende bronnen:

• IIS-logboeken (Internet Information Services)
• Windows-gebeurtenislogboeken
• Prestatiestatistieken
• Syslog van Linux-knooppunten
• Tekst- en JSON-logboeken die toepassingen schrijven

Strategieën voor het verzamelen van instrumentatiegegevens

Vanwege de elastische aard van de cloud en om te voorkomen dat telemetriegegevens handmatig worden opgehaald uit elk knooppunt in het systeem, moet u de gegevens samenvoegen en overdragen naar een centrale locatie. In een systeem dat meerdere datacenters omvat, wilt u mogelijk eerst gegevens verzamelen, samenvoegen en opslaan op basis van regio's en vervolgens de regionale gegevens samenvoegen in één centraal systeem.

Als u het bandbreedtegebruik wilt optimaliseren, kunt u minder urgente gegevens overdragen als batches. Vertraag de overdracht niet voor onbepaalde tijd, met name als de gegevens tijdgevoelige informatie bevatten.

Instrumentatiegegevens ophalen en verzenden

Het subsysteem voor het verzamelen van instrumentatiegegevens kan actief instrumentatiegegevens ophalen uit de verschillende logboeken en andere bronnen voor elk exemplaar van de toepassing. Deze methode wordt het pull-model genoemd. Het kan ook fungeren als een passieve ontvanger die wacht op de onderdelen die elk exemplaar van de toepassing vormen om de gegevens te verzenden. Deze methode wordt het pushmodel genoemd.

Een benadering van het pull-model is het gebruik van bewakingsagents die lokaal worden uitgevoerd met elk exemplaar van de toepassing. Een controleagent is een afzonderlijk proces dat periodiek telemetriegegevens ophaalt die op het lokale knooppunt worden verzameld en deze informatie wegschrijft naar een gecentraliseerde opslagvoorziening die door alle exemplaren van de toepassing wordt gedeeld. De Azure Monitor-agent implementeert dit mechanisme. U configureert de gegevens die van elk rekenproces moeten worden verzameld via een regel voor gegevensverzameling. De bewakingsagent die samen met elk exemplaar wordt uitgevoerd, verzamelt de opgegeven gegevens, zoals IIS-logboeken, Windows-gebeurtenislogboeken en prestatietellers, en stuurt deze naar een Log Analytics-werkruimte in Azure Monitor, waar u deze kunt doorzoeken en analyseren. In het volgende diagram ziet u een voorbeeld van deze architectuur.

U kunt de pull- en pushmodellen gebruiken om telemetriegegevens op te slaan voor een kleinschalige toepassing die wordt uitgevoerd op een beperkt aantal knooppunten op één locatie. Een complexe, uiterst schaalbare, wereldwijde cloudtoepassing kan enorme hoeveelheden gegevens genereren van honderden rekeninstanties, database-shards en andere services. Deze stroom aan gegevens kan de I/O-bandbreedte die beschikbaar is op één centrale locatie gemakkelijk overweldigen. Als gevolg hiervan moet u uw telemetrieoplossing kunnen schalen om een knelpunt te voorkomen wanneer het systeem uitbreidt. In het ideale geval moet uw oplossing een mate van redundantie bevatten om de risico's van het verliezen van belangrijke bewakingsgegevens, zoals controle- of factureringsgegevens, te verminderen als een deel van het systeem uitvalt.

Implementeer wachtrijen om deze problemen op te lossen. In de volgende voorbeeldarchitectuur plaatst de lokale bewakingsagent of aangepaste service voor gegevensverzameling gegevens in een wachtrij. De opslagschrijfservice, een afzonderlijk asynchroon proces, haalt de gegevens uit deze wachtrij en schrijft die weg naar gedeelde opslag. Een berichtenwachtrij is geschikt voor dit scenario, omdat deze ten minste één keer semantiek biedt die ervoor zorgt dat in de wachtrij geplaatste gegevens niet verloren gaan nadat deze zijn gepost. U kunt de opslagschrijfservice implementeren met behulp van een afzonderlijk achtergrondproces.

De service voor het verzamelen van lokale gegevens kan direct na ontvangst gegevens toevoegen aan een wachtrij. De wachtrij fungeert als buffer en de opslagschrijfservice kan de gegevens in een eigen tempo ophalen en schrijven. Een wachtrij werkt standaard op basis van first-in, first-out. U kunt echter prioriteit geven aan berichten om ze via de wachtrij te versnellen als ze gegevens bevatten die u snel moet afhandelen. Zie het patroon Prioriteitswachtrij voor meer informatie. U kunt ook verschillende kanalen, zoals Service Bus onderwerpen, gebruiken om gegevens naar verschillende bestemmingen te leiden, afhankelijk van de vorm van analytische verwerking die is vereist.

Voor schaalbaarheid kunt u meerdere exemplaren van de opslagschrijfservice uitvoeren. Voor grote hoeveelheden gebeurtenissen kunt u een Event Hub gebruiken om de gegevens naar verschillende rekenresources te verzenden voor verwerking en opslag.

Instrumentatiegegevens samenvoegen

De instrumentatiegegevens die door de service voor gegevensverzameling worden opgehaald uit één exemplaar van een toepassing, geven een gelokaliseerde weergave van de status en prestaties van dat exemplaar. Om de algehele status van het systeem te beoordelen, voegt u aspecten van de gegevens in de lokale weergaven samen. U kunt deze stap uitvoeren nadat de gegevens zijn opgeslagen, maar in sommige gevallen kunt u dit ook doen wanneer de gegevens worden verzameld. In plaats van rechtstreeks naar gedeelde opslag te schrijven, worden de instrumentatiegegevens via een afzonderlijke service doorgegeven waarmee gegevens worden geconsolideerd, gefilterd en opgeschoond. Instrumentatiegegevens met dezelfde correlatie-informatie, zoals een activiteits-id, kunnen bijvoorbeeld worden samengevoegd. Een gebruiker kan een bedrijfsbewerking op één knooppunt starten en vervolgens worden overgedragen naar een ander knooppunt als het knooppunt mislukt of vanwege taakverdeling. Dit proces kan ook dubbele gegevens detecteren en verwijderen, wat mogelijk is als de telemetrieservice berichtenwachtrijen gebruikt om instrumentatiegegevens naar de opslag te pushen. In het volgende diagram ziet u een voorbeeld van deze structuur.

Instrumentatiegegevens opslaan

In de vorige secties ziet u een vereenvoudigde weergave van het opslaan van instrumentatiegegevens. In de praktijk moet u verschillende soorten informatie opslaan met behulp van de technologieën die aansluiten bij de manier waarop u deze wilt gebruiken.

Azure Blob Storage en Azure-tabelopslag hebben bijvoorbeeld vergelijkbare toegangspatronen, maar de bewerkingen die ze kunnen uitvoeren, zijn beperkt en de granulariteit van de gegevens die ze opslaan, varieert. Als u analytische bewerkingen moet uitvoeren of zoekmogelijkheden voor volledige tekst nodig hebt, moet u mogelijk gegevensopslag gebruiken die de volgende query- en gegevenstoegangsmogelijkheden biedt:

• Sla prestatiemeteritems op in een SQL-database om ongeplande analyse mogelijk te maken.
• Sla traceerlogboeken op in Azure Cosmos DB.
• Schrijf beveiligingsgegevens naar het Hadoop Distributed File System (HDFS).
• Sla informatie op waarvoor zoeken in volledige tekst is vereist met behulp van Elasticsearch, waarbij uitgebreide indexering wordt gebruikt om zoekopdrachten te versnellen.

In het volgende diagram ziet u hoe u een extra service kunt implementeren die de gegevens periodiek ophaalt uit gedeelde opslag, partities en filtert de gegevens op basis van het doel en deze vervolgens naar een geschikte set gegevensarchieven schrijft. U kunt deze functionaliteit ook opnemen in het samenvoegings- en opschoonproces en de gegevens rechtstreeks naar deze archieven schrijven terwijl deze worden opgehaald, in plaats van deze op te slaan in een tussenliggend gedeeld opslaggebied. Elke benadering heeft voor- en nadelen. Het implementeren van een afzonderlijke partitioneringsservice vermindert de belasting van de consolidatie- en opschoonservice. Ook kunt u zo nodig ten minste enkele gepartitioneerde gegevens opnieuw genereren, afhankelijk van hoeveel gegevens gedeelde opslag behouden blijft. Deze benadering verbruikt echter meer resources. Het kan ook de ontvangst van instrumentatiegegevens van elke toepassingsinstantie en de omzetting van deze gegevens in bruikbare informatie vertragen.

Mogelijk hebt u dezelfde instrumentatiegegevens nodig voor meer dan één doel. Prestatiemeteritems kunnen bijvoorbeeld een historisch overzicht bieden van systeemprestaties in de loop van de tijd. U kunt deze informatie combineren met andere gebruiksgegevens om klantfactureringsgegevens te genereren. In deze scenario's verzendt u dezelfde gegevens naar meer dan één bestemming, zoals een documentdatabase waarin factureringsgegevens en een multidimensionaal archief worden opgeslagen waarmee complexe prestatieanalyses worden verwerkt.

Bedenk hoe dringend u de gegevens nodig hebt. Gegevens die informatie bieden voor waarschuwingen, moeten snel worden geopend, dus u moet deze opslaan in snelle gegevensopslag en indexeren of structureren om waarschuwingssysteemquery's te optimaliseren. In sommige gevallen moet de telemetrieservice die de gegevens op elk knooppunt verzamelt mogelijk gegevens lokaal opmaken en opslaan, zodat een lokaal exemplaar van het waarschuwingssysteem u snel op de hoogte kan stellen van problemen. U kunt dezelfde gegevens verzenden naar de opslagschrijfservice die in de vorige diagrammen centraal wordt weergegeven en opgeslagen als u deze nodig hebt voor andere doeleinden.

Informatie die u gebruikt voor complexere analyse, voor rapportage en om historische trends te identificeren, is minder urgent. Sla deze op een manier op die ondersteuning biedt voor gegevensanalyse en ongeplande query's. Zie Ondersteuning voor dynamische, warme en koude analyses voor meer informatie.

Logboekrotatie en gegevensretentie

Met instrumentatie worden veel gegevens gegenereerd. In sommige gevallen kunt u, nadat de gegevens zijn verwerkt en overgedragen, de oorspronkelijke onbewerkte brongegevens uit elk knooppunt verwijderen. Of misschien moet u de onbewerkte gegevens opslaan.

Prestatiegegevens hebben doorgaans een langere levensduur, zodat u deze kunt gebruiken om prestatietrends te identificeren en capaciteit te plannen. Houd de geconsolideerde weergave van deze gegevens online voor een eindige periode, zodat u deze snel kunt openen. Mogelijk moet u gegevens die zijn verzameld voor meting en facturering voor onbepaalde tijd opslaan. Voor wettelijke vereisten moet u mogelijk ook gegevens archiveren en opslaan die zijn verzameld voor controle- en beveiligingsdoeleinden. Versleutel of beveilig deze gevoelige gegevens op een andere manier om manipulatie te voorkomen. Noteer nooit de wachtwoorden van gebruikers of andere persoonlijke gegevens. Verwijder deze gegevens uit de data voordat u die opslaat.

Gegevens omlaag nemen

Sla historische gegevens op om trends op lange termijn te herkennen. In plaats van alle oude gegevens op te slaan, kunt u de gegevens omlaag nemen om de resolutie te verminderen en opslagkosten te besparen. In plaats van prestatie-indicatoren per minuut op te slaan, kunt u bijvoorbeeld gegevens samenvoegen die meer dan een maand oud zijn om een uur-per-uurweergave te vormen.

Aanbevolen procedures voor het verzamelen en opslaan van logboekgegevens

De volgende lijst bevat een overzicht van aanbevolen procedures voor het vastleggen en opslaan van logboekgegevens:

• De bewakingsagent of gegevensverzamelingsservice moet worden uitgevoerd als een niet-processervice en kan eenvoudig worden geïmplementeerd.

• Alle uitvoer van de monitoringagent of gegevensverzamelingsservice moet opgeslagen zijn in een platformonafhankelijk formaat dat losstaat van de computer, het besturingssysteem of het netwerkprotocol. U kunt bijvoorbeeld informatie verzenden in een zelfbeschrijfde indeling, zoals JSON-, MessagePack- of Protobuf-bestanden in plaats van ETL-bestanden (Event Trace Log) in Linux of ETW. Gebruik een standaardindeling zodat het systeem verwerkingspijplijnen kan maken. U kunt eenvoudig onderdelen integreren die gegevens lezen, transformeren en verzenden in de overeengekomen indeling.

• Het bewakings- en gegevensverzamelingsproces moet fail-safe zijn en mag geen trapsgewijze fouten activeren.

• Als een tijdelijke fout informatie naar een gegevenssink verzendt, moet de bewakingsagent of gegevensverzamelingsservice worden voorbereid om telemetriegegevens opnieuw te ordenen, zodat de nieuwste informatie eerst wordt verzonden. De bewakingsagent of gegevensverzamelingsservice kan ervoor kiezen om de oudere gegevens te verwijderen of lokaal op te slaan en later te verzenden om naar eigen goeddunken in te halen.

Gegevens analyseren en problemen vaststellen

Een belangrijk onderdeel van bewaking en diagnose is het analyseren van de verzamelde gegevens om een beeld te krijgen van de algehele status van het systeem. Definieer uw eigen KPI's en prestatiegegevens en leer hoe u de gegevens kunt structuren om te voldoen aan uw analysevereisten. Begrijpen hoe gegevens die zijn vastgelegd in verschillende metrische gegevens en logboekbestanden correleren, omdat deze informatie essentieel is voor het bijhouden van een reeks gebeurtenissen en het diagnosticeren van problemen.

De gegevens voor elk deel van het systeem worden doorgaans lokaal vastgelegd, maar vervolgens moet u deze combineren met gegevens die zijn gegenereerd op andere sites die deelnemen aan het systeem. Correleert deze informatie zorgvuldig om ervoor te zorgen dat gegevens nauwkeurig worden gecombineerd. De gebruiksgegevens voor een bewerking kunnen bijvoorbeeld de volgende knooppunten omvatten:

• Een knooppunt dat als host fungeert voor een website waarmee een gebruiker verbinding maakt
• Een knooppunt waarop een afzonderlijke service wordt uitgevoerd die wordt geopend als onderdeel van deze bewerking
• Een knooppunt waarin gegevensopslag wordt opgeslagen

U moet deze informatie aan elkaar koppelen om een algemeen overzicht te geven van het resource- en verwerkingsgebruik voor de bewerking. Het knooppunt dat de gegevens vastlegt, kan deze vooraf verwerken en filteren, maar centrale knooppunten aggregeren en formatteren de gegevens doorgaans. Zie Instrumentatiegegevens samenvoegen voor meer informatie.

Ondersteuning voor dynamische, warme en koude analyse

Het analyseren en opnieuw opmaken van gegevens voor visualisatie-, rapportage- en waarschuwingsdoeleinden kan een complex proces zijn dat een eigen set resources verbruikt. Sommige vormen van bewaking vereisen dat directe gegevensanalyse effectief is, ook wel dynamische analyse genoemd. Voorbeelden hiervan zijn analyse voor waarschuwingen en beveiligingsbewaking. Voor hot-analyse maakt u gegevens beschikbaar en structureert u deze voor efficiënte verwerking. In sommige gevallen moet u de analyseverwerking mogelijk verplaatsen naar de afzonderlijke knooppunten die de gegevens bevatten.

Andere vormen van analyse zijn minder tijdgevoelig en vereisen mogelijk berekeningen en aggregatie nadat de onbewerkte gegevens zijn ontvangen. Deze methode wordt warme analyse genoemd. Prestatieanalyse valt vaak in deze categorie. In dit geval kan een plotselinge piek of storing een geïsoleerde, enkele prestatiegebeurtenis veroorzaken die niet statistisch significant is. De gegevens uit een reeks gebeurtenissen bieden een betrouwbaarder beeld van systeemprestaties.

U kunt ook warme analyse gebruiken om statusproblemen te diagnosticeren. Gebruik dynamische analyse om een status gebeurtenis te verwerken en onmiddellijk een waarschuwing te genereren. Gebruik vervolgens warm analysis om de gegevens te analyseren en de oorzaak van het gezondheidsincident te achterhalen.

Sommige soorten bewaking genereren meer langetermijngegevens. U kunt deze analyse op een later tijdstip uitvoeren, mogelijk volgens een vooraf gedefinieerd schema. In sommige gevallen moet de analyse mogelijk grote hoeveelheden gegevens filteren die in de loop van de tijd zijn vastgelegd. Deze methode wordt koude analyse genoemd. De belangrijkste vereiste is dat u de gegevens veilig opslaat nadat u deze hebt vastgelegd. Voor gebruiksbewaking en -controle is bijvoorbeeld regelmatig een nauwkeurig beeld van de systeemstatus vereist, maar deze statusinformatie hoeft niet onmiddellijk beschikbaar te zijn voor verwerking.

U kunt ook koude analyses gebruiken om de gegevens te leveren voor voorspellende statusanalyse. Verzamel historische informatie over een opgegeven periode en combineer deze met de huidige statusgegevens om trends te zien die statusproblemen kunnen veroorzaken. In dergelijke gevallen moet u mogelijk een waarschuwing genereren om de trend te corrigeren.

Gegevens correleren

De gegevens die door instrumentatie worden vastgelegd, kunnen een momentopname van de systeemstatus bieden, maar het doel van analyse is om deze gegevens actie te laten ondernemen. U kunt bijvoorbeeld de oorzaak van intensief I/O-laden op systeemniveau op een bepaald tijdstip bepalen en ervoor zorgen dat reactietijden van de database, het aantal transacties per seconde en reactietijden van toepassingen op hetzelfde moment uw bevindingen bevestigen.

Een manier om de belasting te verminderen, is door de gegevens via meer servers te sharden. Uitzonderingen kunnen optreden vanwege een fout op elk niveau van het systeem. Een uitzondering op één niveau activeert vaak een andere fout op het niveau erboven.

Om deze redenen moet u de verschillende soorten bewakingsgegevens op elk niveau correleren om een algemeen overzicht te maken van de systeemstatus en de toepassingen die erop worden uitgevoerd. Gebruik deze informatie om te bepalen of het systeem acceptabel functioneert en bepaal wat u kunt doen om de kwaliteit te verbeteren.

Zorg ervoor dat de onbewerkte instrumentatiegegevens voldoende context- en activiteits-id-informatie bevatten ter ondersteuning van de vereiste aggregaties voor het correleren van gebeurtenissen. Deze gegevens kunnen in verschillende indelingen worden opgeslagen, dus mogelijk moet u deze parseren en converteren naar een gestandaardiseerde indeling voor analyse. Zie Informatie over het correleren van gegevens voor meer informatie.

Problemen oplossen en diagnosticeren

Als u problemen wilt diagnosticeren, moet u RCA uitvoeren om de oorzaak van fouten of onverwacht gedrag te bepalen. Doorgaans hebt u de volgende informatie nodig voor het hele systeem of voor een specifiek subsysteem tijdens een opgegeven tijdvenster:

• Gedetailleerde informatie uit gebeurtenislogboeken en traceringen
• Volledige stacktraces van uitzonderingen en storingen van elk opgegeven niveau
• Crashdumps voor mislukte processen
• Activiteitenlogboeken die de bewerkingen vastleggen die alle gebruikers uitvoeren of gebruikers selecteren

Als u gegevens wilt analyseren voor probleemoplossingsdoeleinden, hebt u een grondige technische kennis van de systeemarchitectuur en de bijbehorende onderdelen nodig. U moet de gegevens interpreteren, de oorzaak van problemen vaststellen en een strategie aanbevelen om deze te corrigeren. Een andere strategie is om een kopie van deze informatie op te slaan in de oorspronkelijke indeling en deze beschikbaar te maken voor koude analyse door een expert.

Gegevens visualiseren en waarschuwingen genereren

Bewakingssystemen moeten gegevens presenteren, zodat u snel trends of problemen kunt identificeren. Ze moeten u ook onmiddellijk op de hoogte stellen wanneer een gebeurtenis waarvoor aandacht is vereist, plaatsvindt.

Gegevenspresentatie kan verschillende vormen aannemen, waaronder visualisatie met behulp van dashboards, waarschuwingen en rapportage.

Visualisatie met behulp van dashboards

De meest voorkomende manier om gegevens te visualiseren, is door dashboards te gebruiken die informatie weergeven als een reeks grafieken, grafieken of andere illustraties. U kunt deze items parameteriseren en de belangrijke parameters, zoals de periode, selecteren voor een specifieke situatie.

U kunt dashboards hiërarchisch organiseren. Dashboards op het hoogste niveau geven een algemeen overzicht van elk aspect van het systeem en laten u inzoomen op de details. In een dashboard met de totale schijf-I/O voor het systeem kunt u bijvoorbeeld de I/O-tarieven voor elke afzonderlijke schijf bekijken om te bepalen of een of meer specifieke apparaten een onevenredig volume aan verkeer hebben. Het dashboard moet ook gerelateerde informatie weergeven, zoals de gebruiker of activiteit die deze I/O genereert. Met deze informatie kunt u de belasting gelijkmatiger verdelen over apparaten.

Een dashboard kan ook kleurcodering of andere visuele aanwijzingen gebruiken om waarden aan te geven die afwijkend lijken of die buiten een verwacht bereik vallen. Bekijk de volgende kleurencoderingsvoorbeelden:

• Rood voor een schijf met een I/O-snelheid die de maximale capaciteit nadert gedurende een langere periode, of een hot disk

• Geel voor een schijf met een I/O-snelheid die periodiek gedurende korte perioden de maximumlimiet bereikt, of een warme schijf

• Groen voor een schijf die normaal gebruik vertoont

Dashboardsystemen moeten de onbewerkte gegevens hebben om effectief te kunnen werken. Als u uw eigen dashboardsysteem bouwt of een dashboard gebruikt dat is ontwikkeld door een andere organisatie, moet u begrijpen welke instrumentatiegegevens u moet verzamelen, op welke granulariteitsniveaus en hoe u het kunt opmaken voor het dashboard dat moet worden gebruikt.

Met een effectief dashboard kunt u ook vragen stellen over informatie. Sommige systemen bieden beheerhulpprogramma's die u kunt gebruiken om deze taken uit te voeren en de onderliggende gegevens te verkennen. Afhankelijk van de opslagplaats die de informatie bevat, kunt u gegevens mogelijk rechtstreeks opvragen of importeren in hulpprogramma's zoals Excel voor verdere analyse en rapportage.

Waarschuwingen genereren

Waarschuwingen analyseren de bewakings- en instrumentatiegegevens en genereren een melding als er een belangrijke gebeurtenis wordt gedetecteerd.

Waarschuwingen zorgen ervoor dat het systeem in orde, responsief en veilig blijft. Het is een belangrijk onderdeel van elk systeem dat garanties biedt voor prestaties, beschikbaarheid en privacy voor gebruikers. Waarschuwingen kunnen u ook waarschuwen over gebeurtenissen die waarschuwingen activeren. Gebruik waarschuwingen om systeemfuncties aan te roepen, zoals automatisch schalen.

Waarschuwingen zijn afhankelijk van de volgende instrumentatiegegevens:

• Beveiligingsevenementen: Als in de gebeurtenislogboeken wordt aangegeven dat herhaalde verificatie- of autorisatiefouten optreden. In dit scenario moet een waarschuwing u informeren dat het systeem mogelijk wordt aangevallen.

• Metrische prestatiegegevens: Het systeem moet snel reageren als een prestatiemetriek een opgegeven drempelwaarde overschrijdt.

• Beschikbaarheidsgegevens: Als er een fout wordt gedetecteerd, moet u mogelijk snel een of meer subsystemen opnieuw opstarten of een failover uitvoeren naar een back-upresource. Herhaalde fouten in een subsysteem kunnen ernstigere problemen aangeven.

U kunt waarschuwingsinformatie ontvangen via veel kanalen, zoals e-mail, een pager of een sms-sms-bericht. Een waarschuwing kan ook een indicatie bevatten van hoe kritiek een situatie is. Veel waarschuwingssystemen ondersteunen abonneegroepen en alle operators die lid zijn van dezelfde groep ontvangen dezelfde set waarschuwingen.

Maak het waarschuwingssysteem aanpasbaar en geef de juiste waarden op uit de onderliggende instrumentatiegegevens als parameters. Met deze methode kunt u gegevens filteren op specifieke drempelwaarden of combinaties van waarden. In sommige gevallen kunt u de onbewerkte instrumentatiegegevens aan het waarschuwingssysteem verstrekken. Het kan ook beter zijn om geaggregeerde gegevens op te geven. Een waarschuwing wordt bijvoorbeeld geactiveerd wanneer het CPU-gebruik voor een knooppunt langer is dan 90% in de afgelopen 10 minuten. Geef het waarschuwingssysteem de juiste samenvattings- en contextinformatie op om de mogelijkheid te verminderen dat fout-positieve gebeurtenissen een waarschuwing activeren.

Rapportage

Gebruik rapportage om een algemeen overzicht van het systeem te genereren. Het kan historische gegevens en huidige informatie bevatten. Rapportagevereisten vallen in operationele en beveiligingscategorieën.

Operationele rapportage omvat doorgaans de volgende aspecten voor het algehele systeem of specifieke subsystemen tijdens een opgegeven tijdvenster:

• Geaggregeerde statistieken die u kunt gebruiken om inzicht te verkrijgen in het resourcegebruik

• Trends in het gebruik van resources

• Uitzonderingsbewaking

• Toepassingsefficiëntie in termen van de geïmplementeerde resources en of u het volume van resources kunt verminderen zonder de prestaties te beïnvloeden

Met beveiligingsrapportage wordt bijgehouden hoe klanten het systeem gebruiken. Dit omvat doorgaans de volgende aspecten:

• Gebruikersbewerkingen controleren. Noteer afzonderlijke aanvragen die elke gebruiker samen met datums en tijden uitvoert. Structureer de gegevens zodat u snel de volgorde van bewerkingen kunt reconstrueren die een gebruiker gedurende een bepaalde periode uitvoert.

• Gebruik van resources voor elke gebruiker bijhouden. Noteer hoe elke aanvraag voor een gebruiker toegang heeft tot systeembronnen en hoe lang. Gebruik deze gegevens om een gebruiksrapport te genereren voor elke gebruiker gedurende een opgegeven periode, mogelijk voor factureringsdoeleinden.

In veel gevallen kunnen batchprocessen rapporten genereren volgens een ingesteld schema. Het genereren van rapporten verhoogt doorgaans geen latentie, dus u kunt zo nodig rapporten op aanvraag genereren. Als u gegevens opslaat in een relationele database, zoals Azure SQL Database, kunt u een hulpprogramma zoals SQL Server Reporting Services gebruiken om gegevens te extraheren en op te maken en te presenteren als een set rapporten.

Volgende stappen 

• Overzicht van Azure Monitor
• Opslag bewaken, diagnosticeren en problemen oplossen
• Overzicht van waarschuwingen in Azure
• Overzicht van Application Insights
• Prestatiediagnose voor Azure-VM's

Gerelateerde bronnen

• Richtlijnen voor automatisch schalen leggen uit hoe u de beheerlast kunt verlagen door minder vaak systeemprestaties te hoeven bewaken en beslissingen te nemen over het toevoegen of verwijderen van resources.

• Het patroon Statuseindpuntbewaking beschrijft hoe u functionele controles implementeert in een toepassing waartoe externe hulpprogramma's met regelmatige tussenpozen toegang hebben via weergegeven eindpunten.

• In het patroon Wachtrij met prioriteit wordt beschreven hoe u prioriteit geeft aan berichten in de wachtrij, zodat systemen urgente aanvragen ontvangen en verwerken voordat er minder urgente berichten worden verzonden.