# Monitoring and Observability for ML Systems

**Kategori:** MLOps & GenAIOps
**Dato:** 2026-04
**Kilder:** Microsoft Learn (azure-machine-learning, azure-monitor)
**Konfidensgrad:** ⭐⭐⭐⭐⭐ (Verifisert mot offisiell Microsoft-dokumentasjon)

---

**Verified:** MCP 2026-04

## 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

```yaml
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):
```python
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):
```yaml
# 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**:
```kusto
# 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):
```python
# Enable for online endpoint
deployment = ManagedOnlineDeployment(
    name="blue",
    endpoint_name="my-endpoint",
    app_insights_enabled=True  # ← Enabler App Insights
)
```

**Query logs via Python**:
```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)

### Azure AI Foundry (GenAI-specific)

**Generation Quality Monitoring** (🤖 For LLM-apps):
```python
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
```python
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)
```bash
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:**
- **Azure AI 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](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-monitor-model-performance?view=azureml-api-2)
2. [Azure Machine Learning model monitoring](https://learn.microsoft.com/en-us/azure/machine-learning/concept-model-monitoring?view=azureml-api-2)
3. [Detect and mitigate potential issues using AIOps and machine learning in Azure Monitor](https://learn.microsoft.com/en-us/azure/azure-monitor/aiops/aiops-machine-learning)
4. [Monitor Azure Machine Learning](https://learn.microsoft.com/en-us/azure/machine-learning/monitor-azure-machine-learning?view=azureml-api-2)
5. [Send distributed training logs to Azure Application Insights](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-log-search?view=azureml-api-2)

**Kodeeksempler verifisert fra:**
- [azureml-examples GitHub repo](https://github.com/Azure/azureml-examples) (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)