Встановлення Healthchecks.

Конфігурація

Після встановлення базових компонентів Healthchecks.io необхідно налаштувати зовнішній доступ до застосунку через доменне ім'я та забезпечити безпеку з'єднання за допомогою HTTPS. Ми будемо використовувати Caddy — сучасний веб-сервер, який автоматично керує сертифікатами Let's Encrypt.

Важливе примітка: Перш ніж продовжити, переконайтеся, що ваш домен (наприклад, monitor.yourdomain.com) вказує на IP-адресу вашого VPS. Додайте відповідний A-запис у налаштуваннях DNS вашого доменного реєстратора.

1. Встановлення Caddy

Caddy можна встановити з офіційного репозиторію. Це забезпечить актуальні версії та простоту оновлень.

# Встановлення залежностей для додавання репозиторію Caddy
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https

# Додавання GPG-ключа Caddy
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg

# Додавання репозиторію Caddy
echo "deb [signed-by=/usr/share/keyrings/caddy-stable-archive-keyring.gpg] https://dl.cloudsmith.io/public/caddy/stable/deb/debian $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/caddy-stable.list

# Оновлення списку пакетів
sudo apt update

# Встановлення Caddy (актуальна версія на 2026 рік)
sudo apt install caddy -y

# Перевірка версії Caddy
caddy version

Очікувана версія: Caddy 2.x.x+.

2. Налаштування Caddyfile

Caddyfile — це основний файл конфігурації Caddy. Створимо його для проксіювання запитів до нашого контейнера Healthchecks.io.

# Відкриття файлу Caddyfile для редагування
sudo nano /etc/caddy/Caddyfile

Видаліть весь існуючий вміст і додайте наступну конфігурацію, замінивши monitor.yourdomain.com на ваш реальний домен:

monitor.yourdomain.com {
    # Проксіювання всіх запитів до контейнера Healthchecks.io
    reverse_proxy 127.0.0.1:8000 {
        # Заголовки для коректної роботи проксіювання
        header_up Host {host}
        header_up X-Real-IP {remote_ip}
        header_up X-Forwarded-For {remote_ip}
        header_up X-Forwarded-Proto {scheme}
    }

    # Увімкнення стиснення (опціонально, але рекомендується)
    encode gzip zstd

    # Логування доступу (опціонально)
    log {
        output file /var/log/caddy/access.log
        format json
    }

    # Обробка помилок (опціонально)
    handle_errors {
        respond "{err.status_code} {err.status_text}" {err.status_code}
    }
}

Пояснення:

• monitor.yourdomain.com: Вказує домен, для якого застосовується ця конфігурація. Caddy автоматично отримає для нього HTTPS-сертифікат.
• reverse_proxy 127.0.0.1:8000: Перенаправляє всі вхідні запити на локальний порт 8000, де запущено Healthchecks.io (всередині Docker-мережі він доступний через 127.0.0.1, якщо в docker-compose.yml вказано ports: - "127.0.0.1:8000:8000").
• header_up ...: Передає оригінальні заголовки хоста, IP-адреси та схеми протоколу в Healthchecks.io, що важливо для коректної роботи застосунку, особливо при генерації посилань.

Збережіть файл (Ctrl+O, Enter) та вийдіть (Ctrl+X).

3. Створення директорії для логів Caddy

Якщо ви увімкнули логування в Caddyfile, переконайтеся, що директорія для логів існує і Caddy має до неї доступ.

# Створення директорії для логів Caddy
sudo mkdir -p /var/log/caddy

# Встановлення правильних прав доступу
sudo chown caddy:caddy /var/log/caddy

4. Перезапуск Caddy

Застосуйте нову конфігурацію, перезапустивши службу Caddy.

# Перевірка конфігурації Caddyfile на помилки
sudo caddy validate --config /etc/caddy/Caddyfile

# Перезапуск служби Caddy
sudo systemctl restart caddy

# Переконайтеся, що Caddy запущений і працює
sudo systemctl status caddy

У виводі systemctl status caddy ви повинні побачити active (running).

5. Налаштування брандмауера для Caddy

Ми вже відкрили порти 80 і 443 на етапі підготовки сервера, але якщо ви цього не зробили, переконайтеся, що вони відкриті.

# Дозволити HTTP (порт 80)
sudo ufw allow 80/tcp

# Дозволити HTTPS (порт 443)
sudo ufw allow 443/tcp

# Перезавантажити UFW, якщо вносили зміни
sudo ufw reload

6. Перевірка працездатності

Тепер ви можете перевірити доступність Healthchecks.io через ваш домен.

• Через браузер: Відкрийте https://monitor.yourdomain.com у вашому веб-браузері. Ви повинні побачити сторінку входу Healthchecks.io.
• Через curl на сервері:

# Перевірка доступності через HTTPS
curl -I https://monitor.yourdomain.com

Ви повинні побачити HTTP-заголовки відповіді, включаючи HTTP/2 200 та заголовки, що вказують на Healthchecks.io.

• Перевірка логів Caddy:

# Перегляд логів Caddy
sudo journalctl -u caddy -f
# Або якщо налаштували у файл:
sudo tail -f /var/log/caddy/access.log

Ви повинні побачити записи про вхідні запити та успішні відповіді.

Якщо все налаштовано правильно, Healthchecks.io має бути повністю доступний через ваш домен із захищеним HTTPS-з'єднанням. Тепер ви можете увійти, використовуючи створеного раніше суперкористувача, і почати додавати свої перші перевірки.

Конфігурація

Резервне копіювання та обслуговування

Регулярне резервне копіювання та своєчасне обслуговування є запорукою надійності будь-якої системи. Healthchecks.io не виняток. У цьому розділі ми розглянемо, що саме потрібно бекапити, як автоматизувати процес та як підтримувати систему в актуальному стані.

1. Що бекапити

Для повного відновлення Healthchecks.io вам потрібно буде зберегти три основні типи даних:

• База даних PostgreSQL: Містить усі ваші перевірки, пінги, налаштування користувачів, історію подій та сповіщень. Це найкритичніший компонент.
• Файл конфігурації .env: Містить секретний ключ, налаштування SMTP, ключі API та інші важливі параметри.
• Конфігурація Caddyfile: Хоча його легко відтворити, збереження поточної версії може заощадити час при відновленні.

2. Простий скрипт автобекапу

Створимо простий скрипт, який буде виконувати дамп бази даних та копіювати файли конфігурації.

# Створення директорії для скриптів бекапу
mkdir -p ~/backups
nano ~/backups/backup_healthchecks.sh

Додайте наступний вміст у файл backup_healthchecks.sh. Замініть /path/to/healthchecks на фактичний шлях до вашої директорії Healthchecks.io (наприклад, /home/newuser/healthchecks).

#!/bin/bash

# Каталог, де знаходяться файли Healthchecks.io
HEALTHCHECKS_DIR="/home/newuser/healthchecks"
# Каталог для зберігання бекапів
BACKUP_DIR="/home/newuser/backups/healthchecks_data"
# Ім'я файлу дампу бази даних
DB_DUMP_FILE="healthchecks_db_$(date +%Y%m%d_%H%M%S).sql.gz"
# Кількість днів для зберігання локальних бекапів
RETENTION_DAYS=7

# Створення директорії для бекапів, якщо її немає
mkdir -p "${BACKUP_DIR}"

echo "--- Починаємо процес резервного копіювання Healthchecks.io ---"

# 1. Бекап бази даних PostgreSQL
echo "Дампінг бази даних PostgreSQL..."
docker compose -f "${HEALTHCHECKS_DIR}/docker-compose.yml" exec -T db pg_dumpall -U hc | gzip > "${BACKUP_DIR}/${DB_DUMP_FILE}"

if [ $? -eq 0 ]; then
    echo "База даних успішно збережена в ${BACKUP_DIR}/${DB_DUMP_FILE}"
else
    echo "ПОМИЛКА: Не вдалося зберегти базу даних."
    exit 1
fi

# 2. Копіювання файлу .env
echo "Копіювання файлу .env..."
cp "${HEALTHCHECKS_DIR}/.env" "${BACKUP_DIR}/.env_$(date +%Y%m%d_%H%M%S)"

if [ $? -eq 0 ]; then
    echo "Файл .env успішно скопійовано."
else
    echo "ПОМИЛКА: Не вдалося скопіювати файл .env."
fi

# 3. Копіювання Caddyfile
echo "Копіювання Caddyfile..."
sudo cp /etc/caddy/Caddyfile "${BACKUP_DIR}/Caddyfile_$(date +%Y%m%d_%H%M%S)"

if [ $? -eq 0 ]; then
    echo "Caddyfile успішно скопійовано."
else
    echo "ПОМИЛКА: Не вдалося скопіювати Caddyfile."
fi

# 4. Видалення старих бекапів (старше RETENTION_DAYS)
echo "Видалення старих бекапів (старше ${RETENTION_DAYS} днів)..."
find "${BACKUP_DIR}" -type f -name "healthchecks_db_*.sql.gz" -mtime +"${RETENTION_DAYS}" -delete
find "${BACKUP_DIR}" -type f -name ".env_*" -mtime +"${RETENTION_DAYS}" -delete
find "${BACKUP_DIR}" -type f -name "Caddyfile_*" -mtime +"${RETENTION_DAYS}" -delete
echo "Старі бекапи видалено."

echo "--- Процес резервного копіювання завершено ---"

Зробіть скрипт виконуваним:

chmod +x ~/backups/backup_healthchecks.sh

3. Куди складати бекапи (зовнішнє сховище)

Зберігання бекапів на тому ж сервері, що й оригінальні дані, вкрай ризиковано. У разі виходу з ладу сервера або втрати даних, ви втратите й бекапи. Обов'язково налаштуйте копіювання бекапів у зовнішнє, географічно віддалене сховище:

• S3-сумісне сховище (AWS S3, DigitalOcean Spaces, Backblaze B2): Найнадійніший та масштабований варіант. Використовуйте awscli або rclone для автоматичної синхронізації.
• Окремий VPS: Ви можете налаштувати другий, дешевший VPS та використовувати rsync або scp для копіювання бекапів по SSH.
• NFS/SMB Share: Якщо у вас є мережеве сховище, можна монтувати його та копіювати туди файли.

Приклад додавання синхронізації з S3 за допомогою awscli (передбачається, що awscli встановлено та налаштовано):

# Додайте у ваш скрипт backup_healthchecks.sh після секції "Видалення старих бекапів":
echo "Синхронізація бекапів з S3..."
/usr/local/bin/aws s3 sync "${BACKUP_DIR}" s3://your-s3-bucket-name/healthchecks/
if [ $? -eq 0 ]; then
    echo "Бекапи успішно синхронізовані з S3."
else
    echo "ПОМИЛКА: Не вдалося синхронізувати бекапи з S3."
fi

Не забудьте налаштувати awscli на сервері з відповідними обліковими даними та правами доступу до вашого S3-бакету.

4. Автоматизація з Cron

Додайте скрипт бекапу в Cron для автоматичного виконання. Наприклад, для щоденного бекапу о 03:00 ночі:

# Відкриття crontab для поточного користувача
crontab -e

Додайте наступний рядок у кінець файлу:

0 3 * * * /home/newuser/backups/backup_healthchecks.sh >> /home/newuser/backups/backup.log 2>&1

Цей рядок запускає скрипт щодня о 03:00 та перенаправляє весь вивід (включаючи помилки) у файл backup.log для подальшої перевірки.

5. Оновлення: Rolling vs Maintenance Window

Регулярні оновлення критично важливі для безпеки та отримання нових функцій.

• Оновлення ОС: Рекомендується виконувати раз на місяць.

  
  sudo apt update && sudo apt upgrade -y
  sudo apt autoremove -y && sudo apt clean
  

• Оновлення Docker-контейнерів (Healthchecks.io, PostgreSQL, Redis):

  Healthchecks.io оновлюється шляхом отримання нових образів Docker. Це можна робити без значного простою (rolling update), якщо ви використовуєте кілька екземплярів, але для одного VPS знадобиться коротке вікно обслуговування.

  
  cd ~/healthchecks
  # Зупинка сервісів
  docker compose down
  
  # Отримання останніх образів
  docker compose pull
  
  # Запуск сервісів з новими образами
  docker compose up -d
  
  # Видалення старих, невикористовуваних образів та томів
  docker system prune -f
  docker volume prune -f
  

  Рекомендується виконувати ці кроки у заздалегідь визначене вікно обслуговування, щоб мінімізувати вплив на користувачів. Перед оновленням завжди перевіряйте офіційну документацію Healthchecks.io на предмет змін у конфігурації або міграцій бази даних, які можуть вимагати додаткових кроків.

Пам'ятайте, що регулярне тестування процесу відновлення з бекапів так само важливе, як і саме створення бекапів. Це гарантує, що у випадку збою ви зможете швидко відновити свою систему.

Вирішення проблем + FAQ

Навіть при найретельнішому налаштуванні можуть виникнути проблеми. Цей розділ допоможе вам діагностувати та вирішити найпоширеніші неполадки, а також відповість на часто задавані питання.

Не можу отримати доступ до Healthchecks.io через браузер. Що перевіряти?

Якщо ви не можете відкрити веб-інтерфейс Healthchecks.io за вашим доменним ім'ям (наприклад, https://monitor.yourdomain.com), перевірте наступне:

1. DNS-запис: Переконайтеся, що A-запис вашого домену коректно вказує на IP-адресу вашого VPS. Використовуйте dig monitor.yourdomain.com або онлайн-інструменти.
2. Брандмауер (UFW): Перевірте, чи відкриті порти 80 (HTTP) та 443 (HTTPS) на вашому VPS. Використовуйте sudo ufw status verbose.
3. Caddy: Переконайтеся, що служба Caddy запущена (sudo systemctl status caddy) і що його конфігураційний файл (/etc/caddy/Caddyfile) коректно налаштований та вказує на правильний порт (127.0.0.1:8000). Перевірте логи Caddy: sudo journalctl -u caddy -f.
4. Docker-контейнери: Переконайтеся, що всі контейнери Healthchecks.io запущені: cd ~/healthchecks && docker compose ps. Усі контейнери (db, redis, web) повинні бути в статусі Up.
5. SITE_ROOT в .env: Переконайтеся, що змінна SITE_ROOT у файлі .env встановлена на повний HTTPS-URL вашого домену (наприклад, https://monitor.yourdomain.com).

Контейнер Healthchecks.io (web) не запускається або постійно перезапускається.

Це зазвичай вказує на проблему з конфігурацією або залежностями. Перевірте логи контейнера:

cd ~/healthchecks
docker compose logs web

Шукайте повідомлення про помилки у виводі. Типові причини:

• Проблеми з базою даних: Невірні облікові дані в .env (DB_USER, DB_PASSWORD), або контейнер db не запущений.
• Некоректний SECRET_KEY: SECRET_KEY повинен бути довгим, випадковим рядком.
• Проблеми з міграціями: Переконайтеся, що python manage.py migrate було виконано успішно.
• Проблеми з Redis: Контейнер redis не запущений або недоступний.

Не надходять сповіщення електронною поштою.

Перевірте наступні пункти:

1. Налаштування SMTP в .env: Переконайтеся, що всі змінні EMAIL_HOST, EMAIL_PORT, EMAIL_HOST_USER, EMAIL_HOST_PASSWORD, EMAIL_USE_TLS та DEFAULT_FROM_EMAIL у файлі .env налаштовані коректно для вашого SMTP-провайдера.
2. Тестовий лист: Спробуйте відправити тестовий лист з консолі Healthchecks.io:

   
   cd ~/healthchecks
   docker compose run --rm web python manage.py sendtestemail [email protected]
               

   Це повинно показати помилки відправки, якщо вони є.

3. Брандмауер VPS: Переконайтеся, що ваш VPS може встановлювати вихідні з'єднання на порт SMTP вашого провайдера (зазвичай 587 або 465).
4. Спам-фільтри: Перевірте папку "Спам" у вашій поштовій скриньці.

Пінги не реєструються в Healthchecks.io.

Якщо ваші завдання відправляють пінги, але Healthchecks.io їх не бачить:

1. URL пінгу: Переконайтеся, що URL, який використовує ваше завдання для відправки пінгу, абсолютно точний (включаючи UUID перевірки). Він повинен бути у форматі https://monitor.yourdomain.com/ping/YOUR_CHECK_UUID/.
2. Мережева доступність: Переконайтеся, що сервер, який відправляє пінг, може досягти вашого інстансу Healthchecks.io. Перевірте за допомогою curl -I https://monitor.yourdomain.com з сервера, що відправляє пінг.
3. PING_KEY: Якщо ви встановили змінну PING_KEY у .env, переконайтеся, що ваші завдання відправляють цей ключ у заголовку X-Ping-Key.
4. Часовий пояс: Переконайтеся, що часові пояси на VPS та в Healthchecks.io налаштовані коректно, щоб уникнути проблем з розкладом.

Який VPS-конфіг мінімально підійде?

Для базового використання Healthchecks.io, моніторингу десятків або навіть пари сотень завдань, мінімально підійде VPS з 1 vCPU, 1-2 ГБ RAM та 20-40 ГБ SSD. Цього буде достатньо для роботи операційної системи, Docker, Healthchecks.io та його бази даних. Однак, для більшої стабільності та можливості зростання рекомендується 2 vCPU, 4 ГБ RAM та 60-80 ГБ SSD.

Що вибрати — VPS чи dedicated для цього завдання?

Для більшості користувачів та сценаріїв моніторингу Healthchecks.io на VPS є оптимальним рішенням. Він економічно ефективний, достатньо продуктивний та забезпечує необхідний рівень ізоляції. Dedicated-сервери виправдані лише в дуже специфічних випадках: при моніторингу сотень тисяч або мільйонів завдань, коли потрібна максимальна продуктивність та повна відсутність "сусідського шуму", або за наявності суворих вимог до фізичної ізоляції обладнання.

Висновки та наступні кроки

Вітаємо! Ви успішно встановили та налаштували Healthchecks.io на вашому VPS, забезпечивши надійний моніторинг для ваших Cron-завдань та фонових процесів. Тепер у вас є повний контроль над вашою системою моніторингу, що забезпечує своєчасні сповіщення про будь-які збої або затримки в роботі ваших критично важливих завдань. Це значно підвищить надійність вашої інфраструктури та дозволить оперативно реагувати на проблеми.

Наступні кроки

1. Інтеграція зі сповіщеннями: Налаштуйте додаткові канали сповіщень Healthchecks.io, такі як Slack, Telegram, PagerDuty або користувацькі вебхуки, щоб отримувати сповіщення найбільш зручним для вас способом.
2. Додаткові перевірки: Почніть додавати всі ваші періодичні завдання в Healthchecks.io. Розгляньте моніторинг не тільки скриптів, а й регулярних операцій, таких як оновлення кешів, перевірка дискового простору або виконання очищення логів.
3. Моніторинг ресурсів сервера: Для повного огляду стану вашої системи розгляньте встановлення додаткового інструменту моніторингу ресурсів сервера, такого як Netdata або Prometheus/Grafana, щоб відстежувати CPU, RAM, диск та мережу вашого VPS.