feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command
Add /ultraresearch-local for structured research combining local codebase analysis with external knowledge via parallel agent swarms. Produces research briefs with triangulation, confidence ratings, and source quality assessment. New command: /ultraresearch-local with modes --quick, --local, --external, --fg. New agents: research-orchestrator (opus), docs-researcher, community-researcher, security-researcher, contrarian-researcher, gemini-bridge (all sonnet). New template: research-brief-template.md. Integration: --research flag in /ultraplan-local accepts pre-built research briefs (up to 3), enriches the interview and exploration phases. Planning orchestrator cross-references brief findings during synthesis. Design principle: Context Engineering — right information to right agent at right time. Research briefs are structured artifacts in the pipeline: ultraresearch → brief → ultraplan --research → plan → ultraexecute. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen
commit
baa2d0220b
488 changed files with 213221 additions and 0 deletions
|
|
@ -0,0 +1,609 @@
|
|||
# Monitoring and Observability for ML Systems
|
||||
|
||||
**Kategori:** MLOps & GenAIOps
|
||||
**Dato:** 2026-02-04
|
||||
**Kilder:** Microsoft Learn (azure-machine-learning, azure-monitor)
|
||||
**Konfidensgrad:** ⭐⭐⭐⭐⭐ (Verifisert mot offisiell Microsoft-dokumentasjon)
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
|
||||
**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-02-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-02-04
|
||||
**Neste review:** Når Azure ML Model Monitoring v3 lanseres (roadmap Q2 2026)
|
||||
Loading…
Add table
Add a link
Reference in a new issue