Powershell/PRTG: False alarms

[hikedaya]

Enter agents of ill fantasy
For evil holds you in its arms, false alarms...
---
(c) Old Gods of Asgard - Control

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

Всем известно, что постоянно висящие оповещения, "о которых все знают", в итоге приводят к тому, что на мониторинг в целом "забивают". Пример такого смоделирован в уже пробегавшем в этом блоге PRTG ниже:

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

Со временем количество таких вот "всем известных" проблем может перерасти в качественный снежный ком.

Примерно такая же ситуация сложилась и у меня сейчас. Без конкретики и в общих чертах задача выглядит так: есть несколько важных узлов. Даже не так, не просто важных, а ВАЖНЫХ. Но важность их не в том, что они должны быть онлайн всегда, нет. Они вполне себе легально могут быть и оффлайн, например, после окончания рабочих часов или на выходных. Да, вы догадались - на мониторинг завели отдельные рабочие машины нескольких сотрудников. Зачем это сделали, толком не объяснили, просто поставили перед фактом - они там есть, за ними надо следить.

Ок, анализируем ситуацию. Первый же уход такого узла в оффлайн на ночь. Сотрудник отдела мониторинга обязан на такое событие отреагировать, поскольку оно является критичным (критикой является все то, что в мониторинге подсвечено красным). Хорошо, оповестим всех причастных, а дальше-то что? Дальше вариантов два. Можно либо поставить этот узел в консоли PRTG в паузу до следующего утра, либо подтвердить наступившее событие (Acknowledge), сделав его менее режущим глаза. В обоих вариантах есть проблема - утром узел проснется, какое-то время проработает, а потом снова уйдет в оффлайн, и вся ситуация повторится по новой.

В конце концов это достанет кого угодно. Вот меня и достало. Что ж, за спрос не ударят в нос, потому уточнил прямо - в чем смысл наблюдения за этими узлами, и как парни должны реагировать на постоянные "критические события". Ответ таков - компьютеры туда добавлены для сбора статистики, на события ухода в оффлайн на ночь или выходные реагировать не нужно. На пропадание компьютера из сети во время рабочего дня разбираемся в обычном порядке по звонку. Бинго!

Раскручиваем ситуацию дальше, вспоминая про минимум оповещений. Можно ли заставить PRTG при пропадании такого особого устройства выдавать не статус Error, а Warning, чтобы и знать, что к чему, и в то же время не замыливать глаза лишними оповещениями о якобы критических событиях? Как выяснилось - можно, но для этого придется поиграться с кастомными сенсорами.

Сенсором в PRTG является объект, выполняющий определенную последовательность команд и возвращающую определенный результат. Оформлена эта последовательность может быть многими способами, в том числе и вызовом скриптов. И в зависимости от того, какой результат выдаст скрипт, PRTG изменит статус сенсора. Дальше курим официальную справку о том, как оформлять вывод результата скрипта и о том, как вообще подключать сторонние скрипты к PRTG. Подключаются они просто - файл скрипта копируется в каталог:

C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXE

С результатом все немного интереснее. В справке указано следующее:

Standard EXE/sсript Sensor

The returned data for standard EXE/sсript sensors must be in the following format:

value:message

icon-i-round-redValue has to be a 64-bit integer or float. It is used as the resulting value for this sensor (for example, bytes, milliseconds) and stored in the database. The message can be any string (maximum length: 2000 characters).

The exit code of the executable file has to be one of the following values:
0 - OK
1 - WARNING
2 - System Error (for example, a network/socket error)
3 - Protocol Error (for example, web server returns a 404)
4 - Content Error (for example, a web page does not contain a required word)

И если с value:message все понятно, то на result code я затупил, пока методом проб и ошибок все же не понял, как это оформляется. Учитывая, что в заголовке записи присутствует Powershell - речь идет, понятное дело, именно о нем. Так вот, result code записывается довольно... эээ... даже не тривиально, а тупо:

exit n

где n - нужный нам код. И именно этот код определяет состояние, в котором окажется сенсор после получения данных. Поехали:

$target = $args[0]
$data = Test-Connection $target -ErrorAction SilentlyContinue

if ($data) {
    $ResponseTime = 0
    foreach ($item in $data) {
        $responseTime += $item.responsetime
    }
    if ([math]::round($ResponseTime/$data.count) -lt 1) {
        $ResponseTime = 1
    }
    else {
        $responseTime = [math]::round($ResponseTime/$data.count)
    }
    write-host "$($ResponseTime):OK"
    exit 0
}
else {
    write-host "0:Host Unreachable"
    exit 1
}

Все стандартно, из передаваемых скрипту аргументов берем адрес, пингуем его в стандартные же 4 пакета, вычисляем среднее время ответа и это самое время ответа выдаем как результат с нулевым кодом исполнения (минимальный результат будет равен 1 мс). А вот если адрес пинг не прошел - выдаем нулевой результат с кодом выполнения 1, который переведет сенсор в состояние Warning, а не Error. Что нам и нужно по условию задачи. Результат выглядит значительно приятнее, особенно по ночам:

spb-01-hv1 потушен, в консоли это отражено, но раздражать больше не будет.

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