Uptime Kuma pod NIS2: status page, powiadomienia i dowód SLA

Klient dzwoni w poniedziałek rano: „wasz system znowu nie działał w piątek wieczorem, chcemy rekompensatę”. Masz dwie opcje. Możesz grzebać w logach serwera i próbować odtworzyć, co się stało, albo otworzyć jeden dashboard i pokazać: awaria trwała 6 minut, o 20:14 dostałeś powiadomienie na Telegramie, o 20:19 usługa wróciła. W świecie NIS2, gdzie od audytora i od klienta coraz częściej pada pytanie „a jak to udowodnicie”, ta druga opcja to nie wygoda. To konkretny dowód.

W poprzednim wpisie o podstawach Uptime Kuma pokazaliśmy, jak postawić monitoring dostępności za 0 zł. Dziś idziemy krok dalej: jak zbudować z niego narzędzie, które broni Cię przed roszczeniami klientów i pytaniami audytora, zamiast tylko wyświetlać zielone kropki na ekranie w serwerowni.

Status page: wewnętrzna kontra publiczna

Uptime Kuma pozwala postawić dowolną liczbę status page’ów, każdy z innym zestawem monitorów i innym poziomem szczegółowości. W praktyce warto rozdzielić dwa scenariusze.

Status page wewnętrzna, dostępna tylko z sieci firmowej albo po VPN, pokazuje wszystko: nazwy serwerów, adresy IP, porty, czasy odpowiedzi w milisekundach. To narzędzie dla Twojego zespołu albo administratora klienta, kiedy trzeba szybko sprawdzić, co konkretnie leży.

Status page publiczna to zupełnie inna rzecz. Pokazujesz na niej usługi z perspektywy klienta: „Strona www”, „Poczta firmowa”, „System CRM”, bez adresów IP i szczegółów infrastruktury, które nikomu z zewnątrz nie powinny być znane. Dodajesz krótki opis, logo klienta, i tyle. Taką stronę możesz udostępnić klientowi jako element umowy SLA: zamiast obiecywać dostępność na słowo, dajesz mu adres, pod którym sam sprawdzi historię. To zmienia rozmowę o reklamacjach z „ja twierdzę, ty twierdzisz” na wspólne patrzenie w te same dane.

Jakie monitory faktycznie mają sens

Nie chodzi o to, żeby monitorować wszystko, co się da. Chodzi o pokrycie tego, co realnie wpływa na działanie firmy klienta i co pojawi się w rozmowie o SLA.

• HTTP/HTTPS strony i aplikacji: sprawdzasz nie tylko czy serwer odpowiada, ale czy zwraca kod 200 i oczekiwaną treść. Monitor typu „keyword” wychwyci sytuację, w której serwer żyje, ale aplikacja pokazuje błąd 500 zamiast strony głównej.
• Port TCP: dla usług bez interfejsu www, na przykład bazy danych, serwera RDP czy własnej aplikacji na niestandardowym porcie. Sprawdzasz samo otwarcie połączenia.
• Ping (ICMP): podstawowa dostępność hosta w sieci, przydatny dla urządzeń sieciowych, routerów, drukarek serwerowych.
• Wygasające certyfikaty SSL: Uptime Kuma sam liczy dni do wygaśnięcia certyfikatu monitorowanej domeny i ostrzega z wyprzedzeniem. To jeden z najtańszych sposobów, żeby nigdy więcej nie usłyszeć od klienta „strona pokazuje błąd bezpieczeństwa”.
• Dostępność poczty: monitor SMTP albo IMAP sprawdzający, czy serwer pocztowy w ogóle przyjmuje połączenia. Awaria poczty firmowej boli klienta bardziej niż wielu administratorom się wydaje, bo blokuje całą komunikację z ich klientami.
• DNS: monitor typu DNS sprawdza, czy domena w ogóle się rozwiązuje z zewnątrz, co bywa pierwszym objawem problemów u rejestratora albo w konfiguracji strefy.

Dla jednego typowego klienta MŚP to zwykle 8-15 monitorów, nie setki. Kluczowe jest pokrycie usług, które są wymienione w umowie SLA albo które klient uzna za „krytyczne”, jeśli zapytasz go wprost.

Progi i powiadomienia: żeby wiedzieć zanim zadzwoni klient

Domyślne ustawienia Uptime Kuma sprawdzają większość monitorów co 60 sekund i uznają usługę za niedostępną po jednym nieudanym sprawdzeniu. W praktyce warto to dostroić, żeby nie zalewać się fałszywymi alarmami przy chwilowym zacięciu sieci.

• Ustaw „Retries” na 2-3 przed oznaczeniem usługi jako DOWN, z odstępem 20-30 sekund między próbami. Jedno zerwane połączenie nie powinno budzić nikogo o 3 w nocy.
• Dla usług krytycznych (strona sprzedażowa, system płatności) skróć interwał sprawdzania do 30 sekund, żeby czas wykrycia awarii nie zjadał Ci budżetu dostępności z SLA.
• Certyfikaty SSL ustaw na ostrzeżenie 14 i 7 dni przed wygaśnięciem, nie w dniu wygaśnięcia.

Kanały powiadomień warto rozdzielić według wagi zdarzenia. Mail sprawdza się jako archiwum, do którego zawsze można wrócić i pokazać datę zgłoszenia, ale nikt nie czyta go w czasie rzeczywistym. Telegram (własny bot, kilka minut konfiguracji) daje powiadomienie na telefon w kilka sekund od wykrycia awarii, co w małym zespole IT jest często wystarczające. Webhook do Slacka albo Teams sprawdza się tam, gdzie zespół i tak żyje na co dzień w tym narzędziu, bo alert trafia od razu do kanału, gdzie ktoś już go zobaczy przy okazji innej pracy. W praktyce dobrze skonfigurowany zestaw to Telegram dla dyżurnego technika plus webhook na kanał zespołowy, a mail jako zapasowy log.

Twardy dowód SLA, nie deklaracja

Tu wracamy do sedna tego wpisu. Kiedy podpisujesz z klientem umowę SLA, zwykle pojawia się tam liczba w stylu „99,5% dostępności miesięcznie”. Bez narzędzia, które to mierzy, ta liczba jest tylko obietnicą. Uptime Kuma przelicza ją automatycznie: dla każdego monitora widzisz procent uptime za 24 godziny, 30 dni i rok, oraz pełną historię incydentów z dokładnymi znacznikami czasu.

Przy audycie NIS2 albo przy rozmowie o rozszerzeniu umowy to konkretny argument: nie „u nas rzadko coś pada”, tylko wykres z ostatnich 90 dni i lista trzech incydentów, każdy poniżej 10 minut. Kiedy klient kwestionuje reklamację, eksportujesz historię danego monitora i pokazujesz dokładny czas trwania awarii, zamiast się kłócić o to, co kto pamięta. To samo działa w drugą stronę: jeśli faktycznie nie dotrzymałeś SLA w danym miesiącu, dane są jednoznaczne i łatwiej ustalić rekompensatę bez sporu.

Czego Uptime Kuma nie zrobi za Ciebie

Trzeba to powiedzieć wprost, bo łatwo wpaść w pułapkę traktowania jednego narzędzia jako całego monitoringu. Uptime Kuma odpowiada na pytanie „czy usługa działa”, nie na pytanie „dlaczego działa wolno” ani „kto próbował się do niej dostać”.

• 🚩 Nie zastąpi SIEM: nie analizuje logów bezpieczeństwa, nie koreluje zdarzeń z różnych systemów, nie wykryje próby włamania ani anomalii w ruchu.
• 🚩 Nie mierzy wydajności w głębi: powie Ci, że strona odpowiada w 300 ms, ale nie powie, że baza danych dławi się na konkretnym zapytaniu albo że serwer za chwilę skończy pamięć RAM.
• 🚩 Nie robi alertów na metryki systemowe: obciążenie CPU, wolne miejsce na dysku, zużycie pamięci to zadanie dla osobnego narzędzia.

Dlatego Uptime Kuma dobrze działa jako pierwsza warstwa stosu, ta która odpowiada za czysty widok „działa / nie działa” i dowód dla klienta, a obok niej stawia się narzędzie do monitoringu wydajności i zasobów serwera oraz, w firmach z wyższymi wymaganiami, właściwy SIEM do analizy bezpieczeństwa. Jedno narzędzie pilnuje dostępności na zewnątrz, drugie pilnuje kondycji wewnątrz, trzecie pilnuje bezpieczeństwa. Razem dają pełny obraz, osobno każde ma swoją lukę.

Co dalej w cyklu

W kolejnym wpisie zejdziemy głębiej w tę drugą warstwę: Zabbix w praktyce, czyli konkretne szablony, wyzwalacze i eskalacje, których naprawdę używamy u klientów, a nie tylko te z domyślnej instalacji.

W Zjawa.IT stawiamy monitoring dostępności pod klucz: od instalacji Uptime Kuma i doboru monitorów, przez konfigurację powiadomień, po status page gotową do pokazania klientowi jako dowód SLA. Jeśli chcesz mieć twarde dane zamiast domysłów przy następnej awarii, Napisz do nas.