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>
2026-04-08 08:58:35 +02:00 · 2026-04-08 08:58:35 +02:00 · baa2d0220b
commit baa2d0220b
488 changed files with 213221 additions and 0 deletions
--- a/skills/ms-ai-security/references/cost-optimization/observability-cost-reduction.md
+++ b/skills/ms-ai-security/references/cost-optimization/observability-cost-reduction.md
@ -0,0 +1,464 @@
+# Observability and Monitoring Cost Optimization
+
+**Last updated:** 2026-02
+**Status:** GA
+**Category:** Cost Optimization & FinOps for AI
+
+---
+
+## 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) | ASP.NET, ASP.NET Core, Azure Functions | Reduserer volum uten konfigurasjon, kan miste sjeldne events |
+| **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.
+
+## 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.4+, 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 | Støttes ikke | Støttes ikke |
+| **Retention** | 30-730 dager | 8 dager interactive + long-term | Long-term kun |
+| **Pris (ingestion)** | Standard | ~50% lavere | ~75% lavere |
+
+**Beslutningstre:**
+1. **Trenger du real-time alerting?** → Analytics
+2. **Queries kun ved feilsøking?** → Basic
+3. **Kun compliance-arkivering?** → Auxiliary
+
+### 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).
+
+### Azure AI 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-02)
+
+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* – Analytics, Basic, Auxiliary table plans.
+
+### 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 (feb 2026) |
+| Prismodell | **Verified** | Microsoft Learn MCP (feb 2026) |
+| Table plans | **Verified** | Microsoft Learn MCP (feb 2026) |
+| Retention policies | **Verified** | Microsoft Learn MCP (feb 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) |