ms-ai-architect/skills/ms-ai-engineering/references/mlops-genaiops/monitoring-observability-ml-systems.md

Monitoring and Observability for ML Systems

Category: MLOps & GenAIOps Last updated: 2026-04 Kilder: Microsoft Learn (azure-machine-learning, azure-monitor) Konfidensgrad: ⭐⭐⭐⭐⭐ (Verifisert mot offisiell Microsoft-dokumentasjon) Type: reference Source: https://learn.microsoft.com/azure/machine-learning/concept-model-monitoring Status: Established Practice

---

Innhold

• Introduksjon
• Kjernekomponenter
• Arkitekturmønstre
• Beslutningsveiledning
• Integrasjon med Microsoft-stakken
• Offentlig sektor (Norge)
• Kostnad og lisensiering
• For arkitekten (Cosmo)
• Kilder og verifisering

Introduksjon

Monitoring og observability for ML-systemer handler om kontinuerlig overvåkning av modeller i produksjon for å sikre ytelse, kvalitet og pålitelighet. Azure tilbyr et komplett økosystem for ML-overvåkning gjennom Azure Machine Learning Model Monitoring og Azure Monitor, som til sammen gir innsikt i både modellytelse (data science-perspektiv) og operasjonell helse (infrastruktur-perspektiv).

Hvorfor dette er kritisk: ML-modeller degraderer over tid (model decay) på grunn av data drift, concept drift, og endringer i produktionsmiljøet. Uten kontinuerlig overvåkning kan dette føre til dårlige prediksjoner og forretningsmessig risiko.

Kjernekomponenter

1. Azure Machine Learning Model Monitoring

Built-in monitoring signals (✅ Production-ready):

• Data Drift – Oppdager når input-data endrer seg sammenlignet med treningsdata (baseline)
• Prediction Drift – Sporer endringer i modellens prediksjoner over tid
• Data Quality – Måler null-verdier, data type errors, og out-of-bounds rater
• Model Performance – Beregner accuracy, precision, recall (klassifisering) eller MAE/MSE/RMSE (regresjon) ved å sammenligne prediksjoner med ground truth
• Feature Attribution Drift – Sporer endringer i feature importance (hvilke features som påvirker prediksjoner mest)

Metrics and thresholds (✅ Konfigurerbare):

• Jensen-Shannon distance (numeriske features)
• Pearson's chi-squared test (kategoriske features)
• Normalized Discounted Cumulative Gain (feature attribution drift)

Data collection (🔧 Avhenger av deployment-type):

• Online endpoints: Azure ML Data Collector samler automatisk inference data (inputs + outputs) til Azure Blob Storage
• Batch endpoints eller eksterne deployments: Du må selv implementere data collection og registrere det som Azure ML data asset
• Ground truth data: Må samles manuelt på applikasjonsnivå for model performance monitoring

Scheduling (⏰ Fleksibelt):

• Konfigurer via cron expressions eller recurrence patterns (minutt, time, dag, uke, måned)
• Kjører på serverless Spark compute (Standard_E4s_v3 - Standard_E64s_v3)
• Alert notifications sendes via e-post når thresholds overskrides

Best practices (📋 Fra Microsoft):

1. Start monitoring umiddelbart etter deployment
2. Bruk treningsdata som baseline for data drift og data quality
3. Bruk valideringsdata som baseline for prediction drift
4. Monitor top N features (basert på feature importance) for store datasett
5. Kombiner flere signals for bred og granulær overvåkning
6. Sett monitoring frequency basert på data-akkumulering (daglig hvis høy trafikk, ellers ukentlig/månedlig)
7. Involver data scientists som kjenner modellen for å sette riktige thresholds

2. Azure Monitor for ML Infrastructure

Platform metrics (📊 Auto-collected):

• Workspace-nivå: Run counts, model deployments, quota utilization
• Online endpoint-nivå: Request latency (P50/P90/P95/P99), requests per minute, network bytes
• Deployment-nivå: CPU/GPU utilization, memory utilization, disk utilization, data collection events/errors

Application Insights integration (🔍 Deep telemetry):

• Distributed training logs: Samler stdout/stderr fra alle workers til AppTraces table (90 dagers retention)
• Custom telemetry: Track custom metrics, traces, dependencies, exceptions
• Smart detection: ML-drevet anomaly detection for ytelse og feil
• Live Metrics Stream: Sanntids-visning av request rates, response times, failures

Log Analytics (📝 KQL-basert):

• Query logs med Kusto Query Language (KQL)
• Built-in time series analysis og ML-funksjoner (anomaly detection, forecasting, root cause analysis)
• Integration med workbooks og dashboards

3. AIOps and Machine Learning på Logs

Built-in capabilities (🤖 Ingen ML-kunnskap påkrevd):

• Dynamic thresholds: Lærer metric patterns fra historikk og setter automatiske alert thresholds
• Predictive autoscale: Forecaster CPU-behov for VM scale sets basert på historikk
• Log Analytics Workspace Insights: Oppdager ingestion anomalies med ML
• Observability agent: Korrelerer findings på tvers av data sources

Custom ML pipelines (🔬 For avanserte scenarioer):

• Query-basert tilnærming: Bruk Azure Monitor Query client library (Python SDK) til å hente data til Pandas DataFrames → tren modeller med Scikit-learn/PyTorch
• Export-basert tilnærming: Eksporter logs til Azure Storage → prosesser med Synapse/Databricks → tren store modeller med SynapseML/Spark MLlib
• Hybrid approach: Eksporter for model training (store datamengder), query for scoring (lav latency)

ML lifecycle støtte (🔄 End-to-end):

1. Explore data: Log Analytics eller notebooks
2. Train model: Scikit-learn (små datasett) eller SynapseML (store datasett)
3. Score model: Azure Monitor Query library
4. Ingest results: Azure Monitor Ingestion library → custom table i Log Analytics
5. Schedule pipeline: Azure Synapse eller Azure ML pipelines

Arkitekturmønstre

Pattern 1: Out-of-Box Online Endpoint Monitoring

┌─────────────────┐
│ Online Endpoint │
│ (w/ Data        │──┐
│  Collector)     │  │
└─────────────────┘  │
                     ▼
              ┌────────────────┐
              │ Azure Blob     │
              │ Storage        │
              │ (Inference     │
              │  Data)         │
              └────────────────┘
                     │
                     ▼
              ┌────────────────┐
              │ Model Monitor  │
              │ (Spark compute)│──► Email alerts
              │ - Data drift   │
              │ - Pred. drift  │
              │ - Data quality │
              └────────────────┘
                     │
                     ▼
              ┌────────────────┐
              │ Azure ML       │
              │ Studio UI      │
              └────────────────┘

Når bruke: Modeller deployert til Azure ML online endpoints med data collection enablet. Konfidensgrad: ⭐⭐⭐⭐⭐ (Microsoft-anbefalt standard)

Pattern 2: Model Performance Monitoring (Ground Truth Join)

┌─────────────────┐       ┌─────────────────┐
│ Model Outputs   │       │ Ground Truth    │
│ (w/ corr. ID)   │       │ (w/ corr. ID)   │
└─────────────────┘       └─────────────────┘
         │                         │
         └────────────┬────────────┘
                      ▼
              ┌────────────────┐
              │ Join on ID     │
              │ (Spark compute)│
              └────────────────┘
                      │
                      ▼
              ┌────────────────┐
              │ Performance    │
              │ Metrics        │──► Email alerts
              │ - Accuracy     │    (threshold breach)
              │ - Precision    │
              │ - MAE/RMSE     │
              └────────────────┘

Når bruke: Når du har tilgang til ground truth data (actuals) for å måle objektiv modellytelse. Best practice: Bruk data collector til å logge egen unique ID per row for enklere join.

Pattern 3: Multi-Signal Advanced Monitoring

Monitoring Signals:
├─ Data Drift (top 10 features, training data baseline)
├─ Data Quality (individual features, training data baseline)
├─ Prediction Drift (validation data baseline)
└─ Feature Attribution Drift (training data + target column)

Når bruke: Produksjonsmodeller der du trenger bred og granulær overvåkning. Trade-off: Høyere compute-kostnad, men bedre innsikt.

Pattern 4: Custom Signal Component

┌─────────────────────────────────────────┐
│ Custom Signal Component (Azure ML)      │
│ Input:                                  │
│ - production_data (mltable)             │
│ - <metric>_threshold (literal)          │
│                                         │
│ Logic:                                  │
│ - Compute custom metrics (e.g., std dev)│
│                                         │
│ Output:                                 │
│ - signal_metrics (mltable):             │
│   - group                               │
│   - metric_name                         │
│   - metric_value                        │
│   - threshold_value                     │
└─────────────────────────────────────────┘

Når bruke: Built-in signals dekker ikke ditt use case (f.eks. domene-spesifikke metrics). Krav: Registrer som Azure ML component med spesifikk input/output-signatur.

Pattern 5: Event Grid Integration for Automated Retraining

┌─────────────────┐
│ Model Monitor   │
│ (threshold      │
│  breach)        │
└─────────────────┘
         │
         ▼
┌─────────────────┐
│ Event Grid      │
│ (Run status     │
│  changed)       │
└─────────────────┘
         │
         ├──► Azure Functions
         ├──► Azure Logic Apps
         └──► Azure Event Hubs
                    │
                    ▼
         ┌──────────────────┐
         │ ML Pipeline      │
         │ (Retrain + Redeploy)│
         └──────────────────┘

Event filter (⚠️ Viktig):

• Event type: Run status changed (IKKE "Dataset drift detected" som er v1)
• Advanced filter key: data.RunTags.azureml_modelmonitor_threshold_breached
• Operator: String contains
• Value: has failed due to one or more features violating metric thresholds

Beslutningsveiledning

Når bruke hva?

Scenario	Løsning	Konfidensgrad
Online endpoint med data collection	Out-of-box monitoring (data drift + prediction drift + data quality)	⭐⭐⭐⭐⭐
Batch endpoint eller ekstern deployment	Custom preprocessing component + production data monitoring	⭐⭐⭐⭐
Har ground truth tilgjengelig	Model performance signal (join via correlation ID)	⭐⭐⭐⭐⭐
Stor modell (100+ features)	Monitor top N features basert på feature importance	⭐⭐⭐⭐
Trenger custom metrics	Custom signal component (register som Azure ML component)	⭐⭐⭐⭐
Infrastruktur-overvåkning	Azure Monitor metrics + Application Insights	⭐⭐⭐⭐⭐
Distributed training debugging	Application Insights AppTraces (forward logs via env var)	⭐⭐⭐⭐
Anomaly detection på logs	KQL time series functions eller custom ML pipeline	⭐⭐⭐⭐
Automated retraining	Event Grid + Azure Functions/Logic Apps	⭐⭐⭐⭐

Data Drift vs. Concept Drift

Data Drift (✅ Detectable med monitoring):

• Hva: Input-data endrer seg (f.eks. demografiske endringer etter redistricting)
• Signal: Data drift metric overstiger threshold
• Aksjon: Retrain modell med nyere data

Concept Drift (⚠️ Krever model performance monitoring):

• Hva: Sammenhengen mellom input og output endrer seg (f.eks. ny konkurrent endrer consumer behavior)
• Signal: Model performance degraderer (accuracy/precision synker)
• Aksjon: Feature engineering eller ny modell-arkitektur

Integrasjon med Microsoft-stakken

Azure Machine Learning

SDK v2 (✅ Anbefalt):

from azure.ai.ml.entities import (
    MonitorSchedule,
    MonitorDefinition,
    ServerlessSparkCompute,
    DataDriftSignal,
    AlertNotification
)

# Opprett monitor med Python SDK
monitor = MonitorSchedule(
    name="my_monitor",
    trigger=RecurrenceTrigger(frequency="day", interval=1),
    create_monitor=MonitorDefinition(
        compute=ServerlessSparkCompute(instance_type="standard_e4s_v3"),
        monitoring_signals={"data_drift": DataDriftSignal(...)},
        alert_notification=AlertNotification(emails=["ops@example.com"])
    )
)
ml_client.schedules.begin_create_or_update(monitor)

CLI v2 (⚙️ YAML-basert):

# monitoring.yaml
$schema: http://azureml/sdk-2-0/Schedule.json
trigger:
  type: recurrence
  frequency: day
  interval: 1
create_monitor:
  compute:
    instance_type: standard_e4s_v3
  monitoring_signals:
    data_drift:
      type: data_drift
      metric_thresholds:
        numerical:
          jensen_shannon_distance: 0.01

Azure Monitor

Azure Machine Learning Monitoring Architecture (2026) — Verified (MCP 2026-04)

Azure Monitor integration:

• All metrics in namespace: Machine Learning Service Workspace
• Platform metrics collected automatically, no configuration needed
• Route resource logs to Log Analytics for querying with KQL

Key Kusto (KQL) queries:

# Failed jobs last 5 days
AmlComputeJobEvent
| where TimeGenerated > ago(5d) and EventType == "JobFailed"
| project TimeGenerated, ClusterId, EventType, ExecutionState, ToolType

# Failed online endpoint requests
AmlOnlineEndpointTrafficLog
| where TimeGenerated > ago(1d) and ResponseCode != 200
| project TimeGenerated, EndpointName, DeploymentName, ResponseCode

Recommended alert rules:

Alert	Condition	Threshold
Model Deploy Failed	Total > 0	Any failure
Quota Utilization	Average > 90%	High utilization
Unusable Nodes	Total > 0	Any unusable

Application Insights integration: Live metrics, Transaction search, Failures, Performance analysis. Use workspace-based Application Insights (default for new workspaces) + Azure Monitor Private Link for VNet isolation.

Data storage layers:

• Metrics database: Platform metrics (near real-time)
• Log Analytics: Resource logs + Activity log (queryable with KQL)
• Azure Storage / Event Hubs: Long-term export

Cross-workspace monitoring: Use single Log Analytics workspace for multiple Azure ML workspaces to query across all resources simultaneously.

Application Insights (📊 For endpoints):

# Enable for online endpoint
deployment = ManagedOnlineDeployment(
    name="blue",
    endpoint_name="my-endpoint",
    app_insights_enabled=True  # ← Enabler App Insights
)

Query logs via Python:

from azure.monitor.query import LogsQueryClient

client = LogsQueryClient(credential)
response = client.query_workspace(
    workspace_id=workspace_id,
    query="AppTraces | where Message contains 'ERROR' | take 100",
    timespan=timedelta(hours=1)
)

Event Grid

Subscription for monitoring alerts:

1. Create Event Grid system topic for ML workspace
2. Create subscription med filter:
   • Event type: Run status changed
   • Advanced filter: data.RunTags.azureml_modelmonitor_threshold_breached contains has failed
3. Configure endpoint (Event Hubs, Functions, Logic Apps)

Microsoft Foundry (GenAI-specific)

Generation Quality Monitoring (🤖 For LLM-apps):

from azure.ai.ml.entities import GenerationSafetyQualitySignal

gsq_signal = GenerationSafetyQualitySignal(
    metric_thresholds={
        "groundedness": {"aggregated_groundedness_pass_rate": 0.7},
        "relevance": {"aggregated_relevance_pass_rate": 0.7}
    },
    production_data=[LlmData(
        data_column_names={
            "prompt_column": "question",
            "completion_column": "answer",
            "context_column": "context"
        }
    )]
)

Token Usage Monitoring (💰 Cost tracking):

• GenerationTokenStatisticsSignal tracker token usage automatisk
• Ingen thresholds påkrevd (informasjonell metric)

Offentlig sektor (Norge)

Relevante hensyn

Personvern og GDPR:

• Ground truth data: Må anonymiseres før lagring som Azure ML data asset
• Inference logs: Vurder PII-filter før data collection (custom preprocessing component)
• Application Insights: 90 dagers default retention – vurder kortere for sensitive data
• Log Analytics: Konfigurer table-level retention policies (Basic vs. Analytics logs)

Compliance-krav:

• Revisjon: Alle monitoring alerts og actions logges i Azure Activity Log (90 dager, eksporter til Storage for lengre retention)
• Sporbarhet: Bruk correlation IDs for å spore requests end-to-end (inference → monitoring → retraining)
• Tilgangskontroll: RBAC på Log Analytics workspace (Reader, Contributor, Log Analytics Reader, Monitoring Metrics Publisher)

Etterrettelighet (Auditability):

• Model lineage tracking: Link monitoring til deployment → model → training run
• Threshold justifications: Dokumenter hvorfor spesifikke thresholds er valgt
• Alert response SLAs: Definer hvordan alerts skal håndteres (eskalering, retraining)

Anbefalinger for norsk offentlig sektor:

1. Start konservativt: Høye thresholds først (unngå alert fatigue), juster basert på historikk
2. Combiner med ROS-analyse: Monitor ikke bare teknisk drift, men også risikoscenarioer (f.eks. bias i prediksjoner)
3. Integrer med eksisterende drift: Event Grid → ServiceNow/ITSM for incident management
4. Dokumenter beslutninger: Bruk Azure ML model lineage til å koble monitoring-alerts til ADRs

Eksempel: NAV-scenario

Use case: Modell for å predikere sannsynlighet for retur til arbeid

Monitoring setup:
├─ Data drift (top 10 features): Threshold 0.02 (2% drift)
│  └─ Rationale: Demografiske endringer skjer langsomt
├─ Model performance (ukentlig ground truth join): Threshold accuracy > 0.85
│  └─ Rationale: Under 85% accuracy gir for mange false positives
├─ Custom signal: Bias detection (protected attributes drift)
│  └─ Rationale: GDPR Art. 22 + Diskrimineringsloven
└─ Alert notification → Slack + PagerDuty

Event Grid integration:
└─ Threshold breach → Retrain pipeline (requires manual approval for deployment)

Kostnad og lisensiering

Azure Machine Learning Model Monitoring

Compute-kostnader (💰 Varierer med frekvens):

• Serverless Spark compute: Pay-per-use (ingen kostnad når ikke kjører)
• Standard_E4s_v3: ~$0.50/time (ca. 5 NOK/time)
• Kjøretid per run: 5-20 minutter avhengig av datavolum og antall signals

Estimat (📊 Daglig monitoring, 3 signals, 10 minutter per run):

• Månedlig compute: ~30 runs × 10 min × $0.50/time / 60 = $2.50/måned (~25 NOK/måned)

Storage-kostnader:

• Azure Blob Storage (inference data): Hot tier $0.02/GB/måned (~0.20 NOK/GB/måned)
• Estimat: 100 GB/måned = $2/måned (~20 NOK/måned)

Azure Monitor

Application Insights:

• Data ingestion: $2.76/GB etter gratis 5 GB/måned (~28 NOK/GB)
• Data retention: Gratis første 90 dager, deretter $0.12/GB/måned (~1.20 NOK/GB/måned)
• Live Metrics Stream: Gratis

Log Analytics:

• Data ingestion: $3.11/GB etter gratis 5 GB/måned (~31 NOK/GB)
• Data retention: Gratis første 31 dager, deretter $0.12/GB/måned (~1.20 NOK/GB/måned)
• Basic logs: Billigere ingestion ($0.62/GB, ~6 NOK/GB) men begrenset query capabilities

Estimat (🧮 1000 requests/dag, 1 KB per log):

• Månedlig ingestion: 30 GB → (30-5) × $2.76 = $69/måned (~690 NOK/måned)

Event Grid

Gratis tier: Første 100k operasjoner/måned gratis Deretter: $0.60 per million operasjoner (~6 NOK per million)

Optimaliseringsstrategier

1. Reduser monitoring frequency: Ukentlig i stedet for daglig hvis lav trafikk
2. Sample production data: Monitor subset (10-50%) hvis høyt volum
3. Bruk Basic logs: For non-kritiske logs (80% billigere ingestion)
4. Export old data: Move fra Log Analytics til Azure Storage etter 31 dager (99% billigere)
5. Kombiner signals: Bruk top N features i stedet for all features

Lisensieringskrav

Komponent	Lisens påkrevd	Detaljer
Azure ML Model Monitoring	Azure ML workspace	Gratis (betaler kun compute/storage)
Azure Monitor Metrics	Inkludert i Azure-subscription	Gratis platform metrics
Application Insights	Pay-as-you-go	Ingen forhåndskostnad
Log Analytics	Pay-as-you-go	Ingen forhåndskostnad
Event Grid	Pay-as-you-go	100k operasjoner/måned gratis

Ingen premium-lisensiering påkrevd for standard monitoring-scenarioer.

For arkitekten (Cosmo)

Når jeg anbefaler dette

Go for Azure ML Model Monitoring når:

• ✅ Du deployer ML-modeller til Azure ML online endpoints
• ✅ Du trenger continuous monitoring av data drift, prediction drift, data quality
• ✅ Du har ground truth data tilgjengelig (eller kan samle det)
• ✅ Du vil automatisere retraining basert på threshold breaches
• ✅ Du trenger feature-level granularitet (top N features)

Kombiner med Azure Monitor når:

• 📊 Du trenger infrastruktur-metrics (CPU, memory, latency)
• 🔍 Du trenger deep telemetry (distributed training logs, custom traces)
• 📈 Du vil visualisere metrics i Grafana/Power BI
• 🚨 Du trenger sanntids-alerting (Live Metrics Stream)

Vurder custom ML pipeline på logs når:

• 🔬 Built-in signals ikke dekker ditt use case
• 🧠 Du trenger avansert anomaly detection (multi-variate, deep learning-basert)
• 🔄 Du vil korrelere ML-metrics med business-metrics fra andre kilder

Anbefalte startpunkter

Dag 1: Enable data collection på online endpoints

deployment = ManagedOnlineDeployment(
    name="blue",
    data_collector=DataCollector(
        collections={
            "model_inputs": DataCollectionMode.ENABLED,
            "model_outputs": DataCollectionMode.ENABLED
        }
    )
)

Dag 2: Sett opp out-of-box monitoring (data drift + prediction drift + data quality)

az ml schedule create -f out-of-box-monitoring.yaml

Uke 2: Analyser første resultater i Azure ML Studio → juster thresholds basert på faktisk drift

Uke 4: Legg til model performance monitoring (hvis ground truth tilgjengelig)

Måned 2: Integrer Event Grid for automated alerting til eksisterende incident management

Måned 3: Vurder custom signals for domene-spesifikke metrics

Vanlige fallgruver

❌ IKKE:

• Start med for mange signals og for lave thresholds (alert fatigue)
• Glem å sette opp alerting (monitoring uten action er bortkastet)
• Bruk samme threshold for alle features (forskjellige features drifter forskjellig)
• Ignorer feature importance (monitor alt = dyrt og støyete)
• Deploy uten data collection enablet (kan ikke enable retrospektivt)

✅ GJØR:

• Start med 3-4 signals (data drift, prediction drift, data quality)
• Involver data scientists i threshold-setting (de kjenner modellen)
• Monitor top 10-20 features basert på feature importance
• Sett opp scheduled monitoring umiddelbart etter deployment
• Test alerting-flow før produksjon (send test-alerts)

Arkitekturbeslutninger

ADR-forslag: "Hvordan skal vi overvåke ML-modeller i produksjon?"

Kontekst: Vi deployer ML-modeller til Azure ML online endpoints og trenger kontinuerlig overvåkning for å detektere model decay (data drift, concept drift) og infrastruktur-problemer.

Beslutning: Vi bruker Azure Machine Learning Model Monitoring for modell-spesifikke signals (data drift, prediction drift, model performance) og Azure Monitor + Application Insights for infrastruktur-metrics (latency, CPU, errors).

Konsekvenser:

• Pros: Standardisert Microsoft-løsning, integrasjon med Event Grid for automated retraining, granulær feature-level monitoring
• Cons: Krever ground truth data collection for model performance monitoring, compute-kostnad for Spark-based monitoring jobs
• Risiko: Alert fatigue hvis thresholds settes for lavt, data privacy hvis PII ikke filtreres

Alternativer vurdert:

1. Custom Prometheus/Grafana stack → Forkastet (krever mer vedlikehold)
2. MLflow tracking only → Forkastet (mangler production monitoring capabilities)
3. Azure Monitor Logs only → Forkastet (mangler ML-spesifikke signals som data drift)

Integrasjonspunkter

Med andre Microsoft AI-tjenester:

• Microsoft Foundry: Generation quality monitoring for LLM-apps (groundedness, relevance, coherence)
• Power Platform: Monitor AI Builder models (custom vision, form processing) via Azure Monitor
• Copilot Studio: Track conversation quality metrics via Application Insights custom events
• Semantic Kernel: Instrument med OpenTelemetry → Azure Monitor

Med eksisterende IT-drift:

• ServiceNow/ITSM: Event Grid → Azure Functions → ServiceNow Incident API
• Slack/Teams: Alert notifications via Logic Apps
• PagerDuty: Event Grid → PagerDuty Events API v2

Spørsmål å stille kunden

1. "Har dere tilgang til ground truth data for modellen?" → Hvis ja: Sett opp model performance monitoring. Hvis nei: Fokuser på data drift og prediction drift.

2. "Hvor ofte oppdateres produksjonsdata?" → Bestemmer monitoring frequency (daglig hvis høy trafikk, ukentlig/månedlig hvis lavt volum).

3. "Hva er konsekvensen av feil prediksjoner i deres domene?" → Bestemmer hvor konservative thresholds bør være (kritiske systemer = lave thresholds).

4. "Har dere eksisterende incident management system?" → Integrer Event Grid med dette (ikke bygg nytt).

5. "Har dere data scientists som kan sette thresholds?" → Hvis ja: Involver dem. Hvis nei: Start med Microsoft-anbefalte default thresholds.

6. "Trenger dere automated retraining eller manuell review?" → Bestemmer Event Grid-integrasjon (automated) vs. bare email alerts (manuell).

Sammendrag for arkitekturforslag

TL;DR: Azure Machine Learning Model Monitoring gir production-ready overvåkning av ML-modeller med built-in signals for data drift, prediction drift, og data quality. Kombiner med Azure Monitor for infrastruktur-metrics. Integrer Event Grid for automated retraining. Start med out-of-box monitoring og juster thresholds basert på faktisk drift.

Key takeaways:

• ⚙️ Enable data collection fra dag 1 (kan ikke enable retrospektivt)
• 📊 Monitor top N features (ikke alt) for cost efficiency
• 🔄 Kombiner flere signals for bred overvåkning
• 🚨 Integrer med eksisterende alerting-systemer
• 💰 Compute-kostnad er lav (~25-50 NOK/måned for daglig monitoring)
• 🔐 Filtrer PII før logging (GDPR-compliance)

---

Kilder og verifisering

Primærkilder (✅ Verifisert 2026-04):

1. Monitor the performance of models deployed to production
2. Azure Machine Learning model monitoring
3. Detect and mitigate potential issues using AIOps and machine learning in Azure Monitor
4. Monitor Azure Machine Learning
5. Send distributed training logs to Azure Application Insights

Kodeeksempler verifisert fra:

• azureml-examples GitHub repo (out-of-box-monitoring.yaml, advanced-model-monitoring.yaml)
• Azure Monitor Query Python samples (notebooks for anomaly detection)

Konfidensmarkører:

• ⭐⭐⭐⭐⭐ = Verifisert mot offisiell Microsoft-dokumentasjon
• ⭐⭐⭐⭐ = Basert på Microsoft Learn, men med noe tolkning
• ⭐⭐⭐ = Community best practices (ikke offisiell Microsoft-guidance)

Sist verifisert: 2026-04 Neste review: Når Azure ML Model Monitoring v3 lanseres (roadmap Q2 2026)