🇬🇧 Go to english version of this post / Przejdź do angielskiej wersji tego wpisu
W tytule chciałem ująć to krótko, więc użyłem słowa usług, co w tym miejscu chciałbym rozszerzyć jako strony, aplikacje i serwery, a w zasadzie praktycznie wszystko co jest dostępne w sieci i może z jakiegoś powodu nie działać. Do monitorowania właśnie tych rzeczy służy narzędzie Uptime Kuma. Jest to rozwiązanie self-hosted, które jest szalenie proste w uruchomieniu i późniejszej obsłudze, a przy tym niezmiernie funkcjonalne.
Jak uruchomić Uptime Kuma
Uruchomienie Uptime Kuma na swoim serwerze jest możliwe na wiele sposobów. Jednym z nich jest dostępność tego narządzia w bibliotece aplikacji Yunohost. W tym wpisie pokaże jednak jak uruchomić to narzędzie jako kontener Docker’a, a konkretnie wykorzystam do tego ostatnio opisany przeze mnie Portainer.
W pierwszej kolejności należy utworzyć wymagany wolumen. W dokumentacji Uptime Kuma podane jest, że trzeba podmontować ścieżkę /app/data. Dlatego utwórzmy wolumen o nazwie uptime-kuma_app_data.
Możemy przejść do tworzenia kontenera:
- Name – Uptime-kuma
- Image – louislam/uptime-kuma:latest
- Manual network port publishing (host -> container):
- 3001 -> 3001
- Volumes (container -> volume):
- /app/data -> uptime-kuma_app_data – local
- Restart policy – Unless stopped
Wszystkie te ustawienia potwierdzamy przyciskiem Deploy the container. Jak ktoś nie lubi Portainer’a to identyczny skutek osiągnąć można stosując poniższe komendy:
docker volume create uptime-kuma_app_data
docker run -d \
-p 3001:3001 \
-v uptime-kuma_app_data:/app/data \
--name Uptime-kuma \
--restart unless-stopped \
louislam/uptime-kuma:latest
Tak uruchomiona usługa dostępna będzie pod adresem:
http://localhost:3001
Po wejściu na podany adres przywita nas standardowy instalator, w którym musimy określić język w jakim chcemy widzieć interfejs, nazwę i hasło dla administratora.
Podstawowa obsługa
Cała zasada działania usługi Uptime Kuma polega na tworzeniu monitorów, których zadaniem jest cykliczne badanie czy wskazana usługa, aplikacja, serwer czy nawet kontener Docker’a pracuje prawidłowo, tj. działa czy też jak kto woli – żyje. Jest to idea zarówno prosta jak i szalenie funkcjonalna. Stworzę zatem taki przykładowy monitor, aby pokazać jak to działa.
Najbardziej podstawowa funkcja jaka przyszła mi do głowy to utworzenie monitora, który będzie sprawdzał czy mój blog działa i ma się dobrze. Naciskamy przycisk Dodaj monitor i następnie w wyświetlonym kreatorze wybieramy Rodzaj monitora jako HTTP(s), nadajemy mu nazwę np. Tomasz Dunia Blog i wprowadzamy URL https://blog.tomaszdunia.pl, a resztę parametrów możemy zostawić jako domyślne. Chęć utworzenia monitora potwierdzamy przyciskiem Zapisz.
Tak utworzony monitor wykonuje bardzo proste zadanie. W interwale co 60 sekund odwiedza podany adres strony i pobiera nagłówek HTTP, w którym znajduje się kod statusu. Otrzymanie kodu zawierającego się w zakresie 200-299 oznacza, że strona działa prawidłowo. Ten fakt jest zapisywany w bazie danych i monitor czeka kolejne 60 sekund, aby znowu powtórzyć analogiczne działanie i tak w kółko. Zebrane dane prezentowane są w sposób pokazany na poniższym zrzucie ekranu.
Jak widać podstawowa informacja to aktualny status strony oraz pasek pokazujący zielone kreski (lub czerwone, gdy występowały jakieś przerwy w działaniu) informujące o wcześniejszych statusach. Do tego liczona i agregowana jest długość odpowiedzi strony (wraz z wykresem jak kształtował się w poprzednich iteracjach) oraz wyliczany jest średni czas pracy.
Oczywiście pokazałem jedynie podstawowe, najprostsze zastosowanie. Uptime Kuma pozwala na wiele więcej. Można na przykład:
- zmienić częstotliwość sprawdzania,
- zmienić ilość prób jakie mają być podjęte przed uznaniem porażki,
- określić czas żądania, po którym uznajemy, że już nie otrzymamy odpowiedzi i przestajemy na nią czekać,
- włączyć powiadomienia informujące o tym, że monitorowana usługa nie działa, co możemy zrealizować przez ogromną ilość obsługiwanych przez Uptime Kuma sposobów, jak np. wysyłanie powiadomień na telefon przez aplikacje do tego służące czy też chociażby komunikatory jak Telegram, Discord czy Signal,
- określić proxy przez które mają być wysyłane zapytania,
- określić metodę, a może raczej typ, zapytania jakie ma zostać wysłane, kodowanie treści, treść i nagłówek zapytania,
- określić metodę uwierzytelnienia jakie ma zostać wykorzystane, aby uzyskać dostęp do monitorowanego zasobu,
- poprosić o sprawdzenie czy certyfikat SSL jest aktualny,
- określić ile maksymalnie przekierowań jest dozwolonych (szczególnie istotne, gdy sprawdzamy strony, które przed wyświetleniem swojej zawartości przepuszczają nas przez niezłą pętlę przekierowań),
- określić akceptowalny kody statusu (nie musi to być zakres 200-299),
- grupować monitory,
- tworzyć opisy monitorów,
- dodawać tagi dla monitorów.
Jest trochę tych ustawień zaawansowanych, prawda? A wymieniłem tylko te dostępne dla rodzaju monitora HTTP(s). Tych rodzajów jest o wiele więcej, ale nie będę ich wszystkich tutaj omawiał.
Podpowiedź na koniec
Uptime Kuma to niewątpliwie bardzo przydatne narzędzie! Jednakże ma jedną zasadniczą wadę. Jeżeli na swojej stronie prowadzisz statystyki odwiedzin to przez monitorowanie mogą one zostać zaburzone. Jak to? Zobacz, że domyślny monitor realizuje swoją pracę, poprzez odwiedzanie strony, dokładnie co 60 sekund. To aż 60 razy na godzinę i 1440 razy na dobę. Każde takie działanie wygląda i jest kalkulowane w statystykach jak normalne odwiedziny strony, np. przez czytelnika bloga. Na bardzo popularnych stronach to może być w ogóle niezauważalna kropla w morzu, ale na takich niszowych jak mój blog stanowiłoby to sporą część zliczonych odwiedzin. Pocieszające jest to, że w większości przypadków da się temu zaradzić! Ja na swoim blogu jako wtyczkę od statystyk wykorzystuję Independent Analytics. To dlaczego wybrałem tę konkretną wtyczkę opisałem tutaj. Piszę o tym dlatego, że ma ona specjalną opcję, dzięki której mogę wyłączyć odwiedziny z określonego adresu IP ze statystyk. W praktyce powinno się tam podać adres IP serwera, na którym uruchomiliśmy Uptime Kuma i po sprawie. Wierzę, że inne narzędzia do prowadzenia statystyk również posiadają taką funkcję, której należy poszukać w ich ustawieniach. Istotne jest jedynie, aby wyłączyć (po ang. exclude) dany adres IP ze statystyk, a nie całkowicie zablokować mu dostęp do strony, bo wtedy monitor Uptime Kuma przestanie działać.
Pingback: Uptime Kuma – monitoring tool for services [ENG 🇬🇧] – Tomasz Dunia Blog
SpeX
Jestem ciekaw, czy da się postawić to w środowisku multinode. Gdzie mamy lokalny (in-house) i zdalny (vps) monitoring tych samych targetów.
Tomasz Dunia
Nie wiem czy dobrze zrozumiałem, ale uptime kuma może monitorować usługi zarówno w sieci lokalnej jak i zewnętrzne (mające dostęp z internetu) i jeżeli to wystawisz na jakimś porcie zewnętrznym to normalnie podstęp do wyników będziesz mieć z zewnątrz też
SpeX
Nie w sensie mieć dwie kumy, jedna lokalna która sprawdza czy usługa działa pod IP 192.168.*.*, a druga kuma która sprawdza z poziomu sieci globalne czy usługa przez mnie wystawiona działa online. Bo mogło mi jakieś HA proxy paść lub konfiguracja DNS zepsułem.
Tomasz Dunia
To nie wystarczy wtedy jedna UK, która będzie sprawdzać na dwóch adresach? Mogła by przecież pingować adres lokalny i ten wystawiony na zewnątrz, co zachowywało się jak kuma działająca z zewnątrz.