Każdy monitor zadania cron ma własny adres URL do pingowania, widoczny na jego stronie. Zastąp poniższy https://app.uptimecheck.com/api/hb/your-token swoim adresem. Jak utworzyć monitor, dowiesz się z artykułu jak monitorować zadanie cron.
Adresy URL
…/your-token: zadanie się wykonało i zakończyło sukcesem.…/your-token/start: zadanie się rozpoczęło. Widzisz czasy wykonania, a przebieg, który przekroczy Maximum run time, wywołuje alert.…/your-token/fail: zadanie się nie powiodło. Dostajesz alert od razu, a nie dopiero po upływie terminu.…/your-token/0 do /255: kod wyjścia. 0 oznacza sukces, każdy inny – błąd.
Działają GET, POST i HEAD, a odpowiedź to OK. Treść żądania POST jest zapisywana jako wynik zadania i pokazywana przy błędach oraz w alercie. Odczytujemy do 64 kB i zachowujemy początek i koniec, łącznie 10 000 znaków. Większa treść jest odrzucana, a ping przepada, więc wysyłaj koniec logu, jak poniżej. Token w adresie URL jest sekretem, więc nie umieszczaj go w publicznych logach.
Skrypt opakowujący dla dowolnego harmonogramu
Ten skrypt uruchamia polecenie, zgłasza jego start, kod wyjścia i ostatnie 60 kB wyniku, a następnie przekazuje kod wyjścia dalej. Zapisz go jako /usr/local/bin/with-ping i wykonaj na nim chmod +x.
#!/bin/sh
# with-ping URL COMMAND…: runs COMMAND and reports it to Uptimecheck
url=”$1″; shift
curl -fsS -m 10 –retry 3 -o /dev/null „$url/start”
log=$(mktemp)
„$@” > „$log” 2>&1
code=$?
tail -c 60000 „$log” | curl -fsS -m 10 –retry 3 –data-binary @- -o /dev/null „$url/$code”
rm -f „$log”
exit $code
crontab
# Ping when the job succeeds
0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 –retry 3 -o /dev/null https://app.uptimecheck.com/api/hb/your-token
# Or report start, exit code and output with the script above
0 3 * * * /usr/local/bin/with-ping https://app.uptimecheck.com/api/hb/your-token /usr/local/bin/backup.sh
Ustaw w monitorze ten sam harmonogram i Time zone, w której działa crontab – często UTC.
Harmonogram Laravel
Laravel sam pinguje adresy URL. W pliku routes/console.php (Laravel 11 i nowsze; we wcześniejszych wersjach te same metody na $schedule w app/Console/Kernel.php):
use Illuminate\Support\Facades\Schedule;
Schedule::command(„backup:run”)
->dailyAt(„03:00”)
->pingBefore(„https://app.uptimecheck.com/api/hb/your-token/start”)
->pingOnSuccess(„https://app.uptimecheck.com/api/hb/your-token”)
->pingOnFailure(„https://app.uptimecheck.com/api/hb/your-token/fail”);
Błąd to polecenie, które kończy się niezerowym kodem wyjścia. Harmonogram korzysta ze strefy czasowej aplikacji, chyba że dodasz ->timezone(); ustaw tę samą strefę w monitorze.
Kubernetes CronJob
Zapisz adres URL do pingowania jako sekret poleceniem kubectl create secret generic uptimecheck –from-literal=ping-url=https://app.uptimecheck.com/api/hb/your-token. Obraz musi zawierać curl.
apiVersion: batch/v1
kind: CronJob
metadata:
name: nightly-backup
spec:
schedule: „0 3 * * *”
timeZone: „Europe/Stockholm”
concurrencyPolicy: Forbid
jobTemplate:
spec:
backoffLimit: 0
template:
spec:
restartPolicy: Never
containers:
– name: backup
image: registry.example.com/backup:1.4
env:
– name: PING_URL
valueFrom:
secretKeyRef:
name: uptimecheck
key: ping-url
command: [„/bin/sh”, „-c”]
args:
– |
curl -fsS -m 10 –retry 3 -o /dev/null „$PING_URL/start”
/app/backup.sh > /tmp/out.log 2>&1
code=$?
tail -c 60000 /tmp/out.log | curl -fsS -m 10 –retry 3 –data-binary @- -o /dev/null „$PING_URL/$code”
exit $code
Jeśli pod w ogóle się nie uruchomi, na przykład dlatego, że nie da się pobrać obrazu, ping nie dotrze, a monitor wyśle alert po upływie terminu. timeZone wymaga Kubernetes 1.27 lub nowszego.
GitHub Actions
on:
schedule:
– cron: „0 3 * * *”
jobs:
nightly:
runs-on: ubuntu-latest
env:
PING_URL: ${{ secrets.UPTIMECHECK_PING_URL }}
steps:
– uses: actions/checkout@v4
– run: curl -fsS -m 10 –retry 3 -o /dev/null „$PING_URL/start” || true
– run: ./scripts/nightly.sh
– if: success()
run: curl -fsS -m 10 –retry 3 -o /dev/null „$PING_URL”
– if: failure()
run: curl -fsS -m 10 –retry 3 -o /dev/null „$PING_URL/fail”
Zapisz adres URL do pingowania jako sekret repozytorium UPTIMECHECK_PING_URL. Ustaw w monitorze strefę czasową workflow – domyślnie UTC. Gdy GitHub jest obciążony, zaplanowane uruchomienia mogą startować z opóźnieniem, więc ustaw hojny Grace period, na przykład 30 minut.
Timer systemd
# /etc/systemd/system/backup.service
[Unit]
Description=Nightly backup
[Service]
Type=oneshot
ExecStart=/usr/local/bin/with-ping https://app.uptimecheck.com/api/hb/your-token /usr/local/bin/backup.sh
# /etc/systemd/system/backup.timer
[Unit]
Description=Run the nightly backup
[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
[Install]
WantedBy=timers.target
Włącz go poleceniami sudo systemctl daemon-reload i sudo systemctl enable –now backup.timer. OnCalendar korzysta ze strefy czasowej serwera.
Harmonogram zadań Windows
# C:\Scripts\backup-with-ping.ps1
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$ping = „https://app.uptimecheck.com/api/hb/your-token”
try { Invoke-RestMethod -Uri „$ping/start” -TimeoutSec 10 | Out-Null } catch {}
$output = & „C:\Scripts\backup.cmd” 2>&1 | Out-String
$code = $LASTEXITCODE
if ($output.Length -gt 30000) { $output = $output.Substring($output.Length – 30000) }
Invoke-RestMethod -Uri „$ping/$code” -Method Post -Body $output -TimeoutSec 10 | Out-Null
exit $code
Zarejestruj go do uruchamiania codziennie o 03:00 w PowerShellu uruchomionym jako administrator:
$action = New-ScheduledTaskAction -Execute „powershell.exe” -Argument „-NoProfile -ExecutionPolicy Bypass -File C:\Scripts\backup-with-ping.ps1”
$trigger = New-ScheduledTaskTrigger -Daily -At 3am
Register-ScheduledTask -TaskName „Nightly backup” -Action $action -Trigger $trigger -User „SYSTEM” -RunLevel Highest
Harmonogram zadań korzysta ze strefy czasowej komputera; ustaw tę samą w monitorze. Przeczytaj więcej o wyrażeniach cron i monitorowaniu zadań cron.