Prometheus WAL replay peklo: pomalý štart a chýbajúce alerty
Keď Prometheus štartuje desiatky minút, často je vinník WAL replay. Ako to dokázať z logov a disku, bezpečne sa zotaviť a predísť blind spotom.
52 článkov
Keď Prometheus štartuje desiatky minút, často je vinník WAL replay. Ako to dokázať z logov a disku, bezpečne sa zotaviť a predísť blind spotom.
Klienti timeoutujú, tcpdump ukazuje SYN (niekedy aj SYN-ACK), ale aplikácia nič neloguje. Častý vinník: Linux listen/accept fronty, ktoré sa pri load-e alebo CPU starvation preplnia.
Jedna obrovská transakcia vie pripnúť logical replication na hodiny. Runbook na rýchlu identifikáciu, bezpečné tunenie decodingu a kontrakt na bounded transakcie.
Reloady NGINX Ingressu vedia dropovať keep-alive a robiť 502 špičky pri častých zmenách. Runbook na dôkaz reloadu, zníženie churnu a hardening.
Sporadicke TLS handshake zlyhania a JWT zamietnutia napriec sluzbami. Vsetko prejde ked to skontrolujete. Vinik: hodiny nodu sa posunuli alebo skocili, a NTP to opravilo skor nez ste to stihli zachytit.
Váš EXPLAIN vyzerá perfektne ale produkcia horí. Vinník: PostgreSQL ticho prepol z custom plánu na generic plán po dostatočnom počte vykonaní, a generic plán je katastrofálne zlý.
PostgreSQL LISTEN/NOTIFY funguje perfektne v lokalnom testovani ale notifikacie nahodne prestanu prichodit v produkcii. Vinik: transaction pooling ticho prideluje vase spojenie niekomu inemu.
tcpdump ukazuje pakety ktore prichadzaju, ale aplikacia nic nevidi. Vinik: Linux reverse path filtering ticho zahadzuje pakety predtym nez dosiahnu iptables, sposobene asymetrickym routovanim.
df -h ukazuje 40% voľného miesta. Ale váš kontajner stále padá s ENOSPC. Vinník: vyčerpanie inodov na overlayfs vrstvách, neviditeľné pre štandardný monitoring.
Aplikácia visí, ale databáza vyzerá zdravo. Najčastejšie je vyčerpaný connection pool. Ukážem detekciu, rozumné dimenzovanie a prevenciu únikov spojení.
Niečo zmazalo riadky z produkcie ale nikto nepriznáva že spustil DELETE. Použi pg_waldump na analýzu WAL súborov a rekonštruuj presne čo sa stalo a kedy.
Queue vyzerá zdravo až do deploymentu, potom messages_unacknowledged exploduje, pamäť stúpa a redelivery storms začínajú. Vinník: tvoj prefetch je príliš vysoký a nikto netestoval skutočné ack správanie.
Kontajner má 4GB memory limit ale OOM kill pri 2GB used. Kernel buffers, page cache a cgroup accounting triky spôsobujú skoré OOMKills. Tu je celý obraz.
Všetky partitiony vyzerajú vyvážené v testovaní, potom príde produkčný traffic a jedna partition sa roztopí. Vinník: tvoj partition key má otrásnú kardinalitu a nikto si toho nevšimol.
APF vie vyhladovať Kubernetes API: kubectl visí, controllery timeoutujú a rastú 429. Runbook na izoláciu klienta, úpravu FlowSchema a verifikáciu.
Envoy/Istio vie vrátiť 503 UF/UO/UT, keď pretečie connection pool. Ako čítať flags, pozrieť proxy stats, upraviť DestinationRule a rýchlo overiť.
5 data nodov ale jeden je na 100% CPU. Nerovnomerné routing kľúče vytvárajú hot shardy. Ukážem ako detekovať skew a opraviť ho pomocou routing stratégií.
Disk sa plní WAL súbormi. Príčina: logical replication slot consumer odišiel offline a PostgreSQL drží všetok WAL odvtedy pretože by mohol byť potrebný.
CPU je na 20% ale latencia je 500ms. Štandardné profilery neukazujú nič. Appka čaká, nepočíta. Ukážem ako použiť eBPF na nájdenie na čo čaká.
Náhodné DNS timeouty, dropped spojenia, služby timeout-ujú. Vaša nf_conntrack tabuľka je plná. Ukážem ako diagnostikovať, monitorovať a opraviť tento K8s networking problém.
Váš Redis má 4GB maxmemory ale RSS ukazuje 6GB. OOM killer zasiahne. Vysvetlím jemalloc fragmentáciu s reprodukciou a tuningom activedefrag.
Full-text search bol rýchly, teraz je pomalý. Príčina: GIN index pending list narástol obrovský počas bulk insertov a každé vyhľadávanie musí teraz skenovať nezoradené pending záznamy.
Query vracia nesprávne výsledky po upgrade OS. Príčina: ICU library verzia sa zmenila, pravidlá collation sa posunuli a indexy sú teraz zoradené nekonzistentne s novým poradím.
Nemôžeš pripojiť profiler k produkčnej JVM. seccomp blokuje perf_event_open, container dropol CAP_SYS_PTRACE a PodSecurityPolicy bráni privileged mode. Tu je ako profilovať aj tak.
Query skenuje celú tabuľku napriek perfektnému partial indexu. Príčina: WHERE klauzula query sa presne nezhoduje s predikátom indexu, alebo štatistiky zavádzajú plánovač.
Go aplikácia má zrazu 10,000 threadov konzumujúcich všetku pamäť. Príčina: cgo-based DNS resolution blokujúce v pomalých DNS prostrediach, obchádzajúce Go's goroutine scheduler.
CPU využitie je nízke ale requesty sú pomalé. Skrytý vinník: čas strávený čakaním v scheduler run-queue, neviditeľný pre tradičné profilery ale viditeľný s eBPF off-CPU analýzou.
Traffic ide na starý server po failoveri. Príčina: Linux ARP cache drží MAC adresu zlyhajúceho nodu, posiela pakety na nedosiahnuteľnú destináciu minúty.
Nový node sa pripája ku clusteru ale je odmietaný. IP starého nodu je stále v blackliste failure detection gossip protokolu. Zombie membership záznam žije ďalej.
Service vracia zlé pod IP po škálovaní. Príčina: Linux conntrack drží DNAT záznamy dlhšie ako existujú pody, smeruje traffic na zmazané endpointy.
Perfektná idempotency logika, ale zákazníci sú stále účtovaní dvakrát. Príčina: kontrola idempotency keys voči read replice ktorá je sekundy za primary počas špičiek.
Dotazy na read replikách zlyhávajú s 'canceling statement due to conflict with recovery'. Riešenie závisí od toho, ktorý z 5 typov konfliktov máte - tu je návod ako diagnostikovať a vyriešiť každý z nich.
Redis nody OOMKilled počas rebalancingu clustra. Príčina: migrácia slotov kopíruje kľúče do cieľa pred zmazaním zo zdroja, dočasne zdvojnásobuje využitie pamäte.
Dva nody súčasne veria že držia leader lease. Príčina: malá NTP korekcia hodín dozadu kombinovaná s kódom ktorý mieša wall-clock čas s duration-based timeoutmi.
Heap metriky vyzerajú dobre, GC je spokojný, ale kontajner stále umiera. Vinník: native memory z direct buffers, JNI a glibc memory allocator fragmentácia.
Periodické latency špičky ktoré vyzerajú ako network jitter. Skutočná príčina: vnorené timeouty vytvárajú tisíce timerov ktoré zaťažujú Go runtime timer heap a spúšťajú GC scanning.
Dostávate 'could not serialize access due to concurrent update'? Riešenie nie je len retry logika - je to pochopenie kedy použiť ktorú isolation level a ako znížiť frekvenciu konfliktov.
gRPC spojenia sa náhodne zatvárajú s 'transport is closing'. Príčina: klient a server keepalive nastavenia sa nezhodujú, server terminuje idle spojenia.
Náhodné ECONNRESET na niektorých nodoch. Endpointy vyzerajú správne. Vinník: conntrack NAT záznamy držia dlhodobé spojenia pripnuté k podom, ktoré už neexistujú.
work_mem vyzerá malé na 256MB, ale parallel hash join so 4 workers naprieč 3 plan nodes používa 3GB. Tu je ako zabrániť PostgreSQL legitímne OOMnúť váš kontajner.
Pod OOMKilled napriek nastavenému MaxMetaspaceSize. Príčina: Metaspace rastie mimo heap, container memory limit nepočíta s tým, a triedy sa neuvoľňujú.
Pridanie indexu pre výkon spôsobilo 10x pomalšie zápisy. Kontra-intuitívna príčina: nový index rozbil HOT updaty, meniaci lacné in-place updates na drahé full-row rewrites s masívnym bloatom.
Rolling deploy zlyháva s cached plan chybami po ALTER TABLE. Príčina: server-side prepared statements cachujú query plány ktoré sa rozbijú pri zmene schémy.
Apiserver je 'náhodne pomalý'. Príčina: veľké, často aktualizované ConfigMapy spúšťajú watch compaction, čo spôsobuje simultánny relist tisícov kontrolérov.
Cluster prestane prijímať zápisy, pody sa nedajú naplánovať. Príčina: etcd dosiahol storage quota lebo compaction nebežal, história sa nahromadila nad limity.
Requesty idú na neexistujúce pody. Príčina: headless service DNS záznamy pretrvávajú v klient DNS cache po zmazaní podov, pred propagáciou endpoints update.
Deploy spôsobuje 503 presne 2 minúty. Problém: conntrack drží NAT mapovanie na staré pod IP aj po tom čo Kubernetes odstráni endpointy.
Jeden Kubernetes node začne zlyhávať pripojenia k externým službám zatiaľ čo pody vyzerajú zdravé. Skrytá príčina: sidecar proxy vyčerpávajú ephemeral porty krátkodobými spojeniami.
Malé API odpovede fungujú, veľké visia navždy. Príčina: ICMP 'Fragmentation Needed' správy filtrované firewallmi, rozbíjajú Path MTU Discovery v overlay sieťach.
Náhodné 1-3 sekundové výpadky spojení počas deploymentov. CPU vyzerá v poriadku, pamäť stabilná. Skrytá príčina: iptables-restore drží xtables lock počas endpoint churnu.
Služba sa nemôže pripojiť k databáze - 'cannot assign requested address'. Príčina: ephemeral porty vyčerpané tisíckami socketov v TIME_WAIT stave.
gRPC volania medzi nodmi náhodne zlyhávajú ale lokálna komunikácia funguje. Vinník: TX checksum offload poškodzuje VXLAN hlavičky na špecifických NIC driveroch.