ms-ai-architect/skills/ms-ai-governance/references/monitoring-observability/endpoint-health-and-capacity-planning.md

Endpoint Health Monitoring and Capacity Planning

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

---

Introduksjon

Endpoint-overvåkning og kapasitetsplanlegging er kritisk for å opprettholde høy tilgjengelighet og forutsigbar ytelse i produksjons-AI-systemer. Azure OpenAI og andre Microsoft AI-tjenester tilbyr omfattende overvåkningsverktøy gjennom Azure Monitor, som samler inn både plattformmetrikkdata (automatisk) og ressurslogger (konfigureres via diagnostic settings).

Effektiv overvåkning involverer tre dimensjoner: tilstandssjekk (health monitoring) av endepunkt, kapasitetsplanlegging (quota og throughput-grenser), og proaktiv alerting. Sammen gir disse innsikt i både nåværende driftsstatus og fremtidige skaleringsmuligheter.

Utfordringen for arkitekter er å balansere kostnad (monitoreringsdata lagres i Log Analytics), ytelse (rate limits og throttling), og pålitelighet (SLA og tilgjengelighet). Azure OpenAI har ingen latens-SLA for Standard-tilbudet, men Provisioned Throughput Units (PTU) tilbyr forutsigbar ytelse for produksjonskritiske workloads.

Kjernekomponenter

Azure Monitor Platform Metrics

Metrikk	Beskrivelse	Tidsromdetaljering	DS Export
AzureOpenAIRequests	Totalt antall API-kall over tid	PT1M (1 minutt)	Ja
AzureOpenAIAvailabilityRate	(Total Calls - Server Errors) / Total Calls (%)	PT1M	Nei
TokensGenerated	Completion tokens generert	PT1M	Ja
ActiveTokens	Totale tokens (prompt + completion)	PT1M	Ja
PTUUtilization	Prosentvis bruk av PTU-kapasitet	PT1M	Ja
ProcessingTime	End-to-end latency (ms)	PT1M	Ja

Viktig: Platform metrics samles automatisk uten konfigurasjon, men for å analysere i Log Analytics må diagnostic settings aktiveres.

Quota og Rate Limits

Konsept	Forklaring	Enhet	Håndtering
Tokens Per Minute (TPM)	Maksimal throughput per deployment	TPM	Settes ved deployment, kan justeres etterpå
Requests Per Minute (RPM)	Maks antall requests per minutt	RPM	Beregnes automatisk fra TPM (varierer per modell)
Quota	Regionbasert grense per modell/subscription	TPM	Forespørres via support
429 Throttling	HTTP-responskode når rate limit overstiges	-	Implementer retry-logic

RPM/TPM-ratio varierer per modell:

Modell	1 Unit Capacity	RPM	TPM
Eldre chat-modeller	1	6	1,000
o1, o1-preview	1	1	6,000
o3	1	1	1,000
o3-mini, o1-mini	1	1	10,000

Viktig: Deployment TPM kan IKKE overskride subscription quota for den modellen i den regionen.

Diagnostic Settings og Log Analytics

# Konfigurer diagnostic settings via Azure Portal:
# Azure OpenAI resource → Monitoring → Diagnostic settings → Add diagnostic setting

# Velg:
# - Logs: AzureDiagnostics (alle operasjoner)
# - Metrics: AllMetrics (for historisk analyse)
# - Destination: Log Analytics workspace

KQL-eksempel for tilstandssjekk:

AzureDiagnostics
| where TimeGenerated > ago(1h)
| where Category == "RequestResponse"
| summarize
    TotalRequests = count(),
    SuccessRequests = countif(ResultSignature == "200"),
    ServerErrors = countif(ResultSignature >= "500"),
    ClientErrors = countif(ResultSignature >= "400" and ResultSignature < "500"),
    AvgDurationMs = avg(DurationMs)
  by bin(TimeGenerated, 5m)
| extend AvailabilityRate = round((SuccessRequests * 100.0) / TotalRequests, 2)
| project TimeGenerated, TotalRequests, AvailabilityRate, AvgDurationMs, ServerErrors

Out-of-Box Dashboards

Azure OpenAI tilbyr to innebygde dashboards:

1. Azure Portal Dashboard (Overview-pane)

   • HTTP Requests (total, status codes, feilrate)
   • Tokens-Based Usage (prompt, completion, total tokens)
   • PTU Utilization (kun for PTU-deployments)
   • Fine-tuning metrics

2. AI Foundry Metrics Dashboard

   • Tilgjengelig via "Go to AI Foundry portal" → Tools → Metrics dashboard
   • Samme kategorier som Portal dashboard, med mer interaktivitet

Anbefaling: Start med disse dashboards, deretter bygg custom dashboards i Grafana eller Power BI for cross-service-korrelasjon.

Arkitekturmønstre

1. Multi-Deployment Failover (High Availability)

Scenario: Produksjonsapplikasjon krever 99.9% tilgjengelighet.

Mønster:

• Opprett to deployments i forskjellige regioner (eks. East US + West Europe)
• Implementer application-side health checks (HTTP 200 status)
• Bruk Azure Front Door eller Traffic Manager for automatisk failover
• Overvåk begge endpoints med Azure Monitor metric alerts

Fordeler:

• Geografisk redundans
• Automatisk failover ved regional outage
• Lavere latens for distribuerte brukere

Ulemper:

• Dobbelt quota-behov (2x TPM)
• Økt kompleksitet i applikasjonskode
• Kostnad for to deployments

KQL for cross-region health check:

AzureDiagnostics
| where Resource in ("openai-eastus-01", "openai-westeu-01")
| where TimeGenerated > ago(15m)
| summarize
    ErrorRate = countif(ResultSignature >= "500") * 100.0 / count(),
    P95Latency = percentile(DurationMs, 95)
  by Resource, bin(TimeGenerated, 1m)
| where ErrorRate > 1.0 or P95Latency > 2000  // Alert if >1% errors or >2s latency

2. Dynamic Quota (Preview)

Scenario: Varierende last med sporadiske traffic spikes.

Mønster:

• Aktiver Dynamic Quota på Standard-deployment
• Sett base TPM til gjennomsnittlig forventet last
• Dynamic Quota tillater opportunistic burst utover base TPM når kapasitet er tilgjengelig

Fordeler:

• Lavere 429-feilrate under spikes
• Ingen ekstra kostnad (betaler kun for faktisk bruk)
• Automatisk skalering uten konfigurasjon

Ulemper:

• Ikke garantert — avhenger av regional kapasitet
• Ingen latens-SLA (Standard offer)
• Kan IKKE redusere TPM under base-grensen

Kode-aktivering (REST API):

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.CognitiveServices/accounts/{accountName}/deployments/{deploymentName}?api-version=2023-05-01

{
  "sku": {
    "name": "Standard",
    "capacity": 100  // Base TPM = 100K
  },
  "properties": {
    "model": { "format": "OpenAI", "name": "gpt-4o", "version": "2024-11-20" },
    "dynamicThrottlingEnabled": true  // Enable dynamic quota
  }
}

3. Provisioned Throughput (PTU) for Mission-Critical

Scenario: Offentlig sektor-applikasjon med strenge latens- og tilgjengelighetskrav.

Mønster:

• Bruk PTU i stedet for Standard (pay-as-you-go)
• PTU gir dedikert kapasitet med forutsigbar latens
• Overvåk PTUUtilization-metrikk for kapasitetsplanlegging
• Sett alert hvis utilization > 80% (signal om behov for oppgradering)

Fordeler:

• Latens-SLA (garantert ytelse)
• Ingen 429-throttling innenfor PTU-kapasitet
• Forutsigbar månedlig kostnad

Ulemper:

• Høyere kostnad sammenlignet med Standard
• Krever commitment (1 måned eller 1 år)
• Overprovisionering hvis last varierer mye

Alert-regel for PTU-kapasitet:

AzureMetrics
| where MetricName == "PTUUtilization"
| where TimeGenerated > ago(5m)
| summarize AvgUtilization = avg(Average) by Resource
| where AvgUtilization > 80
// Trigger alert: PTU nærmer seg kapasitetsgrense

Beslutningsveiledning

Valg av Deployment-type

Kriterium	Standard (pay-as-you-go)	Standard + Dynamic Quota	PTU (Provisioned)
Kostnad	Betaler per token	Samme (ingen ekstra kostnad)	Høyere (månedlig commitment)
Latens-SLA	Nei	Nei	Ja
Burst-håndtering	429 ved TPM-grense	Opportunistic burst	Ingen throttling innenfor PTU
Variabel last	God for testing/dev	God for prod med spikes	Dårlig (sløser kapasitet)
Compliance-krav	OK	OK	Bedre (dedikert kapasitet)

Anbefaling for norsk offentlig sektor:

• Utvikling/test: Standard
• Produksjon (ikke-kritisk): Standard + Dynamic Quota
• Produksjon (kritisk, SLA-krav): PTU

Quota-planlegging

Steg-for-steg:

1. Estimer baseline TPM:

   • Gjennomsnittlig requests/min × gjennomsnittlig tokens/request
   • Eksempel: 10 req/min × 2000 tokens = 20,000 TPM baseline

2. Legg til buffer for spikes:

   • Anbefalt: 1.5x - 2x baseline
   • Eksempel: 20K TPM × 1.5 = 30K TPM

3. Sjekk regional quota:

   az cognitiveservices usage list --location norwayeast
   # Eller via Portal: Management → Quota
   

4. Request quota increase hvis nødvendig:

   • Bruk quota increase form
   • Prioritet gis til kunder med aktiv bruk (ikke "just in case")

5. Overvåk faktisk bruk:

   AzureDiagnostics
   | where TimeGenerated > ago(7d)
   | extend TokenCount = toint(properties_s.estimatedTokens)
   | summarize TotalTokens = sum(TokenCount) by bin(TimeGenerated, 1h)
   | extend TPM = TotalTokens / 60
   | summarize AvgTPM = avg(TPM), P95TPM = percentile(TPM, 95)
   

Vanlige feil

Feil	Årsak	Løsning
429 "Rate Limit Exceeded"	TPM/RPM quota overskredet	Øk deployment TPM eller request quota increase
429 "High demand"	Regional kapasitet utilgjengelig	Retry med exponential backoff, eller bytt region
Lav AvailabilityRate (<99%)	Server errors (5xx)	Sjekk Azure Service Health, implementer retry-logic
Høy latens (>5s)	Standard offer under load	Vurder PTU, eller optimaliser prompts (reduser tokens)
Deployment creation fails	Quota tilgjengelig, men ingen kapasitet i region	Bruk capacity finder API, eller velg annen region

Røde flagg

• Utilization > 80% over tid: Signal om å øke quota/PTU
• Error rate > 1%: Indikerer ustabilitet eller kapasitetsproblem
• Latens P95 > 2x P50: Tyder på intermittent throttling eller regional load
• Quota 100% allocated, men lav faktisk bruk: Over-provisjonering — reduser deployments

Integrasjon med Microsoft-stakken

Azure Monitor Alerts

Metric alert for availability:

# Anbefalt CLI-syntaks (2026): Bruk condition sub-command for betingelser
scope=$(az cognitiveservices account show \
  --resource-group "rg-ai-prod" --name "{account}" --output tsv --query id)

action=$(az monitor action-group show \
  --resource-group "rg-ai-prod" --name "{actionGroup}" --output tsv --query id)

condition=$(az monitor metrics alert condition create \
  --aggregation Average \
  --metric "AzureOpenAIAvailabilityRate" \
  --op LessThan \
  --type static \
  --threshold 99 \
  --output tsv)

az monitor metrics alert create \
  --name "OpenAI-LowAvailability" \
  --resource-group "rg-ai-prod" \
  --scopes $scope \
  --condition $condition \
  --action $action \
  --window-size 5m \
  --evaluation-frequency 1m \
  --description "Alert hvis availability < 99% over 5 min"

(Verified MCP 2026-04 — nytt mønster med condition create sub-command)

Log alert for 429 errors:

az monitor scheduled-query create \
  --name "OpenAI-Throttling" \
  --resource-group "rg-ai-prod" \
  --scopes "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.CognitiveServices/accounts/{account}" \
  --condition "count > 10" \
  --condition-query "AzureDiagnostics | where ResultSignature == '429' | count" \
  --window-size 5m \
  --evaluation-frequency 5m \
  --action "/subscriptions/{sub}/resourceGroups/{rg}/providers/microsoft.insights/actionGroups/{actionGroup}"

Oppdatert metric alert CLI-syntaks (2026): Microsoft anbefaler nå sub-kommandoer for betingelser og dimensjoner: (Verified MCP 2026-04)

# Opprett betingelse som variabel
condition=$(az monitor metrics alert condition create \
  --aggregation Average \
  --metric "AzureOpenAIAvailabilityRate" \
  --op LessThan \
  --type static \
  --threshold 99 \
  --output tsv)

# Opprett metric alert med betingelse-variabel
az monitor metrics alert create \
  --name "OpenAI-LowAvailability-v2" \
  --resource-group "rg-ai-prod" \
  --scopes "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.CognitiveServices/accounts/{account}" \
  --condition $condition \
  --description "Alert hvis availability < 99% over 5 min" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --action "/subscriptions/{sub}/resourceGroups/{rg}/providers/microsoft.insights/actionGroups/{actionGroup}"

Application Insights Integration

For applikasjoner som bruker Azure OpenAI, integrer Application Insights for end-to-end observability:

from azure.monitor.opentelemetry import configure_azure_monitor
from openai import AzureOpenAI

# Konfigurer Application Insights
configure_azure_monitor(connection_string="InstrumentationKey=...")

# OpenAI-kall vil automatisk bli tracet
client = AzureOpenAI(
    api_key="...",
    api_version="2024-10-21",
    azure_endpoint="https://..."
)

response = client.chat.completions.create(...)
# Latency, tokens, success/fail logges automatisk til App Insights

Power BI og Grafana

Power BI:

• Koble til Log Analytics workspace
• Import KQL-queries som datasets
• Bygg executive dashboards med availability, cost, og usage trends

Grafana:

• Bruk Azure Monitor datasource plugin
• Visualiser real-time metrics (latency, throughput, error rate)
• Sett opp on-call alerting via PagerDuty/Slack

Eksempel Grafana panel query (PromQL-style via Azure Monitor):

avg_over_time(AzureOpenAIAvailabilityRate[5m])

Azure Service Health

Overvåk planlagte vedlikehold og regional outages:

az monitor activity-log alert create \
  --name "OpenAI-ServiceHealth" \
  --resource-group "rg-ai-prod" \
  --condition category=ServiceHealth \
  --action-group "/subscriptions/{sub}/resourceGroups/{rg}/providers/microsoft.insights/actionGroups/{actionGroup}" \
  --description "Alert for Azure OpenAI service health events"

Offentlig sektor (Norge)

GDPR og datasuverenitet

Logging-retensjon:

• Log Analytics data lagres i valgt region (Norway East anbefales)
• Sett retention policy i henhold til organisasjonens retningslinjer (default: 30 dager)
• For compliance, vurder eksport til Azure Storage (immutable blobs)

Sensitive data i logs:

• Azure OpenAI logger IKKE prompt/completion-innhold som standard
• Men diagnostic logs inneholder metadata (timestamps, model, token counts)
• Bruk Private Link for Azure Monitor hvis ekstra datasikkerhet kreves

Forvaltningsloven og etterprøvbarhet

Revisjonsspor:

• Aktiver diagnostic settings for alle produksjons-deployments
• Eksporter logs til langtidslagring (Azure Storage Archive tier)
• Inkluder CorrelationId i requests for å spore beslutningsflyt

KQL for audit trail:

AzureDiagnostics
| where Category == "RequestResponse"
| extend UserId = tostring(properties_s.userId)
| extend ModelName = tostring(properties_s.modelName)
| extend TokensUsed = toint(properties_s.totalTokens)
| project TimeGenerated, UserId, ModelName, TokensUsed, OperationName, ResultSignature
| order by TimeGenerated desc

AI Act og risikoklassifisering

High-risk AI systems (offentlig forvaltning):

• Krav om logging av alle AI-beslutninger
• Overvåkning av modell-drift (data distribution shifts)
• Azure Monitor gir grunnlag for compliance-rapporter

Anbefalt arkitektur:

• AI-request → Application Insights (full trace)
• Endpoint metrics → Azure Monitor (availability, latency)
• Audit logs → Log Analytics → Azure Storage (langtidsarkiv)

Schrems II og data residency

Norway East region:

• Velg Norway East for både Azure OpenAI resource OG Log Analytics workspace
• Verifiser at diagnostic settings IKKE sender data til utenlandske regioner
• Azure OpenAI data processing skjer i EU (selv om kontrollplan er globalt)

Kostnad og lisensiering

Prismodell for overvåkning

Komponent	Prismodell	Estimert kostnad (per måned)
Platform metrics	Gratis (innsamling)	0 NOK
Log Analytics ingestion	Per GB innsamlet	~50-200 NOK per GB
Log Analytics retention	Gratis (første 31 dager), deretter per GB	~10 NOK per GB/måned (etter 31 dager)
Alerts	Per regel per måned	~1-5 NOK per regel
Application Insights	Per GB innsamlet	~50-200 NOK per GB

Kostnadsoptimalisering:

• Bruk sampling i Application Insights (f.eks. 10% av requests)
• Sett opp data export til Azure Storage for langtidslagring (billigere enn Log Analytics retention)
• Bruk Azure Monitor Baseline Alerts (AMBA) templates i stedet for custom queries (mindre compute)

Lisenskrav

Azure Monitor:

• Inkludert i Azure subscription (ingen separat lisens)
• Log Analytics workspace krever subscription med Owner/Contributor-rolle for oppsett

Roller for quota-visning:

• Cognitive Services Usages Reader: Minimal rolle for å se quota på tvers av subscription (anbefalt)
• Reader: Gir også quota-innsyn, men bredere tilgang enn nødvendig
• Viktig: Rollen MÅ være satt på subscription-nivå, ikke resource-nivå

Eksempel Azure CLI:

az role assignment create \
  --assignee "user@example.com" \
  --role "Cognitive Services Usages Reader" \
  --scope "/subscriptions/{subscriptionId}"

For arkitekten (Cosmo)

Spørsmål å stille kunden

1. Tilgjengelighetskrav:

   • Hva er akseptabel downtime per måned? (99.9% = ~43 min/måned)
   • Finnes det kritiske tidsvinduer (f.eks. kontortid) med strengere SLA?

2. Last-profil:

   • Gjennomsnittlig requests per minutt? Peak vs. gjennomsnitt?
   • Forventes det sesongvariasjoner eller plutselige spikes?

3. Latenskrav:

   • Hva er akseptabel end-to-end responstid? (P50, P95, P99)
   • Er dette en batch-prosess eller interaktiv chat?

4. Compliance:

   • Kreves revisjonsspor for alle AI-requests? (Forvaltningsloven)
   • Data residency-krav? (Norge, EU, eller globalt OK?)

5. Eksisterende overvåkning:

   • Brukes det allerede Log Analytics/Application Insights i organisasjonen?
   • Finnes det SOC (Security Operations Center) som skal motta alerts?

6. Budsjettrammer:

   • Hva er månedlig budsjett for AI-tjenester (inkl. monitoring)?
   • Preferanse for pay-as-you-go vs. commitment (PTU)?

7. Skaleringsplan:

   • Forventes brukervekst neste 6-12 måneder?
   • Multi-region deployment planlagt?

8. Feiltoleranse:

   • Kan applikasjonen håndtere retry-logic? (429-errors)
   • Finnes det fallback-strategi hvis Azure OpenAI er nede?

Fallgruver

1. Over-provisjonering av quota:

   • Feil: Forespørre 500K TPM "for sikkerhets skyld" uten faktisk bruk
   • Konsekvens: Azure kan avslå request, eller allokere quota som ikke brukes (sløsing)
   • Løsning: Start med 1.5x estimert baseline, øk basert på faktisk bruk

2. Glemmer diagnostic settings:

   • Feil: Forventer at logs samles automatisk
   • Konsekvens: Ingen historikk ved troubleshooting/incidents
   • Løsning: Aktiver diagnostic settings DAG 1 i produksjon

3. Ingen alert-strategi:

   • Feil: Overvåker dashboards manuelt
   • Konsekvens: Oppdager problemer først når brukere klager
   • Løsning: Sett opp metric alerts for availability + log alerts for 429-errors

4. Ignorerer PTU for kritiske workloads:

   • Feil: Bruker Standard offer for produksjonskritisk applikasjon
   • Konsekvens: Variabel latens, ingen SLA, throttling under load
   • Løsning: Vurder PTU hvis tilgjengelighet > 99.5% er påkrevd

5. Cross-region failover uten testing:

   • Feil: Setter opp multi-region, men tester aldri failover
   • Konsekvens: Oppdager bugs i failover-logikk under reell outage
   • Løsning: Kjør chaos engineering (simuler regional failure månedlig)

6. Misforstår Dynamic Quota:

   • Feil: Forventer garantert burst over base TPM
   • Konsekvens: Fortsatt får 429-errors under spikes
   • Løsning: Dynamic Quota er opportunistic, IKKE garantert — planer for base TPM som absolutt minimum

Anbefalinger per modenhetsnivå

Nivå 1: Pilot/POC

• Bruk Standard deployment (pay-as-you-go)
• Aktiver IKKE diagnostic settings (spar kostnader)
• Manuell sjekk av Portal dashboard ukentlig
• Quota: Start med 10K TPM

Nivå 2: Testing/Staging

• Bruk Standard + Dynamic Quota
• Aktiver diagnostic settings (7 dagers retention)
• Sett opp 1-2 metric alerts (availability < 95%)
• Quota: 50-100K TPM basert på testvolum

Nivå 3: Early Production

• Bruk Standard + Dynamic Quota (eller PTU hvis SLA-krav)
• Diagnostic settings med 30 dagers retention
• Metric alerts (availability, latency) + log alerts (429-errors)
• Application Insights integration
• Quota: Baseline + 50% buffer
• Multi-region vurderes (men ikke obligatorisk ennå)

Nivå 4: Mission-Critical Production

• PTU deployment (dedikert kapasitet)
• Multi-region failover (minimum 2 regioner)
• Diagnostic settings med 90+ dagers retention (eller export til Storage)
• Full alert-suite (availability, latency, quota utilization, PTU saturation)
• Application Insights + custom dashboards (Grafana/Power BI)
• Quarterly capacity planning reviews
• Quota: Baseline + 100% buffer (eller PTU-sizing med 20% headroom)

Spesielt for norsk offentlig sektor (nivå 4):

• Log Analytics workspace i Norway East
• Export av logs til Azure Storage Archive (compliance)
• Azure Service Health alerts
• Inkluder CorrelationId i alle requests (revisjonsspor)
• Quarterly compliance reports til IT-sikkerhet/personvern

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 — Komplett guide til diagnostics, metrics, alerts, og KQL-queries

2. Manage Azure OpenAI quota: https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/quota Confidence: Verified — TPM/RPM-allokering, quota requests, 429-feilhåndtering

3. Azure OpenAI quotas and limits: https://learn.microsoft.com/en-us/azure/ai-foundry/openai/quotas-limits Confidence: Verified — Rate limits per modell, Usage tiers, regional constraints

4. Dynamic quota (Preview): https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/dynamic-quota Confidence: Verified — Opportunistic burst-kapasitet for Standard deployments

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 — Fullstendig metrikk-referanse (Azure OpenAI, Content Safety, etc.)

6. Azure Monitor REST API reference: https://learn.microsoft.com/en-us/rest/api/monitor/operation-groups Confidence: Verified — API for metrics export og programmatic access

7. Service limits in Azure AI Search: https://learn.microsoft.com/en-us/azure/search/search-limits-quotas-capacity Confidence: Verified — Throttling patterns (relevant for RAG-arkitekturer)

8. Monitor model quality and endpoint health (Databricks): https://learn.microsoft.com/en-us/azure/databricks/machine-learning/model-serving/monitor-diagnose-endpoints Confidence: Verified — Verktøy: ephemeral service logs, OpenTelemetry for custom endpoints (Unity Catalog Delta tables, langtidsretensjon), build logs (30-dagers retensjon), endpoint health metrics (siste 14 dager), og AI Gateway-enabled inference tables (automatisk logging av requests/responses til Delta tables). (Verified MCP 2026-04)

Code Samples (Verified via MCP)

9. Azure Monitor Query Metrics (Python SDK): https://learn.microsoft.com/en-us/python/api/azure-monitor-querymetrics/azure.monitor.querymetrics.metricsclient Confidence: Verified — Kodeeksempler for programmatisk metrics-query

10. Azure CLI metrics alert creation: https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/azure-cli-metrics-alert-sample Confidence: Verified — CLI-kommandoer for metric alerts (brukt i eksempler over)

Seksjon-konfidensgradering

Seksjon	Kilde	Konfidens
Kjernekomponenter	Microsoft Learn (MCP)	Verified
Quota og Rate Limits	Microsoft Learn (MCP)	Verified
Diagnostic Settings	Microsoft Learn (MCP)	Verified
Arkitekturmønstre (Failover)	Microsoft Learn + Baseline Knowledge	Verified (design), Baseline (best practices)
Dynamic Quota	Microsoft Learn (MCP)	Verified
PTU-mønster	Microsoft Learn + Baseline Knowledge	Verified (features), Baseline (trade-offs)
Azure Monitor Alerts	Microsoft Learn (MCP, code samples)	Verified
Application Insights	Baseline Knowledge + Azure Docs	Baseline
Offentlig sektor	Baseline Knowledge (GDPR, AI Act)	Baseline
Kostnadsmodell	Azure Pricing (public)	Baseline (tall er estimerte, krever priskalkulator for nøyaktighet)

Samlet konfidens: 85% Verified (core features), 15% Baseline (best practices, offentlig sektor-spesifikt)

Sist verifisert: 2026-04 (MCP-searches mot Microsoft Learn)