Alertmanager-jira для интеграции алертов в jira

[Z55]

Честно говоря, не очень понятно, это замена классическому алертменеджеру?

Ну и несколько моментов:

Очень ограниченное количество настроек (переоткрывать или нет, шаблон, ну ещё парочку). Конфиг по ресиверам, но без глубокого контроля над полями — всё через YAML с базовыми шаблонами. Нет нормальной поддержки кастомных полей или динамических JQL-запросов для обновлений.

А что ещё нужно? Можете рассказать про какую-то киллер-фичу, которая есть у alertmanager-jira, но нет у jiralert? И что значит "нет нормальной поддержки кастомных полей"? Такого недостаточно "customfield_13011: {"value": "Другое"}"? Конфиг через yaml. Но вроде и в статье тоже yaml?

Очень длинный хеш алерта для идентификации, такой, что часто даже рушит интерфейс. Работать очень неудобно. Хеш по group_key может быть огромным, ломая UI Jira. На одном из предыдущих мест работы мы даже специально патчили его, чтобы укоротить.

Даже с активным флагом hash-jira-label ? Но тут больше вопросы к создателям jira, ибо если в поле 255 символов, и полное заполнение поля ломает разметку, то выглядит как баг.

[Hubbitus]

Честно говоря, не очень понятно, это замена классическому алертменеджеру?

Ни в коем случае! Это кракраз интеграция с ним, чтобы алерты из него в JIRA класть. Это альтернатива jiralert.

А что ещё нужно? Можете рассказать про какую-то киллер-фичу, которая есть у alertmanager-jira, но нет у jiralert?

Например, попробуйте лейблы указать в jiralert для задачи, исходя из значений алерта. Никак. Или записать их значение в компонент. Или указать какие задачи переоткрывать, а какие комментировать...

Даже с активным флагом hash-jira-label ? Но тут больше вопросы к создателям jira, ибо если в поле 255 символов, и полное заполнение поля ломает разметку, то выглядит как баг.

Во-первых, поле label это теги, для коротких литералов вроде alert, airflow, serviceX. Оно не предполагает что там будет текст произвольной длины. Обработать на UI и как-то сократить, конечно могли бы и на стороне Jira, не спорю, но почему-то я думаю они даже не предполагали что кто-то туда будет главку из Онегина писать.
Но, во вторых, тут важно, другое. Не всегда именно такая идентификация нужна. Например, у нас часть алертов идентифицируется как fingerprint, который сам же alertmanager и формирует. Он стабильнее, и не включает значение value алерта, если вы его используете в label, например. А часть идентифицируются вообще иначе, у нас в практике есть скажем по лейблу dag:{some_name}. Здесь вы можете это настроить как хотите. В jiraalert - не получится.

[Z55]

Например, попробуйте лейблы указать в jiralert для задачи, исходя из значений алерта. Никак. Или записать их значение в компонент. Или указать какие задачи переоткрывать, а какие комментировать...

Лейблы мы не используем, jiralert кладёт туда хеш, поэтому не мешает.
Компоненты также не используем.
"Переоткрывать или комментировать" - это мы настраивали флагами и переходами в jira. Но у вас думаю у вас это можно более гибко настроить, надо посмотреть как.

В любом случае, спасибо за продукт! Возможно когда дойдут руки, потестируем, сравним с jiralert.

[Hubbitus]

"Переоткрывать или комментировать" - это мы настраивали флагами и переходами в jira. Но у вас думаю у вас это можно более гибко настроить, надо посмотреть как.

Тут думаю некоторое недопонимание произошло того что я выше сказал. Я имел в виду что, например, случай, когда была создана задача в джире о проблеме из алерта. Она висит, какое-то время открытой, её никто не берёт. Вы настраиваете в алертменеджере в алерте чтобы он скажем каждый день повторялся (одна опция), и в джиру можно в задачу добавлять что-то вроде "проблема до сих пор актуальна" (а можно и более сложный шаблон сделать, скажем указать количество часов актальности проблемы или что-то подобное). Этот "пинг" исполнителю отзовётся в почте - вдруг забыл? У нас ещё и в чатики ГидМост приходит, но это отдельная история.

И спасибо за отклик! Буду рад фидбеку, если попробуете

[Z55]

 в джиру можно в задачу добавлять что-то вроде "проблема до сих пор актуальна" 

Мы специально отключили авто резолв, ибо если инцидент был, его надо разбирать, даже если проблема уже не актуальна. Как говорится, "у любой проблемы должно быть имя, фамилия и должность" - это про нас ))

Но фича интересная, согласен

[Hubbitus]

Я такого же мнения придерживаюсь! Мы тоже отключили авторезолв. Но вот комментарий, например о том что проблема больше не актальна, или дополнительные данные по алерту (скажем сколько ещё неразобранных сообщений в качка топике или количество упавших дагов, или количество ошибок и т.д.), может быть весьма полезна тому кто будет разбирать.

[Hubbitus]

Кстати, про длинные хеши и что их плохо хранить в лейблах я далеко не одинок, вот такой реквест в их трекере лежит ... годами: https://github.com/prometheus-community/jiralert/issues/164