Стратегии установки пороговых значений

Следует ли устанавливать пороговые значения для опроса производительности? Что собирается делать персонал с пороговыми событиями?

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

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

Если предполагается, что желательно генерировать пороговые события, то каким образом следует устанавливать пороговые значения? Можно рассмотреть три подхода.

Простейший способ основан на использовании опубликованных эмпирических правил, подобных тем, которые приведены в таблице 1.2, и учебников по планированию пропускной способности.²⁾

Более сложный подход состоит в повышении уровня пороговых уровней до тех пор, пока интенсивность событий не станет приемлемо низкой. Очевидно, что этот подход является трудоемким, поскольку приходится отслеживать каждый интерфейс и производить индивидуальную наладку. Этот метод еще называют «последовательной оптимизацией». Для каждого устройства показатели производительности отслеживаются на протяжении нескольких недель, и затем соответствующим образом изменяются пороговые уровни. Заметим, что эти пороговые уровни можно вручную добавить в файл $OV_CONF/snmpCol.conf, чтобы избежать утомительной работы с GUI конфигурирования сборщика данных SNMP. Формат этого файла изменен в версии NNM 6.0, так что при модернизации системы NNM следует соблюдать осторожность при миграции этого файлового формата.

И, наконец, существует подход к установке пороговых значений на основе аналитических рассуждений. Например, предположим, что последовательный канал моделируется как простая очередь M/M/1. Напомним, что если эта очередь нагружается на 90%, то среднее время ожидания превышает норму в 10 раз. Это уважительная причина для сигнала тревоги. По поводу частоты ошибок и потери пакетов рассмотрим график, приведенный на рис. 1.7. Он показывает, как падает пропускная способность TCP у приложения, выполняющего непрерывную передачу данных с использованием TCP, при увеличении процентного отношения потерянных пакетов. Наличие всего одного процента потери пакетов фактически снижает пропускную способность до ничтожного уровня.

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

Чтобы избежать генерации сигнала тревоги по причине случайной одиночной ошибки, можно воспользоваться пороговыми опциями NNM. Если указать, что данный показатель должен превысить пороговое значение для четырех последовательных выборок образцов, то можно гарантировать, что сигнал тревоги будет вырабатываться только при продолжительном существовании условия ошибки. При пятиминутных выборках это означает, что для подачи сигнала тревоги требуется 20-минутная продолжительность существования условия ошибки. Чтобы обеспечить быстрое обнаружение восстановления обслуживания, можно установить продолжительность интервала снятия сигнала тревоги всего лишь в две выборки образцов, или в 10 минут. Эти принципы объясняются на рис. 1.8.