Aanbevelingen voor het ontwerpen en maken van een bewakingssysteem

Van toepassing op deze aanbeveling voor de controlelijst voor operationele uitmuntendheid van Azure Well-Architected Framework:

OE:07 Ontwerp en implementeer een bewakingssysteem om ontwerpkeuzen te valideren en toekomstige ontwerp- en bedrijfsbeslissingen te informeren. Dit systeem legt operationele telemetrie, metrische gegevens en logboeken vast en maakt deze beschikbaar die afkomstig zijn van de infrastructuur en code van de workload.

Gerelateerde handleiding: Aanbevelingen voor het instrumenteren van een toepassing

In deze handleiding worden de aanbevelingen beschreven voor het ontwerpen en maken van een bewakingssysteem. Als u uw workload effectief wilt bewaken op beveiliging, prestaties en betrouwbaarheid, hebt u een uitgebreid systeem met een eigen stack nodig dat de basis vormt voor alle functies voor bewaking, detectie en waarschuwingen.

Definities

Termijn Definitie
Logboeken Opgenomen systeem gebeurtenissen. Logboeken kunnen verschillende typen gegevens bevatten in een gestructureerde of vrije tekstindeling. Ze bevatten een tijdstempel.
Metrische gegevens Numerieke waarden die regelmatig worden verzameld. Metrische gegevens beschrijven enkele aspecten van een systeem op een bepaald moment.

Belangrijke ontwerpstrategieën

Als u een uitgebreid bewakingssysteemontwerp voor uw workload wilt implementeren, volgt u deze kernbeginselen:

  • Wanneer dit praktisch is, kunt u gebruikmaken van de door het platform geleverde bewakingshulpprogramma's, die doorgaans zeer weinig configuratie vereisen en diepgaande inzichten kunnen bieden in uw workload die anders mogelijk moeilijk te realiseren zijn.

  • Verzamel logboeken en metrische gegevens van de volledige workloadstack. Alle infrastructuurresources en toepassingsfuncties moeten worden geconfigureerd om gestandaardiseerde, zinvolle gegevens te produceren en die gegevens moeten worden verzameld.

  • Sla de verzamelde gegevens op in een gestandaardiseerde, betrouwbare en veilige opslagoplossing.

  • Opgeslagen gegevens verwerken zodat deze kunnen worden verwerkt door analyse- en visualisatieoplossingen.

  • Analyseer verwerkte gegevens om de status van de workload nauwkeurig te bepalen.

  • Visualiseer de status van de workload in zinvolle dashboards of rapporten voor workloadteams en andere belanghebbenden.

  • Configureer bruikbare waarschuwingen en andere automatische reacties op intelligent gedefinieerde drempelwaarden om workloadteams op de hoogte te stellen wanneer zich problemen voordoen.

  • Neem bewakings- en waarschuwingssystemen op in uw algehele procedures voor het testen van workloads.

  • Zorg ervoor dat bewakings- en waarschuwingssystemen binnen het bereik van continue verbetering vallen. Gedrag van toepassingen en infrastructuur in productie biedt continue leermogelijkheden. Neem deze lessen op in ontwerpen voor bewaking en waarschuwingen.

  • Koppel de bewakingsgegevens die u verzamelt en analyseert terug aan uw systeem en gebruikersstromen om de status van de stromen te correleren met de gegevens, naast de algehele status van de workload. Als u deze gegevens analyseert in termen van de stromen, kunt u uw waarneembaarheidsstrategie afstemmen op uw statusmodel.

U moet alle functies van het bewakingssysteem zoveel mogelijk automatiseren en ze moeten allemaal continu, de hele dag en elke dag worden uitgevoerd.

Deze werkstroompijplijn illustreert het bewakingssysteem:

Diagram met de fasen van een uitgebreid bewakingssysteem als pijplijn.

Verzameling

Notitie

U moet uw toepassing instrumentatie toepassen om logboekregistratie in te schakelen. Zie de instrumentatiehandleiding voor meer informatie.

U moet alle workloadonderdelen configureren, of het nu infrastructuurresources of toepassingsfuncties zijn, om telemetrie en/of gebeurtenissen zoals logboeken en metrische gegevens vast te leggen.

Logboeken zijn vooral handig voor het detecteren en onderzoeken van afwijkingen. Logboeken worden doorgaans geproduceerd door het workloadonderdeel en vervolgens naar het bewakingsplatform verzonden of door het bewakingsplatform via automatisering opgehaald.

Metrische gegevens zijn voornamelijk nuttig voor het bouwen van een statusmodel en het identificeren van trends in prestaties en betrouwbaarheid van workloads. Metrische gegevens zijn ook handig voor het identificeren van trends in het gebruiksgedrag van uw klanten. Deze trends kunnen helpen bij het nemen van beslissingen over verbeteringen vanuit het perspectief van de klant. Normaal gesproken worden metrische gegevens gedefinieerd in het bewakingsplatform en het bewakingsplatform en andere hulpprogramma's peilen de workload om metrische gegevens vast te leggen.

Toepassingsgegevens

Voor toepassingen kan de verzamelservice een APM-hulpprogramma (Application Performance Management) zijn dat autonoom kan worden uitgevoerd vanuit de toepassing die de instrumentatiegegevens genereert. Nadat APM is ingeschakeld, hebt u duidelijk inzicht in belangrijke metrische gegevens, in realtime en historisch. Gebruik een geschikt logboekregistratieniveau. Uitgebreide logboekregistratie kan aanzienlijke kosten met zich meebrengen. Logboekniveaus instellen op basis van de omgeving. Lagere omgevingen hebben bijvoorbeeld niet hetzelfde uitgebreidheidsniveau nodig als productie.

Toepassingslogboeken ondersteunen de end-to-end levenscyclus van toepassingen. Logboekregistratie is essentieel om te begrijpen hoe de toepassing in verschillende omgevingen werkt, welke gebeurtenissen plaatsvinden en de omstandigheden waaronder ze plaatsvinden.

U wordt aangeraden toepassingslogboeken en -gebeurtenissen in alle belangrijke omgevingen te verzamelen. Scheid de gegevens zoveel mogelijk tussen omgevingen door verschillende gegevensarchieven voor elke omgeving te gebruiken, als dit praktisch is. Gebruik filters om ervoor te zorgen dat niet-kritieke omgevingen de interpretatie van productielogboeken niet bemoeilijken. Ten slotte moeten overeenkomende logboekvermeldingen in de toepassing een correlatie-id vastleggen voor hun respectieve transacties.

U moet toepassingsgebeurtenissen vastleggen in gestructureerde gegevenstypen met machineleesbare gegevenspunten in plaats van ongestructureerde tekenreekstypen. Een gestructureerde indeling die gebruikmaakt van een bekend schema kan het parseren en analyseren van logboeken vereenvoudigen. Gestructureerde gegevens kunnen ook eenvoudig worden geïndexeerd en doorzocht, en rapportage kan aanzienlijk worden vereenvoudigd.

Gegevens moeten een agnostische indeling hebben die onafhankelijk is van de computer, het besturingssysteem of het netwerkprotocol. Verzend bijvoorbeeld informatie in een zelfbeschrijvende indeling zoals JSON, MessagePack of Protobuf in plaats van ETL/ETW. Met een standaardindeling kan het systeem verwerkingspijplijnen maken. Onderdelen die gegevens in de standaardindeling lezen, transformeren en verzenden, kunnen eenvoudig worden geïntegreerd.

Infrastructuurgegevens

Voor infrastructuurresources in uw workload moet u ervoor zorgen dat u zowel logboeken als metrische gegevens verzamelt. Leg voor IaaS-systemen (Infrastructure as a Service) logboeken van het besturingssysteem, de toepassingslaag en diagnostische logboeken vast naast metrische gegevens met betrekking tot de workloadstatus. Voor PaaS-resources (Platform as a Service) bent u mogelijk beperkt in de mogelijkheid om logboeken vast te leggen die betrekking hebben op de onderliggende infrastructuur, maar zorg ervoor dat u diagnostische logboeken kunt vastleggen naast metrische gegevens met betrekking tot de workloadstatus.

Verzamel zoveel mogelijk logboeken van uw cloudplatform. U kunt mogelijk activiteitenlogboeken verzamelen voor uw abonnement en diagnostische logboeken voor het beheervlak.

Verzamelingsstrategieën

Vermijd het handmatig ophalen van telemetriegegevens uit elk onderdeel. Verplaats gegevens naar een centrale locatie en consolideert deze daar. Voor een oplossing voor meerdere regio's raden we u aan om eerst gegevens per regio te verzamelen, samen te voegen en op te slaan, en vervolgens de regionale gegevens samen te voegen in één centraal systeem.

Afweging: Houd er rekening mee dat er kosten verbonden zijn aan regionale en gecentraliseerde gegevensarchieven.

Als u het gebruik van bandbreedte wilt optimaliseren, moet u prioriteit geven op basis van het belang van gegevens. U kunt minder urgente gegevens in batches overdragen. Deze gegevens mogen echter niet voor onbepaalde tijd worden uitgesteld, met name als ze tijdgevoelige informatie bevatten.

Er zijn twee primaire modellen die de verzamelingsservice kan gebruiken om instrumentatiegegevens te verzamelen:

  • Pull-model: haalt actief gegevens op uit de verschillende logboeken en andere bronnen voor elk exemplaar van de toepassing.

  • Pushmodel: wacht passief tot de gegevens worden verzonden vanuit de onderdelen waaruit elk exemplaar van de toepassing bestaat.

Bewakingsagents

U kunt bewakingsagents gebruiken in het pull-model. Agents worden lokaal uitgevoerd in een afzonderlijk proces met elk exemplaar van de toepassing, waarbij periodiek gegevens worden opgehaald en de informatie rechtstreeks naar de algemene opslag wordt geschreven die wordt gedeeld door alle exemplaren van de toepassing.

Diagram met het gebruik van een bewakingsagent om informatie op te halen en naar gedeelde opslag te schrijven.

Notitie

Het gebruik van een bewakingsagent is ideaal voor het vastleggen van gegevens die natuurlijk worden opgehaald uit een gegevensbron. Dit is geschikt voor een kleinschalige toepassing die wordt uitgevoerd op een beperkt aantal knooppunten op één locatie. Voorbeelden hiervan zijn informatie uit SQL Server dynamische beheerweergaven of de lengte van een Azure Service Bus wachtrij.

Prestatieoverwegingen

Een complexe en zeer schaalbare toepassing kan enorme hoeveelheden gegevens genereren. De hoeveelheid gegevens kan gemakkelijk de I/O-bandbreedte overweldigen die beschikbaar is voor één centrale locatie. De telemetrieoplossing mag niet fungeren als knelpunt en moet schaalbaar zijn naarmate het systeem uitbreidt. In het ideale geval moet de oplossing een mate van redundantie bevatten om het risico te beperken dat belangrijke bewakingsgegevens (zoals controle- of factureringsgegevens) verloren gaan als een deel van het systeem uitvalt.

Een manier om instrumentatiegegevens te bufferen, is door wachtrijen te gebruiken:

Diagram dat laat zien hoe u een wachtrij kunt gebruiken om instrumentatiegegevens te bufferen.

In deze architectuur plaatst de service voor gegevensverzameling gegevens in een wachtrij. Een berichtenwachtrij is geschikt omdat deze 'ten minste één keer' semantiek biedt die ervoor zorgt dat gegevens in de wachtrij niet verloren gaan nadat ze zijn gepost. U kunt de service voor het schrijven van opslag implementeren met behulp van een afzonderlijke werkrol. U kunt het patroon Priority Queue gebruiken om deze architectuur te implementeren.

Voor schaalbaarheid kunt u meerdere exemplaren van de service voor het schrijven van opslag uitvoeren. Als een groot aantal gebeurtenissen of een groot aantal gegevenspunten wordt bewaakt, kunt u Azure Event Hubs gebruiken om de gegevens naar een ander rekenproces te verzenden voor verwerking en opslag.

Consolidatiestrategieën

De gegevens die worden verzameld van één exemplaar van een toepassing, bieden een gelokaliseerde weergave van de status en prestaties van dat exemplaar. Als u de algehele status van het systeem wilt beoordelen, moet u enkele aspecten van de gegevens uit de lokale weergaven samenvoegen. U kunt dit doen nadat de gegevens zijn opgeslagen, maar in sommige gevallen kunt u dit doen terwijl de gegevens worden verzameld.

Diagram met een voorbeeld van het gebruik van een service om instrumentatiegegevens samen te voegen.

De instrumentatiegegevens kunnen worden doorgegeven via een afzonderlijke service voor gegevensconsolidatie die gegevens combineert en fungeert als een filter- en opschoonproces. U kunt bijvoorbeeld instrumentatiegegevens die dezelfde correlatie-informatie bevatten, zoals een activiteits-id, samenvoegen. (Een gebruiker kan een zakelijke bewerking op het ene knooppunt starten en vervolgens worden overgedragen naar een ander knooppunt als het eerste knooppunt mislukt of vanwege de configuratie van taakverdeling.) Dit proces kan ook gedupliceerde gegevens detecteren en verwijderen. (Er kan duplicatie optreden als de telemetrieservice berichtenwachtrijen gebruikt om instrumentatiegegevens naar de opslag te pushen.)

Storage

Wanneer u een opslagoplossing kiest, moet u rekening houden met het type gegevens, hoe deze worden gebruikt en hoe dringend deze nodig zijn.

Notitie

Gebruik afzonderlijke opslagoplossingen voor niet-productie- en productieomgevingen om ervoor te zorgen dat gegevens uit elke omgeving gemakkelijk te identificeren en te beheren zijn.

Opslagtechnologieën

Overweeg een polyglot persistentiebenadering, waarbij verschillende soorten informatie worden opgeslagen in technologieën die het meest geschikt zijn voor de manier waarop elk type waarschijnlijk wordt gebruikt.

Azure Blob Storage en Azure Table Storage zijn bijvoorbeeld op vergelijkbare manieren toegankelijk. Maar de bewerkingen die u op deze bewerkingen kunt uitvoeren, verschillen, evenals de granulariteit van de gegevens die ze bevatten. Als u meer analytische bewerkingen wilt uitvoeren of functies voor zoeken in volledige tekst van de gegevens nodig hebt, is het mogelijk beter om gegevensopslag te gebruiken met mogelijkheden die zijn geoptimaliseerd voor bepaalde typen query's en gegevenstoegang. Bijvoorbeeld:

  • Prestatiemeteritem-gegevens kunnen worden opgeslagen in een SQL database zodat ad hoc-analyse mogelijk is.

  • Het is wellicht beter om traceringslogboeken op te slaan in Azure Monitor-logboeken of Azure Data Explorer.

  • U kunt beveiligingsgegevens opslaan in een HDFS-oplossing.

Dezelfde instrumentatiegegevens zijn mogelijk vereist voor meer dan één doel. U kunt bijvoorbeeld prestatiemeteritems gebruiken om een historisch overzicht van de systeemprestaties in de loop van de tijd te bieden. Deze informatie kan worden gecombineerd met andere gebruiksgegevens voor het genereren van de factureringsgegevens voor de klant. In dergelijke situaties kunnen dezelfde gegevens naar meer dan één bestemming worden verzonden, zoals naar een documentdatabase die een langetermijnopslag kan zijn voor het opslaan van factureringsgegevens, en naar een multidimensionale opslag voor het afhandelen van complexe prestatieanalyses.

Zorg ervoor dat u functionaliteit inschakelt om de gegevens te beschermen tegen onbedoelde verwijdering, zoals resourcevergrendelingen en voorlopig verwijderen.

Zorg er ook voor dat u de toegang tot opslag beveiligt met behulp van op rollen gebaseerd toegangsbeheer om ervoor te zorgen dat alleen personen die toegang nodig hebben tot de gegevens, dit kunnen doen.

Consolidatieservice

U kunt een andere service implementeren die de gegevens periodiek ophaalt uit gedeelde opslag, partitioneert en filtert op basis van het doel, en schrijft deze vervolgens naar een geschikte set gegevensarchieven.

Diagram met een gegevenspartitioneringsservice die gegevens verplaatst naar een geschikt gegevensarchief op basis van het type.

Een alternatieve methode is het opnemen van deze functionaliteit in het proces voor consolidatie en opschonen en de gegevens rechtstreeks naar deze archieven te schrijven wanneer ze worden opgehaald, in plaats van ze op te slaan in een tussenliggende gedeelde opslagruimte.

Elke methode heeft zijn voordelen en nadelen. Het implementeren van een afzonderlijke partitioneringsservice vermindert de belasting van de consolidatie- en opschoningsservice en zorgt ervoor dat ten minste een deel van de gepartitioneerde gegevens indien nodig opnieuw kan worden gegenereerd (afhankelijk van de hoeveelheid gegevens die worden bewaard in de gedeelde opslag). Deze benadering verbruikt echter extra resources. Bovendien kan er een vertraging optreden tussen de ontvangst van gegevens van elke toepassingsinstantie en de conversie van deze gegevens in toepasbare informatie.

Overwegingen bij het uitvoeren van query's

Bedenk hoe dringend de gegevens nodig zijn. Gegevens die waarschuwingen genereren, moeten snel worden geopend, dus ze moeten worden opgeslagen in snelle gegevensopslag en worden geïndexeerd of gestructureerd om de query's te optimaliseren die door het waarschuwingssysteem worden uitgevoerd. In sommige gevallen kan het nodig zijn dat de verzamelingsservice gegevens lokaal opmaken en opslaan, zodat een lokaal exemplaar van het waarschuwingssysteem snel meldingen kan verzenden. Dezelfde gegevens kunnen worden verzonden naar de opslagschrijfservice die wordt weergegeven in de vorige diagrammen en centraal worden opgeslagen als dit ook voor andere doeleinden vereist is.

Overwegingen voor gegevensretentie

In sommige gevallen kunt u, nadat de gegevens zijn verwerkt en overgedragen, de oorspronkelijke onbewerkte brongegevens verwijderen die lokaal zijn opgeslagen. In andere gevallen kan het nodig of nuttig zijn om de onbewerkte informatie op te slaan. U wilt bijvoorbeeld gegevens die worden gegenereerd voor foutopsporing beschikbaar houden in de onbewerkte vorm, maar deze vervolgens snel verwijderen nadat eventuele fouten zijn opgelost.

Prestatiegegevens hebben vaak een langere levensduur, zodat u deze kunt gebruiken voor het herkennen van prestatietrends en voor capaciteitsplanning. De geconsolideerde weergave van deze gegevens wordt meestal voor een beperkte periode online opgeslagen voor snelle toegang. Daarna kunnen deze worden gearchiveerd of verwijderd.

Het is handig om historische gegevens op te slaan, zodat u ook op lange termijn trends kunt herkennen. In plaats van oude gegevens in zijn geheel op te slaan, kunt u mogelijk een down-sample uitvoeren van de gegevens 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 weergave per uur te vormen.

Gegevens verzameld voor het meten en facturering van klanten moeten mogelijk voor onbepaalde tijd worden opgeslagen. Daarnaast kunnen wettelijke vereisten dicteren dat gegevens die worden verzameld voor controle en beveiliging moeten worden gearchiveerd en opgeslagen. Deze gegevens zijn ook gevoelig en moeten mogelijk worden versleuteld of anders beveiligd om manipulatie te voorkomen. U mag nooit gebruikerswachtwoorden of andere gegevens vastleggen die kunnen worden gebruikt om identiteitsfraude te plegen. U moet deze gegevens uit de gegevens wissen voordat deze worden opgeslagen.

Om ervoor te zorgen dat u voldoet aan wet- en regelgeving, minimaliseert u de opslag van identificeerbare informatie. Als u identificeerbare informatie moet opslaan, moet u bij het ontwerpen van uw oplossing rekening houden met vereisten die personen in staat stellen om hun gegevens te verwijderen.

Analyse

Nadat u gegevens uit verschillende gegevensbronnen hebt verzameld, analyseert u deze om het algehele welzijn van het systeem te beoordelen. Voor deze analyse moet u een duidelijk beeld hebben van:

  • Gegevens structureren op basis van KPI's en metrische prestatiegegevens die u hebt gedefinieerd.

  • Het correleren van de gegevens die zijn vastgelegd in verschillende metrische gegevens en logboekbestanden. Deze correlatie is belangrijk wanneer u een reeks gebeurtenissen bijhoudt en kan u helpen bij het diagnosticeren van problemen.

In de meeste gevallen worden gegevens voor elk onderdeel van de architectuur lokaal vastgelegd en vervolgens nauwkeurig gecombineerd met gegevens die door andere onderdelen worden gegenereerd.

Een toepassing met drie lagen kan bijvoorbeeld het volgende hebben:

  • Een presentatielaag waarmee een gebruiker verbinding kan maken met een website.

  • Een middelste laag die als host fungeert voor een set microservices die bedrijfslogica verwerkt.

  • Een databaselaag waarin gegevens worden opgeslagen die zijn gekoppeld aan de bewerking.

De gebruiksgegevens voor één bedrijfsbewerking kunnen alle drie de lagen omvatten. Deze informatie moet worden gecorreleerd om een algemeen overzicht te geven van het resource- en verwerkingsgebruik voor de bewerking. De correlatie kan betrekking hebben op het voorverwerken en filteren van gegevens in de databaselaag. Op de middelste laag zijn aggregatie en opmaak veelvoorkomende taken.

Aanbevelingen

  • Logboeken op toepassingsniveau en resourceniveau correleren. Evalueer gegevens op beide niveaus om de detectie van problemen en de probleemoplossing van deze problemen te optimaliseren. U kunt de gegevens samenvoegen in één gegevenssink of gebruikmaken van methoden waarmee query's worden uitgevoerd op gebeurtenissen op beide niveaus. We raden een geïntegreerde oplossing aan, zoals Azure Log Analytics, om logboeken op toepassingsniveau en resourceniveau te aggregeren en op te vragen.

  • Definieer duidelijke retentietijden voor opslag voor koude analyse. We raden deze procedure aan om historische analyses gedurende een specifieke periode in te schakelen. Het kan u ook helpen de opslagkosten te beheersen. Implementeer processen die ervoor zorgen dat gegevens worden gearchiveerd in goedkopere opslag en gegevens aggregeren voor langetermijntrendanalyse.

  • Analyseer langetermijntrends om operationele problemen te voorspellen. Evalueer langetermijngegevens om operationele strategieën te vormen en ook om te voorspellen welke operationele problemen zich waarschijnlijk zullen voordoen en wanneer. U ziet bijvoorbeeld dat de gemiddelde reactietijden langzaam toenemen in de loop van de tijd en het maximale doel naderen.

Zie Bewakingsgegevens voor cloudtoepassingen analyseren voor gedetailleerde richtlijnen over deze aanbevelingen.

Visualisatie

Dashboards

De meest voorkomende manier om gegevens te visualiseren, is het gebruik van dashboards die informatie kunnen weergeven als een reeks grafieken of grafieken, of in een andere visuele vorm. Deze items kunnen worden geparameteriseerd en een analist kan de belangrijke parameters, zoals de periode, voor elke specifieke situatie selecteren.

Stem uw dashboards af op uw statusmodel , zodat ze aangeven wanneer de workload of onderdelen van de workload in orde, gedegradeerd of beschadigd zijn.

Een dashboardsysteem werkt alleen effectief als het zinvol is voor het workloadteam. Visualiseer informatie die betrekking heeft op de status van de workload en die ook kan worden uitgevoerd. Wanneer de workload of een onderdeel gedegradeerd of beschadigd is, moeten leden van het workloadteam eenvoudig kunnen bepalen waar het probleem in de workload vandaan komt en kunnen beginnen met corrigerende acties of onderzoeken. Omgekeerd kan het opnemen van informatie die niet kan worden uitgevoerd of die niet gerelateerd is aan de status van de workload het dashboard onnodig complex en frustrerend maken voor teamleden die achtergrondruis willen onderscheiden van bruikbare gegevens.

Mogelijk hebt u dashboards voor belanghebbenden of ontwikkelaars die zijn aangepast om alleen gegevens weer te geven over de workload die zij relevant vinden. Zorg ervoor dat het workloadteam begrijpt welke typen gegevenspunten andere teams willen zien en bekijkt een voorbeeld van de dashboards voordat ze worden gedeeld om de duidelijkheid te controleren. Het verstrekken van dashboards over uw workload voor belanghebbenden is een goede manier om hen op de hoogte te houden van de status van de workload, maar kan averechts werken als de belanghebbenden de gegevens die ze zien niet duidelijk begrijpen.

Een goed dashboard geeft niet alleen informatie weer. Het stelt een analist ook in staat om geïmproviseerde vragen te stellen over die informatie. Sommige systemen bieden beheerhulpprogramma's die een operator kan gebruiken om deze taken uit te voeren en de onderliggende gegevens te verkennen. Afhankelijk van de opslagplaats die wordt gebruikt voor de informatie, is het mogelijk om rechtstreeks een query uit te voeren op de gegevens of deze te importeren in hulpprogramma's zoals Excel voor verdere analyse en rapportage.

Notitie

Dashboardtoegang beperken tot geautoriseerd personeel. Informatie op dashboards kan commercieel gevoelig zijn. U moet ook de onderliggende gegevens beveiligen om te voorkomen dat gebruikers deze wijzigen.

Rapporten

Rapportage wordt gebruikt voor het genereren van een algemeen overzicht van het systeem. Het kan historische gegevens en huidige informatie bevatten. Rapportagevereisten zijn onderverdeeld in twee algemene categorieën: operationele rapportage en beveiligingsrapportage.

Operationele rapportage omvat doorgaans het volgende:

  • Statistische gegevens die u kunt gebruiken om inzicht te geven in het resourcegebruik van het algehele systeem of opgegeven subsystemen tijdens een opgegeven tijdvenster.

  • Het identificeren van trends in resourcegebruik voor het algehele systeem of opgegeven subsystemen tijdens een opgegeven periode.

  • Bewaken van uitzonderingen die zijn opgetreden in het systeem of in opgegeven subsystemen gedurende een opgegeven periode.

  • Het bepalen van de efficiëntie van de toepassing voor de geïmplementeerde resources en het bepalen of het volume van resources en de bijbehorende kosten kan worden verlaagd zonder de prestaties onnodig te beïnvloeden.

Met beveiligingsrapportage wordt het gebruik van het systeem door klanten bijgehouden. Dit is onder andere:

  • Controle van gebruikersbewerkingen. Deze taak vereist het vastleggen van de afzonderlijke aanvragen die elke gebruiker voltooit, samen met datums en tijden. De gegevens moeten zodanig zijn gestructureerd dat een beheerder snel de reeks bewerkingen kan reconstrueren die een gebruiker tijdens een opgegeven periode voltooit.

  • Gebruik van resources door de gebruiker bijhouden. Voor deze taak moet worden opgenomen hoe elke aanvraag van een gebruiker toegang heeft tot de verschillende resources waaruit het systeem bestaat en hoe lang. Een beheerder kan deze gegevens gebruiken om een gebruiksrapport per gebruiker te genereren voor een opgegeven periode, mogelijk voor facturering.

In veel gevallen kunnen batchprocessen rapporten genereren volgens een ingesteld schema. Latentie is normaal gesproken geen probleem. U moet ook batchprocessen hebben waarmee rapporten op spontane basis kunnen worden gegenereerd, indien nodig. Als u bijvoorbeeld 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 deze weer te geven als een set rapporten.

Waarschuwingen

Om ervoor te zorgen dat het systeem in orde, responsief en veilig blijft, stelt u waarschuwingen in zodat operators er tijdig op kunnen reageren. Een waarschuwing kan voldoende contextuele informatie bevatten om snel aan de slag te gaan met diagnostische activiteiten. Waarschuwingen kunnen worden gebruikt om herstelfuncties aan te roepen, zoals automatisch schalen of andere zelfherstelmechanismen. Waarschuwingen kunnen ook kostenbewustzijn mogelijk maken door inzicht te bieden in budgetten en limieten.

Aanbevelingen

  • Definieer een proces voor waarschuwingsreacties waarmee de verantwoordelijke eigenaren en acties worden geïdentificeerd.

  • Configureer waarschuwingen voor een goed gedefinieerd bereik (resourcetypen en resourcegroepen) en pas de uitgebreidheid aan om ruis te minimaliseren.

  • Gebruik een geautomatiseerde waarschuwingsoplossing, zoals Splunk of Azure Monitor, in plaats van dat mensen actief moeten zoeken naar problemen.

  • Waarschuwingen gebruiken om herstelprocessen operationeel te maken. Maak bijvoorbeeld automatisch tickets om problemen en oplossingen bij te houden.

  • Houd de status van uw cloudplatformservices in regio's bij, communicatie over storingen, geplande onderhoudsactiviteiten en andere statusadviezen.

Drempelwaarden

Waarschuwingen worden gegenereerd wanneer drempelwaarden worden overschreden, zoals gedetecteerd door uw bewakingssysteem. Zorg ervoor dat de drempelwaarden die u instelt u over het algemeen voldoende tijd geven om de benodigde wijzigingen in uw workload te implementeren om verslechtering of storingen te voorkomen. Stel bijvoorbeeld de drempelwaarde voor automatisch schalen in om het schalen te initiëren voordat een van de actieve systemen overweldigd raakt tot het punt van een verslechterde gebruikerservaring. Baseer de drempelwaarden die u toewijst op uw eerdere ervaring met het beheren van de infrastructuur en valideer deze door middel van de tests die u uitvoert als onderdeel van uw testprocedures.

Zie Een betrouwbare bewakings- en waarschuwingsstrategie ontwerpen voor gedetailleerde richtlijnen voor het gebruik van waarschuwingen en andere overwegingen.

Azure-facilitering

  • Azure Monitor is een uitgebreide bewakingsoplossing voor het verzamelen, analyseren en reageren op bewakingsgegevens van uw cloud- en on-premises omgevingen.

  • Log Analytics is een hulpprogramma in de Azure Portal dat u kunt gebruiken om logboekquery's te bewerken en uit te voeren op gegevens in de Log Analytics-werkruimte.

    Als u meerdere werkruimten gebruikt, raadpleegt u de handleiding voor log analytics-werkruimtearchitectuur voor best practices.

  • Application Insights is een uitbreiding van Azure Monitor. Het biedt APM-functies.

  • Azure Monitor Insights zijn geavanceerde analysehulpprogramma's voor specifieke Azure-technologieën (zoals VM's, app-services en containers). Deze hulpprogramma's maken deel uit van Azure Monitor en Log Analytics.

  • Azure Monitor voor SAP-oplossingen is een Azure-bewakingsprogramma voor SAP-landschappen die worden uitgevoerd in Azure.

  • Azure Policy kunt u helpen bij het afdwingen van organisatiestandaarden en het beoordelen van naleving op schaal.

  • Azure Monitor Baseline Alerts (AMBA) is een centrale opslagplaats van waarschuwingsdefinities die klanten en partners kunnen gebruiken om hun ervaring met waarneembaarheid te verbeteren door azure Monitor te gebruiken.

Controlelijst voor operationele uitmuntendheid

Raadpleeg de volledige set aanbevelingen.