Настройка оповещений (алертов) в системе мониторинга

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

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

При попытке правильной расстановки важности даже на уже имеющийся комплект оповещений, администратор психологически склонен либо завышать их важность, провоцируя повышенный поток сообщений с высоким уровнем «шума», либо, наоборот, занижать, вовсе лишая себя возможности узнавать о критическом состоянии некоторых подсистем. (Быть может, именно этот эффект имел в виду Николай Васильевич, написав «редкая птица долетит до середины…»)  :)

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

Выявление важных алертов

Ключ подхода к вопросу эффективного оповещения видится в том, чтобы определить набор алертов, которые должны вызывать безусловную реакцию персонала. Для этого необходимо:

  1. Разделить контролируемую систему на жизненно важные сервисы.
  2. Для каждого сервиcа определить как минимум одно или два критических состояния, которые должны обрабатываться безусловно:
    1. сервис не работает;
    2. сервис прекратит работу в течение 1 часа (возможны варианты, но не более 4 часов).
      Алерты о данных состояниях должны доставляться как можно быстрее и обрабатываться незамедлительно.
  3. Все имеющиеся алерты должны быть просеяны на однозначное соответствие двум упомянутым состояниям. Для несоответствующих критерию алертов уровень важности должен быть понижен.
  4. Для критических алертов, выдающих flip-flop эффект из-за проблем со связью или способом измерения должны вводиться загрубляющие характеристики (вычисление среднего или задержка) до того уровня, когда безусловная реакция на них начнет иметь смысл. Если такое загрубление делает алерт бесполезным, следует от него отказаться и искать другой способ определения критического состояния.

Смысловая нагрузка различных уровней важности алертов

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

Традиционно, при мониторинге применяется система «уровней важности», позволяющая оператору определить уровень своего интереса к событиям системы и отсекать поток информации, которая не является для него важной.

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

  • N — «не классифицировано»: просто нечто, что никому не известно зачем оно нужно.
    Оповещение бессмысленно.
  • I — «информация»: событие констатирует некий факт работы системы. На надежность не влияет.
    Оповещение не нужно.
  • W — «предупреждение»: событие, предупреждает о выходе параметра за пределы baseline или любого контрольного уровня, без оценки влияния на надежность.
    Пример: превышение параметром некого уровня, которого он раньше никогда не достигал, но без оглядки, к примеру, на то, что система имеет 10-кратный запас надежности по данному параметру.
    Оповещение возможно для диагностических целей, но для целей обеспечения надежности является ненужным «шумом».
    Получателям необходимо настроить почтовый фильтр, разделяющий алерты «W», «A» и «H,D» по разным папкам.
  • A — «средняя важность»: событие констатирует негативную тенденцию, которая в дальнейшем приведет к необходмости вмешательства.
    Пример: преодоление параметром 90% уровня от предельно возможного значения, с оценкой времени достижения самого предела через некоторое время (1 месяц), дающее возможность планово подготовиться и провести необходимые работы.
    Оповещение по e-mail для тех, кому интересно.
    Получателям необходимо настроить почтовый фильтр, разделяющий алерты «А» и «H,D» по разным папкам.
  • H — «высокая важность»: событие свидетельствует о работе систмы в критическом режиме (предотказное состояние жизненно важных параметров, отказ вспомогательных сервисов), когда быстрое вмешательство еще может исправить ситуацию.
    Пример: ситуация практического исчерпания ресурса, типа «На 1Т диске файлопомойки осталось свободных 20Мб, первый кто выложит фотки убъет сервис.»
    Оповещение обязательно.
    Рекомендуется дублирование по SMS (jabber).
  • D — «чрезвычайная важность»: отказ жизненно важных параметров или системы в целом — невозможность обслуживания клиентов.
    Оповещение обязательно.
    Рекомендуется дублирование по SMS (jabber).

Каналы оповещения

Среди каналов доставки информации о событиях можно выделить e-mail, jabber (и другие мессенджеры), SMS.

Не смотря на определенную архаичность, канал e-mail по прежнему обладает полным комплексом достаточно уникальных свойств:

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

Оценивая особенности применения jabber и SMS следует иметь в виду следующее обстоятельство:
Смысл данных каналов — в быстрой доставке сообщений, причем даже в ситуациях, когда получатель не находится у терминала (прием на мобильное устройство) и привлечение внимания путем подачи сигнала при поступлении сообщения.

Увы, в настоящий момент нет общепринятых средств, позволяющих дифференцировать вид сигнала в зависимости от содержимого принятого сообщения, поэтому распространение по данным каналам алертов важности ниже «H, D» будет неоправданным зашумлением.

Важным свойством системы мониторинга является своевременное оповещение оператора о важных событиях, происходящих в системе. Оповещения позволяют предупреждать аварии и оперативно восстанавливать отказавшие системы.
В англоязычных системах такое событие называется «алерт». Я позволю себе здесь попользоваться этим англицизмом, поскольку все буквы слова «оповещение» не помещаются в мой стек и вытесняют из него смысл большинства фраз.

Назначение алертов разнообразно — от простой констатации неких фактов, до сообщений о чрезвычайных систуациях и их правильное использование необходимо для четкой работы технической службы.
Неверное распределение алертов по уровням важности провоцирует проявление халатности при их обработке оператором.
В то же время, при попытке правильной расстановки важности даже на уже имеющийся комплект алертов, администратор психологически склонен либо завышать их важность, провоцируя повышенный поток сообщений с высоким уровнем «шума», либо, наоборот, занижать, вовсе лишая себя возможности узнавать о критическом состоянии некоторых подсистем. (Быть может, именно этот эффект имел в виду Николай Васильевич, написав «редкая птица долетит до середины…» ;)

Выявление важных алертов

Ключ подхода к вопросу эффективного оповещения видится в том, чтобы определить набор алертов, которые должны вызывать безусловную реакцию персонала. Для этого необходимо:

  1. Разделить контролируемую систему на жизненно важные сервисы.
  2. Для каждого сервиcа определить как минимум одно или два критических состояния, которые должны обрабатываться безусловно:
    1. сервис не работает;
    2. сервис прекратит работу в течение 1 часа (воможны варианты, но не более 4 часов).
      Алерты о данных состояниях должны доставляться как можно быстрее и обрабатываться незамедлительно.
  3. Все имеющиеся алерты должны быть просеяны на однозначное соответствие двум упомянутым состояниям. Для несоответствующих критерию алертов уровень важности должен быть понижен.
  4. Для критических алертов, выдающих flip-flop эффект из-за проблем со связью или способом измерения должны вводиться загрубляющие характеристики (вычисление среднего или задержка) до того уровня, когда безусловная реакция на них начнет иметь смысл. Если такое загрубление делает алерт бесполезным, следует от него отказаться и искать другой способ определения критического состояния.

Смысловая нагрузка различных уровней важности алертов

Помимо критических алертов, существуют и другие, позволяющие оператору узнавать о нюансах состояния системы без непрерывного анализа данных измерений и их графиков.
Традиционно, при мониторинге применяется система «уровней важности», позволяющая оператору определить уровень своего интереса к событиям системы и отсекать поток информации, которая не является для него важной.

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

  • N — «не классифицировано»: просто нечто, что никому не известно зачем оно нужно.
    Оповещение бессмысленно.
  • I — «информация»: событие констатирует некий факт работы системы. На надежность не влияет.
    Оповещение не нужно.
  • W — «предупреждение»: событие, предупреждает о выходе параметра за пределы baseline или любого контрольного уровня, без оценки влияния на надежность.
    Пример: превышение параметром некого уровня, которого он раньше никогда не достигал, но без оглядки, к примеру, на то, что система имеет 10-кратный запас надежности по данному параметру.
    Оповещение возможно для диагностических целей, но для целей обеспечения надежности является ненужным «шумом».
    Получателям необходимо настроить почтовый фильтр, разделяющий алерты «W», «A» и «H,D» по разным папкам.
  • A — «средняя важность»: событие констатирует негативную тенденцию, которая в дальнейшем приведет к необходмости вмешательства.
    Пример: преодоление параметром 80% уровня от предельно возможного значения, без оценки времени достижения самого предела.
    Оповещение по e-mail для тех, кому интересно.
    Получателям необходимо настроить почтовый фильтр, разделяющий алерты «А» и «H,D» по разным папкам.
  • H — «высокая важность»: событие свидетельствует о работе систмы в критическом режиме (предотказное состояние жизненно важных параметров, отказ вспомогательных сервисов), когда быстрое вмешательство еще может исправить ситуацию.
    Пример: ситуация практического исчерпания ресурса, типа «На 1Т диске файлопомойки осталось свободных 20Мб, первый кто выложит фотки убъет сервис.»
    Оповещение обязательно.
    Рекомендуется дублирование по SMS (jabber).
  • D — «чрезвычайная важность»: отказ жизненно важных параметров или системы в целом — невозможность обслуживания клиентов.
    Оповещение обязательно.
    Рекомендуется дублирование по SMS (jabber).

Каналы оповещения

Среди каналов доставки информации о событиях можно выделить e-mail, jabber (и другие мессенджеры), SMS.

Не смотря на определенную архаичность, канал e-mail по прежнему обладает полным комплексом достаточно уникальных свойств:

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

Оценивая особенности применения jabber и SMS следует иметь в виду следующее обстоятельство:
Смысл данных каналов — в быстрой доставке сообщений, причем даже в ситуациях, когда получатель не находится у терминала (прием на мобильное устройство) и привлечение внимания путем подачи сигнала при поступлении сообщения.

Увы, в настоящий момент нет общепринятых ср

Мониторинг

1 comment


  1. Pingback: Настройка оповещений (алертов) в системе мониторинга | Zabber – голос вашего сервера

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

captcha

Please enter the CAPTCHA text