Dlaczego monitoring kontenerów Docker jest niezbędny • Jak Uptime Kuma monitoruje kontenery Docker • Konfiguracja Docker Host w Uptime Kuma — krok po kroku • Tworzenie monitora Docker Container — krok po kroku • Docker socket — konfiguracja i bezpieczeństwo • Docker Health Check — zaawansowane monitorowanie stanu kontenerów • Co monitorować w kontenerach — statusy, restarty, zasoby • Docker Compose — praktyczne przykłady konfiguracji • Łączenie monitoringu Docker z HTTP — pełna obserwacja stosu • Best practices i najczęstsze błędy • Podsumowanie • Najczęściej zadawane pytania
Docker zrewolucjonizował sposób, w jaki wdrażamy i zarządzamy aplikacjami. Kontenery pozwalają na izolację usług, łatwe skalowanie i powtarzalność środowisk — od developmentu po produkcję. Według raportu Datadog z 2025 roku, ponad 65% organizacji korzysta z Dockera w środowiskach produkcyjnych, a średni stos kontenerowy w firmie liczy od kilkunastu do kilkuset działających kontenerów.
Problem pojawia się wtedy, gdy kontenery zaczynają żyć własnym życiem. Kontener może się zatrzymać z powodu błędu aplikacji, OOM Killer może go ubić przy zbyt niskim limicie pamięci, restart policy może powodować nieskończoną pętlę restartów, a health check może wskazywać stan unhealthy, mimo że kontener formalnie „działa". Bez monitoringu te problemy pozostają niewidoczne — aż do momentu, gdy użytkownik końcowy zgłosi awarię.
Tradycyjne podejście do monitoringu Docker opiera się na ciężkich rozwiązaniach: Prometheus + cAdvisor + Alertmanager + Grafana. To potężny stos, ale wymaga znacznego nakładu pracy przy konfiguracji, utrzymaniu i zrozumieniu PromQL. Dla wielu administratorów — szczególnie tych zarządzających mniejszymi środowiskami, homelabami lub pojedynczymi serwerami produkcyjnymi — jest to przerost formy nad treścią.
Uptime Kuma oferuje prostszą, ale niezwykle skuteczną alternatywę. Wbudowany typ monitora Docker Container pozwala na bezpośrednie monitorowanie stanu kontenerów przez Docker socket — bez dodatkowych agentów, eksporterów czy złożonej konfiguracji. W połączeniu z monitorami HTTP, TCP i DNS, Uptime Kuma zapewnia pełny obraz zdrowia Twojego stosu kontenerowego — od warstwy infrastruktury po warstwę aplikacji.
/var/run/docker.sock) oraz Docker TCP z certyfikatami TLS — co pozwala monitorować zarówno lokalne, jak i zdalne hosty Docker.
Zanim przejdziemy do praktycznej konfiguracji, warto zrozumieć mechanizm, dzięki któremu Uptime Kuma komunikuje się z Dockerem. Wiedza o architekturze pozwoli Ci lepiej diagnozować problemy i podejmować świadome decyzje dotyczące bezpieczeństwa.
Docker działa w modelu klient-serwer. Docker Engine (daemon dockerd) udostępnia REST API, które pozwala na zarządzanie kontenerami, obrazami, sieciami i wolumenami. Każde polecenie docker ps, docker inspect czy docker stats w rzeczywistości wykonuje wywołanie HTTP do tego API.
Uptime Kuma wykorzystuje dokładnie ten sam mechanizm. Gdy tworzysz monitor typu Docker Container, Uptime Kuma w cyklicznych interwałach odpytuje Docker Engine API o stan wskazanego kontenera. Konkretnie wykonuje zapytanie do endpointu /containers/{id}/json, który zwraca pełny opis kontenera — w tym jego status, health check, czas uruchomienia i konfigurację.
Docker Engine API jest domyślnie dostępne przez Unix socket pod ścieżką /var/run/docker.sock. To plik specjalny w systemie plików, który umożliwia komunikację IPC (Inter-Process Communication) bez użycia sieci. Jest to jednocześnie najbezpieczniejsza i najwydajniejsza metoda połączenia.
Alternatywnie Docker Engine może nasłuchiwać na porcie TCP (domyślnie 2375 bez TLS lub 2376 z TLS). Ta metoda jest przydatna, gdy Uptime Kuma i Docker Engine działają na różnych maszynach — na przykład gdy masz jedną centralną instancję monitoringu nadzorującą kontenery na wielu serwerach.
| Metoda połączenia | Adres | Bezpieczeństwo | Zastosowanie |
|---|---|---|---|
| Unix socket | /var/run/docker.sock | Lokalne — dostęp przez uprawnienia pliku | Uptime Kuma na tym samym hoście co Docker |
| TCP bez TLS | tcp://host:2375 | Brak szyfrowania — tylko sieć lokalna | Testowe środowiska, sieci izolowane |
| TCP z TLS | tcp://host:2376 | Szyfrowanie + certyfikaty klienta | Zdalne monitorowanie przez sieć |
W Uptime Kuma połączenie z Docker Engine jest zarządzane przez obiekt o nazwie Docker Host. Docker Host definiuje sposób połączenia (socket lub TCP), dane uwierzytelniające (certyfikaty TLS) i nazwę identyfikacyjną. Jeden Docker Host może być używany przez wiele monitorów Docker Container — co oznacza, że konfigurujesz połączenie raz, a potem tworzysz monitory dla poszczególnych kontenerów.
Możesz zdefiniować wiele Docker Hostów — na przykład serwer-web (socket lokalny), serwer-db (TCP z TLS do zdalnego hosta) i homelab-nas (TCP do NAS-a). Każdy monitor Docker Container wskazuje, z którego Docker Hosta ma korzystać.
Pierwszym krokiem do monitorowania kontenerów jest dodanie Docker Hosta w Uptime Kuma. Docker Host to definicja połączenia z Docker Engine — bez niego nie będziesz mógł tworzyć monitorów typu Docker Container.
1.
Zaloguj się do panelu Uptime Kuma. Przejdź do Settings (ikona koła zębatego w lewym dolnym rogu), a następnie wybierz zakładkę Docker Hosts. Zobaczysz listę skonfigurowanych hostów Docker — na początku będzie pusta.
2.
Kliknij przycisk Setup Docker Host. Otworzy się formularz konfiguracji z następującymi polami:
3.
Jeśli Uptime Kuma działa na tym samym serwerze co Docker Engine (lub ma dostęp do Docker socketa), wybierz Socket i podaj ścieżkę:
/var/run/docker.sockTo domyślna ścieżka Docker socketa na systemach Linux. Na macOS ścieżka to /var/run/docker.sock (przez Docker Desktop), a na Windows //./pipe/docker_engine.
4.
Dla zdalnych hostów Docker wybierz TCP i podaj adres w formacie:
https://10.10.10.50:2376Przy połączeniu TCP z TLS musisz dostarczyć trzy certyfikaty: CA Cert (certyfikat autorytetu certyfikacji), Cert (certyfikat klienta) i Key (klucz prywatny klienta). Wklej ich zawartość w odpowiednie pola formularza.
5.
Kliknij Test, aby zweryfikować, że Uptime Kuma może połączyć się z Docker Engine. Jeśli test zakończy się sukcesem, zobaczysz zielony komunikat potwierdzający. Kliknij Save, aby zapisać konfigurację Docker Hosta.
1.
Kliknij Add New Monitor w panelu głównym. Z listy rozwijanej Monitor Type wybierz Docker Container.
2.
Wypełnij formularz monitora:
nginx-proxy) lub jego ID. Uptime Kuma wyświetli listę dostępnych kontenerów po wybraniu Docker Hosta — możesz wybrać z listy rozwijanej3.
Skonfiguruj częstotliwość monitorowania:
4.
W sekcji Notifications wybierz skonfigurowane kanały powiadomień (Telegram, Discord, e-mail, Slack lub dowolny z 91 obsługiwanych serwisów). Możesz przypisać wiele kanałów do jednego monitora — na przykład Telegram dla szybkich alertów i e-mail dla audytu.
5.
Kliknij Save. Monitor natychmiast rozpocznie sprawdzanie stanu kontenera. Na dashboardzie zobaczysz zielony status UP, jeśli kontener działa poprawnie, lub czerwony DOWN, jeśli kontener jest zatrzymany, nie istnieje lub zwraca status unhealthy.
EACCES: permission denied, oznacza to, że proces Uptime Kuma nie ma uprawnień do odczytu Docker socketa. Upewnij się, że użytkownik uruchamiający Uptime Kuma jest w grupie docker, lub zamontuj socket z odpowiednimi uprawnieniami. W kontenerze Docker rozwiązaniem jest montowanie socketa z flagą :ro (read-only) i uruchomienie kontenera z odpowiednim GID grupy docker.
Po skonfigurowaniu Docker Hosta możesz tworzyć monitory dla poszczególnych kontenerów. Każdy monitor śledzi stan jednego kontenera i powiadamia Cię, gdy kontener przestanie działać lub zmieni status na unhealthy.
docker compose up -d). ID kontenera zmienia się przy każdym odtworzeniu, co złamałoby konfigurację monitora. Upewnij się, że Twoje kontenery mają jawnie nadane nazwy w docker-compose.yml za pomocą dyrektywy container_name.
Docker socket (/var/run/docker.sock) to potężne narzędzie — ale właśnie dlatego wymaga ostrożnego obchodzenia się z nim. Dostęp do socketa to de facto pełna kontrola nad Docker Engine: możliwość tworzenia kontenerów, usuwania wolumenów, a nawet uzyskania dostępu root do systemu hosta. Dlatego kwestia bezpieczeństwa jest kluczowa.
Jeśli Uptime Kuma działa jako kontener Docker na tym samym hoście, musisz zamontować Docker socket jako wolumen. Zawsze rób to z flagą :ro (read-only):
volumes:
- /var/run/docker.sock:/var/run/docker.sock:roFlaga :ro uniemożliwia Uptime Kuma wykonywanie operacji zapisu na sockecie — co oznacza, że nie może tworzyć, usuwać ani restartować kontenerów. Może jedynie odczytywać informacje o stanie kontenerów, co jest dokładnie tym, czego potrzebujemy do monitoringu.
:ro Docker socket daje dostęp do odczytu wrażliwych informacji: zmiennych środowiskowych kontenerów (mogą zawierać hasła i tokeny), konfiguracji sieci i wolumenów. W środowiskach o podwyższonych wymaganiach bezpieczeństwa rozważ użycie Docker socket proxy, który filtruje dostępne endpointy API.
Najlepszą praktyką jest nieprzekazywanie Docker socketa bezpośrednio do kontenerów aplikacyjnych. Zamiast tego użyj dedykowanego proxy, które filtruje zapytania API i udostępnia tylko bezpieczne endpointy. Najpopularniejszym rozwiązaniem jest Tecnativa/docker-socket-proxy:
services:
dockerproxy:
image: tecnativa/docker-socket-proxy
container_name: dockerproxy
restart: unless-stopped
environment:
- CONTAINERS=1 # Zezwól na odczyt kontenerów
- IMAGES=0 # Zablokuj dostęp do obrazów
- NETWORKS=0 # Zablokuj dostęp do sieci
- VOLUMES=0 # Zablokuj dostęp do wolumenów
- POST=0 # Zablokuj operacje zapisu (POST/PUT/DELETE)
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
ports:
- "127.0.0.1:2375:2375"
networks:
- monitoring
uptime-kuma:
image: louislam/uptime-kuma:2
container_name: uptime-kuma
restart: unless-stopped
volumes:
- uptime-kuma-data:/app/data
ports:
- "3001:3001"
networks:
- monitoring
depends_on:
- dockerproxy
volumes:
uptime-kuma-data:
networks:
monitoring:
driver: bridgeW tej konfiguracji Uptime Kuma łączy się z Docker socket proxy (adres: tcp://dockerproxy:2375) zamiast bezpośrednio z Docker socketem. Proxy przepuszcza tylko zapytania GET do endpointu /containers — wszystko inne jest blokowane. To daje Uptime Kuma dokładnie tyle uprawnień, ile potrzebuje do monitoringu, i ani grama więcej.
Po wdrożeniu Docker socket proxy, skonfiguruj Docker Host w Uptime Kuma następująco:
tcp://dockerproxy:2375 (jeśli w tej samej sieci Docker) lub tcp://127.0.0.1:2375 (jeśli Uptime Kuma nie jest w kontenerze)Nie potrzebujesz certyfikatów TLS, ponieważ komunikacja odbywa się w ramach wewnętrznej sieci Docker (lub przez localhost). Proxy nigdy nie powinno być wystawione na zewnętrzny interfejs sieciowy.
Jeśli Uptime Kuma działa bezpośrednio na hoście (bez Dockera), proces musi mieć uprawnienia do odczytu Docker socketa. Socket /var/run/docker.sock jest domyślnie własnością użytkownika root i grupy docker z uprawnieniami srw-rw----. Rozwiązania:
sudo usermod -aG docker kuma-usersudo chmod 666 /var/run/docker.sock — niezalecane w produkcjiDOCKER_GID lub uruchom z --group-add odpowiadającym GID grupy docker na hościeDomyślnie Uptime Kuma sprawdza, czy kontener jest w stanie running (uruchomiony). To najprostszy poziom monitoringu — informuje, czy kontener w ogóle działa. Ale kontener może być „running" i jednocześnie całkowicie niefunkcjonalny — na przykład serwer HTTP zwracający 502, baza danych odrzucająca połączenia lub aplikacja w deadlocku.
Tutaj wchodzi w grę mechanizm Docker Health Check. Jest to wbudowana funkcja Dockera, która pozwala zdefiniować komendę diagnostyczną uruchamianą cyklicznie wewnątrz kontenera. Na podstawie jej wyniku Docker oznacza kontener jednym z trzech statusów:
| Status | Znaczenie | Uptime Kuma |
|---|---|---|
| healthy | Health check zwraca kod 0 — kontener działa poprawnie | UP (zielony) |
| unhealthy | Health check zwraca kod 1 po określonej liczbie prób — kontener ma problem | DOWN (czerwony) |
| starting | Kontener właśnie się uruchamia, health check jeszcze nie zakończył się sukcesem | PENDING |
Uptime Kuma automatycznie rozpoznaje health check — jeśli kontener ma zdefiniowany health check, Uptime Kuma używa statusu healthy/unhealthy zamiast prostego running/stopped. To oznacza głębszy poziom monitoringu bez dodatkowej konfiguracji w Uptime Kuma.
Health check definiuje się w Dockerfile za pomocą instrukcji HEALTHCHECK:
HEALTHCHECK --interval=30s --timeout=10s --start-period=60s --retries=3 \
CMD curl -f http://localhost:8080/health || exit 1Parametry:
Preferowaną metodą definiowania health checków jest plik docker-compose.yml — dzięki temu masz konfigurację w jednym miejscu, bez potrzeby modyfikowania Dockerfile:
services:
webapp:
image: my-webapp:latest
container_name: webapp
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
interval: 30s
timeout: 10s
start_period: 60s
retries: 3Poniżej znajdziesz gotowe konfiguracje health check dla najczęściej monitorowanych kontenerów:
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:80"]
interval: 30s
timeout: 5s
retries: 3healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 30s
timeout: 5s
retries: 3healthcheck:
test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
interval: 30s
timeout: 5s
retries: 3healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 30s
timeout: 5s
retries: 3healthcheck:
test: ["CMD", "mongosh", "--eval", "db.adminCommand('ping')"]
interval: 30s
timeout: 10s
retries: 3healthcheck:
test: ["CMD", "rabbitmq-diagnostics", "check_port_connectivity"]
interval: 30s
timeout: 10s
retries: 3wget lub curl w health checkach, jeśli obraz ich nie zawiera (np. obrazy alpine bez dodatkowych pakietów). W takich przypadkach użyj wbudowanych narzędzi danej usługi (jak pg_isready dla PostgreSQL czy redis-cli ping dla Redis) lub napisz prosty skrypt w języku dostępnym w obrazie.
Monitor Docker Container w Uptime Kuma śledzi przede wszystkim stan kontenera (container state). Docker definiuje następujące stany, a Uptime Kuma interpretuje je w kontekście dostępności:
| Stan kontenera | Opis | Status w Uptime Kuma |
|---|---|---|
running | Kontener działa normalnie | UP (jeśli brak health check) lub zależy od health check |
running + healthy | Kontener działa i health check jest OK | UP |
running + unhealthy | Kontener działa, ale health check wskazuje problem | DOWN |
exited | Kontener zakończył działanie (crash lub celowe zatrzymanie) | DOWN |
restarting | Kontener jest w trakcie restartu | DOWN (tymczasowo) |
paused | Kontener zapauzowany (docker pause) | DOWN |
dead | Kontener w stanie martwym (błąd przy usuwaniu) | DOWN |
created | Kontener utworzony, ale nigdy nie uruchomiony | DOWN |
Jednym z najczęstszych problemów w środowiskach Docker jest pętla restartów (restart loop) — kontener crashuje, Docker go restartuje (dzięki restart: unless-stopped lub restart: always), kontener znów crashuje i tak w kółko. Z perspektywy docker ps kontener „działa", bo za każdym razem jest restartowany. Ale usługa jest faktycznie niedostępna.
Uptime Kuma pomoże wykryć ten problem na kilka sposobów:
unhealthy pojawi się między restartamiMonitor Docker Container w Uptime Kuma koncentruje się na stanie kontenera (running/healthy/unhealthy), a nie na szczegółowych metrykach zasobów (CPU, RAM, I/O). Jeśli potrzebujesz monitoringu zasobów kontenerów, masz kilka opcji:
/metrics lub /health z informacjami o zasobach, możesz użyć monitora JSON Query do weryfikacji wartoścideploy.resources.limits.memory) i dodaj health check do każdego kontenera. W ten sposób Docker automatycznie oznaczy kontener jako unhealthy lub go zrestartuje przy problemach z zasobami, a Uptime Kuma natychmiast Cię o tym powiadomi. To prostsze i bardziej niezawodne niż próba monitorowania metryk zasobów z zewnątrz.
Poniżej znajdziesz kompletne, gotowe do użycia konfiguracje Docker Compose dla typowych scenariuszy monitorowania kontenerów za pomocą Uptime Kuma.
services:
nginx:
image: nginx:alpine
container_name: nginx-web
restart: unless-stopped
ports:
- "80:80"
- "443:443"
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:80"]
interval: 30s
timeout: 5s
retries: 3
depends_on:
php:
condition: service_healthy
php:
image: php:8.3-fpm
container_name: php-app
restart: unless-stopped
healthcheck:
test: ["CMD-SHELL", "php-fpm-healthcheck || exit 1"]
interval: 30s
timeout: 5s
retries: 3
mysql:
image: mysql:8.0
container_name: mysql-db
restart: unless-stopped
environment:
MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
healthcheck:
test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
interval: 30s
timeout: 5s
retries: 3Dla tego stosu utwórz w Uptime Kuma trzy monitory Docker Container (nginx-web, php-app, mysql-db) oraz jeden monitor HTTP sprawdzający odpowiedź strony na porcie 80/443. Grupa monitorów z nazwą „Stos webowy" da Ci pełny obraz stanu aplikacji.
services:
nextcloud:
image: nextcloud:latest
container_name: nextcloud-app
restart: unless-stopped
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost/status.php"]
interval: 60s
timeout: 10s
start_period: 120s
retries: 3
depends_on:
postgres:
condition: service_healthy
redis:
condition: service_healthy
postgres:
image: postgres:16
container_name: nextcloud-db
restart: unless-stopped
healthcheck:
test: ["CMD-SHELL", "pg_isready -U nextcloud"]
interval: 30s
timeout: 5s
retries: 3
redis:
image: redis:7-alpine
container_name: nextcloud-redis
restart: unless-stopped
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 30s
timeout: 5s
retries: 3W Uptime Kuma utwórz monitory Docker Container dla każdego z trzech kontenerów oraz dodaj monitor HTTP na https://cloud.twoja-domena.pl/status.php z oczekiwanym kodem statusu 200. Opcjonalnie dodaj monitor HTTP JSON Query, który sprawdza wartość installed i maintenance w odpowiedzi JSON z endpointu /status.php.
services:
dockerproxy:
image: tecnativa/docker-socket-proxy
container_name: dockerproxy
restart: unless-stopped
environment:
- CONTAINERS=1
- POST=0
- IMAGES=0
- NETWORKS=0
- VOLUMES=0
- SERVICES=0
- TASKS=0
- INFO=0
- EVENTS=0
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
networks:
- proxy-net
healthcheck:
test: ["CMD-SHELL", "wget -qO- http://localhost:2375/version || exit 1"]
interval: 30s
timeout: 5s
retries: 3
uptime-kuma:
image: louislam/uptime-kuma:2
container_name: uptime-kuma
restart: unless-stopped
volumes:
- ./data:/app/data
ports:
- "3001:3001"
networks:
- proxy-net
depends_on:
dockerproxy:
condition: service_healthy
volumes:
uptime-kuma-data:
networks:
proxy-net:
driver: bridgePo uruchomieniu dodaj Docker Host w Uptime Kuma z adresem tcp://dockerproxy:2375 (Connection Type: TCP, bez certyfikatów TLS). Wszystkie kontenery na hoście będą widoczne przez bezpieczne proxy.
Monitoring samego stanu kontenera to dopiero połowa obrazu. Kontener Docker może być running i healthy, a jednocześnie aplikacja w nim może nie odpowiadać na żądania HTTP — na przykład z powodu błędnej konfiguracji, problemu z certyfikatem SSL, zablokowanego portu lub deadlocka w aplikacji.
Dlatego najlepszą praktyką jest łączenie monitorów Docker Container z monitorami warstwy aplikacji — tworząc wielowarstwowy model obserwacji, który wykrywa problemy na każdym poziomie.
| Warstwa | Typ monitora | Co sprawdza | Przykład |
|---|---|---|---|
| Infrastruktura | Docker Container | Czy kontener działa i jest healthy | Kontener nginx-proxy = running + healthy |
| Sieć | TCP | Czy port usługi jest otwarty | Port 443 na serwerze = open |
| Aplikacja | HTTP(s) | Czy endpoint odpowiada poprawnie | https://app.example.com = 200 OK |
| Logika | HTTP JSON Query | Czy dane w odpowiedzi są poprawne | /api/health → {"status": "ok"} |
| Treść | HTTP Keyword | Czy na stronie jest oczekiwany tekst | Strona główna zawiera „Witamy" |
| Certyfikat | HTTP(s) | Ważność certyfikatu SSL (dni do wygaśnięcia) | SSL ważny > 14 dni |
Przyjmijmy, że masz typowy stos: Nginx reverse proxy + aplikacja Node.js + PostgreSQL + Redis. Oto rekomendowana konfiguracja monitorów w Uptime Kuma:
Zorganizuj monitory w grupy (Groups) — na przykład „Stos aplikacji" z podgrupami „Kontenery" i „Endpointy". Dzięki temu dashboard jest czytelny, a strona statusu wyświetla logiczną strukturę usług.
Wielowarstwowy monitoring pozwala na szybką korelację alertów. Gdy otrzymasz powiadomienie, scenariusze diagnostyczne wyglądają następująco:
docker logs nazwa)warstwa:infra dla monitorów Docker, warstwa:app dla monitorów HTTP i środowisko:prod lub środowisko:staging dla rozróżnienia środowisk. Tagi pomagają w filtracji i szybkiej diagnostyce, gdy masz dziesiątki monitorów.
Na podstawie doświadczeń tysięcy administratorów korzystających z monitoringu Docker w Uptime Kuma, zebraliśmy najważniejsze zalecenia i najczęstsze pułapki.
running, co nie gwarantuje, że usługa faktycznie działa. Health check to różnica między monitoringiem „czy proces istnieje" a „czy usługa odpowiada"/var/run/docker.sock bezpośrednio, użyj Tecnativa/docker-socket-proxy z minimalnymi uprawnieniami. To standard bezpieczeństwa w środowiskach produkcyjnychcontainer_name w Docker Compose. Automatycznie generowane nazwy (np. projekt-nginx-1) mogą się zmieniać i zawierać losowe sufiksystart_period w health check — daj kontenerowi czas na pełne uruchomienie. Bez tego kontenery z dłuższym rozruchem (np. Java, WordPress) mogą być oznaczone jako unhealthy tuż po starcie:ro — bez read-only każdy kontener z dostępem do socketa ma efektywnie uprawnienia roota na hościedocker compose up -d. Używaj nazw kontenerów (container_name)running nie oznacza, że usługa działa poprawnie. Zawsze łącz z monitorami warstwy aplikacyjnejunhealthy — kontener w stanie unhealthy to poważny sygnał ostrzegawczy. Sprawdź logi health check: docker inspect --format='{{json .State.Health}}' nazwa127.0.0.1 lub w izolowanej siecidepends_on z condition: service_healthy — jeśli jeden kontener zależy od drugiego (np. aplikacja od bazy danych), użyj warunku startu opartego na health check zamiast prostego depends_onMonitoring kontenerów Docker w Uptime Kuma to proste, skuteczne i bezpieczne rozwiązanie, które daje administratorom pełną kontrolę nad stanem ich środowisk kontenerowych. W porównaniu z ciężkimi stosami monitoringu (Prometheus + cAdvisor + Alertmanager + Grafana), Uptime Kuma oferuje natychmiastową wartość przy minimalnym nakładzie konfiguracji.
Kluczowe elementy skutecznego monitoringu Docker w Uptime Kuma:
Niezależnie od tego, czy zarządzasz kilkoma kontenerami w homelabie, czy setkami w środowisku produkcyjnym — Uptime Kuma z monitoringiem Docker daje Ci spokój ducha i natychmiastową informację, gdy coś pójdzie nie tak. A w połączeniu z 91 kanałami powiadomień masz pewność, że alert dotrze do właściwej osoby w odpowiednim czasie.
Nie. Uptime Kuma może monitorować kontenery Docker niezależnie od tego, jak sama jest zainstalowana. Jeśli działa jako kontener — łączysz się przez zamontowany Docker socket. Jeśli działa bezpośrednio na hoście (bare metal / Node.js) — łączysz się przez lokalny socket lub TCP. Jeśli korzystasz z hostingu zarządzanego (np. SmartXHosting.pl) — łączysz się z Docker Engine na Twoich serwerach przez TCP z certyfikatami TLS. Każda z tych metod jest w pełni obsługiwana.
Nie ma sztucznego limitu. Praktyczny limit zależy od zasobów serwera i interwału sprawdzania. Przy interwale 60 sekund jedna instancja Uptime Kuma bez problemu obsłuży kilkaset monitorów Docker Container — każde sprawdzenie to jedno lekkie zapytanie do Docker API, które zwraca odpowiedź w milisekundach. Wąskim gardłem są raczej monitory HTTP i DNS niż Docker.
Tak. Uptime Kuma obsługuje wiele Docker Hostów jednocześnie. Dla każdego serwera Docker konfigurujesz osobny Docker Host (z połączeniem TCP z TLS lub przez socket proxy) i tworzysz monitory wskazujące na odpowiedni host. Możesz więc z jednej instancji Uptime Kuma monitorować kontenery na serwerze produkcyjnym, stagingowym, NAS-ie i dowolnej liczbie innych maszyn.
Monitor Docker Container sprawdza stan kontenera na poziomie Docker Engine — czy kontener jest running, healthy lub unhealthy. Odpowiada na pytanie „czy proces istnieje i czy health check przechodzi". Monitor HTTP sprawdza, czy usługa wewnątrz kontenera odpowiada na żądania HTTP — odpowiada na pytanie „czy aplikacja faktycznie działa i odpowiada użytkownikom". Najlepszą praktyką jest używanie obu typów monitorów jednocześnie dla pełnej obserwacji.
Wpływ na wydajność jest pomijalny. Docker socket proxy (Tecnativa/docker-socket-proxy) to lekki kontener bazujący na HAProxy, który przekazuje zapytania HTTP między Uptime Kuma a Docker socketem. Dodaje jedynie ułamek milisekundy do każdego zapytania. W zamian zyskujesz znacząco lepsze bezpieczeństwo — proxy filtruje zapytania i blokuje nieautoryzowane operacje na Docker Engine.
Jeśli Uptime Kuma sprawdza stan kontenera dokładnie w momencie restartu, może zobaczyć stan restarting lub krótkotrwały exited. Dlatego ważne jest ustawienie Retries w konfiguracji monitora na wartość 2-3. Dzięki temu pojedyncze „mignięcie" podczas restartu (np. przy aktualizacji obrazu) nie spowoduje fałszywego alarmu. Alert zostanie wysłany dopiero wtedy, gdy kontener nie wróci do stanu running/healthy po kilku kolejnych sprawdzeniach.
Monitor Docker Container w Uptime Kuma jest zaprojektowany do pracy z pojedynczym Docker Engine (standalone Docker lub Docker Compose). Nie obsługuje natywnie Docker Swarm services ani Kubernetes pods. Dla Kubernetes zalecamy monitorowanie przez endpointy HTTP (liveness/readiness probes) lub TCP — Uptime Kuma sprawdza endpoint Service/Ingress, a Kubernetes zarządza podami wewnętrznie. Dla Docker Swarm możesz monitorować poszczególne kontenery na poszczególnych node'ach przez TCP z TLS.