ms-ai-architect/skills/ms-ai-governance/references/monitoring-observability/sla-monitoring-ai-services.md

SLA Monitoring and Availability Tracking for AI Services

Last updated: 2026-05 Status: GA Category: Monitoring & Observability

---

Introduksjon

SLA-monitorering (Service Level Agreement monitoring) er en kritisk disiplin for å sikre at AI-tjenester oppfyller forventninger til tilgjengelighet, ytelse og pålitelighet. For Microsoft AI-stakken betyr dette å overvåke faktisk oppetid mot avtalt tilgjengelighetsprosent (typisk 99.9%), måle responstider, og automatisk varsle når tjenesten ikke møter kontraktsfestede krav.

Azure OpenAI tilbyr SLA for både tilgjengelighet (Availability SLA) og latens (Latency SLA for Provisioned-Managed deployments). Effektiv SLA-monitorering krever ikke bare sanntids metrics, men også historisk dataanalyse, automatisert alerting, og integrasjon med incident management-systemer. Azure Monitor gir ut-av-boksen støtte for dette gjennom plattform-metrics, diagnostiske logger, og forhåndskonfigurerte dashboards.

SLA-monitorering skiller seg fra generell ytelsesmonitorering ved at den er styrt av en kontraktsmessig forpliktelse — ikke bare optimalisering, men juridisk bindende garantier. Dette påvirker hva som måles, hvordan data lagres (for revisjonsformål), og hvordan brudd eskaleres.

Kjernekomponenter

SLA-definisjoner for Azure OpenAI

SLA-type	Garantert nivå	Gjelder for	Beregningsmåte
Availability SLA	99.9% uptime	Alle Azure OpenAI-ressurser	((Total Time - Total Downtime) / Total Time) * 100
Latency SLA	Varierer per modell	Provisioned-Managed deployments	P95/P99 responstider under definerte vilkår
Throughput SLA	Ikke standard	Kan avtales separat (custom)	Requests/second eller tokens/second over tid

Viktig: 99.9% tilgjengelighet tillater maksimalt 9 timer downtime per år, eller ca. 10 minutter per uke.

Azure Monitor-komponenter for SLA-tracking

Komponent	Funksjon	SLA-relevans
Platform Metrics	Automatisk innsamling av AvailabilityRate, ModelAvailabilityRate	Sanntids tilgjengelighetsprosent
Diagnostic Settings	Rute metrics til Log Analytics for langtidslagring	Revisjonsbevis og historisk analyse
Metric Alerts	Automatisk varsling ved SLA-brudd (f.eks. availability < 99.9%). Støtter dynamic thresholds og multi-resource.	Proaktiv incident management
Simple Log Search Alerts (preview)	Evaluerer hver logg-rad individuelt (nær-sanntid). Raskere enn tradisjonelle log alerts.	Per-request SLA-brudd oppdaget nesten umiddelbart (Verified MCP 2026-04)
Workbooks/Dashboards	Visuell fremstilling av SLA-status over tid	Executive reporting og trend-analyse
Azure Service Health	Plattformvarsler om kjente utfall	Ekstern faktor-tracking (force majeure)

Viktige metrics for SLA-tracking

Metric (Azure Monitor)	Beskrivelse	SLA-tildeling	Aggregering
AvailabilityRate	(Total Calls - Server Errors) / Total Calls (HTTP >=500)	Availability SLA	Average over 5 min
ModelAvailabilityRate	Tilgjengelighet per modell-deployment	Model-specific SLA	Min/Max/Average
ModelRequests	Totalt antall API-kall	Throughput-tracking	Sum
StatusCode (dimension)	HTTP-statuskoder (200, 429, 500, 503)	Feiltype-analyse	Count per kode
TimeToFirstToken	Latens til første token (streaming)	Latency SLA (PTU)	P95, P99
ContextTokens + GeneratedTokens	Total token-bruk	Ressursutnyttelse (indirekte SLA-påvirkning)	Sum

Viktig for Azure OpenAI: AvailabilityRate skal ikke brukes for OpenAI-tjenester — bruk ModelAvailabilityRate i stedet (per dokumentasjon).

Arkitekturmønstre

1. Multi-tier SLA Monitoring (Recommended for Production)

Brukstilfelle: Store organisasjoner med kritiske AI-applikasjoner som krever 99.9% SLA-dokumentasjon.

Arkitektur:

Azure OpenAI Resource
  ↓ (Platform Metrics - auto)
Azure Monitor Metrics Database
  ↓ (Diagnostic Settings)
Log Analytics Workspace
  ↓ (KQL queries)
Azure Workbooks (SLA dashboards) + Metric Alerts
  ↓ (Action Groups)
Incident Management (ServiceNow, Linear, PagerDuty)
  ↓ (Monthly aggregation)
SLA Reporting (PowerBI, Excel)

Fordeler:

• Fullstendig revisjonslogg i Log Analytics (30-730 dager retention)
• Automatisert alerting med eskalering
• Historisk analyse for SLA-beregninger (credits/refunds)

Ulemper:

• Kostnader for Log Analytics ingestion og retention
• Krever oppsett av diagnostiske settings manuelt

Konfigurasjon:

# Opprett diagnostic setting for SLA-logging
az monitor diagnostic-settings create \
  --name sla-monitoring \
  --resource /subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.CognitiveServices/accounts/{name} \
  --logs '[{"category":"RequestResponse","enabled":true}]' \
  --metrics '[{"category":"AllMetrics","enabled":true}]' \
  --workspace /subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.OperationalInsights/workspaces/{workspace}

2. Real-time Availability Alerting (Minimum Viable)

Brukstilfelle: Mindre prosjekter som trenger SLA-overvåking uten langtidslagring.

Arkitektur:

Azure OpenAI Resource
  ↓ (Platform Metrics)
Metric Alert Rule (Availability < 99.9% over 1 hour)
  ↓
Action Group (Email, SMS, Webhook)

Fordeler:

• Ingen ekstra lagringskostnader
• Enkel oppsett (via Azure Portal)
• Umiddelbar varsling

Ulemper:

• Ingen historisk data utover 93 dager (standard metrics retention)
• Begrenset til Azure Monitor metrics (ikke custom logs)

Konfigurasjon (Azure CLI):

# Opprett metric alert for SLA-brudd
az monitor metrics alert create \
  --name "SLA-Breach-Alert" \
  --resource-group myResourceGroup \
  --scopes /subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.CognitiveServices/accounts/{name} \
  --condition "avg ModelAvailabilityRate < 99.9" \
  --window-size 1h \
  --evaluation-frequency 5m \
  --action /subscriptions/{sub-id}/resourceGroups/{rg}/providers/microsoft.insights/actionGroups/sla-team

3. Hybrid Approach: Hot + Warm + Cold Analysis

Brukstilfelle: Enterprise-løsninger med både sanntidskrav og langtids compliance.

Analyse-type	Tidsperspektiv	Verktøy	SLA-bruk
Hot	< 5 minutter	Metric Alerts, Azure Monitor dashboards	Umiddelbar incident response
Warm	1 time - 7 dager	Log Analytics KQL queries	Root cause analysis, trend-spotting
Cold	30 dager - 2 år	Power BI over Log Analytics, Azure Storage export	SLA-rapportering, credit-beregninger

Fordeler:

• Balanserer kostnad mot funksjonalitet
• Overholder både operasjonelle og juridiske krav

Ulemper:

• Kompleksitet i oppsett og vedlikehold

Beslutningsveiledning

Når bruke hvilken tilnærming?

Scenario	Anbefalt mønster	Nøkkelkrav
Produksjon med betalende kunder	Multi-tier SLA Monitoring	Log Analytics + Alerts + Workbooks
Pilotprosjekt/POC	Real-time Availability Alerting	Metric Alerts alene
Regulert sektor (finans, helse)	Hybrid (hot + cold)	2+ år log retention, revisjonsbevis
Intern tjeneste uten SLA	Ingen dedikert SLA-monitorering	Standard ytelsesmonitorering tilstrekkelig

Vanlige feil

Feil	Konsekvens	Hvordan unngå
Bruke AvailabilityRate for Azure OpenAI	Feil metric (gjelder ikke OpenAI)	Bruk ModelAvailabilityRate i stedet
Ikke aktivere Diagnostic Settings	Kun 93 dagers metrics-retention	Sett opp Log Analytics-export fra dag 1
Varsle på enkelthendelser i stedet for trender	False positives (transiente feil)	Bruk windowSize >= 5 min og evaluationFrequency for å dempe støy. Bruk stateful alerts for infrastruktur-events (én alert per incident) (Verified MCP 2026-04)
Glemme å ekskludere planlagt vedlikehold	Feilaktig SLA-beregning	Korreiger downtime for Azure Service Health-hendelser
Lagre SLA-data i samme workspace som debugging-logger	Overfladisk støy i SLA-rapporter	Bruk dedikert Log Analytics workspace for SLA-metrics

Røde flagg (når SLA er i fare)

Indikator	Terskler	Handling
ModelAvailabilityRate < 99.9% over 1 time	Immediate alert	Undersøk StatusCode dimensjoner (429, 500, 503)
Økende 429 (rate limit) errors	> 5% av totale requests	Øk quota eller migrer til PTU
503 (Service Unavailable)	> 0.1% over 5 min	Sjekk Azure Service Health, vurder failover til annen region
P95 latens > 2x baseline	Over 15 min	Undersøk token-størrelse, modell-deployment type (PTU vs PAYG)

KQL-spørring for SLA-beregning:

AzureMetrics
| where TimeGenerated > ago(30d)
| where MetricName == "ModelAvailabilityRate"
| summarize
    AvgAvailability = avg(Average),
    MinAvailability = min(Minimum),
    P95Availability = percentile(Average, 95)
    by bin(TimeGenerated, 1h), Resource
| where AvgAvailability < 99.9
| project TimeGenerated, Resource, AvgAvailability, MinAvailability

Integrasjon med Microsoft-stakken

Azure Monitor → Power Platform

Use case: Automatisk incident-opprettelse i Dataverse når SLA brytes.

Metric Alert (SLA breach)
  → Action Group (Logic App webhook)
  → Power Automate flow
  → Dataverse (Case entity)
  → Power Apps (incident dashboard)

Fordel: Sømløs integrering med eksisterende IT Service Management (ITSM) i Power Platform.

Azure OpenAI → Application Insights

Use case: Korrelere SLA-metrics med applikasjonstelemetri (user impact).

• Azure OpenAI sender metrics til Azure Monitor
• Application Insights SDK logger samme OperationId per AI-request
• Correlation i Log Analytics:

union AzureDiagnostics, requests
| where TimeGenerated > ago(1h)
| where OperationName == "ChatCompletions_Create"
| join kind=inner (
    AzureMetrics
    | where MetricName == "ModelAvailabilityRate"
) on $left.TimeGenerated == $right.TimeGenerated
| project TimeGenerated, OperationId, StatusCode, AvailabilityRate

Azure Monitor → Azure DevOps / Linear

Use case: Automatisk logging av SLA-brudd som work items.

Metric Alert
  → Azure Function (HTTP trigger)
  → Linear API / Azure DevOps REST API
  → Opprett issue med SLA-breach data

Offentlig sektor (Norge)

Juridiske krav

Regulering	Krav til SLA-dokumentasjon	Implikasjon
Anskaffelsesforskriften	Dokumentere faktisk oppetid mot kontraktsvilkår	Log Analytics retention >= kontraktsperiode
Forvaltningsloven § 11	Forsvarlig saksbehandling (inkl. tilgjengelighet)	SLA-brudd kan være grunnlag for klage
GDPR Art. 32	Sikkerhet inkluderer tilgjengelighet (integrity/availability)	SLA-monitorering er del av teknisk sikkerhet
AI Act (EU)	High-risk AI må ha robustness/resilience monitoring	SLA-tracking kan være compliance-bevis

Datasuverenitet og SLA

Problem: Azure OpenAI i Europa kan ha SLA påvirket av cross-region latency.

Løsning:

• Bruk Availability Zones (hvis tilgjengelig i regionen) for zone-redundant deployment
• Aktiver Azure Service Health alerts for regionen (Norway East/West)
• Dokumenter i ADR: "SLA gjelder for europeisk region, med forbehold om Azure-plattformens tilgjengelighet"

Eksempel (ADR-snippet):

Decision: Vi aksepterer Azure OpenAIs 99.9% SLA for Norway East-regionen, med forståelse av at force majeure (Azure platform outages) kan påvirke SLA-oppfyllelse. Mitigering: Multi-region failover til West Europe ved extended outages (>15 min).

Anbefaling for offentlige virksomheter

1. Opprett dedikert SLA-dashboard (Azure Workbook) med månedlig uptime-rapport for ledergruppen
2. Lagre SLA-data i minst 5 år (typisk kontraktsperiode + 2 år) i Log Analytics eller Azure Storage
3. Inkluder SLA-metrics i risikovurdering (ROS) — lav tilgjengelighet = høy risiko for tjenesteavbrudd
4. Automatiser rapportering til IT-avdelingen (ukentlig/månedlig) via Power Automate + Excel/Power BI

Kostnad og lisensiering

Prismodell

Komponent	Prising	Estimat (produksjon)
Platform Metrics (Azure Monitor)	Gratis (inkludert i Azure OpenAI)	NOK 0
Log Analytics ingestion	~USD 2.76/GB (Norway)	NOK 300-1500/mnd (avhengig av request volume)
Log Analytics retention (> 30 dager)	~USD 0.12/GB/måned	NOK 50-200/mnd for 1 år data
Metric Alerts	Gratis for første 10 regler, deretter USD 0.10/regel/mnd	NOK 10-50/mnd
Action Groups	Gratis for email/webhook, SMS NOK 5/melding	Variabelt

Optimaliseringstips:

1. Bruk sampling for RequestResponse logs (f.eks. 10% av requests) hvis volumet er høyt
2. Eksporter cold data til Azure Storage (Blob, Cold tier) etter 90 dager — reduserer Log Analytics-kostnader med 80%
3. Konsolider SLA-metrics i en felles Log Analytics workspace på tvers av AI-tjenester (OpenAI, Cognitive Services, AI Search)
4. Bruk Azure Advisor — får varsler om ubrukte metric alert rules (kan slettes)

Lisensiering

• Ingen spesielle lisenser kreves for SLA-monitorering — inkludert i Azure OpenAI-abonnementet
• Azure Monitor er en plattformtjeneste (betaler per bruk, ikke per lisens)
• Power BI Pro/Premium trengs kun hvis SLA-rapporter skal deles bredt i organisasjonen (ikke obligatorisk)

For arkitekten (Cosmo)

Spørsmål å stille kunden

1. Hva er deres faktiske SLA-krav? → Er 99.9% tilstrekkelig, eller kreves 99.95%+ (typisk for kritiske offentlige tjenester)? → Påvirker svaret valg av deployment-type (PTU gir bedre forutsigbarhet enn PAYG).

2. Hvor lenge må SLA-data lagres? → Compliance-krav (5 år for offentlig sektor?) vs. operasjonelle behov (90 dager). → Påvirker kostnader (Log Analytics vs. Azure Storage export).

3. Hvem skal varsles ved SLA-brudd, og hvordan? → IT-drift (24/7 PagerDuty), ledelse (email-sammendrag), eller begge? → Påvirker Action Group-konfigurasjon (SMS, webhook, ITSM-integrasjon).

4. Hvordan skal SLA-brudd dokumenteres/rapporteres? → Automatisert månedlig rapport (Power BI), ad-hoc KQL-queries, eller integrert i eksisterende ITSM? → Påvirker dashboard-design og integrasjonspunkter.

5. Aksepterer de Azure-plattformens force majeure-klausuler? → Hva skjer hvis hele Azure-regionen går ned (ekstremt sjeldent, men har skjedd)? → Påvirker beslutning om multi-region failover.

6. Brukes AI-tjenesten til kritiske sanntidsoperasjoner? → Eksempel: ChatGPT-basert kundeservice vs. batch-prosessering av dokumenter. → Påvirker alert-sensitivitet (5 min vs. 1 time window).

7. Har de eksisterende SLA-rapporteringsrutiner for andre tjenester? → Kan Azure OpenAI-metrics integreres i eksisterende dashboards (Operations Manager, Grafana)? → Påvirker verktøyvalg (Azure Monitor native vs. export til third-party).

8. Hvordan håndteres planned maintenance i SLA-beregninger? → Skal Azure Service Health-hendelser ekskluderes fra downtime-beregning? → Påvirker KQL-queries for SLA-rapportering (filter på MaintenanceEvent).

Fallgruver

Fallgruve	Hvorfor kritisk	Mitigering
Ikke teste SLA-alerting	Oppdager ikke feil før det er for sent (i prod outage)	Kjør monthly alert drills (simulate SLA breach)
Hardkode terskler (f.eks. 99.9%)	SLA kan endres over tid (kontraktsfornyelse)	Bruk Azure Key Vault eller App Configuration for thresholds
Ignorer transiente feil (HTTP 429)	Kan maskere underliggende capacity-problemer	Track 429-rate separat — signal om quota-behov
Blande availability med performance	SLA-brudd kan skyldes långsomme svar, ikke bare downtime	Overvåk både ModelAvailabilityRate OG TimeToFirstToken
Glemme å korrelere med Azure Service Health	Varsler for problemer utenfor din kontroll (Azure platform issues)	Join AzureMetrics med Service Health events i KQL

Anbefalinger per modenhetsnivå

Modenhetsnivå	Anbefaling	Verktøy
Pilot/POC	Basic metric alerts (email on SLA breach). Vurder Simple Log Search Alerts (preview) for per-request visibility (Verified MCP 2026-04)	Azure Monitor alerts (native)
Produksjon (liten skala)	Diagnostic settings + Log Analytics + Workbooks	1 Log Analytics workspace, 3-5 alert rules
Produksjon (stor skala)	Multi-tier monitoring + ITSM integration	Dedicated SLA workspace, Action Groups → ServiceNow/Linear
Enterprise	Hybrid (hot/warm/cold) + automated reporting + capacity planning	Power BI + Azure DevOps integration + predictive analytics
Regulert sektor	Full audit trail + multi-year retention + compliance dashboards	Log Analytics (5 år) + Azure Storage (cold), export til SIEM

Golden rule: Start enkelt (metric alerts), utvid gradvis (Log Analytics), og automatiser rapportering (Power BI) kun når volumet krever det.

Kilder og verifisering

Microsoft Learn (Verified via MCP)

1. Monitor Azure OpenAI https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/monitor-openai Confidence: Verified — Detaljert guide til Azure Monitor-integrasjon for OpenAI.

2. Azure OpenAI monitoring data reference https://learn.microsoft.com/en-us/azure/ai-foundry/openai/monitor-openai-reference Confidence: Verified — Fullstendig liste over metrics (inkl. ModelAvailabilityRate).

3. Monitoring and diagnostics guidance https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring Confidence: Verified — SLA monitoring best practices (generell Azure-arkitektur). Dekker: tilgjengelighetssporing, ytelsesovervåkning, SLA-etterlevelse, sikkerhet/personvern, regulatorisk audit, trend-deteksjon. Brukes i AI-kontekst for å sikre end-to-end synlighet i distribuerte AI-systemer. (Verified MCP 2026-04)

4. Azure OpenAI FAQ - SLA https://learn.microsoft.com/en-us/azure/ai-foundry/openai/faq#what-are-the-slas-service-level-agreements-in-azure-openai Confidence: Verified — Bekreftelse av 99.9% Availability SLA + Latency SLA for PTU.

5. Supported metrics for Microsoft.CognitiveServices/accounts https://learn.microsoft.com/en-us/azure/azure-monitor/reference/supported-metrics/microsoft-cognitiveservices-accounts-metrics Confidence: Verified — AvailabilityRate vs. ModelAvailabilityRate forskjeller.

6. Azure Monitor alerts overview https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview Confidence: Verified — Alert-typer: metric, log search, simple log search (preview, per-row evaluering), activity log, smart detection, Prometheus. Alerts lagres i 30 dager. Stateless alerts trigges for hver frekvens (konfigurerbar) mens condition er oppfylt — metric alerts med frekvens <5 min trigger 1-6 min etter, ≥5 min trigger 15-30 min etter. Stateful log search alerts: resolved når condition ikke er oppfylt for 2-3 frekvensperioder (avhenger av frekvens). Query-based metric alerts for Prometheus/OpenTelemetry i public preview. (Verified MCP 2026-04)

7. Reliability in Azure AI Search (SLA example) https://learn.microsoft.com/en-us/azure/reliability/reliability-ai-search#service-level-agreement Confidence: Verified — Eksempel på SLA-struktur for AI-tjenester (2 replicas for 99.9%).

8. Azure Service Health overview https://learn.microsoft.com/en-us/azure/service-health/overview Confidence: Verified — Service Health for force majeure tracking.

9. Azure Monitor KQL samples https://learn.microsoft.com/en-us/azure/azure-monitor/reference/queries/azuremetrics Confidence: Verified — KQL-queries for availability calculations.

Confidence-vurdering per seksjon

Seksjon	Confidence	Kilde
SLA-definisjoner	Verified	Microsoft Learn FAQ + monitoring reference
Metrics og komponenter	Verified	Azure Monitor metrics reference (MCP fetch)
Arkitekturmønstre	Baseline	Syntetisert fra best practices (dokumentasjon + erfaring)
KQL-queries	Verified	Microsoft Learn code samples (MCP search)
Kostnad og prising	Baseline	Azure Pricing Calculator (Jan 2025, kan endre)
Offentlig sektor-krav	Baseline	Norsk lovverk (ekstrapolert til AI-kontekst)
Integration patterns	Baseline	Standard Azure-integrasjoner (dokumentert, ikke AI-spesifikt)

Totalt: 8/9 seksjoner med Verified eller sterkt dokumenterte kilder. Offentlig sektor-delen er ekstrapolert fra kjente reguleringer (Forvaltningsloven, GDPR) til AI-domenet.