IncidentGarden

Обзор

Что такое сайленс, где он стоит в обработке алертов, чем отличается от политики и как устроены scope и matchers.

Silence (сайленс) — это ручное временное подавление алертов под конкретную ситуацию: известная проблема, на которую уже реагируют, или плановые работы, на время которых шум не нужен. В отличие от политики — постоянного правила в конвейере обработки — сайленс заводят вручную как разовое окно: он действует ограниченный срок и выключается сам. Подробнее о разнице — во врезке в конце Обзора политик.

Место в обработке

Сайленсы применяются после политик, в момент создания алертов. Полная картина обработки — Конвейер обработки алертов.

Что происходит при срабатывании

Подавленный алерт не исчезает. Он создаётся как обычно, но ставится на паузу: по нему не идут уведомления и не запускается политика эскалации. В системе он виден как подавленный — вы знаете, что проблема зафиксирована, но никого не дёргает.

Когда окно сайленса заканчивается, такой алерт автоматически возвращается в работу (firing) и уходит в эскалацию — как будто пришёл только что. Именно этим подавление отличается от действия Drop в политиках: Drop выбрасывает алерт безвозвратно, а сайленс лишь откладывает реакцию до конца окна.

Сайленс не гасит уже летящий алерт

Если телефон звонит прямо сейчас, сайленс эту эскалацию не остановит. Нужно действовать по самому алерту:

  • Acknowledge — вы взяли инцидент в работу. Эскалация по алерту останавливается, следующие шаги никого не поднимают, алерт остаётся открытым.
  • Resolve — проблема закрыта. Алерт уходит из работы совсем.

Сайленс имеет смысл завести дополнительно — чтобы следующие алерты той же природы не будили, пока вы разбираетесь. Но останавливает текущий звонок именно Acknowledge.

Создать сайленс — не способ заглушить уже звонящий алерт. Сайленс проверяется в момент, когда алерт создаётся: он решает судьбу тех алертов, что придут после него. Алерт, созданный раньше, эту проверку уже прошёл — задним числом его никто не пересматривает, и он продолжит эскалацию по своей цепочке.

Это ровно то место, где в разгар инцидента легко потерять минуты: человек создаёт сайленс, звонки продолжаются, он создаёт второй, третий — а нужно было нажать Acknowledge на алерте.

У этого правила есть зеркальная половина: отмена сайленса точно так же не возвращает в работу уже подавленный алерт. Разбор — в Отмене сайленса.

Область применения (scope)

Сайленс принадлежит конкретной команде и подавляет только её алерты. Область применения (scope) выбирается одним из двух способов:

  • Все интеграции команды — сайленс подавляет алерты от каждой интеграции команды, включая те, что будут добавлены позже. Не нужно заводить новый сайленс при появлении новой интеграции — он накрывает её автоматически. Удобно для плановых работ, затрагивающих команду целиком.
  • Одна конкретная интеграция — сайленс подавляет алерты только от выбранной интеграции.

Выбрать произвольное подмножество интеграций нельзя — либо одна, либо все. Сайленсов на всю организацию тоже нет: сайленс всегда живёт в границах команды.

Поле выбора области (Scope) в форме доступно всегда, независимо от точки входа. Значение по умолчанию подставляется по контексту: со страницы команды — все её интеграции, со страницы алерта — интеграция этого алерта. В обоих случаях его можно изменить — см. Создание и управление.

Type: метка намерения

У сайленса два типа — Manual silence (ручной сайленс) и Maintenance (плановые работы). Это семантическая метка: на обработку алертов тип не влияет, поведение одинаковое — отличается только подпись и намерение. Для типового сценария «глушим алерты на время работ» см. Подавление на время работ.

Matchers: что подавлять

Matchers отбирают алерты по меткам — пары «ключ = значение» с точным совпадением, между парами действует логическое И. Шаблонов и регулярных выражений нет (в отличие от Alertmanager).

Метки берутся уже после политик

Сайленс стоит в конвейере после политик, поэтому и метки видит те, что получились после их работы. Метка, которую политика добавила действием Add labels, для сайленса такая же настоящая, как пришедшая от источника, — и может заставить сайленс сработать на алерт, который по исходным меткам под него не подходил.

Пример. Политика вешает на всё из тестового контура метку env=staging. Сайленс с matcher env = staging подавит такие алерты — даже если источник метку env вообще не присылал. С точки зрения дежурного алерт «замолчал по метке, которой в нём не было».

Это удобно: политикой можно один раз разметить поток, а дальше глушить его короткими сайленсами по одной метке. Но работает и в обратную сторону — если сайленс подавил не то, что вы ожидали, проверьте, не добавляет ли эту метку какая-нибудь политика команды: в журнале алерта сработавшая политика видна записью Policy Applied.

Пустой список matchers подавляет все алерты в выбранной области. Если вы создаёте сайленс на одну интеграцию и не добавляете ни одного matcher — замолкнут вообще все её алерты. Это нормально для плановых работ, но при точечном подавлении проверьте, что matchers заданы.

Кто может управлять

  • Создать сайленс может org_admin или org_owner (любой сайленс организации), а также team_admin или team_member — но только сайленс своей команды (на все её интеграции или на одну).
  • Изменять и отменять сайленс могут те же роли, а также его автор — даже если он уже вышел из команды.
  • org_member видит сайленсы только своих команд.

С чего начать

Сайленс и политика решают похожую задачу — убрать лишний шум, — но по-разному. политика встроена в конвейер и срабатывает на каждом подходящем алерте постоянно, по заданным условиям. Сайленс — точечное подавление на ограниченный срок, которое заводят вручную под конкретную ситуацию и которое выключается само. Подробнее о политиках — в разделе Политики.