Prometheus remote_write backpressure: keď monitoring zaplní disk a ešte aj stratí dáta

Remote write vyzerá ako “len ďalší výstup”. V skutočnosti je to pipeline s vlastnými failure módmi:

• remote endpoint je pomalý alebo offline,
• remote_write začne zaostávať,
• backlog rastie (v pamäti aj v WAL),
• a po čase riešiš dve krízy naraz:
  1. disk pressure / reštarty Promethea
  2. dáta sa už nedajú dobehnúť (gap v remote storage)

Tento článok je operatívny runbook: symptómy → merania → bezpečné zásahy → prevencia.

Testované na: Prometheus 2.45+ (TSDB + remote_write), bežné remote storage (Mimir/Thanos/“čokoľvek s /api/v1/write”). Názvy metrík sa môžu líšiť podľa verzie.

Ako remote_write funguje (iba to, čo potrebuješ pri incidente)

remote_write číta dáta z WAL (write-ahead log). To je výhoda: krátke výpadky remote endpointu sa dajú “prebufferovať” na disku.

Ale má to tvrdé hrany:

• Keď je endpoint down “príliš dlho”, buffer nie je nekonečný.
• Po návrate endpointu môže prísť catch-up burst, ktorý vie preťažiť sieť/CPU (a niekedy aj doraziť samotný remote endpoint).

Symptómy (čo uvidíš)

V grafoch

• samples_pending rastie a nevracia sa späť
• retried_samples_total rastie stabilne (neustále retry)
• “highest sent timestamp” výrazne zaostáva za aktuálnym časom
• disk s Prometheus dátami rastie rýchlosťou, ktorá vyzerá zle

V logoch

• context deadline exceeded, 500, 429, TLS chyby
• retry/backoff správy (závisí od verzie a logger nastavení)

Minimum signálov, ktoré chcem mať pri incidente

Metriky sa historicky menili. Ber konkrétne názvy ako “typické” a vždy si over, čo presne má tvoja verzia.

1) Ako ďaleko zaostáva remote_write (lag)

Typická metrika:

• prometheus_remote_storage_queue_highest_sent_timestamp_seconds (najnovší timestamp úspešne odoslaný)

Potom si spravíš “lag”:

time() - prometheus_remote_storage_queue_highest_sent_timestamp_seconds

Ak to rastie, remote_write nestíha.

2) Koľko backlogu visí

Typická metrika:

• prometheus_remote_storage_samples_pending

prometheus_remote_storage_samples_pending

3) Disk trend (time-to-disk-full)

Ak máš node exporter, sleduj:

• node_filesystem_avail_bytes
• rýchlosť poklesu dostupného miesta

Ak nie, sprav manuálny snapshot (na hostovi/pode):

du -sh /prometheus
du -sh /prometheus/wal 2>/dev/null || true
df -h /prometheus

Incident playbook: čo robiť, keď remote_write padá

Krok 0: potvrď, že problém je remote endpoint (nie lokálna sieť)

Z hosta/podu s Prometheusom:

curl -v https://REMOTE-ENDPOINT/api/v1/write

Často to nebude “200 OK” (niektoré endpointy neočakávajú GET), ale ide ti o DNS/TLS/connectivity a latenciu.

Krok 1: zisti, či si ešte v “bezpečnom okne”

Ak lag rastie a endpoint je down, polož si otázky:

• Ako dlho už remote_write reálne nestíha?
• Je pravdepodobné, že endpoint bude späť skôr, než hrozí disk full alebo neobnoviteľná strata backlogu?

Krok 2: rozhodni sa o trade-offe (prežiť vs. “žiadna strata”)

Keď endpoint nejde, máš iba pár možností:

Možnosť A — maximalizovať šancu dobehnutia (endpoint sa vráti čoskoro)

• necháš remote_write bežať,
• chrániš Prometheus pred OOM/disk full,
• pripravíš sa na “catch-up burst”, keď sa endpoint vráti.

Možnosť B — zachrániť Prometheus aj za cenu dier v remote storage

• dočasne vypneš remote_write alebo agresívne znížiš objem dát,
• cieľ: aby Prometheus nezomrel a lokálne alerty pokračovali,
• akceptuješ gap v remote storage.

Toto rozhodnutie musí byť explicitné. “Nechajme to tak a uvidíme” je najhoršia stratégia.

Krok 3: tuning queue_config (ak endpoint ide, ale je pomalý)

Template (neber čísla ako univerzálne — sú to len páky):

remote_write:
  - url: https://REMOTE-ENDPOINT/api/v1/write
    queue_config:
      # Backpressure / throughput knobs:
      max_samples_per_send: 2000
      capacity: 10000
      min_shards: 1
      max_shards: 50

      # Retry/backoff knobs:
      batch_send_deadline: 5s
      min_backoff: 30ms
      max_backoff: 5s

Praktické pravidlá:

• capacity: ak je príliš nízka, queue sa vie naplniť a backlog prestane odtekať.
  • rozumný starting point: capacity má byť niekoľkonásobok max_samples_per_send
• max_shards: viac shardov = viac paralelizmu = viac throughputu… ale aj:
  • viac pamäte,
  • viac tlaku na remote endpoint (riziko, že ho “dorazíš” po návrate)
• min_backoff/max_backoff: pomáhajú, aby po návrate endpointu neprišla “retry búrka”

Krok 4: keď sa endpoint vráti — sleduj catch-up, nie len “green”

Po návrate remote storage chceš vidieť:

• samples_pending klesá (trendovo),
• “highest sent timestamp” dobieha k aktuálnemu času,
• počet shardov nie je trvalo na maxime (saturácia).

Catch-up môže trvať dlho a byť náročný na CPU/network. Sleduj saturácie.

Prevencia: sprav z remote_write kontrakt s budgetom

Formalizuj si remote_write budget:

1. Max lag (napr. “remote_write nesmie byť pozadu viac než X minút”)
2. Disk budget pre Prometheus dáta (koľko GB vieš tolerovať pri výpadku)
3. Pamäťový budget (koľko RAM navyše remote_write smie zobrať)
4. Fallback stratégia:
   • kedy radšej vypnúť remote_write, aby Prometheus prežil,
   • čo dropnúť ako prvé (high-cardinality, noisy, low-value)

A hlavne: alerty, ktoré sa spúšťajú ešte pred disk full.

Čo by som spravil v produkcii

Moja “production default” stratégia:

1. mať dashboard pre remote_write lag + pending + shard saturáciu
2. mať alert “remote_write behind” + “pending rastie” + “disk trend”
3. mať dopredu rozhodnuté, či je priorita:
   • “remote storage bez dier”, alebo
   • “lokálne alertovanie musí žiť”
4. mať pripravené “safe switches”:
   • dočasné zníženie objemu (drop low-value metrík),
   • konzervatívne max_shards, aby som po návrate nedorazil endpoint

FAQ

Pomôže zvýšiť max_shards vždy?

Nie. Môže to len presunúť problém:

• preťaží remote endpoint,
• alebo zožerie RAM na Prometheovi.

Je bezpečné zmazať WAL?

Je to “data loss by design”. Ak to spravíš, robíš vedomé rozhodnutie zahodiť backlog. Nerob to bez explicitného súhlasu (incident channel).

Ako znížim objem dát bez úplného vypnutia?

Najčistejšie je dropnúť low-value metriky cez relabeling/metric_relabel_configs (alebo znížiť scrape rozsah). Začni tým, čo má najhoršiu kardinalitu.

Súvisiace

• /sk/blog/prometheus-cardinalita-explozia/ (keď objem/churn pochádza z kardinality)
• /sk/blog/cardinality-contracts-prometheus-label-budgety/ (label budgety ako kontrakt)
• /sk/blog/dash-contracts-grafana-alerty-ci/ (dashboardy/alerty ako kontrakt)

Ďalšie čítanie

• https://prometheus.io/docs/practices/remote_write/
• https://prometheus.io/docs/prometheus/latest/configuration/configuration/
• https://prometheus.io/docs/prometheus/latest/storage/