Delen via


Aanbevelingen voor het ontwerpen en maken van een bewakingssysteem

Is van toepassing op deze controlelijst voor Azure Well-Architected Framework Operational Excellence:

OE:07 Ontwerp en implementeer een bewakingssysteem om ontwerpkeuzen te valideren en toekomstige ontwerp- en bedrijfsbeslissingen te informeren. Met dit systeem worden operationele telemetrie, metrische gegevens en logboeken vastgelegd en weergegeven die worden verzonden vanuit de infrastructuur en code van de workload.

Verwante 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 voor beveiliging, prestaties en betrouwbaarheid, hebt u een uitgebreid systeem nodig met een eigen stack die de basis biedt voor alle bewakings-, detectie- en waarschuwingsfuncties.

Definities

Termijn Definitie
Logboeken Opgenomen systeemevenementen. Logboeken kunnen verschillende typen gegevens bevatten in een gestructureerde of vrije tekstindeling. Ze bevatten een tijdstempel.
Metrische gegevens voor 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 kernten:

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

  • Verzamel logboeken en metrische gegevens van de hele 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 werkbelasting 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 er problemen optreden.

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

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

  • Koppel de bewakingsgegevens die u verzamelt en analyseert 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 die gegevens analyseert in termen van de stromen, kunt u uw strategie voor waarneembaarheid afstemmen op uw statusmodel.

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

Deze werkstroompijplijn illustreert het bewakingssysteem:

Diagram met de fasen van een uitgebreid bewakingssysteem als pijplijn.

Instrumentatiegegevens verzamelen

Notitie

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

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

Logboeken zijn voornamelijk handig voor het detecteren en onderzoeken van afwijkingen. Normaal gesproken worden logboeken geproduceerd door het workloadonderdeel en vervolgens verzonden naar het bewakingsplatform of opgehaald door het bewakingsplatform via automatisering.

Metrische gegevens zijn voornamelijk nuttig voor het bouwen van een statusmodel en het identificeren van trends in de 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 verzamelingsservice 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 niveau van logboekregistratie. Uitgebreide logboekregistratie kan aanzienlijke kosten met zich meebrengen. Stel logboekniveaus in op basis van de omgeving. Lagere omgevingen hebben bijvoorbeeld niet hetzelfde niveau van uitgebreidheid nodig als productie.

Toepassingslogboeken ondersteunen de end-to-end toepassingslevenscyclus. Logboekregistratie is essentieel om inzicht te krijgen in de werking van de toepassing in verschillende omgevingen, welke gebeurtenissen plaatsvinden en de omstandigheden waaronder deze zich voordoen.

U wordt aangeraden toepassingslogboeken en -gebeurtenissen te verzamelen in alle belangrijke omgevingen. Scheid de gegevens tussen omgevingen zoveel mogelijk 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 eenvoudiger maken. 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. U kunt bijvoorbeeld informatie verzenden in een zelfbeschrijfde 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) de logboeken van het besturingssysteem, de toepassingslaag en diagnostische logboeken vast naast metrische gegevens met betrekking tot de status van de werkbelasting. Voor PaaS-resources (Platform as a Service) kunt u mogelijk logboeken vastleggen die betrekking hebben op de onderliggende infrastructuur, maar zorg ervoor dat u diagnostische logboeken kunt vastleggen naast metrische gegevens met betrekking tot de status van de workload.

Verzamel zoveel mogelijk logboeken van uw cloudplatform. Mogelijk kunt u 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 voeg deze daar samen. Voor een oplossing voor meerdere regio's raden we u aan 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 kostengevolgen zijn voor het hebben van regionale en gecentraliseerde gegevensarchieven.

Als u het gebruik van bandbreedte wilt optimaliseren, geeft u prioriteit aan 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 deze tijdgevoelige informatie bevat.

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.

  • Push-model: wacht passief totdat de gegevens worden verzonden vanuit de onderdelen die elk exemplaar van de toepassing vormen.

Agents bewaken

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 gemeenschappelijke opslag worden 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. Het is geschikt voor een kleinschalige toepassing die wordt uitgevoerd op een beperkt aantal knooppunten op één locatie. Voorbeelden hiervan zijn informatie uit dynamische beheerweergaven van SQL Server 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 de beschikbare I/O-bandbreedte eenvoudig overweldigen voor één centrale locatie. De telemetrieoplossing mag niet fungeren als knelpunt en moet schaalbaar zijn wanneer het systeem wordt uitgebreid. In het ideale geval moet de 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.

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 semantiek 'ten minste één keer' biedt om ervoor te zorgen dat in de wachtrij geplaatste gegevens niet verloren gaan nadat deze zijn gepost. U kunt de opslagschrijfservice 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 opslagschrijfservice 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 consolideren. U kunt dit doen nadat de gegevens zijn opgeslagen, maar in sommige gevallen kunt u dit doen wanneer 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 amalgamate die dezelfde correlatie-informatie bevatten, zoals een activiteits-id. (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.) Met dit proces kunt u ook dubbele gegevens detecteren en verwijderen. (Duplicatie kan optreden als de telemetrieservice berichtenwachtrijen gebruikt om instrumentatiegegevens naar de opslag te pushen.)

Gegevens opslaan voor query's en analyses

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

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 persistence-benadering, waarbij verschillende soorten informatie worden opgeslagen in technologieën die het meest geschikt zijn voor de manier waarop elk type waarschijnlijk wordt gebruikt.

Zo worden Azure Blob Storage en Azure Table Storage op vergelijkbare manieren geopend. Maar de bewerkingen die u op deze bewerkingen kunt uitvoeren, verschillen, net zoals 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. Voorbeeld:

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

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

  • Mogelijk slaat u beveiligingsgegevens op 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 een documentdatabase die een langetermijnopslag kan zijn voor het opslaan van factureringsgegevens en naar een multidimensionaal archief voor het verwerken 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, partities en filtert deze op basis van het doel en deze vervolgens naar een geschikte set gegevensarchieven schrijft.

Diagram met een gegevenspartitioneringsservice die gegevens naar een geschikt gegevensarchief verplaatst 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. Door een afzonderlijke partitioneringsservice te implementeren, wordt de belasting van de consolidatie- en opschoonservice verminderd en kunnen ten minste enkele gepartitioneerde gegevens indien nodig opnieuw worden gegenereerd (afhankelijk van de hoeveelheid gegevens die in gedeelde opslag worden bewaard). 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

Overweeg hoe dringend de gegevens vereist zijn. Gegevens die waarschuwingen genereren, moeten snel worden geopend, dus deze moeten worden bewaard in snelle gegevensopslag en geïndexeerd of gestructureerd om de query's te optimaliseren die door het waarschuwingssysteem worden uitgevoerd. In sommige gevallen kan het nodig zijn voor de verzamelingsservice om gegevens lokaal op te maken en op te slaan, 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 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 gegevens op te slaan. U kunt bijvoorbeeld gegevens bewaren die zijn gegenereerd voor foutopsporing 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 om prestatietrends en capaciteitsplanning te herkennen. 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 de gegevens mogelijk down-samplen 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.

Gegevens verzameld voor het meten en facturering van klanten moeten mogelijk voor onbepaalde tijd worden opgeslagen. Daarnaast kunnen wettelijke vereisten bepalen 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 moet nooit gebruikerswachtwoorden of andere gegevens vastleggen die kunnen worden gebruikt voor het doorvoeren van identiteitsfraude. U moet deze details van de gegevens wissen voordat deze worden opgeslagen.

Om ervoor te zorgen dat u voldoet aan de 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 de vereisten waarmee personen kunnen aanvragen dat hun gegevens worden verwijderd.

Gegevens analyseren om inzicht te hebben in de status van een workload

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

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

  • Hoe u de gegevens correleert die zijn vastgelegd in verschillende metrische gegevens en logboekbestanden. Deze correlatie is belangrijk wanneer u een reeks gebeurtenissen bijhoudt en u kunt 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 vooraf verwerken en filteren van gegevens op de databaselaag. Op de middelste laag zijn aggregatie en opmaak veelvoorkomende taken.

Aanbevelingen

  • Correleer logboeken op toepassingsniveau en resourceniveau. Evalueer gegevens op beide niveaus om de detectie van problemen en het oplossen van deze problemen te optimaliseren. U kunt de gegevens aggregeren in één gegevenssink of gebruikmaken van methoden die query's uitvoeren op gebeurtenissen op beide niveaus. We raden een uniforme oplossing aan, zoals Azure Log Analytics, om logboeken op toepassingsniveau en resourceniveau te aggregeren en op te vragen.

  • Definieer duidelijke bewaartijden voor opslag voor koude analyse. We raden deze procedure aan om historische analyses gedurende een bepaalde periode mogelijk te maken. Het kan u ook helpen bij het beheren van de opslagkosten. Implementeer processen die ervoor zorgen dat gegevens worden gearchiveerd in goedkopere opslag en geaggregeerde gegevens voor langetermijntrendanalyse.

  • Analyseer trends op lange termijn om operationele problemen te voorspellen. Evalueer langetermijngegevens om operationele strategieën te vormen en om te voorspellen welke operationele problemen zich waarschijnlijk voordoen en wanneer. U kunt er bijvoorbeeld rekening mee houden dat de gemiddelde reactietijden na verloop van tijd langzaam toenemen en het maximumdoel naderen.

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

Statusrapporten van workloads visualiseren

Dashboards

De meest voorkomende manier om gegevens te visualiseren, is door dashboards te gebruiken 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, selecteren voor elke specifieke situatie.

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

Om een dashboardsysteem effectief te laten werken, moet het zinvol zijn voor het workloadteam. Visualiseer informatie die betrekking heeft op de status van de werkbelasting en dat kan ook worden uitgevoerd. Wanneer de workload of een onderdeel is gedegradeerd of beschadigd, moeten leden van het workloadteam gemakkelijk kunnen bepalen waar het probleem vandaan komt en hun corrigerende acties of onderzoeken starten. Omgekeerd kan het dashboard onnodig complex en frustrerend zijn voor teamleden die achtergrondgeluiden 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 ze relevant vinden. Zorg ervoor dat het workloadteam de typen gegevenspunten begrijpt die andere teams geïnteresseerd zijn in het bekijken en bekijken van de dashboards voordat ze worden gedeeld om de duidelijkheid te controleren. Het bieden van dashboards over uw workload voor belanghebbenden is een goede manier om ze op de hoogte te houden van de status van de workload, maar het risico loopt dat ze contraproductief zijn 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 geïmproviseerde vragen over die informatie te stellen. 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 het opslaan van 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

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

Rapportage

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

Operationele rapportage omvat doorgaans het volgende:

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

  • Trends in resourcegebruik identificeren voor het algehele systeem of opgegeven subsystemen tijdens een opgegeven periode.

  • Bewaking van uitzonderingen die in het hele systeem of in opgegeven subsystemen zijn opgetreden tijdens een opgegeven periode.

  • Het bepalen van de efficiëntie van de toepassing voor de geïmplementeerde resources en het begrijpen of het volume van resources en de bijbehorende kosten kan worden verminderd zonder dat dit onnodig van invloed is op de prestaties.

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

  • Controle van gebruikersbewerkingen. Voor deze taak moeten de afzonderlijke aanvragen worden opgenomen die elke gebruiker heeft voltooid, samen met datums en tijden. De gegevens moeten zodanig zijn gestructureerd dat een beheerder snel de volgorde van bewerkingen kan reconstrueren die een gebruiker tijdens een opgegeven periode heeft voltooid.

  • 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 die het systeem samenstellen 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 die zo nodig rapporten kunnen genereren. 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 te presenteren als een set rapporten.

Waarschuwingen voor belangrijke gebeurtenissen definiëren

Om ervoor te zorgen dat het systeem in orde, responsief en veilig blijft, stelt u waarschuwingen in, zodat operators op een tijdige manier hierop kunnen reageren. Een waarschuwing kan voldoende contextuele informatie bevatten om hen te helpen 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 oplossing voor waarschuwingen, zoals Splunk of Azure Monitor, in plaats van dat mensen actief naar problemen moeten zoeken.

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

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

Drempelwaarden

Waarschuwingen worden gegenereerd wanneer drempelwaarden worden overschreden, zoals gedetecteerd door uw bewakingssysteem. Zorg ervoor dat de drempelwaarden die u instelt, over het algemeen voldoende tijd hebben om de benodigde wijzigingen in uw workload te implementeren om verslechtering of storingen te voorkomen. Stel bijvoorbeeld de drempelwaarde voor automatisch schalen in om schalen te initiëren voordat een van de actieve systemen wordt overweldigd tot het punt van een verminderde gebruikerservaring. Baseer de drempelwaarden die u toewijst aan uw eerdere ervaring bij 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 over het gebruik van waarschuwingen en andere overwegingen.

Azure-facilitering

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

  • Log Analytics is een hulpprogramma in 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 architectuurhandleiding voor Log Analytics-werkruimten 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.

  • Met Azure Policy kunt u organisatiestandaarden afdwingen en naleving op schaal beoordelen.

  • Azure Monitor Baseline Alerts (AMBA) is een centrale opslagplaats van waarschuwingsdefinities die klanten en partners kunnen gebruiken om hun waarneembaarheidservaring te verbeteren door gebruik te maken van Azure Monitor.

Controlelijst voor operationele uitmuntendheid

Raadpleeg de volledige set aanbevelingen.