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

```bash
# 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:**

```kql
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:**

```kql
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):**

```bash
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:**

```kql
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:**
   ```bash
   az cognitiveservices usage list --location norwayeast
   # Eller via Portal: Management → Quota
   ```

4. **Request quota increase hvis nødvendig:**
   - Bruk [quota increase form](https://aka.ms/oai/stuquotarequest)
   - Prioritet gis til kunder med aktiv bruk (ikke "just in case")

5. **Overvåk faktisk bruk:**
   ```kql
   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:**

```bash
# 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:**

```bash
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)*

```bash
# 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:

```python
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):**

```promql
avg_over_time(AzureOpenAIAvailabilityRate[5m])
```

### Azure Service Health

Overvåk planlagte vedlikehold og regional outages:

```bash
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:**

```kql
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:**

```bash
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)