Skip to content

Интерфейсы

Общая информация

Объект узел (host) связан с объектами - интерфейсами. Один узел может иметь произвольное количество интерфейсов. Интерфейсы нужны для указания сетевого адреса и специфичных реквизитов протоколов для активного опроса узла. Большинство типов айтемов привязываются к интерфейсам.

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

Пример конфигурации интерфейсов узла:

alt text

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

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

Состояние интерфейсов и подавление лишнего траффика

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

Доступность интерфейсов позволяет наглядно оценить общую работоспособность узла при работе с UI (фрагмент списка узлов с состояниями интерфейсов):

alt text

На недоступный интерфейс ограничивается траффик для уменьшения нагрузки на сетевые ресурсы и мониторинг.

Логика работы ограничения траффика:

диаграмма ограничения траффика

На диаграмме изображена шкала времени со схематично обозначенными событиями запросов (стрелки вверх), ответами (стрелки вниз). Пунктиром обозначены ожидаемые ответы, которые не пришли.

Красным пунктиром - время, когда узел перестал отвечать на запросы. Зеленым - момент когда работа ответов узла восстановилась

В период (1) идет нормальная работа - на запросы приходят ответы, запросов много, идет штатная работа

В точке (2) начинается аварийный режим работы.

В течении периода (3) - узел перестает не отвечает на запросы, но сервер ожидает предопределенный таймаут (UnreachableTimeout) и предопределенное количество неотвеченных запросов (UnreachableRetries). До момента выполнения обоих условий интенсивность опроса узла не меняется.

После срабатывания условия по таймауту неответов и количества неотвеченных запросов интерфейс переходит в режим недоступности - период (4), при этом система позволяет делать не более одного запроса каждые UnreachableDelay секунд, таким образом ограничивая траффик на узел.

В точке (5) происходит восстановление сервиса, однако сервер узнает о том, что узел начал отвечать с некоторой задержкой, при выполнении очередного запроса. После первого успешного ответа от узла интерфейс переводится в состояние "доступен" и траффик запросов восстанавливается в обычном режиме - период (6)

Опции таймингов определения недоступности и интенсивности запросов во время недоступности задаются в конфигурационном файле сервера, пример со значениями по-умолчанию:

UnreachableTimeout = 45
UnreachableRetries = 2
UnreachableDelay = 15