Preset „kondycja serwera”

Większość awarii pojedynczego serwera to nie wysypana aplikacja. To ciche rzeczy wokół niej: konfiguracja nginx, która już nie przechodzi nginx -t i wywali się dopiero przy następnym reloadzie, odnawianie certyfikatu zepsute od tygodni, dysk, który się zapełnia i kładzie razem z sobą bazę danych, backup, który przestał tworzyć pliki.

Preset kondycja serwera zakłada monitor dla każdej z tych rzeczy w jednym kroku i daje plik crona, który je zasila.

Co tworzy

Grupa	Monitor	Polecenie	Harmonogram
Serwer WWW	`{host}-nginx-config-test`	`nginx -t`	co godzinę
Serwer WWW	`{host}-apache-config-test`	`apachectl configtest`	co godzinę
System ✓	`{host}-certbot-renew-dry-run`	`certbot renew --dry-run --quiet`	codziennie
System ✓	`{host}-disk-space-root`	błąd, gdy zajętość `/` przekracza próg (domyślnie 85%)	co 15 minut
System ✓	`{host}-backup-freshness`	błąd, gdy w katalogu backupów (domyślnie `/var/backups`) nie ma pliku młodszego niż 25 godzin	codziennie
Bazy danych	`{host}-postgres-ready`	`pg_isready -q`	co 5 minut
Bazy danych	`{host}-mysql-ping`	`mysqladmin ping --silent` (MySQL i MariaDB)	co 5 minut
Bazy danych	`{host}-redis-ping`	`redis-cli ping`, oczekuje `PONG`	co 5 minut
Bazy danych	`{host}-mongodb-ping`	polecenie `ping` przez `mongosh`	co 5 minut

Sprawdzenia oznaczone ✓ są zaznaczone domyślnie. Serwer WWW i bazę wybierasz sam: serwer ma zwykle nginx albo Apache i jedną bazę, a monitor dla usługi, której nie ma, tylko by alarmował. mysqladmin korzysta z uprawnień użytkownika, jako który działa cron: dla roota to gniazdo unix albo /root/.my.cnf.

Sam wybierasz, które sprawdzenia chcesz. Każde to zwykły monitor ping z oczekiwanym interwałem i okresem tolerancji: sprawdzenie, które przestanie się meldować, daje alert missed, a takie, którego polecenie zawiedzie, daje alert failed.

Preset tylko tworzy. Jeśli monitor ping o tej samej nazwie już istnieje, jest oznaczony jako istniejący i zostaje nietknięty, więc ponowne zastosowanie presetu nigdy nie cofa ustawień zmienionych później. Nazwy są osobne dla każdego typu monitora: check HTTP albo SSL o nazwie web1-nginx-config-test nie blokuje pinga o tej samej nazwie.

W panelu

Monitory → Dodaj monitor → Presety → Kondycja serwera.
Wpisz nazwę hosta (małe litery, np. web1). Stanie się prefiksem nazw wszystkich monitorów.
Zaznacz swój serwer WWW i bazę, popraw katalog backupów i próg dysku, i kliknij Podgląd.
Kliknij Utwórz monitory, a potem skopiuj plik crona widoczny pod podglądem.

Na serwerze

Plik crona wywołuje klienta shell, więc najpierw go zainstaluj i skonfiguruj:

curl -fsSL https://hellocron.com/hellocron.sh -o /usr/local/bin/hellocron
chmod +x /usr/local/bin/hellocron
sudo hellocron configure

Potem zapisz wygenerowany plik jako /etc/cron.d/hellocron-server-health. Wygląda tak:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
7 * * * * root /usr/local/bin/hellocron run web1-nginx-config-test /bin/sh -c 'nginx -t'
*/15 * * * * root /usr/local/bin/hellocron run web1-disk-space-root /bin/sh -c 'test "$(df --output=pcent / | tail -n 1 | tr -dc 0-9)" -lt 85'

Trzy szczegóły, które mają znaczenie:

Zostaw linię PATH. Cron uruchamia zadanie z ubogim PATH (w Debianie /usr/bin:/bin), a nginx, apachectl i mysqladmin leżą w /usr/sbin - bez tej linii sprawny serwer za każdym razem zgłaszałby awarię.
Bez kropki w nazwie pliku. Cron w Debianie i Ubuntu pomija pliki w /etc/cron.d, których nazwa zawiera kropkę.
Zostaw znak nowej linii na końcu. Cron ignoruje ostatnią linię bez niego. Wygenerowany plik już się nim kończy.

hellocron run wysyła ping run, uruchamia polecenie i wysyła complete albo fail z kodem wyjścia i komunikatem błędu. Polecenie jest w środku sh -c '...', żeby potoki i przekierowania były częścią monitorowanego przebiegu.

Z serwera, jedną komendą

Zamiast zaznaczać sprawdzenia w panelu, pozwól hostowi powiedzieć, co na nim działa. Z zainstalowanym klientem i zapisanym kluczem zarządzania (sudo hellocron configure --management-key, klucz zaczyna się od mk_ i potrzebuje zakresu write) uruchom:

sudo hellocron discover-server-apps

Klient szuka binarek stojących za każdym sprawdzeniem (nginx, apachectl, certbot, pg_isready, mysqladmin, redis-cli, mongosh) i pyta systemd albo listę procesów, czy usługa działa. Wynik to lista, którą możesz poprawić, zanim cokolwiek powstanie:

Checks for this host ([x] = selected):
  [x]  1. nginx-config-test      nginx -t                                   running (/usr/sbin/nginx, service active)
  [ ]  2. apache-config-test     apachectl configtest                       not found
  [x]  3. certbot-renew-dry-run  certbot renew --dry-run                    installed (/usr/bin/certbot)
  [x]  4. disk-space-root        disk usage of / below the threshold        built-in
  [x]  5. backup-freshness       a file younger than 25h in the backup dir  built-in
  [x]  6. postgres-ready         pg_isready                                 running (/usr/bin/pg_isready, service active)
  [ ]  7. mysql-ping             mysqladmin ping                            installed (/usr/bin/mysqladmin, service not active)
  [ ]  8. redis-ping             redis-cli ping                             not found
  [ ]  9. mongodb-ping           mongosh ping                               not found

Toggle: numbers separated by spaces, a = all, n = none, Enter = continue, q = quit:

Serwery WWW i certbot są zaznaczone, gdy tylko są zainstalowane, bo nginx -t działa niezależnie od tego, czy nginx jest uruchomiony. Baza danych jest zaznaczona tylko wtedy, gdy jej usługa jest aktywna: zainstalowany, ale zatrzymany MySQL to zwykle pozostałość, a monitor dla niego tylko by alarmował. Potem klient pyta o nazwę hosta (prefiks nazw wszystkich monitorów, domyślnie nazwa tej maszyny), katalog backupów i próg dysku, pokazuje, co powstanie, a co już istnieje, i po potwierdzeniu tworzy monitory oraz wypisuje plik crona.

Po wypisaniu pliku w terminalu klient proponuje zapis do /etc/cron.d/hellocron-server-health (wymaga roota). Potwierdzenie instaluje plik z właścicielem root:root i uprawnieniami 0644. Zastąpienie istniejącego pliku wymaga osobnej zgody, domyślnie odmownej, i zachowuje ukrytą kopię, której cron nie wykonuje. Sprawdzenia ruszą zgodnie z harmonogramem, jeśli usługa cron działa.

Plik crona to jedyna rzecz na stdout; lista, pytania i podsumowanie idą na stderr. Przy --yes, -o i przekierowanym stdout propozycja instalacji jest pomijana. Nieinteraktywny zapis (przekierowanie wymaga powłoki roota):

sudo sh -c 'hellocron discover-server-apps --yes > /etc/cron.d/hellocron-server-health'

--yes przyjmuje wykryty wybór i wartości domyślne bez pytań. --items nginx-config-test,postgres-ready wybiera sprawdzenia samodzielnie, --all bierze wszystkie, --host web1, --backup-dir /srv/backups i --disk-threshold 90 podają odpowiedzi z góry, --dry-run zatrzymuje się po podglądzie, a -o <plik> zapisuje plik crona pod wskazaną ścieżką zamiast na stdout. Tak jak panel, komenda tylko tworzy: istniejące monitory są wymienione jako istniejący i zostają nietknięte. Komenda wymaga planu z config as code; na planie bez niego klient mówi o tym wprost i odsyła do panelu.

Przez API

Te same presety są dostępne dla skryptów provisioningu przez Management API (klucz mk_). Zastosowanie presetu to POST i wymaga zakresu write; GET /api/v1/presets to odczyt i wymaga read, więc nazwany klucz używany do obu potrzebuje obu zakresów:

curl -s https://app.hellocron.com/api/v1/presets/server-health/apply?dry_run=true \
  -H "Authorization: Bearer $HELLOCRON_MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"host": "web1", "params": {"backup_dir": "/srv/backups"}}'

Odpowiedź wymienia, co zostanie utworzone, a w polu cron zawiera plik crona; dry run nie tworzy ani nie zmienia żadnego monitora i żadnego zdarzenia. dry_run przyjmuje tylko true, false, 1 albo 0 - literówka to 422 z kodem dry_run_invalid, nigdy cichy zapis. Bez ?dry_run=true monitory zostaną utworzone. GET /api/v1/presets zwraca listę dostępnych presetów. Oba endpointy są opisane w specyfikacji OpenAPI.