🤦‍♂️ Не думал, что придется разжевывать простые вещи, но придется: почему Grafana не подходит для алертинга и инцидентов. 👀 Grafana — это “витрина” метрик. Она отлично рисует графики, даёт ад-hoc анализ, аннотации, переменные, сравнения и т. п. Это про наблюдение. 🚨 Алертинг — это отдельный контур. Его делают движки правил (Prometheus rules / vmalert) + маршрутизатор уведомлений (Alertmanager) + «пейджер» с гарантиями доставки (Opsgenie/PagerDuty и т. п.). Это про управление инцидентами. 💡 Почему это стоит разделять: • Надёжность: движки правил и Alertmanager спроектированы под HA, ретраи, дедупликацию, ингибишн, тайминги, “maintenance windows”. Grafana — не про гарантии доставки. • Чёткие зоны ответственности: дашборды ≠ жизненный цикл алертов (эскалации, расписания, SLO/SLA). • Управление: сотни/тысячи правил удобнее хранить/версионировать как код (rules/CRD), а не в UI дашборда. • Роутинг и подавление шума: Alertmanager умеет группировать, подавлять каскадные алерты, ставить “silences” — этого часто не хватает в “встроенном” алертинге. ⚠️ Да, есть “Unified Alerting”, это удобно для быстрой проверки правил на графиках. Но: ❌ нет (или ограничены) полноценные дедуп/ингибиции/сложный роутинг/федерация; ❌ сложнее обеспечить HA и гарантии доставки; ❌ правила хуже живут как код (код-ревью, тесты, промоушен между средами). 👉 Поэтому в проде используем его как игрушку в дополнение, а не как основной инструмент. 📌 ИТОГО: • Grafana = визуализация и обзор. • Prometheus/vmalert = тул, который решает «когда зажигать алерт». • Alertmanager = диспетчер, который решает «кому и как посылать алерт». • Opsgenie/PagerDuty/OnCall = гарантия доставки, расписания и эскалации.