VPS для бота-уведомителя: мониторинг и алерты 24/7

Бот-уведомитель следит за сайтами, серверами и метриками и шлёт алерт в Telegram, когда что-то ломается. Такому боту нужен независимый сервер: если он стоит на той же машине, что и объект мониторинга, он умрёт вместе с ней.

Зачем уведомителю отдельный VPS

Главный принцип мониторинга: наблюдатель должен быть независим от объекта. Если бот, следящий за вашим сайтом, живёт на том же сервере, то при падении сервера вы не получите алерт — упадёт и наблюдатель.

Поэтому уведомителя выносят на отдельный дешёвый VPS, желательно в другой локации. Оттуда он пингует ваши сервисы снаружи — ровно так, как их видят пользователи.

• Внешняя точка обзора — видите то же, что и клиенты.
• Независимость — падение объекта не выключает мониторинг.
• Дёшево — уведомителю хватает младшего тарифа.

Отправка алерта в Telegram через curl

Отправить сообщение боту можно одним запросом к Bot API — никакой библиотеки не нужно. Создайте бота у @BotFather, узнайте свой chat_id и проверьте отправку:

BOT_TOKEN='123456:AA...'
CHAT_ID='100500'
curl -s "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
  --data-urlencode "chat_id=${CHAT_ID}" \
  --data-urlencode "text=Тест: уведомитель на связи"

Этого достаточно, чтобы встроить алерты в любой bash-скрипт мониторинга.

Скрипт мониторинга сайтов

Простой health-check: проверяем HTTP-код и шлём алерт только при проблеме. Флаг-файл не даёт спамить одинаковыми сообщениями каждую минуту.

#!/usr/bin/env bash
set -euo pipefail
source /opt/notifier/.env   # BOT_TOKEN, CHAT_ID
URL='https://example.com/health'
FLAG='/tmp/notifier_down'

notify() {
  curl -s "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
    --data-urlencode "chat_id=${CHAT_ID}" \
    --data-urlencode "text=
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.
Арендовать VPS для бота-уведомителя
Отправка алерта в Telegram через curl
Отправить сообщение боту можно одним запросом к Bot API — никакой библиотеки не нужно. Создайте бота у @BotFather, узнайте свой chat_id и проверьте отправку:
BOT_TOKEN='123456:AA...'
CHAT_ID='100500'
curl -s "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
  --data-urlencode "chat_id=${CHAT_ID}" \
  --data-urlencode "text=Тест: уведомитель на связи"
Этого достаточно, чтобы встроить алерты в любой bash-скрипт мониторинга.
Скрипт мониторинга сайтов
Простой health-check: проверяем HTTP-код и шлём алерт только при проблеме. Флаг-файл не даёт спамить одинаковыми сообщениями каждую минуту.
#!/usr/bin/env bash
set -euo pipefail
source /opt/notifier/.env   # BOT_TOKEN, CHAT_ID
URL='https://example.com/health'
FLAG='/tmp/notifier_down'

notify() {
  curl -s "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
    --data-urlencode "chat_id=${CHAT_ID}" \
    --data-urlencode "text=$1" >/dev/null
}

code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 10 "$URL" || echo 000)
if [ "$code" != "200" ]; then
  [ -f "$FLAG" ] || notify "🔴 $URL недоступен (код $code)"
  touch "$FLAG"
else
  if [ -f "$FLAG" ]; then notify "🟢 $URL снова работает"; rm -f "$FLAG"; fi
fi
sudo mkdir -p /opt/notifier
sudo mv check.sh /opt/notifier/ && sudo chmod +x /opt/notifier/check.sh
Таймер systemd вместо cron
Таймеры systemd надёжнее cron: у них есть логи, зависимости и защита от наложений запусков. Создаём service и timer:
sudo tee /etc/systemd/system/notifier.service >/dev/null <<'EOF'
[Unit]
Description=Site health check

[Service]
Type=oneshot
ExecStart=/opt/notifier/check.sh
EOF
sudo tee /etc/systemd/system/notifier.timer >/dev/null <<'EOF'
[Unit]
Description=Run health check every minute

[Timer]
OnBootSec=1min
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now notifier.timer
systemctl list-timers notifier.timer
Что ещё стоит мониторить
Тот же подход расширяется на любые метрики самого сервера — место на диске, память, нагрузку. Пример проверки диска:
use=$(df / | awk 'END{gsub("%","",$5); print $5}')
[ "$use" -gt 90 ] && notify "⚠️ Диск заполнен на ${use}%"
Аптайм сайтов и API — HTTP-код и время ответа.
Ресурсы сервера — диск, RAM, load average.
Сертификаты TLS — алерт за 14 дней до истечения.
SSH-входы — уведомление о новом логине.
Где брать сервер и частые ошибки
Уведомителю нужен минимум ресурсов — младшего тарифа хватает с запасом. На MAATRIX это AMD EPYC + NVMe от $8/мес с ежедневными бэкапами, а три локации (UK, США и РФ) позволяют держать мониторинг в другой стране относительно ваших основных серверов — так вы поймаете и региональные сетевые сбои. Оплата картой РФ, СБП, криптой или токеном MAAT.
Уведомитель на том же сервере — не сообщит о его падении.
Нет защиты от повторов — бот засыпет вас алертами каждую минуту.
Малый --max-time или его отсутствие — ложные срабатывания на медленном ответе.
cron без логов — молчаливые сбои проверки; берите systemd-таймер.

  
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.
Арендовать VPS для бота-уведомителя
" >/dev/null
}

code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 10 "$URL" || echo 000)
if [ "$code" != "200" ]; then
  [ -f "$FLAG" ] || notify "🔴 $URL недоступен (код $code)"
  touch "$FLAG"
else
  if [ -f "$FLAG" ]; then notify "🟢 $URL снова работает"; rm -f "$FLAG"; fi
fi

sudo mkdir -p /opt/notifier
sudo mv check.sh /opt/notifier/ && sudo chmod +x /opt/notifier/check.sh

Таймер systemd вместо cron

Таймеры systemd надёжнее cron: у них есть логи, зависимости и защита от наложений запусков. Создаём service и timer:

sudo tee /etc/systemd/system/notifier.service >/dev/null <<'EOF'
[Unit]
Description=Site health check

[Service]
Type=oneshot
ExecStart=/opt/notifier/check.sh
EOF

sudo tee /etc/systemd/system/notifier.timer >/dev/null <<'EOF'
[Unit]
Description=Run health check every minute

[Timer]
OnBootSec=1min
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now notifier.timer
systemctl list-timers notifier.timer

Что ещё стоит мониторить

Тот же подход расширяется на любые метрики самого сервера — место на диске, память, нагрузку. Пример проверки диска:

use=$(df / | awk 'END{gsub("%","",$5); print $5}')
[ "$use" -gt 90 ] && notify "⚠️ Диск заполнен на ${use}%"

• Аптайм сайтов и API — HTTP-код и время ответа.
• Ресурсы сервера — диск, RAM, load average.
• Сертификаты TLS — алерт за 14 дней до истечения.
• SSH-входы — уведомление о новом логине.

Где брать сервер и частые ошибки

Уведомителю нужен минимум ресурсов — младшего тарифа хватает с запасом. На MAATRIX это AMD EPYC + NVMe от $8/мес с ежедневными бэкапами, а три локации (UK, США и РФ) позволяют держать мониторинг в другой стране относительно ваших основных серверов — так вы поймаете и региональные сетевые сбои. Оплата картой РФ, СБП, криптой или токеном MAAT.

• Уведомитель на том же сервере — не сообщит о его падении.
• Нет защиты от повторов — бот засыпет вас алертами каждую минуту.
• Малый --max-time или его отсутствие — ложные срабатывания на медленном ответе.
• cron без логов — молчаливые сбои проверки; берите systemd-таймер.

Частые вопросы