Delen via

Statusmodellering en waarneembaarheid van bedrijfskritieke workloads in Azure

  • Artikel

Statusmodellering en waarneembaarheid zijn essentiële concepten voor het maximaliseren van betrouwbaarheid, die gericht is op robuuste en gecontextualiseerde instrumentatie en bewaking. Deze concepten bieden een essentieel inzicht in de status van toepassingen, wat de snelle identificatie en oplossing van problemen bevordert.

De meeste bedrijfskritieke toepassingen zijn zowel qua schaal als qua complexiteit belangrijk en genereren daarom grote hoeveelheden operationele gegevens, waardoor het lastig is om optimale operationele actie te evalueren en te bepalen. Statusmodellering streeft er uiteindelijk naar om de waarneembaarheid te maximaliseren door onbewerkte bewakingslogboeken en metrische gegevens uit te voeren met belangrijke bedrijfsvereisten om de status van toepassingen te kwantificeren, waardoor automatische evaluatie van statussen wordt aangestuurd om consistente en versnelde bewerkingen te bereiken.

Dit ontwerpgebied is gericht op het proces voor het definiëren van een robuust statusmodel, waarbij gekwantificeerde statussen van toepassingen worden toegewezen via waarneembaarheid en operationele constructies om operationele volwassenheid te bereiken.

Belangrijk

Dit artikel maakt deel uit van de reeks bedrijfskritische workloads van Azure Well-Architected . Als u niet bekend bent met deze reeks, raden we u aan te beginnen met wat is een essentiële workload?

Er zijn drie belangrijke niveaus van operationele volwassenheid bij het streven naar maximale betrouwbaarheid.

  1. Problemen detecteren en erop reageren wanneer ze zich voordoen.
  2. Problemen vaststellen die zich voordoen of al zijn opgetreden.
  3. Voorspel en voorkom problemen voordat ze plaatsvinden.

Video: Een statusmodel definiëren voor uw bedrijfskritieke workload

Status van gelaagde toepassing

Als u een statusmodel wilt bouwen, definieert u eerst de toepassingsstatus in de context van de belangrijkste bedrijfsvereisten door de statussen 'gezond' en 'beschadigd' te kwantificeren in een gelaagde en meetbare indeling. Verfijn vervolgens voor elk toepassingsonderdeel de definitie in de context van een stabiele actieve status en geaggregeerd op basis van de gebruikersstromen van de toepassing. Plaats boven op de belangrijkste niet-functionele bedrijfsvereisten voor prestaties en beschikbaarheid. Ten slotte voegt u de statussen voor elke afzonderlijke gebruikersstroom samen om een acceptabele weergave van de algehele toepassingsstatus te vormen. Zodra deze gelaagde statusdefinities tot stand zijn gebracht, moeten ze worden gebruikt om kritieke metrische bewakingsgegevens voor alle systeemonderdelen te informeren en de samenstelling van het operationele subsysteem te valideren.

Belangrijk

Wanneer u definieert welke statussen 'niet in orde' zijn, vertegenwoordigt u voor alle niveaus van de toepassing. Het is belangrijk om onderscheid te maken tussen tijdelijke en niet-tijdelijke foutstatussen om servicevermindering ten opzichte van niet-beschikbaarheid te kwalificeren.

Overwegingen bij het ontwerpen

  • Het proces van modelleringsstatus is een top-down ontwerpactiviteit die begint met een architectuuroefening om alle gebruikersstromen te definiëren en afhankelijkheden tussen functionele en logische onderdelen toe te wijzen, waardoor afhankelijkheden tussen Azure-resources impliciet worden toegewezen.

  • Een statusmodel is volledig afhankelijk van de context van de oplossing die het vertegenwoordigt en kan daarom niet 'out-of-the-box' worden opgelost omdat 'one size doesn't fit all'.

    • Toepassingen verschillen in samenstelling en afhankelijkheden
    • Metrische en metrische drempelwaarden voor resources moeten ook nauwkeurig worden afgestemd op de waarden die een gezonde en slechte status vertegenwoordigen. Deze waarden worden sterk beïnvloed door de functionaliteit van de omvattende toepassing en niet-functionele vereisten.

  • Met een gelaagd statusmodel kan de toepassingsstatus worden getraceerd naar afhankelijkheden op een lager niveau, waardoor de service snel wordt gedegradeerd.

  • Als u statussen voor een afzonderlijk onderdeel wilt vastleggen, moeten de afzonderlijke operationele kenmerken van dat onderdeel worden begrepen onder een stabiele status die de productiebelasting weerspiegelt. Prestatietests zijn daarom een belangrijke mogelijkheid om de toepassingsstatus te definiëren en voortdurend te evalueren.

  • Fouten in een cloudoplossing treden mogelijk niet geïsoleerd op. Een storing in één onderdeel kan ertoe leiden dat verschillende mogelijkheden of extra onderdelen niet meer beschikbaar zijn.

    • Dergelijke fouten zijn mogelijk niet onmiddellijk waarneembaar.

Ontwerpaanbeveling

  • Definieer een meetbaar statusmodel als prioriteit om een duidelijk operationeel begrip van de hele toepassing te garanderen.

    • Het statusmodel moet gelaagd zijn en een weerspiegeling zijn van de toepassingsstructuur.
    • De basislaag moet rekening houden met afzonderlijke toepassingsonderdelen, zoals Azure-resources.
    • Basisonderdelen moeten worden samengevoegd naast belangrijke niet-functionele vereisten om een bedrijfscontextuele lens te bouwen in de status van systeemstromen.
    • Systeemstromen moeten worden samengevoegd met de juiste gewichten op basis van bedrijfskritiek om een zinvolle definitie van de algehele toepassingsstatus te maken. Financieel belangrijke of klantgerichte gebruikersstromen moeten prioriteit krijgen.
    • In elke laag van het statusmodel moet worden vastgelegd welke statussen 'in orde' en 'niet in orde' zijn.
    • Zorg ervoor dat het health-model onderscheid kan maken tussen tijdelijke en niet-tijdelijke slechte statussen om servicedegradatie te isoleren van niet-beschikbaarheid.

  • Statussen weergeven met behulp van een gedetailleerde statusscore voor elk afzonderlijke toepassingsonderdeel en elke gebruikersstroom door statusscores voor toegewezen afhankelijke onderdelen te aggregeren, waarbij belangrijke niet-functionele vereisten als coëfficiënten worden overwogen.

    • De statusscore voor een gebruikersstroom moet worden vertegenwoordigd door de laagste score voor alle toegewezen onderdelen, waarbij rekening wordt gehouden met relatieve prestaties ten opzichte van niet-functionele vereisten voor de gebruikersstroom.
    • Het model dat wordt gebruikt om de statusscores te berekenen, moet consistent de bedrijfsstatus weerspiegelen. Als dat niet het geval is, moet het model worden aangepast en opnieuw worden geïmplementeerd om nieuwe bevindingen weer te geven.
    • Definieer drempelwaarden voor de statusscore om de status weer te geven.

  • De statusscore moet automatisch worden berekend op basis van onderliggende metrische gegevens, die kunnen worden gevisualiseerd via waarneembaarheidspatronen en waarop kan worden gereageerd via geautomatiseerde operationele procedures.

    • De statusscore moet de kern van de bewakingsoplossing worden, zodat operationele teams geen operationele gegevens meer hoeven te interpreteren en toewijzen aan de toepassingsstatus.

  • Gebruik het statusmodel om de mate van beschikbaarheidsdoelstelling (SLO) te berekenen in plaats van onbewerkte beschikbaarheid, zodat de afbakening tussen servicedegradatie en niet-beschikbaarheid wordt weergegeven als afzonderlijke SLO's.

  • Gebruik het statusmodel in CI/CD-pijplijnen en testcycli om te controleren of de toepassingsstatus wordt gehandhaafd na code- en configuratie-updates.

    • Het statusmodel moet worden gebruikt om de status te observeren en te valideren tijdens belastingstests en chaostests als onderdeel van CI/CD-processen.

  • Het bouwen en onderhouden van een gezondheidsmodel is een iteratief proces en technische investeringen moeten worden afgestemd om continue verbeteringen te stimuleren.

    • Definieer een proces om de nauwkeurigheid van het model voortdurend te evalueren en af te stemmen, en overweeg te investeren in machine learning-modellen om het model verder te trainen.

Voorbeeld: gelaagd statusmodel

Dit is een vereenvoudigde weergave van een gelaagd toepassingsstatusmodel voor illustratieve doeleinden. Een uitgebreid en gecontextualiseerd statusmodel wordt geboden in de Mission-Critical referentie-implementaties:

Bij het implementeren van een statusmodel is het belangrijk om de status van afzonderlijke onderdelen te definiëren via de aggregatie en interpretatie van belangrijke metrische gegevens op resourceniveau. Een voorbeeld van hoe metrische resourcegegevens kunnen worden gebruikt, is de onderstaande afbeelding:

Bedrijfskritieke voorbeeldstatusdefinities

Deze definitie van status kan vervolgens worden weergegeven door een KQL-query, zoals wordt gedemonstreerd door de onderstaande voorbeeldquery waarin InsightsMetrics (Container Insights) en AzureMetrics (diagnostische instelling voor AKS-cluster) worden samengevoegd en (inner join) wordt vergeleken met gemodelleerde statusdrempels.

// ClusterHealthStatus
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
    // Disk Usage:
    "used_percent", 50, 80,
    // Average node cpu usage %:
    "node_cpu_usage_percentage", 60, 90,
    // Average node disk usage %:
    "node_disk_usage_percentage", 60, 80,
    // Average node memory usage %:
    "node_memory_rss_percentage", 60, 80
    ];
InsightsMetrics
| summarize arg_max(TimeGenerated, *) by Computer, Name
| project TimeGenerated,Computer, Namespace, MetricName = Name, Value=Val
| extend NodeName = extract("([a-z0-9-]*)(-)([a-z0-9]*)$", 3, Computer)
| union (
    AzureMetrics
    | extend ResourceType = extract("(PROVIDERS/MICROSOFT.)([A-Z]*/[A-Z]*)", 2, ResourceId)
    | where ResourceType == "CONTAINERSERVICE/MANAGEDCLUSTERS"
    | summarize arg_max(TimeGenerated, *) by MetricName
    | project TimeGenerated, MetricName, Namespace = "AzureMetrics", Value=Average
    )
| lookup kind=inner Thresholds on MetricName
| extend IsYellow = iff(Value > YellowThreshold and Value < RedThreshold, 1, 0)
| extend IsRed = iff(Value > RedThreshold, 1, 0)
| project NodeName, MetricName, Value, YellowThreshold, IsYellow, RedThreshold, IsRed

De resulterende tabeluitvoer kan vervolgens worden omgezet in een statusscore voor eenvoudigere aggregatie op hogere niveaus van het statusmodel.

// ClusterHealthScore
ClusterHealthStatus
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed)
| extend HealthScore = 1-(YellowScore*0.25)-(RedScore*0.5)

Deze geaggregeerde scores kunnen vervolgens worden weergegeven als een afhankelijkheidsdiagram met behulp van visualisatiehulpmiddelen zoals Grafana om het statusmodel te illustreren.

In deze afbeelding ziet u een voorbeeld van een gelaagd statusmodel uit de onlinereferentie-implementatie van Azure Mission-Critical en ziet u hoe een wijziging in de status van een fundamenteel onderdeel een trapsgewijze impact kan hebben op gebruikersstromen en de algehele toepassingsstatus (de voorbeeldwaarden komen overeen met de tabel in de vorige afbeelding).

Mission Critical Example Health Model Visualization

Demovideo: Demo over bewaking en statusmodellering

Geïntegreerde gegevenssink voor gecorreleerde analyse

Veel operationele gegevenssets moeten worden verzameld uit alle systeemonderdelen om een nauwkeurig gedefinieerd statusmodel weer te geven, rekening houdend met logboeken en metrische gegevens van zowel toepassingsonderdelen als onderliggende Azure-resources. Deze enorme hoeveelheid gegevens moet uiteindelijk worden opgeslagen in een indeling die vrijwel realtime interpretatie mogelijk maakt om snelle operationele actie mogelijk te maken. Bovendien is correlatie tussen alle omvattende gegevenssets vereist om ervoor te zorgen dat effectieve analyse niet gebonden is, waardoor een gelaagde weergave van de status mogelijk is.

Een geïntegreerde gegevenssink is vereist om ervoor te zorgen dat alle operationele gegevens snel worden opgeslagen en beschikbaar worden gesteld voor gecorreleerde analyse om een 'één deelvenster'-weergave van de toepassingsstatus te bouwen. Azure biedt verschillende operationele technologieën onder de paraplu van Azure Monitor en de Log Analytics-werkruimte fungeert als de belangrijkste azure-systeemeigen gegevenssink voor het opslaan en analyseren van operationele gegevens.

Mission Critical Health Data Collection

Overwegingen bij het ontwerpen

Azure Monitor

  • Azure Monitor is standaard ingeschakeld voor alle Azure-abonnementen, maar Azure Monitor-logboeken (Log Analytics-werkruimte) en Application Insights-resources moeten worden geïmplementeerd en geconfigureerd om mogelijkheden voor gegevensverzameling en query's op te nemen.

  • Azure Monitor ondersteunt drie typen waarneembaarheidsgegevens: logboeken, metrische gegevens en gedistribueerde traceringen.

    • Logboeken worden opgeslagen in Log Analytics-werkruimten, die zijn gebaseerd op Azure Data Explorer. Logboekquery's worden opgeslagen in querypakketten die kunnen worden gedeeld tussen abonnementen en worden gebruikt om waarneembaarheidsonderdelen zoals dashboards, werkmappen of andere hulpprogramma's voor rapportage en visualisatie aan te drijven.
    • Metrische gegevens worden opgeslagen in een interne tijdreeksdatabase. Voor de meeste Azure-resources worden metrische gegevens automatisch verzameld en gedurende 93 dagen bewaard . Metrische gegevens kunnen ook worden verzonden naar de Log Analytics-werkruimte met behulp van een diagnostische instelling voor de resource.

  • Alle Azure-resources bevatten logboeken en metrische gegevens, maar resources moeten op de juiste manier worden geconfigureerd om diagnostische gegevens te routeren naar de gewenste gegevenssink.

Tip

Azure biedt verschillende ingebouwde beleidsregels die kunnen worden toegepast om ervoor te zorgen dat geïmplementeerde resources zijn geconfigureerd voor het verzenden van logboeken en metrische gegevens naar een Log Analytics-werkruimte.

  • Het is niet ongebruikelijk dat regelgevingscontroles vereisen dat operationele gegevens binnen oorspronkelijke geografische gebieden of landen/regio's blijven. Wettelijke vereisten kunnen bepalen dat kritieke gegevenstypen gedurende een langere periode worden bewaard. In gereguleerd bankieren moeten auditgegevens bijvoorbeeld ten minste zeven jaar worden bewaard.

  • Voor verschillende typen operationele gegevens zijn mogelijk verschillende bewaarperioden vereist. Beveiligingslogboeken moeten bijvoorbeeld gedurende een lange periode worden bewaard, terwijl prestatiegegevens waarschijnlijk geen langetermijnretentie vereisen buiten de context van AIOps.

  • Gegevens kunnen worden gearchiveerd of geëxporteerd vanuit Log Analytics-werkruimten voor langetermijnretentie en/of controledoeleinden.

  • Toegewezen clusters bieden een implementatieoptie waarmee Beschikbaarheidszones kan worden beschermd tegen zonefouten in ondersteunde Azure-regio's. Toegewezen clusters vereisen een minimale dagelijkse toezegging voor gegevensopname.

  • Log Analytics-werkruimten worden geïmplementeerd in een opgegeven Azure-regio.

  • Resources kunnen worden geconfigureerd met meerdere diagnostische instellingen om te voorkomen dat er gegevens verloren gaan als een Log Analytics-werkruimte niet beschikbaar is. Elke diagnostische instelling kan metrische gegevens en logboeken verzenden naar een afzonderlijke Log Analytics-werkruimte.

    • Voor gegevens die naar elke extra Log Analytics-werkruimte worden verzonden, worden extra kosten in rekening gebracht.
    • De redundante Log Analytics-werkruimte kan worden geïmplementeerd in dezelfde Azure-regio of in afzonderlijke Azure-regio's voor extra regionale redundantie.
    • Voor het verzenden van logboeken en metrische gegevens van een Azure-resource naar een Log Analytics-werkruimte in een andere regio worden kosten in rekening gebracht voor uitgaande gegevens tussen regio's.
    • Voor sommige Azure-resources is een Log Analytics-werkruimte vereist binnen dezelfde regio als de resource zelf.
    • Zie Best practices voor Azure Monitor-logboeken voor meer beschikbaarheidsopties voor de Log Analytics-werkruimte.

  • Log Analytics-werkruimtegegevens kunnen continu, gepland of eenmalig worden geëxporteerd naar Azure Storage of Azure Event Hubs.

    • Gegevensexport maakt langetermijnarchivering van gegevens mogelijk en beschermt tegen mogelijk verlies van operationele gegevens als gevolg van niet-beschikbaarheid.
    • Beschikbare exportbestemmingen zijn Azure Storage of Azure Event Hubs. Azure Storage kan worden geconfigureerd voor verschillende redundantieniveaus , waaronder zonegebonden of regionaal. Bij gegevensexport naar Azure Storage worden de gegevens opgeslagen in JSON-bestanden.
    • Bestemmingen voor gegevensexport moeten zich binnen dezelfde Azure-regio bevinden als de Log Analytics-werkruimte. Een Event Hub-doel voor gegevensexport moet zich binnen dezelfde regio bevinden als de Log Analytics-werkruimte. Azure Event Hubs geo-herstel na noodgevallen is niet van toepassing op dit scenario.
    • Er gelden verschillende beperkingen voor het exporteren van gegevens. Alleen specifieke tabellen in de werkruimte worden ondersteund voor gegevensexport.
    • Archiveren kan worden gebruikt om gegevens op te slaan in een Log Analytics-werkruimte voor langetermijnretentie tegen lagere kosten zonder deze te exporteren.

  • Azure Monitor-logboeken hebben beperkingslimieten voor gebruikersquery's, die kunnen worden weergegeven als verminderde beschikbaarheid voor clients, zoals waarneembaarheidsdashboards.

    • Vijf gelijktijdige query's per gebruiker: als er al vijf query's worden uitgevoerd, worden er extra query's in een gelijktijdigheidswachtrij per gebruiker geplaatst totdat een actieve query eindigt.
    • Tijd in de wachtrij voor gelijktijdigheid: als een query langer dan drie minuten in de gelijktijdigheidswachtrij staat, wordt deze beëindigd en wordt een 429-foutcode geretourneerd.
    • Limiet voor de diepte van de gelijktijdigheidswachtrij: de gelijktijdigheidswachtrij is beperkt tot 200 query's en extra query's worden geweigerd met foutcode 429.
    • Limiet voor queryfrequentie: er is een limiet van 200 query's per gebruiker per 30 seconden in alle werkruimten.

  • Querypakketten zijn Azure Resource Manager-resources, die kunnen worden gebruikt om logboekquery's te beveiligen en te herstellen als de Log Analytics-werkruimte niet beschikbaar is.

    • Querypakketten bevatten query's als JSON en kunnen extern worden opgeslagen in Azure, vergelijkbaar met andere infrastructure-as-code-assets.
      • Kan worden geïmplementeerd via de Microsoft.Insights REST API.
      • Als een Log Analytics-werkruimte opnieuw moet worden gemaakt, kan het querypakket opnieuw worden geïmplementeerd vanuit een extern opgeslagen definitie.

  • Application Insights kan worden geïmplementeerd in een implementatiemodel op basis van een werkruimte, ondersteund door een Log Analytics-werkruimte waarin alle gegevens worden opgeslagen.

  • Steekproeven kunnen worden ingeschakeld in Application Insights om de hoeveelheid verzonden telemetrie te verminderen en de kosten voor gegevensopname te optimaliseren.

  • Alle gegevens die door Azure Monitor worden verzameld, inclusief Application Insights, worden in rekening gebracht op basis van het volume van de gegevensopname en de duur van de gegevens die worden bewaard.

    • Gegevens die worden opgenomen in een Log Analytics-werkruimte, kunnen zonder extra kosten worden bewaard tot de eerste 31 dagen (90 dagen als Sentinel is ingeschakeld)
    • Gegevens die worden opgenomen in application insights op basis van een werkruimte, worden de eerste 90 dagen zonder extra kosten bewaard.

  • Het prijsmodel van de Log Analytics-toezeggingslaag biedt een lagere kosten en een voorspelbare benadering van kosten voor gegevensopname.

    • Elk gebruik boven het reserveringsniveau wordt gefactureerd tegen dezelfde prijs als de huidige laag.

  • Log Analytics, Application Insights en Azure Data Explorer de Kusto-querytaal (KQL) gebruiken.

  • Log Analytics-query's worden opgeslagen als functies in de Log Analytics-werkruimte (savedSearches).

Ontwerpaanbeveling

  • Gebruik de Log Analytics-werkruimte als een geïntegreerde gegevenssink om een 'enkel deelvenster' te bieden voor alle operationele gegevenssets.

    • Log Analytics-werkruimten gedecentraliseerd in alle gebruikte implementatieregio's. Elke Azure-regio met een toepassingsimplementatie moet rekening houden met een Log Analytics-werkruimte om alle operationele gegevens te verzamelen die afkomstig zijn van die regio. Alle globale resources moeten gebruikmaken van een afzonderlijke toegewezen Log Analytics-werkruimte, die moet worden geïmplementeerd in een primaire implementatieregio.
      • Als u alle operationele gegevens naar één Log Analytics-werkruimte verzendt, ontstaat er een Single Point of Failure.
      • Vereisten voor gegevenslocatie kunnen voorkomen dat gegevens de oorspronkelijke regio verlaten. Federatieve werkruimten lossen deze vereiste standaard op.
      • Er zijn aanzienlijke kosten verbonden aan het overdragen van logboeken en metrische gegevens tussen regio's.
    • Alle implementatiestempels binnen dezelfde regio kunnen dezelfde regionale Log Analytics-werkruimte gebruiken.

  • Overweeg om resources te configureren met meerdere diagnostische instellingen die verwijzen naar verschillende Log Analytics-werkruimten ter bescherming tegen niet-beschikbaarheid van Azure Monitor voor toepassingen met minder regionale implementatiestempels.

  • Gebruik Application Insights als een consistent APM-hulpprogramma (Application Performance Monitoring) voor alle toepassingsonderdelen om toepassingslogboeken, metrische gegevens en traceringen te verzamelen.

    • Implementeer Application Insights in een configuratie op basis van een werkruimte om ervoor te zorgen dat elke regionale Log Analytics-werkruimte logboeken en metrische gegevens bevat van zowel toepassingsonderdelen als onderliggende Azure-resources.

  • Gebruik query's voor meerdere werkruimten om één enkel deelvenster in de verschillende werkruimten te onderhouden.

  • Gebruik querypakketten om logboekquery's te beveiligen in het geval de werkruimte niet beschikbaar is.

    • Sla querypakketten op in de git-opslagplaats van de toepassing als infrastructure-as-code-assets.

  • Alle Log Analytics-werkruimten moeten worden behandeld als langlopende resources met een andere levenscyclus dan toepassingsresources binnen een regionale implementatiestempel.

  • Exporteer kritieke operationele gegevens uit de Log Analytics-werkruimte voor langetermijnretentie en analyse om AIOps en geavanceerde analyses te vergemakkelijken om het onderliggende statusmodel te verfijnen en voorspellende actie te ondersteunen.

  • Zorgvuldig evalueren welk gegevensarchief moet worden gebruikt voor langetermijnretentie; niet alle gegevens moeten worden opgeslagen in een dynamisch gegevensarchief waarop query's kunnen worden uitgevoerd.

    • Het wordt sterk aanbevolen om Azure Storage te gebruiken in een GRS-configuratie voor langdurige operationele gegevensopslag.
      • Gebruik de log analytics-werkruimte exportmogelijkheid om alle beschikbare gegevensbronnen te exporteren naar Azure Storage.

  • Selecteer de juiste retentieperioden voor operationele gegevenstypen in Log Analytics, waarbij u langere retentieperioden configureert binnen de werkruimte waar 'dynamische' waarneembaarheidsvereisten bestaan.

  • Gebruik Azure Policy om ervoor te zorgen dat alle regionale resources operationele gegevens doorsturen naar de juiste Log Analytics-werkruimte.

Notitie

Wanneer u implementeert in een Azure-landingszone en er een vereiste is voor gecentraliseerde opslag van operationele gegevens, kunt u gegevens bij het starten splitsen , zodat deze worden opgenomen in zowel gecentraliseerde hulpprogramma's als Log Analytics-werkruimten die zijn toegewezen aan de toepassing. U kunt ook toegang tot Log Analytics-werkruimten van de toepassing beschikbaar maken, zodat centrale teams toepassingsgegevens kunnen opvragen. Het is uiteindelijk essentieel dat operationele gegevens die afkomstig zijn van de oplossing beschikbaar zijn in Log Analytics-werkruimten die zijn toegewezen aan de toepassing.

Als SIEM-integratie is vereist, verzendt u geen onbewerkte logboekvermeldingen, maar in plaats daarvan kritieke waarschuwingen.

  • Configureer steekproeven alleen binnen Application Insights als dit is vereist om de prestaties te optimaliseren, of als steekproeven niet duur zijn.

    • Overmatige steekproeven kunnen leiden tot gemiste of onnauwkeurige operationele signalen.

  • Gebruik correlatie-id's voor alle traceringsgebeurtenissen en logboekberichten om deze te koppelen aan een bepaalde aanvraag.

    • Retourneer correlatie-id's naar de aanroeper voor alle aanroepen, niet alleen mislukte aanvragen.

  • Zorg ervoor dat toepassingscode de juiste instrumentatie en logboekregistratie bevat om het statusmodel te informeren en latere probleemoplossing of hoofdoorzaakanalyse mogelijk te maken, indien nodig.

    • Toepassingscode moet Application Insights gebruiken om gedistribueerde tracering mogelijk te maken, door de aanroeper een uitgebreid foutbericht te geven dat een correlatie-id bevat wanneer er een fout optreedt.

  • Gebruik gestructureerde logboekregistratie voor alle logboekberichten.

  • Voeg zinvolle statustests toe aan alle toepassingsonderdelen.

    • Wanneer u AKS gebruikt, configureert u de statuseindpunten voor elke implementatie (pod), zodat Kubernetes correct kan bepalen of een pod in orde of beschadigd is.
    • Wanneer u Azure App Service gebruikt, configureert u de statuscontroles zo dat uitschaalbewerkingen geen fouten veroorzaken door verkeer te verzenden naar exemplaren die nog niet gereed zijn en ervoor te zorgen dat beschadigde exemplaren snel worden gerecycled.

Als de toepassing is geabonneerd op Microsoft Mission-Critical Support, kunt u overwegen om belangrijke statustests beschikbaar te maken voor Microsoft Ondersteuning, zodat de toepassingsstatus nauwkeuriger kan worden gemodelleerd door Microsoft Ondersteuning.

  • Aanvragen voor geslaagde statuscontrole vastleggen, tenzij verhoogde gegevensvolumes niet kunnen worden getolereerd in de context van toepassingsprestaties, omdat ze aanvullende inzichten bieden voor analytische modellering.

  • Configureer log analytics-werkruimten voor productie niet om een daglimiet toe te passen, waardoor de dagelijkse opname van operationele gegevens wordt beperkt, omdat dit kan leiden tot het verlies van kritieke operationele gegevens.

    • In lagere omgevingen, zoals Ontwikkeling en Testen, kan een daglimiet worden beschouwd als een optioneel kostenbesparend mechanisme.

  • Als de opnamevolumes van operationele gegevens voldoen aan de drempelwaarde voor de minimumlaag, configureert u Log Analytics-werkruimten om prijsstelling op basis van toezeggingslagen te gebruiken om kostenefficiëntie te verhogen ten opzichte van het prijsmodel 'betalen per gebruik'.

  • Het wordt sterk aanbevolen om Log Analytics-query's op te slaan met behulp van broncodebeheer en CI/CD-automatisering te gebruiken om ze te implementeren in relevante Log Analytics-werkruimte-exemplaren.

Visualisatie

Het visueel weergeven van het statusmodel met kritieke operationele gegevens is essentieel om effectieve bewerkingen te realiseren en de betrouwbaarheid te maximaliseren. Dashboards moeten uiteindelijk worden gebruikt om bijna realtime inzicht te bieden in de toepassingsstatus voor DevOps-teams, waardoor de snelle diagnose van afwijkingen van een stabiele status mogelijk wordt.

Microsoft biedt verschillende technologieën voor gegevensvisualisatie, waaronder Azure Dashboards, Power BI en Azure Managed Grafana (momenteel in preview). Azure Dashboards biedt een nauw geïntegreerde, out-of-the-box visualisatieoplossing voor operationele gegevens in Azure Monitor. Het heeft daarom een fundamentele rol te spelen bij de visuele weergave van operationele gegevens en toepassingsstatus voor een bedrijfskritieke workload. Er zijn echter verschillende beperkingen met betrekking tot de positionering van Azure-dashboards als een holistisch waarneembaarheidsplatform. Als gevolg hiervan moet er aandacht worden besteed aan het aanvullende gebruik van toonaangevende waarneembaarheidsoplossingen, zoals Grafana, die ook als een beheerde oplossing in Azure wordt aangeboden.

Deze sectie is gericht op het gebruik van Azure Dashboards en Grafana om een robuuste dashboardervaring te bouwen waarmee technische en zakelijke lenzen kunnen worden geboden voor de status van toepassingen, waardoor DevOps-teams en een effectieve werking mogelijk worden. Robuuste dashboarding is essentieel om problemen te diagnosticeren die al zijn opgetreden en operationele teams te ondersteunen bij het detecteren van en reageren op problemen wanneer ze zich voordoen.

Overwegingen bij het ontwerpen

  • Wanneer u het statusmodel visualiseert met behulp van logboekquery's, moet u er rekening mee houden dat er Log Analytics-limieten zijn voor gelijktijdige en in de wachtrij geplaatste query's, evenals de algehele queryfrequentie, waarbij volgende query's in de wachtrij worden geplaatst en beperkt.

  • Query's voor het ophalen van operationele gegevens die worden gebruikt om statusscores te berekenen en weer te geven, kunnen worden geschreven en uitgevoerd in Log Analytics of Azure Data Explorer.

    • Voorbeeldquery's zijn hier beschikbaar.

  • Log Analytics legt verschillende querylimieten op, die moeten worden ontworpen voor het ontwerpen van operationele dashboards.

  • De visualisatie van metrische gegevens van onbewerkte resources, zoals CPU-gebruik of netwerkdoorvoer, vereist een handmatige evaluatie door operationele teams om de gevolgen van de status te bepalen. Dit kan lastig zijn tijdens een actief incident.

  • Als meerdere gebruikers dashboards gebruiken in een hulpprogramma zoals Grafana, wordt het aantal query's dat naar Log Analytics wordt verzonden snel vermenigvuldigd.

    • Als u de limiet voor gelijktijdige query's in Log Analytics bereikt, worden volgende query's in de wachtrij geplaatst, waardoor de dashboardervaring 'traag' aanvoelt.

Ontwerpaanbeveling

  • Verzamel en presenteer query-uitvoer van alle regionale Log Analytics-werkruimten en de globale Log Analytics-werkruimte om een uniforme weergave van de toepassingsstatus te maken.

Notitie

Als u implementeert in een Azure-landingszone, kunt u overwegen om een query uit te voeren op de Log Analytics-werkruimte van het centrale platform als er belangrijke afhankelijkheden van platformresources bestaan, zoals ExpressRoute voor on-premises communicatie.

  • Een verkeerslichtmodel moet worden gebruikt om de status 'gezond' en 'beschadigd' visueel weer te geven, waarbij groen wordt gebruikt om aan te geven wanneer aan belangrijke niet-functionele vereisten volledig is voldaan en resources optimaal worden gebruikt. Gebruik 'Groen', 'Oranje' en 'Rood' om de statussen 'In orde', 'Gedegradeerd' en 'Niet beschikbaar' weer te geven.

  • Gebruik Azure Dashboards om operationele lenzen te maken voor wereldwijde resources en regionale implementatiestempels, die belangrijke metrische gegevens vertegenwoordigen, zoals het aantal aanvragen voor Azure Front Door, latentie aan de serverzijde voor Azure Cosmos DB, inkomende/uitgaande berichten voor Event Hubs en CPU-gebruik of implementatiestatussen voor AKS. Dashboards moeten worden aangepast om de operationele effectiviteit te stimuleren, door kennis op te doen van foutscenario's om ervoor te zorgen dat DevOps-teams direct inzicht hebben in belangrijke metrische gegevens.

  • Als Azure Dashboards niet kunnen worden gebruikt om het statusmodel en de vereiste bedrijfsvereisten nauwkeurig weer te geven, wordt het ten zeerste aanbevolen grafana te gebruiken als een alternatieve visualisatieoplossing, die toonaangevende mogelijkheden en een uitgebreid opensource-invoegtoepassingsecosysteem biedt. Evalueer de preview-versie van Beheerde Grafana om de operationele complexiteit van het beheren van de Grafana-infrastructuur te voorkomen.

  • Gebruik bij het implementeren van zelf-hostende Grafana een maximaal beschikbaar en geografisch gedistribueerd ontwerp om ervoor te zorgen dat kritieke operationele dashboards bestand zijn tegen regionale platformfouten en trapsgewijze foutscenario's.

    • Scheid de configuratiestatus in een extern gegevensarchief, zoals Azure Database for Postgres of MySQL, om ervoor te zorgen dat Grafana-toepassingsknooppunten staatloos blijven.

      • Configureer databasereplicatie tussen implementatieregio's.

    • Implementeer Grafana-knooppunten in App Services in een configuratie met hoge beschikbaarheid binnen een regio, met behulp van implementaties op basis van containers.

      • Implementeer App Service exemplaren in overwogen implementatieregio's.

      App Services biedt een containerplatform met lage wrijving, dat ideaal is voor scenario's met een lage schaal, zoals operationele dashboards, en het isoleren van Grafana van AKS biedt een duidelijke scheiding van zorg tussen het primaire toepassingsplatform en operationele representaties voor dat platform. Raadpleeg het gebied Application Platform-uitlijning voor verdere configuratieaanbeveling.

    • Gebruik Azure Storage in een GRS-configuratie voor het hosten en beheren van aangepaste visuals en invoegtoepassingen.

    • Implementeer Grafana-onderdelen voor app-service en database read-replica in minimaal twee implementatieregio's en overweeg om een model te gebruiken waarin Grafana wordt geïmplementeerd in alle overwogen implementatieregio's.

Voor scenario's met een >SLO van = 99,99% moet Grafana worden geïmplementeerd binnen minimaal drie implementatieregio's om de algehele betrouwbaarheid voor belangrijke operationele dashboards te maximaliseren.

  • Beperk log analytics-querylimieten door query's te aggregeren in één of een klein aantal query's, bijvoorbeeld met behulp van de KQL-operator 'union' en een juiste vernieuwingsfrequentie in te stellen op het dashboard.

    • Een geschikte maximale vernieuwingsfrequentie is afhankelijk van het aantal en de complexiteit van dashboardquery's; analyse van geïmplementeerde query's is vereist.

  • Als de limiet voor gelijktijdige query's van Log Analytics wordt bereikt, kunt u overwegen het ophaalpatroon te optimaliseren door (tijdelijk) de gegevens op te slaan die nodig zijn voor het dashboard in een gegevensarchief met hoge prestaties, zoals Azure SQL.

Geautomatiseerde reactie op incidenten

Hoewel de visuele weergaven van de toepassingsstatus waardevolle operationele en zakelijke inzichten bieden ter ondersteuning van de detectie en diagnose van problemen, is het afhankelijk van de gereedheid en interpretaties van operationele teams, evenals de effectiviteit van de volgende door de mens geactiveerde reacties. Om de betrouwbaarheid te maximaliseren, is het daarom noodzakelijk om uitgebreide waarschuwingen te implementeren om proactief problemen te detecteren en bijna in realtime te reageren op problemen.

Azure Monitor biedt een uitgebreid waarschuwingsframework voor het detecteren, categoriseren en reageren op operationele signalen via actiegroepen. Deze sectie richt zich daarom op het gebruik van Azure Monitor-waarschuwingen om geautomatiseerde acties te stimuleren als reactie op huidige of potentiële afwijkingen van een goede toepassingsstatus.

Belangrijk

Waarschuwingen en geautomatiseerde acties zijn essentieel voor het effectief detecteren en snel reageren op problemen wanneer deze zich voordoen, voordat grotere negatieve gevolgen kunnen optreden. Waarschuwingen bieden ook een mechanisme om binnenkomende signalen te interpreteren en te reageren om problemen te voorkomen voordat ze optreden.

Overwegingen bij het ontwerpen

  • Waarschuwingsregels worden gedefinieerd om te worden geactiveerd wanneer aan een voorwaardelijk criterium wordt voldaan voor binnenkomende signalen, waaronder verschillende gegevensbronnen, zoals metrische gegevens, logboekquery's of beschikbaarheidstests.

  • Waarschuwingen kunnen worden gedefinieerd in Log Analytics of Azure Monitor voor de specifieke resource.

  • Sommige metrische gegevens kunnen alleen worden ondervraagbaar in Azure Monitor, omdat niet alle diagnostische gegevenspunten beschikbaar zijn in Log Analytics.

  • De API voor Waarschuwingen van Azure Monitor kan worden gebruikt om actieve en historische waarschuwingen op te halen.

  • Er zijn abonnementslimieten met betrekking tot waarschuwingen en actiegroepen, die moeten worden ontworpen voor:

    • Er bestaan limieten voor het aantal configureerbare waarschuwingsregels.
    • De WAARSCHUWINGEN-API heeft beperkingslimieten, die in overweging moeten worden genomen voor scenario's met extreem gebruik.
    • Actiegroepen hebben verschillende vaste limieten voor het aantal configureerbare antwoorden waarvoor moet worden ontworpen.
      • Elk antwoordtype heeft een limiet van 10 acties, met uitzondering van e-mail, die een limiet van 1000 acties heeft.

  • Waarschuwingen kunnen worden geïntegreerd in een gelaagd statusmodel door een waarschuwingsregel te maken voor een opgeslagen logboekzoekquery op basis van de scorefunctie 'root' van het model. Bijvoorbeeld het gebruik van 'WebsiteHealthScore' en het waarschuwen voor een numerieke waarde die de status 'Beschadigd' aangeeft.

Ontwerpaanbeveling

  • Voor resourcegerichte waarschuwingen maakt u waarschuwingsregels in Azure Monitor om ervoor te zorgen dat alle diagnostische gegevens beschikbaar zijn voor de waarschuwingsregelcriteria.

  • Voeg geautomatiseerde acties samen binnen een minimaal aantal actiegroepen, afgestemd met serviceteams ter ondersteuning van een DevOps-benadering.

  • Reageren op signalen van overmatig resourcegebruik via geautomatiseerde schaalbewerkingen, waar mogelijk met behulp van azure-systeemeigen mogelijkheden voor automatisch schalen. Als de ingebouwde functionaliteit voor automatisch schalen niet van toepassing is, gebruikt u de statusscore van het onderdeel om signalen te modelleren en te bepalen wanneer er moet worden gereageerd met geautomatiseerde schaalbewerkingen. Zorg ervoor dat geautomatiseerde schaalbewerkingen worden gedefinieerd volgens een capaciteitsmodel, dat schaalrelaties tussen onderdelen kwantificeert, zodat schaalreacties onderdelen omvatten die moeten worden geschaald ten opzichte van andere onderdelen.

  • Modeleer acties voor een volgorde met prioriteit, die moeten worden bepaald door de impact op het bedrijf.

  • Gebruik de Azure Monitor-waarschuwingen-API om historische waarschuwingen te verzamelen die kunnen worden opgenomen in 'koude' operationele opslag voor geavanceerde analyse.

  • Voor kritieke foutscenario's, die niet kunnen worden beantwoord met een geautomatiseerd antwoord, moet u ervoor zorgen dat operationele runbookautomatisering aanwezig is om snelle en consistente actie te ondernemen zodra handmatige interpretatie en afmelding is verstrekt. Waarschuwingsmeldingen gebruiken om snel problemen te identificeren die handmatige interpretatie vereisen

  • Maak toegestaan binnen technische sprints om incrementele verbeteringen in waarschuwingen aan te brengen om ervoor te zorgen dat nieuwe foutscenario's die nog niet eerder zijn overwogen, volledig kunnen worden ondergebracht in nieuwe geautomatiseerde acties.

  • Operationele gereedheidstests uitvoeren als onderdeel van CI/CD-processen om belangrijke waarschuwingsregels voor implementatie-updates te valideren.

Voorspellende actie en AIOps (AIOps)

Machine learning-modellen kunnen worden toegepast om operationele gegevens te correleren en prioriteit te geven. Zo kunt u essentiële inzichten verzamelen met betrekking tot het filteren van overmatige waarschuwingsruis, het voorspellen van problemen voordat deze gevolgen veroorzaken, en het versnellen van de reactie op incidenten wanneer ze dat doen.

Meer specifiek kan een AIOps-methodologie worden toegepast op essentiële inzichten over het gedrag van het systeem, gebruikers en DevOps-processen. Deze inzichten kunnen bestaan uit het identificeren van een probleem dat zich nu voordoet (detecteren), het kwantificeren van waarom het probleem zich voordoet (diagnose) of het signaleren van wat er in de toekomst zal gebeuren (voorspellen). Dergelijke inzichten kunnen worden gebruikt om acties te stimuleren die de toepassing aanpassen en optimaliseren om actieve of potentiële problemen te verhelpen, met behulp van belangrijke metrische gegevens van het bedrijf, metrische gegevens van systeemkwaliteit en DevOps-productiviteitsstatistieken, om prioriteiten te stellen op basis van de impact op het bedrijf. Uitgevoerde acties kunnen zelf in het systeem worden opgenomen via een feedbacklus die het onderliggende model verder traint om extra efficiëntie te stimuleren.

Bedrijfskritieke AIOps-methodologieën

Er zijn meerdere analytische technologieën in Azure, zoals Azure Synapse en Azure Databricks, die kunnen worden gebruikt om analytische modellen voor AIOps te bouwen en te trainen. Deze sectie richt zich daarom op hoe deze technologieën in een toepassingsontwerp kunnen worden geplaatst om AIOps te kunnen gebruiken en voorspellende actie te stimuleren, met de nadruk op Azure Synapse die wrijving verminderen door het beste van de gegevensservices van Azure samen te voegen met krachtige nieuwe functies.

AIOps wordt gebruikt voor het stimuleren van voorspellende actie, het interpreteren en correleren van complexe operationele signalen die gedurende een langere periode worden waargenomen om beter te reageren op problemen en deze te voorkomen voordat ze optreden.

Overwegingen bij het ontwerpen

  • Azure Synapse Analytics biedt meerdere ml-mogelijkheden (Machine Learning).

    • ML-modellen kunnen worden getraind en uitgevoerd in Synapse Spark-pools met bibliotheken zoals MLLib, SparkML en MMLSpark, evenals populaire opensource-bibliotheken, zoals Scikit Learn.
    • ML-modellen kunnen worden getraind met algemene hulpprogramma's voor gegevenswetenschap, zoals PySpark/Python, Scala of .NET.

  • Synapse Analytics is geïntegreerd met Azure ML via Azure Synapse Notebooks, waardoor ML-modellen kunnen worden getraind in een Azure ML-werkruimte met behulp van Geautomatiseerde ML.

  • Synapse Analytics biedt ook ML-mogelijkheden met behulp van Azure Cognitive Services om algemene problemen in verschillende domeinen op te lossen, zoals anomaliedetectie. Cognitive Services kan worden gebruikt in Azure Synapse, Azure Databricks en via SDK's en REST API's in clienttoepassingen.

  • Azure Synapse integreert systeemeigen met Azure Data Factory hulpprogramma's voor het extraheren, transformeren en laden (ETL) of opnemen van gegevens in indelingspijplijnen.

  • Azure Synapse maakt registratie van externe gegevenssets mogelijk voor gegevens die zijn opgeslagen in Azure Blob Storage of Azure Data Lake Storage.

    • Geregistreerde gegevenssets kunnen worden gebruikt in synapse Spark-poolgegevensanalysetaken.

  • Azure Databricks kan worden geïntegreerd in Azure Synapse Analytics-pijplijnen voor extra Spark-mogelijkheden.

    • Synapse organiseert het lezen van gegevens en verzendt deze naar een Databricks-cluster, waar ze kunnen worden getransformeerd en voorbereid voor ml-modeltraining.

  • Brongegevens moeten doorgaans worden voorbereid voor analyse en ML.

    • Synapse biedt verschillende hulpprogramma's voor het voorbereiden van gegevens, waaronder Apache Spark, Synapse Notebooks en serverloze SQL-pools met T-SQL en ingebouwde visualisaties.

  • ML-modellen die zijn getraind, operationeel gemaakt en geïmplementeerd, kunnen worden gebruikt voor batchgewijs scoren in Synapse.

    • AIOps-scenario's, zoals het uitvoeren van regressie- of degradatievoorspellingen in CI/ CD-pijplijn , vereisen mogelijk realtime scoren.

  • Er zijn abonnementslimieten voor Azure Synapse, die volledig moeten worden begrepen in de context van een AIOps-methodologie.

  • Als u AIOps volledig wilt opnemen, moet u doorlopend bijna realtime waarneembaarheidsgegevens invoeren in realtime ML-deductiemodellen.

    • Mogelijkheden zoals anomaliedetectie moeten worden geëvalueerd binnen de gegevensstroom voor waarneembaarheid.

Ontwerpaanbeveling

  • Zorg ervoor dat alle Azure-resources en toepassingsonderdelen volledig zijn geïnstrueerd, zodat een volledige operationele gegevensset beschikbaar is voor aiOps-modeltraining.

  • Operationele Log Analytics-gegevens van de globale en regionale Azure Storage-accounts opnemen in Azure Synapse voor analyse.

  • Gebruik de AZURE Monitor-waarschuwingen-API om historische waarschuwingen op te halen en op te slaan in koude opslag voor operationele gegevens die vervolgens kunnen worden gebruikt in ML-modellen. Als Log Analytics-gegevens worden geëxporteerd, slaat u historische waarschuwingsgegevens op in dezelfde Azure Storage-accounts als de geëxporteerde Log Analytics-gegevens.

  • Nadat de opgenomen gegevens zijn voorbereid voor ML-training, schrijft u deze terug naar Azure Storage, zodat deze beschikbaar zijn voor ml-modeltraining zonder dat synapse-rekenresources voor gegevensvoorbereiding moeten worden uitgevoerd.

  • Zorg ervoor dat ml-modeluitvoering zowel batch- als realtime scoren ondersteunt.

  • Wanneer AIOps-modellen worden gemaakt, implementeert u MLOps en past u DevOps-procedures toe om de LEVENSCYCLUS van ML te automatiseren voor training, operationalisatie, scoren en continue verbetering. Maak een iteratief CI/CD-proces voor AIOps ML-modellen.

  • Evalueer Azure Cognitive Services voor specifieke voorspellende scenario's vanwege de lage overhead voor beheer en integratie. Overweeg anomaliedetectie om snel onverwachte afwijkingen in waarneembaarheidsgegevensstromen te markeren.

Volgende stap

Bekijk de overwegingen voor implementatie en testen.

Implementatie en testen