ms-ai-architect/skills/ms-ai-engineering/references/azure-ai-services/ai-services-monitoring-logging.md

Azure AI Services - Monitoring, Logging and Diagnostics

Last updated: 2026-06-19 | Verified: MCP 2026-06-19 Status: GA Category: Azure AI Services (Foundry Tools)

---

Introduksjon

Monitoring, logging og diagnostikk er kritiske komponenter for å drive Azure AI-løsninger i produksjon. Azure Monitor-plattformen gir omfattende innsikt i ytelse, tilgjengelighet, kostnader og feilsituasjoner for alle Azure AI Services (tidligere Cognitive Services).

Denne kunnskapsreferansen dekker:

• Azure Monitor-integrasjon for AI Services (inkludert Azure OpenAI)
• Diagnostic settings og log-konfigurasjon
• Application Insights for applikasjonsnivå-observabilitet
• Kusto Query Language (KQL) for log-analyse
• Alerts, metrics og dashboards
• Cost tracking og budsjett-varsling

Verdi for arkitekten: Strukturert overvåkning sikrer at AI-løsninger ikke bare fungerer ved lansering, men kan opereres, feilsøkes og optimaliseres over tid. Tidlig etablering av monitoring-strategi reduserer MTTR (Mean Time To Recovery) dramatisk.

---

Kjernekomponenter / Nøkkelegenskaper

1. Azure Monitor Platform

Tre datalagringsmodeller:

• Platform metrics – numeriske tidsserie-data samlet automatisk, lagres i Azure Monitor metrics database
• Resource logs – detaljert operasjonslogging (må aktiveres via diagnostic settings)
• Activity log – subscription-level hendelser (automatisk samlet, separat lager)

Datainnsamling for Azure AI Services:

Data Type	Automatisk?	Konfigurasjon	Bruk
Platform Metrics	Ja	Ingen	Real-time dashboards, alerts
Resource Logs	Nei	Diagnostic settings påkrevd	Post-mortem analyse, compliance
Activity Log	Ja	Ingen	Kontrollplan-operasjoner (create/delete)

Viktig distinksjon:

• Control plane – Azure Resource Manager-operasjoner (opprettelse av ressurser, endring av SKU)
• Data plane – faktisk AI-tjeneste-bruk (API-kall, token-bruk, latency)

2. Diagnostic Settings (Nøkkelkonfigurasjon)

Diagnostic settings er obligatorisk for å samle resource logs.

Konfigurasjon via Azure Portal:

1. Naviger til Azure AI Services-ressursen
2. Monitoring → Diagnostic settings → Add diagnostic setting
3. Gi beskrivende navn (eks: "my-openai-all-logs")
4. Velg log-kategorier:
   • Audit – bruker/app-interaksjoner med data
   • RequestResponse – detaljer om API-requests
   • Trace – kun for Custom Question Answering
   • AllLogs – alt (start her, reduser deretter)
5. Velg destinasjon:
   • Log Analytics workspace (anbefalt for KQL-queries)
   • Azure Storage (langvarig arkivering, compliance)
   • Event Hubs (strømming til eksterne systemer)
6. Save

Kritisk merknad:

Verbose logging kan være kostbart å lagre. Start med allLogs for å forstå volumet, deretter switch til mer skopede kategorier.

ResourceProvider-identifikator: Azure AI Services rapporterer med ResourceProvider == "MICROSOFT.COGNITIVESERVICES" i AzureDiagnostics-tabellen.

3. Log Analytics Workspace

Lagringssted for strukturert log-analyse:

• Kusto Query Language (KQL) for ad-hoc queries
• Pre-built queries tilgjengelig i portal
• Integrerer med Power BI, Grafana, Azure Dashboards

Typiske tabeller:

• AzureDiagnostics – resource logs fra AI Services
• AzureMetrics – metrics eksportert via diagnostic settings
• AzureActivity – activity log (hvis routet)

Kostnadsstyring: Log Analytics har eget prisingmodell basert på:

• Data ingestion (per GB)
• Data retention (90 dager gratis, deretter betalt)

4. Application Insights (Applikasjonsnivå)

For dypere applikasjons-observabilitet:

• OpenTelemetry-kompatibel APM (Application Performance Monitoring)
• End-to-end transaction tracing
• Client-side telemetri (JavaScript SDK)
• AI agent monitoring (Azure AI Foundry, Copilot Studio)

Sentrale views:

View	Formål
Application Map	Visuell oversikt over arkitektur og avhengigheter
Live Metrics	Real-time dashboard (1-2 sek latency)
Failures View	Exception tracking, HTTP error rates
Performance View	Latency analyse, dependency duration
Agents View	Spesialisert for AI agents (token usage, cost per session)

Når bruke Application Insights vs. Diagnostic Logs:

• Application Insights → utviklere som bygger applikasjoner (custom events, distributed tracing)
• Diagnostic Logs → platform-operatører som overvåker infrastruktur (API call volumes, errors)

Integrasjon: Application Insights kan kobles til Azure AI Services via:

• Connection string i app settings (APPLICATIONINSIGHTS_CONNECTION_STRING)
• Microsoft Entra ID-autentikasjon (anbefalt for prod)

5. Alerts (Proaktiv varsling)

Alert-typer:

• Metric alerts – kontinuerlig evaluering av metrics (eks: "token rate > 10 000/min i 5 min")
• Log alerts – KQL-basert, evaluerer logs ved intervaller (eks: "mer enn 10 failures i 1 min")
• Activity log alerts – trigger på ARM-operasjoner (eks: "noen slettet en ressurs")

Best practice:

Alerts skal være actionable. Hvis ingen respons er nødvendig, bruk rapporter i stedet.

Vanlige alert-scenarioer for AI Services:

• Token rate nærmer seg quota limit
• Error rate overstiger terskel (eks: 429 Too Many Requests)
• Latency overskrider SLA (eks: P95 > 2 sekunder)
• Absence of expected log events (ingen heartbeat på 10 min)

Action groups: Alerts kan trigge:

• Email, SMS, push notifications
• Azure Functions, Logic Apps (automation)
• ITSM-integrasjoner (ServiceNow, etc.)
• Webhooks

---

Arkitekturmønstre

Pattern 1: Centralized Monitoring Hub

Scenario: Enterprise med mange AI Services på tvers av subscriptions/resource groups.

Design:

• Ett sentralt Log Analytics workspace per miljø (dev/test/prod)
• Diagnostic settings på alle AI Services router til samme workspace
• Azure Monitor Workbooks for konsistente dashboards
• Shared alert rules via Azure Policy

Fordeler:

• Cross-resource correlation (finn patterns på tvers av tjenester)
• Sentralisert RBAC for monitoring
• Kostnadseffektivt (volume discounts på Log Analytics ingestion)

Ulemper:

• Kan bli "noisy" workspace hvis ikke filtrert riktig
• Må bruke resource-tagging for å skille workloads

Pattern 2: Per-Application Isolation

Scenario: Multitenancy eller streng data-separasjon (offentlig sektor).

Design:

• Dedikert Log Analytics workspace per applikasjon/kunde
• Application Insights per applikasjon
• Separate alert action groups

Fordeler:

• Data isolation (compliance-vennlig)
• Enklere cost chargeback til business units
• Redusert risiko for data leakage

Ulemper:

• Høyere forvaltningskostnad (mange workspaces å vedlikeholde)
• Vanskeligere å se trender på tvers av applikasjoner

Pattern 3: Hot/Cold Tiering

Scenario: Langvarig compliance-krav, men begrenset behov for interaktive queries.

Design:

• Hot tier (Log Analytics) – siste 30 dager, KQL-queries
• Cold tier (Azure Storage) – 1-7 år, batch-analyse
• Diagnostic settings sender til både destinations

Fordeler:

• Compliance med arkiveringskrav (GDPR Article 17, etc.)
• Dramatisk reduserte kostnader (Storage vs. Log Analytics)
• Kan re-hydrate data til Log Analytics ved behov

Ulemper:

• Mer kompleks konfigurasjon
• Queries mot cold storage krever separat pipeline (Azure Data Explorer, Synapse)

Pattern 4: Azure API Management Gateway

Scenario: Mange applikasjoner som deler samme Azure OpenAI-instans.

Design:

• APIM som unified gateway foran Azure OpenAI
• APIM logger til egen Application Insights
• Correlation-ID propageres fra APIM til backend AI Service
• Rate limiting og token quotas håndteres i APIM

Fordeler:

• Granular logging per consumer (app, team, subscription key)
• Sentralisert rate limiting og cost tracking
• Abstraherer backend-endringer fra consumers

Monitoring-perspektiv:

• APIM metrics viser consumer-side latency
• AI Services metrics viser backend-side latency
• Differanse indikerer APIM overhead eller network issues

---

Beslutningsveiledning

Når velge Log Analytics vs. Storage?

Kriterium	Log Analytics	Azure Storage
Interaktive queries (< 5 min respons)	✅ Ja	❌ Nei (batch)
Real-time alerts	✅ Ja	❌ Nei
Retention > 2 år	⚠️ Dyrt	✅ Ja
Compliance-arkivering	⚠️ Mulig	✅ Anbefalt
Kostnad for 100 GB/dag	~$230/mnd (30 dager)	~$2/mnd (cool tier)

Anbefaling: Start med Log Analytics for operational monitoring (30-90 dager). Legg til Storage hvis compliance krever lengre retention.

Når bruke Application Insights?

Bruk Application Insights hvis:

• Du bygger en custom applikasjon på toppen av Azure AI Services
• Du trenger end-to-end transaction tracing (fra frontend → API → AI Service → database)
• Du ønsker client-side telemetri (JavaScript i browser)
• Du bygger AI agents (Azure AI Foundry, Copilot Studio)

Ikke nødvendig hvis:

• Du kun kjører pre-built AI Services uten custom app-logikk
• Du kun trenger infra-metrics (API call volumes, error rates)

Metric Alerts vs. Log Alerts?

Alert Type	Bruk når...	Latency	Cost
Metric	Data finnes som metric (token count, latency)	~1 min	Lavere
Log	Trenger aggregasjon/grouping (errors per container ID)	~5 min	Høyere

Regel: Bruk metrics når mulig. Bruk log alerts kun for komplekse patterns som ikke finnes som metrics.

Retention Policy

Log Analytics retention-strategi:

• 30 dager – hot data, ingen ekstra kostnad
• 90 dager – operational troubleshooting (anbefalt minimum)
• 1-2 år – compliance for de fleste use cases (offentlig sektor: Noark-5)
• 7 år – finansielle data (bokføringslov)

Konfigurasjon: Portal → Log Analytics workspace → Usage and estimated costs → Data retention

---

Integrasjon med Microsoft-stakken

Azure OpenAI-spesifikt

Out-of-box dashboards i Azure AI Foundry:

• HTTP Requests – request count, error rates
• Tokens-Based Usage – prompt tokens, completion tokens, total tokens
• PTU Utilization – Provisioned Throughput Unit-bruk (for provisioned deployments)
• Fine-tuning – training job metrics

Viktige metrics for Azure OpenAI:

Metric	Hva det måler	Alert threshold (eksempel)
TokenTransaction	Totalt antall tokens brukt	> 1M tokens/time
GeneratedTokens	Completion tokens	Trend analysis (spot unintended usage)
ProcessedPromptTokens	Input tokens	Spike detection (data leak?)
ActiveTokens (PTU)	Concurrent token processing	> 80% capacity
Requests	API call count	> 10 000/min (nær rate limit)
Http429	Throttled requests	> 10/min (scaling needed)

KQL-query for token cost estimation:

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.COGNITIVESERVICES"
| where OperationName == "Generate Completion"
| extend tokens = toint(properties_s.tokens)
| summarize TotalTokens = sum(tokens) by bin(TimeGenerated, 1h)
| extend EstimatedCostNOK = TotalTokens * 0.0002  // Eksempel pricing

Power Platform AI

Dynamics 365 og Power Apps med Application Insights:

• Enable via Monitoring → Application Insights
• customDimensions-feltet inneholder Power Platform-spesifikke properties
• User-identitet ikke logget (privacy by default)

Typiske queries:

pageViews
| where cloud_RoleInstance == "CDS Data Export"
| where session_Id == "[insert session id]"

Microsoft 365 Copilot

Monitoring via Microsoft 365 Admin Center:

• Copilot usage dashboards (aggregert, ikke detaljert logging)
• Vipps-integrasjon via Graph API (for custom dashboards)

Application Insights for Copilot Studio: Copilot Studio-bottar kan kobles til Application Insights for:

• Conversation analytics
• LUIS intent recognition performance
• QnA Maker query latency

---

Offentlig sektor (Norge)

Compliance-krav

Noark-5 (Offentlig arkivlov):

• Hendelseslogging av alle operasjoner som involverer personopplysninger
• Minimum 10 års oppbevaringstid (visse kategorier)
• Integritetsikring (checksums, immutable storage)

GDPR Article 30 (Behandlingsprotokoll):

• Logging av hvem som har aksessert persondata
• Azure AI Services logger ikke individual user identity by default
• Må implementeres i klient-applikasjon (custom logging)

Implementasjonsstrategi:

1. Resource logs → Log Analytics (90 dager)
2. Export to Storage (Immutable Blob Storage, 10 år)
3. Client-side logging (custom Event Hubs → SIEM)

Schrems II og dataresidency

Challenge: Diagnostic logs lagres i Log Analytics workspace. Workspace må være i Norge (Norway East/West) for å sikre data residency.

Verifisering: Portal → Log Analytics workspace → Properties → Location = "Norway East"

Viktig: Selv om AI Service-ressursen er i Norge, kan Log Analytics workspace være i annen region hvis ikke eksplisitt konfigurert.

Sikkerhetstiltak

Private Link for Log Analytics:

• Azure Monitor Private Link Scope (AMPLS) sikrer at logs ikke traverserer public internet
• Påkrevd for data classification "Begrenset" eller høyere

Customer-Managed Keys (CMK): Log Analytics støtter CMK for encryption at rest. Relevant for "Strengt fortrolig" data.

Konfigurasjon: Portal → Log Analytics workspace → Properties → Customer-managed key

---

Kostnad og lisensiering

Prismodell for Azure Monitor

Log Analytics:

• Pay-as-you-go – $2.76/GB ingested (Norway East, jan 2026)
• Commitment Tiers – 100 GB/day ($196/mnd), 200 GB/day ($360/mnd)
• Data retention – 90 dager gratis, deretter $0.12/GB/måned

Application Insights:

• Basert på data ingestion (samme som Log Analytics)
• 5 GB/måned gratis per subscription

Alerts:

• Metric alerts: $0.10 per metric signal per måned
• Log alerts: $0.20 per evaluation per måned
• Email/SMS notifications: varierer (100 emails gratis/mnd)

Kostnadsoptimalisering:

1. Filtrer bort støy – bruk diagnostic setting categories strategisk
2. Sampling – Application Insights adaptive sampling (default 5 items/sec)
3. Data export – export til Storage for langvarig retention
4. Workspace design – konsolider workspaces for volume discounts

Estimert kostnad for typisk Azure OpenAI deployment

Scenario: 1 million API-kall per måned, 500 tokens gjennomsnitt per request.

Log volume-estimat:

• Per request log entry: ~2 KB
• Daglig volume: (1 000 000 / 30) * 2 KB = ~67 GB/måned
• Log Analytics cost: 67 GB * $2.76 = ~$185/måned

Optimalisering: Hvis kun interessert i errors og high-latency requests:

• Filtrer ut successful requests < 1 sek latency
• Redusert volume: 10 GB/måned → **$28/måned**

Lisensiering

Ingen separate lisenser påkrevd: Azure Monitor-funksjoner er inkludert i Azure-subscription. Betaler kun for ressursforbruk (data ingestion, retention).

Unntak: Hvis du bruker ITSM-integrasjoner (ServiceNow, etc.) via Action Groups, kan det påløpe kostnader fra ITSM-leverandør per ticket.

---

For arkitekten (Cosmo)

Pre-emptive troubleshooting

Red flags å se etter i monitoring data:

1. Økende latency uten økende load:

   • Indikerer backend-degradering (model hosting issues)
   • Action: Kontakt Azure Support, vurder multi-region failover

2. Spike i 429-errors:

   • Rate limit hit (TPM/RPM quota)
   • Action: Øk quota, implementer retry-logikk, vurder PTU

3. Plutselig drop i request volume:

   • Potensielt auth-problem (expired keys, RBAC-endringer)
   • Action: Sjekk Activity Log for endringer i IAM

4. Uforholdsmessig høy token usage:

   • Mulig prompt injection attack eller dataleakage
   • Action: Analysér request payloads, implementer input validation

Arkitektur-anbefalinger

For proof-of-concept:

• Start med Diagnostic Settings → Log Analytics (allLogs)
• Basic metric alerts (error rate, latency)
• Manuell review i portal (ingen automation)

For pilot (begrenset prod):

• Application Insights hvis custom app
• Alert action groups (email til team)
• Weekly review av dashboards

For full produksjon:

• Comprehensive alert coverage (metrics + logs)
• Action groups med PagerDuty/OpsGenie-integrasjon
• Runbooks for vanlige failure scenarios
• Grafana dashboards for NOC/SOC
• Automated cost reports (Power BI + Log Analytics export)

For regulert miljø (offentlig sektor):

• Private Link (AMPLS) obligatorisk
• Customer-Managed Keys for Log Analytics
• Immutable Storage for compliance logs (10 år+)
• Quarterly audit reports fra Log Analytics queries

Diskusjonspunkter med stakeholders

Med utviklerteam:

"Hva er akseptabel MTTR (Mean Time To Recovery) for denne løsningen? Dette bestemmer hvor mye vi investerer i monitoring og alerting."

Med InfoSec:

"Hvilke logs må vi bevare for compliance, og hvor lenge? Dette påvirker arkitekturvalg (Log Analytics vs. Storage)."

Med FinOps:

"Monitoring kan koste 5-15% av total AI Services-kostnad. Hvilke trade-offs er vi villige til å gjøre?"

Med business:

"Hvis AI-tjenesten går ned, hvor raskt må vi vite om det, og hva er konsekvensen av 10 min vs. 1 time downtime?"

Decision-making framework

Spørsmål å stille:

1. Hva er SLA-kravet?

   • 99.9% (43 min/mnd) → Basic alerts holder
   • 99.99% (4 min/mnd) → Trenger real-time monitoring (Live Metrics)

2. Hva er dataklassifisering?

   • Åpen/Intern → Standard Log Analytics
   • Begrenset → Private Link
   • Strengt fortrolig → Private Link + CMK

3. Hvor mange AI Services-instanser?

   • 1-5 → Per-resource Log Analytics
   • 5+ → Centralized monitoring hub

4. Hva er budsjettet?

   • < $100/mnd → Minimal logging, metric alerts
   • $100-500/mnd → Full Log Analytics, Application Insights
   • $500+ → Grafana, Workbooks, multi-region dashboards

Common pitfalls

❌ "Vi setter opp monitoring etter lansering" → MTTR blir 10x høyere. Etabler baseline metrics i pilot-fase.

❌ "AllLogs er greit, vi har budsjett" → Etter 3 måneder: "Hvorfor koster Log Analytics $2000/mnd?"

❌ "Vi trenger ikke alerts, vi sjekker dashboards daglig" → Outage kl 02:00 oppdages kl 09:00. Kunde allerede misfornøyd.

❌ "Application Insights erstatter Diagnostic Logs" → Nei, de er komplementære. Trenger begge for full observability.

Iterative rollout-strategi

Uke 1-2 (Foundation):

• Opprett Log Analytics workspace
• Enable Diagnostic Settings (allLogs)
• Opprett basic metric alerts (error rate, latency)

Uke 3-4 (Visibility):

• Deploy Azure Monitor Workbook (eller Grafana dashboard)
• Etabler daglig review-rutine (15 min standup)
• Dokumenter baseline metrics (normal vs. abnormal)

Uke 5-8 (Automation):

• Tune alert thresholds (reduser false positives)
• Implementer action groups (email → PagerDuty)
• Opprett runbooks for top 3 failure scenarios

Uke 9-12 (Optimization):

• Analyser log volume, filtrer bort støy
• Vurder commitment tier for Log Analytics
• Implementer cost dashboards (show to FinOps)

Kontinuerlig (Post-launch):

• Monthly review av alert effectiveness
• Quarterly update av runbooks
• Bi-annual review av retention policies

---

Kilder og verifisering

Verified (MCP-research, januar 2026):

• Enable diagnostic logging for Foundry Tools – Offisiell guide, sist oppdatert 2024
• Monitor Azure OpenAI – Kusto queries, diagnostic settings, dashboards
• Introduction to Application Insights – OpenTelemetry-basert APM
• Monitor Azure AI services (Training module) – Microsoft Learn offisiell kurs

Baseline (Modellkunnskap, januar 2025):

• Azure Monitor pricing (verifiser via Azure Pricing Calculator)
• Noark-5 arkiveringskrav (verifiser via Arkivverket)
• GDPR Article 30 (behandlingsprotokoll)
• Best practices for Log Analytics workspace design

Andre ressurser:

• Azure Monitor Baseline Alerts – Community-drevet alert templates
• Kusto Query Language reference – KQL syntax guide
• Cost Management for Azure AI – Budgets, alerts, exports

---

Konfidensgradering:

• Diagnostic settings, Log Analytics, KQL queries: Verified ✅
• Azure OpenAI metrics og dashboards: Verified ✅
• Application Insights integration: Verified ✅
• Pricing estimates (NOK): Baseline (valutakurs varierer, verifiser i calculator)
• Noark-5 retention: Baseline (tolkninger kan variere per kommune/etat)