Prometheus native histogramy v produkcii: rollout plán, budgety a failure módy

Zapnete native histogramy, lebo chcete lepšiu viditeľnosť latencie bez bucket-cardinality bolesti. O dve hodiny neskôr:

Prometheus pamäť rastie rýchlejšie, než ste čakali
WAL rastie agresívne
remote_write začne zaostávať
query latencia je horšia, nie lepšia

Native histogramy sú silné, ale operatívne sa správajú ako nový metric typ s novými cost surface. Rollout berte ako infra zmenu, nie ako “upgrade knižnice”.

Testované na: Prometheus 2.48–2.53, Grafana 10.x, remote_write do long-term storage, mix klasických + native histogram workloadov.

Incident (anonymizovaný)

Tím zapol native histogramy cluster‑wide pre request latenciu. Očakávali “menej kardinality, rovnaké náklady”.

Namiesto toho:

head memory ~2x
WAL write volume vyššie
remote_write queue backlog
dashboardy timeoutovali počas peak

Blast radius: monitoring celého clusteru degradoval; on-call pri inom incidente nemal spoľahlivé grafy.

Constraint: histogramy potrebovali (SLO práca), ale nemohli si dovoliť destabilizovať observability.

Timeline

T-0: zapnuté native histogramy; bez okamžitých problémov.
T+2h: Prometheus RSS rastie; GC a scrape timings sa zhoršia.
T+4h: WAL rastie; remote_write pending samples rastú.
T+6h: Grafana dashboardy timeoutujú (ťažké query nad histogrammi).
T+30m (mitigácia): drop native histogramy pre high-volume joby; necháme len canary job.
T+1d: staged rollout plán + budgety sú implementované.

Mechanizmus: prečo native histogramy menia cost model

Neplatíte iba “series count”

Klasické rady riešia kardinalitu. Native histogramy môžu mať nízky počet series, ale byť drahé v:

bytes per sample
WAL amplifikácii
head chunk pamäti
query CPU/pamäti (agregácie nad hustými histogram samplemi)

remote_write a long-term storage nemusia byť symetrické

Aj keď remote_write “funguje”, downstream systém môže:

dropovať nepodporovaný sample type
ukladať drahšie kvôli encodingu
mať pomalší ingest path pre histogramy

Failure mode potom vyzerá ako “remote_write backpressure”, ale trigger je sample typ + objem.

Runbook: diagnostika problémov s native histogramami

Čo skontrolovať ako prvé

Je to naozaj zapnuté?

Prometheus má endpoint s flags:

curl -s http://prometheus:9090/api/v1/status/flags | head

Hľadajte enable-feature s native histogramami.

Tri pressure pointy

head memory (TSDB head)
WAL growth
remote_write queue

Porovnajte “pred vs po” zapnutí.

Ako potvrdiť hypotézu

Použite Prometheus vlastné metriky.

PromQL v text:

# Head memory/series pressure
prometheus_tsdb_head_series
prometheus_tsdb_head_chunks
rate(prometheus_tsdb_wal_writes_total[5m])

# Scrape pressure
rate(prometheus_target_scrapes_exceeded_sample_limit_total[5m])
rate(prometheus_target_scrapes_sample_duplicate_timestamp_total[5m])

# remote_write pressure
prometheus_remote_storage_samples_pending
rate(prometheus_remote_storage_samples_failed_total[5m])
rate(prometheus_remote_storage_samples_dropped_total[5m])

Pattern:

step change krátko po enable
rast pending samples + scrape duration
WAL write rate rastie aj keď series count veľmi nevyskočí

Bezpečné mitigácie

Canary rollout

zapnúť native histogramy iba pre jeden Prometheus alebo jeden scrape job

Keep/Drop na scrape

pre high-volume joby si nechajte iba histogramy, ktoré reálne potrebujete
dropnite experimentálne metriky skoro

Dočasne znížiť scrape volume

zvýšiť scrape interval pre job, ktorý posiela veľké histogramy
znížiť label noise, ktorý multiplikuje sample

Vypnúť native histogramy pre problémové joby

netreba rollbacknúť celú infra, ak sú problém 1–2 joby

Rizikové mitigácie

Wipe TSDB/WAL

“opraví disk”, ale stratíte dáta a zakryjete root cause

Slepo zvýšiť remote_write queue

maskuje nekompatibilitu downstreamu a oddiali pád

Zapnúť histogramy všade

“global switch” je najrýchlejší spôsob, ako rozbiť monitoring

Čo sme zmenili (konkrétne)

1) Staged rollout: najprv canary job

Native histogramy sme obmedzili na jeden job.

Príklad keep-only relabelingu:

scrape_configs:
- job_name: api-canary
  static_configs:
  - targets: ["api-canary:8080"]
  metric_relabel_configs:
  - source_labels: [__name__]
    regex: 'http_request_duration_seconds'
    action: keep

2) Budget: native histogramy sú opt-in a počítajú sa

Zaviedli sme “observability contract”:

per job: max N native histogram metrík
per service: max ingestion rate pre histogram samples
rollout vyžaduje pred/po dashboard review

3) Query guardrails: prepočítajte bežné pohľady dopredu

Pridali sme recording rules pre stabilné dashboardy a nižší query cost.

Príklad:

groups:
- name: api-histograms
  rules:
  - record: job:http_request_duration_seconds:p95
    expr: |
      histogram_quantile(0.95, sum by (le, job) (rate(http_request_duration_seconds_bucket[5m])))

(Ak používate native histogramy, prispôsobte tvar pravidla. Pointa je: prepočítajte drahý view dopredu.)

Ako verifikovať (merateľné)

Po zmenách overte:

head metriky sa stabilizujú (žiadny monotónny rast viazaný na histogramy)
WAL write rate sa vráti blízko baseline
remote_write pending samples ostanú bounded
dashboardy netimeoutujú; query duration klesne

Prevencia / guardrails

Kontrakty

Native histogramy sú feature-flagované per job, nie cluster-wide default.
remote_write pipeline musí preukázať kompatibilitu pred rolloutom (staging + load test).
budgety:
- histogram metriky per service
- ingestion rate budget
- dashboard query budget (max duration, max samples)

Alerty

anomália rastu head series/chunks
anomália WAL write rate
remote_write pending > threshold > N min
dashboard SLO: query error rate a p95 query duration