Один пинг говорит «я жива». Три сигнала рассказывают, когда задача началась, чем закончилась и сколько шла.
| Адрес | Смысл | Статус после |
|---|---|---|
/<uuid> | успех | up |
/<uuid>/start | задача началась | не меняется |
/<uuid>/fail | явный провал | down сразу |
/<uuid>/<код> | код выхода 0–255 | 0 — up, иначе down |
/<uuid>/log | запись в журнал | не меняется |
Тело POST-запроса (до 100 КБ) сохраняется в журнале пинга — удобно класть туда хвост лога, чтобы разбираться в инциденте не заходя на сервер.
График «Длительность выполнения» на странице чека строится
только по парам: /start, а
затем успех или код выхода. Разница между ними и есть время
работы задачи.
Важное следствие. Если слать только успешный пинг,
без /start, чек будет работать
нормально — статусы, алерты, аптайм на месте, — но график
длительности останется пустым: считать нечего. Миллисекунды
появляются лишь у тех прогонов, у которых был старт.
# без длительности: сервис знает «отработала», но не знает «сколько шла» /usr/local/bin/backup.sh && curl -fsS -m 10 "$PING" # с длительностью curl -fsS -m 10 "$PING/start" /usr/local/bin/backup.sh curl -fsS -m 10 "$PING/$?"
Пары связываются по порядку поступления. Если задача может идти в несколько экземпляров одновременно, длительность смешается — для таких случаев лучше отдельные чеки.
Обычный путь в down — молчание: дедлайн, потом grace, потом алерт. Явный сигнал провала этот путь минует: чек падает в момент пинга.
/fail — «задача сообщила об ошибке»;/<код> — код выхода: 0 считается успехом, любой другой роняет чек. Причина в алерте будет «ненулевой код выхода».
Второй вариант удобнее в shell: код последней команды уже
лежит в $?, отдельная ветка не
нужна. В systemd ту же роль играет
$EXIT_STATUS в
ExecStopPost — см.
сниппеты.
signal() { curl -fsS -m 10 --retry 3 -o /dev/null "$PING$1" || true; }
signal /start
/usr/local/bin/backup.sh
signal "/$?" /log кладёт в журнал строку, не
трогая ни статус, ни дедлайн. Годится для промежуточных
отметок длинного прогона: «выгрузил 10 000 строк»,
«переключился на резервный источник».
Заводить чеки руками необязательно. Если пинговать по
слагу — понятному имени вместо UUID — и добавить
?create=1, чек появится сам при
первом обращении. Это удобно, когда задачи раскатываются
деплоем и заранее неизвестно, сколько их будет.
https://ping.cronalive.com/<ping-key>/<slug>?create=1
ping-key — ключ проекта
(Проекты → Ping key в дашборде), общий для всех его
чеков; slug — имя задачи
строчными буквами, например
etl-run. Расписание нового чека
берётся из query-параметров:
| Параметр | Значение |
|---|---|
period | период в секундах, 60–31536000 |
grace | grace в секундах, 0–2592000 |
cron | cron-выражение вместо периода |
tz | таймзона для cron, по умолчанию UTC |
# простой период curl "https://ping.cronalive.com/<ping-key>/etl-run?create=1&period=3600&grace=300" # cron-выражение с таймзоной (плюсы вместо пробелов) curl "https://ping.cronalive.com/<ping-key>/backup?create=1&cron=30+3+*+*+*&tz=Europe/Moscow"
Правила, о которых стоит знать заранее:
create=1 и параметры расписания игнорируются — пинг просто засчитывается. Менять расписание можно в дашборде или через API;/<ping-key>/etl-run/start?create=1;