Optimalizácia nákladov na observabilitu: Ako znížiť účet za CloudWatch, Datadog a logy v roku 2026

Praktický sprievodca, ako znížiť účet za CloudWatch, Datadog a logy o 40-70 % cez sampling, tiering, kontrolu kardinality a OpenTelemetry Collector.

Zníž účet CloudWatch a Datadog 2026

Aktualizované: 22. júna 2026

Optimalizácia nákladov na observabilitu je proces zníženia výdavkov na zber, ukladanie a analýzu logov, metrík a tracingov bez straty viditeľnosti, typicky úsporou 40–70 % cez samplovanie, filtrovanie, tiering úložiska a kontrolu kardinality metrík. V roku 2026 prerástli faktúry za CloudWatch Logs a Datadog v mnohých tímoch náklady na samotnú compute infraštruktúru a observabilita sa stala druhou najväčšou položkou cloudového rozpočtu. Honestly, v poslednom projekte som videl tím, ktorý platil viac za logy než za samotné Kubernetes nody. Tento sprievodca ukazuje konkrétne techniky, konfigurácie a kód, ktorými môžete účet znížiť okamžite.

  • CloudWatch Logs účtuje 0,50 USD za GB ingescie a 0,03 USD za GB mesačne za úložisko. Ingescia je 16× drahšia než úložisko, preto filtrujte už na zdroji.
  • Datadog faktúruje hostov, custom metriky (po 100 na host) a indexované logy zvlášť. Kardinalita custom metrík je najčastejšou príčinou neočakávaných nárastov faktúry.
  • Tail-based sampling tracingov pri 1–5 % zachová 100 % chybových span-ov a zníži náklady o 90 % oproti head-based samplingu.
  • Presmerovaním logov do S3 + Athena namiesto CloudWatch Logs Insights znížite cenu dotazu z 0,005 USD/GB skenovania na 0,005 USD/GB pri rádovo lacnejšom úložisku.
  • OpenTelemetry Collector s processormi filter, tail_sampling a transform umožňuje vendor-neutral kontrolu nákladov pred odoslaním dát.
  • Štandardná stratégia retencie 7-30-90: 7 dní hot v Datadogu, 30 dní v CloudWatch, 90+ dní v S3 Glacier.

Prečo je CloudWatch taký drahý?

Najčastejšia príčina šokujúcej faktúry za CloudWatch sú náklady na ingesciu logov, nie úložisko. Aktuálny cenník AWS CloudWatch (2026) účtuje 0,50 USD za GB ingestovaných logov v regióne us-east-1 a iba 0,03 USD za GB mesačne za uložené dáta. To znamená, že prvý mesiac platíte za GB logov 17,7× viac za ingesciu než za uloženie. Ak vaša aplikácia produkuje 1 TB logov denne, ide o 15 000 USD mesačne len za ingesciu, a to ešte predtým, než spustíte čo i len jeden CloudWatch Logs Insights dotaz (0,005 USD za GB skenovaných dát).

Druhým skrytým faktorom sú custom a vysoko-rozlíšené metriky: 0,30 USD mesačne za prvých 10 000 custom metrík a štandardná metrika má 1-minútovú granularitu zadarmo, no high-resolution metrika s 1-sekundovou granularitou stojí výrazne viac. Tretím faktorom je CloudWatch Logs Insights. Používatelia spúšťajú ad-hoc dotazy nad celými log groupmi a každý dotaz skenuje desiatky GB. Štvrtým je data egress pri exporte logov do iného účtu alebo regiónu. Pochopenie týchto štyroch položiek je prvý krok k optimalizácii a presne sa odráža v stratégii na zníženie nákladov na sieťový prenos, ktorá rieši rovnaké pasce v iných službách.

Anatómia účtu za observabilitu v roku 2026

Predtým než začnete škrtať, musíte vedieť, kde peniaze tečú. Typický mid-size SaaS tím s 200 hostmi má v roku 2026 takúto štruktúru observability nákladov: 40 % logy (ingescia + indexácia), 25 % custom metriky (kardinalita), 20 % APM/tracingy, 10 % syntetické monitoring a uptime, 5 % dashboardy a alerting. Toto rozloženie sa za posledné dva roky výrazne posunulo. Podiel custom metrík vzrástol kvôli nárastu Kubernetes labelov a tagovacích stratégií, ktoré doslova vystrelili kardinalitu.

PoložkaCloudWatch (AWS native)Datadog (SaaS)Self-hosted (Grafana/Loki)
Cena za GB logov (ingescia)0,50 USD0,10 USD + 1,70 USD indexácia~0,02 USD (S3 + compute)
Cena za host APMX-Ray: 5 USD / mil. traces31–40 USD / host / mesiacTempo + infra: ~3–5 USD / host
Custom metriky0,30 USD / metrika / mesiac5 USD / 100 metrík / hostZadarmo (cardinality limit)
Retencia (default)Nekonečná, manuálne15 dní indexovanéKonfigurovateľná
Vendor lock-inVysokýVysokýNízky (OTLP)
Prevádzková réžiaŽiadnaŽiadna1–2 FTE

Rozhodnutie medzi týmito tromi modelmi nie je čierno-biele. Väčšina tímov v roku 2026 prevádzkuje hybrid: Datadog pre kritické produkčné služby (APM, real-time alerting), CloudWatch pre AWS-native služby (Lambda, RDS) a self-hosted Loki/Tempo pre dev a staging prostredia. Je to ten istý princíp, ktorý uplatňujeme pri optimalizácii nákladov na Kubernetes, teda segmentovať záťaž podľa kritickosti a tomu priradiť cenovú úroveň.

Ako znížiť náklady na CloudWatch Logs

Existuje päť konkrétnych pák, ktorými okamžite znížite CloudWatch faktúru. Začnite v poradí najväčšieho dopadu.

1. Filtrujte logy na zdroji

Drvivá väčšina logov sú DEBUG a INFO správy, ktoré v produkcii nikdy nečítate. Ak používate Lambda, nastavte log level cez environment variable a v kóde filtrujte ešte pred odoslaním:

import logging
import os

logger = logging.getLogger()
logger.setLevel(os.environ.get("LOG_LEVEL", "WARNING"))

def handler(event, context):
    logger.debug("Vstupny event: %s", event)
    logger.warning("Zlyhanie validacie: %s", event.get("id"))
    return {"statusCode": 200}

U mnohých klientov samotná zmena z INFO na WARNING znížila ingesciu o 60–75 %. V jednom prípade som tento jediný flip nasadil v piatok večer a v pondelok ráno mal CFO otázku, či sa nám nepokazil logging (nepokazil, len konečne dával zmysel).

2. Nastavte retenciu na každej Log Group

Defaultná retencia CloudWatch je nekonečná, čo znamená, že stále platíte za logy spred rokov, ktoré nikdy nepoužijete. Cez Terraform nastavte explicitne:

resource "aws_cloudwatch_log_group" "app" {
  name              = "/aws/lambda/payment-service"
  retention_in_days = 30
}

Pre staré log groupy spustite jednorazový script, ktorý nastaví retenciu na všetkých existujúcich groupoch bez nastavenej politiky.

3. Exportujte do S3 a dotazujte cez Athena

CloudWatch Logs Insights stojí 0,005 USD za GB skenovaných dát, čo je rovnaká cena ako Athena, ale úložisko v S3 Standard-IA stojí 0,0125 USD/GB oproti 0,03 USD/GB v CloudWatch. Pre logy staršie než 7 dní nastavte automatický export do S3 cez subscription filter s Kinesis Data Firehose ako destination.

4. Vypnite vector tagging na metrikách, ktoré nepotrebujete

Container Insights generuje automaticky podrobné metriky s tagmi PodName, Namespace, ContainerName. Ak máte 50 namespacov × 200 podov × 10 metrík, ide o 100 000 unikátnych časových radov mesačne, čo je okolo 30 000 USD. Vypnite enhanced container insights tam, kde nie sú potrebné, alebo zúžte scope na produkčné namespacy.

5. Použite subscription filters na samplovanie

Pre vysoko-objemové access logy posielajte cez Kinesis Data Firehose iba 10 % do indexovania a 100 % do S3 archívu. Tento vzor sa nazýva dual-pipeline a zachováva forenznú schopnosť bez ceny indexácie. Pri 1 TB denne ide o úsporu okolo 13 500 USD mesačne.

Ako znížiť náklady na Datadog

Datadog je vynikajúci, no jeho pricing model dosť kruto penalizuje neopatrných používateľov. Tri najväčšie kategórie šetrenia v roku 2026 sú indexácia logov, custom metriky a APM hosty. Ak máte mesačnú faktúru nad 20 000 USD, takmer isto je 30–50 % z nej eliminovateľných bez straty viditeľnosti.

Použite Logging without Limits a Index filters

Datadog oddelil ingesciu (lacnú) od indexácie (drahej). Posielajte všetky logy, ale indexujte iba tie, ktoré naozaj potrebujete pre real-time alerting. V Datadog UI vytvorte Index filter typu:

status:(error OR warn) OR @http.status_code:[400 TO 599]

Týmto indexujete iba chybové logy a HTTP 4xx/5xx, typicky 5–10 % objemu, no 95 % skutočnej hodnoty pre incident response. Zvyšok zostane v Online Archives (S3) za zlomok ceny a v prípade potreby ho rehydratujete. Detailný postup popisuje oficiálna dokumentácia Datadog Log Indexes.

Konsolidujte hosty cez tagging

Datadog APM faktúruje za unikátne kombinácie service + env + host. Ak máte 100 mikroservisov s krátkymi container ID, Datadog vidí 100 000 „hostov". Riešenie: nastavte stabilné DD_TAGS a používajte DD_HOSTNAME namiesto container ID. Je to tá istá disciplína, ktorú popisujeme v stratégii cloud taggingu pre alokáciu nákladov.

Vypnite nepoužívané integrácie

Datadog Marketplace má cez 600 integrácií a každá emituje desiatky metrík. Po prvotnom POC zostávajú zapnuté integrácie, ktoré tím už dávno nepoužíva. Mesačný audit v Datadog Usage Attribution UI ukáže top spotrebiteľov a typicky odhalí 5–10 % okamžitej úspory.

Kontrola kardinality metrík

Custom metric s vysokou kardinalitou je #1 zabijak rozpočtu na observabilitu. Ak emitujete metriku http_requests_total s tagmi user_id (10 000 unikátov), endpoint (200), status (5), region (3), kardinalita je 10 000 × 200 × 5 × 3 = 30 000 000 unikátnych časových radov pre jednu metriku. Pri 5 USD za 100 custom metrík/host je to 1 500 000 USD mesačne za jeden tag. Áno, naozaj. Tento bug som videl v reálnej produkcii a stál tím dva mesiace fakturácie.

Pravidlá pre kardinalitu

  • Nikdy nepoužívajte ako tag: user_id, request_id, trace_id, session_id, email, ip_address. Sú to vysoko-kardinálne dimenzie, ktoré patria do logov alebo tracingov, nie metrík.
  • Áno používajte: service, env, region, http_status_class (2xx/3xx/4xx/5xx), endpoint_template (/users/{id} nie /users/12345).
  • Aplikujte cardinality limits v Prometheus / OTel Collector, drop metriky, ktoré prekročia limit.

Príklad limitu v Prometheus konfigu:

scrape_configs:
  - job_name: app
    metric_relabel_configs:
      - source_labels: [__name__]
        regex: http_requests_total
        action: keep
      - source_labels: [user_id]
        action: labeldrop

Sampling tracingov a APM

Distributed tracing je drahý. Každý span obsahuje atribúty, timing a baggage. Pri 1 000 RPS naprieč 20 mikroservisami generujete 20 000 spanov za sekundu, čo je 1,7 miliardy spanov denne. Indexovať 100 % je finančne nemožné, ale head-based sampling (rozhodnutie pri vstupe) zahodí aj kritické chybové trace-y.

Riešenie je tail-based sampling v OpenTelemetry Collectore: rozhodnutie padne až po dokončení celého trace, takže si môžete nechať 100 % chýb, 100 % pomalých dotazov a 1 % normálnej premávky.

processors:
  tail_sampling:
    decision_wait: 30s
    num_traces: 100000
    policies:
      - name: errors
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: slow
        type: latency
        latency: { threshold_ms: 1000 }
      - name: baseline
        type: probabilistic
        probabilistic: { sampling_percentage: 1 }

Tail-based sampling vyžaduje stateful collector (drží spany v pamäti 30 s), takže škálujete cez Kafka partition-key na trace_id. Podrobnosti sú v OpenTelemetry Collector dokumentácii. Tento prístup sa pekne dopĺňa s rovnakou disciplínou, ktorú popisujeme v agentickom FinOps prístupe, kde sampling policy autonómne upravuje AI agent na základe pozorovanej premávky.

OpenTelemetry Collector ako kontrolný bod nákladov

OTel Collector je v roku 2026 de-facto štandard pre vendor-neutral observability pipeline. Jeho najsilnejšou stránkou pre FinOps je možnosť filtrovať, transformovať a vzorkovať dáta pred tým, než opustia vašu sieť. Takže neplatíte ingesciu za logy, ktoré aj tak zahodíte.

Minimálna konfigurácia s filtrovaním a batching:

receivers:
  otlp:
    protocols: { grpc: { endpoint: 0.0.0.0:4317 } }

processors:
  filter/logs:
    logs:
      log_record:
        - severity_number < SEVERITY_NUMBER_WARN
  batch:
    timeout: 5s
    send_batch_size: 10000

exporters:
  datadog:
    api: { key: ${DD_API_KEY} }

service:
  pipelines:
    logs:
      receivers: [otlp]
      processors: [filter/logs, batch]
      exporters: [datadog]

Collector môžete nasadiť ako DaemonSet v Kubernetes alebo ako sidecar. Pre vendor-neutral pipeline odporúčam gateway deployment v dedicated node pool, aby ste obetovali iba 2–3 % infraštruktúry za úsporu desiatok percent SaaS faktúry.

Tiering, retencia a archivácia do S3

Štandardná stratégia retencie pre rok 2026 je 7-30-90-365: 7 dní v Datadog/CloudWatch Insights pre real-time debug, 30 dní v štandardnom úložisku, 90 dní v S3 Standard-IA, 365+ dní v S3 Glacier Deep Archive (1 USD/TB/mesiac).

Pre serverless workloady platí rovnaký vzor. Pozrite si konkrétny návod v sprievodcovi optimalizáciou nákladov na serverless, kde sú Lambda log retention policies kombinované s Firehose archiváciou.

Lifecycle policy pre S3 archív logov

{
  "Rules": [{
    "Id": "archive-logs",
    "Status": "Enabled",
    "Prefix": "logs/",
    "Transitions": [
      { "Days": 30,  "StorageClass": "STANDARD_IA" },
      { "Days": 90,  "StorageClass": "GLACIER_IR" },
      { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
    ],
    "Expiration": { "Days": 2555 }
  }]
}

Compliance požiadavky (PCI DSS, HIPAA) typicky vyžadujú retenciu 1–7 rokov, ale nikde nehovoria, že to musí byť v drahom horúcom úložisku. Deep Archive je 80× lacnejší ako CloudWatch a stále zachováva dôkaznú hodnotu.

Monitoring observability nákladov

Najväčšia chyba: optimalizujete raz a o tri mesiace ste tam, kde ste začali. Observability budget musí mať vlastný dashboard a alerty. Vytvorte si týždenný KPI prehľad:

  • GB ingestovaných logov/deň/služba, alert pri +20 % týždeň-na-týždeň.
  • Počet aktívnych časových radov metrík, alert pri prekročení 80 % zazmluvneného limitu.
  • Sampling rate efektívne aplikovaný (sledovať per-service v OTel Collector metrikách).
  • Náklady na hosta na mesiac (Datadog usage attribution API).
  • Pomer indexovaných ku ingestovaným logom, cieľ 5–15 %.

AWS Cost Anomaly Detection a Datadog Cost Insights vedia upozorniť na anomáliu skôr, než ju zachytí mesačný billing review. Kombinujte ich s tagovaním per-team, aby ste vedeli, kto faktúru zdvihol, a aby team zodpovedný za nárast mal motiváciu ho aj vyriešiť. Bez chargeback modelu sa observability výdavky vždy vracajú do pôvodného stavu.

Často kladené otázky

Ako sa najrýchlejšie zníži účet za CloudWatch Logs?

Najrýchlejší zásah je nastaviť explicitnú retenciu (30 alebo 90 dní) na všetkých log groupoch, default je nekonečno. Druhým krokom je zvýšiť log level v produkcii z INFO na WARNING, čo typicky odstráni 60–75 % objemu ingescie pri zachovaní viditeľnosti pre incidenty.

Oplatí sa migrovať z Datadog na self-hosted Grafana stack?

Pri menej ako 50 hostoch sa migrácia oplatí len zriedka, uvoľnené FTE zjedia úsporu. Pri 200+ hostoch a stabilnom inžinieringu typicky ušetríte 60–80 % nákladov, no počítajte s 3–6 mesiacmi implementácie a trvalou prevádzkovou réžiou Loki, Tempo a Mimir clusterov.

Čo je high-cardinality metrika a prečo je drahá?

High-cardinality metrika je taká, ktorá má tagy s veľkým počtom unikátnych hodnôt (user_id, request_id, container_id). Každá kombinácia tagov tvorí samostatnú časovú radu, ktorá sa fakturuje. Tag user_id s 10 000 používateľmi vytvorí 10 000 časových radov z jednej metriky.

Aký sampling rate je správny pre distributed tracing?

V produkcii používajte tail-based sampling: 100 % chybových trace-ov, 100 % pomalých (nad 1 sekundu) a 1–5 % normálnej premávky. Head-based sampling zahodí kritické chyby skôr, než sa objavia, takže v roku 2026 je tail-based prakticky štandard pre serióznu APM.

Môžem použiť S3 ako primárne úložisko logov?

Áno. Kombinácia Kinesis Data Firehose, S3 a Athena je 10–30× lacnejšia ako CloudWatch Logs pre logy, ktoré nepotrebujete v real-time. Stratíte sub-sekundovú vyhľadávateľnosť, ale pre compliance, audit a forenznú analýzu je to optimálne riešenie.

O Autorovi Editorial Team

Our team of expert writers and editors.