Observability-utgiftene vokser raskere enn infrastrukturen de overvåker. Team leverer dashbord ingen leser, varsler ingen stoler på, og fakturaer som får CFO-en til å stille ubehagelige spørsmål. Det finnes en bedre arkitektur -- og den begynner med å innrømme at det meste du samler inn er avfall.

Vi drifter 22 produksjonssystemer. Den samlede observability-regningen vår er lavere enn en enkelt utviklers månedlige kaffebudsjett. Ikke fordi vi er uansvarlige. Fordi vi er bevisste. Denne artikkelen forklarer hvordan vi kom dit, og hvorfor du kanskje bør gjøre det samme.

I. Fakturaen ingen forventet

En gang rundt 2023 dukket et mønster opp på tvers av konsulentoppdragene våre. Team som hadde brukt år på å optimalisere skyberegning -- riktig dimensjonering av instanser, overgang til ARM, innføring av serverless -- åpnet månedsregningen og fant en ny linjepost som stille spiste opp besparelsene deres.

Datadog. New Relic. Splunk. Elastic Cloud. Dynatrace.

Observability-leverandøren hadde blitt den nest eller tredje største linjeposten. I noen tilfeller den største. En fintech-klient med 40 mikrotjenester på AWS brukte $8 200/mnd på EKS og Fargate. Datadog-regningen var $14 600/mnd. Verktøyet som overvåket infrastrukturen kostet 78 % mer enn selve infrastrukturen.

Dette er ikke et avvik. Dette er markedet.

Datadogs årlige omsetning passerte $2,1 milliarder i 2024. New Relic, Splunk (nå Cisco), Elastic og Dynatrace representerer samlet et marked på over $40 milliarder. De pengene kommer fra et sted. De kommer fra deg.

Spørsmålet er ikke om observability betyr noe. Det gjør det. Spørsmålet er om observability-arkitekturen din er proporsjonal med beslutningene den muliggjør. For de fleste team er svaret nei.

II. Prisfellen: Slik trekker leverandørene ut verdi

Å forstå kostnadene krever at man forstår prismodellene. De er ikke designet for transparens. De er designet for innlåsing og overraskelser.

Per-vert-prising. Datadog tar betalt per vert per måned. Infrastrukturovervåking starter rundt $15/vert/mnd, men APM dytter det til $31-40/vert. En Kubernetes-klynge med 100 noder er $3 100-4 000/mnd før du aktiverer en eneste tilpasset metrikk.

Per-GB-inntak. Logghåndtering tar betalt etter volum. Datadog tar omtrent $0,10/GB for første nivå, med lagringskostnader på toppen. En moderat snakkesalig applikasjon som produserer 500 GB/mnd med logger er $50/mnd bare for inntak -- før indeksering, varsling eller lagring.

Per-tilpasset-metrikk. Det er her budsjettene dør. Datadogs basisplan inkluderer 100 tilpassede metrikker. Hver ekstra tilpasset metrikk koster omtrent $0,05/mnd. Det høres billig ut til en utvikler instrumenterer en tjeneste med Prometheus og ved et uhell oppretter 50 000 tilpassede metrikker fra høy-kardinalitetsetiketter. Det er $2 500/mnd fra en enkelt utrulling.

Per-span-prising for sporing. Å ta inn 1 milliard spans/mnd til $0,0000002/span høres ikke dyrt ut. Til du innser at en enkelt API-forespørsel gjennom 8 mikrotjenester produserer 8+ spans, og ved 10 000 forespørsler/sekund genererer du 6,9 milliarder spans/mnd. Regnestykket blir reelt fort.

Cost model for a mid-size SaaS (100 hosts, 50 services):


Infrastructure monitoring:  100 hosts x $23/mo  = $ 2,300
  APM (50 services):          50 hosts  x $40/mo  = $ 2,000
  Log management (2TB/mo):    2,000 GB  x $0.10   = $   200
  Log indexing + retention:                        = $ 1,800
  Custom metrics (15,000):    15,000    x $0.05   = $   750
  Trace ingestion (5B spans): 5B x $0.0000002     = $ 1,000
  Synthetics (500 tests):     500       x $12/mo  = $ 6,000
  RUM (1M sessions):                               = $ 1,500
  ─────────────────────────────────────────────────────────
  Monthly total:                                   ~$15,550
  Annual total:                                    ~$186,600

Det tilsvarer to seniorutviklere. Eller hele skyregningen for et velarktitekturert system i samme skala. Og det vokser med hver vert du legger til, hver metrikk du oppretter, hver logglinje du sender ut.

III. Fryktdrevet overvåking og dashbord-gravlunden

Kostnaden ville vært forsvarlig hvis hver krone drev en beslutning. Det gjør den ikke.

De fleste observability-oppsett er produkter av frykt. En hendelse inntreffer. Noen sier "vi trenger mer innsyn." Et dashbord bygges. Et varsel opprettes. Ingen sletter dashbordet seks måneder senere når det underliggende problemet er fikset. Ingen gjennomgår om varselet noensinne ble utløst. Overvåkingsoverflaten vokser monotont.

Vi har et navn for dette: dashbord-gravlunden. Enhver organisasjon har en. Rader av Grafana-paneler ingen har åpnet på måneder. Datadog-dashbord laget av utviklere som forlot selskapet for to år siden. PagerDuty-tjenester med varslingsregler som refererer til infrastruktur som ikke lenger eksisterer.

Kostnaden er ikke bare finansiell. Varseltretthet er reell og målbar.

En studie fra 2023 av PagerDutys eget forskerteam fant at den typiske vakthavende utvikleren mottar 25+ varsler per vakt. Av disse er færre enn 3 handlingsbare. Resten er støy -- terskelbrudd på metrikker som ikke korrelerer med brukereffekt, forbigående topper som løser seg selv, og kaskaderende varsler fra en enkelt rotårsak.

90/10-regelen: 90 % av varslene er støy. 10 % er handlingsbare. Og støyen gjør signalet vanskeligere å finne.

Alert taxonomy (based on audit of 4 client systems, 2024-2025):


Actionable + urgent:      8%   -- Real incidents, need human response
  Actionable + deferred:    4%   -- Real issues, can wait for business hours
  Informational:           22%   -- Interesting but requires no action
  Noise (self-resolving):  41%   -- Transient spikes, auto-scaling events
  Stale (dead references): 25%   -- Alerts on decommissioned services

Hvis en fjerdedel av varslene refererer til infrastruktur som ikke lenger eksisterer, gir ikke observability-oppsettet ditt innsyn. Det gir teater.

IV. Cargokult-instrumenteringsproblemet

Det finnes et mønster i hvordan team adopterer observability som speiler hvordan de adopterer testing: de starter med gode intensjoner og ender med dekningsmetrikker som måler innsats, ikke verdi.

Cargokulten fungerer slik:

  1. Les et blogginnlegg om hvordan Uber instrumenterer mikrotjenestene sine.
  2. Installer Datadog-agenten på alt.
  3. Aktiver APM på hver tjeneste.
  4. Legg til tilpassede metrikker for hver teller, måler og histogram du kan tenke deg.
  5. Bygg dashbord som ser imponerende ut i sprintdemoer.
  6. Slett aldri noe.

Resultatet er omfattende instrumentering av et system du ikke forstår noe bedre enn du gjorde før. Du har mer data. Du har ikke mer innsikt.

Forskjellen betyr noe. Data er det systemene dine sender ut. Innsikt er det som endrer atferden din. En metrikk ingen ser på er ikke observability. Det er en post i leverandørreskontro.

Vurder alternativet: i stedet for å instrumentere alt og håpe at mønstre dukker opp, starter du med å spørre hvilke beslutninger du trenger å ta og jobber bakover til minimumsdataene som kreves for å ta dem.

Beslutning: Er API-et friskt sett fra brukerens perspektiv? Minimumsdata: Forespørsels-latens P50/P95/P99, feilrate og tilgjengelighet -- tre metrikker per endepunkt.

Beslutning: Nærmer databasen seg kapasitetsgrensene? Minimumsdata: Tilkoblingspoolbruk, spørringslatens P95, diskbruk i prosent -- tre metrikker.

Beslutning: Forårsaket siste utrulling en regresjon? Minimumsdata: Feilrate-delta og latens-delta sammenlignet med forrige 24-timersvindu -- to metrikker.

Du trenger ikke 15 000 tilpassede metrikker for å besvare disse spørsmålene. Du trenger færre enn 100.

V. OpenTelemetry-standarden: Din exit-strategi

OpenTelemetry er det viktigste infrastrukturprosjektet de fleste team ignorerer. Det er et leverandørnøytralt, åpen kildekode-rammeverk for observability som standardiserer hvordan telemetridata -- spor, metrikker og logger -- samles inn, prosesseres og eksporteres.

Hvorfor det betyr noe: det kobler instrumentering fra destinasjon. Du instrumenterer koden din en gang med OpenTelemetry SDK-er, og kan sende dataene til hvilken som helst backend. Datadog i dag, Grafana Cloud i morgen, selvhostet ClickHouse neste kvartal. Ingen re-instrumentering. Ingen leverandørlåsing.

OpenTelemetry Collector er den arkitektoniske bærebjelken. Den sitter mellom applikasjonene dine og backendene dine, og håndterer innsamling, prosessering, filtrering og ruting.

# otel-collector-config.yaml


receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318



processors:
  batch:
    timeout: 5s
    send_batch_size: 8192



# Drop metrics you don't need before they hit storage
  filter/metrics:
    metrics:
      exclude:
        match_type: regexp
        metric_names:
          - "http.server.request.body.size"
          - "runtime.cpython.*"
          - "process.runtime.*"



# Sample traces intelligently -- keep errors, sample successes
  tail_sampling:
    decision_wait: 10s
    policies:
      - name: errors-always
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: slow-requests
        type: latency
        latency: { threshold_ms: 2000 }
      - name: sample-normal
        type: probabilistic
        probabilistic: { sampling_percentage: 5 }



# Add deployment context to every signal
  resource:
    attributes:
      - key: deployment.environment
        value: production
        action: upsert
      - key: service.version
        from_attribute: DEPLOY_SHA
        action: upsert



exporters:
  otlp/tempo:
    endpoint: tempo.internal:4317
    tls:
      insecure: false
  prometheusremotewrite:
    endpoint: http://mimir.internal/api/v1/push
  loki:
    endpoint: http://loki.internal/loki/api/v1/push



service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [tail_sampling, resource, batch]
      exporters: [otlp/tempo]
    metrics:
      receivers: [otlp]
      processors: [filter/metrics, resource, batch]
      exporters: [prometheusremotewrite]
    logs:
      receivers: [otlp]
      processors: [resource, batch]
      exporters: [loki]

Nøkkelinnsikten ligger i processors-seksjonen. Før en eneste byte treffer lagringsbackenden din, filtrerer collectoren ut metrikker du ikke trenger, sampler spor intelligent (beholder feil og trege forespørsler mens rutinetrafikk samples med 5 %), og beriker alt med utrullingskontekst.

Det filtreringssteget er der du gjenvinner 60-80 % av observability-budsjettet.

VI. Strukturert logging som faktisk fungerer

Mesteparten av logging er narrativ. En utvikler skriver logger.info("Processing order for customer") og går videre. Den logglinjen er lesbar for mennesker og ubrukelig for maskiner. Du kan ikke aggregere den, filtrere den eller varsle på den uten regex-gymnastikk.

Strukturert logging snur dette på hodet. Hver loggoppføring er en typet hendelse med navngitte felt. Narrativet er fortsatt der -- i message-feltet -- men de handlingsbare dataene lever i strukturerte attributter.

// Bad: narrative logging
logger.info(Processing order ${orderId} for customer ${customerId});
logger.error(Payment failed for order ${orderId}: ${error.message});


// Good: structured logging with OpenTelemetry semantic conventions
logger.info("order.processing", {
  order_id: orderId,
  customer_id: customerId,
  currency: order.currency,
  amount_cents: order.totalCents,
  items_count: order.items.length,
});



logger.error("payment.failed", {
  order_id: orderId,
  customer_id: customerId,
  payment_provider: "stripe",
  error_code: error.code,
  error_category: categorizePaymentError(error),
  retry_eligible: isRetryable(error),
  attempt_number: attemptCount,
});

Den strukturerte versjonen koster det samme å sende ut, men er uendelig mye mer nyttig nedstrøms. Du kan spørre etter alle mislykkede betalinger per leverandør. Du kan beregne feilrater for gjenforsøksbare feil. Du kan bygge varsler på error_category i stedet for å regex-matche feilmeldinger som endres med hver refaktorering.

En loggnivå-taksonomi som betyr noe

De fleste team behandler loggnivåer som stemning. Her er en taksonomi som knytter hvert nivå til en operasjonell respons:

Nivå Betydning Operasjonell respons Oppbevaring
FATAL Prosessen kan ikke fortsette. Data kan være i fare. Umiddelbar varsling. Alle mann. For alltid
ERROR Operasjonen feilet. Brukereffekt bekreftet. Varsle vakthavende. Undersøk innen SLO. 90 dager
WARN Degradert men funksjonell. Nærmer seg en grense. Opprett sak. Gjennomgå neste arbeidsdag. 30 dager
INFO Normale driftsmilepæler. Tilstandsoverganger. Ingen handling. Tilgjengelig for undersøkelse. 14 dager
DEBUG Detaljert flyt for aktiv feilsøking. Ingen handling. Aktiver ved behov. 3 dager

Oppbevaringskolonnen er kostnadsspaken. Hvis DEBUG-logger utgjør 60 % av volumet og du oppbevarer dem i 3 dager i stedet for 30, har du nettopp kuttet lagringskostnadene med 54 %. Hvis du deaktiverer DEBUG i produksjon helt og aktiverer det per tjeneste ved feilsøking, er besparelsene enda større.

VII. Edge-telemetri: Den billigste observability du ikke bruker

Hvis du deployer til Cloudflare Workers, Vercel Edge Functions eller et hvilket som helst CDN med analysekapasitet, har du allerede et telemetrilag de fleste team ignorerer.

Cloudflare Workers Analytics Engine gir per-forespørsel-metrikker ved kanten -- latens, statuskoder, cache-treffrate, geografisk distribusjon -- uten ekstra kostnad utover Workers-planen din. Ingen agent å installere. Ingen SDK å integrere. Ingen per-metrikk-prising.

// Cloudflare Worker: lightweight telemetry at the edge
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const start = Date.now();
    const url = new URL(request.url);


try {
      const response = await handleRequest(request, env);
      const duration = Date.now() - start;



// Write to Analytics Engine -- included in Workers plan
      env.TELEMETRY.writeDataPoint({
        blobs: [
          url.pathname,                    // index 1: route
          response.status.toString(),      // index 2: status
          request.headers.get("cf-ipcountry") || "XX", // index 3: country
        ],
        doubles: [
          duration,                        // index 1: latency_ms
          response.headers.get("content-length")
            ? parseInt(response.headers.get("content-length")!)
            : 0,                           // index 2: response_bytes
        ],
        indexes: [url.pathname],           // queryable index
      });



return response;
    } catch (err) {
      env.TELEMETRY.writeDataPoint({
        blobs: [url.pathname, "500", "error"],
        doubles: [Date.now() - start, 0],
        indexes: [url.pathname],
      });
      throw err;
    }
  },
};

Du kan spørre disse dataene med SQL gjennom Cloudflare API eller GraphQL. P50/P95-latens per rute, feilrater per land, trafikkmønstre per time. Dataene du trenger for 80 % av operasjonelle beslutninger, samlet inn på punktet nærmest brukeren, til null marginalkostnad.

Dette er observability-inversjonen: i stedet for å trekke metrikker fra innsiden av systemet utover, fanger du dem ved grensen der brukerne faktisk opplever tjenesten din.

VIII. Arkitekturen: Billig lagring, smarte spørringer

De kommersielle observability-plattformene bundler tre ting: innsamling, lagring og spørring. De tar premiumpris fordi pakken er bekvem. Men hver komponent har et commodity-alternativ som koster 5-20 ganger mindre.

The Observability Tax architecture vs. the alternative:


VENDOR BUNDLE                    UNBUNDLED ARCHITECTURE
  ┌──────────────────────┐         ┌─────────────────────────────────┐
  │  App + Agent          │         │  App + OTel SDK                  │
  │       │               │         │       │                          │
  │       v               │         │       v                          │
  │  Vendor Collector     │         │  OTel Collector (self-hosted)    │
  │       │               │         │       │         │         │      │
  │       v               │         │       v         v         v      │
  │  Vendor Storage       │         │   ClickHouse  S3/R2    Loki     │
  │  ($$$$/GB)            │         │   (metrics+   (cold    (logs)   │
  │       │               │         │    traces)    archive)          │
  │       v               │         │       │         │         │      │
  │  Vendor UI            │         │       └────┬────┘─────────┘      │
  │  (included)           │         │            v                     │
  │                       │         │        Grafana                   │
  │  Cost: ~$15K/mo       │         │        (dashboards + alerts)     │
  │                       │         │                                  │
  │                       │         │  Cost: ~$1.5K-3K/mo             │
  └──────────────────────┘         └─────────────────────────────────┘

Komponentene:

ClickHouse for metrikk- og sporlagring. Kolonneorientert, komprimeringsrater på 10-20x for strukturert telemetri, spørringsytelse som matcher dedikerte TSDB-systemer. ClickHouse Cloud-priser starter rundt $0,03/GB for komprimert lagring -- omtrent 10-30 ganger billigere enn kommersiell APM-lagring når komprimering tas med i beregningen.

S3/R2/GCS for kaldarkiv. Etter 7-14 dager flyttes rå telemetri til objektlagring. Cloudflare R2 tar $0,015/GB/mnd uten utgående trafikk-kostnader. Spør ved behov med Athena, DuckDB eller ClickHouse-eksterne tabeller.

Grafana for visualisering og varsling. Grafana i seg selv er åpen kildekode. Grafana Clouds gratistier håndterer 10 000 metrikker, 50 GB logger og 50 GB spor per måned. Det betalte nivået starter på omtrent $0,50/1 000 metrikkserier -- fortsatt en brøkdel av kommersiell APM-prising.

Loki for loggaggregering. Designet av Grafana-teamet som en "Prometheus for logger." Indekserer ikke logginnhold -- bare etiketter. Dette gjør det dramatisk billigere å drifte enn Elasticsearch/Splunk for logglagring.

En reell kostnadssammenligning

For den samme mellomstore SaaS-en fra del II (100 verter, 50 tjenester):

Commercial APM (Datadog-class):     ~$186,600/year


Unbundled architecture:
    ClickHouse Cloud (metrics+traces):  $  7,200/year
    R2 cold storage (24 months):        $  2,160/year
    Grafana Cloud (Pro):                $  6,000/year
    Loki (self-hosted on 2 nodes):      $  3,600/year
    OTel Collector (3 nodes):           $  2,400/year
  ──────────────────────────────────────────────────
    Total:                              ~ $21,360/year



Annual savings:                       ~$165,240
  Savings percentage:                   ~89%

Avveiningen er operasjonell kompleksitet. Du drifter collectoren. Du forvalter ClickHouse (eller betaler for ClickHouse Cloud). Du konfigurerer Grafana-dashbord. Dette krever et team som forstår komponentene. Det er ikke null innsats.

Men det er ærlig innsats. Du betaler for utviklertid i stedet for leverandørmargin. Og utviklerne som drifter denne stakken forstår observability-oppsettet sitt dypt -- fordi de bygde det. Den forståelsen er verdt mer enn noe leverandørdashbord.

IX. Når kommersielle plattformer er riktig svar

Denne artikkelen er ikke et polemisk innlegg mot kommersiell observability. Det finnes genuine tilfeller der det er rasjonelt å betale skatten:

Oppstartsbedrifter i tidlig fase uten driftskapasitet. Har du 5 utviklere og ingen dedikert driftsperson, sparer Datadogs installer-og-kjør-modell tid du ikke har råd til å bruke. Kostnaden er reell, men tidskostnaden ved selvhosting er høyere. Revurder når dere passerer 50 utviklere eller $10 000/mnd i observability-utgifter.

Genuint komplekse distribuerte systemer. Kjører du 200+ mikrotjenester på tvers av flere skyer med polyglotte kjøretider, gir korrelasjons-motoren i Datadog eller New Relic verdi som er vanskelig å replikere med åpen kildekode-verktøy. Tjenestekartet, den automatiske sporings-korrelasjonen, anomalideteksjonen -- disse funksjonene rettferdiggjør en premie når alternativet er et team på tre som bruker hele kvartalet på å bygge ekvivalenter.

Komplianse-miljøer med revisjonskrav. Noen regulerte bransjer krever spesifikke oppbevaringspolicyer, tilgangskontroller og revisjonslogger som kommersielle plattformer leverer ut av boksen. Å bygge SOC 2-kompatibel logg-infrastruktur fra bunnen av er mulig, men dyrt i en annen valuta.

Team som ikke har interesse av å bli observability-eksperter. Dette er gyldig. Ikke alle team bør bygge sin egen overvåkingsstakk. Hvis observability ikke er en kjernekompetanse og du heller vil bruke utviklertid på produktfunksjoner, er leverandørskatten en rimelig avveining. Bare vit at du betaler den.

Testen er enkel: del de årlige observability-utgiftene på antall hendelser det hjalp deg med å løse. Hvis kostnaden per hendelse overstiger kostnaden av selve hendelsen, er du overinstrumentert.

X. Gothars tilnærming: 22 systemer, minimal skatt

Vi praktiserer det vi prediker. Slik overvåker vi 22 produksjonssystemer på tvers av Cloudflare Workers, AWS og bare-metal-infrastruktur:

Lag 1: Edge-telemetri. Hver Cloudflare Worker skriver til Analytics Engine. Rutenivå-latens, statuskoder, cache-ytelse. Null marginalkostnad. Dette dekker 70 % av "er systemet friskt?"-spørsmålene våre.

Lag 2: Strukturert logging med kontekstpropagering. Hver tjeneste sender strukturerte JSON-logger med spor-ID-er, forespørsels-ID-er og deployment-SHA-er. Logger sendes til Loki via OTel Collector. Oppbevaring: 14 dager varmt, 90 dager kaldt på R2.

Lag 3: Fire gylne signaler per tjeneste. Latens (P50/P95/P99), trafikk (forespørsler/sek), feil (rate) og metning (ressursutnyttelse). Eksportert som Prometheus-metrikker via OTel SDK. Lagret i en lettvekts Mimir-instans. Ingen tilpassede metrikker utover disse fire kategoriene.

Lag 4: Sporing ved behov. Vi sporer ikke hver forespørsel. Vi sporer feil, trege forespørsler (>2s) og et 5 %-utvalg av normal trafikk. Lagret i Tempo. Spurt gjennom Grafana ved undersøkelse av spesifikke hendelser.

Lag 5: Syntetiske kanarifugler. Enkle HTTP-sjekker mot kritiske endepunkter, hvert 60. sekund, fra tre geografiske regioner. Cloudflare Health Checks pluss en håndfull tilpassede Workers. Varsler går til en enkelt Slack-kanal med vaktrotasjon.

Totale observability-utgifter for 22 systemer: omtrent $340/mnd. Det er ikke en skrivefeil. Edge-telemetri er gratis. Loki, Mimir og Tempo kjører på to beskjedne VM-er ($85/mnd hver). R2-lagring er ubetydelig. Grafana Clouds gratistier dekker dashbord- og varslingsbehovene våre.

Begrensningen som gjør dette mulig: vi bestemte hvilke spørsmål vi trenger å besvare før vi bestemte hva vi skulle samle inn. Disiplin i designfasen eliminerer sløsing i faktureringsfasen.

XI. Den praktiske migreringsveien

Hvis du i dag betaler observability-skatten og vil redusere den, ikke riv og erstatt. Migrer inkrementelt:

Måned 1: Revisjon. Kartlegg hvert dashbord, varsel og metrikk. For hvert element, svar: når ble dette sist sett på? Drev det en beslutning? Slett alt som feiler begge testene. De fleste team kan eliminere 40-60 % av observability-overflaten i dette steget alene, uten risiko.

Måned 2: Instrumenter med OpenTelemetry. Legg til OTel SDK ved siden av den eksisterende leverandøragenten. Dobbeltlever telemetri til både nåværende leverandør og en selvhostet collector. Dette gir et sammenligningsgrunnlag uten nedetid.

Måned 3: Sett opp billig lagring. Deploy ClickHouse Cloud eller en selvhostet instans, Loki for logger og Grafana for dashbord. Rut OTel Collector-utdataene til begge backendene. Verifiser at den selvhostede stakken besvarer de samme spørsmålene som den kommersielle plattformen.

Måned 4: Overgang. Deaktiver leverandøragenten på ikke-kritiske tjenester først. Overvåk for hull. Utvid til alle tjenester over 2-4 uker. Behold leverandørkontrakten aktiv i en måned til som forsikring.

Måned 5: Optimaliser. Nå som du kontrollerer pipelinen, implementer aggressiv filtrering og sampling i OTel Collector. Fjern metrikker ingen spør etter. Sampl rutinespor. Forkort oppbevaring på debug-logger. Det er her kostnadsreduksjonen på 80-90 % materialiserer seg.

XII. Hva observability bør være

Observability eksisterer for å informere beslutninger. Ikke for å gi trygghet. Ikke for å generere dashbord. Ikke for å fylle en SOC 2-avkrysningsboks. For å informere beslutninger.

Hver metrikk bør ha en eier og en responsplan. Hvert varsel bør ha en runbook. Hvert dashbord bør besvare et spørsmål noen faktisk stiller. Alt annet er kostnad uten verdi.

Den antikke greske legen Hippokrates krediteres prinsippet: "Først, gjør ingen skade." Observability-ekvivalenten er: først, ikke sløs. Ikke samle inn data du ikke vil spørre etter. Ikke varsle på tilstander du ikke vil handle på. Ikke oppbevar logger utover vinduet der de er nyttige.

Det finnes en dypere parallell her. I Marcus Aurelius' Meditasjoner vender han gjentatte ganger tilbake til ideen om å skille mellom det som er i din kontroll og det som ikke er det. Den stoiske disiplinen er å fokusere oppmerksomhet og energi utelukkende på det førstnevnte. Observability, praktisert godt, er en stoisk disiplin. Du kan ikke forhindre hver hendelse. Du kan kontrollere hva du måler, hva du varsler på, og hvordan du responderer. Resten er støy -- og støy, i observability som i filosofi, er fienden til klarhet.

Det beste overvåkingssystemet er det du forstår fullstendig, som koster proporsjonalt med verdien det gir, og som du kunne bygge opp igjen fra bunnen av på en uke. Hvis observability-leverandøren din forsvant i morgen, ville du være fortapt -- eller frigjort?

Det spørsmålet fortjener et ærlig svar.

Referanser

  1. Datadog, Inc. "Pricing." datadoghq.com/pricing
  2. OpenTelemetry Project. "OpenTelemetry Collector Documentation." opentelemetry.io/docs/collector
  3. ClickHouse, Inc. "ClickHouse Cloud Pricing." clickhouse.com/pricing
  4. Grafana Labs. "Grafana Loki Documentation." grafana.com/docs/loki
  5. Cloudflare. "Workers Analytics Engine." developers.cloudflare.com/analytics/analytics-engine
  6. Charity Majors, Liz Fong-Jones, George Miranda. Observability Engineering. O'Reilly Media, 2022.
  7. Google SRE Team. "Monitoring Distributed Systems." sre.google/sre-book/monitoring-distributed-systems
  8. Cindy Sridharan. Distributed Systems Observability. O'Reilly Media, 2018.
  9. PagerDuty. "State of Digital Operations Report 2023." pagerduty.com/resources
  10. Cloudflare. "R2 Pricing." developers.cloudflare.com/r2/pricing
  11. Grafana Labs. "Grafana Tempo Documentation." grafana.com/docs/tempo
  12. New Relic, Inc. "New Relic Pricing." newrelic.com/pricing