Это не анонсированная третья часть. Первые две здесь:
1. Подготовка Django приложения для локальной разработки и деплоя
2. Django приложение в докере. Логирование и мониторинг (тоже в докере)
Не анонсированная, потому что этот способ подходит для любого приложения с метриками через Prometheus, но как настраивать их для конкретного Django приложения можно посмотреть в предыдущих частях.
Для начала нужно создать telegram-бота, находим бота BotFather и создаем нового бота в нем с помощью команды /newbot, получаем токен вашего бота.
Теперь нужно получить ChatId. Для этого, напишите вашему новому боту сообщение, а затем откройте в браузере(желательно инкогнито, а еще лучше curl-ом) следующий адрес:
https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getUpdates
Заменив <YOUR_BOT_TOKEN> на токен вашего бота. В ответе вы получите json с информацией о последних сообщениях, отправленных вашему боту. В этом JSON найдите поле chat, которое будет содержать ваш id.
Значение поля id внутри объекта chat — это и есть ваш Chat ID.
Ну, основное позади.
Далее переходим в графану Home → Alerting → Contact points
Там у вас, если еще не было Contact points редактируем единственный существующий.
Вводим любое название и в поле Integration выбираем Telegram.
Там указываем BOT API Token и Chat ID полученные ранее, сохраняем.
Переходим в Alert rules в том же Alerting и создаем новое правило — New alert rule.
Тут мы подразумеваем, что у вас уже есть настроенный на приложение Prometheus, хотя бы из предыдущих шагов.
Итак, в первом поле вводим любое название правила. Ниже в А выбираем Prometheus, в Metric вводим up и в лэйблах выбираем приложение. Далее в B выбираем input A, Function — Min, Mode — Strict. В С(Threshold) выбираем Input — B, ниже IS BELOW — 1.
Можно нажать Preview и убедиться, что правило отрабатывает.
Далее в п. 3 можно выбрать папку, куда положить правило и период ожидания.
4 пункт заполняем так же по желанию.
В п. 5 указываем произвольные лэйблы для правила. Они по-сути нужны для верного выбора нотификатора.
Ну и последний в статье этап — выбор политик нотификации: переходим в Notification policies там же в Alerting, нажимаем три точки напротив Default policy — Edit и меняем Default contact point на созданную нами на соответствующем этапе. Сохраняем. Все!
Теперь у нас настроены нотификации от бота в телеграмме если метрика up в Prometheus-е упадет ниже 1.
Комментарии (5)
m1skam
23.09.2024 16:48+3А чем это лучше официальной документации? Я бы понял, если бы еще был приведет пример настройки сontact points совместно с notification policy или шаблона сообщений с передачей SilenceURL, DashboardURL и PanelURL. В крайнем случае более сложные настройки самого алерта.
Там у вас, если еще не было Contact points редактируем единственный существующий.
Не надо так делать. Делается отдельный contact point, который либо указывается в настройках алерта, либо, что ИМХО более правильно, настриваются notification policy.
Далее в п.3 можно выбрать папку, куда положить правило и период ожидания.
Период ожидания чего?
Итак, в первом поле вводим любое название правила. Ниже в А выбираем Prometheus, в Metric вводим up и в лэйблах выбираем приложение.
А если приложение несколько? А если подобную метрику отдает не только django?
Далее в B выбираем input A, Function — Min, Mode — Strict. В С(Threshold) выбираем Input — B, ниже IS BELOW — 1.
А вы точно понимаете значение того, что делаете? Если у вас метрика UP, скорее всего у вас может приходить только 2 значения 1 или 0, зачем там делать reduce?
В п.5 указываем произвольные лэйблы для правила. Они по-сути нужны для верного выбора нотификатора.
Выбор нотификатора, я подразумеваю, что речь идет о блоке Configure labels and notifications, который таки идет под номером 4, а в 5м блоке вы можете детально расписать ошибку и этот тест отобразится в сообщении алерта и да, этот текст тоже шаблонизируется, можно добавлять лейблы полученные в promql запросе, к примеру имя сервиса.
famer Автор
23.09.2024 16:48Я очень рад этому комментарию. Все по делу.
Если у вас больше одного приложения и больше одного канала нотификации, обратите на него внимание.
У меня описан самый простой случай
m1skam
23.09.2024 16:48+1Не бывает "самого простого" случая.
Ладно, ок, возможно в какой то вселенной, есть инсталяции где prometheus и grafana ставят ради одной метрики, но мне очень сложно представить такой случай, просто потому что, знать, что у вас жив серсис по метрики UP, ИМХО, не достаточно.
Скорее всего хочется знать и понимать, а что поисходит с хостом, на котором крутится это приложение. Если ли там еще ресурс CPU, достаточно ли памяти или памяти уже под 90% занято и скоро все свалится в OOM, а что там с местом на диске, есть ли место под ваши данные?
А если там есть публичная часть через nginx с доменом и сертификатом, то было бы здорого знать что nginx жив, что нет резких выбросов по трафику, что сертификаты корректно обновляются и скро жизни сертификата не менее 15 дней, потому что если срок жизни сертификата менее 15 дней и они у вас от letsencrypt это означает, что либо вы не смогли по какой то причине получить новый, либо certbot или его аналог не смог попросить nginx перечитать конфигурацию и тд и тп.
Ну и в догонку. Телеграм это канал для оперативной доставки нотификаций, для алертов которые требуют действий - вот прямо сейчас. Дефолтный канал, по умолчанию шлет в почту, алерты из почты вы прочитаете когда до нее дойдете и тогда уже будете принимать решение делать что либо или нет. Думаю разница очевидна.
aborouhin
23.09.2024 16:48Там самая замысловатая часть задачи - настройка хорошего шаблона. И язык шаблонизатора оригинальный, и писать приходится нечитаемо, чтобы разрывы строк в сообщение не попадали, и телега некоторые символы не принимает, молча сваливаясь в ошибку, так что переменные надо подчищать...
space2pacman
Нотификации? Почему не "уведомления"?