Monitoring homelaba: jak wiedzieć o awarii, zanim zauważy ją rodzina

Homelab psuje się po cichu

Nic nie wybucha. Po prostu któregoś wieczoru film się nie włącza, lista zakupów przestaje się synchronizować albo poranne przypomnienie nie przychodzi. Na początku moim systemem monitoringu była rodzina: niezawodny system, ale raportuje wyłącznie po awarii i najczęściej w najmniej oczekiwanym momencie.

Przy kilku kontenerach dało się z tym żyć. Przy kilkudziesięciu — z bazami danych, automatyzacjami i Home Assistant pod spodem — „chyba działa” przestało być odpowiedzią. Skoro traktuję dom jak mały system produkcyjny, to system produkcyjny bez monitoringu jest po prostu zgadywaniem i proszeniem się o katastrofę.

Trzy pytania, trzy narzędzia

Podział ról jest prosty. Metryki mówią, że coś się dzieje: kontener zjada pamięć, dysk się zapełnia, czas odpowiedzi rośnie. Logi mówią, dlaczego. Alerty decydują, czy ktoś ma o tym wiedzieć teraz, czy wystarczy rano.

Sam przepływ danych jest prostszy, niż sugeruje liczba nazw. Prometheus co kilkanaście sekund odpytuje eksportery o metryki kontenerów, hosta i poszczególnych usług; Promtail w tym czasie czyta logi wszystkich kontenerów i odsyła je do Loki. Reguły alertów mieszkają w konfiguracji Prometheusa, a gdy któraś się zapali, Alertmanager decyduje o trasie — kto ma się dowiedzieć, którym kanałem i czy w ogóle o tej porze. Ostatni odcinek, od surowego alertu do zrozumiałej wiadomości na telefonie, należy do n8n.

Grafana celowo nie jest w tym łańcuchu niczym więcej niż oknem. Dashboard, na który nikt nie patrzy, nie jest monitoringiem — jest wygaszaczem ekranu. Prawdziwą robotę wykonują reguły alertów, a te bolą najbardziej. Każda z poniższych historii to fałszywy alarm, który najpierw obudził mnie, a dopiero potem nauczył.

Lekcja 1: metryki kłamią uprzejmie

Pierwsza wersja alertu o pamięci używała metryki container_memory_usage_bytes. Brzmi jak dokładnie to, czego potrzeba — i według niej mój bloker reklam zajmował 433 MB, niepokojąco blisko limitu. Problem w tym, że ta metryka wlicza cache systemu plików, który jądro i tak odda przy pierwszej potrzebie. Realne zużycie, mierzone przez container_memory_working_set_bytes, wynosiło 326 MB. Sto megabajtów różnicy — i alert, który straszył pamięcią możliwą do odzyskania w każdej chwili.

# Źle: wlicza cache FS, zawyża o 30-100%
container_memory_usage_bytes{name="adguard"}

# Dobrze: pamięć, której kontener naprawdę potrzebuje
container_memory_working_set_bytes{name="adguard"}

Lekcja 2: alert, który nigdy nie gaśnie

Liczniki w Prometheusie tylko rosną. Reguła w stylu „alarmuj, gdy licznik restartów jest większy od zera” wygląda niewinnie, ale ma zabawną właściwość: kontener, który zrestartował się raz, trzy tygodnie temu, będzie ją spełniał do końca świata. Alert zapala się i już nigdy nie gaśnie.

# Źle: prawda na zawsze po pierwszym restarcie
container_restart_count > 0

# Dobrze: czy restart zdarzył się w ostatnich 5 minutach
increase(container_restart_count[5m]) > 0

Pytanie, na które ma odpowiadać alert, to nie „czy to się kiedykolwiek zdarzyło”, tylko „czy to dzieje się teraz”. Różnica między tymi zapytaniami to różnica między monitoringiem a kroniką.

Lekcja 3: monitoring, który monitorował sam siebie

Najlepsza pętla, jaką zbudowałem nieświadomie. Reguła w Loki szukała w logach słów wskazujących na zabite procesy — między innymi „oom” i „killed”. Rzecz w tym, że Loki loguje także własne zapytania. Zapytanie o „oom” trafiało do logów Loki, gdzie znajdowała je ta sama reguła, która je wysłała. Monitoring z powodzeniem wykrywał, że monitoruje.

Bonus: samo „oom” bez granic słowa dopasowuje się też do „Room” i „Zoom”. Wystarczy kontener z nazwą pokoju w logu, żeby dostać alert o rzekomo zabitym procesie.

# Dobrze: granice słowa + wykluczenie własnych logów Loki
{job="containerlogs", container_name!="loki"} |~ "(?i)\\boom\\b|\\bkilled\\b"

Alert ma być wiadomością, nie zrzutem stosu

Surowy alert z Alertmanagera wygląda jak wiadomość od robota do robota: etykiety, wartości, identyfikatory. O siódmej rano, na telefonie, nikt tego nie czyta. Dlatego między Alertmanagerem a telefonem stoi n8n z małym lokalnym modelem językowym, który streszcza alert po polsku: co się stało, którego kontenera dotyczy i od czego zacząć.

Trasa jest krótka, ale każdy przystanek ma swoje zadanie. Alertmanager wysyła webhook do n8n, ten sprowadza etykiety i opisy różnych reguł do jednego formatu i prosi lokalny model uruchomiony w Ollama o streszczenie. Ważność alertu nie jest opinią modelu — wynika z etykiet reguły; AI tłumaczy, nie decyduje. Gotowa wiadomość trafia do adresata jego kanałem: ntfy albo Telegram.

# Trasa alertu:
# Prometheus → Alertmanager → webhook → n8n
#   → normalizacja etykiet i opisów do jednego formatu
#   → lokalny model (Ollama): streszczenie po polsku
#   → routing per użytkownik: ntfy | Telegram
#   → godziny ciszy: kolejka → wysyłka rano

Model działa na CPU serwera — streszczenie alertu to nie konwersacja, więc kilkanaście lub kilkadziesiąt sekund w zupełności wystarcza. W zamian opis tego, co dzieje się w moim domu, nigdy nie opuszcza domu. To ten sam kompromis, który opisałem przy agencie AI w Home App: lokalna AI jest wolniejsza od chmurowego API, ale prywatność ma tu wyższy priorytet niż kilka sekund.

Dalej działa zwykła higiena powiadomień: alerty krytyczne przechodzą zawsze, reszta respektuje godziny ciszy i czeka w kolejce do rana. System, który budzi ludzi wiadomością o niekrytycznym wzroście użycia dysku, sam prosi się o wyciszenie — a wyciszony monitoring to najdroższy rodzaj braku monitoringu.

Kto pilnuje strażnika

Najgorszy scenariusz to nie awaria usługi. To awaria monitoringu — cisza, która wygląda jak spokój. Przez jakiś czas żyłem w przekonaniu, że brak alertów oznacza zdrowy system, aż odkryłem, że potrafi też oznaczać martwy kanał powiadomień.

Rozwiązanie jest stare jak kolej: dead-man's switch. Jeden sygnał kontrolny jest aktywny zawsze, ale nie budzi człowieka co kilka minut — regularnie potwierdza, że cała ścieżka od Prometheusa, przez n8n, po telefon działa. Dopiero jego brak jest alarmem. Do tego osobny watchdog sprawdza, czy zaplanowane zadania faktycznie się wykonały. Cisza przestała być dobrą wiadomością; dobrą wiadomością jest regularny puls.

Z tej samej kategorii: po restarcie serwera eksporter metryk kontenerów potrafi wstać w stanie, w którym niczego nie zgłasza. Wszystko wygląda na zielone, bo nie ma danych, które mogłyby być czerwone. O takich rzeczach dowiadujesz się tylko wtedy, gdy monitorujesz również monitoring.

Kompromisy

Ten stack nie jest darmowy. To kilka dodatkowych kontenerów, zauważalny kawałek RAM-u i reguły, które trzeba utrzymywać jak kod — moje żyją w repozytorium git, z historią zmian i powodem każdej poprawki w komunikacie commita. Bez tego po pół roku nikt nie pamięta, czemu alert ma akurat taki próg i czy ten próg był mądrością, czy paniką.

Co się zmieniło

Trzy rzeczy widać na co dzień. Fałszywe alarmy po opisanych poprawkach niemal zniknęły — a te alerty, które przychodzą, czyta się jak wiadomość od człowieka, nie jak zrzut z systemu. O większości awarii dowiaduję się z telefonu, zanim ktokolwiek w domu zdąży je zauważyć: kontener, który padł w nocy, jest rano opisany i zwykle naprawiony, zanim ktoś sięgnie po listę zakupów. A martwy kanał powiadomień — kiedyś niewidzialny tygodniami — dziś zgłasza się sam, brakiem pulsu.

Rodzina nadal zgłasza błędy. Ale już nie jako pierwsza.

Czego nauczył mnie ten stack

Że najtrudniejsze w monitoringu nie jest zbieranie danych — zbierać jest łatwo, kontenery chętnie opowiadają o sobie wszystko. Najtrudniejsze jest zdecydowanie, co z tego zasługuje na czyjąś uwagę o trzeciej w nocy. Każdy z moich fałszywych alarmów był w gruncie rzeczy błędną odpowiedzią na to pytanie.

I że monitoring też jest usługą, która się psuje. Odkąd pilnuje go dead-man's switch, ufam ciszy — ale tylko dlatego, że cisza co kilka minut podpisuje się imieniem i nazwiskiem.