Как настроить мониторинг cron-задач по шагам
Это инструкция по подключению мониторинга cron-задач в SitePuls — от выбора расписания до проверки детекта пропуска. Это учебный гайд, а не коммерческий лендинг и не operational checklist. SitePuls не запускает ваш crontab; задача должна сама отправить check-in после успешной работы.
Шаг 1: Выберите cron-задачу для мониторинга
Выберите задачу, чьё молчание бьёт по бизнесу — бэкапы, импорты, отчёты, cleanup. Зафиксируйте владельца, ритм и максимальный здоровый runtime.
Шаг 2: Создайте heartbeat check-in монитор
В SitePuls создайте heartbeat-монитор для этой задачи. Получите уникальный check-in URL. Один монитор на пайплайн — так пропуск указывает на нужный скрипт.
Шаг 3: Скопируйте уникальный check-in URL
Скопируйте URL из карточки монитора. Храните как секрет в окружении деплоя, не в публичном репозитории.
Шаг 4: Отправьте HTTP check-in после успеха
В конце успешного прогона вызовите URL через HTTP GET (например curl -fsS "https://example.sitepuls/heartbeat/YOUR_TOKEN"). Check-in только после успеха — путь ошибки не должен слать ложное завершение. Точный shell зависит от среды; подойдёт любой HTTPS-клиент.
Шаг 5: Задайте ожидаемый интервал и grace
Интервал — как часто задача должна check-in. Grace — запас на длинные прогоны. Подстройте под худший здоровый runtime.
Шаг 6: Подключите контакты алертов
Привяжите email, Telegram или webhook контакты владельцев задачи. Пропуск и recovery идут теми же каналами, что и у других мониторов.
Шаг 7: Проверьте пропуск и восстановление
В окне обслуживания пропустите или задержите check-in. Убедитесь в DOWN и алертах, затем отправьте успешный check-in и проверьте recovery. После — таймлайн инцидента.
Шаг 8: Поддерживайте монитор после смены расписания
При смене cron обновите интервал и grace. После смены владельцев перепроверьте контакты. Продуктовый контекст — на странице мониторинга cron; механизм — на heartbeat; перед go-live пройдите operational checklist.
Что можно проверять в SitePuls на этой странице
- Надёжность cron через heartbeat: задача вызывает уникальный URL при успешном завершении.
- Если запрос не пришёл в ожидаемое окно (с учётом grace), heartbeat помечается как сбойный.
- Агент не нужен — только исходящий HTTPS из вашей среды.
Куда уходят оповещения об инцидентах
- Адреса электронной почты в контактах получают письма при открытии и закрытии инцидентов (в рамках настроек уведомлений).
- Уведомления в Telegram через бота SitePuls после привязки чата к контакту (включая сценарий /start для ожидающих контактов).
- HTTPS-вебхуки с JSON: тип события, идентификаторы монитора, статус, время, при необходимости id инцидента и короткое сообщение — для своих интеграций.
- Режим Slack-compatible incoming webhook: отдельный формат полезной нагрузки в настройках контакта.
Частые вопросы
Куда добавить check-in запрос?
В конце успешного пути задачи — после бэкапа, импорта или отчёта, а не в начале скрипта.
Check-in слать до или после задачи?
После успешного завершения. Ранний check-in может отметить failed или частичный прогон как успешный.
Как выбрать ожидаемый интервал?
Под ритм cron. Если задача часовая — ждите примерно часовой check-in, затем добавьте grace.
Как проверить настройку?
В контролируемом окне пропустите или задержите check-in, подтвердите DOWN и алерты, затем восстановите успешным check-in.
Что происходит при пропуске запуска?
Если check-in не пришёл в интервал плюс grace, монитор может стать DOWN и уведомить контакты.
Как учитывать смену расписания?
Обновите ожидаемый интервал и grace под новое расписание cron, затем повторите контролируемый тест.
Какие контакты алертов можно использовать?
Email, Telegram и webhook-контакты, привязанные к монитору.
Можно ли мониторить задачи на другом сервере?
Да, если сервер может достучаться до HTTPS check-in URL после успешного прогона.