headermask image



Устанавливаем и настраиваем систему мониторинга сети OpenNMS, часть 3

Начало тут и тут.

Что ж, вопросы с установкой решены , и система openNMS работает. Как же теперь сделать ее более функциональной, а работу с ней более удобной? Запасаемся временем и терпением, не забываем подключить к работе голову и руки – и вперед!

Возможности веб-интерфейса

Какую же информацию мы можем получить после начальной настройки OpenNMS через веб-интерфейс? На главной странице веб-интерфейса, на которую мы попадаем сразу после авторизации, представлена информация о текущем
состоянии наблюдаемых устройств, и если какое-то устройство, интерфейс или сервис недоступны, то эта информация выделяется цветом (см. рис. 1).

opennms_monitor2_1.png

Рисунок 1. Главная страница веб-интерфейса

В верхней части интерфейса расположено основное навигационное меню, с помощью которого можно просмотреть список всех проверяемых узлов (меню “Node List”), либо с помощью поискового интерфейса (меню “Search”)
найти конкретное устройство по различным критериям поиска: IP-адресу, наименованию, предоставляемому сервису и др.

Каждому узлу можно сопоставить дополнительную инвентарную информацию и затем просматривать ее через меню “Assets” (имущество). Путем несложной навигации можно узнать подробную статистику о текущих и исправленных отказах (меню “Outages”) устройств и сервисов, об авариях (меню “Alarms”), а также обо всех событиях (меню “Events”), зарегистрированных системой.

В меню “Reports” (отчеты) можно просмотреть отчеты о доступности и графики, полученные при опросах устройств. Это могут быть и основанные на ICMP-запросах RoundTrip Ping и StrafePing (статистика по потерянным пакетам), и графики, основанные на данных, собранных с помощью SNMP. Имеется возможность составлять собственные отчеты (Custom Reports), основанные на собранных данных.

В меню “Surveillance” (слежение) можно сгруппировать информацию об узлах сети по определенным признакам в виде таблицы. Можно, например, категоризировать устройства по территориальной принадлежности и типу оборудования. По умолчанию ни один узел не принадлежит какой-либо категории, добавление узла в категорию можно произвести через администраторский интерфейс (меню “Admin”).

В меню “DashBoard” (панель инструментов) на основе категоризации из меню “Surveillance” собрана дополнительная информация о состоянии устройств, такая, как текущие аварии, состояние об отказах устройства за последние 24 часа и статистические графики.

С помощью меню “Admin” существует возможность изменять многие настройки OpenNMS, но возможностей веб-интерфейса в некоторых случаях бывает недостаточно, поэтому возникает необходимость прямого
редактирования конфигурационных файлов.

Группировка узлов по определенным признакам с помощью таблиц слежения

Визуальное представление многих данных мониторинга, просматриваемых через веб-интерфейс, можно изменять в некоторых пределах. Одна из удобных функций заключается в возможности группировки узлов сети по
различным признакам в виде таблицы слежения. В меню “Surveillance” (слежение) уже задано разбиение на категории по умолчанию (см. рис. 2), однако сетевые устройства пока не привязаны к существующим категориям
слежения.

opennms_monitor2_2.png

Рисунок 2. Вид меню “Surveillance” после установки системы

Добавить устройство в необходимую категорию по определенным признакам можно через меню “Admin -> Manage Surveillance Categories” (см. рис. 3).

opennms_monitor2_3.png

Рисунок 3. Добавление узлов в категории по определенным признакам

В строках и столбцах таблицы слежения определяются признаки наблюдаемых устройств, а в местах пересечения конкретной строки и столбца отображается количество узлов, удовлетворяющих этим признакам. Можно
создать необходимое количество собственных категорий слежения, на основе которых в дальнейшем построить собственную таблицу (таких таблиц может быть несколько). Для создания таблицы слежения или модификации
существующей необходимо отредактировать конфигурационный файл surveillance-views.xml:

<?xml version="1.0" encoding="utf-8"?>
<surveillance-view-configuration
xmlns:this="http://www.opennms.org/xsd/config/surveillance-views"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opennms.org/xsd/config/surveillance-views
http://www.opennms.org/xsd/config/surveillance-views.xsd"
default-view="by Priority and Office" >
<views >
<view name="default" refresh-seconds="300" >
<rows>
<row-def row="1" label="Main Office" >
<category name="MainOffice"/>
</row-def>
<row-def row="2" label="Filial 1" >
<category name="Filial-1" />
</row-def>
<row-def row="3" label="Filial 2" >
<category name="Filial-2" />
</row-def>
<row-def row="4" label="Filial 3" >
<category name="Filial-3" />
</row-def>
</rows>
<columns>
<column-def col="1" label="Routers" >
<category name="Routers" />
</column-def>
<column-def col="2" label="Servers" >
<category name="Servers" />
</column-def>
<column-def col="3" label="Switches" >
<category name="Switches" />
</column-def>
</columns>
</view>

<view name="by Priority and Office" refresh-seconds="300" >
<rows>
<row-def row="1" label="Main Office" >
<category name="MainOffice"/>
</row-def>
<row-def row="2" label="Filial 1" >
<category name="Filial-1" />
</row-def>
<row-def row="3" label="Filial 2" >
<category name="Filial-2" />
</row-def>
<row-def row="3" label="Filial 3" >
<category name="Filial-3" />
</row-def>
</rows>
<columns>
<column-def col="1" label="High Priority" >
<category name="HighPriority" />
</column-def>
<column-def col="2" label="Mid Priority" >
<category name="MidPriority" />
</column-def>
<column-def col="3" label="Low Priority" >
<category name="LowPriority" />
</column-def>
</columns>
</view>
</views>
</surveillance-view-configuration>

В тег <views> вложен тег <view>, в котором описываются строки и столбцы таблицы категорий. В параметре name тега <view> задается название таблицы категорий. В теге <rows> описываются строки таблицы с помощью
вложенных тегов <row-def>, а в теге <columns> с помощью <column-def> описываются столбцы. В тегах <row-def> и <column-def>, которые являются строками и столбцами таблицы категорий, описываются категории узлов с
помощью тегов <category>. Данные в тегах <category> должны соответствовать данным, заполненным через меню “Admin -> Manage Surveillance Categories” (данные хранятся в таблице categories базы данных PostgreSQL), иначе при попытке перейти в меню “Surveillance” мы получим ошибку.

В приведенном выше примере описаны два разных разбиения на категории – “default” и “by Priority and Office” (см. рис. 4), однако вы можете создать таблицы слежения по вашим потребностям.

opennms_monitor2_4.png

Рисунок 4. Вид меню “Surveillance” после настройки таблицы категорий

В корневом теге <surveillance-view-configuration> в параметре default-view можно задать отображаемую по умолчанию таблицу слежения (в приведенном выше конфигурационном файле этому параметру присвоено имя
таблицы “by Priority and Office”, которая будет отображаться при переходе в меню “Surveillance” и “DashBoard” (см. рис. 5).

opennms_monitor2_5.png

Рисунок 5. Меню “DashBoard” после настройки таблицы категорий

Настройка уведомлений

В openNMS существует возможность использовать систему уведомлений, чтобы оповещать пользователей о происходящих событиях. Основным методом уведомлений является отправка e-mail-сообщений пользователю, но
существует и ряд других методов, например, отправка POST/GET-запросов на веб-сервер, отправка уведомлений по протоколу XMPP (jabber), пересылка уведомлений посредством запуска внешней программы (подобным образом можно отправить SMS-сообщение с помощью GSM-модема) и уведомления с помощью формирования SNMP traps.

Мы рассмотрим классический способ с отправкой уведомлений на электронную почту, для чего нам понадобится внести необходимые настройки в следующие конфигурационные файлы:

  • javamail-configuration.properties – в файле содержатся настройки почтового сервера и учетной записи (почтового ящика);
  • destinationPaths.xml – в файле описывается, кто получает уведомления;
  • notifd-configuration.xml – здесь описываются глобальные настройки службы уведомлений;
  • notificationCommands.xml – в файле описываются методы уведомления, такие, как e-mail-оповещения, XMPP и др.;
  • notification.xml – здесь содержится описание уведомлений.

Будем использовать тип доставки javaEmail (уведомления на электронную почту) для оповещения о происходящих в системе событиях. Для этого изменим настройки файла javamail-configuration.properties, чтобы отправлять сообщения через ящик на сервере Google Mail, например (однако это может быть и ваш корпоративный почтовый сервер):

org.opennms.core.utils.useJMTA=false
org.opennms.core.utils.transport=smtps
org.opennms.core.utils.mailHost=smtp.gmail.com
org.opennms.core.utils.smtpport=465
org.opennms.core.utils.authenticate=true
org.opennms.core.utils.authenticateUser=user@gmail.com
org.opennms.core.utils.authenticatePassword=userpass
org.opennms.core.utils.starttls.enable=true
org.opennms.core.utils.smtpssl.enable=true
org.opennms.core.utils.messageContentType=text/html
org.opennms.core.utils.charset=windows-1251

Google Mail использует SMTP over SSL (TLSv1 и SSLv3), поэтому параметр org.opennms.core.utils.smtpssl.enable выставлен в true, в качестве транспорта (org.opennms.core.utils.transport) используется SMTPS, а порт для подключения (org.opennms.core.utils.smtpport) используется стандартный для SMTPS – 465. В более простых случаях, когда используется обычный SMTP-протокол без шифрования, необходимо будет заменить номер порта на 25, транспорт – на smtp и параметры smtpssl.enable и starttls.enable=true выставить в false.

В файле destinationPaths.xml содержится информация об адресах доставки уведомлений:

<?xml version="1.0" encoding="UTF-8"?>
<destinationPaths xmlns=
"http://xmlns.opennms.org/xsd/destinationPaths">
<ns1:header xmlns:ns1="http://xmlns.opennms.org/xsd/types">
<rev xmlns="">1.2</rev>
<created xmlns="">10 Июнь 2008 г. 4:43:30 GMT</created>
<mstation xmlns="">localhost</mstation>
</ns1:header>
<path name="Email-Admin" initial-delay="0s">
<target interval="0s">
<name xmlns="">Admin</name>
<command xmlns="">javaEmail</command>
</target>
</path>
</destinationPaths>

Атрибут name тега <path> определяет имя блока адреса доставки. Значение данного атрибута также используется в файле notifications.xml в качестве адреса доставки при описании конкретного вида уведомлений.
Внутри каждого тега <path> можно описать несколько вложенных тегов <target>, в которых с помощью тега <name> можно описать адресатов, которым будут посылаться уведомления, а также способ доставки (в нашем случае javaEmail) с помощью тега <command>. В качестве адресата может выступать как отдельный пользователь, так и группа или роль. Добавить учетную запись пользователя, группы и роли можно через веб-интерфейс (меню “Admin -> Configure Users, Groups and Roles”) или через конфигурационные файлы users.xml (пользователи) и groups.xml (группы и роли).

Для обеспечения более гибкой отправки уведомлений в файле destinationPaths.xml можно описать несколько дополнительных тегов <path>:

<path name="Email-Filial1" initial-delay="0s">
<target interval="0m">
<name xmlns="">Filial1</name>
<autoNotify xmlns="">auto</autoNotify>
<command xmlns="">javaEmail</command>
</target>
</path>

В приведенном выше коде создается путь для отправки уведомлений на адрес абонента Filial1. Конечно, учетная запись пользователя (или группы, роли) Filial1 должна быть предварительно создана, в таком случае уведомления будут отправляться, например, одному или нескольким сотрудникам филиала No.1. Эти сотрудники будут получать почтовые сообщения в случае проблем с сетевыми устройствами или сервисами.

Настройки уведомлений задаются в файле notifications.xml. По умолчанию здесь уже заданы стандартные типы уведомлений, которые отправляются на адрес доставки Email-Admin (то есть всем пользователям группы Admin).
Теперь добавим собственное уведомление, которое будет отправляться по адресу доставки Email-Filial1:

<notification name="Filial1-nodeDown" status="on" writeable="yes">
<uei xmlns="">uei.opennms.org/nodes/nodeDown</uei>
<rule xmlns="">IPADDR IPLIKE 10.10.12.*</rule>
<destinationPath xmlns="">Email-Filial1</destinationPath>
<text-message xmlns="">
All services are down on node %nodelabel%.
</text-message>
<subject xmlns="">Node %nodelabel% down.</subject>
<numeric-message xmlns="">111-%noticeid%</numeric-message>
</notification>

Описанное уведомление будет отправлено по адресу Email-Filial1 (см. файл destinationPaths.xml) при возникновении события nodeDown (<uei xmlns=”"> uei.opennms.org/nodes/nodeDown </uei>), когда недоступны узлы, принадлежащие сети 10.10.12.0/24 (см. правило <rule xmlns=”">IPADDR IPLIKE 10.10.12.*</rule>).

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

Автор: Андрей Семенов

О разном

Высокотехнологичные гаджеты, инновационные технологии, оригинальные разработки и многое другое в блоге mobilexus.ru

Если вам нужна качественная медицинская помощь, обращайтесь в Центр медицины имени Розина – Консультация врача-специалиста в Митино. Ваша проблема будет решена в кратчайшие сроки.

Похожие посты
  • Устанавливаем и настраиваем систему мониторинга сети OpenNMS, часть 1
  • Устанавливаем и настраиваем систему мониторинга сети OpenNMS, часть 4
  • Устанавливаем и настраиваем систему мониторинга сети OpenNMS, часть 2
  • Устанавливаем систему мониторинга zabbix
  • Устанавливаем русский man в FreeBSD
  • Настраиваем Windows Server 2003 на обмен маршрутами RIP с роутерами Cisco. Часть 2
  • Настраиваем 2003 Server на обмен маршрутами RIP с роутерами Cisco. Часть 1
  • 3 способа мониторинга веб-сайтов в SCOM
  • Система мониторинга Cacti
  • Введение в защиту доступа к сети NAP. Часть 2
  • Комментарии

    Your email is never published nor shared. Required fields are marked *

    *
    *