Czym jest Push Monitor i dlaczego warto go znać • Push vs Pull — dwa modele monitoringu • Dead Man's Switch — mechanizm heartbeat • Konfiguracja Push Monitora w Uptime Kuma krok po kroku • Push URL, interwał i graceful period • Zastosowania Push Monitora — praktyczne scenariusze • Integracja ze skryptami — curl, Python, PowerShell, Docker • Zaawansowane: wiadomości, status i body w push • Alerting — co się dzieje, gdy heartbeat nie przychodzi • Best practices — jak skonfigurować push monitoring prawidłowo • Podsumowanie • Najczęściej zadawane pytania
Większość narzędzi monitoringu — w tym Uptime Kuma — działa domyślnie w modelu aktywnym: serwer monitoringu regularnie odpytuje (pulluje) monitorowane usługi, sprawdzając czy są dostępne. To doskonale sprawdza się przy monitorowaniu stron www, API czy portów TCP. Ale co z zadaniami, które nie nasłuchują na żadnym porcie? Co z cronjobami, skryptami backupowymi, procesami ETL czy zaplanowanymi zadaniami Windows, które uruchamiają się o 3:00 w nocy, wykonują swoją pracę i kończą działanie?
Tutaj wchodzi Push Monitor (nazywany też Heartbeat Monitor lub Passive Monitor) — odwrócony model monitoringu, w którym to monitorowany skrypt sam wysyła sygnał do Uptime Kuma po zakończeniu pracy. Jeśli sygnał (heartbeat) nie przyjdzie w oczekiwanym czasie — Uptime Kuma uznaje, że coś poszło nie tak, i natychmiast wysyła powiadomienie.
Koncepcja jest prosta jak genialnie prosty jest mechanizm, na którym się opiera: Dead Man's Switch (przełącznik martwego człowieka). Dopóki ktoś regularnie naciska przycisk — wszystko jest w porządku. Gdy przestaje — uruchamia się alarm. W kontekście IT: dopóki skrypt regularnie wysyła heartbeat — monitor jest zielony. Gdy heartbeat przestaje przychodzić — monitor przechodzi w stan DOWN i wysyła alert.
Push Monitor w Uptime Kuma to jedno z najbardziej niedocenianych narzędzi w arsenale administratora. Pozwala monitorować procesy, które są niewidoczne dla tradycyjnego monitoringu — a jednocześnie często krytyczne dla działania całej infrastruktury. Backup, który nie wykonał się w nocy, cronjob odnawiający certyfikat SSL, który się zawiesił, skrypt synchronizacji danych, który cicho przestał działać — to scenariusze, w których push monitoring ratuje sytuację.
Aby w pełni zrozumieć wartość Push Monitora, warto porównać dwa fundamentalne modele monitoringu. Każdy z nich ma swoje zastosowania — i oba są potrzebne w dobrze zaprojektowanej infrastrukturze monitoringu.
W modelu Pull to serwer monitoringu inicjuje połączenie do monitorowanej usługi. Uptime Kuma co X sekund wysyła żądanie (HTTP GET, Ping ICMP, zapytanie DNS, połączenie TCP) i sprawdza odpowiedź. To domyślny model dla większości typów monitorów w Uptime Kuma — HTTP(s), Ping, TCP, DNS, SNMP, bazy danych i wielu innych.
Zalety modelu Pull:
Ograniczenia modelu Pull:
W modelu Push to monitorowana usługa inicjuje połączenie do serwera monitoringu. Skrypt, cronjob lub aplikacja po zakończeniu pracy wysyła sygnał HTTP do Uptime Kuma. Serwer monitoringu czeka pasywnie na sygnały i reaguje, gdy sygnał nie przyjdzie w oczekiwanym czasie.
Zalety modelu Push:
Ograniczenia modelu Push:
| Cecha | Pull (aktywny) | Push (pasywny) |
|---|---|---|
| Kto inicjuje | Serwer monitoringu | Monitorowany skrypt/usługa |
| Wymaga nasłuchiwania | Tak (port, URL) | Nie |
| Cronjobs / backupy | Niemożliwe | Idealne zastosowanie |
| Modyfikacja skryptu | Nie | Tak (1 linia kodu) |
| Za firewallem / NAT | Wymaga konfiguracji | Działa bez zmian |
| Monitoring sukcesu | Tylko dostępność | Dostępność + sukces wykonania |
| Dodatkowe dane | Brak | Status, msg, ping (czas) |
W praktyce najlepsze podejście to kombinacja obu modeli. Pull monitoring dla usług ciągłych (serwery www, API, bazy danych), push monitoring dla zadań okresowych (cronjobs, backupy, synchronizacje). Uptime Kuma obsługuje oba modele natywnie, co czyni ją kompletnym narzędziem monitoringu.
Dead Man's Switch (DMS) to mechanizm bezpieczeństwa znany z kolei i przemysłu — maszynista musi regularnie naciskać pedał lub przycisk, aby pociąg kontynuował jazdę. Jeśli przestanie (np. z powodu zasłabnięcia), system automatycznie zatrzyma pojazd. W IT ten sam koncept stosuje się do monitoringu procesów, które powinny regularnie dawać znać, że żyją.
Push Monitor w Uptime Kuma działa dokładnie na tej zasadzie:
1.
Tworzysz Push Monitor w Uptime Kuma i otrzymujesz unikalny Push URL, np. https://twoja-instancja.uptimekuma.eu/api/push/abc123XYZ?status=up&msg=OK&ping=. Ten URL jest Twoim „przyciskiem" — każde żądanie HTTP GET lub POST na ten adres to sygnał „jestem żywy".
2.
Monitorowany skrypt (cronjob, backup, ETL) po pomyślnym zakończeniu pracy wysyła żądanie HTTP na Push URL. Uptime Kuma rejestruje heartbeat, zapisuje timestamp i opcjonalne dane (status, wiadomość, czas odpowiedzi) i oznacza monitor jako UP (zielony).
3.
Uptime Kuma zna skonfigurowany Heartbeat Interval — oczekiwany czas między sygnałami (np. 300 sekund = 5 minut). Po otrzymaniu heartbeatu zaczyna odliczanie. Jeśli kolejny sygnał przyjdzie przed upływem interwału — wszystko OK, timer resetuje się.
4.
Jeśli heartbeat nie przyjdzie w oczekiwanym czasie (interwał + graceful period), Uptime Kuma zmienia status monitora na DOWN i wysyła powiadomienia przez wszystkie skonfigurowane kanały — e-mail, Telegram, Slack, Discord czy dowolny z 91 obsługiwanych serwisów. Skrypt się zawiesił? Cronjob nie wykonał się? Backup nie doszedł do końca? Dowiesz się natychmiast.
1.
Zaloguj się do Uptime Kuma i kliknij przycisk „Add New Monitor" (lub „Dodaj nowy monitor" w polskiej wersji językowej). Otworzy się formularz konfiguracji monitora.
2.
Z rozwijanej listy „Monitor Type" wybierz „Push". Po wybraniu tego typu Uptime Kuma automatycznie wygeneruje unikalny Push URL — skopiuj go i zachowaj. To jedyny typ monitora, który nie wymaga podania adresu URL ani hosta — bo to monitorowane usługi będą się łączyć z Uptime Kuma, nie na odwrót.
3.
Wpisz opisową nazwę, np. „Backup nocny — serwer DB", „Cron: odnawianie certyfikatów SSL", „ETL: import danych z hurtowni". Dobra nazwa pozwoli szybko zidentyfikować monitor na dashboardzie i w powiadomieniach.
4.
Ustaw Heartbeat Interval — oczekiwany maksymalny czas (w sekundach) między sygnałami heartbeat. Jeśli Twój cronjob uruchamia się co 5 minut, ustaw interwał na 300 sekund. Jeśli backup działa raz dziennie o 3:00 — ustaw interwał na 86400 sekund (24 godziny). Uptime Kuma oznaczy monitor jako DOWN, jeśli nie otrzyma heartbeatu w ciągu tego czasu (plus opcjonalny grace period).
5.
Ustaw liczbę ponownych prób (Max Retries) — ile razy monitor może „przegapić" heartbeat, zanim przejdzie w stan DOWN. Wartość 0 oznacza natychmiastową reakcję po upływie interwału. Dla zadań, które mogą się lekko opóźnić (np. backup dużej bazy danych), warto ustawić 1-2 retries z odpowiednim interwałem retries, co daje dodatkowy bufor czasowy.
6.
Przypisz kanały powiadomień — Telegram, e-mail, Discord, Slack lub dowolny inny z 91 obsługiwanych. Możesz przypisać wiele kanałów jednocześnie. Włącz opcję „Resend Notification", jeśli chcesz otrzymywać powtarzane alerty co X minut, dopóki problem nie zostanie rozwiązany.
7.
Skopiuj wygenerowany Push URL (widoczny na stronie szczegółów monitora). URL ma format: https://twoja-instancja/api/push/TOKEN?status=up&msg=OK&ping=. Dodaj wywołanie tego URL na końcu swojego skryptu — szczegóły integracji opisane są w kolejnych sekcjach artykułu.
1.
Monitor jest w stanie UP (zielony). Uptime Kuma zapisuje timestamp ostatniego heartbeatu i rozpoczyna odliczanie do następnego oczekiwanego sygnału (heartbeat interval).
2.
Oczekiwany czas minął, a nowy heartbeat nie przyszedł. Uptime Kuma oznacza monitor jako PENDING (oczekujący/niestabilny) — jeszcze nie DOWN, bo może być skonfigurowane retry.
3.
Jeśli ustawiono Max Retries > 0, Uptime Kuma czeka kolejne cykle (retry interval). Każdy cykl bez heartbeatu to kolejne „przegapienie". Monitor przechodzi w stan DOWN dopiero po wyczerpaniu wszystkich retries.
4.
Monitor przechodzi w stan DOWN (czerwony). Uptime Kuma natychmiast wysyła powiadomienia przez wszystkie przypisane kanały. Wiadomość zawiera nazwę monitora, czas ostatniego heartbeatu i czas przestoju. Jeśli włączono Resend Notification — alerty będą powtarzane w ustalonych interwałach.
5.
Gdy skrypt ponownie wyśle heartbeat (np. po naprawie problemu), monitor przechodzi z powrotem w stan UP (zielony). Uptime Kuma wysyła powiadomienie recovery — „Monitor XYZ is back online". W historii heartbeatów widoczny jest dokładny czas przestoju.
Kluczowa różnica w stosunku do tradycyjnego monitoringu: Push Monitor nie sprawdza stanu usługi aktywnie. Czeka na sygnały i reaguje na ich brak. To odwrócona logika — „brak wiadomości" to zła wiadomość.
Dodanie Push Monitora w Uptime Kuma to kilka minut. Poniżej pełna instrukcja krok po kroku — od utworzenia monitora do skonfigurowania pierwszego heartbeatu.
curl z terminala.
Push URL to serce Push Monitora. Każdy monitor generuje unikalny URL z tokenem, który służy jako endpoint do odbierania heartbeatów. Zrozumienie jego struktury i parametrów jest kluczowe dla prawidłowej konfiguracji.
Format Push URL w Uptime Kuma wygląda następująco:
https://twoja-instancja.uptimekuma.eu/api/push/TOKEN?status=up&msg=OK&ping=Parametry URL:
TOKEN — unikalny identyfikator monitora, generowany automatycznie. Traktuj go jak hasło — nie udostępniaj publiczniestatus — status heartbeatu: up (domyślny, wszystko OK) lub down (skrypt zgłasza błąd)msg — opcjonalna wiadomość tekstowa, np. „Backup zakończony pomyślnie" lub „Błąd: brak miejsca na dysku"ping — opcjonalny czas w milisekundach, np. czas wykonania skryptu. Wyświetlany na wykresie Response Time w Uptime KumaHeartbeat Interval to najważniejszy parametr Push Monitora. Określa maksymalny oczekiwany czas między sygnałami. Zbyt krótki interwał generuje fałszywe alarmy. Zbyt długi — opóźnia wykrycie problemu.
Zasada kciuka: ustaw interwał na czas cyklu zadania + margines bezpieczeństwa. Przykłady:
| Zadanie | Cykl | Sugerowany interwał | Uzasadnienie |
|---|---|---|---|
| Cronjob co 5 minut | 5 min | 600 s (10 min) | Podwójny czas cyklu — bufor na opóźnienia |
| Cronjob co godzinę | 60 min | 4200 s (70 min) | Cykl + 10 minut marginesu |
| Backup nocny (3:00) | 24 h | 90000 s (25 h) | Dobowy cykl + 1h na opóźnienia backupu |
| Backup tygodniowy | 7 dni | 648000 s (7.5 dnia) | Tygodniowy cykl + 12h marginesu |
| Heartbeat IoT co 1 min | 1 min | 120 s (2 min) | Podwójny czas cyklu |
Poza Heartbeat Interval, Uptime Kuma oferuje dodatkowe mechanizmy, które pomagają uniknąć fałszywych alarmów:
Przykład konfiguracji dla nocnego backupu:
# Konfiguracja Push Monitora:
# Heartbeat Interval: 86400 sekund (24 godziny)
# Max Retries: 1
# Retry Interval: 3600 sekund (1 godzina)
#
# Logika:
# - Backup powinien zakończyć się codziennie do ~4:00
# - Jeśli do 3:00 następnego dnia nie ma heartbeatu → pierwsze sprawdzenie
# - Po dodatkowej godzinie (4:00) bez heartbeatu → status DOWN + alert
# - Łączny czas tolerancji: ~25 godzin od ostatniego heartbeatuPush Monitor w Uptime Kuma jest niezwykle wszechstronny. Poniżej opisujemy najczęstsze zastosowania z konkretnymi przykładami konfiguracji i integracji.
Cron to scheduler zadań w systemach Unix/Linux. Zadania cron uruchamiają się automatycznie według harmonogramu — ale domyślnie nikt nie wie, czy się wykonały pomyślnie. Cron wysyła e-mail z outputem (jeśli skonfigurowano MTA), ale w praktyce większość serwerów nie ma skonfigurowanej poczty, a nawet jeśli ma — kto czyta e-maile z crona?
Push Monitor rozwiązuje ten problem elegancko. Dodaj curl na końcu komendy w crontab — i masz monitoring:
# Przykład: cronjob wykonujący cleanup logów co godzinę
0 * * * * /usr/local/bin/cleanup-logs.sh && curl -fsS -m 10 --retry 3 "https://twoja-instancja.uptimekuma.eu/api/push/TOKEN?status=up&msg=OK" > /dev/null
# Kluczowe flagi curl:
# -f → fail silently (zwróć kod błędu przy HTTP 4xx/5xx)
# -sS → cichy tryb, ale pokaż błędy
# -m 10 → timeout 10 sekund
# --retry 3 → ponów 3 razy przy błędach sieciowychDlaczego && zamiast ;? Operator && oznacza, że curl wykona się tylko jeśli poprzedni skrypt zakończy się sukcesem (kod wyjścia 0). Jeśli skrypt zwróci błąd — heartbeat nie zostanie wysłany — i Uptime Kuma zaalarmuje. To właśnie esencja push monitoringu: heartbeat wysyłamy tylko po sukcesie.
Bardziej zaawansowany wariant z raportowaniem statusu:
# Cronjob z raportowaniem sukcesu/porażki
0 * * * * /usr/local/bin/cleanup-logs.sh \
&& curl -fsS -m 10 "https://twoja-instancja.uptimekuma.eu/api/push/TOKEN?status=up&msg=Cleanup+OK" > /dev/null \
|| curl -fsS -m 10 "https://twoja-instancja.uptimekuma.eu/api/push/TOKEN?status=down&msg=Cleanup+FAILED" > /dev/nullW tym wariancie operator || powoduje, że jeśli skrypt się nie powiedzie, wyślemy heartbeat ze statusem down — Uptime Kuma natychmiast oznaczy monitor jako DOWN i wyśle alert, nie czekając na upłynięcie interwału.
Backup, który nie wykonał się w nocy, to jeden z najczęstszych i najgroźniejszych problemów w administracji IT. Odkrywany zazwyczaj dopiero, gdy dane są potrzebne — czyli w najgorszym możliwym momencie. Push Monitor zamienia cichy błąd w natychmiastowy alert.
#!/bin/bash
# backup-database.sh — backup bazy danych z push monitoring
PUSH_URL="https://twoja-instancja.uptimekuma.eu/api/push/TOKEN"
START_TIME=$(date +%s)
# Wykonaj backup
mysqldump --all-databases --single-transaction \
| gzip > /backup/db-$(date +%Y%m%d-%H%M%S).sql.gz
BACKUP_EXIT=$?
END_TIME=$(date +%s)
DURATION=$(( END_TIME - START_TIME ))
DURATION_MS=$(( DURATION * 1000 ))
if [ $BACKUP_EXIT -eq 0 ]; then
# Sprawdź rozmiar pliku backupu
BACKUP_SIZE=$(ls -lh /backup/db-*.sql.gz | tail -1 | awk '{print $5}')
curl -fsS -m 10 --retry 3 \
"${PUSH_URL}?status=up&msg=Backup+OK+(${BACKUP_SIZE})+w+${DURATION}s&ping=${DURATION_MS}" \
> /dev/null
else
curl -fsS -m 10 --retry 3 \
"${PUSH_URL}?status=down&msg=Backup+FAILED+(exit+code+${BACKUP_EXIT})" \
> /dev/null
fiTen skrypt nie tylko monitoruje, czy backup się wykonał, ale też raportuje rozmiar pliku i czas wykonania do Uptime Kuma. Dzięki parametrowi ping z czasem w milisekundach, na wykresie Response Time w Uptime Kuma zobaczysz historyczny trend czasu trwania backupu — i wykryjesz, jeśli backup zaczyna trwać niepokojąco długo.
Procesy ETL (Extract-Transform-Load) i zadania batch processing to kręgosłup wielu firm — przetwarzanie zamówień, synchronizacja danych między systemami, generowanie raportów, import z hurtowni. Ich awaria często pozostaje niezauważona godzinami lub dniami.
#!/bin/bash
# etl-pipeline.sh — pipeline ETL z monitoringiem push
PUSH_URL="https://twoja-instancja.uptimekuma.eu/api/push/TOKEN"
PROCESSED=0
ERRORS=0
# Etap 1: Extract
python3 /etl/extract.py --source warehouse
[ $? -ne 0 ] && { curl -fsS -m 10 "${PUSH_URL}?status=down&msg=ETL+EXTRACT+FAILED"; exit 1; }
# Etap 2: Transform
python3 /etl/transform.py --validate
[ $? -ne 0 ] && { curl -fsS -m 10 "${PUSH_URL}?status=down&msg=ETL+TRANSFORM+FAILED"; exit 1; }
# Etap 3: Load
PROCESSED=$(python3 /etl/load.py --target production | grep "records" | awk '{print $1}')
[ $? -ne 0 ] && { curl -fsS -m 10 "${PUSH_URL}?status=down&msg=ETL+LOAD+FAILED"; exit 1; }
# Sukces — raportuj liczbę przetworzonych rekordów
curl -fsS -m 10 "${PUSH_URL}?status=up&msg=ETL+OK:+${PROCESSED}+rekordow"Każdy etap pipeline'u może zgłosić błąd niezależnie — w wiadomości push zobaczysz, który konkretnie etap się nie powiódł. To znacznie przyspiesza diagnozę problemów.
Windows Task Scheduler to odpowiednik crona w środowisku Windows. Monitoring jest równie ważny — i równie prosty dzięki PowerShell:
# W Task Scheduler utwórz nowe zadanie, które na końcu wykonuje:
# Program: powershell.exe
# Arguments: -ExecutionPolicy Bypass -File C:\Scripts\backup-with-heartbeat.ps1
# Zawartość backup-with-heartbeat.ps1:
$PushUrl = "https://twoja-instancja.uptimekuma.eu/api/push/TOKEN"
$StartTime = Get-Date
try {
# Twoje zadanie backupowe
& "C:\Scripts\backup-sqlserver.ps1"
$Duration = [math]::Round(((Get-Date) - $StartTime).TotalMilliseconds)
Invoke-RestMethod -Uri "${PushUrl}?status=up&msg=Backup+OK&ping=$Duration" -Method Get
}
catch {
$ErrorMsg = $_.Exception.Message -replace ' ', '+'
Invoke-RestMethod -Uri "${PushUrl}?status=down&msg=FAILED:+$ErrorMsg" -Method Get
}Urządzenia IoT (Internet of Things) — czujniki, sterowniki, bramy sieciowe — często działają w trudnych warunkach sieciowych: za NATem, na LTE, z ograniczoną łącznością. Tradycyjny pull monitoring jest często niemożliwy. Push Monitor jest idealnym rozwiązaniem:
# Przykład: ESP32 (MicroPython) wysyłający heartbeat co minutę
import urequests
import time
PUSH_URL = "https://twoja-instancja.uptimekuma.eu/api/push/TOKEN"
while True:
try:
temp = read_temperature_sensor()
response = urequests.get(
f"{PUSH_URL}?status=up&msg=Temp:{temp}C&ping="
)
response.close()
except Exception as e:
pass # Brak łączności — Uptime Kuma wykryje brak heartbeatu
time.sleep(60) # Heartbeat co 60 sekundW Uptime Kuma ustaw interwał na 120 sekund (podwójny czas cyklu). Jeśli urządzenie IoT straci łączność na dłużej niż 2 minuty — otrzymasz alert. Dzięki parametrowi msg możesz nawet przesyłać dane telemetryczne (temperaturę, wilgotność, stan baterii) bezpośrednio do interfejsu Uptime Kuma.
Push Monitor w Uptime Kuma akceptuje żądania HTTP GET i POST. Integracja jest trywialna w dowolnym języku programowania i środowisku. Poniżej kompletne przykłady dla najpopularniejszych technologii.
Najprostszy i najczęściej używany sposób — jedna linia na końcu skryptu:
# Minimalny heartbeat (GET)
curl -fsS -m 10 --retry 3 "https://twoja-instancja.uptimekuma.eu/api/push/TOKEN?status=up&msg=OK" > /dev/null
# Heartbeat z czasem wykonania
START=$(date +%s%N)
# ... twój skrypt ...
END=$(date +%s%N)
PING=$(( (END - START) / 1000000 )) # nanosekundy → milisekundy
curl -fsS -m 10 "https://twoja-instancja.uptimekuma.eu/api/push/TOKEN?status=up&msg=OK&ping=${PING}"
# Heartbeat z dodatkowym kontekstem (POST z body)
curl -fsS -m 10 -X POST \
-H "Content-Type: application/json" \
-d '{"status":"up","msg":"Przetworzone: 1523 rekordów","ping":4521}' \
"https://twoja-instancja.uptimekuma.eu/api/push/TOKEN"Idealne dla skryptów Python — ETL, data science, automatyzacja:
import requests
import time
PUSH_URL = "https://twoja-instancja.uptimekuma.eu/api/push/TOKEN"
def send_heartbeat(status="up", msg="OK", ping=None):
"""Wyślij heartbeat do Uptime Kuma Push Monitora."""
params = {"status": status, "msg": msg}
if ping is not None:
params["ping"] = int(ping)
try:
response = requests.get(PUSH_URL, params=params, timeout=10)
response.raise_for_status()
except requests.RequestException as e:
print(f"Heartbeat failed: {e}")
# Użycie w skrypcie:
start = time.time()
try:
# Twoja logika biznesowa
result = process_data()
duration_ms = int((time.time() - start) * 1000)
send_heartbeat(
status="up",
msg=f"Przetworzono {result['count']} rekordów",
ping=duration_ms
)
except Exception as e:
send_heartbeat(
status="down",
msg=f"Błąd: {str(e)[:100]}"
)Elegancki wzorzec dla wielu monitorowanych zadań:
import requests
import time
import functools
def push_monitor(push_url):
"""Dekorator do automatycznego wysyłania heartbeatu po wykonaniu funkcji."""
def decorator(func):
@functools.wraps(func)
def wrapper(*args, **kwargs):
start = time.time()
try:
result = func(*args, **kwargs)
duration_ms = int((time.time() - start) * 1000)
requests.get(push_url, params={
"status": "up",
"msg": f"{func.__name__} OK",
"ping": duration_ms
}, timeout=10)
return result
except Exception as e:
requests.get(push_url, params={
"status": "down",
"msg": f"{func.__name__} FAILED: {str(e)[:80]}"
}, timeout=10)
raise
return wrapper
return decorator
# Użycie:
@push_monitor("https://twoja-instancja.uptimekuma.eu/api/push/TOKEN_BACKUP")
def run_backup():
# ... logika backupu ...
pass
@push_monitor("https://twoja-instancja.uptimekuma.eu/api/push/TOKEN_ETL")
def run_etl():
# ... logika ETL ...
passNatywne rozwiązanie dla środowisk Windows Server i Active Directory:
# Prosty heartbeat
$PushUrl = "https://twoja-instancja.uptimekuma.eu/api/push/TOKEN"
try {
# Twoje zadanie
& "C:\Scripts\maintenance-task.ps1"
Invoke-RestMethod -Uri "$PushUrl`?status=up&msg=Task+completed" -Method Get -TimeoutSec 10
}
catch {
$ErrMsg = $_.Exception.Message.Substring(0, [Math]::Min(100, $_.Exception.Message.Length))
$ErrMsg = $ErrMsg -replace ' ', '+' -replace '&', '%26'
Invoke-RestMethod -Uri "$PushUrl`?status=down&msg=FAILED:+$ErrMsg" -Method Get -TimeoutSec 10
}
# Wersja z pomiarem czasu (jako Scheduled Task)
$Stopwatch = [System.Diagnostics.Stopwatch]::StartNew()
# ... zadanie ...
$Stopwatch.Stop()
$PingMs = $Stopwatch.ElapsedMilliseconds
Invoke-RestMethod -Uri "$PushUrl`?status=up&msg=OK&ping=$PingMs" -Method GetDocker HEALTHCHECK pozwala zdefiniować komendę sprawdzającą zdrowie kontenera. Połączenie tego z Push Monitorem daje podwójne zabezpieczenie — Docker restartuje kontener, a Uptime Kuma alarmuje:
# Dockerfile
FROM your-app:latest
# Healthcheck wysyła heartbeat do Uptime Kuma
HEALTHCHECK --interval=60s --timeout=10s --retries=3 \
CMD curl -fsS -m 5 "https://twoja-instancja.uptimekuma.eu/api/push/TOKEN?status=up&msg=Container+healthy" || exit 1Alternatywnie w docker-compose.yml:
services:
my-app:
image: your-app:latest
healthcheck:
test: ["CMD", "curl", "-fsS", "-m", "5",
"https://twoja-instancja.uptimekuma.eu/api/push/TOKEN?status=up&msg=healthy"]
interval: 60s
timeout: 10s
retries: 3
start_period: 30sW tej konfiguracji kontener co 60 sekund wysyła heartbeat do Uptime Kuma. Jeśli kontener się zawiesi, healthcheck nie wykona się, heartbeat przestanie przychodzić — i Uptime Kuma poinformuje Cię o problemie, nawet jeśli Docker nie zdoła zrestartować kontenera.
Na niektórych systemach curl nie jest zainstalowany, ale wget jest dostępny domyślnie:
# wget jako alternatywa dla curl
wget -q --spider --timeout=10 "https://twoja-instancja.uptimekuma.eu/api/push/TOKEN?status=up&msg=OK"
# W crontab:
0 * * * * /usr/local/bin/myscript.sh && wget -q --spider --timeout=10 "https://twoja-instancja.uptimekuma.eu/api/push/TOKEN?status=up" 2>/dev/nullPush Monitor w Uptime Kuma obsługuje znacznie więcej niż prosty sygnał „jestem żywy". Parametry status, msg i ping pozwalają na budowanie zaawansowanego monitoringu z bogatym kontekstem.
Domyślny push (bez parametru status lub ze status=up) oznacza sukces. Ale możesz też aktywnie zgłosić błąd, wysyłając status=down. To natychmiast przełącza monitor w stan DOWN — nie musisz czekać na upłynięcie interwału:
# Skrypt zgłaszający błąd aktywnie
if ! /usr/local/bin/critical-task.sh; then
curl -fsS "https://twoja-instancja.uptimekuma.eu/api/push/TOKEN?status=down&msg=Task+failed"
exit 1
fi
curl -fsS "https://twoja-instancja.uptimekuma.eu/api/push/TOKEN?status=up&msg=Task+OK"To kluczowa różnica: bez aktywnego zgłaszania błędu musisz czekać, aż heartbeat interval upłynie. Ze status=down alert jest natychmiastowy.
Parametr msg pozwala przekazać dodatkowy kontekst, który jest widoczny w historii heartbeatów w interfejsie Uptime Kuma. Przydatne zastosowania:
msg=Backup+OK+(12.4+GB)msg=ETL:+15420+records+processedmsg=Deployed+v2.4.1msg=Disk+usage:+73%25 (uwaga: % musi być zakodowane jako %25 w URL)msg=FAILED:+Connection+timed+outPamiętaj o kodowaniu URL — spacje zastępuj + lub %20, znaki specjalne koduj odpowiednio. W curl możesz użyć --data-urlencode dla automatycznego kodowania.
Parametr ping przyjmuje wartość w milisekundach i wyświetla ją na wykresie Response Time w Uptime Kuma — tak samo jak czas odpowiedzi HTTP w pull monitorach. To pozwala na:
# Pomiar czasu z precyzją milisekundową
START_MS=$(date +%s%3N)
/usr/local/bin/heavy-task.sh
END_MS=$(date +%s%3N)
PING=$((END_MS - START_MS))
curl -fsS "https://twoja-instancja.uptimekuma.eu/api/push/TOKEN?status=up&msg=OK&ping=${PING}"Oprócz parametrów URL, Push Monitor akceptuje również żądania POST z body w formacie JSON:
# POST z JSON body
curl -fsS -X POST \
-H "Content-Type: application/json" \
-d '{
"status": "up",
"msg": "Backup completed: 15.2 GB, 1523 files",
"ping": 184200
}' \
"https://twoja-instancja.uptimekuma.eu/api/push/TOKEN"POST z body jest wygodniejszy przy dłuższych wiadomościach i eliminuje problemy z kodowaniem URL. Format JSON jest czytelniejszy w kodzie i łatwiejszy do generowania programistycznie.
Cały sens Push Monitora polega na wykrywaniu braku heartbeatu i szybkim alertowaniu. Oto co dzieje się w Uptime Kuma, gdy heartbeat nie przychodzi:
Warto pamiętać, że alert może nastąpić na dwa sposoby:
Kombinacja obu mechanizmów daje kompletne pokrycie: wykrywasz zarówno ciche awarie (skrypt nie wykonał się w ogóle), jak i wykryte błędy (skrypt wykonał się, ale napotkał problem).
Push Monitor obsługuje wszystkie 91 kanałów powiadomień dostępnych w Uptime Kuma. Dla monitoringu zadań krytycznych (backupy, procesy biznesowe) zalecamy skonfigurować minimum 2 kanały z eskalacją:
Push monitoring jest prosty koncepcyjnie, ale łatwo go źle skonfigurować — zbyt agresywne interwały generują fałszywe alarmy, zbyt luźne opóźniają wykrycie problemów. Oto sprawdzone praktyki.
Ustaw heartbeat interval na co najmniej dwukrotność cyklu zadania. Cronjob co 5 minut? Interwał 10 minut. Backup co 24h? Interwał 48h (lub 25-26h, jeśli chcesz szybszą reakcję, ale dodaj retries). Zbyt ciasny interwał + jitter w czasie wykonania = fałszywe alarmy, które prowadzą do ignorowania alertów (alert fatigue).
Najczęstszy błąd: heartbeat na końcu skryptu niezależnie od wyniku. Używaj && zamiast ; w crontab. W skryptach sprawdzaj kody wyjścia. Heartbeat powinien być potwierdzeniem sukcesu, nie dowodem uruchomienia. Wyjątek: aktywne zgłaszanie błędu ze status=down — to celowe i wartościowe.
Zawsze ustawiaj timeout dla wywołań heartbeat: curl -m 10, requests.get(..., timeout=10), -TimeoutSec 10 w PowerShell. Bez timeout'u, jeśli Uptime Kuma jest chwilowo niedostępna, Twój skrypt może zawisnąć na minuty, czekając na odpowiedź — co zablokuje cały cronjob.
Chwilowy problem sieciowy nie powinien powodować fałszywego alarmu. curl --retry 3 --retry-delay 5 ponowi próbę 3 razy z 5-sekundowym odstępem. W Pythonie użyj biblioteki tenacity lub prostego try/except z pętlą.
Zamiast „Push Monitor 1" napisz „Backup nocny — MySQL prod — serwer db01". W alertach i na dashboardzie od razu wiesz, co się zepsuło. Stosuj konwencję: [Typ] [Co] — [Gdzie], np. „[Cron] Cleanup logów — srv-web03", „[Backup] PostgreSQL — db-master".
Używaj tagów Uptime Kuma do kategoryzacji push monitorów: backup, cron, etl, iot. Twórz grupy monitorów per serwer lub per środowisko (production, staging). Ułatwia to filtrowanie na dashboardzie i przypisywanie kanałów powiadomień per grupa.
Jeśli Twoja instancja Uptime Kuma przestanie działać, push monitory nie wykryją problemów — bo nie ma kto odebrać heartbeat. Rozwiązanie: skonfiguruj zewnętrzny monitoring samej instancji Uptime Kuma (np. prosty uptime check z innej usługi lub drugiej instancji). Na hostingu zarządzanym SmartXHosting.pl ten problem nie istnieje — monitoring infrastruktury jest po stronie dostawcy.
Push URL zawiera token, który pozwala wysyłać heartbeaty do Twojego monitora. Traktuj go jak hasło — przechowuj w zmiennych środowiskowych, secret managerze (Vault, AWS Secrets Manager) lub plikach konfiguracyjnych z ograniczonymi uprawnieniami. Nie commituj tokenów do repozytoriów Git.
# Zamiast hardcoded URL w skrypcie:
# curl "https://instancja/api/push/TOKEN_W_JAWNYM_TEKSCIE"
# Użyj zmiennej środowiskowej:
export UPTIME_KUMA_PUSH_URL="https://instancja/api/push/TOKEN"
# W skrypcie:
curl -fsS -m 10 "${UPTIME_KUMA_PUSH_URL}?status=up&msg=OK"
# Lub z pliku:
PUSH_URL=$(cat /etc/uptime-kuma/backup-monitor.url)
curl -fsS -m 10 "${PUSH_URL}?status=up&msg=OK"Po dodaniu Push Monitora zawsze przetestuj cały flow: wyślij ręczny heartbeat (curl z terminala), upewnij się że monitor przechodzi w UP, poczekaj na upłynięcie interwału bez heartbeatu i sprawdź czy alert dochodzi. Jeden test uchroni Cię przed fałszywym poczuciem bezpieczeństwa.
Utrzymuj listę push monitorów z informacją: co monitorują, na jakim serwerze działa skrypt, jaki jest oczekiwany harmonogram, kto jest odpowiedzialny. Bez dokumentacji push monitory stają się „magicznymi" elementami — nikt nie wie co robią, ale wszyscy boją się ich dotknąć.
Push Monitor (Heartbeat) w Uptime Kuma to potężne narzędzie do monitorowania procesów, które są niewidoczne dla tradycyjnego monitoringu aktywnego. Dzięki odwróconej logice — to skrypt wysyła sygnał do Uptime Kuma, nie odwrotnie — możesz monitorować dosłownie każde zadanie, które da się zakończyć wywołaniem HTTP.
Kluczowe wnioski z tego artykułu:
curl, requests.get(), Invoke-RestMethod)status, msg i ping pozwalają na raportowanie sukcesu/błędu, wiadomości i czasu wykonaniastatus=down nie musisz czekać na upłynięcie interwałuPush Monitor jest jedną z tych funkcji, które wydają się proste — bo takie są. Ale ich wartość jest ogromna. Ile razy backup nie wykonał się w nocy i nikt o tym nie wiedział? Ile razy cronjob cicho przestał działać? Push monitoring w Uptime Kuma eliminuje te scenariusze — za cenę jednej linii kodu na końcu skryptu.
Nie. Push Monitor działa w odwrotnym kierunku — to monitorowany skrypt nawiązuje połączenie wychodzące (HTTP GET/POST) do Uptime Kuma. Nie wymaga otwierania żadnych portów przychodzących na monitorowanym serwerze. Działa przez NAT, firewalle i VPN bez żadnej konfiguracji sieciowej — wystarczy, że serwer ma dostęp HTTP/HTTPS do instancji Uptime Kuma.
Nie ma sztucznego limitu na liczbę Push Monitorów w Uptime Kuma. Możesz mieć ich setki — każdy z unikalnym Push URL. Jedynym ograniczeniem są zasoby serwera (RAM, dysk na dane heartbeatów). Na praktyce kilkadziesiąt-kilkaset push monitorów nie stanowi żadnego problemu wydajnościowego, ponieważ push monitory są „pasywne" — nie generują ruchu wychodzącego, tylko odbierają heartbeaty.
Heartbeat nie zostanie zarejestrowany. Dlatego zalecamy: (1) dodanie --retry 3 w curl dla automatycznego ponowienia próby, (2) ustawienie heartbeat interval z zapasem (np. podwójny czas cyklu) i (3) skonfigurowanie Max Retries > 0 w Uptime Kuma, co da dodatkowy bufor. Krótkotrwała niedostępność Uptime Kuma nie spowoduje fałszywego alarmu, jeśli konfiguracja ma odpowiednie marginesy. Na hostingu zarządzanym SmartXHosting.pl uptime instancji jest monitorowany i utrzymywany na najwyższym poziomie.
Tak. Ustaw Heartbeat Interval na wartość większą niż tydzień (np. 648 000 sekund = 7.5 dnia). Push Monitor w Uptime Kuma obsługuje interwały do wielu dni. Pamiętaj o odpowiednim marginesie — jeśli backup tygodniowy uruchamia się w niedzielę o 3:00, ale czasem trwa do 6:00, interwał powinien to uwzględniać.
Docker Container Monitor to monitor aktywny (pull) — Uptime Kuma łączy się z Docker socket i sprawdza stan kontenera (Running, Healthy). Push Monitor jest pasywny — kontener sam musi wysłać heartbeat. Docker Monitor sprawdza czy kontener żyje; Push Monitor sprawdza czy aplikacja w kontenerze działa prawidłowo. Najlepsza praktyka to użycie obu: Docker Monitor dla stanu kontenera + Push Monitor (przez HEALTHCHECK) dla zdrowia aplikacji.
Push URL zawiera unikalny token, który pełni rolę klucza autoryzacji. Jeśli ktoś pozna Twój token, może wysyłać fałszywe heartbeaty (utrzymując monitor w stanie UP nawet gdy usługa nie działa). Dlatego traktuj Push URL jak hasło: przechowuj w zmiennych środowiskowych lub secret managerze, nie commituj do repozytoriów Git, używaj HTTPS (nigdy HTTP). Jeśli token zostanie skompromitowany, możesz usunąć monitor i utworzyć nowy — wygeneruje się nowy token.
Tak. Push Monitor akceptuje standardowe żądania HTTP GET lub POST na Push URL. Możesz użyć dowolnej biblioteki HTTP w dowolnym języku: fetch() w Node.js, http.Get() w Go, HttpClient w Javie, HttpWebRequest w C#. To zwykłe żądanie HTTP — wystarczy wykonać GET na URL z parametrami status, msg i ping. Nic więcej nie jest wymagane — żadne SDK, biblioteki ani agenty.