Dlaczego monitoring serwera jest konieczny?

Serwer, na którym działają strony i aplikacje klientów, to nie urządzenie, o którym można zapomnieć po konfiguracji. Dysk się zapełnia, pamięć RAM się wyczerpuje, certyfikaty SSL wygasają, usługi padają. Bez monitoringu dowiesz się o problemie dopiero wtedy, gdy zadzwoni klient z informacją, że strona nie działa — a to najgorszy możliwy scenariusz.

Dobry monitoring to system wczesnego ostrzegania, który pozwala reagować zanim problem dotknie użytkowników.

Podstawowe narzędzia wiersza poleceń

htop — podgląd procesów

htop to interaktywna wersja klasycznego top, oferująca czytelny widok procesów, zużycia CPU, RAM i swap:

sudo apt install htop
htop

Na co zwracać uwagę:

  • Zużycie CPU — stale powyżej 80% oznacza potrzebę optymalizacji lub skalowania
  • Pamięć RAM — gdy zbliża się do limitu, system zaczyna korzystać ze swap, co drastycznie spowalnia działanie
  • Swap — aktywne korzystanie ze swap to sygnał ostrzegawczy

df i du — miejsce na dysku

Zapełniony dysk to jedna z najczęstszych przyczyn awarii. Regularne sprawdzanie:

df -h          # wykorzystanie partycji
du -sh /var/*  # rozmiar katalogów w /var

Szczególnie narażone na zapełnienie są /var/log (logi) i /var/lib/docker (obrazy i kontenery Docker).

free — pamięć RAM

free -h

Kolumna available pokazuje, ile pamięci jest faktycznie dostępnej dla nowych procesów. Linux aktywnie wykorzystuje wolną pamięć na cache dyskowy, więc kolumna free może być niska nawet przy normalnym działaniu — to normalne zachowanie.

Logowanie i rotacja logów

Centralne logi systemowe

Na serwerze z systemd logi dostępne są przez journalctl:

journalctl -u nginx --since "1 hour ago"  # logi Nginx z ostatniej godziny
journalctl -p err --since today            # błędy z dzisiaj
journalctl --disk-usage                    # ile miejsca zajmują logi

Logi Dockera

Dla usług działających w kontenerach Docker:

docker compose logs -f --tail=100 nazwa-uslugi

Docker domyślnie nie ogranicza rozmiaru logów, co może prowadzić do zapełnienia dysku. Konfiguracja rotacji logów w /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Po zmianie konieczny jest restart Dockera: sudo systemctl restart docker.

Logrotate

Dla logów spoza Dockera, logrotate automatycznie rotuje, kompresuje i usuwa stare pliki logów:

/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data www-data
}

Ta konfiguracja utrzymuje logi z ostatnich 14 dni, kompresując starsze pliki.

Sprawdzanie dostępności (uptime checks)

Prosty skrypt monitorujący

Podstawowy skrypt sprawdzający dostępność stron:

#!/bin/bash
SITES=("https://www.linwork.pl" "https://www.lintax.pl")

for site in "${SITES[@]}"; do
    status=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$site")
    if [ "$status" != "200" ]; then
        echo "ALERT: $site zwraca status $status" | mail -s "Strona niedostępna" admin@example.com
    fi
done

Uruchamiany co 5 minut przez cron:

*/5 * * * * /home/user/scripts/check-sites.sh

Zewnętrzne usługi monitoringu

Monitorowanie z własnego serwera ma istotną wadę — gdy serwer padnie, monitoring też przestaje działać. Dlatego warto korzystać z zewnętrznych usług:

  • UptimeRobot — darmowy plan dla 50 monitorów, sprawdzanie co 5 minut
  • Hetrix Tools — darmowy plan z 15 monitorami, sprawdzanie co minutę
  • Uptime Kuma — self-hosted, ale warto uruchomić na osobnym serwerze

Zewnętrzna usługa powiadomi emailem, SMS-em lub przez webhook (np. do Slacka) o niedostępności strony.

Monitorowanie certyfikatów SSL

Wygaśnięcie certyfikatu SSL to problem, który łatwo przeoczyć, a skutkuje ostrzeżeniem przeglądarki odstraszającym odwiedzających:

#!/bin/bash
DOMAIN="www.linwork.pl"
EXPIRY=$(echo | openssl s_client -servername "$DOMAIN" -connect "$DOMAIN:443" 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))

if [ "$DAYS_LEFT" -lt 14 ]; then
    echo "Certyfikat $DOMAIN wygasa za $DAYS_LEFT dni" | mail -s "SSL Warning" admin@example.com
fi

Monitorowanie zasobów — alerty progowe

Automatyczne alerty, gdy zasoby zbliżają się do limitów:

#!/bin/bash
# Sprawdzenie miejsca na dysku
USAGE=$(df / | tail -1 | awk '{print $5}' | tr -d '%')
if [ "$USAGE" -gt 85 ]; then
    echo "Dysk zapełniony w ${USAGE}%" | mail -s "Disk Alert" admin@example.com
fi

# Sprawdzenie pamięci RAM
AVAILABLE=$(free -m | awk '/Mem:/ {print $7}')
if [ "$AVAILABLE" -lt 256 ]; then
    echo "Dostępna pamięć RAM: ${AVAILABLE}MB" | mail -s "RAM Alert" admin@example.com
fi

Rozwiązania zaawansowane

Dla bardziej wymagających środowisk warto rozważyć pełne systemy monitoringu:

  • Prometheus + Grafana — zbieranie metryk i wizualizacja na dashboardach. Standard branżowy, ale wymaga dodatkowych zasobów serwera.
  • Netdata — monitoring w czasie rzeczywistym z minimalną konfiguracją, piękne dashboardy od razu po instalacji.
  • Monit — lekki monitor procesów, automatycznie restartuje usługi po awarii.

Dla małego serwera z kilkoma usługami, kombinacja prostych skryptów Bash + zewnętrzna usługa uptime + konfiguracja logrotate jest zwykle wystarczająca.

Podsumowanie

Monitoring serwera nie musi być skomplikowany. Zaczyna się od podstaw: kontroli miejsca na dysku, pamięci RAM i dostępności stron. Proste skrypty Bash uruchamiane przez cron w połączeniu z zewnętrzną usługą monitoringu zapewniają solidną ochronę przed najczęstszymi problemami. Kluczowe jest, aby monitoring działał stale i powiadamiał o problemach zanim odczują je użytkownicy. Czas zainwestowany w konfigurację monitoringu zwraca się wielokrotnie przy pierwszej uchwyconej awarii.