Comments 5
Нотификации? Почему не "уведомления"?
А чем это лучше официальной документации? Я бы понял, если бы еще был приведет пример настройки с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 запросе, к примеру имя сервиса.
Я очень рад этому комментарию. Все по делу.
Если у вас больше одного приложения и больше одного канала нотификации, обратите на него внимание.
У меня описан самый простой случай
Не бывает "самого простого" случая.
Ладно, ок, возможно в какой то вселенной, есть инсталяции где prometheus и grafana ставят ради одной метрики, но мне очень сложно представить такой случай, просто потому что, знать, что у вас жив серсис по метрики UP, ИМХО, не достаточно.
Скорее всего хочется знать и понимать, а что поисходит с хостом, на котором крутится это приложение. Если ли там еще ресурс CPU, достаточно ли памяти или памяти уже под 90% занято и скоро все свалится в OOM, а что там с местом на диске, есть ли место под ваши данные?
А если там есть публичная часть через nginx с доменом и сертификатом, то было бы здорого знать что nginx жив, что нет резких выбросов по трафику, что сертификаты корректно обновляются и скро жизни сертификата не менее 15 дней, потому что если срок жизни сертификата менее 15 дней и они у вас от letsencrypt это означает, что либо вы не смогли по какой то причине получить новый, либо certbot или его аналог не смог попросить nginx перечитать конфигурацию и тд и тп.
Ну и в догонку. Телеграм это канал для оперативной доставки нотификаций, для алертов которые требуют действий - вот прямо сейчас. Дефолтный канал, по умолчанию шлет в почту, алерты из почты вы прочитаете когда до нее дойдете и тогда уже будете принимать решение делать что либо или нет. Думаю разница очевидна.
Там самая замысловатая часть задачи - настройка хорошего шаблона. И язык шаблонизатора оригинальный, и писать приходится нечитаемо, чтобы разрывы строк в сообщение не попадали, и телега некоторые символы не принимает, молча сваливаясь в ошибку, так что переменные надо подчищать...
Нотификации в telegram о падении приложения, через графану