Первая часть данной статьи находится тут.
Настройка процесса обнаружения сервисов (Capabilities daemon) После того как зарегистрированы события newSuspect для обнаруженных интерфейсов, приходит время работы демона capsd (capabilities daemon). Его задачей является распознавание всех функционирующих на интерфейсе сервисов. Рассмотрим пример конфигурационного файла capsd-configuration.xml. Конфигурация файла позволяет очень гибко управлять ходом процесса обнаружения сервисов. В первых строчках определяются глобальные параметры функционирования сервиса:
<capsd-configuration rescan-frequency="86400000"
initial-sleep-time="300000"
management-policy="managed"
max-suspect-thread-pool-size="6"
max-rescan-thread-pool-size="3"
abort-protocol-scans-if-no-route="false">
где:
* rescan-frequency – время, через которое происходит повторноесканирование интерфейса на предмет обнаружения сервисов.
* initial-sleep-time – время задержки после запуска openNMS передначалом сканирования сервисов.
* management-policy - контролирует процесс сканирования сервисов.
Если установлен в “managed” – то все события newSuspect будут обработаны, если же параметр установлен в значение “unmanaged”, то все события newSuspect будут проигнорированы, и сканирование не произойдет. Параметр можно переопределить в теге <protocol-configuration>, о котором будет рассказано дальше.
* max-suspect-thread-pool-size – количество одновременных потоковсканирования при первоначальном обходе адресов. Увеличение значения ускоряет сканирование ценой потребляемых ресурсов.* max-rescan-thread-pool-size – количество создаваемых потоков наинтерфейсах с уже обнаруженными сервисами при повторном сканировании.
* abort-protocol-scans-if-no-route – если параметр выставлен в”false”, то попытки сканирования сервисов при получении сообщения “no route to host” продолжатся, так как это сообщение может быть в некоторых случаях вызвано наличием межсетевого экрана. Если параметр примет значение “true”, то сканирование интерфейса будет остановлено.
Далее в конфигурационном файле идет описание сервисов (protocols). Определение сервисов основано на установлении TCP-подключения на определенный порт, но есть также специальные классы для некоторых сервисов. Список сервисов, поддерживаемых “из коробки” можно просмотреть в конфигурационном файле (возможно также добавление дополнительных сервисов с помощью тега <protocol-plugin>).
При обработке события newEvent, в случае, если IP-адрес определен как “managed” демон capsd начинает сканирование сервисов в порядке их следования в конфигурационном файле. Первым в конфигурационном файле указан протокол ICMP:
<protocol-plugin protocol="ICMP"
class-name="org.opennms.netmgt.capsd.IcmpPlugin"
scan="on" user-defined="false">
<property key="timeout" value="2000"/>
<property key="retry" value="2"/>
</protocol-plugin>
Описание каждого сервиса заключено внутри тега <protocol-plugin>
Данный тег содержит следующие атрибуты:
* protocol – название сервиса;
* class-name – определяет класс, который будет использоваться для сканирования сервиса;* scan – признак включения сканирования данного сервиса (“on” -сканирование сервиса включено, “off” – сервис не будет сканироваться);
* user-defined – добавление новых сервисов возможно черезвеб-интерфейс. В таком случае атрибут примет значение “true”.
В каждом сервисе можно указывать дополнительные параметры, определяемые через значения key и value внутри тега <property>. Кроме того, применительно к каждому сервису можно применять дополнительный тег <protocol-configuration>, в котором можно описывать группы IP-адресов, исключенные (или включенные) из сканирования.
Например:
<protocol-plugin protocol="SNMP"
class-name="org.opennms.netmgt.capsd.plugins.SnmpPlugin" scan="on"
user-defined="false">
<protocol-configuration scan="off" user-defined="false">
<range begin="10.10.12.1" end="10.10.14.254"/>
<property key="timeout" value="4000"/>
<property key="retry" value="3"/>
</protocol-configuration>
<protocol-configuration scan="on" user-defined="false">
<specific>10.10.11.1</specific>
</protocol-configuration>
<property key="timeout" value="2000" />
<property key="retry" value="1" />
</protocol-plugin>
В приведенном выше примере мы переопределили группу адресов (10.10.12.1 -10.10.14.254), для которых определение сервиса SNMP будет отключено, и добавили адрес 10.10.11.1, для которого наличие сервиса будет определяться. Также можно переопределить общие для всех настройки обнаружения, заданные в головном теге <capsd-configuration>с помощью тега <ip-management>:
<ip-management policy="managed">
<range begin="10.10.10.1" end="10.10.14.254"/>
<include-url>file:/opt/OpenNMS/etc/include</include-url>
</ip-management>
где значение атрибута policy может принимать значение “managed” и “unmanaged”. Данные настройки действуют на все указанные в capsd-configuration сервисы, если только диапазон адресов для какого-либо сервиса (в нашем случае – SNMP) не переопределен c помощью тега <protocol-configuration>.
Необходимо заметить, что если в процессе обнаружения (discovery) интерфейс по каким-то причинам не был определен, и не было зарегистрировано событие newSuspect, демон capsd для такого интерфейса не будет запущен, даже если указать IP-адрес в файле конфигурации capsd явно.
астройка периодичности опросов (polling)
После сбора информации об узлах, интерфейсах и функционирующих на них сервисах приходит время мониторинга. Информация о состоянии сервисов, интерфейсов и узлов собирается двумя основными способами.
Первый способ основан на периодических опросах (polling). Процессы-мониторы подключаются к ресурсу и производят простой тест, чтобы определить текущее состояние ресурса. Если ресурс недоступен – генерируется определенное событие.
Настройка периодичности опросов описывается в файле poller-configuration.xml. Для удобства введено понятие пакета (package) сервисов. В файле можно описать несколько пакетов, в каждом из которых можно указать собственную периодичность опросов, а также определить уникальное подмножество опрашиваемых сервисов. Кроме того, в каждом пакете можно задавать собственную модель действий при недоступности сервиса.
Период опроса в случае недоступности сервиса меняется динамически и может гибко настраиваться. Также для каждого пакета можно задать время простоя, когда не будет производиться опрос сервисов. Глобально периоды простоя для всех пакетов можно задать в файле poll-outages.xml. Данные опросов собираются с помощью библиотеки jrrd – Java-реализации всем известной RRD (Round Robin Database). Рассмотрим файл poller-configuration.xml:
<poller-configuration threads="30"
serviceUnresponsiveEnabled="false"
nextOutageId="SELECT nextval('outageNxtId')" xmlrpc="false">
<node-outage status="on" pollAllIfNoCriticalServiceDefined="true">
<critical-service name="ICMP" />
</node-outage>
Параметр threads определяет максимальное количество потоков для опроса. Варьируется в зависимости от количества опрашиваемых устройств и мощности сервера. Будьте внимательны с данным параметром, при большом количестве опрашиваемых устройств может потребоваться увеличить количество потоков для опроса, так как демон может не успеть опросить все устройства в течение заданного времени. Узнать, успевает ли демон опросить все устройства и сервисы, можно, заглянув в файл logs/daemon/poller.log. В файле нужно найти строку, содержащую максимальное значение параметра alive:
2008-05-15 17:01:16,201 DEBUG [PollerScheduler-40 Pool]RunnableConsumerThreadPool$SizingFifoQueue:
adjust: started fiber PollerScheduler-40 Pool-fiber21
ratio = 1.0476191, alive = 21
Если значение параметра alive+1 (так как есть еще родительский поток) близко к значению параметра threads, то есть смысл увеличить количество потоков опроса.
Параметр serviceUnresponsiveEnabled определяет, какое событие будет генерироваться в случае кратковременного сбоя – “выход из строя” (outage) или только “сервис не отвечает” (unresponsive). Чтобы не генерировать событие “выход из строя” при кратковременной недоступности, нужно выставить этот параметр в “true”.
Тег <node-outage> определяет поведение в случае недоступности всех интерфейсов на узле. Если во время опроса какой-либо сервис на интерфейсе не отвечает, генерируется событие NodeLostService, если все сервисы на интерфейсе не отвечают, то генерируется событие InterfaceDown. Если параметру status присвоено значение “on”, то в случае недоступности всех интерфейсов узла не генерируется множество событий NodeLostService и InterfaceDown, а лишь одно событие – NodeDown. Во время недоступности узла, в случае, если с помощью тега <critical-service> определен критический сервис (в нашем случае ICMP), будет опрашиваться только критический сервис.
После того как критический сервис будет восстановлен, начнут опрашиваться все остальные сервисы. Если тег <critical-service> не задан, то опрос всех сервисов определяется параметром pollAllIfNoCriticalServiceDefined. Если данное свойство имеет значение “false”, то будет опрашиваться только первый сервис в пакете, иначе – все. Для удобства создадим на основе уже готового пакета exmaple1 пакет ICMP-PKG и поместим туда единственный сервис ICMP, так как хотим опрашивать устройства по данному протоколу чаще, чем, например, собирать статистику по SNMP:
<package name="ICMP-PKG">
<filter>IPADDR != '0.0.0.0'</filter>
<include-range begin="1.1.1.1" end="254.254.254.254" />
<rrd step="60">
<rra>RRA:AVERAGE:0.5:1:89280</rra>
<rra>RRA:AVERAGE:0.5:60:8784</rra>
<rra>RRA:AVERAGE:0.5:1440:366</rra>
<rra>RRA:MAX:0.5:1440:366</rra>
<rra>RRA:MIN:0.5:1440:366</rra>
</rrd>
<service name="ICMP" interval="30000"
user-defined="false" status="on">
<parameter key="retry" value="2" />
<parameter key="timeout" value="3000" />
<parameter key="rrd-repository"
value="D:/PROGRA~1/OpenNMS/share/rrd/response" />
<parameter key="rrd-base-name" value="icmp" />
<parameter key="ds-name" value="icmp" />
</service>
<downtime interval="20000" begin="0" end="300000"/>
<!-- 20s, 0, 5m -->
<downtime interval="120000" begin="300000" end="3600000"/>
<!-- 2m, 5m, 1h -->
<downtime interval="300000" begin="3600000" end="432000000"/>
<!-- 5m, 1h, 5d -->
<downtime begin="432000000" delete="true" />
<!-- anything after 5 days delete -->
</package>
Обратите внимание на тег <filter>. Внутри пакета он может быть задан в единственном числе. В теге можно задать фильтрацию IP-адресов по маскам. Например, так:
<filter>IPADDR = '10.*.*.*'</filter>
- будут опрашиваться лишь адреса 10.0.0.0/8. Также можно задавать диапазоны адресов с помощью уже известного тега <include-range>, внутри которого задан диапазон IP-адресов для опроса. Напомню, что опрашиваться будут лишь сервисы на интерфейсах, найденных в процессе обнаружения. То есть сервисов на интерфейсе может быть найдено множество, однако сбор статистики будет происходить лишь по сервисам, указанным в пакетах файла poller-configuration. Внутри пакета с помощью тега<service>может быть определено несколько сервисов (в нашем пакете только сервис ICMP). Рассмотрим атрибуты и вложенные теги тега<service>:
Атрибут status может принимать значения “on” – статистика собирается и “off” – сбор статистики отключен.
В тегах <parameter> с помощью атрибутов key и value задаются дополнительные параметры, среди которых следует обратить внимание на параметр rrd-repository, в котором задается путь для хранения данных опросов. Учтите, что этот параметр связан с параметром rrd.base.dir в файле opennms.properties. Не забывайте об этом, если будете переносить конфигурационные файлы с сервера на сервер.
В тегах<downtime> описывается поведение опроса сервиса в случае его недоступности:
* Атрибут interval – задает периодичность опроса при недоступности;
* Атрибут begin - время начала заданного периода опросамиллисекундах;
* Атрибут end - время с окончания заданного периода опроса вмиллисекундах.
То есть в строке:
interval="20000" begin="0" end="300000"/>
указано, что в случае недоступности сервиса производить опрос каждые 20 секунд, начиная с нулевой секунды и по достижении 5 минут времени недоступности. Начиная с пяти минут недоступности сервиса можно увеличить интервал опроса до 2 минут, таким образом уменьшив нагрузку на вычислительные ресурсы:
<downtime interval="120000" begin="300000" end="3600000"/>
а после недоступности сервиса в течение часа увеличить интервал опроса еще больше.
Тег <rrd>, в котором задаются параметры сбора и хранения данных, заслуживает более пристального изучения и будет рассмотрен позже. Второй способ сбора статистики основан на коллекторах (collectors).
Он немного сложнее в настройке, но может дать больше информации. Существует возможность использования нескольких коллекторов, мы остановимся подробнее на сборе статистики с помощью опросов SNMP-агентов.
Настройка сбора статистики по протоколу SNMP
При настройках по умолчанию в OpenNMS 1.5.90 для сбора статистики на основе коллекторов используется протокол SNMP версии 1 и 2(с).
Однако существует также возможность использовать протокол SNMP-версии 3. Для активации возможности сбора информации по SNMPv3 необходимо использовать библиотеку SNMP4J [1], поддерживающую протокол SNMPv3 (по умолчанию используется библиотека JoeSNMP). Однако для большинства случаев достаточно SNMPv1 и SNMPv2. Для активации SNMPv3 необходимо раскомментировать строчку:
org.opennms.snmp.strategyClass=org.opennms.netmgt.snmp.snmp4j.Snmp4JStrategy
в файле opennms.properties и поставить символ комментария перед строчкой с JoeSNMP. Теперь следует возвратиться к файлу capsd-configuration.xml и добавить для удобства новый сервис с названием SNMPv3 (название может быть любым, удобным вам). В будущем это поможет отличать узлы с обнаруженными SNMP-агентами разных версий:
<protocol-plugin protocol="SNMPv3"
class-name="org.opennms.netmgt.capsd.SnmpPlugin"
scan="on" user-defined="false">
<property key="force version" value="SNMPv3"/>
<property key="timeout" value="2000"/>
<property key="retry" value="3"/>
</protocol-plugin>
Также необходимо добавить сервис с таким же именем в файл poller-configuration.xml, если этого не сделать, сервис определится, но опрашиваться не будет. Здесь есть одна тонкость – если не указывать конкретную версию протокола и вообще исключить строчку
<property key="force version" value="SNMPv3"/>
(как это сделано в конфигурации по умолчанию), то будут найдены SNMP-агенты версий, указанных в файле snmp-config.xml. При сканировании сервиса SNMP демон capsd обращается за дополнительной информацией в файл snmp-config.xml:
<?xml version="1.0"?>
<snmp-config port="161" retry="3" timeout="1500"
read-community="public" write-community="private">
<definition version="v3" security-name="myname"
auth-protocol="MD5" auth-passphrase="yourmd5pass">
<specific>10.10.10.1</specific>
<specific>10.10.11.1</specific>
</definition>
<definition version="v1" read-community="charoday">
<specific>10.10.14.1</specific>
</definition>
</snmp-config>
В файле находится дополнительная информация для опроса SNMP-агентов. Корневой тег файла называется <snmp-config>
* port - порт, через который идет обращение к SNMP-агенту;* retry – количество попыток подключения к SNMP-агенту;
* timeout - время ожидания ответа от агента;
* read-community – строка для доступа на чтение к SNMP-агенту;
* write-community – строка для доступа на запись к SNMP-агенту;
* version - версия SNMP-протокола.
Можно переопределить атрибуты, указанные в корневом теге, описав внутри него тег <definition>. В нашем случае в первом вложенном теге <definition> мы переопределили версию протокола SNMP. Внутри этого тега также можно определять диапазоны IP-адресов с помощью тегов <include-range>, <specific> и <exclude-range>.
Для определения протокола SNMPv3 существуют дополнительные атрибуты:
* security-name – имя для аутентификации;
* auth-protocol - протокол шифрования пароля аутентификации (SHA или MD5);
* auth-passphrase – пароль аутентификации (шифруется MD5 или SHA);
* privacy-protocol – протокол шифрования данных (DES);
* privacy-passphrase – пароль шифрования данных.
Протокол SNMPv3 поддерживает три типа аутентификации: noAuthNoPriv, authNoPriv и authPriv.
Если указать все атрибуты – получим тип authPriv (самый защищенный тип: шифруются данные авторизации и все передаваемые данные).
Если не указывать атрибуты privacy-protocol и privacy-passphrase, то получим тип authNoPriv, когда в защищенном виде передаются лишь аутентификационные данные, остальные данные не шифруются.
Если указать только атрибут security-name, то получим самый незащищенный тип noAuthNoPriv.
Подробнее о модели безопасности SNMPv3 (User-Based Security Model – USM и VACM – View-based Access-Control Model) можно найти в RFC3414 и RFC3415. Обратите внимание, что библиотека SNMP4J [8] ревностно относится к соблюдению стандартов, согласно которым auth-passphrase должен быть не менее 8 символов, то же касается и privacy-passphrase. Поэтому не советую испытывать судьбу коротким паролем. Что дальше? После осуществления всех приведенных выше настроек можно запустить openNMS:
./opennms start
или для Windows:
opennms.bat start
Через некоторое время после запуска в списке узлов появятся первые обнаруженные устройства с найденными интерфейсами и сервисами. Это уже работающая система. Через веб-интерфейс мы можем получать информацию о событиях, таких как доступность сервисов и устройств, просматривать графики загрузки каналов связи и ряд других, уже внесенных в типовую конфигурацию графиков. На рис. 2 показана основная страница веб-интерфейса OpenNMS.
Рисунок 2. Главная страница веб-интерфейса
Однако многие вопросы дополнительной настройки остались неосвещенными, например, настройка уведомлений о событиях на e-mail, кастомизация веб-интерфейса, отвечающая требованиям вашей сети, тонкая настройка хранимых в базах RRD данных, а также настройка параметров отображения графиков и создание отчетов о состоянии сервисов и устройств. Подробнее изучим данные вопросы в следующей статье.
Постовой
Уже близиться 8-ое марта, и вопрос подарков встает перед мужской частью населения очень остро. Обратите внимание на интернет магазин часов, где можно купить копию настоящих швейцарских часов.
Из всех зол выбираем меньшее. Гостиниц в Камышине немного, лучшая из них определенно гостиница Глория.