Свой Gotify или привычный бот в Telegram: кто владеет вашими алертами

MAATRIX

Если у вас уже есть бот, который шлёт алерты в Telegram-чат, вопрос «зачем что-то менять» логичен — работает же. Но возникает другой: что будет, если Telegram недоступен в вашей сети или у оператора именно в момент, когда упал прод? Gotify — self-hosted альтернатива, где канал уведомлений принадлежит вам целиком: сервер, база, доставка. Разберём честно, что вы получаете и что теряете, перенося критичные алерты со привычного бота на свой Gotify.

Разница в архитектуре: чья это инфраструктура

Бот-алертер в Telegram — скрипт на вашем сервере, который дёргает Bot API Telegram (api.telegram.org) и отправляет сообщение в чат. Сама доставка после этого — целиком забота Telegram: его серверы, его сеть, его политика доступности в конкретной стране. Вы управляете тем, что отправляете, но не тем, как это долетает до телефона.

Gotify устроен иначе. Это отдельный сервер (написан на Go, распространяется как Docker-образ gotify/server), который вы разворачиваете на своей VPS: REST API для отправки (POST /message с токеном приложения в заголовке X-Gotify-Key), WebSocket-канал для push в реальном времени, веб-интерфейс с историей уведомлений и официальное приложение для Android.

Разница принципиальная: у Telegram-бота один хоп до чужого API, дальше всё делает чужая инфраструктура. У Gotify весь путь — от «скрипт зафиксировал событие» до «пуш на телефоне» — на серверах, которые контролируете вы. Это не значит «надёжнее» в абсолютном смысле: Telegram эксплуатирует куда более отказоустойчивую сеть, чем ваша одна VPS. Это значит «независимее» — сбой у Telegram или блокировка в конкретной сети не затрагивает ваш канал алертов, потому что это разные системы.

Установка: минимальный рабочий стенд

Проще всего поднять Gotify через Docker Compose:

version: "3.8"
services:
  gotify:
    image: gotify/server
    restart: unless-stopped
    ports:
      - "8443:80"
    volumes:
      - ./data:/app/data
    environment:
      - GOTIFY_DEFAULT_USER_NAME=admin
      - GOTIFY_DEFAULT_USER_PASS=сложный-пароль-замените

docker compose up -d

В боевой эксплуатации порт закрывают за reverse-proxy с TLS — настройка стандартная для любого сервиса за Nginx или Caddy. Дальше в веб-интерфейсе: меняете пароль администратора, во вкладке Applications создаёте приложение и получаете токен для отправки, во вкладке Clients — клиент и client-токен для приёма push на телефоне.

Отправка сообщения из скрипта:

curl -s -X POST "https://gotify.example.com/message?token=ВАШ_APP_TOKEN" \
  -F "title=Диск заполнен" \
  -F "message=На /var осталось меньше 10% свободного места" \
  -F "priority=8"

Приоритет (0–10) влияет на то, как клиент показывает уведомление: например, только приоритет 5 и выше показывается как push, остальное просто ложится в ленту. Это гибче, чем в Telegram-боте, где все сообщения выглядят одинаково без ручной разметки по важности.

Что вы реально выигрываете

Полный контроль над каналом. Никто, кроме вас, не может ограничить доступ или изменить правила API без предупреждения. История уведомлений хранится в вашей базе, а не в чужой инфраструктуре.

Независимость от доступности мессенджера в конкретной сети. Если у дежурного инженера в моменте не работает Telegram — блокировка, сбой оператора, недоступность в конкретной стране — алерты через Gotify всё равно долетят, потому что путь доставки не завязан на инфраструктуру мессенджера. Особенно важно, если команда распределена по странам с разной доступностью Telegram.

Открытый протокол без чужих лимитов и с разделением по клиентам. Любой скрипт или система мониторинга, умеющая делать HTTP-запрос, может слать в Gotify — не нужно оглядываться на ограничения стороннего Bot API, только на ресурсы своего сервера. При этом один сервер принимает сообщения от десятка источников (мониторинг, CI/CD, backup-скрипты, cron) и раздаёт их разными токенами — не нужно городить несколько ботов и чатов, как часто приходится в Telegram.

Что вы теряете, отказавшись от привычного бота

Отдельное приложение вместо уже открытого Telegram. У большинства людей Telegram открыт весь день. Gotify требует держать установленным и активным отдельное Android-приложение с постоянным WebSocket-соединением. Это та же проблема, что встречается у других self-hosted push-решений (например, у ntfy) — агрессивные политики энергосбережения Android могут задерживать уведомления, если приложение не получает push через системный сервис. Здесь важнее другое: кому принадлежит канал уведомлений, а не конкретный механизм сбоя доставки на телефоне.

Нет официального iOS-приложения. Заметное ограничение: у Gotify есть Android-клиент и веб-клиент, но нет полноценного официального приложения под iOS. Владельцы iPhone вынуждены либо держать открытой веб-страницу (для push нерабочий вариант — вкладка должна быть активна), либо искать сторонние клиенты сомнительного качества. Если в команде есть люди на iPhone — это довод в пользу гибридной схемы, а не полного отказа от Telegram.

Сервер, который нужно поддерживать самому. Telegram-бот использует чужую готовую инфраструктуру доставки. Gotify — ещё один сервис на вашей VPS: его нужно обновлять, резервировать базу, следить за диском. Возникает классический парадокс мониторинга: система, которая должна сообщать о падении сервера, сама зависит от его работоспособности. Если Gotify стоит на том же хосте, что и то, что он мониторит, при полном отказе хоста алерт некому будет отправить — та же проблема, что в статье про антипаттерн мониторинга на том же сервере, что и прод. Правильная схема — Gotify на отдельной минимальной VPS.

Меньше «удобства мессенджера». У Telegram есть тонкая настройка уведомлений — режим «Не беспокоить» с исключениями, кастомные звуки, удобный поиск по истории. Gotify — минималистичный инструмент под доставку алерта, а не под UX мессенджера.

Интеграция с тем, что уже шлёт алерты

Uptime Kuma. В настройках уведомлений уже есть готовый тип «Gotify»: указываете URL сервера и токен приложения, дальше Uptime Kuma сама формирует запросы при падении и восстановлении мониторов.

Grafana Alerting. Gotify не входит в список встроенных контактных точек Grafana «из коробки» — заводится через Webhook-контакт на https://gotify.example.com/message?token=..., сверьтесь с документацией docs.gotify.net, формат тела запроса может отличаться между релизами.

Cron-скрипты и watchdog-сервисы. Как и с Telegram-ботом, проще всего обернуть curl-запрос в функцию:

notify() {
  curl -s -X POST "https://gotify.example.com/message?token=$GOTIFY_TOKEN" \
    -F "title=$1" -F "message=$2" -F "priority=${3:-5}" > /dev/null
}

notify "Бэкап завершился с ошибкой" "Код возврата: $?" 8

Внешние сервисы для контроля cron-задач обычно тоже поддерживают generic webhook — заводятся на Gotify тем же способом.

Гибридная схема: не выбирать одно вместо другого

На практике рабочее решение — не заменять Telegram Gotify-ем полностью, а развести каналы по важности.

• Telegram остаётся основным каналом для команды — там все уже сидят, там удобно обсуждать инцидент прямо рядом с алертом, там низкий порог входа для новых людей.
• Gotify — резервный или дублирующий канал для критичных алертов (падение прод-сервиса, недоступность самого мониторинга) — на случай, если именно Telegram окажется недоступен в нужный момент.
• Для критичных проверок настраивайте отправку в оба канала сразу — большинство систем мониторинга поддерживают несколько контактных точек без дополнительной сложности.

Эта логика зеркально повторяет то, что уже разобрано в статье про резервный канал уведомлений на случай, если Telegram лёг — там про сам факт наличия запасного пути, здесь — конкретно про Gotify как один из вариантов такого пути. Если у вас пока вообще нет канала алертов, начните с более простого варианта — настройки алертов в Telegram с нуля, а Gotify добавляйте вторым слоем.

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