Ten tekst opisuje monitoring Zabbiksem w małej firmie: co monitorujemy na kilkanaście serwerów i przełączników, czego świadomie nie monitorujemy i dlaczego pierwszy miesiąc po wdrożeniu to strojenie progów, a nie oglądanie wykresów.
Zabbix nie kosztuje ani złotówki za licencję i to jest najmniej ważna rzecz, jaką da się o nim powiedzieć. O wartości monitoringu rozstrzyga to, co dzieje się zaraz po alercie: kto go widzi, kto ma prawo działać i czy sygnał w ogóle dotarł do człowieka, który nie śpi.
Kto odbiera telefon o trzeciej w nocy i co wtedy robi? Wokół tej odpowiedzi zbudowany jest cały ten tekst. Opisujemy, jak wygląda monitoring Zabbiksem w małej firmie: co monitorujemy na kilkanaście serwerów i przełączników, czego świadomie nie monitorujemy, dlaczego pierwszy miesiąc schodzi na strojenie progów, oraz czego w Zabbiksie nie lubimy.
Firma bez monitoringu też ma system wykrywania awarii. Tym systemem są pracownicy, a w gorszym wariancie klienci.
Ta różnica nie polega na tym, że ktoś ma wykresy, a ktoś inny ich nie ma. Polega na tym, kto dowiaduje się pierwszy i ile czasu mija między momentem, w którym coś przestało działać, a momentem, w którym ktokolwiek o tym wie. Bez monitoringu ta przerwa trwa dokładnie tyle, ile potrzeba, żeby ktoś zauważył problem, uznał go za swój, znalazł numer do informatyka i dodzwonił się. W środku dnia to kwadrans, w piątek po siedemnastej to poniedziałek rano.
Jest jeszcze druga kategoria awarii, których pracownik nie zgłosi nigdy, bo ich nie widzi. Kopia zapasowa, która od trzech tygodni kończy się błędem, wygląda z zewnątrz identycznie jak kopia, która się udaje. Dysk zapełniony w 94 procentach działa tak samo jak pusty, aż do dnia, w którym przestaje. Certyfikat strony wygasa w niedzielę i nikt nie zgłasza tego w sobotę. To są awarie z zapowiedzią, tylko że zapowiedź trafia do pliku dziennika, którego nikt nie czyta.
Monitoring zamienia obie sytuacje na jedną: to system melduje o problemie, a nie człowiek. Reszta tego tekstu jest o tym, co dzieje się po tym meldunku, bo tam siedzi cała wartość i wszystkie sposoby, żeby ją zmarnować. Jeśli szukacie ogólnego wprowadzenia, po co w firmie monitoring, opisaliśmy to w osobnym wpisie o monitoringu infrastruktury .
Zasada doboru jest jedna i brzmi banalnie, dopóki nie zacznie się jej trzymać: mierzymy to, na co ktoś zareaguje. Metryka, po której nikt nic nie zrobi, nie jest monitoringiem, tylko wykresem.
Lista, która w firmie na kilkanaście maszyn zamyka większość realnych awarii:
Czego świadomie nie monitorujemy w takiej firmie: obciążenia procesora na stacjach roboczych, każdej pozycji z domyślnego szablonu producenta, temperatury każdego czujnika w serwerze i wszystkiego, czego właścicielem nie jest żadna konkretna osoba. Standardowy szablon systemu operacyjnego zbiera kilkadziesiąt wartości, z których w małej firmie działanie wywołuje kilka. Reszta obciąża bazę i rozmywa obraz.
Test, który stosujemy przy każdej pozycji przed jej włączeniem: napisz jednym zdaniem, co zrobi człowiek, który dostanie o tym alert o drugiej w nocy. Jeśli takiego zdania nie ma, pozycja zostaje jako dane historyczne, bez wyzwalacza.
źródło: pexels.com
Mogę Ci jakoś pomóc?
Wybór narzędzia jest w małej firmie decyzją wtórną wobec pytania, kto będzie odbierał alerty. Narzędzie ustala tylko, ile pracy trzeba włożyć, żeby ten ktoś dostawał sensowne wiadomości. Poniższa tabela pokazuje sytuację, w której każde z rozwiązań wygrywa jednoznacznie.
Rozwiązanie | Wygrywa, gdy | Przegrywa, gdy |
|---|---|---|
Zabbix u siebie | macie własne serwery, przełączniki i zasilanie awaryjne, kilkadziesiąt hostów i chcecie mieć dane u siebie, bez opłaty za monitorowaną maszynę | całe środowisko to trzy usługi w chmurze, a w firmie nie ma nikogo, kto zaloguje się do serwera |
Proste narzędzie do sprawdzania dostępności | pytanie brzmi wyłącznie „czy to odpowiada”, hostów jest kilka, a wdrożenie ma zająć popołudnie | zaczyna Was interesować, dlaczego coś zwolniło, i potrzebujecie historii do porównania z zeszłym tygodniem |
Usługa monitoringu w chmurze, rozliczana za host | nie macie własnej infrastruktury do postawienia serwera i akceptujecie, że dane o środowisku wychodzą na zewnątrz | hostów robi się kilkadziesiąt i opłata miesięczna zaczyna przekraczać koszt własnego wdrożenia |
Monitoring wbudowany w sprzęt lub serwer plików | chodzi o jedno urządzenie, które samo wysyła maila o awarii dysku | urządzeń jest więcej niż jedno i każde ma własny format powiadomień, własne konto i własną skrzynkę docelową |
Ostatni wiersz jest częstszy, niż się wydaje. Firma, która twierdzi, że nie ma monitoringu, zwykle ma go w czterech miejscach naraz. Serwer plików wysyła maile o dyskach, zasilacz awaryjny o zaniku napięcia, program do kopii o wyniku zadania, a firewall o aktualizacjach.
Każde z tych źródeł pisze na inny adres i w innym stylu, więc nie da się z tego zbudować ani jednego obrazu, ani jednej ścieżki reakcji. Sensem wdrożenia jest wtedy nie tyle zbieranie nowych danych, ile sprowadzenie istniejących do jednego kanału z jednym adresatem.
Zabbix wygrywa w tym zestawieniu głównie tam, gdzie liczba hostów rośnie, a środowisko jest mieszane. Nie ma opłaty za monitorowaną maszynę, radzi sobie z kilkoma lokalizacjami i pozwala opisać sprawdzenie usługi, o której żaden gotowy szablon nie słyszał, na przykład firmowego programu magazynowego. Płaci się za to pracą przy konfiguracji i tym, że ktoś musi utrzymać sam serwer monitoringu. Zakresy, w jakich to robimy, są opisane w usługach monitoringu .
Kolejność jest zawsze ta sama, a najciekawsze jest to, że dwa najważniejsze kroki nie są techniczne.
Spis tego, co w ogóle istnieje. Zaczyna się od listy maszyn, usług i urządzeń sieciowych. Ewidencja z księgowości praktycznie nigdy nie zgadza się z tym, co faktycznie stoi w szafie. Przy okazji tego kroku regularnie znajdują się rzeczy, o których nikt już nie pamiętał, że działają.
Ustalenie, kto jest adresatem. To krok, który klient musi wykonać sam i to on decyduje o powodzeniu całości. Potrzebne są nazwiska, telefony, godziny i zastępstwa. Nie „dział IT”, nie skrzynka ogólna, tylko konkretna osoba przy konkretnej klasie zdarzeń.
Instalacja i podłączenie hostów. Serwer, baza, agenty na maszynach, SNMP na przełącznikach, drukarkach i zasilaczach awaryjnych, sprawdzenia z zewnątrz dla usług dostępnych z internetu. Instalacja agenta nie wymaga restartu, więc ten etap idzie w normalnym dniu pracy.
Okres obserwacji, w którym nikt nie dostaje alertów. System zbiera dane i nie odzywa się do nikogo. Bez tego progi są zgadywaniem: nie wiadomo, czy obciążenie serwera o dwudziestej drugiej jest awarią, czy nocnym przeliczaniem raportów, które chodzi tam od czterech lat.
Progi, zależności i ścieżki powiadamiania. Progi ustawia się na danych z obserwacji, zależności mówią systemowi, że maszyny za padniętym przełącznikiem nie mają osobnych awarii. Ścieżka powiadamiania zamienia zdarzenie na wiadomość do konkretnego człowieka.
Przekazanie. Dokumentacja, dostępy i szkolenie tych, którzy będą z tego korzystać. Monitoring, którego nikt w firmie nie rozumie, zostaje wyłączony przy pierwszych porządkach i jest to całkowicie racjonalna decyzja z ich punktu widzenia.
Potem zaczyna się pierwszy miesiąc pracy z alertami i to jest część, której nie da się przeskoczyć. Opisujemy ją w następnej sekcji, bo to ona decyduje, czy pół roku później ktokolwiek jeszcze czyta te wiadomości.
Mogę Ci jakoś pomóc?
Etapy, wymagania sprzętowe i kwotę za tę pracę zbiera strona usługi wdrożenia Zabbiksa . Nie przepisujemy ich tutaj, bo cennik zmienia się szybciej niż ten tekst.
To jest sekcja, dla której powstał ten tekst. Wszystko wcześniejsze da się kupić za pieniądze albo pobrać za darmo. Tego nie.
Zacznijmy od rozróżnienia, które w rozmowach handlowych znika, a decyduje o wszystkim.
Każdy zna czujnik dymu w kuchni. Dobrze powieszony odzywa się raz na kilka lat i wtedy wszyscy wychodzą z mieszkania. Powieszony nad tosterem odzywa się przy każdym śniadaniu, więc po dwóch tygodniach ktoś wyjmuje z niego baterię, i to jest decyzja całkowicie rozsądna: urządzenie przestało nieść informację, a zaczęło nieść hałas. Problem w tym, że w dniu prawdziwego pożaru bateria dalej leży w szufladzie.
Alert ma adresata, termin i czynność do wykonania. Powiadomienie ma tylko treść.
Jeżeli osoba, która to dostała, nie wie, co ma teraz zrobić, to dostała powiadomienie, choćby w temacie wiadomości stało słowo krytyczny. Kanał pełen powiadomień jest czujnikiem nad tosterem: zostaje wyciszony w ciągu kilku tygodni i zabiera ze sobą wszystkie te wiadomości, które naprawdę wymagały reakcji. Cały ten tekst jest o tym, żeby czujnik wisiał we właściwym miejscu.
źródło: pexels.comDobrze ustawiony alert zawiera trzy rzeczy: co się stało, od kiedy i co z tym zrobić. Ostatnia część jest najczęściej pomijana i najbardziej kosztowna. Treść „PROBLEM: Zabbix agent is not available on SRV-MAG01” jest zrozumiała dla osoby, która postawiła ten monitoring, i bezużyteczna dla wszystkich pozostałych o trzeciej w nocy.
Dlatego przy każdym wyzwalaczu, który ma prawo obudzić człowieka, zapisujemy krótką instrukcję: co sprawdzić najpierw, co wolno zrestartować, kogo zawiadomić, jeśli to nie pomoże. Pięć minut po odebraniu alertu dyżurny ma być w połowie drogi do przyczyny, a nie w połowie drogi do zalogowania się do panelu.
Jest jeszcze decyzja, o której mało kto mówi wprost: nie każda awaria zasługuje na to, żeby kogoś budzić. Serwer plików, z którego nikt nie korzysta o trzeciej w nocy, może poczekać do siódmej. Zapełniający się dysk niemal zawsze może poczekać, bo alert przyszedł na kilka dni przed problemem. Wybór, co budzi, a co czeka do rana, robi się raz, na papierze, z klientem, i jest ważniejszy od jakiegokolwiek ustawienia w narzędziu.
System, który krzyczy o wszystkim, jest systemem, który się wycisza. To nie jest ryzyko teoretyczne, tylko domyślny los każdego wdrożenia zostawionego na ustawieniach z szablonu. Strojenie progów to jest właśnie przewieszanie czujnika znad tostera.
Mechanizm jest zawsze ten sam.
Mogę Ci jakoś pomóc?
Strojenie polega na czterech rzeczach i wykonuje się je na danych, a nie z głowy.
Po tym miesiącu liczba wiadomości spada do poziomu, przy którym każda z nich znaczy coś konkretnego. To jest właściwy moment na sprawdzenie, ile alertów faktycznie skończyło się działaniem człowieka, i ta proporcja, a nie liczba sama w sobie, mówi, czy monitoring jest dobrze ustawiony.
Zabbix ma własne pulpity i do pracy technika zwykle wystarczają. Grafana wchodzi wtedy, gdy pojawia się drugi odbiorca: właściciel, prezes albo kierownik, który ma wiedzieć, w jakim stanie jest firma, i nie ma zamiaru oglądać listy wyzwalaczy.
Te dwa ekrany różnią się pytaniem, na które odpowiadają. Technik pyta, co konkretnie się zepsuło i od kiedy. Osoba nietechniczna pyta, czy dziś trzeba się czymś zająć i czy sytuacja poprawia się, czy pogarsza, od zeszłego miesiąca. Wykres obciążenia procesora nie odpowiada na to drugie pytanie w żadnej konfiguracji kolorów.
Co działa na pulpicie dla osoby nietechnicznej:
Czego tam nie ma: czterdziestu wykresów obok siebie, wartości bez jednostki i niczego, co wymaga tłumaczenia przy każdym spojrzeniu.
źródło: pexels.comJest jedna pułapka, którą warto nazwać wprost, bo powtarza się w każdej firmie, która kupiła ekran na ścianę. Pulpit nie jest kanałem alertów. Ekran w korytarzu działa w godzinach, w których ktoś przez ten korytarz przechodzi, a awarie mają brzydki zwyczaj zdarzania się w nocy i w weekend. Pulpit służy do oglądania stanu i do rozmowy o budżecie, alert służy do obudzenia człowieka. Mylenie ich kończy się dwoma zdaniami po awarii: „przecież to było widać na ekranie” oraz „nikt na niego wtedy nie patrzył”.
Jak budujemy takie zestawy i dla kogo osobno, opisuje strona o dashboardach w Grafanie .
Zabbix jest wolnym oprogramowaniem i od wersji 7.0 rozprowadza się go na licencji AGPL w wersji 3 (wcześniej była to GPL w wersji 2). Dla firmy, która stawia go u siebie i używa do pilnowania własnych serwerów, praktyczna konsekwencja jest żadna: wolno, bez opłat, bez limitu monitorowanych maszyn. Warunki tej licencji zaczynają dotyczyć dopiero tego, kto zmieniałby kod i udostępniał zmienioną wersję innym, także przez sieć. Firma na 5 do 50 stanowisk tego nie robi.
Rachunek robią więc cztery inne pozycje i żadnej z nich nie ma w żadnym cenniku producenta:
Pozycja | Dlaczego kosztuje | Kiedy zaskakuje |
|---|---|---|
Maszyna pod serwer monitoringu | musi stać poza tym, co monitoruje, inaczej jedna awaria zabiera usługę i czujnik naraz | przy pierwszej poważnej awarii, gdy okazuje się, że monitoring stał na tym samym hoście |
Dysk pod bazę | baza monitoringu pisze bez przerwy, całą dobę, i rośnie z każdym dołożonym sprawdzeniem | po pół roku, gdy dysk się zapełnia i monitoring zaczyna gubić własne dane |
Praca przy strojeniu | progi z szablonu producenta nie znają Waszego środowiska, a wartość powstaje dopiero po ich dopasowaniu | w pierwszym miesiącu, opisanym wyżej |
Dyżur poza godzinami pracy | czuwa system, reaguje człowiek, a człowiek ma godziny | przy pierwszym zdarzeniu w piątek o dwudziestej drugiej |
Pułapka, która nie jest kosztem, ale bywa droższa od wszystkich czterech naraz: darmowa licencja bywa argumentem za monitorowaniem wszystkiego. Każde dołożone sprawdzenie jest bezpłatne, więc nikt go nie waży, a rachunek przychodzi w postaci bazy, która puchnie, i skrzynki, w której nikt już nie szuka.
Kwot za naszą pracę nie ma w tym akapicie celowo. Stoją na stronach usług, razem z zakresem, i tam się je sprawdza, bo cennik zmienia się szybciej niż artykuł na blogu.
Poniższe błędy widujemy najczęściej i każdy z nich kosztuje więcej niż praca, której wymagało jego uniknięcie.
Błąd | Czym się kończy |
|---|---|
Progi zostawione na wartościach domyślnych z szablonu | fala wiadomości w pierwszym tygodniu, reguła przenosząca je do osobnego katalogu w drugim |
Alerty wysyłane na skrzynkę ogólną | nikt nie czuje się adresatem, zdarzenie z piątku czeka do poniedziałku |
Alert bez informacji, co z tym zrobić | dyżurny w nocy budzi kolejną osobę, żeby zapytać, czy to ważne |
Brak okien serwisowych | zaplanowany restart wygląda jak awaria i budzi trzy osoby |
Serwer monitoringu na tej samej maszynie co monitorowane usługi | jedna awaria zabiera jednocześnie usługę i czujnik, który miał o niej powiadomić |
Tylko sprawdzenia od środka, bez spojrzenia z zewnątrz | serwer widzi siebie jako sprawny, a klient nie widzi strony |
Brak zależności między hostami | jeden padnięty przełącznik generuje kilkanaście osobnych alertów naraz |
Dysk pod bazę policzony na oko | baza puchnie, monitoring zaczyna gubić własne dane i przestaje być dowodem na cokolwiek |
Nikt nie pilnuje samego monitoringu | serwer stoi od miesiąca, a cisza w skrzynce zostaje wzięta za spokój |
Ostatni wiersz zasługuje na osobne zdanie, bo jest jedynym błędem, który udaje sukces. Brak alertów znaczy albo, że nic się nie dzieje, albo że nic nie działa, a z zewnątrz obie sytuacje wyglądają identycznie. Dlatego monitoring musi mieć czujnik skierowany na siebie: sprawdzenie serwera monitoringu z zewnątrz, wiadomość kontrolną wysyłaną cyklicznie albo prostą regułę, że brak sygnału przez określony czas sam jest zdarzeniem. Bez tego pierwsze pytanie po awarii brzmi, kiedy właściwie ten monitoring przestał działać, i zwykle nie ma na nie odpowiedzi.
Warto też pamiętać, że monitoring jest warstwą obok innych, a nie zamiast nich. Sam meldunek o nietypowym ruchu nie zatrzyma niczego, od tego jest firewall , rozejściu się infekcji po sieci przeciwdziała segmentacja , a odtworzeniem danych zajmuje się kopia zapasowa, którą monitoring jedynie sprawdza.
Osobna sekcja, bo tekst o narzędziu bez ani jednego zdania krytycznego czyta się jak materiał producenta.
Kiedy odradzamy samo wdrożenie, są natomiast trzy układy, które widać już na pierwszym spotkaniu. Firma, której całe środowisko to kilka usług w chmurze i żadnego własnego serwera, dostanie więcej pożytku z prostego sprawdzania dostępności niż z własnej instalacji, którą trzeba utrzymywać. Firma planująca w najbliższych miesiącach przeprowadzkę środowiska powinna wdrożyć monitoring po przeprowadzce, a nie przed. I przypadek najważniejszy: firma, która nie potrafi wskazać ani jednej osoby odbierającej alerty, nie kupuje monitoringu, tylko kupuje sobie nowy kanał, który za miesiąc wyciszy.
W tym trzecim przypadku rozmowa nie kończy się na „nie”. Kończy się pytaniem, czy chcecie, żeby te alerty odbierał ktoś z zewnątrz, i to jest zupełnie inna usługa niż wdrożenie.
Licencja tak, wdrożenie nie. Płacicie za maszynę, na której stoi serwer, za dysk pod bazę piszącą bez przerwy i za czas człowieka, który dobierze progi oraz ścieżki powiadamiania. Samo uruchomienie usługi to kilka godzin, a wartość powstaje w tygodniach strojenia po tym uruchomieniu.
Liczba sama w sobie nic nie mówi, znaczenie ma udział alertów, po których ktoś coś zrobił. Jeśli dyżurny kasuje większość wiadomości bez działania, progi są za czułe albo zdarzenie w ogóle nie zasługuje na alert. Zdrowy monitoring odzywa się rzadko i za każdym razem ma rację.
Ktoś musi, inaczej nocny alert jest tylko zapisem w dzienniku. Układy są trzy: wskazana osoba w firmie z listą czynności do wykonania, dyżur po stronie dostawcy jako osobno płatna usługa. Alternatywa to świadoma decyzja, że w nocy nie reagujemy i zdarzenia czekają do rana. Trzeci wariant też jest wyborem.
Alert ma adresata, termin i czynność do wykonania. Powiadomienie ma tylko treść. Test jest jeden: jeśli odbiorca nie wie, co ma teraz zrobić, dostał powiadomienie, choćby nadawca nazywał to alertem. Działa tu ta sama zasada co przy czujniku dymu powieszonym nad tosterem. Kanał, w którym większość wiadomości nie wymaga działania, zostanie wyciszony razem z tymi ważnymi - i to przez rozsądnych ludzi, a nie przez niedbałych.
Do pracy technika zwykle tak, bo Zabbix ma własne pulpity i to w nim ustawia się progi oraz akcje. Grafanę dokłada się wtedy, gdy odbiorcą ekranu jest ktoś, kto nie chce oglądać wyzwalaczy, albo gdy dane z monitoringu trzeba pokazać razem z danymi z innych systemów firmy.
Zauważy skutki, nie zamiar. Nietypowy ruch w nocy, seria nieudanych logowań, nagły przyrost zapisu na dysku albo usługa restartująca się co kwadrans są widoczne w metrykach i warto mieć na nie wyzwalacze. To jednak warstwa uzupełniająca, a nie zamiennik ochrony stacji roboczych ani zapory.
Zwykle tak i zwykle taniej niż wdrożenie od nowa, bo dane już się zbierają. Praca polega na uporządkowaniu grup i szablonów, zmniejszeniu liczby wyzwalaczy, dopisaniu zależności między hostami i ustaleniu od nowa, kto jest adresatem którego zdarzenia. Kanał powiadomień trzeba wtedy założyć nowy.
Jeśli macie już Zabbiksa w małej firmie, a alerty przestały do kogokolwiek docierać, zajmiemy się strojeniem tego, co jest. Wymiana narzędzia jest przy tym potrzebna rzadziej, niż się wydaje.
Umówcie 30 minut rozmowy o Waszym monitoringu i powiedzcie nam trzy rzeczy: ile macie serwerów i urządzeń sieciowych, gdzie dziś przychodzą powiadomienia i kto ostatnio zareagował na jedno z nich. Trzecia odpowiedź mówi zwykle najwięcej.
Pracujemy w całej Polsce, także na miejscu. Firmy z Lubuskiego obsługujemy z biura głównego w Gorzowie Wielkopolskim i tam też realizujemy usługi lokalnie .
Mogę Ci jakoś pomóc?
Zestaw zmienia się codziennie, więc przy kolejnej wizycie zobaczysz inny wycinek bloga.
Podatność CVE-2026-20245 w konsolach Cisco Catalyst SD-WAN trafiła do katalogu CISA KEV, bo atakujący naprawdę z niej korzystają. Z tego tekstu dowiesz się, na czym polega błąd, jak wyglądał opisany przez Mandiant atak i jakie kroki firma musi wykonać przed wgraniem łatki.
Czytaj artykułCISA dopisała CVE-2026-20316 do katalogu aktywnie wykorzystywanych podatności. Chodzi o statyczne dane logowania wbudowane w interfejs webowy Cisco Secure Firewall Management Center. Tekst wyjaśnia mechanizm luki, powody pilności mimo średniej oceny CVSS i kolejność działań dla firmy.
Czytaj artykułPodatność w systemach Cisco SD-WAN pozwala ominąć uwierzytelnianie i przejąć kontrolę nad konfiguracją całej sieci. Według CISA była wykorzystywana jako zero-day, a agencja dała dwa dni na reakcję. Poniżej mechanizm ataku i lista działań.
Czytaj artykułKrótka rozmowa wystarczy, żeby ocenić zakres prac i podać widełki kosztu. Bez zobowiązań.
Klikając „Akceptuję”, zgadzasz się na przechowywanie plików cookie przez UXU w celu poprawy działania strony, analizy i wsparcia działań marketingowych.