Monitoring kontenerów Docker w Uptime Kuma

Dlaczego monitoring kontenerów Docker jest niezbędny

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.

Jak Uptime Kuma monitoruje kontenery 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 Engine API — fundament komunikacji

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ę.

Dwa sposoby połączenia z Docker Engine

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.

Docker Host — koncepcja w Uptime Kuma

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ć.

Konfiguracja Docker Host w Uptime Kuma — krok po kroku

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.

/var/run/docker.sock

https://10.10.10.50:2376

Tworzenie monitora Docker Container — krok po kroku

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 socket — konfiguracja i bezpieczeństwo

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.

Montowanie socketa w trybie read-only

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:ro

Flaga :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.

Docker Socket Proxy — zalecane rozwiązanie bezpieczeństwa

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: bridge

W 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.

Konfiguracja Docker Host z socket proxy

Po wdrożeniu Docker socket proxy, skonfiguruj Docker Host w Uptime Kuma następująco:

• Connection Type: TCP
• Docker Daemon: 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.

Uprawnienia grupy docker

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:

• Dodaj użytkownika do grupy docker: sudo usermod -aG docker kuma-user
• Zmień grupę socketa (tymczasowe): sudo chmod 666 /var/run/docker.sock — niezalecane w produkcji
• W kontenerze Docker: ustaw zmienną DOCKER_GID lub uruchom z --group-add odpowiadającym GID grupy docker na hoście

Docker Health Check — zaawansowane monitorowanie stanu kontenerów

Domyś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:

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.

Definiowanie Health Check w Dockerfile

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 1

Parametry:

• --interval=30s — co ile sekund uruchamiać test (domyślnie 30s)
• --timeout=10s — maksymalny czas oczekiwania na wynik (domyślnie 30s)
• --start-period=60s — czas rozruchu, w którym niepowodzenia nie są liczone (domyślnie 0s)
• --retries=3 — ile niepowodzeń pod rząd oznacza status unhealthy (domyślnie 3)

Health Check w Docker Compose

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: 3

Przykłady Health Check dla popularnych usług

Poniżej znajdziesz gotowe konfiguracje health check dla najczęściej monitorowanych kontenerów:

Nginx / Apache

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:80"]
  interval: 30s
  timeout: 5s
  retries: 3

PostgreSQL

healthcheck:
  test: ["CMD-SHELL", "pg_isready -U postgres"]
  interval: 30s
  timeout: 5s
  retries: 3

MySQL / MariaDB

healthcheck:
  test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
  interval: 30s
  timeout: 5s
  retries: 3

Redis

healthcheck:
  test: ["CMD", "redis-cli", "ping"]
  interval: 30s
  timeout: 5s
  retries: 3

MongoDB

healthcheck:
  test: ["CMD", "mongosh", "--eval", "db.adminCommand('ping')"]
  interval: 30s
  timeout: 10s
  retries: 3

RabbitMQ

healthcheck:
  test: ["CMD", "rabbitmq-diagnostics", "check_port_connectivity"]
  interval: 30s
  timeout: 10s
  retries: 3

Co monitorować w kontenerach — statusy, restarty, zasoby

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:

Wykrywanie pętli restartów

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:

• Health check — jeśli kontener ma zdefiniowany health check, status unhealthy pojawi się między restartami
• Niestabilny wykres heartbeat — na wykresie w Uptime Kuma zobaczysz wzorzec UP-DOWN-UP-DOWN w krótkich interwałach, co jest wyraźnym sygnałem pętli restartów
• Uzupełniający monitor HTTP/TCP — dodatkowy monitor sprawdzający port lub endpoint aplikacji wykryje niedostępność usługi nawet gdy kontener formalnie działa

Monitorowanie zasobów — CPU i pamięć

Monitor 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:

• Docker health check z progami zasobów — możesz napisać health check, który sprawdza zużycie pamięci wewnątrz kontenera i zwraca kod 1, gdy przekroczy próg
• Prometheus + cAdvisor — pełny monitoring zasobów z możliwością alertów na podstawie metryk CPU/RAM/I/O
• HTTP JSON Query monitor w Uptime Kuma — jeśli Twoja aplikacja eksponuje endpoint /metrics lub /health z informacjami o zasobach, możesz użyć monitora JSON Query do weryfikacji wartości

Docker Compose — praktyczne przykłady konfiguracji

Poniżej znajdziesz kompletne, gotowe do użycia konfiguracje Docker Compose dla typowych scenariuszy monitorowania kontenerów za pomocą Uptime Kuma.

Scenariusz 1: Monitoring stosu webowego (Nginx + PHP + MySQL)

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: 3

Dla 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.

Scenariusz 2: Monitoring stosu self-hosted (Nextcloud + Redis + PostgreSQL)

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: 3

W 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.

Scenariusz 3: Docker socket proxy z Uptime Kuma (zalecana konfiguracja)

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: bridge

Po 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.

Łączenie monitoringu Docker z HTTP — pełna obserwacja stosu

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.

Model wielowarstwowego monitoringu

Praktyczna strategia monitorowania stosu

Przyjmijmy, że masz typowy stos: Nginx reverse proxy + aplikacja Node.js + PostgreSQL + Redis. Oto rekomendowana konfiguracja monitorów w Uptime Kuma:

1. Docker Container: nginx-proxy — sprawdza stan kontenera Nginx (interwał: 60s)
2. Docker Container: node-app — sprawdza stan kontenera aplikacji (interwał: 60s)
3. Docker Container: postgres-db — sprawdza stan kontenera bazy danych (interwał: 60s)
4. Docker Container: redis-cache — sprawdza stan kontenera Redis (interwał: 60s)
5. HTTP(s): https://app.example.com — sprawdza odpowiedź strony przez Nginx (interwał: 30s)
6. HTTP(s) Keyword: https://app.example.com — sprawdza, czy strona zawiera oczekiwaną treść (interwał: 60s)
7. TCP: postgres:5432 — sprawdza, czy port PostgreSQL jest otwarty (interwał: 60s)
8. HTTP JSON Query: https://app.example.com/api/health — waliduje odpowiedź health endpoint (interwał: 60s)

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.

Korelacja alertów — gdzie jest problem?

Wielowarstwowy monitoring pozwala na szybką korelację alertów. Gdy otrzymasz powiadomienie, scenariusze diagnostyczne wyglądają następująco:

• Docker DOWN + HTTP DOWN = kontener się zatrzymał → sprawdź logi kontenera (docker logs nazwa)
• Docker UP + HTTP DOWN = kontener działa, ale aplikacja nie odpowiada → sprawdź konfigurację reverse proxy, porty, health check
• Docker UP + HTTP UP + Keyword DOWN = strona odpowiada, ale treść się zmieniła → możliwy defacement, błąd w deploymencie lub problem z danymi
• Docker UP (unhealthy) + HTTP DOWN = kontener przeszedł w stan unhealthy → sprawdź logi health check i zasoby kontenera

Best practices i najczęstsze błędy

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.

Zalecenia (Do's)

• Zawsze dodawaj health check do kontenerów — bez health check Uptime Kuma może jedynie sprawdzić, czy kontener jest 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"
• Używaj Docker socket proxy — zamiast montować /var/run/docker.sock bezpośrednio, użyj Tecnativa/docker-socket-proxy z minimalnymi uprawnieniami. To standard bezpieczeństwa w środowiskach produkcyjnych
• Łącz monitory Docker z HTTP — monitor Docker mówi „kontener działa", monitor HTTP mówi „usługa odpowiada". Oba razem dają pełny obraz
• Nadawaj kontenerom jawne nazwy — używaj container_name w Docker Compose. Automatycznie generowane nazwy (np. projekt-nginx-1) mogą się zmieniać i zawierać losowe sufiksy
• Ustawiaj parametr start_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
• Konfiguruj retries w Uptime Kuma na 2-3 — eliminuje fałszywe alarmy wynikające z chwilowych problemów (np. krótki restart kontenera przy aktualizacji)
• Grupuj monitory logicznie — jeden stos aplikacyjny = jedna grupa z monitorami Docker i HTTP
• Ustaw powiadomienia na różne kanały — Telegram/Discord na telefon dla natychmiastowych alertów, e-mail dla audytu i archiwum

Najczęstsze błędy (Don'ts)

• Nie montuj Docker socketa bez flagi :ro — bez read-only każdy kontener z dostępem do socketa ma efektywnie uprawnienia roota na hoście
• Nie używaj ID kontenera w monitorze — ID zmienia się po każdym docker compose up -d. Używaj nazw kontenerów (container_name)
• Nie ustawiaj zbyt krótkiego interwału dla Docker — sprawdzanie stanu kontenera co 20 sekund jest niepotrzebne. Interwał 60 sekund jest optymalny dla monitorów Docker Container, podczas gdy monitor HTTP sprawdzający endpoint może mieć interwał 30s
• Nie polegaj wyłącznie na monitoringu Docker — status running nie oznacza, że usługa działa poprawnie. Zawsze łącz z monitorami warstwy aplikacyjnej
• Nie ignoruj stanu unhealthy — kontener w stanie unhealthy to poważny sygnał ostrzegawczy. Sprawdź logi health check: docker inspect --format='{{json .State.Health}}' nazwa
• Nie wystawiaj Docker TCP (port 2375) bez TLS na publiczny interfejs — to równoznaczne z udostępnieniem pełnego dostępu root do serwera. Docker TCP bez TLS powinien nasłuchiwać wyłącznie na 127.0.0.1 lub w izolowanej sieci
• Nie zapomnij o depends_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_on

Podsumowanie

Monitoring 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:

• Docker Host — konfiguracja połączenia z Docker Engine (socket lub TCP z TLS)
• Docker Container monitor — śledzenie stanu poszczególnych kontenerów (running/healthy/unhealthy)
• Docker Health Check — definiowanie diagnostyki wewnątrz kontenerów dla głębszego monitoringu
• Docker socket proxy — bezpieczny dostęp do Docker API z minimalnymi uprawnieniami
• Wielowarstwowy monitoring — łączenie monitorów Docker z HTTP, TCP i Keyword dla pełnej obserwacji
• Grupowanie i tagowanie — logiczna organizacja monitorów dla szybkiej diagnostyki

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.

Najczęściej zadawane pytania