ms-ai-architect/skills/ms-ai-security/references/cost-optimization/observability-cost-reduction.md

# Observability and Monitoring Cost Optimization

**Last updated:** 2026-06-19 | Verified: MCP 2026-06
**Status:** GA
**Category:** Cost Optimization & FinOps for AI
**Type:** reference
**Source:** https://learn.microsoft.com/azure/azure-monitor/app/opentelemetry-configuration

---

## Innhold

- [Introduksjon](#introduksjon)
- [Kjernekomponenter](#kjernekomponenter)
- [Arkitekturmønstre](#arkitekturmønstre)
- [Beslutningsveiledning](#beslutningsveiledning)
- [Integrasjon med Microsoft-stakken](#integrasjon-med-microsoft-stakken)
- [Offentlig sektor (Norge)](#offentlig-sektor-norge)
- [Kostnad og lisensiering](#kostnad-og-lisensiering)
- [For arkitekten (Cosmo)](#for-arkitekten-cosmo)
- [Kilder og verifisering](#kilder-og-verifisering)

## Introduksjon

Observability og monitoring er kritiske for produksjonsklare AI-løsninger, men kan raskt bli en betydelig kostnadsfaktor hvis de ikke konfigureres riktig. Azure Monitor, Application Insights og Log Analytics workspace representerer ofte 15-30% av den totale driftskostnaden for AI-workloads. Denne referansen fokuserer på strategier for å optimalisere kostnader knyttet til telemetri-innsamling, lagring og spørringer, samtidig som du opprettholder nødvendig innsikt i systemets helse og ytelse.

Kostnadsoptimalisering av observability handler om å finne balansen mellom detaljnivå og kostnad. For AI-workloads er det spesielt viktig å skille mellom kritiske produksjons-signaler (som må logges 100%) og mindre viktige debug-data (som kan samples aggressivt). En typisk feilkonfigurasjon er å samle full telemetri fra alle miljøer – produktiv bruk av sampling, retention policies og table plans kan redusere monitoring-kostnader med 50-70% uten at du mister kritisk diagnostisk kapasitet.

Moderne Azure Monitor tilbyr flere kostnadseffektive alternativer som Basic Logs (redusert ingestion-pris), long-term retention (billigere arkivering), og adaptive sampling-mekanismer. For AI-løsninger som genererer store volumer av telemetri (f.eks. inference-requests, embedding-operasjoner, eller RAG-pipeline-traces), er riktig konfigurering av disse mekanismene forskjellen mellom en bærekraftig og en uhåndterbar kostnad.

## Kjernekomponenter

### Azure Monitor-økosystemet

| Komponent | Funksjon | Prising | Optimaliserings-mulighet |
|-----------|----------|---------|--------------------------|
| **Application Insights** | Telemetri for applikasjoner (traces, dependencies, requests, exceptions) | Per GB ingested data (workspace-based) | Sampling, filtering, retention-tuning |
| **Log Analytics Workspace** | Sentral lagrings- og query-motor for all log-data | Per GB ingestion + retention cost | Commitment tiers, Basic/Auxiliary tables, long-term retention |
| **Azure Monitor Metrics** | Pre-aggregerte metrics (aldri samplet) | Inkludert i platform metrics, ekstra kostnad for custom metrics | Reduser antall custom metric-dimensjoner |
| **Azure Monitor Logs** | Strukturerte logger fra Azure-ressurser | Per GB ingestion + retention cost | Data Collection Rules (DCRs) for filtering |

### Kostnadsmodeller for Log Analytics

| Modell | Beskrivelse | Når å bruke | Besparelse |
|--------|-------------|-------------|------------|
| **Pay-as-you-go** | Standard prising per GB | Lave volumer (<100 GB/dag) | Baseline |
| **Commitment Tiers** | Forhåndsbetalte daglige volumer (100 GB, 200 GB, 500 GB, osv.) | Stabile, høye volumer | Opptil 30% rabatt |
| **Basic Logs** | Redusert ingestion-pris, query-kostnad, begrenset query-tid (8 dager) | Debugging, troubleshooting, audit-logs | Opptil 50% lavere ingestion |
| **Auxiliary Logs** | Lavest ingestion-pris, kun for search jobs | Verbose logs, kun sporadisk query | Opptil 75% lavere ingestion |
| **Long-term Retention** | Arkivering utover interactive retention (opptil 12 år) | Compliance, historiske analyser | Opptil 90% lavere retention-kostnad |

### Sampling-strategier

| Strategi | Mekanisme | Bruksområde | Trade-off |
|----------|-----------|-------------|-----------|
| **Adaptive Sampling** | Automatisk justering basert på telemetri-volum (default: 5 items/sec) — gjelder **kun Classic API SDK** (ASP.NET, ASP.NET Core). OpenTelemetry-baserte distros har **ikke** adaptive sampling aktivert som default. | ASP.NET, ASP.NET Core, Azure Functions | Reduserer volum uten konfigurasjon (Classic SDK kun), kan miste sjeldne events | Verified (MCP 2026-04) |
| **Fixed-rate Sampling** | Fast prosentandel (f.eks. 10%, 25%, 50%) | Konsistent sampling på tvers av client/server | Forutsigbar reduksjon, krever manuell tuning |
| **Rate-limited Sampling** | Begrenser til maks N requests/sec (f.eks. 1.5 req/sec) | Java-applikasjoner, cost-capping | Streng volum-kontroll, kan miste spikes |
| **Ingestion Sampling** | Server-side sampling (kun hvis SDK ikke sampler) | Legacy apps uten SDK-sampling | Reduserer ikke nettverkstrafikk |
| **Sampling Overrides** | Regel-basert sampling per endpoint/dependency (Java) | Filtrere bort health checks, støyende dependencies | Granulær kontroll, kompleks konfigurasjon |

**Viktig:** Metrics samples aldri. Sampling påvirker kun traces (spans) og optionally logs. Alerts basert på metrics forblir nøyaktige.

**OpenTelemetry-distro (MCP 2026-06):** Azure Monitor OTel-distroen har **ikke** sampling på som default og bruker to strategier: **fixed-rate** (ratio 0–1, f.eks. `0.1` = ~10 %) og **rate-limited** (traces/sek, f.eks. `5.0` = fem traces/sek). En egen **trace-based sampling for logs** dropper logger knyttet til ikke-samplede traces og er **på som default når sampling er aktivert** (støttede språk) — gir kostnadsreduksjon utover trace-sampling alene. Distroens custom sampler bevarer hele traces (unngår broken traces) og kreves for Live Metrics. Anbefalt logg-strategi: eksporter kun `ERROR` (legg til `WARN` kun når handlingsrettet).

## Arkitekturmønstre

### Mønster 1: Full Observability (Production-Grade AI)

**Scenario:** Kritiske AI-tjenester med strenge SLA-krav, feilsøking må være mulig for alle requests.

**Konfigurasjon:**
- **Sampling:** Deaktivert for kritiske flows (errors alltid 100%), 10% for success-cases
- **Retention:** 90 dager interactive, 2 år long-term retention
- **Table Plan:** Analytics for `requests`, `exceptions`, `dependencies`; Basic for `traces`
- **Alerts:** Sanntids-alerting på kritiske metrics (failure rate, latency)

**Kostnad:** Høy (baseline), men komplett diagnostisk kapasitet.

**Eksempel (Application Insights, ASP.NET Core):**
```csharp
builder.Services.Configure<TelemetryConfiguration>(telemetryConfiguration =>
{
   var builder = telemetryConfiguration.DefaultTelemetrySink.TelemetryProcessorChainBuilder;

   // Adaptive sampling: 10 items/sec (ikke 5 default)
   builder.UseAdaptiveSampling(maxTelemetryItemsPerSecond: 10, excludedTypes: "Exception");

   builder.Build();
});

builder.Services.AddApplicationInsightsTelemetry(new ApplicationInsightsServiceOptions
{
   EnableAdaptiveSampling = false, // Bruk egen konfigurasjon
});
```

**Norsk offentlig sektor:** Full observability passer for fagsystemer med persondata der sporbarhet er lovpålagt (Arkivloven, GDPR).

---

### Mønster 2: Sampled Monitoring (Cost-Optimized AI)

**Scenario:** AI-tjenester med høyt request-volum (tusenvis av inference-requests/dag), hvor kostnadskontroll er viktigere enn full trace-visibilitet.

**Konfigurasjon:**
- **Sampling:** Fixed-rate 1-5% for normale requests, 100% for errors
- **Retention:** 30 dager interactive, 1 år long-term retention for compliance
- **Table Plan:** Basic for `traces` og `dependencies`, Analytics kun for `exceptions`
- **Pre-aggregated Metrics:** Bruk metrics for dashboards, ikke log queries

**Kostnad:** 50-70% reduksjon vs. full observability.

**Eksempel (Java Agent 3.7.5+, rate-limited sampling):**
```json
{
  "sampling": {
    "requestsPerSecond": 1.5
  }
}
```

**Eksempel (Sampling overrides for health checks):**
```json
{
  "preview": {
    "sampling": {
      "overrides": [
        {
          "telemetryType": "request",
          "attributes": [
            {
              "key": "http.url",
              "value": "https://.*/health",
              "matchType": "regexp"
            }
          ],
          "percentage": 0
        }
      ]
    }
  }
}
```

**Norsk offentlig sektor:** Egnet for chatbots og AI-assistenter uten persondata, der full logging ikke er lovpålagt.

---

### Mønster 3: Tiered Retention (Compliance-Driven)

**Scenario:** AI-løsninger som må oppbevare logs for compliance (Arkivloven, Riksrevisjonen), men som sjelden spørrer historiske data.

**Konfigurasjon:**
- **Interactive Retention:** 30 dager (for daglig bruk)
- **Long-term Retention:** 7 år (arkivering, søk via search jobs)
- **Table Plan:** Auxiliary for verbose logs (kun søk når nødvendig)
- **Data Export:** Eksporter til Azure Storage for billig langtidslagring

**Kostnad:** 80-90% reduksjon i retention-kostnader.

**Eksempel (Kusto-query for retention-konfigurasjon):**
```kusto
// Sett 7 års long-term retention på AppTraces-tabellen
.alter-merge table AppTraces policy retention
```
{
    "SoftDeletePeriod": "2555d",  // 7 år
    "Recoverability": "Enabled"
}
```
```

**Norsk offentlig sektor:** Påkrevd for fagsystemer underlagt Arkivloven § 6 (bevaring i minimum 5 år, ofte 10 år).

## Beslutningsveiledning

### Når skal du bruke Basic Logs?

| Kriterium | Analytics | Basic | Auxiliary |
|-----------|-----------|-------|-----------|
| **Query-frekvens** | Daglig/ukentlig | Månedlig/ved incidents | Sjelden (search jobs) |
| **Query-kompleksitet** | Full KQL, joins, aggregeringer | Begrenset KQL (8 dager) | Search jobs kun |
| **Ingestion-volum** | Moderat | Høyt (debugging) | Veldig høyt (verbose) |
| **Alerts** | Støttes | ✅ (Simple Log Alerts) — Verified (MCP 2026-04) | Støttes ikke |
| **Retention** | 30-730 dager | 8 dager interactive + long-term | Long-term kun |
| **Pris (ingestion)** | Standard | ~50% lavere | ~75% lavere |
| **Workspace replication** | ✅ | ✅ | ❌ (data ikke replikert — ingen beskyttelse ved regional feil) |
| **Customer Lockbox** | ✅ | ✅ | ❌ (Lockbox-grensesnitt gjelder ikke for Auxiliary-tabeller) |

**Beslutningstre:**
1. **Trenger du real-time alerting?** → Analytics
2. **Queries kun ved feilsøking?** → Basic (støtter Simple Log Alerts — Verified MCP 2026-04)
3. **Kun compliance-arkivering?** → Auxiliary (støtter Microsoft Sentinel og Search jobs — Verified MCP 2026-04)

### Vanlige feil

| Feil | Konsekvens | Løsning |
|------|------------|---------|
| **Sampling deaktivert i prod** | Ekstremt høy ingestion-kostnad | Aktiver adaptive sampling (minimum 10% fixed) |
| **Alle tables i Analytics-plan** | Betaler full pris for debug-logs | Flytt `AppTraces`, `AppDependencies` til Basic |
| **Retention 90 dager for alt** | Unødvendig høy retention-kostnad | Bruk 30 dager interactive + long-term for compliance |
| **Custom metrics med mange dimensjoner** | Høy custom metric-kostnad | Bruk pre-aggregated metrics, reduser dimensjoner |
| **Ingen Data Collection Rules (DCRs)** | Samler unødvendige logs fra Azure-ressurser | Filtrer bort støyende logs via DCRs |
| **Daily cap som primær kostnadskontroll** | Mister data ved cap-overskridelse | Bruk commitment tiers + sampling i stedet |

### Røde flagg

- **Ingestion >500 GB/dag uten commitment tier** → Du betaler 30% for mye
- **Query-kostnader >10% av total Monitor-kostnad** → For mange queries mot Basic/Auxiliary tables
- **`itemCount` alltid 1 i telemetri** → Sampling er ikke konfigurert
- **Ingen telemetri fra errors** → For aggressiv sampling, juster excluded types

## Integrasjon med Microsoft-stakken

### Application Insights

**Workspace-based vs. Classic:**
- **Workspace-based** (anbefalt): Lagrer data i Log Analytics workspace, kan bruke commitment tiers og Basic Logs
- **Classic** (deprecated): Pay-as-you-go kun, kan ikke bruke moderne kostnadsoptimaliseringer

**Migration-path:** Flytt Classic AI resources til workspace-based for å få tilgang til commitment tiers.

### Log Analytics Workspace

**Commitment Tiers:**
| Tier | Daglig volum | Pris/GB (ca. Norge) | Besparelse vs. PAYG |
|------|--------------|---------------------|---------------------|
| Pay-as-you-go | Variabel | ~70 NOK/GB | 0% |
| 100 GB/dag | 100 GB | ~50 NOK/GB | 30% |
| 200 GB/dag | 200 GB | ~48 NOK/GB | 32% |
| 500 GB/dag | 500 GB | ~45 NOK/GB | 35% |

**Dedicated Clusters:**
For volumer >1 TB/dag, vurder dedicated cluster for ytterligere besparelser (cluster commitment tier).

### Microsoft Foundry & Azure OpenAI

**Telemetri-volum:**
- **Inference-requests:** 1-5 KB per request (prompt + completion metadata)
- **Embeddings:** 0.5-2 KB per request
- **Fine-tuning logs:** Høyt volum (vurder Basic Logs)

**Optimalisering:**
- Bruk **metrics** for throughput-monitoring (gratis pre-aggregated metrics)
- Sample **successful requests** 5-10%, behold 100% errors
- Bruk **Diagnostic Settings** til å filtrere bort health checks

### Microsoft Semantic Kernel

**Logging-strategi:**
- **Development:** Full logging (trace level)
- **Production:** Warning/Error level + 10% sampling av Info-level
- **Custom telemetry:** Bruk `ILogger` med Application Insights, ikke custom events (dyrere)

## Offentlig sektor (Norge)

### Arkivloven

**§ 6 - Bevaringsplikt:**
- **Minimum:** 5 år for elektroniske dokument (kan forlenges til 10-25 år)
- **Implementering:** Bruk long-term retention (7-10 år) i Log Analytics
- **Kostnadsoptimalisering:** Flytt til Auxiliary tables etter 30 dager, søk via search jobs ved behov

**§ 9 - Tilgjengelighetskrav:**
- Arkiverte logs må kunne gjenfinnes "innen rimelig tid"
- **Search jobs** i Azure Monitor oppfyller dette (kjøres asynkront, resultater tilgjengelig i timevis/dager)

### Riksrevisjonen

**Revisjonskrav:**
- Full sporbarhet av administrative beslutninger (hvem, hva, når)
- **Implementering:** Behold `AuditLogs`, `SecurityEvent` i Analytics-plan med 90 dagers retention + 7 års long-term
- **Kostnadsoptimalisering:** Bruk Data Export til Azure Storage for billigere arkivering av rådata

### GDPR / Personvernforordningen

**Lagringsminimering (Art. 5.1.e):**
- Ikke behold persondata lengre enn nødvendig
- **Implementering:** Separate workspaces for persondata (kort retention) og operational data (lang retention)
- **Purge API:** Slett person-identifiserbare telemetri ved slettingsforespørsler (GDPR Art. 17)

### Sikkerhetsloven (Nasjonal Sikkerhetsmyndighet)

**Logging av sikkerhetshendelser:**
- Kritiske systemer må logge sikkerhetsrelevante hendelser i minimum 6 måneder
- **Implementering:** Microsoft Sentinel (hvis aktivert) krever Log Analytics workspace, kombiner sikkerhet + operational data kun hvis kostnadseffektivt (vurder separate workspaces)

## Kostnad og lisensiering

### Prismodell (Norge, ca. 2026)

| Komponent | Enhet | Pris (NOK eks. mva) |
|-----------|-------|---------------------|
| **Log Analytics Ingestion (PAYG)** | Per GB | ~70 NOK |
| **Log Analytics Ingestion (100 GB tier)** | Per GB | ~50 NOK |
| **Basic Logs Ingestion** | Per GB | ~35 NOK |
| **Auxiliary Logs Ingestion** | Per GB | ~18 NOK |
| **Data Retention (30+ dager)** | Per GB/måned | ~8 NOK |
| **Long-term Retention (archive)** | Per GB/måned | ~1 NOK |
| **Basic/Auxiliary Query** | Per GB scanned | ~6 NOK |
| **Search Job** | Per GB scanned | ~6 NOK |
| **Data Export** | Per GB exported | ~5 NOK |

**Eksempel-beregning (AI chatbot, 100k requests/dag):**

**Baseline (ingen optimalisering):**
- Telemetri-volum: 100k requests × 3 KB = 300 MB/dag = 9 GB/måned
- Ingestion: 9 GB × 70 NOK = **630 NOK/måned**
- Retention (90 dager): 27 GB × 8 NOK = **216 NOK/måned**
- **Total:** 846 NOK/måned

**Optimalisert (10% sampling, Basic Logs):**
- Sampled volum: 9 GB × 10% = 0.9 GB/måned
- Ingestion (Basic): 0.9 GB × 35 NOK = **32 NOK/måned**
- Retention (30 dager): 2.7 GB × 8 NOK = **22 NOK/måned**
- **Total:** 54 NOK/måned (**94% besparelse**)

### Optimaliseringstips

1. **Start med commitment tier-kalkulatoren:** Azure Portal → Log Analytics Workspace → Usage and Estimated Costs
2. **Analyser ingestion-kilder:** Kjør query for å identifiere høy-volum tables:
   ```kusto
   Usage
   | where TimeGenerated > ago(30d)
   | summarize IngestedGB = sum(Quantity) / 1000 by DataType
   | order by IngestedGB desc
   ```
3. **Identifiser sampling-muligheter:**
   ```kusto
   requests
   | where timestamp > ago(1d)
   | summarize RetainedPercentage = 100/avg(itemCount)
   // Hvis RetainedPercentage = 100%, sampling er ikke aktivert
   ```
4. **Vurder Basic Logs for debug-tables:**
   - `AppTraces`, `AppDependencies` (hvis kun queries ved incidents)
   - `ContainerLog`, `AzureDiagnostics` (hvis verbose logging)

## For arkitekten (Cosmo)

### Nøkkelspørsmål

1. **Hva er akseptabel diagnostisk latency?**
   - Sanntids-alerting → Analytics plan, aktiver sampling forsiktig
   - Daglig/ukentlig analyse → Basic Logs OK
   - Kun compliance → Auxiliary + long-term retention

2. **Hvor mye telemetri genererer løsningen (GB/dag)?**
   - <10 GB/dag → Pay-as-you-go, vurder sampling
   - 10-100 GB/dag → Vurder commitment tier
   - >100 GB/dag → Commitment tier obligatorisk, aggressive sampling

3. **Hvilke events må logges 100%?**
   - Errors/exceptions → Alltid 100%
   - Security events → 100%
   - Business-critical transactions → 100%
   - Health checks, debug traces → 0-10%

4. **Hva er retention-krav?**
   - Compliance-driven (Arkivloven) → Long-term retention
   - Operasjonell troubleshooting → 30-90 dager interactive
   - Development/test → 7-30 dager

5. **Er det persondata i telemetri?**
   - Ja → Separate workspace, kort retention, GDPR-purge-rutiner
   - Nei → Del workspace med andre apps (commitment tier-fordel)

6. **Hvor ofte kjøres log queries?**
   - Daglig (dashboards, alerts) → Analytics plan
   - Ukentlig/månedlig → Basic Logs
   - Sjelden (kun incidents) → Auxiliary + search jobs

7. **Brukes Microsoft Sentinel?**
   - Ja → All data i workspace er subject to Sentinel pricing (vurder separate workspaces)
   - Nei → Standard Log Analytics pricing

8. **Hva er prod vs. non-prod split?**
   - Dev/test → Aggressiv sampling (1-5%), kort retention (7 dager)
   - Prod → Moderat sampling (10-25%), compliance-driven retention

### Fallgruver

| Fallgruve | Hvorfor det skjer | Hvordan unngå |
|-----------|-------------------|---------------|
| **"Vi trenger full logging i prod"** | Frykt for å miste kritisk data | Start med 25% sampling, øk gradvis hvis nødvendig. Pre-aggregated metrics gir nøyaktige tall uansett. |
| **"Daily cap beskytter oss mot kostnad"** | Misforstått som primær kostnadskontroll | Daily cap stopper ingestion når nådd → data loss. Bruk commitment tier + sampling i stedet. |
| **"Vi bruker samme workspace for alt"** | Enklere administrasjon | Kostbar hvis Sentinel er aktivert. Vurder separate workspaces for security vs. operational data. |
| **"Sampling påvirker metrics"** | Feilaktig forståelse | Metrics samples aldri. Kun traces/logs påvirkes. Alerts basert på metrics er nøyaktige. |
| **"Vi trenger Analytics plan for alle tables"** | Default-konfigurasjon | Flytt debug/verbose tables til Basic Logs, spar 50% ingestion. |

### Anbefalinger per modenhetsnivå

**Nivå 1 - Proof of Concept:**
- Pay-as-you-go pricing
- Default adaptive sampling (5 items/sec)
- 30 dagers retention
- Ingen Basic Logs (forenkler setup)

**Nivå 2 - Pilot/Test:**
- Commitment tier hvis >50 GB/dag
- 10% fixed sampling for normale flows, 100% errors
- 30 dagers retention + long-term for compliance-testing
- Basic Logs for `AppTraces`

**Nivå 3 - Produksjon (Standard):**
- Commitment tier basert på faktisk volum
- Adaptive/fixed sampling per endpoint (sampling overrides)
- 90 dagers interactive + 2-7 års long-term
- Basic Logs for debug-tables, Auxiliary for verbose logs
- Data Collection Rules (DCRs) for å filtrere bort unødvendige Azure resource logs

**Nivå 4 - Enterprise/Scale:**
- Dedicated cluster (hvis >1 TB/dag på tvers av workspaces)
- Granular sampling overrides per business function
- Separate workspaces for security (Sentinel) vs. operational data
- Automatisert retention policy-management
- Data Export til Azure Data Lake for ML-analyse

## Kilder og verifisering

### Microsoft Learn-dokumentasjon (Verified via MCP 2026-04)

1. **Sampling in Application Insights:**
   https://learn.microsoft.com/en-us/azure/azure-monitor/app/sampling-classic-api
   *Confidence: Verified* – Offisiell guide til adaptive, fixed-rate og ingestion sampling.

2. **Azure Monitor Logs cost calculations and options:**
   https://learn.microsoft.com/en-us/azure/azure-monitor/logs/cost-logs
   *Confidence: Verified* – Detaljert prismodell, commitment tiers, Basic/Auxiliary tables.

3. **Configuration options: Azure Monitor Application Insights for Java:**
   https://learn.microsoft.com/en-us/azure/azure-monitor/app/java-standalone-config#sampling
   *Confidence: Verified* – Rate-limited sampling, sampling overrides.

4. **Cost optimization in Azure Monitor:**
   https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/best-practices-cost
   *Confidence: Verified* – Best practices for Application Insights, Log Analytics.

5. **Best practices for Azure Monitor Logs:**
   https://learn.microsoft.com/en-us/azure/azure-monitor/logs/best-practices-logs
   *Confidence: Verified* – Retention, commitment tiers, Basic Logs.

6. **Architecture best practices for Application Insights:**
   https://learn.microsoft.com/en-us/azure/azure-monitor/service-guides/application-insights#cost-optimization
   *Confidence: Verified* – Well-Architected Framework guidance.

7. **Troubleshoot high data ingestion in Application Insights:**
   https://learn.microsoft.com/en-us/troubleshoot/azure/azure-monitor/app-insights/telemetry/troubleshoot-high-data-ingestion
   *Confidence: Verified* – Feilsøking, sampling-strategier, daily cap.

8. **Sampling in Azure Monitor Application Insights with OpenTelemetry:**
   https://learn.microsoft.com/en-us/azure/azure-monitor/app/opentelemetry-sampling
   *Confidence: Verified* – OpenTelemetry-specific sampling (Azure Monitor Distro).

9. **Configure Azure Monitor OpenTelemetry - Enable Sampling:**
   https://learn.microsoft.com/en-us/azure/azure-monitor/app/opentelemetry-configuration#enable-sampling
   *Confidence: Verified* – Environment variables, code-based config.

10. **Azure Monitor Logs overview: Table plans:**
    https://learn.microsoft.com/en-us/azure/azure-monitor/logs/data-platform-logs#table-plans
    *Confidence: Verified (MCP 2026-04)* – Analytics, Basic, Auxiliary table plans. Oppdatering 2026-04: Basic-plan støtter nå Simple Log Alerts (✅), ikke kun Analytics-plan. Auxiliary-plan bekrefter ingen workspace replication (data ikke beskyttet mot regional feil) og ingen Customer Lockbox-støtte. Auxiliary-plan støtter Microsoft Sentinel (✅), Search jobs (✅) og Summary rules (✅). Verified (MCP 2026-04)

### Norsk lovverk (Baseline-kunnskap)

- **Arkivloven (1992):** § 6 (bevaring), § 9 (tilgjengelighet)
  *Confidence: Baseline* – Lovtekst krever juridisk tolkning for spesifikke use cases.

- **Sikkerhetsloven (2018):** Krav til logging av sikkerhetshendelser
  *Confidence: Baseline* – NSM-veiledere gir utfyllende detaljer.

### Confidence-nivåer

| Seksjon | Confidence | Kilde |
|---------|------------|-------|
| Sampling-strategier | **Verified** | Microsoft Learn MCP (apr 2026) |
| Prismodell | **Verified** | Microsoft Learn MCP (apr 2026) |
| Table plans | **Verified** | Microsoft Learn MCP (apr 2026) |
| Retention policies | **Verified** | Microsoft Learn MCP (apr 2026) |
| Arkitektuurmønstre | **Baseline** | Kombinasjon av verified docs + modellkunnskap |
| Norsk compliance | **Baseline** | Lovtekst + modellkunnskap (krever juridisk validering) |
| Kostnadseksempler (NOK) | **Baseline** | Estimater basert på Azure pricing calculator (feb 2026) |