Збій бекапу — не питання «якщо», а «коли»
Без моніторингу ви дізнаєтесь про проблему лише в момент відновлення. За 7 років ми впровадили моніторинг для 50+ проектів: бекапи, синхронізації, оновлення — все, що працює за розкладом. Healthchecks.io вирішує задачу за допомогою dead man's switch (концепція з Wikipedia): задача чекає регулярний ping, а при його відсутності — алерт. Прискорення виявлення збоїв — у 10 разів порівняно з перевіркою логів, скорочення MTTR з 24 годин до 1 години.
Як працює dead man's switch?
Створюєте check з очікуваним періодом (наприклад, щодня о 02:00) та grace period 1 година. В кінці cron-задачі додаєте HTTP-запит на унікальний URL check'а. Якщо пінг не прийшов — Healthchecks.io надсилає сповіщення. Важливо: використовуйте оператор &&, щоб пінг відправлявся лише при успішному завершенні скрипта.
# /etc/cron.d/backup
0 2 * * * root /opt/scripts/backup.sh && curl -fsS --retry 3 https://hc-ping.com/your-uuid-here > /dev/null 2>&1
Цей підхід надійніший за моніторинг логів: Healthchecks.io перевіряє не лише наявність процесу, але й його успішне завершення. Ви отримуєте алерт протягом grace period (зазвичай 1 година) замість того, щоб виявити збій через добу.
Чому обирають self-hosted Healthchecks.io?
Для чутливих даних або air-gapped середовищ розгортаємо власний інстанс. Всі дані залишаються на вашій інфраструктурі, оновлення — вручну, але повний контроль. Безкоштовно і без обмежень. Self-hosted знижує витрати на моніторинг при великій кількості checks у порівнянні з хмарним тарифом. Вихідний код доступний на GitHub.
---
version: '3.8'
services:
web:
image: healthchecks/healthchecks:latest
environment:
- SECRET_KEY=your-secret-key-here
- ALLOWED_HOSTS=healthchecks.example.com
- [email protected]
- EMAIL_HOST=smtp.example.com
- EMAIL_PORT=587
- EMAIL_USE_TLS=True
ports:
- "8000:8000"
volumes:
- healthchecks-db:/data
---
Що обрати: хмару чи власний сервер?
| Параметр | Cloud | Self-hosted |
|---|---|---|
| Безкоштовно | До 20 checks | Повністю |
| Управління даними | На серверах провайдера | Ваш сервер |
| Оновлення | Автоматичні | Вручну |
| Інтеграція із зовнішніми системами | Через webhook | Через webhook + внутрішні API |
| Максимальна затримка алерту | Grace + затримка відправки | Grace + ваш SMTP |
Які задачі моніторять через Healthchecks.io?
- Бекапи БД: pg_dump, mysqldump, Barman — критично для production.
- Синхронізація: rsync, rclone в S3/GCS.
- Ротація логів: logrotate, архівація.
- Оновлення SSL: certbot renew — особливо важливо для самопідписаних сертифікатів.
- ETL-задачі: нічні звіти, експорти.
Кейс з практики: На одному проекті бекап MySQL не виконувався місяць через нестачу місця на диску. Після налаштування Healthchecks.io з перевіркою розміру файлу проблема виявлялася протягом години. Ми додали перевірку мінімального розміру (10 КБ) та алерт в Telegram. Відтоді втрат даних не було. Аналогічна ситуація на іншому проекті з PostgreSQL: спрацювання healthcheck попередило про неповний дамп (файл 2 КБ замість очікуваних 50 МБ). Grace period у 30 хвилин дозволив виправити скрипт до наступного бекапу.
Приклад скрипта з перевіркою розміру
#!/bin/bash
set -e
BACKUP_FILE="/backups/db_$(date +%Y%m%d).sql.gz"
pg_dump -h localhost -U app mydb | gzip > "$BACKUP_FILE"
# Перевіряємо, що файл не пустий (мінімум 10KB)
MIN_SIZE=10240
ACTUAL_SIZE=$(stat -c%s "$BACKUP_FILE")
if [ "$ACTUAL_SIZE" -lt "$MIN_SIZE" ]; then
echo "Backup too small: $ACTUAL_SIZE bytes" >&2
exit 1
fi
# Пінг тільки при успіху
curl -fsS --retry 3 "https://hc-ping.com/${HC_UUID}" > /dev/null
Канали сповіщень та їх можливості
| Канал | Затримка | Особливості |
|---|---|---|
| Telegram | Секунди | Просте налаштування, групові чати |
| До 5 хвилин | Надійно, але повільніше | |
| PagerDuty | Секунди | Escalation, інтеграція з ITSM |
| Webhook | Налаштовується | Кастомні дії (API, Slack тощо) |
Реакція на збій
Алерт приходить протягом grace period. Далі — runbook: перевірити диск, логи, перезапустити задачу. Healthchecks.io дозволяє вручну підтвердити problem і відправити повторний ping після виправлення.
Процес впровадження під ключ
- Аудит — інвентаризація всіх cron-задач, визначення критичності.
- Проектування — вибір періоду, grace, каналів сповіщень.
- Розгортання — self-hosted інстанс з HTTPS та резервним копіюванням.
- Інтеграція — підключення всіх задач, у тому числі з перевіркою розміру.
- Тестування — емуляція збоїв, перевірка алертів.
- Документація — інструкція для команди з додавання нових checks.
- Підтримка — тиждень post-deploy.
Що ви отримаєте в результаті
- Документація: конфігурації всіх checks, інструкція з додавання нових.
- Доступи: до інстансу Healthchecks.io, інтеграція з вашими системами.
- Навчання: демонстрація додавання checks та реакції на алерти.
- Підтримка: тиждень post-deploy для доналаштування.
Типовий проект — від кількох годин до одного робочого дня. Вартість розраховується індивідуально залежно від складності. Замовте впровадження — і ваші бекапи будуть під контролем. Отримайте консультацію: ми оцінимо вашу поточну схему моніторингу та запропонуємо оптимальний варіант. Зв'яжіться з нами для аудиту ваших cron-задач.
