​​Эскалации в Zabbix

От проблем не убежать, они были, есть и будут возникать с определенной периодичностью, какие бы превентивные меры мы не принимали. Но важно не факт отсутствия проблем, а факт своевременного на них реагирования.

И очень часто в дело вступает человеческий фактор, который превращает небольшое происшествие в проблему масштаба предприятия.

Кто-то не заметил, не отработал, не хватило собственной квалификации, либо вообще принял ошибочные решения. Как все это отследить, как проконтролировать?

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

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

Самое простое – это кого-нибудь уведомить. Но как быть, если ответственный не увидел уведомления, не отреагировал или не справляется?

Все очень просто, каждое действие состоит из некоторых операций, которых может быть несколько, и они будут выполняться по очереди.

Допустим мы создали некоторое действие, привязали к нему нужные триггеры и думаем как мы будем обрабатывать сложившуюся ситуацию.

А обрабатывать мы ее будем пошагово, с каждым шагом поднимая проблему на более высокий уровень.

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

Но и выставлять слишком большой период тоже не стоит, иначе может оказаться что мы начали «бить в колокола» слишком поздно.

Для примера мы возьмем триггер «High CPU usage», т.е. когда процессор начинает стабильно выдавать высокую загрузку. Ситуация серьезная, но не катастрофическая. Дадим на решение вопроса 15 минут. Такое же время выделим на каждый шаг.

Первый шаг – уведомить ответственное лицо, кстати, каждую операцию можно растянуть на несколько шагов. И тогда ответственное лицо будет уведомляться несколько раз.

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

Ждем еще 15 минут, если нет реакции, то мы можем не только продолжать уведомлять все более вышестоящие лица, но и выполнять некоторые действия для решения проблемы. Например, снять отчеты по нагрузке на CPU, память, диски и отправить их кому надо.

Снова нет реакции? Ну тогда в дело вступают роботы, можем прибить самый ресурсоемкий процесс. Не помогло? Кстати, для этого можно и не ждать следующие 15 минут, а задать произвольное время шага, допустим 5 минут.

Через 5 минут после того, как мы прибили процесс снова высокая нагрузка? Ну давайте последний раз всех предупредим. Не помогло? Ну тогда идем на крайние меры и перезагружаем узел.

Количество шагов ограничено только вашей фантазией и позволяет реализовывать достаточно сложные сценарии.

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

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

В общем, эскалация в Zabbix это крайне гибкий и удобный инструмент, позволяющий контролировать не только возникновение проблем, но и процесс их решения.