Метод CASE: гуманный мониторинг

[Tzimie]

Как у вас хорошо. А у нас есть целый отдел в стране, где танцуют и поют. Они получают алерты от тупого и многословного SCOM и эскалируют из сообразно процедуре. Особенно умиляют алерты на high CPU. Да, спорадически бывает такое, и это нормально.

Они столько раз кричали «волки, волки» что наш подбизнес почти забил на них. Благо звонить им нам нельзя… Пока… А мыла пусть пишут

Реально используется моя самописка

[AntoniusFirst]

Если систем мониторинга несколько (а обычно это так и бывает), события лучше обрабатывать (коррелировать, схлопывать и т.д.) во внешнем event consolidator (или зонтичной системе). Дополнительным плюсом будет единая точка интеграции с системой инцидент-менеджмента.

Ещё одна статья о лечении при следующих сиптомах событийной усталости:

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

[Matvey-Kuk]

Symptom-based — может вызвать недопонимание и привести к алертам по нарушению SLA, а не SLI. Опасно) Вообще тема исчерпывающе описана в SRE.

Кстати относительно картинки «Вижу алерт — завожу инцидент» — в amixr.io подвезли кнопочки прямо под алерт в слаке, которые можно сконфигурировать на вебхук и вешать таски:

вот как это выглядит