Ложные срабатывания (false positives) - основная проблема всех средств мониторинга. Как в известной притче про мальчика, который кричал "Волки! Волки!", ложные срабатывания понижают степень доверия к оповещениям мониторинга, снижают внимание и позволяют настоящим проблемам происходить незаметно. Так как мы делали okerr для себя, нас очень волнует качественное решение этой проблемы, и, думаем, у нас это получилось неплохо. Здесь мы рассмотрим, что делать, если вы получили сообщение о ложном срабатывании.
Под ложным срабатыванием мы будем понимать срабатывание, которое вызвало отправку оповещения, но на самом деле не требовало какого-то вмешательства от получателя. К примеру, кратковременный сетевой сбой, или повышенная нагрузка на сервер, которые сами прошли со временем.
Столько всего интересного!
С мониторингом вы можете узнать много нового о своих системах. Возможно, вы привыкли считать, что Load Average (средняя нагрузка) на системах не поднимается выше 0.10. Потому что раз 10-20 за последние полгода смотрели на нее и она была в этих пределах. Но настроив мониторинг, вы начнете получать сообщения о повышенной нагрузке, потому что он ее может смотреть раз в 20 минут, 72 раза в сутки, каждый день. И вы узнаете, что иногда у вас случаются всплески нагрузки до очень больших значений.
Возможно, вы привыкли, что у вас есть сайт, и он открывается. Вы так считаете, потому что пару раз в день сами на него заходите, и он открывается. Хотя иногда кажется не открывался... Но вы нажали reload и он открылся. Неизвестно, что это было. С мониторингом, который будет его загружать каждые 10 минут, 144 раза в день, вы узнаете, что такая проблема происходит довольно регулярно на самом деле. (Даже у многих крупных провайдеров бывают редкие потери пакетов.).
А может быть ничего не делать?
Если ложное срабатывание произошло в первый раз - можно и на самом деле проигнорировать его. Если оно будет происходить очень редко - это нестрашно. Ложные срабатывания - неизбежны, важно только чтобы они были достаточно редкими. Если же оно происходит часто - придется взяться за работу.
Важно, но не вам
Возможно, некоторые получатели в принципе не должны получать оповещение о некоторых индикаторах. Например, руководителю скорее всего не нужно отвлекаться каждый раз на каждое срабатывание. Вместо этого, он может быть заинтересован только в слежении за особо важными индикаторами и за эскалациями (когда какая-то проблема не исправлена в течение положенного времени). В этом случае, такой получатель может в настройках профиля отключить получение оповещений для себя, но при этом "подписаться" только на интересующие его индикаторы, поставив галочку "subscribe" в разделе "пользовательские настройки" на страничке индикатора (При подписке на индикатор, оповещения приходят даже если они отключены в профиле).
Кроме того, можно настроить селективные групповые оповещения разным группам пользователей с использованием меток и логических индикаторов, или же разбив проект на несколько проектов меньшего размера.
Проблемы почти не было
Возможно, проблему можно решить просто настроив индикатор менее строго? Для числовых индикаторов - повысить (или понизить) соответствующее ограничение. Индикатор должен срабатывать не в ситуации, которая чуть-чуть отличается от обычной, а в ситуации, которая либо явно является проблемной наверняка, либо подозрительна настолько, что стоит того, чтобы разобраться с ней при получении оповещения.
А если повторить? (Retry schedule)
Иногда проблема проходит сама. Довольно бессмысленно при получении оповещения бросать все дела, срочно переключаться на решение проблемы только для того, чтобы увидеть, что проблемы уже нет. Странички грузятся, сервера пингаются... Для таких случаев в okerr есть расписание повторных проверок (retry schedule). Расписание (в виде строчки из чисел, каждое из которых - пауза в секундах, например "30 120") задается в политике индикатора. Если проверка активного индикатора завершилась неудачей, назначается следующая проверка (30 секунд), если и она неудачна, тогда еще одна (еще через 120 секунд) и только если последняя проверка из расписания так же не удалась - тогда регистрируется ошибка.
При этом, каждая проверка выполняется с другого сервера (не с того, который показал неудачную проверку), чтобы исключить срабатывания если проблемы будут связаны с самими проверяющими серверами okerr .
Все результаты проверок тем не менее записываются в логах индикатора. Таким образом, использование перепроверок позволяет и избавиться от случайных ложных срабатываний, но при этом регистрировать проблемы.
Логика
Следующий невероятно мощный (но более сложный) инструмент - логические индикаторы. Логический индикатор исполняется по своему расписанию, и ему доступны все данные о проекте, которые он может проверить по логическому выражению.
Это позволяет реализовать довольно сложные условия, например:
Борьба с "морганием" (flapping)
Иногда бывает так, что индикатор переходит в состояние ERR, но сам из него выходит через короткое время. Например, загрузка сервера (Load Average) может иногда быть высокой, и мы не хотим получать сообщения каждый раз об этом, но тем не менее, нам важно знать, если загрузка будет высокой в течение длительного времени (скажем, более 45 минут).
С правильной настройкой логических индикаторов, мы не будем получать лишние сообщения. Алерт придет только если высокая нагрузка будет длится достаточно долго.
На странице индикатора в okerr есть ссылка "создать индикатор верхнего уровня", которая позволяет реализовать эту схему проще и удобнее (через wizard).
Работа с резервированием (N из M)
Мы можем допускать ситуацию, когда у нас 5 серверов какого-то типа, и мы разрешаем, чтобы 2 из них были отключены (не менее 3 включено).
Благодаря логическим индикаторам, мы получим алерт только если в бою осталось менее 3 серверов, а техники смогут спокойно их отключать, не вызывая панику у руководства.
Разные правила для разного времени
Логический индикатор может учитывать время и дату. Например, мы можем разрешить отключение серверов в интервале от 4 до 6 утра. В это время, если какой-то из наблюдаемых серверов не будет доступен, алерта не
будет. Но в 6 утра, если сервер все еще не будет введен в строй, проверка это обнаружит и вышлет оповещение.
Контроль качества и эскалации
Логический индикатор может оповещать о ситуации, когда некоторая проблема обнаружена достаточно давно, но при этом над ней не начата работа (админ "не увидел" ее), или же работа начата, но не завершена в допустимое время. Это решение очень хорошо подходит для руководителей разного уровня, которым не нужно тревожится из-за каждой мелочи (это делегируется техническим специалистам), но при этом нужно держать ситуацию в целом под контролем, и видеть, что специалисты справляются с задачами достаточно хорошо.
Тихий режим
Можно сделать так, чтобы индикатор не отправлял оповещения. Для этого нужно установить ему флаг "тихий". Тихие индикаторы помечаются значком "динамика" в списке. Тихий режим полезен как в случае, когда индикатор контролируется логическим индикатором верхнего уровня, так и для случая, когда нам не нужно получать оповещения от индикатора, но мы при этом хотим все таки иногда видеть текущее состояние индикатора и его историю.