Statusmodellering voor workloads

Cloudtoepassingen genereren grote hoeveelheden operationele gegevens, waardoor het lastig is om problemen snel vast te stellen en op te lossen. Een veelvoorkomende reden voor deze uitdaging is het ontbreken van een statusbasislijn die is aangepast aan de functionaliteit van de workload en het niet kunnen detecteren van afwijkingen van die basislijn.

Statusmodellering is een waarneembaarheidsoefening die bedrijfscontext combineert met onbewerkte bewakingsgegevens om de algehele status van een workload te kwantificeren. Hiermee kunt u een basislijn instellen waarmee u de workload kunt bewaken. U moet rekening houden met gegevens zoals telemetrie van infrastructuur- en toepassingsonderdelen. Statusmodellering kan ook andere informatie bevatten die nodig is om de kwaliteitsdoelen van de workload te bereiken.

Prestatieproblemen of operationele degradatie kunnen afwijkingen van de verwachte operationele status veroorzaken. Door de status van een workload te modelleren, kunt u afwijkingen identificeren en weloverwogen operationele beslissingen nemen die rekening houden met de bedrijfsimpact.

Gezondheidsmodellering overbrugt de kloof tussen tribale operationele kennis en bruikbare inzichten. Hiermee kunt u kritieke problemen effectief beheren. Het concept is essentieel om de betrouwbaarheid en operationele effectiviteit te maximaliseren.

Deze handleiding biedt praktische richtlijnen over statusmodellering, waaronder het bouwen van een model dat de runtimestatus van een workload en alle bijbehorende subsystemen evalueert.

Terminologie	Definitie
Statusmodellering	Een waarneembaarheidsoefening die gebruikmaakt van bedrijfscontext om bewakingsgegevens te interpreteren als statussen.
Statusmodel	Een grafische weergave van logische entiteiten en hun relaties voor een bepaald bereik. Elk knooppunt heeft een statusdefinitie om bewakingsgegevens in het hele model te rationaliseren.
Statusentiteit	Een logisch onderdeel dat een afzonderlijke eenheid van een systeem vertegenwoordigt, een logische combinatie van meerdere gerelateerde entiteiten of het algehele systeem.
Status	Een gedefinieerde en meetbare status die zinvolle operationele inzichten biedt over de status van een entiteit.
Statussignaal	Afzonderlijke gegevensstromen die inzicht bieden in het operationele gedrag van een entiteit.
Model van modellen	Een geaggregeerd modelleringsbereik waarin entiteiten afzonderlijke statusmodellen voor onderdeelsystemen vertegenwoordigen.

We raden u aan deze video watch om inzicht te krijgen in statusmodellering.

Wat is status, statusmodellering en een statusmodel?

De term status verwijst naar de operationele status van een entiteit en de bijbehorende afhankelijkheden. Die entiteit kan een afzonderlijke eenheid van een systeem zijn, een logische combinatie van meerdere gerelateerde entiteiten of het algehele systeem.

U wordt aangeraden de status in een van de volgende drie statussen weer te geven:

• In orde: werkt optimaal en voldoet aan de verwachtingen van de kwaliteit

• Gedegradeerd: vertoont minder dan gezond gedrag, wat wijst op mogelijke problemen

• Niet in orde: zich in een kritieke toestand bevindt en onmiddellijke aandacht vereist

Notitie

U kunt de status weergeven met een score in plaats van statussen om meer gegevensgranulariteit te bieden.

Statussen worden afgeleid door bewakingsgegevens te combineren met domeingegevens. Elke status moet worden gedefinieerd en meetbaar zijn. Statussen worden berekend met behulp van statussignalen. Dit zijn afzonderlijke gegevensstromen die inzicht bieden in het operationele gedrag van een entiteit. Signalen kunnen metrische gegevens, logboeken, traceringen of andere kwaliteitskenmerken bevatten. Een statussignaal voor een entiteit van een virtuele machine (VM) kan bijvoorbeeld het metrische cpu-gebruik bijhouden. Andere signalen voor deze entiteit kunnen geheugengebruik, netwerklatentie of foutpercentages zijn.

Houd bij het definiëren van statussignalen rekening met de niet-functionele vereisten voor de workload. Neem in het voorbeeld van CPU-gebruik de verwachte drempelwaarden voor elke status op. Als het gebruik de getolereerde drempelwaarde overschrijdt in overeenstemming met de workloadvereisten, gaat het systeem over van In orde naar Gedegradeerd of Beschadigd. Deze statuswijzigingen activeren de juiste waarschuwingen of acties.

Voor statusmodellering moeten entiteiten goed gedefinieerde statussen hebben die zijn afgeleid van meerdere statussignalen en die zijn gecontextualiseerd voor de workload. De statusdefinitie voor een VM kan bijvoorbeeld zijn:

• In orde: aan de belangrijkste niet-functionele vereisten en doelen, zoals reactietijd, resourcegebruik en algehele systeemprestaties, wordt volledig voldaan. Zo wordt 95% van de aanvragen binnen 500 milliseconden verwerkt. De workload maakt optimaal gebruik van VM-resources zoals CPU, geheugen en opslag en houdt een balans tussen de workloadvereisten en de beschikbare capaciteit. De gebruikerservaring is op het verwachte niveau.

• Gedegradeerd: resources presteren niet optimaal, maar zijn nog steeds operationeel. De opslagschijf ondervindt bijvoorbeeld beperkingsproblemen. Gebruikers kunnen trage reacties ervaren.

• Beschadigd: degradatie valt buiten de getolereerde limieten. Resources reageren niet meer of zijn niet meer beschikbaar en het systeem voldoet niet meer aan acceptabele prestatieniveaus. De gebruikerservaring wordt ernstig beïnvloed.

Het resultaat van statusmodellering is een model of een grafische weergave van logische entiteiten en hun relaties voor een workloadarchitectuur. Elk knooppunt heeft een statusdefinitie.

Belangrijk

Statusmodellering is een abstract concept dat u kunt implementeren en toepassen op verschillende bereiken als u een goed begrip hebt van de bedrijfsscenario's.

In de afbeelding:

• Entiteiten zijn logische onderdelen van de workload die aspecten van het systeem vertegenwoordigen. Dit kunnen infrastructuuronderdelen zijn, zoals servers, databases en netwerken. Ze kunnen ook specifieke toepassingsmodules, pods, services of microservices zijn. Of entiteiten kunnen gebruikersinteracties en systeemstromen binnen de workload vastleggen.

  Notitie

  Gebruikers- en systeemstromen bevatten een overzicht van niet-functionele vereisten voor bedrijfsscenario's waarbij toepassings- en infrastructuuronderdelen zijn betrokken. Deze samenvatting weerspiegelt de bedrijfswaarde voor de toepassing.

• Relaties tussen entiteiten weerspiegelen de afhankelijkheidsketens binnen het systeem. Een toepassingsmodule kan bijvoorbeeld specifieke infrastructuuronderdelen aanroepen die een relatie vormen.

Overweeg een scenario waarin een e-commerceworkload een piek in mislukte berichten ervaart in een Azure Service Bus wachtrij, waardoor betalingen mislukken. Dit probleem is essentieel voor de organisatie vanwege het impliciete omzetverlies. Hoewel een toepassingsontwikkelaar het effect van deze piek in metrische gegevens op betalingen begrijpt, wordt deze kennis niet vaak gedeeld door het operationele team.

Een statusmodel kan operators onmiddellijk inzicht geven in het probleem en de gevolgen ervan. De betalingsstroom is afhankelijk van Service Bus, een van de workloadonderdelen. De visuele weergave toont de gedegradeerde status van het Service Bus-exemplaar en het effect ervan op de betalingsstroom. Operators kunnen het belang van het probleem begrijpen en hun herstelinspanningen richten op dat specifieke onderdeel.

Statusmodellering was belangrijk in het vorige scenario op de volgende manieren:

• Het verbeterde de tijd om te detecteren (TTD) en de tijd om te beperken (TTM) door snellere probleemisolatie in te schakelen, wat leidde tot snellere detectie van problemen en mogelijke oplossingen.

• Operators hebben waarschuwingen ontvangen op basis van statussen, waardoor onnodige ruis is verminderd. Operators hebben meldingen ontvangen met specifieke context over de bedrijfsimpact op betalingen.

• Afhankelijkheidsketens hebben operators volledig inzicht in de omvang van operationele problemen. Deze kennis versnelde effectbeoordelingen en leidde tot antwoorden met prioriteit. Operators kunnen ook eenvoudig trapsgewijze of gecorreleerde problemen identificeren.

• Operators hebben activiteiten na incidenten met nauwkeurigheid uitgevoerd, omdat het statusmodel inzicht biedt in de hoofdoorzaken van afwijkingen en de specifieke statussignalen die betrokken waren.

• Het maakte de bewakingsgegevens zinvol voor alle teamleden. Het overbrugde de kloof tussen tribale kennis en gedeelde inzichten.

• De organisatie heeft het statusmodel gebruikt als basis voor toekomstige investeringen in AI-gestuurde bewerkingen om intelligente inzichten af te leiden.

Statusmodelschema

Statusmodellen bieden een uniek gegevensschema dat is geoptimaliseerd voor gebruiksvoorbeelden met waarneembaarheid. In dit schema wordt statusmodellering van een abstract concept naar een meetbare oplossing gebruikt. Door uw specifieke vereisten, doelstellingen en architectuurcontext te modelleren, kunt u statusgegevens aanpassen aan uw unieke scenario.

Status is een relatief gegevensconcept. Elk model vertegenwoordigt statusgegevens die uniek zijn en prioriteit hebben voor het contextuele bereik, zelfs als dezelfde set entiteiten wordt gebruikt. Wat in een specifiek scenario gezond is, kan aanzienlijk verschillen in andere contexten.

Overweeg bijvoorbeeld Azure-resources van hetzelfde type binnen uw workload.

• VM A voert een CPU-gevoelige toepassing uit.
• VM B verwerkt een geheugenintensieve service.

De statusdefinities voor deze machines verschillen. Metrische gegevens over CPU-gebruik zijn waarschijnlijk van invloed op de status van VM A en VM B kan prioriteit geven aan geheugengerelateerde metrische gegevens.

Belangrijk

Een statusmodel moet niet alle fouten op dezelfde wijze behandelen. Het moet duidelijk onderscheid maken tussen verwachte of tijdelijke maar herstelbare fouten en een echte noodtoestand.

Een statusmodel bouwen

De eerste stap voor het bouwen van een statusmodel is een logische ontwerpoefening, die doorgaans de activiteiten omvat die in de volgende secties worden beschreven.

Uw workloadontwerp evalueren

Begin met deze logische ontwerpoefening door de volgende onderdelen van uw workloadontwerp te evalueren.

• Infrastructuuronderdelen, zoals rekenclusters en databases

• Toepassingsonderdelen die worden uitgevoerd op rekenkracht en hun relevante onderdelen

• Logische of fysieke afhankelijkheden tussen onderdelen

• Gebruikers- en systeemstromen

Het statusmodel voor een e-commercetoepassing moet bijvoorbeeld de huidige status van kritieke processen, zoals gebruikersaanmelding, betaling en betalingen, vertegenwoordigen.

Contextualiseren met behulp van bedrijfsvereisten

Evalueer het relatieve belang en de algehele impact van elke stroom op uw organisatie. Houd rekening met factoren als gebruikerservaring, beveiliging en operationele efficiëntie. In de meeste scenario's is het mislukken van een betalingsproces waarschijnlijk groter dan het mislukken van een rapportageproces.

Identificeer escalatiepaden voor het afhandelen van problemen met betrekking tot elke stroom. Zie Workloadontwerp optimaliseren met behulp van stromen voor meer informatie.

Notitie

U realiseert de waarde van health modeling alleen wanneer u uw bedrijfsscenario's en context opneemt. Vervolgens kunt u de bedrijfsimpact van operationele problemen rationaliseren.

Toewijzen aan metrische betrouwbaarheidsgegevens

Zoek in het ontwerp van de toepassing naar relevante metrische betrouwbaarheidsgegevens .

Overweeg om serviceniveau-indicatoren (SLO's) en serviceniveaudoelstellingen (SLO's) te definiëren voor de hele toepassing en de bijbehorende afzonderlijke bedrijfsprocessen. Deze SLO's en SLO's moeten worden afgestemd op de specifieke statussignalen die voor uw statusmodel in aanmerking worden genomen. Door dit te doen, maakt u een uitgebreide definitie van de status die nauwkeurig het bereiken van een acceptabel serviceniveau voor de toepassing weergeeft.

Belangrijk

SLA's en SLO's zijn kritieke statussignalen. Ze maken een zinvolle definitie van de status die het gewenste serviceniveau weerspiegelt, samen met andere kwaliteitskenmerken. U kunt ook servicestatusdoelstellingen (SPO's) definiëren om de status vast te leggen die u wilt bereiken over een geaggregeerd tijdsbereik.

Statussignalen identificeren

Als u een uitgebreid statusmodel wilt bouwen, moet u verschillende soorten bewakingsgegevens correleren, waaronder metrische gegevens, logboeken en traceringen. Door dit te doen, zorgt u ervoor dat het concept van status de runtimestatus van een specifieke entiteit of de hele workload nauwkeurig weergeeft.

Metrische platformgegevens en logboeken gebruiken

In de context van statusmodellering is het essentieel om metrische gegevens en logboeken op platformniveau te verzamelen van onderliggende Azure-resources. Deze metrische gegevens omvatten CPU-percentage, netwerk in- en netwerkuit, en schijfbewerkingen per seconde. U kunt deze gegevens in uw statusmodel gebruiken om potentiële problemen te detecteren en te voorspellen met behoud van een betrouwbare omgeving.

Bovendien kunt u met deze aanpak onderscheid maken tussen tijdelijke fouten, tijdelijke onderbrekingen en niet-tijdelijke fouten of aanhoudende problemen.

Notitie

Als best practice moet u alle toepassingsresources configureren om diagnostische logboeken en metrische gegevens om te leiden naar de gekozen technologie voor logboekaggregatie. Bouw kaders met behulp van Azure Policy om consistente diagnostische instellingen in de toepassing te garanderen en de gekozen configuratie af te dwingen voor elke Azure-service.

Toepassingslogboeken toevoegen

Toepassingslogboeken zijn een belangrijke bron van diagnostische gegevens voor uw statusmodel. Hier volgen enkele aanbevolen procedures voor toepassingslogboeken:

• Gebruik semantische of gestructureerde logboekregistratie. Gestructureerde logboeken maken geautomatiseerd gebruik en analyse van logboekgegevens op schaal mogelijk.

  Overweeg om metrische gegevens en diagnostische gegevens van Azure-resources op te slaan in een Werkruimte voor Azure Monitor-logboeken in plaats van in een opslagaccount. Met deze methode kunt u statussignalen maken met behulp van Kusto-query's voor een efficiënte evaluatie.

• Logboekgegevens in de productieomgeving. Leg uitgebreide gegevens vast terwijl de toepassing in de productieomgeving werkt. Voldoende informatie is essentieel voor de evaluatie van de status en om eventuele gedetecteerde productieproblemen vast te stellen.

• Gebeurtenissen registreren bij servicegrenzen. Neem een correlatie-id op die servicegrenzen overschrijdt. Als een transactie meerdere services omvat en een van deze services mislukt, helpt de correlatie-id u aanvragen in uw toepassing bij te houden en de oorzaak van de fout aan te geven.

• Gebruik asynchrone logboekregistratie. Vermijd synchrone logboekregistratiebewerkingen die toepassingscode kunnen blokkeren. Asynchrone logboekregistratie zorgt voor beschikbaarheid door achterstallige aanvragen tijdens het schrijven van logboeken te voorkomen.

• Scheid toepassingslogboeken van controle. Beheer auditlogboeken afzonderlijk van diagnostische logboeken. Hoewel auditrecords voldoen aan nalevings- of regelgevingsvereisten, voorkomt het uniek houden van deze records dat transacties worden verwijderd.

Gedistribueerde tracering implementeren

Implementeer gedistribueerde tracering door telemetrie te correleren tussen kritieke systeemstromen. Gecorreleerde telemetrie biedt inzicht in end-to-end transacties en is essentieel voor een effectieve hoofdoorzaakanalyse (RCA) wanneer er fouten optreden.

Statustests gebruiken

Implementeer en voer statustests uit buiten de toepassing om expliciet de status en reactiesnelheid van uw toepassing te controleren. Gebruik testreacties als signalen binnen uw statusmodel.

U kunt statustests implementeren door de reactietijd van de toepassing als geheel of van de afzonderlijke onderdelen ervan te meten. Met tests kunnen processen worden uitgevoerd om de latentie te meten en de beschikbaarheid te controleren of om informatie uit de toepassing te extraheren. Zie Patroon statuseindpuntbewaking voor meer informatie.

De meeste load balancers ondersteunen het uitvoeren van statustests die toepassingseindpunten pingen met geconfigureerde intervallen. U kunt ook een externe watchdog-service gebruiken. Een watchdog-service verzamelt statuscontroles van meerdere onderdelen in de workload. Watchdogs kunnen ook code hosten die onmiddellijk herstel uitvoert voor bekende statusproblemen.

Structurele en functionele bewakingstechnieken gebruiken

Structurele bewaking omvat het uitrusten van de toepassing met semantische logboeken en metrische gegevens. De toepassing verzamelt deze metrische gegevens rechtstreeks, waaronder het huidige geheugenverbruik, aanvraaglatentie en andere relevante gegevens op toepassingsniveau.

Versterk uw bewakingsprocessen met behulp van functionele bewaking. Deze benadering is gericht op het meten van platformservices en hun effect op de algehele gebruikerservaring. In tegenstelling tot structurele bewaking vereist functionele bewaking geen gedetailleerde kennis van het systeem. Hiermee wordt het extern zichtbare gedrag van de toepassing getest. Deze aanpak is handig voor het beoordelen van SLO's en SLO's.

Het ontwerp modelleren

Vertegenwoordigt het geïdentificeerde toepassingsontwerp als entiteiten en relaties. Wijs statussignalen toe aan specifieke onderdelen om statussen op entiteitsniveau te kwantificeren. Houd rekening met de ernst van onderdelen om te bepalen hoe statussen via het model moeten worden doorgegeven. Rapportageonderdelen zijn bijvoorbeeld mogelijk niet zo essentieel als andere onderdelen, wat resulteert in verschillende effecten op de algehele status van de workload.

Waarschuwingen instellen waarop een actie kan worden uitgevoerd

Gebruik de geëvalueerde statussen om waarschuwingen en geautomatiseerde actie te activeren. De status moet worden geïntegreerd in bestaande operationele runbooks als een kernbeginsel voor waarneembaarheidsgegevens.

Normaal gesproken is er een een-op-een-toewijzing tussen bewakingsgegevens en waarschuwingsregels, wat kan leiden tot ongewenste resultaten, zoals waarschuwingsstormen en omgevingsgeluiden. In een rekencluster kunnen bijvoorbeeld grote hoeveelheden waarschuwingen op VM-niveau op basis van CPU-gebruik en het aantal fouten operators overbelasten tijdens fouten en vertragingen in de oplossing veroorzaken. En wanneer er een groot aantal geconfigureerde waarschuwingen is, resulteert omgevingsgeluid vaak in waarschuwingen die over het hoofd worden gezien of genegeerd.

Een statusmodel introduceert scheiding tussen bewakingsgegevens en waarschuwingsregels. Een statusdefinitie voegt veel signalen samen in één status, waardoor het aantal waarschuwingen wordt verlaagd, zodat operators zich alleen kunnen richten op waarschuwingen met een hoge waarde die essentieel zijn voor de organisatie. Bekijk het e-commercescenario. U kunt een waarschuwing instellen om meldingen te verzenden over wijzigingen in de status van de procesbetalingsstroom in plaats van wijzigingen in onderliggende resources, zoals de Service Bus-wachtrij.

Notitie

De mogelijkheid om waarschuwingen uit te brengen in alle lagen van het statusmodel biedt flexibiliteit voor de verschillende workloadpersoonlijkheid. Toepassingseigenaren en productmanagers kunnen worden gewaarschuwd voor statuswijzigingen in belangrijke bedrijfsscenario's of in de hele workload. Operators kunnen worden gewaarschuwd op basis van de status van de infrastructuur of toepassingsonderdelen.

Het model visualiseren

Maak visuele weergaven, zoals tabellen of grafieken, om de huidige status en geschiedenis van het statusmodel effectief over te brengen. Zorg ervoor dat de visualisatie is afgestemd op de bedrijfscontext en bruikbare inzichten biedt.

Wanneer u uw gezondheidsmodel visualiseert, kunt u overwegen een verkeerslichtbenadering te gebruiken om statusstatussen onmiddellijk inzichtelijk te maken in afhankelijkheidsketens.

Wijs groen toe voor gezond, amber voor gedegradeerd en rood voor beschadigd. Door snel de met kleur gecodeerde statussen te identificeren, kunt u efficiënt de hoofdoorzaak van eventuele toepassingsdegradatie vinden.

Notitie

We raden u aan rekening te houden met toegankelijkheidsvereisten voor mensen met een visuele beperking wanneer u een dashboard voor uw gezondheidsmodel maakt. Zie Architectuurontwerpdiagrammen voor aanbevolen procedures voor diagrammen.

Uw gezondheidsmodel gebruiken

Nadat u een statusmodel hebt gemaakt, kunt u de volgende use cases overwegen om de detectie en interpretatie van fouten of operationele problemen te stimuleren.

Toepasselijkheid op verschillende rollen

Statusmodellering kan informatie bieden die specifiek is voor taakfuncties of rollen binnen dezelfde context van de workload. Een DevOps-rol kan bijvoorbeeld operationele statusgegevens nodig hebben. Een beveiligingsbeambte maakt zich mogelijk meer zorgen over inbraaksignalen en blootstelling aan de beveiliging. Een databasebeheerder is waarschijnlijk alleen geïnteresseerd in een subset van het toepassingsmodel via de databaseresources.

Gezondheids-inzichten op maat maken voor verschillende belanghebbenden. Overweeg om afzonderlijke modellen te maken van overlappende gegevenssets.

Continue validatie

Gebruik uw statusmodel om test- en validatieprocessen te optimaliseren, zoals belastings- en chaostests. U kunt de operationele runtimestatus valideren tijdens het testen en de effectiviteit van uw model in schaal- en foutscenario's beoordelen door statusmodellen op te nemen in uw technische levenscyclus.

Organisatiestatus

Hoewel statusmodellering vaak wordt geassocieerd met het kwantificeren van statussen voor afzonderlijke toepassingen, gaat de toepasbaarheid ervan verder dan dat bereik.

Op een individueel workloadniveau bieden statusmodellen een basis voor de waarneembaarheid van toepassingen en operationele inzichten. Elke toepassing kan een eigen statusmodel hebben dat vastlegt wat elke status betekent binnen de context.

U kunt meerdere statusmodellen combineren tot een constructie op hoog niveau door een model van modellen te bouwen. U kunt bijvoorbeeld de waarneembaarheidsvoetafdruk van een bedrijfseenheid of een hele cloudomgeving opbouwen door statusmodellen te gebruiken als onderdelen binnen een groter model. Statusmodellen vertegenwoordigen workloads binnen de estate als knooppunten in de grafiek op het hoogste niveau. Gebruik de relaties in dit model om afhankelijkheden tussen toepassingen vast te leggen, waaronder gegevensstromen, service-interacties en gedeelde infrastructuur.

Overweeg een retailbedrijf dat verschillende toepassingen heeft voor e-commerce, betalingen en orderverwerking. U kunt elk van deze toepassingen definiëren als een onafhankelijk statusmodel om te kwantificeren wat status betekent voor die workload. Vervolgens kunt u een bovenliggend model gebruiken om al deze onderdeelstatusmodellen toe te wijzen als entiteiten en de operationele impact tussen toepassingen vast te leggen via afhankelijkheidsketens. Als de e-commercetoepassing bijvoorbeeld beschadigd raakt, heeft dit een trapsgewijs effect op de betalingstoepassing.

Statustrends en AI voor IT-bewerkingen

Statusmodellering biedt een gekwantificeerde operationele basislijn die is afgestemd op een specifieke bedrijfscontext. AI voor IT-bewerkingen (AIOps) is een populaire manier om de operationele efficiëntie te verbeteren. Statusgegevens zijn een basisinvoer voor machine learning-modellen voor het analyseren van statustrends. Met machine learning-modellen kunt u bijvoorbeeld het volgende doen:

• Extraheer meer inzichten uit statuswijzigingen en aanbevelingen voor acties.

• Analyseer statustrends in de loop van de tijd om de voorspelling van problemen en modelverfijning te stimuleren.

Uw gezondheidsmodel onderhouden

Het onderhouden van een statusmodel is een continue technische activiteit die wordt afgestemd op de ontwikkeling en bewerkingen van uw toepassing. Naarmate uw toepassing zich ontwikkelt, moet u ervoor zorgen dat uw gezondheidsmodel zich parallel ontwikkelt.

Behandel ook statusmodellen zoals workloadartefacten die moeten worden geïntegreerd in uw ontwikkelingslevenscyclus. Adopt infrastructure as code (IaC) voor consistent, versiebeheer van uw statusmodel. Gebruik automatisering zodat het model up-to-date blijft wanneer u infrastructuur en toepassingsonderdelen toevoegt aan of verwijdert uit de workload.

Gezondheidsgegevens nemen geleidelijk af in de loop van de tijd. Om de operationele efficiëntie te optimaliseren en de kosten te minimaliseren, moet u voorkomen dat statusgegevens langer dan 30 dagen worden bewaard. Indien nodig kunt u gegevens archiveren om te voldoen aan auditvereisten of in scenario's waarin een langetermijnpatroonanalyse in AI voor IT-bewerkingen is betrokken.

Notitie

Wanneer u statusgegevens archiveert, moet u deze koppelen aan de configuratiestatus van het model. Het interpreteren van statuswijzigingen kan lastig zijn zonder deze context.

Verwante koppelingen

• Zie Statuscontroles in ASP.NET Core voor het implementeren van statuscontroles in ASP.NET.
• Zie Overzicht van metrische gegevens van Azure Monitor voor meer informatie over het bewaken van metrische gegevens.
• Zie Application Insights voor meer informatie over het gebruik van Application Insights.
• Zie Health modeling and observeability for mission-critical workloads on Azure (Statusmodellering en waarneembaarheid voor bedrijfskritieke workloads in Azure) voor ontwerpoverwegingen en aanbevelingen die betrekking hebben op bedrijfskritieke workloads.
• Zie Een statusmodel ontwerpen voor uw bedrijfskritieke workload voor een praktische ervaring.

Volgende stap

Aanbevelingen voor het ontwerpen van een betrouwbare bewakings- en waarschuwingsstrategie