Architectuurstrategieën voor het bewaken van de betrouwbaarheid van werkbelastingen

Van toepassing op de aanbeveling voor betrouwbaarheid in de Azure Well-Architected Framework-checklist:

Betrouwbaarheidscontrole is de praktijk om te meten hoe goed een systeem in de loop van de tijd voldoet aan de bedrijfsvereisten, met betrekking tot tolerantie en herstelbaarheid. Een goed ontworpen bewakingssysteem biedt realtime weergave en trends van systeemgedrag door inzicht te krijgen in platform-, infrastructuur- en workloadlagen.

Door deze signalen te correleren tussen onderdelen en na verloop van tijd, maakt bewaking snelle, betrouwbare analyse van incidenten en storingen mogelijk. Maak een gestructureerde benadering, zodat inzichten zinvol zijn, waarschuwingen zorgen voor de juiste acties en leerprocessen die teruggaan naar architectuur en bewerkingen.

De belangrijkste strategieën in dit artikel zijn gebaseerd op de fundamentele operationele praktijk van waarneembaarheid, beschreven in OE:07 Architectuurstrategieën voor het ontwerpen van een bewakingssysteem. Richtlijnen voor het implementeren van de bewakingspraktijk zijn beschikbaar in de ontwerphandleiding voor bewaking. We raden u aan deze middelen eerst te bekijken.

Definities

Functionaliteit van de werklast monitoren

Controleer wat uw systeem daadwerkelijk levert. Begin met het bijhouden of kritieke werkstromen zijn voltooid en geldige resultaten opleveren. Een systeem kan in orde lijken terwijl er nog steeds onjuiste of onvolledige uitvoer wordt geproduceerd, dus alleen uitvoering is niet voldoende.

Als een workload bijvoorbeeld elke zes uur rapporten genereert, moet de bewaking twee dingen bevestigen: dat de taak is uitgevoerd als gepland en dat deze een geldig resultaat heeft opgeleverd, zoals een niet-leeg rapport met verwachte inhoud en grootte. Dit soort validatie helpt ervoor te zorgen dat het systeem niet alleen wordt uitgevoerd, maar ook functionaliteit levert waarvoor het is ontworpen.

Gebruikerservaring bewaken

Bewaak de betrouwbaarheid vanuit het perspectief van een bedrijf en gebruiker. Als onderdeel van de analyse van de foutmodus (FMA) moet u al belangrijke gebruikersstromen hebben geïdentificeerd. Houd voor elke stroom bij hoe fouten in een onderdeel of afhankelijkheid van invloed zijn op de gebruikerservaring en wat het verwachte resultaat wordt. In een e-commerce-betaalstroom kan een servicestoring of overbelasting in betalings- of voorraadsystemen bijvoorbeeld voorkomen dat klanten aankopen voltooien.

Betrouwbaarheid weerspiegelt ook de kwaliteit van de service. In een afrekenproces moeten gebruikers hun aankopen zonder onderbreking van begin tot eind kunnen voltooien. Gebruik op percentiel gebaseerde latentiegegevens zoals p50, p95 en p99 om inzicht te hebben in de werkelijke gebruikerservaring, met speciale aandacht voor taillatentie waarbij prestatieproblemen vaak eerst optreden.

Beschikbaarheidsdoelen bijhouden

Houd bij hoe goed uw systeem voldoet aan de gedefinieerde doelen voor beschikbaarheid, doorvoer en reactietijden. Deze doelen worden vaak geformaliseerd als service level agreements (SLA's) en serviceniveaudoelstellingen (SLO's) en weerspiegelen de verwachtingen die u met uw gebruikers hebt ingesteld. Bewaking op basis van deze gegevens houdt de betrouwbaarheid in overeenstemming met echte bedrijfsresultaten. Zie Betrouwbaarheidsdoelen en Service Level Agreements voor meer informatie.

Richt u op de belangrijkste indicatoren die bijdragen aan deze doelen en die in de loop van de tijd volgen. Wanneer iets afdrijdt, moet u kunnen inzoomen op de specifieke onderdelen of subsystemen die betrokken zijn. Leg alle relevante signalen vast, inclusief problemen die worden gemaskeerd door redundantie of failover, zodat u kunt begrijpen wat er daadwerkelijk is gebeurd en herhalingen voorkomen.

Combineer realtime bewustzijn met historische context. Realtime-signalen helpen u snel te reageren wanneer doelen risico lopen, terwijl trends in de loop van de tijd patronen en terugkerende problemen onthullen. Het classificeren van de oorzaken van doelmissers en het samenvoegen van deze metrische gegevens biedt ook ondersteuning voor duidelijke SLA-rapportage en helpt bij het begeleiden van doorlopende verbeteringen.

Bewaak de belangrijkste SLA's van uw leveranciers en platformservices (van Microsoft en anderen). U moet het volgende doen:

• Indicatoren bijhouden van mogelijke SLA-schendingen in realtime
• Het bewijs vastleggen en bewaren dat is vereist voor de ondersteuning van een SLA-claim als er een inbreuk optreedt

Hersteldoelen bijhouden

Herstelbaarheid bijhouden door elke test en elk echt incident te behandelen als meetbare gebeurtenis. Gebruik bewakingsgegevens om te controleren of uw systeem en team onder reële omstandigheden aan gedefinieerde hersteldoelstellingen kunnen voldoen.

Meet belangrijke signalen, zoals de tijd die nodig is om RTO te detecteren, te reageren en te herstellen, samen met blootstelling aan gegevensverlies (RPO). Neem indicatoren op zoals failovergereedheid en capaciteit, failover-slagingspercentages en uitvoeringstijd, geslaagde back-up en herstel, replicatievertraging en hoeveel handmatige interventie is vereist.

Deze metrische gegevens markeren ook operationele hiaten, zoals onduidelijke procedures, beslissingsvertragingen of moeilijk te openen documentatie, die van invloed kunnen zijn op de herstelprestaties. Gebruik deze inzichten om de procedures voor systeemontwerp en incidentrespons te versterken.

Waarschuwingen uitvoerbaar maken met een statusmodel

Ontwerp waarschuwingen zodat ze duidelijk wijzen op iets dat de moeite waard is om op te reageren en baseer ze op een gezondheidsmodel dat het systeem vertegenwoordigt met eenvoudige statussen zoals gezond, gedegradeerd en ongezond.

Structureer het statusmodel hiërarchisch, van afzonderlijke onderdelen tot het volledige systeem, zodat u snel problemen kunt traceren naar hun bron. Definieer drempelwaarden met serviceniveaudoelstellingen (SLO's) en combineer signalen zoals metrische gegevens, logboeken, traceringen en synthetische controles om een betrouwbaar beeld van de systeemstatus te creëren. Dit geeft operators een duidelijk beeld van wat er werkt, wat niet is en waar ze moeten handelen zonder onbewerkte gegevens te doorzoeken. Zie de ontwerphandleiding voor statusmodellering voor meer informatie.

Stem waarschuwingen af op werkelijke omstandigheden door te focussen op end-to-end-ervaring en kritieke transacties, zodat ze de werkelijke impact van de gebruiker weerspiegelen. Verminder ruis door rekening te houden met tijdelijke schommelingen en te reageren op zinvolle statusveranderingen in plaats van geïsoleerde blips of pieken. Combineer realtime waarschuwingen met trendinzichten om zowel onmiddellijke problemen als geleidelijke afname te ondervangen, zodat teams snel kunnen reageren en gefocust blijven.

Risico: Gezondheidsmodellering vereist het verzamelen van zinvolle signalen in het systeem. Als u alleen vertrouwt op eenvoudige metrische gegevens, zoals CPU of geheugen, kunt u missen wat er werkelijk toe doet. Voeg gebruikerservaringgegevens en synthetische controles toe om een volledige weergave te krijgen. Het definiëren van 'gezond' vereist afstemming, en slecht afgestemde drempelwaarden kunnen ruis veroorzaken en de effectiviteit verminderen.

Alle lagen van het systeem bewaken

Bewaak elke laag van het systeem, de toepassing, gegevens/opslag en het netwerk om een volledig overzicht van betrouwbaarheidssignalen te behouden.

Op de toepassingslaag kunt u succes, fouten en latentie bijhouden met behulp van logboeken, metrische gegevens en statustests. Gebruik correlatie-id's om aanvragen in verschillende services te volgen en het oplossen van problemen te vereenvoudigen. Verzamel logboeken asynchroon zodat ze geen invloed hebben op de prestaties van aanvragen en houd diagnostische en auditlogboeken gescheiden voor duidelijkheid. Voeg synthetische transacties en eindpunttests toe om te bevestigen wat klanten daadwerkelijk ervaren.

Afweging. Het kiezen tussen asynchrone en synchrone logboekregistratie omvat een balans tussen prestaties en betrouwbaarheid van telemetrie.

• Asynchrone logregistratie houdt logregistratie buiten de prestatiedrempel, waardoor latentie wordt verminderd en de systeemprestaties worden verbeterd. Het introduceert echter een risico op telemetrieverlies, vooral als er een fout optreedt voordat logboeken worden leeggemaakt of opgeslagen.

• Synchrone logboekregistratie zorgt ervoor dat logboeken worden geschreven voordat de verwerking wordt voortgezet, waardoor de duurzaamheid en controlebaarheid van gegevens wordt verbeterd. De afweging is een hogere latentie en een strakkere koppeling tussen de prestaties van toepassingen en het systeem voor logboekregistratie.

In de meeste scenario's is asynchrone logboekregistratie de voorkeursbenadering vanwege de minimale impact op de prestaties. In sterk gereguleerde of auditgevoelige omgevingen kan synchrone logboekregistratie echter vereist zijn om te garanderen dat kritieke gebeurtenissen betrouwbaar worden vastgelegd..

Richt u op de gegevens- en opslaglaag op beschikbaarheid, schrijfsuccespercentages, querylatentie, time-outs, vergrendelingen en resourcedruk. Bekijk trends in de loop van de tijd om groeiende knelpunten te identificeren en onderscheid te maken tussen kortstondige problemen van duurzame degradatie.

Controleer op de netwerklaag de connectiviteit, latentie, pakketverlies, bandbreedte en verkeerspatronen. Combineer stroomlogboeken, eindpuntcontroles en synthetische tests om routeringsproblemen, afwijkingen of beveiligingsgerelateerd gedrag aan de oppervlakte te laten komen. Verbind deze signalen terug naar toepassings- en platformgegevens om te begrijpen waar problemen vandaan komen.

Operationele logboeken helpen bij het diagnosticeren van problemen, het bijhouden van prestaties en het begrijpen van systeemgedrag. Ze zijn niet ontworpen om te fungeren als bron van waarheid voor zakelijke gebeurtenissen, controle of regelgevingsrapportage, die doorgaans een sterkere tracering vereisen.

Wat u in detail moet bewaken voor elke laag, wordt behandeld in de handleiding voor bewakingsontwerp.

Stempelcapaciteit definiëren en bewaken

Definieer duidelijke capaciteitslimieten voor elke implementatie-eenheid of stempel en bewaak ze nauwkeurig. Elke stempel werkt binnen een eindig plafond, ongeacht of dit een maximum aantal gelijktijdige gebruikers, doorvoer of drempelwaarden voor resourcegebruik is. Als u deze limieten expliciet maakt, beschikt u dus over een betrouwbare basislijn voor besluitvorming.

Deze zichtbaarheid helpt u te identificeren wanneer een stempel bijna verzadiging nadert, ruim voordat dit van invloed is op de betrouwbaarheid. Het biedt ook ondersteuning voor tijdige uitschaalbeslissingen, zoals het toevoegen van nieuwe stempels of herdistributie van belasting, en bevestigt dat het verkeer volgens uw ontwerp stroomt.

Het definiëren van deze limieten is niet altijd eenvoudig. Capaciteit kan moeilijk te meten zijn, met name wanneer deze afhankelijk is van meerdere onderliggende services met verschillende schaalkenmerken. U moet platformrichtlijnen gebruiken, zoals quota en limieten van Microsoft Azure, als uitgangspunt. In de praktijk wordt de capaciteit vaak bepaald door belastingstests, observaties en iteratieve afstemming in plaats van nauwkeurige modellering vooraf.

Bewaken van de belastingverdeling over redundante exemplaren

Wanneer u de werkbelasting uitvoert op meerdere redundante exemplaren, inclusief wanneer u exemplaren distribueert over verschillende regio's of zones, moet het verkeer en resourcegebruik in deze exemplaren evenwichtig blijven.

U wilt onbalansen opsporen die vaak wijzen op routeringsproblemen, configuratieproblemen of afhankelijkheidsbeperkingen. Het zorgt er ook voor dat failoverdoelen voldoende capaciteit hebben om verkeer te absorberen wanneer dat nodig is en bevestigt dat redundantiemechanismen zich gedragen zoals verwacht tijdens zowel scenario's met een stabiele status als fouten.

Foutmodi detecteren

Als onderdeel van uw FMA-oefening (Foutmodusanalyse) moet u de potentiële storingspunten hebben geïdentificeerd.

Houd in de praktijk voor betrouwbaarheidsbewaking continu toezicht op deze punten. Begin met het focussen op eenvoudigere signalen, zoals tijdelijke fouten. Controleer het gedrag van nieuwe pogingen en tijdelijke foutpercentages om te begrijpen hoe uw afhankelijkheden en onderliggende services zich gedragen onder werkelijke operationele omstandigheden. Deze signalen geven een vroeg beeld van opkomende instabiliteit. Ze helpen u te herkennen wanneer patronen voor opnieuw proberen afwijken van de verwachte norm, een idee krijgen of het systeem onder belasting gezond blijft, en vaststellen wanneer een afhankelijkheid of externe service begint te verslechteren voordat dit van invloed is op de gebruikerservaring.

Neem ook grotere impactfouten op, zoals storingen in de beschikbaarheidszone die van invloed zijn op een subset van infrastructuur, servicestoringen of regionale storingen die een hele Azure-regio offline halen. Zelfs kijken naar beveiligingsscenario's zoals DDoS of andere schadelijke activiteiten, onjuiste configuratie van onderdelen en prestatieproblemen, omdat elk van deze scenario's de algehele betrouwbaarheid van uw oplossing kan beïnvloeden.

Zie Architectuurstrategieën voor analyse van foutmodus voor informatie over FMA.

Op de hoogte worden gesteld van de betrouwbaarheidsstatus van het platform

U hebt duidelijk inzicht nodig in de platformstatus om de betrouwbaarheid effectief te beheren. Deze kennis helpt u snel te bepalen of een probleem afkomstig is van uw workload of in het onderliggende cloudplatform.

Azure Service Health biedt inzicht in de status van Azure. Configureer waarschuwingen voor Service Health, zodat u meldingen ontvangt wanneer de platformvoorwaarden veranderen. U ontvangt updates over actieve storingen die van invloed zijn op uw resources, geplande onderhoudsgebeurtenissen die kunnen leiden tot onderbrekingen en regionale of servicespecifieke verslechteringen.

Azure-ondersteuning

• Neem bewakings- en waarschuwingsservices voor cloudplatforms op, waaronder:

  • Gezondheid op platformniveau, zoals Azure Service Health.

  • Gezondheid op resourceniveau, zoals Azure Resource Health.

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

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

• Application Insights is een uitbreiding van Azure Monitor. Het biedt APM-functies (Application Performance Monitoring).

• Azure Monitor-inzichten zijn geavanceerde analysehulpprogramma's waarmee u Azure-services kunt bewaken, zoals virtuele machines, toepassingsservices en containers. Inzichten zijn gebaseerd op Azure Monitor en Log Analytics.

• Azure Monitor voor SAP-oplossingen is een systeemeigen bewakingsproduct van Azure voor SAP-landschappen die worden uitgevoerd in Azure.

• Verbindingsmonitor is een hulpprogramma voor het continu bijhouden van de netwerkconnectiviteit en prestaties in Azure-resources. Het voert synthetische tests uit en biedt realtime waarschuwingen en diagnostische gegevens om fouten vroeg te detecteren. U kunt aangepaste werkmappen maken om de connectiviteitsstatus en geaggregeerde metrische prestatiegegevens te visualiseren.

• Verkeerslogboeken voor virtuele netwerken kunnen worden ingeschakeld voor alle werkbelastingen om netwerkverkeer te bewaken. Traffic Analytics kan worden gebruikt om deze stroomlogboeken te analyseren en te verrijken om inzichten weer te geven, zoals geblokkeerd verkeer, schadelijke stromen en actieve poorten die beschikbaar zijn voor internet. Door werkmappen te maken, kunnen teams het gedrag van liveverkeer bewaken en waarschuwingen ontvangen. Gebruik tijdlijnweergaven en topologievisualisaties om eenvoudig verkeerspatronen te bewaken die kunnen duiden op prestatievermindering of beveiligingsrisico's.

• Zie Een Log Analytics-werkruimtearchitectuur ontwerpen voor de beste werkwijzen voor meerdere werkruimten.

Example

Zie Bewaking van webtoepassingen in Azure en basislijnarchitectuur voor een Azure Kubernetes Service-cluster voor voorbeelden van echte bewakingsoplossingen.

Communityverwijzingen

• 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 betrouwbaarheid

Raadpleeg de volledige reeks aanbevelingen.