Delen via

Statusmodellering voor workloads

  • Artikel

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 onvermogen om driften van die basislijn te detecteren.

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 waarop u de workload kunt bewaken. Overweeg 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 veroorzaken van de verwachte operationele status. Door de status van een workload te modelleren, kunt u drift identificeren en weloverwogen operationele beslissingen nemen die van invloed zijn op het bedrijf.

Gezondheidsmodellering overbrugt de kloof tussen operationele kennis en bruikbare inzichten. Het helpt u kritieke problemen effectief te 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 subsystemen evalueert.

Terminologie Definitie
Statusmodellering Een waarneembaarheidsoefening die bedrijfscontext gebruikt om bewakingsgegevens als statussen te interpreteren.
Statusmodel Een grafische weergave van logische entiteiten en hun relaties voor een bepaald bereik. Elk knooppunt heeft een statusdefinitie om bewakingsgegevens in het model te rationaliseren.
Statusentiteit Een logisch onderdeel dat een afzonderlijke eenheid van een systeem, een logische combinatie van meerdere gerelateerde entiteiten of het algehele systeem vertegenwoordigt.
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 modelleerbereik waarin entiteiten afzonderlijke statusmodellen voor onderdeelsystemen vertegenwoordigen.

We raden u aan deze video te bekijken om inzicht te krijgen in statusmodellering op hoog niveau.

Wat is status, statusmodellering en een statusmodel?

De termstatus verwijst naar de operationele status van een entiteit en de bijbehorende afhankelijkheden. Deze 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 drie statussen weer te geven:

  • Gezond: Werkt optimaal en voldoet aan de kwaliteitswachtingen

  • Gedegradeerd: vertoont minder dan gezond gedrag, wat potentiële problemen aangeeft

  • Beschadigd: in een kritieke toestand en onmiddellijke aandacht vereist

Notitie

U kunt de status vertegenwoordigen 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 moet meetbaar zijn. Statusstatussen worden berekend met behulp van statussignalen, die afzonderlijke gegevensstromen zijn die inzicht geven in het operationele gedrag van een entiteit. Signalen kunnen metrische gegevens, logboeken, traceringen of andere kwaliteitskenmerken bevatten. Een statussignaal voor een vm-entiteit (virtuele machine) kan bijvoorbeeld het metrische cpu-gebruik bijhouden. Andere signalen voor deze entiteit kunnen geheugengebruik, netwerklatentie of foutpercentages omvatten.

Terwijl u statussignalen definieert, moet u rekening houden met de niet-functionele vereisten voor de workload. Neem in het voorbeeld van het 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 VIRTUELE machine kan bijvoorbeeld het volgende zijn:

  • In orde: belangrijke niet-functionele vereisten en doelen, zoals reactietijd, resourcegebruik en algehele systeemprestaties, zijn volledig tevreden. Zo wordt 95% van de aanvragen binnen 500 milliseconden verwerkt. De workload maakt gebruik van VM-resources zoals CPU, geheugen en opslag en onderhoudt een balans tussen de vraag naar workloads en de beschikbare capaciteit. Gebruikerservaring is op verwachte niveaus.

  • 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. 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 op verschillende bereiken kunt implementeren en toepassen als u goed inzicht hebt in de bedrijfsscenario's.

Een diagram met de definitie van het statusmodel.

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 geven een overzicht van niet-functionele vereisten voor bedrijfsscenario's die betrekking hebben op toepassings- en infrastructuuronderdelen. Deze samenvatting weerspiegelt de bedrijfswaarde voor de toepassing.

  • Relaties tussen entiteiten spiegelen 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 ondervindt in mislukte berichten 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 metrische piek in betalingen kan begrijpen, wordt deze stamkennis niet vaak gedeeld door het operations-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 op dat specifieke onderdeel richten.

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

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

  • Operators hebben waarschuwingen ontvangen op basis van statussen, waardoor onnodige ruis wordt verminderd. Operators hebben meldingen ontvangen die specifieke context hebben gegeven over de impact van het bedrijf op betalingen.

  • Afhankelijkheidsketens hebben operators geholpen de omvang van operationele problemen volledig te begrijpen. Deze kennis versnelde impactbeoordelingen en leidde tot reacties met prioriteit. Operators kunnen ook eenvoudig trapsgewijze of gecorreleerde problemen identificeren.

  • Operators voeren activiteiten na incidenten met nauwkeurigheid uit omdat het statusmodel inzicht biedt in de hoofdoorzaken van afwijkingen en de specifieke gezondheidssignalen die betrokken waren.

  • Het heeft de bewakingsgegevens zinvol gemaakt voor alle teamleden. Het overbrugde de kloof tussen stamkennis en gedeelde inzichten.

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

Schema voor statusmodel

Statusmodellen bieden een afzonderlijk gegevensschema dat is geoptimaliseerd voor gebruiksvoorbeelden voor waarneembaarheid. Dit schema neemt statusmodellering van een abstract concept naar een meetbare oplossing. Door uw specifieke vereisten, doelstellingen en architectuurcontext te modelleren, kunt u gezondheidsgegevens aanpassen aan uw unieke scenario.

Een diagram met de statusdefinitie.

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

Denk bijvoorbeeld aan 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 computers verschillen. Metrische gegevens over CPU-gebruik hebben waarschijnlijk invloed op de status van VM A en VM B kan prioriteit geven aan metrische gegevens met betrekking tot geheugen.

Belangrijk

Een statusmodel mag 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 betrekking heeft op de activiteiten die in de volgende secties worden beschreven.

Een diagram met statusmodelleringsactiviteiten.

Uw workloadontwerp evalueren

Begin 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-commerce-toepassing moet bijvoorbeeld de huidige status van kritieke processen vertegenwoordigen, zoals aanmelding, betaling en betalingen van gebruikers.

Contextualiseren met bedrijfsvereisten

Evalueer het relatieve belang en de algehele impact van elke stroom in uw organisatie. Overweeg factoren zoals gebruikerservaring, beveiliging en operationele efficiëntie. In de meeste scenario's is het mislukken van een betalingsproces bijvoorbeeld waarschijnlijk belangrijker 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 statusmodellering alleen wanneer u uw bedrijfsscenario's en context opneemt. Vervolgens kunt u de bedrijfsimpact van operationele problemen rationaliseren.

Toewijzen aan metrische gegevens over betrouwbaarheid

Zoek naar relevante metrische betrouwbaarheidsgegevens in het toepassingsontwerp .

Overweeg om serviceniveauindicatoren (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 overeenkomen met de specifieke gezondheidssignalen die worden overwogen voor uw statusmodel. Hierdoor maakt u een uitgebreide definitie van de status die nauwkeurig overeenkomt met het bereiken van een acceptabel serviceniveau voor de toepassing.

Belangrijk

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

Statussignalen identificeren

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

Metrische gegevens en logboeken van het platform 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 netwerk buiten en schijfbewerkingen per seconde. U kunt deze gegevens in uw statusmodel gebruiken om potentiële problemen te detecteren en voorspellen terwijl u een betrouwbare omgeving onderhoudt.

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

Notitie

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

Toepassingslogboeken toevoegen

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

  • 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 Azure Monitor-logboekwerkruimte in plaats van 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 statusbeoordeling en om eventuele gedetecteerde productieproblemen vast te stellen.

  • Logboeken van gebeurtenissen bij servicegrenzen. Neem een correlatie-id op die de servicegrenzen doorkruist. 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 vast te stellen.

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

  • Scheid toepassingslogboekregistratie van controle. Beheer auditlogboeken afzonderlijk van diagnostische logboeken. Hoewel auditrecords voldoen aan nalevings- of regelgevingsvereisten, voorkomt u dat er afzonderlijke 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 effectieve hoofdoorzaakanalyse (RCA) wanneer er fouten optreden.

Statustests gebruiken

Implementeer en voer statustests buiten de toepassing uit om expliciet de status en reactiesnelheid van uw toepassing te controleren. Testreacties gebruiken 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. Tests kunnen processen uitvoeren om latentie te meten en beschikbaarheid te controleren of om informatie uit de toepassing te extraheren. Zie het 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 voegt statuscontroles van meerdere onderdelen in de workload samen. Watchdogs kunnen ook code hosten die onmiddellijk herstel uitvoert voor bekende gezondheidsomstandigheden.

Structurele en functionele bewakingstechnieken aannemen

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

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

Het ontwerp modelleren

Vertegenwoordig 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 statusstatussen moeten worden doorgegeven via het model. Rapportageonderdelen zijn bijvoorbeeld mogelijk niet zo kritiek als andere onderdelen, wat resulteert in verschillende effecten op de algehele workloadstatus.

Waarschuwingen instellen waarvoor 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 basisgegevens voor waarneembaarheidsgegevens.

Normaal gesproken is er een een-op-een-toewijzing tussen bewakingsgegevens en waarschuwingsregels, wat kan leiden tot ongewenste resultaten, zoals waarschuwingsstormen en omgevingswaarschuwingsruis. In een rekencluster kunnen bijvoorbeeld grote volumes waarschuwingen op VM-niveau op basis van CPU-gebruik en aantal fouten operators overweldigen tijdens storingen en vertragingen in de oplossing veroorzaken. Als er een groot aantal geconfigureerde waarschuwingen is, resulteert omgevingswaarschuwingsruis 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. Houd rekening met het e-commercescenario. U kunt een waarschuwing instellen om meldingen te verzenden over wijzigingen in de status van de betalingsstroom voor processen in plaats van wijzigingen in onderliggende resources, zoals de Service Bus-wachtrij.

Notitie

De mogelijkheid om alle lagen van het statusmodel te waarschuwen, biedt flexibiliteit voor de verschillende persona's van de workload. 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 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 overeenkomt met de bedrijfscontext en bruikbare inzichten biedt.

Wanneer u uw statusmodel visualiseert, kunt u overwegen om 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 kleurgecodeerde statussen te identificeren, kunt u de hoofdoorzaak van elke toepassingsdegradatie efficiënt vinden.

In het diagram ziet u een statusmodel dat gebruikmaakt van een verkeerslichtbenadering.

Notitie

We raden u aan om toegankelijkheidsvereisten te overwegen voor mensen met een visuele handicap wanneer u een dashboard voor uw gezondheidsmodel maakt. Zie Architectuurontwerpdiagrammen voor aanbevolen procedures voor diagrammen.

Uw gezondheidsmodel gebruiken

Nadat u een statusmodel hebt gebouwd, moet u rekening houden met de volgende use cases om detectie en interpretatie van fouten of operationele problemen te stimuleren.

Toepasbaarheid op verschillende rollen

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

Pas gezondheidsinzichten aan voor verschillende belanghebbenden. Overweeg om afzonderlijke modellen te maken van overlappende gegevenssets.

Continue validatie

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

Organisatiestatus

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

Op individueel workloadniveau bieden statusmodellen een basis voor 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 gezondheidsmodellen combineren in een constructie op hoog niveau door een model van modellen te bouwen. U kunt bijvoorbeeld de waarneembaarheidsvoetafdruk van een bedrijfseenheid of een hele cloudomgeving bouwen met behulp van statusmodellen als onderdelen binnen een groter model. Statusmodellen vertegenwoordigen workloads binnen de activa als knooppunten in de grafiek op het hoogste niveau. Gebruik de relaties in dit model om afhankelijkheden tussen toepassingen vast te leggen, waaronder gegevensstromen, serviceinteracties en gedeelde infrastructuur.

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

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 om statustrends te analyseren. Machine Learning-modellen kunnen bijvoorbeeld het volgende doen:

  • Extra inzichten uit statuswijzigingen extraheren en acties aanbevelen.

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

Uw statusmodel onderhouden

Het onderhouden van een health-model is een continue engineeringactiviteit die overeenkomt met de ontwikkeling en bewerkingen van uw toepassing. Wanneer uw toepassing zich ontwikkelt, moet u ervoor zorgen dat uw statusmodel parallel wordt ontwikkeld.

Behandel ook statusmodellen zoals workloadartefacten die moeten worden geïntegreerd in uw ontwikkelingslevenscyclus. Gebruik infrastructuur als 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 waarde in de loop van de tijd. Om de operationele efficiëntie te optimaliseren en de kosten te minimaliseren, vermijdt u het bewaren van statusgegevens na 30 dagen. Indien nodig kunt u gegevens archiveren om te voldoen aan de auditvereisten of in scenario's waarin 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.

Volgende stap

Aanbevelingen voor het ontwerpen van een betrouwbare bewakings- en waarschuwingsstrategie