В эту пятницу на Хабре вышла статья в блоге Фланта, в которой они пишут как проходили свой путь работы с событиями. Это расшифровка выступления Дмитрия Столярова с прошлогодней конференции DevOops.
Давайте я тут приведу свои комментарии к мыслям из этой статьи, которые мне особенно понравились.
1️⃣ Центральное хранилище. Нельзя слать алерты разными путями — все они должны приходить в одно место.
Речь о единой точке сбора событий из разных систем. Из этой точки события уже должны уходить в виде оповещений в Service Desk, Slack или куда вы там ещё их отправляете. В традиционных категориях это можно назвать зонтичной системой мониторинга. У такого подхода невероятное количество плюсов: защита от дупликации событий, возможность навернуть логику на события из разных систем, обогащать события данными из CMDB, базы знаний и т.д. и т.п.
2️⃣ Транспорт. <…>Мы решили, что существующие способы транспорта для алертов не подходят и сделали свою систему. В ней ответственный сотрудник вынужден для каждого алерта нажимать на кнопку «я увидел(а)»: если этого не происходит, к нему приходят запросы по другим каналам.
Общий телеграм-канал или канал в Slack, конечно, нужны только как вспомогательный инструмент. Основной — это прямое уведомление дежурного. В Флант решили сразу не беспокоить дежурных, а вываливать им уведомление в интерфейсе. Может и были какие-то на это причины, но для экономии времени лучше б сразу уведомить дежурного.
3️⃣ Инцидент не равен алерту. Чтобы это окончательно осознать, у нас ушло несколько лет. Алерт — это сообщение о проблеме, а инцидент — это сама проблема. Инцидент может содержать много сообщений о проблеме с разных сторон, и мы стали их объединять.
Я бы написал так: инцидент != событию != алерту. Инцидент — сущность системы тикетов (Service Desk — хороший пример этого семейства), событие — системы мониторинга, а алерт это да, сообщение о проблеме.
4️⃣ Лейблы. Всю идентификацию алертов надо строить на лейблах (key=value) — это стало особенно актуальным с приходом Kubernetes. Если алерт с физического сервера — в лейбле указано название этого сервера, а если с DaemonSet'а — там его название и пространство имён.
Лейблы нужны. Например, в Zabbix можно навесить тэги на хосты или триггеры. В Prometheus, соответственно, лейблы, которые навешиваются на временные ряды при экспозиции.
5️⃣ Чтобы избавиться от подобного психологического эффекта, «полупотушенные» инциденты надо попросту убрать, но сделать это правильно. Я называю это умный игнор, а его идея сводится к операции «отложить инцидент».
Тут речь идёт о событиях типа отказал диск, заказали новый. Т.е. о тех, по которым ожидается какой-то результат, не зависящий от эксплуатации. События при таком умном игноре должны висеть в открытых (т.к. в консоли обычно выполняется сортировка по времени, они будут в хвосте ленты) и на еженедельных ревью по мониторингу (если они у вас, конечно, есть) по всем таким должны быть проведены апдейты.
6️⃣ В компаниях, где часто что-то меняется, весьма актуальна ещё одна проблема: документация.
Документацию еще можно назвать контекстом. По каждому событию в системе мониторинга должен быть доступен контекст. Это может быть страница на вики, история возникновения аналогичных событий и т.д. Дежурному должна быть доступна эта информация по ссылке из события.
В один пост всё не влезло, поэтому п.7 будет идти следом.
Давайте я тут приведу свои комментарии к мыслям из этой статьи, которые мне особенно понравились.
1️⃣ Центральное хранилище. Нельзя слать алерты разными путями — все они должны приходить в одно место.
Речь о единой точке сбора событий из разных систем. Из этой точки события уже должны уходить в виде оповещений в Service Desk, Slack или куда вы там ещё их отправляете. В традиционных категориях это можно назвать зонтичной системой мониторинга. У такого подхода невероятное количество плюсов: защита от дупликации событий, возможность навернуть логику на события из разных систем, обогащать события данными из CMDB, базы знаний и т.д. и т.п.
2️⃣ Транспорт. <…>Мы решили, что существующие способы транспорта для алертов не подходят и сделали свою систему. В ней ответственный сотрудник вынужден для каждого алерта нажимать на кнопку «я увидел(а)»: если этого не происходит, к нему приходят запросы по другим каналам.
Общий телеграм-канал или канал в Slack, конечно, нужны только как вспомогательный инструмент. Основной — это прямое уведомление дежурного. В Флант решили сразу не беспокоить дежурных, а вываливать им уведомление в интерфейсе. Может и были какие-то на это причины, но для экономии времени лучше б сразу уведомить дежурного.
3️⃣ Инцидент не равен алерту. Чтобы это окончательно осознать, у нас ушло несколько лет. Алерт — это сообщение о проблеме, а инцидент — это сама проблема. Инцидент может содержать много сообщений о проблеме с разных сторон, и мы стали их объединять.
Я бы написал так: инцидент != событию != алерту. Инцидент — сущность системы тикетов (Service Desk — хороший пример этого семейства), событие — системы мониторинга, а алерт это да, сообщение о проблеме.
4️⃣ Лейблы. Всю идентификацию алертов надо строить на лейблах (key=value) — это стало особенно актуальным с приходом Kubernetes. Если алерт с физического сервера — в лейбле указано название этого сервера, а если с DaemonSet'а — там его название и пространство имён.
Лейблы нужны. Например, в Zabbix можно навесить тэги на хосты или триггеры. В Prometheus, соответственно, лейблы, которые навешиваются на временные ряды при экспозиции.
5️⃣ Чтобы избавиться от подобного психологического эффекта, «полупотушенные» инциденты надо попросту убрать, но сделать это правильно. Я называю это умный игнор, а его идея сводится к операции «отложить инцидент».
Тут речь идёт о событиях типа отказал диск, заказали новый. Т.е. о тех, по которым ожидается какой-то результат, не зависящий от эксплуатации. События при таком умном игноре должны висеть в открытых (т.к. в консоли обычно выполняется сортировка по времени, они будут в хвосте ленты) и на еженедельных ревью по мониторингу (если они у вас, конечно, есть) по всем таким должны быть проведены апдейты.
6️⃣ В компаниях, где часто что-то меняется, весьма актуальна ещё одна проблема: документация.
Документацию еще можно назвать контекстом. По каждому событию в системе мониторинга должен быть доступен контекст. Это может быть страница на вики, история возникновения аналогичных событий и т.д. Дежурному должна быть доступна эта информация по ссылке из события.
В один пост всё не влезло, поэтому п.7 будет идти следом.