Przejdź do treści
← Powrót do bloga

Opublikowano 9 września 2026 · 3 min czytania

Mój monitoring milczy. Zbudowałem go tak, żeby milczenie coś znaczyło

Mój skrypt kontrolujący kopie zapasowe zwykle nic nie mówi. Uruchamia się, sprawdza kilkadziesiąt rzeczy i kończy bez słowa. Cisza znaczy: wszystko gra.

To jest wygodne i jednocześnie jest to najbardziej ryzykowna decyzja projektowa w całym tym zestawie. Bo cisza ma dokładnie dwie przyczyny: albo naprawdę nie ma o czym mówić, albo kontrola się nie uruchomiła. Z zewnątrz wyglądają identycznie.

Kontrola, która kontroluje samą siebie

Dlatego ostatnią rzeczą, jaką skrypt sprawdza, jest on sam. Dwa pytania: czy zadania w harmonogramie systemu są w ogóle załadowane oraz kiedy ta kontrola przebiegła ostatni raz. Jeśli nie działała dobę z okładem, mówi to wprost — bo cisza w tym czasie nie znaczyła nic.

Próg to 48 godzin. Poniżej tego to zwykle komputer wyłączony na weekend, a alarm o wyłączonym komputerze uczy ignorować alarmy.

To jest cała reguła i mieści się w jednym zdaniu: cisza jest dowodem tylko wtedy, gdy istnieje coś, co potwierdza, że milczący system żyje. Bez tego brak alarmu jest nie do odróżnienia od braku monitoringu.

Co ta kontrola faktycznie sprawdza

Kopie: wiek kopii systemowej, wykorzystanie przydzielonego limitu, kod błędu zgłoszony przez mechanizm kopii, głębokość historii — bo skrócenie łańcucha oznacza, że kopia zaczęła się od nowa i starsze wersje plików przestały istnieć. Do tego wiek kopii zimnej i kopii trzymanej poza domem.

Sprzęt: stan SMART dysków, wolne miejsce na każdym celu kopii, zawieszony montaż udziału sieciowego. Po stronie serwera: stan każdej macierzy, niezgodne bloki, wolne miejsce na pulach, obecność właściwego pliku kopii i rozmiar sieciowego kosza, do którego trafiają pliki usuwane przy przerzedzaniu historii.

Progi nie są okrągłe dla urody. 36 godzin na kopię systemową to harmonogram godzinowy plus zapas na noc bez sieci. 10 dni na kopię zimną, robioną co tydzień, to już poślizg. 14 dni na kopię poza domem to tydzień plus zapas na wyjazd. 50 GB wolnego na celu, bo synchronizacja z usuwaniem potrzebuje miejsca na zapis, zanim skasuje stare pliki.

Czego świadomie nie kontroluję

To jest ważniejsza połowa tej listy, bo każde powiadomienie bez decyzji uczy ignorowania reszty.

Nie pilnuję obciążenia serwera, zużycia pamięci, temperatur w normie ani czasu pracy bez restartu. Żadna z tych liczb nie zmienia żadnej mojej decyzji. Nie pilnuję też procesora, grafiki, zasilaczy i pamięci RAM — nie dlatego, że nie mogą paść, tylko dlatego, że nie dają sygnału z wyprzedzeniem. Dysk zapowiada awarię z miesięcznym zapasem i dlatego go pilnuję. Reszta albo działa, albo nie.

Żadna z moich maszyn nie ma pamięci z korekcją błędów, więc błąd pamięci jest niewidoczny aż do awarii. Zamiast udawać pomiar, którego nie mam, liczę awarie systemu w oknie 14 dni i samoistne restarty serwera. Jedna awaria to informacja, kilka to alarm. To jedyny sygnał, jaki mam o pamięci, zasilaniu i chłodzeniu — i mówię o nim wprost, zamiast pokazywać zielony wskaźnik oparty na niczym.

Czego nie zrobiłem

Nie dorzuciłem przypomnienia o jednej z pul dyskowych, która nie ma redundancji. Kusiło, bo skrypt widzi ten stan, a system operacyjny raportuje tę macierz jako sprawną — jest zdefiniowana jako lustro złożone z jednego dysku. Wygląda zdrowo i technicznie jest zdrowa.

Sprawdziłem, co tam leży: dane odtwarzalne. Awaria tego dysku jest kosztem czasu, nie stratą. Więc zamiast comiesięcznego ostrzeżenia, na które i tak bym nie reagował, decyzja jest zapisana w dokumentacji razem z warunkiem jej unieważnienia: gdyby na tę pulę miało trafić coś nieodtwarzalnego, wracamy do tematu. Dokumentacja pamięta lepiej niż powiadomienie, które nauczyłem się przewijać.

Trzy rzeczy, które z tego biorę

Cisza musi być zasłużona. System, który milczy, ma obowiązek udowodnić, że żyje — inaczej jego milczenie jest bezwartościowe.

Lista rzeczy niekontrolowanych jest częścią monitoringu. Napisana i uzasadniona, przestaje być przeoczeniem, a staje się decyzją, do której da się wrócić.

Alarm bez decyzji to szkoda, nie zysk. Zanim dołożysz kontrolę, odpowiedz sobie, co zrobisz, gdy się odezwie. Jeśli odpowiedź brzmi „nic", właśnie osłabiłeś wszystkie pozostałe alarmy.


Progi, liczby i decyzje opisane wyżej pochodzą z konfiguracji zmierzonej i uporządkowanej 16 sierpnia 2026 na moim własnym sprzęcie domowym.

Patryk Piecyk

Patryk Piecyk

Warszawa · junior konsultant wdrożeniowy · dostępny od zaraz

Przez 7,5 roku pracowałem w niemieckiej firmie, pięć lat prowadząc jej biuro: zamówienia, faktury, reklamacje, ERP. Od czerwca 2026 buduję własne narzędzia do tej samej roboty — nie jestem programistą z wykształcenia, kod powstaje w parze z asystentem AI, a projekt, decyzje i testy są moje. Te notatki opisują, co się w tych systemach zepsuło i co z tego wyszło.

Masz pytanie do tego tekstu?

Napisz do mnie →