Со временем в проекте пришли к тому, что пора бы записывать все инциденты, влияющие на работу сервисов и приложний.
Раньше вели документ в Confluence, который заполняли руками – но решение так себе, ибо 90% инцидентов просто решали без добавления записей о них.
Захотелось как-то навести порядок, ввести более адекватный Incidents Management (IcM), и вообще автоматизировать это дело.
Для отправки уведомлений кроме Prometheus Alertmanager, который шлёт уведомления в Slack, мы используем OpsGenie, который шлёт уведомления в мобильное приложение и выполняет звонок бота. Кроме того, в нём есть возможность создавать Incidents, которым и решил воспользоваться.
Причём, создавать их можно как вручную (см. Manual Incident Creation) так и автоматически при срабатывании алерта, см. Automate Incident Creation.
Сами Incidents по сути являются продвинутыми алертами: в них можно вносить комментарии, апдейты по процессу фикса, отправлять уведомления и так далее.
Документация тут>>>, но местами устаревшая. Однако, у OpsGenie отличная поддержка и все вопросы можно решить в минуты через чатик.
Содержание
Alerts notifications rules
И в целом хочется пересмотреть систему нашего алертинга: сейчас у нас Prometheus Alertmanager шлёт алерты уровня WARNING и CRITICAL в Slack и OpsGenie, см. Prometheus: OpsGenie и Alertmanager — уведомления в почту/SMS/телефон и Prometheus: роутинг алертов в Alertmanager.
OpsGenie в свою очередь алерты уровня Critical шлёт в почту + выполняет звонок держурному инженеру.
Вместо этого сделаем иначе – Prometheus будет слать алерты прямо в OpsGenie и только, а уже OpsGenie будет выполнять отправку в Slack через Slack-интеграцию (по интеграции OpsGenie и Slack будет отдельный пост.).
Нужно это для того, что бы через интеграцию OpsGenie с другими системами (Logz.io, Instana, AWS CloudWatch, Jenkins) иметь единую точку отправки алертов.
Т.е. мы сначала собираем все алерты в самом OpsGenie, а потом уже его настройки определяют, что делать с алертом – проигнорировать, отправить сообщение только в Slack, если это Warning, или отправить в Slack + отправить на почту + позвонить держурному + создать инцидент.
При этом из Slack можно сразу установить Acknowledge для алерта.
Incidents Management processes
Как говорил один хороший человек – “Процессы прежде утилит“, поэтому сначала опишите процессы – кто, как и за что отвечает, процесс рекции на инциденты.
Я набросал черновик, который включает в себя:
Roles
В Roles пока описаны только две роли: Incident Commander – “вечный дежурный”, главное ответсвенное лицо, и OnCall duty – наша DevOps team, чередуются через день по расписанию в OpsGenie.
Incidents severity
В Incidents severity описаны уровни важности – от P5 (Info) до P1 (Critical) в зависимости от влияния события на бизнесс-процессы и процессы разработки приложений.
Например, уровень P1 может означать, что затронуты конечные пользователи наших приложений – они не могут совершать покупки или полноценно пользоваться приложением. Тут может быть затронут API-бекенд, к которому обращаются мобильные клиенты, или падение AWS-сервиса, того же RDS, к которому обращается приложение API-бекенда.
P2, более низкий – влияет на процессы разработки. К примеру – падение Jenkins, что приводит к простою в билдах-деплоях. Уровень высокий, т.к. это тоже business-value, но не такой критичный, как влияние на конечных пользователей.
Ну а самый нижний уровень P5 – просто Info/Debug сообщения типа “На Dev-кластере Kubernetes какой-то под ушёл в постоянный рестарт”.
Incident domains
Области инцидентов. К ним потом можно будет “замапить” Services из OpsGenie (Сервисы рассмотрим ниже).
Пока в виде черновика выглядит так:
Почитать:
OpsGenie – включение Incidents
Как подключить:
- Opsgenie is included in all cloud plans of Jira Service Management – если вы пользуетесь Jira Service Management, то OpsGenie там уже есть
- Opsgenie is available as a standalone offering – купить отдельно (есть бесплатный доступ, но он очень ограничен, мы пользуемся Standart)
У нас возникла проблема из-за того, что наш аккаунт OpsGenie покупался давно, ещё до покупки OpsGenie компанией Atlassian, и у нас не было Incidents в панели вообще.
Что бы активировать их – надо перевести аккаунт из Legace Subscriptions в Atlassian Subscriptions.
Для этого идём в управление подписками и просто выбираем Standart ещё раз:
План поменяется со следующего биллинг-периода, но через обращение в Саппорт можно переключить сразу
Теперь Инциденты должны быть доступны.
Настройка OpsGenie Services
Инциденты привязаны к конкретным Services, т.н. Service-Aware Incident Management, поэтому начнём с создания такого Сервиса.
В роли Сервиса может выступать часть инфрастуктуры (например – AWS RDS, или весь AWS), какая-то утилита, к примеру система сборки и деплоя типа Jenkins, или ваше приложение, в нашем случае это может быть API-бекенд наших мобильных приложений.
Сначала создаём Service, а для этого сервиса настраиваются Rules, Responders и Stakeholders.
- Rules: описывают правила, по которым создаются Инциденты. Кроме того, эти Правила потом используются для проверки статуса Сервиса – выводят список связанных с этим сервисом Алертов.
- Responders: ответственные за работу этого Сервиса, которым будут отправляться уведомления о новых Инцидентах, связанных с этим Сервисом.
- Stakeholders: условно говоря люди, которые этим Сервисом пользуются. Им можно будет отправлять апдейты во время работы над инцидентом.
Создание Service
Переходим в Services:
Кликаем Add service, создадим Сервис для нашего Jenkins.
В Owner team указываем группу, ответственную за этот сервис. Но в нашем OpsGenie всего одна команда DevOps, так что везде будет фигурировать она:
Для настройки Rules и прочего – кликаем на Team settings:
В Service relationship можем связать несколько сервисов.
К примеру, у нас будет сервис AWS, в котором работает EC2, на котором работает Jenkins. Либо можно добавить сервис Kubernetes, в котором Jenkins запускает своих слейвов – тогда Jenkins будет Depends On Kubernetes (а Kubernetes – Depends On AWS):
Добавление Rules
Правила описывают то, как мы хотим автоматически создавать Инциденты из Алертов.
Переходим в Rules, кликаем Add incident rule:
В поле If the following condition(s) are met выбираем условия, при которых Инцидент будет создан, и как к нему потом будут подзвязываться алерты.
К примеру, у нас есть алерт для Jenkins с уровнем Critical, который сообщает о том, что у него на диске заканчивается свободное место:
- alert: JenkinsLowDataDiskCritical expr: ((node_filesystem_size_bytes{mountpoint="/rootfs/data",host="jenkins-production"} - node_filesystem_free_bytes{mountpoint="/rootfs/data",host="jenkins-production"} ) / node_filesystem_size_bytes{mountpoint="/rootfs/data",host="jenkins-production"} * 100) > 95 for: 1s labels: severity: critical ...
Изменим >
на <
, что бы он затриггерился, и получаем алерт в OpsGenie с уровнем P1:
Теперь настраиваем создание Инцидента по такому алерту, используя поля алерта Message и Priority:
В поля Incident Message и Incident Summary можно добавить дополнительную информацию, например – priority
и source
, с которого получен алерт, а в Incident Priority указать важность инцидента:
Жмём Create, рестартим Prometheus, что бы повторно затриггерить срабатывание алерта – и инцидент создан:
И сам инцидент:
А в списке Сервисов у сервиса Jenkins появляется уведомление о том, что есть открытый Инцидент:
Отсюда можем отправить апдейт “стейкхолдерам” (которыми в нашему случае выступаем мы сами):
Сообщение появится в Timeline справа:
Там же через Add entry можно добавить просто комментарий:
И посмотреть связанные алерты, которые попадают под Rules, описанные в начале:
И в конце-концов зарезолвить этот Инцидент:
После чего связанный алерт будет переведён в статус Acknowledged, а к Инциденту можно будет создать Postmortem – “расследование”.
Postmortem
После того, как инцидент решён или закрыт – ему можно добавить Postmortem с описанием причин и способов решения этого инцидента:
Который потом можно найти в Reports > Postmortems:
И даже заекспортить в Confluence:
Готово.