Алерты от grafana alerts и alertmanager: они всегда такие неудобные?

Так зачем вы неудобные делаете? Делайте удобные.

ой, ну самый простой ответ, конечно. Ты хоть переходил туда? Я говорю про дефолт.

суть мониторинга в классическом понимании ITIL, заключается в том, чтобы кто-то сообщал о проблемах несколько раньше (скажем за час до) чем пользователи, а уж тем более начальство, начнут предъявлять претензии (иначе будет: Шеф, все пропало! Гипс снимают, клиент уезжает!). Графана и иже с ними - это никак не мониторинги, они просто какие-то метрики собирают, которые уже после аварии можно хоть как-то попытаться скоррелировать и худо-бедно установить (а может и не установить, всякое бывает) из-за чего проблема возникла.

заключается в том, чтобы кто-то сообщал о проблемах несколько раньше

Поэтому там есть алерты.

Графана и иже с ними - это никак не мониторинги

И поэтому графана это конечно же мониторинг. Хватит чушь нести.

А как у вас?

А у нас в квартире газ. А у тревог в Alertmanager есть понятные названия, позволяющие определить что случилось, метки, указывающие где случилось, длинные описания и ссылки на runbook и выражение prometheus’а в аннотациях. Чего вам ещё нужно?

Это очень отличается от моего представления о полезном алерте, в котором при переходе должно быть плюс-минус понятно, что вообще происходит и что делать Может быть такое требование очень дорогое в реализации?

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

Я говорю про дефолт.

А что ты хочешь видеть в дефолте про что вообще происходит и что делать? Типа ахтунг, ахтунг, приложение сожрало всё память, срочно докиньте пару плашек?

Ну все правильно, приходит алерт: «Шеф, на диске осталось меньше 20% места, посмотри». С этим графана отлично справляется. Ну и при желании можно ошибки слать и видеть все, постфактум, но тем не менее сразу как проблема появилась.

У нас простые алерты, типа: «Задача xxx не выполнилась» или «Сервис xxx не запущен», «Очередь кафки xxx забита» и тд. при этому у алертов есть параметр - хост, где конкретно это что-то сломалось.

Что происходит детально (логи, трейсбеки) и что делать в алертах не написано и не должно я думаю.

т.е. по факту я хочу от девелоперского инструмента для постфактум анализа работы по ИТИЛю?

Ну вообще, как я вижу, то вот этот подход с метриками он не совсем для этого. То есть да, по ним можно увидеть надвигающуюся проблему, или проблему в самом разгаре, в общем виде, и так далее, но для прямо алертов и всего такого надо включать event-based мониторинг, отдельный, это условно говоря, обобщение концепции «логов», что-то типа Sentry и так далее. Ну я когда-то в подобной компании также работал, AlertLogic называлась. Вот там все было именно про евенты какие-то.

Я говорю про дефолт.

Там нет дефолта. Графана - визуализатор, алертменеджер - инструмент отправки уведомлений. То, что алерт описан плохо - это не проблема визуализатора, это ваша проблема, потому что вы взяли конфиг непонятного васяна из интернетов и почему-то он вам не подошел.

Настраивайте сами со своими параметрами. А то дефолтный алерт node_exporter на 70% юз оперативки актуален, когда ее гига четыре. А когда у сервака 1тб оперативки, нет смысла орать, если осталось 300гб.

Ну вообще, как я вижу, то вот этот подход с метриками он не совсем для этого. То есть да, по ним можно увидеть надвигающуюся проблему, или проблему в самом разгаре, в общем виде, и так далее, но для прямо алертов и всего такого надо включать event-based мониторинг, отдельный, это условно говоря, обобщение концепции «логов», что-то типа Sentry и так далее. Ну я когда-то в подобной компании также работал, AlertLogic называлась.

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

• На любой эвент можно сделать метрику, но не наоборот
• Алерты бывают не только по фронту, но и по уровню
• Алерты должны гибко настраиваться в том числе порогами и оконной агрегацией (срабатывать если минимальное значение за 1 час больше X), это никак не ложится на эвенты.
• На метриках проще искать аномалии.

Ну т.е. можно конечно же из эвентов сделать метрики и по ним делать алерты, но всё же метрики для алертов обязательны.

По факту, ты хочешь, чтобы дефолт тебе подходил идеально. Такое бывает только если ты сам пишешь ПО и задаёшь его дефолты. В ином случае дефолт – это отправная точка, а не то, что используется напрямую без доработок.