ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-security/references/cost-optimization/observability-cost-reduction.md

Observability and Monitoring Cost Optimization

Last updated: 2026-05 | Verified: MCP 2026-05 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) — 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
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):

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):

{
  "sampling": {
    "requestsPerSecond": 1.5
  }
}

Eksempel (Sampling overrides for health checks):

{
  "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):

// 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).

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:

   Usage
   | where TimeGenerated > ago(30d)
   | summarize IngestedGB = sum(Quantity) / 1000 by DataType
   | order by IngestedGB desc
   

3. Identifiser sampling-muligheter:

   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)