Search
Write a publication
Pull to refresh

Comments 16

А как быть с ситуацией, что Grafana OnCall будет заархивирована 2026-03-24? Есть ли достойные альтернативы? По ощущением, например, Alerta куда хуже.

Достойных opensource self-hosted альтернатив не вижу.

Отличная вещь, но судя по тому, что ее купил Elastic, они пойдут таким же путем, как OnCall.

Посмотрите на нашу альтернативу Графане, IMPulse.
Из плюсов: у нас меньше шума по инцидентам благодаря incident lifecycle, удобней строятся роуты, потому что это делается в коде. IaC есть, в коде нет лишнего мусора (подход KISS). Статья для ознакомления здесь. С тех пор появилась интеграция с Telegram, интеграция с Google Calendar и другие более мелкие фичи - мы активно развиваем наш продукт.

Если есть вопросы / критика, можно написать в группу Telegram или в личку.

Пока что много забот. Надо найти время посмотреть.

Выглядит очень интересно; Надо будет попробовать прикрутить для теста. Спасибо!

Если есть вопросы / критика, можно написать в группу Telegram или в личку.

А можно спросить Вас здесь? Есть несколько вопросиков:

  1. В OnCall есть UI с разделом "Alert Groups", в котором я вижу список алертов, их статусы, интеграции, могу провалиться в каждую группу и увидеть подробности (лейблы) каждого алерта. Правильно ли я понимаю, что у вас UI в принципе нет и Импульс - это по сути просто шлюз (упрощаю конечно) между алертменеджером и мессенджером? Если всё так, на сколько удобно смотреть аналогичную инфу например для 20 алертов в телеге? А если 200? Или я всё не верно понимаю?

  2. В статье вы пишите :

    "Одна из проблем, которая меня раздражала в OnCall, - это большое количество инцидентов и, соответственно, уведомлений. Возникает она потому что многие алерты имеют плавающий характер: он то в статусе “firing”, то в статусе “resolved”. И каждое такое переключение создаёт новый инцидент в OnCall, хотя это не новая, а всё та же проблема."

    Не пробовали решать эту проблему используя keep_firing_for ?

  3. Также вы пишите:
    "мы избегаем использования дополнительных решений типа баз данных, менеджеров очередей и т. д., которые усложняют конфигурацию"


    Что будет с алертами, если придётся перезапустить импульс?

  4. Есть ли подводные камни/особенности, о которых стоит знать, при интеграции с jiralert через вебхук?

Конечно.

1. UI у нас появится в ближайшее время. Вот описание из соотвестсвующей ветки. О появлении сообщим в группу TG.

2. Нет, так решать не пробовали, мне кажется, это не совсем корректно. Если условие алерта не выполняется, то он должен позеленеть и об этом желательно быстрей узнать. Если выставить эту опцию маленькой (5 мин), то не все флипы она обработает, а если большой (скажем, 15 мин) - то слишком долго алерты будут показывать некорреткный state.
Наше решение мне кажется оптимальным. Если попробуете, будет интересно узнать ваше мнение.

3. Всё отработает корректно. Мы храним только файлы инцидентов, в них же хранится состояние chain'ов. Если понадобится, то будем хранить больше информации, но пока хватает. Стараемся идти по пути минимализма.

4. К сожалению, не смогу подсказать, с Jiralert не сталкивался. Но если каких-то возможностей текущего webhook'а вам не хватит, пишите - мы быстро добавим.

Спасибо за ответы!
Буду следить за развитием вашего продукта, и возможно внедрим его у себя

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

Имхо алерт должен быть как выстрел - вовремя, четко, кратко и в точку.

Данный подход имеет право на жизнь и даже стек вменяемый. Проблема в другом. В том, что количество алертов улетает в космос. И графана - худший инструмент. Для BI есть redash, tableau etc. Для мониторинга уже придумали https://github.com/perses/perses По алертам и сработкам - вообще надо подход менять. Я тут пару раз попадал в ситуацию, когда ты дебажишь проблему, а это... в дашбордах только тонешь. Я считаю, что будущее за решениями вроде https://coroot.com/ - кстати, опенсурс. Они строят систему наблюдаемости с другой точки зрения. Не давайте напилим 100500 разных алертов на разные события, а зайдем с ключевых метрик приложений и нарушения SLA.

Я считаю, что будущее за решениями вроде https://coroot.com/ - кстати, опенсурс. Они строят систему наблюдаемости с другой точки зрения

Очень похоже на Dynatrace. И да, подход очень интересный!

@chemtech форматирование там добавь, плиз, чтобы подсветка была. Баш - баш, ямл - ямл итп

Sign up to leave a comment.

Articles