Log, spike 95% i milczące metryki — dlaczego same wykresy nic nie mówią
Wyciąg z logów: spike CPU do 95% o 02:13 na hoście, na którym działa LXC z Dockerem (Plex + Arr‑s) i gdzie sieciowy system plików na Proxmox wprowadza opóźnienia.
Scena i problem
Proces monitorowania jest dość prosty — regularne gromadzenie danych serwera i analiza ich w czasie — ale prostota to nie to samo co użyteczność. Miernik pokaże 95% CPU, ale nie powie, czy to wina hosta (iowait/steal) ograniczeń cgroup w LXC, kontenera Docker czy opóźnień w warstwie sieciowego systemu plików.
Dlaczego kontekst ma znaczenie
Na poziomie hosta obserwujesz: load, iowait cpu steal liczby IRQ, metryki dysków (latency await), kolejki IO. W LXC dostaniesz ułamek tego, często jako cgroup: cpu.shares, blkio.stat. W Dockerze jeszcze inna perspektywa — docker stats, blkio a do tego specyficzne zachowania aplikacji (Plex skanuje bibliotekę, Arr‑s robi harmonogramy). Sieciowy system plików (NFS/SMB/Ceph) dokłada dodatkową warstwę: opóźnienia RPC, retransmisje, czasy oczekiwania na serwer plików.
Co mierzyć (konkret)
Zbieraj: CPU (user/system/iowait/steal), IO (r/s, w/s, rkB/wkB, await, svctm), kolejki (avgqu‑sz) latency per device, blkio per cgroup, docker blkio i cpu statystyki sieci (retransmits, latency). Użyj narzędzi: iostat -x, pidstat, atop, sar docker stats, cat /sys/fs/cgroup/*, oraz eksportuj to do Prometheus/Influx/Nagios. Nagios XI jest kompletnym rozwiązaniem do monitorowania i ma sens jeśli metryki są sensownie zmapowane do kontekstu host, LXC i Docker.
Jak korelować
Gdy widzisz spike CPU do 95% o 02:13, sprawdź metryki i synchronizację znaczników czasu.
Przykład z warsztatu jors.pl
W jednym wdrożeniu prosty alert na narastający IO uratował produkcję: alarm wskazał wzrost await i średnią długość kolejki na urządzeniu sieciowego systemu plików co wymusiło korektę mount options i bufsize na Proxmoxie. Podczas analizy to samo środowisko ujawniło korelację z działaniem kontenera Plex podczas skanowania biblioteki; dodatkowe testy potwierdziły, że problem nie był w CPU hosta, a w konfiguracji sieciowego systemu plików — podobne wnioski pojawiły się przy testach pamięci ECC, gdzie kontrola jednej warstwy odsłoniła źródło błędu w innej.
Alarms should be simple and targeted: progi CPU/IO/latency/queue z hysteresis i playbook reakcji, tak by Nagios XI lub inny system nie tylko alarmował, ale wskazywał kontekst (host vs LXC vs Docker vs FS).