Система мониторинга OpenNMS

    image

    Ни в малейшей степени не желаю показаться непатриотичным, но исторически сложилось так, что при выборе корпоративной системы мониторинга сетевой инфраструктуры у нас на предприятии победила OpenNMS, сместив с этой должности бабушку Cacti и обогнав земляка-Zabbix. Сравнительный анализ Open Source систем мониторинга не входит в мои планы, поэтому просто в общих чертах расскажу об OpenNMS, благо на Хабре о ней не писали и вообще информации о ней немного.

    Основная функция OpenNMS (Open Network Monitoring System) – мониторинг различных сервисов и внутренних систем сетевого и серверного оборудования. Для сбора информации используются так называемые «коллекторы», работающие по SNMP, HTTP, ИТДИТП протоколам. Отдельных серверных агентов у OpenNMS нет. Если информация окажется востребованной, то примеры реализаций «обёрток» я опишу в следующем материале в разделе «Юзкейсы». Не хочу больше повторять ошибок с публикацией гигантских простыней текста, в которых сложно разобраться как автору, так и читателям.

    Краткая характеристика


    OpenNMS динамично развивается, довольно неплохо документирована, но сообщество разрозненное, а конфигурирование в виде правки несметного количества XML файлов может многих отпугнуть. Система написана на Java с довесками на Perl и выпущено порядочное количество дистрибутивов под различные платформы. При желании её можно запустить на любой машине с Java SDK и сервером PostgreSQL.

    A 1 GHz Pentium III (or equivalent processor) or better. A minimum of 256 MB of RAM, although 512 MB is strongly recommended.

    Эти системные требования из официальной документации, мягко говоря, являются самыми минимальными и позволят именно что только запустить саму систему. Поэтому, позволю себе немного подкорректировать их: 64-битный CPU, 2 Gb RAM (это самый-самый минимум), высокопроизводительный жёсткий диск.

    Прожорливость системы напрямую зависит от количества узлов, которые она будет мониторить. Система с более чем 1500 узлами и 5000 интерфейсами на них (VLAN'ы, порты, сервисы и т.п.) комфортно себя чувствует на Xeon E5520 c 12 Gb оперативки и SAS хардами. При этом под хранение rrd файлов отдан 2Gb tmpfs раздел. Запас по мощности выделен более чем двухкратный — это задел на рост сети и аппетитов системы в процессе обновления и развития.

    Установка


    Предварительно ставим ntp, net-snmp, net-snmp-utils, postgresql, postgresql-server, perl. Базово настраиваем и запускаем все означенные сервисы. Затем устанавливаем JDK последней версии, скачав его с сайта Oracle, и наконец можно подключать репозиторий OpenNMS и ставить саму систему
    rpm -Uvh http://yum.opennms.org/repofiles/opennms-repo-stable-rhel6.noarch.rpm
    yum install opennms iplike
    

    Последний пакет – довесок к PostgreSQL от разработчиков OpenNMS в виде хранимой процедуры IPLIKE, помогающей работать с запросами по IP-адресам и адресам сетей, используя маски вроде 192.168.4-255.*, что активно используется в рамках самой системы.

    [!] Если имя хоста, на который ставится система, не резолвится на прописанных в resolv.conf DNS серверах, пропишите его в hosts. В противном случае, система не запустится. Также следует обратить внимание на первичную настройку PostgreSQL. После дефолтной установки сервера в /var/lib/pgsql/data/pg_hba.conf в поставьте method trust всем трём local подключениям.
    /opt/opennms/bin/runjava -S /usr/java/latest/bin/java
    /opt/opennms/bin/install -dis
    /etc/init.d/opennms start
    

    После запуска система будет доступна по hostname:8980. Отдельный веб-сервер устанавливать не обязательно – вебинтерфейс OpenNMS работает через Jetty сервер. Впрочем, при желании можно переконфигурировать сам Jetty, или на 80й порт повесить Nginx или apache с mod_proxy и делать proxy_pass на все запросы.

    При переустановке всей системы, следует дропнуть базу данных и удалить /var/opennms. В противном случае возникнут коллизии с графиками и отчётами. Для полной переустановки делаем yum reinstall opennms и /opt/opennms/bin/install -dis, для частичной – только второе.

    Бывает так, что OpenNMS при запуске выдаёт сообщение Started OpenNMS, but it has not finished starting up. Прежде всего, следует проверить, не допущена ли ошибка в конфигурации и все ли сервисы запущены (команда opennms -v status). И если все сервисы запущены, то у меня для вас плохие новости – OpenNMS не хватает ресурсов и она хочет послабления. Создаём файл $opennms/etc/opennms.conf с содержанием START_TIMEOUT=20. Число в параметре – это коэффициент, на который будет умножаться 5-секундный интервал проверки запущенности всех сервисов. По умолчанию этот параметр равен 10 и получается, что если за 50 секунд все сервисы не успеют отрапортовать об успешном запуске – будет возвращена ошибка. То есть START_TIMEOUT=20 это 100-секундное ожидание запуска всех систем.

    Интерфейс и настройка


    Пожалуй, я пропущу часть с детальным описанием веб-интерфейса – в общих чертах система станет понятной через 10 минут прогулок по разделам, но стоит сразу отметить, что одной работой с веб-интерфейсом при конфигурировании системы не отделаться — придётся основательно покопаться в XML файлах.



    Так, например, добавить SNMP community для определенной подсети можно легко через веб-интерфейс в разделе Admin → Configure SNMP by IP. Но просмотреть и отредактировать уже добавленные community можно только в соответствующем XML-файле. При этом диапазоны подсетей, за которыми нужно наблюдать (network discovery), можно полностью редактировать из веб-интерфейса.

    Поскольку редактировать конфигурационные файлы придётся много, я бы рекомендовал подключить любую привычную CVS, чтобы отслеживать изменения. Также я бы посоветовал выработать привычку после редактирования конфигурационного файла проверять его как xmllint --noout filename.xml. И финальный штрих: изменения конфигурационных файлов применяются перезапуском демона opennms, что занимает порядочно времени.

    Внутренняя механика



    Основной единицей сбора данных является интерфейс, который под собой объединяет определенные сервисы. Все интерфейсы на одном устройстве группируются в ноду. Интерфейс не обязательно может быть сетевым – с точки зрения OpenNMS температурные датчики тоже являются интерфейсами. Начиная с версии 1.9, однотипные интерфейсы организуются в отдельные группы.

    При обнаружении нового интерфейса срабатывает событие newSuspect, после чего система пытается обнаружить сервисы на этом интерфейсе, по цепочке найти другие интерфейсы на устройстве и сгруппировать полученную информацию в ноду. Получать данные о новых интерфейсах OpenNMS может автоматически (проводя поиск по заданным диапазонам с определенной периодичностью), вручную (вызывая perl скрипт) или по получению SNMP trap’а.
    # Вручную скормим системе сервер, на котором она сама и установлена:
    perl /opt/opennms/bin/send-event.pl --interface 192.168.11.11 uei.opennms.org/internal/discovery/newSuspect
    


    Теперь в Events → All Events можно наблюдать завораживающий процесс рождения новой ноды. Скорость её появления варьируется в зависимости от устройства и составляет от нескольких секунд до нескольких минут.



    Отдельный интерес представляют собой Resource Graphs – графики системных ресурсов. После добавления новой ноды мы увидим только данные по умолчанию для каждого сервиса (например, время отклика ICMP и HTTP в случае наличия последнего). Однако, вполне можно расширить объём получаемой информации. Например, мы хотим снимать больше данных с другого сервера под управлением CentOS. Получать данные мы будем по SNMP, поэтому на целевом сервере устанавливаем net-snmp и редактируем /etc/init.d/snmp/snmpd.conf
    # комментируем в начале конфига строки с com2sec, group, view и 
    # добавляем read-only комьюнити
    rocommunity stat
    # правим location и contact
    syslocation Datacenter N1, Rack 2
    syscontact admin@domain.tld
    # описываем разделы для мониторинга
    disk / 10000
    disk /var 10000
    # описываем предельные значения load average
    load 12 14 14
    


    Открываем 161 UDP порт в iptables, запускаем snmpd и заводим новое SNMP комьюнити в OpenNMS (Admin → Operations → Configure SNMP Community Names by IP). После этого можно открывать добавленную ноду и делать ей Rescan. После завершения сканирования, информации станет больше и графики станут предоставлять данные о дисковом пространстве, инодах и загрузке системы.

    Перезагружать opennms при добавлении SNMP комьюнити через админку формально не требуется. Но иногда обновление этого файла или добавление новой discovery group подхватывается с большой задержкой и быстрее перезагрузить opennms, чем ждать, пока она очнётся самостоятельно.

    Ещё немного внутренней механики


    Разумеется, OpenNMS умеет сканировать сеть и определять появление новых устройств в сети. Процесс поиска настраивается в веб-интерфейсе в разделе Admin → Configure Discovery или в файле $opennms/etc/discovery-configuration.xml.

    image
    Изображение с сайта oopsmonk

    Чуть детальнее остановимся на связях между сервисами в OpenNMS, запускающимися после обнаружения нового интерфейса и срабатывания newSuspect. Существует два сервиса, которые определяют наличие различных сервисов: capsd (capabilities daemon) и provisiond (provisioning daemon). По умолчанию они запускаются оба, и для меня остаётся загадкой, зачем это сделано. Ведь начиная с версии 1.8.0, capsd признан устаревшим, хотя при этом сохраняет высший приоритет по сравнению с provisiond.

    Поэтому моя личная рекомендация — отключать capsd, перекладывая всю заботу об обнаружении сервисов на плечи provisiond. Работа с последним открывает доступ к условиям инициализации (provisioning requisitions), которые позволяют гибко настраивать определяемые сервисы, автоматически включать мониторинг нужных интерфейсов на узлах, сортировать узлы по категориям и т.п.

    Непосредственно определением сервиса занимаются детекторы, являющиеся частью provisiond. Детекторы занимаются только обнаружением и регистрацией сервиса в рамках интерфейса, а сбором информации занимается pollerd. В ранних версиях системы сбором и обработкой данных занимались collectd и pollerd; первый собирал значения для графиков, а второй обрабатывал значения по запросу. Затем Collectd интегрировали в Pollerd и мороки с конфигурацией стало поменьше, хотя кое-где ещё можно наткнуться на оба понятия, что может вызвать определённую путаницу.

    Замыкают цепочку обработки данных политики (policies), которые определяют правила, применяющиеся к нодам, попадающим под определенные условия инициализации. На данный момент доступны три: MatchingIpInterfacePolicy, MatchingSnmpInterfacePolicy, NodeCategorySettingPolicy. Их названия говорят сами за себя и применение политик позволяет управлять механиками получения информации с искомых интерфейсов. В качестве примеров:
    • Применяя MatchingSnmpInterfacePolicy можно включать принудительный сбор информации с интерфейсов, имеющих в description определённое слово (например, [mon]).
    • С помощью NodeCategorySettingPolicy отправлять все свитчи D-Link в отдельную категорию.
    • С MatchingIpInterfacePolicy мы отключили сбор информации с 80 порта со всех коммутаторов, находящихся в одной подсети. График времени HTTP отклика в случае с коммутаторами не нужен — всегда есть ICMP ответ и данные с интерфейсов, в которых указано волшебное слово [mon]


    Заключение


    Стабильность. Единственный серьёзный глюк в системе был зарегистрирован во время «сбоя високосной секунды». И то, это пострадали системы баз данных, а не сама OpenNMS. В остальном, ни одного нарекания на стабильность за несколько лет работы.

    Сложность. Система сложная и комплексная. Ею легко пользоваться с точки зрения саппорта — всё красиво, наглядно и есть даже клиент для айфона [x]. Но процесс настройки (особенно в первый раз) может легко сжечь уйму нервных клеток. Документация покрывает почти все базовые аспекты системы, но стоит отметить неприятную особенность — многие статьи содержат информацию для предыдущих версий. Логически причины этого вполне понятны: поддерживать актуальность для такой комплексной системы — задача не из простых. Но нашу жизнь это совсем не упрощает.

    Гибкость. Разобравшись в системе, можно подключать свои события, трапы и модули для мониторинга. Если оборудование отдаёт какие-то параметры по SNMP или HTTP – его можно мониторить. Хранение данных в RRD позволяет гибко настраивать внешний вид графиков (которые по умолчанию не блещут красотой) в привычном RRDTool синтаксисе. Превышение пороговых значений обрабатывается в виде уведомлений и алармов. Внешние системы могут получать данные из OpenNMS по ReST или напрямую из базы.

    image

    Я не смогу ответить на вопросы «А почему не %systemname%?» и сознательно не стал на себя брать сравнительный анализ разных систем мониторинга — после продолжительной работы с одной системой и определенной привязки к её функционалу, непредвзятого обзора бы не получилось, а ресурсов такая работа отняла бы слишком много. На вопросы о самой системе отвечу с удовольствием, а если тема будет худо-бедно актуальной, то в продолжение этого ознакомительного материала можно будет написать примеры юзкейсов.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 23

      +3
      Также умеет принимать syslog и генерировать события по нему.
      Трапы конфигурируются легко и красиво.

      Подключали к ней много Luminato и прочего оборудования. Сказка просто.
        +1
        Перезапуск для обновления конфигурации — это, конечно, сильно.

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

          По умолчанию при обнаружении HTTP сервиса, OpenNMS начинает мониторить его состояние — доступность и время отклика. Плюс проверяет код ответа, в случае чего, генерируя эвент типа:
          image

          Проверять содержимое веб-страницы тоже возможно, для этого настраивается «HTTP коллектор» и/или «HTTP монитор». В случае несоответствия ответа ожидаемому (по коду или по контенту), генерируется событие nodeLostService. Если грубо, то для настройки такой проверки потребуется изменить два конфигурационных файла: отвечающий за provisioning (поиск и регистрацию сервисов на интерфейсах) и polling (регулярный опрос сервисов по заданным параметрам).
            0
            Судя по скрину он просто делает «GET /» и проверяет код ответа/время отклика на этот запрос? Проверяется ли наличие процессов и открытые порты без дополнительной настройки?

            В любом случае, пишите еще. Интересно будет сравнить с используемым в данный момент Zabbix'ом. У меня OpenNMS давно в списке на изучение, но пока не было острой необходимости.

            PS: Я какое-то время пытался подружиться с Nagios, но после нескольких месяцев правки текстовых конфигов забросил это занятие и перешел на Заббикс, прельстившись веб-интерфейсом. Теперь приходится делать и то, и другое %)
              0
              Этот скриншот просто под руку подвернулся — на одном из тестовых серверов я прибил php-fpm. Minor event показывает, что сервис, который раньше отвечал нормально, стал отдавать код 502 Bad gateway. Если бы там была, например, 404, он бы не ругнулся — у меня отрабатывают только 500 и выше, хотя в новых версиях по умолчанию валидный диапазон ответов уже 100-399.

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

              Если же требуется проверка именно содержимого страницы, то тут придётся повозиться чуть больше, но это всё равно возможно. И если со страницы пропадает какая-то критичная информация, то генерировать аларм. В официальной документации есть забавный пример мониторинга цены товара на eBay с рисованием графиков и срабатыванием аларма.

              Проверяется ли наличие процессов и открытые порты без дополнительной настройки?

              Если Вы имеете в виду, ищет ли OpenNMS иные сервисы кроме SNMP и HTTP, то да, ищет. Процесс discovery включает в себя довольно шустрый поиск открытых портов на предмет сервисов баз данных, почтовых систем, ftp, http, ad и т.д. и т.п. Причём поиск идёт в заданных диапазонах подсетей, отлавливая новые девайсы и проверяя уже существующие девайсы на появление новых сервисов.

              Я какое-то время пытался подружиться с Nagios, но после нескольких месяцев правки текстовых конфигов забросил это занятие и перешел на Заббикс, прельстившись веб-интерфейсом. Теперь приходится делать и то, и другое %)

              Я отдельно акцентировал внимание на том, что из веб-интерфейса сделать можно далеко не всё. Так что в случае с OpenNMS — это 300+ XML-конфигов. Все править не придётся, но пока непонятно где что лежит — выглядит пугающе :)
                0
                Если Вы имеете в виду, ищет ли OpenNMS иные сервисы кроме SNMP и HTTP, то да, ищет.

                Я имел в виду именно поведение http коллектора сразу после обнаружения сервиса.
                В дефолтной конфигурации он проверяет только код ответа и его наличие вообще. Проверка контента в его обязанности не входит. HTTP коллекторы по умолчанию ищут как HTTP, HTTP-8080 и HTTP-8000, но можно и добавить портов, буде на то насущная необходимость.


                А какое примерно соотношение типов устройств, которые вы мониторите? Сетевое оборудование, вин-серверы, линукс и т.п. Если это не секретная информация, конечно.
                  0
                  А какое примерно соотношение типов устройств, которые вы мониторите? Сетевое оборудование, вин-серверы, линукс и т.п. Если это не секретная информация, конечно.

                  Подавляющее большинство устройств — L2 и L3 коммутаторы. В location и description указаны адреса и координаты устройств, поэтому при проблеме на устройстве, саппорту сразу виден адрес. Некоторым портам ставятся специфические description'ы и на них распространяются свои правила мониторинга — сбор статистики или ассоциация с SLA. Намного меньше, но тоже есть — оптические усилители с IP интерфейсом, но у них адски топорная реализация SNMP и пока они только место занимают.

                  В процентном отношении головного оборудования на порядок меньше — несколько почтовых, DNS и веб серверов, базы данных, маленькая хостинговая площадка. Почти все сервера на линуксе и только пара специфических под Win. Эти ребята отдают подробную статистику обо всём — от количества запросов и очереди mailq до трафика на сетевых интерфейсах. Из узкой специфики — головные станции для DOCSIS (кабельные модемы) и мониторинг внутренней системы управления клиентами, чтобы предотвращать перерасход IPv4 адресов в клиентских подсетях. На критические точки настроены алармы с определёнными реакциями.

                  Пограничные и агрегирующие устройства — самые большие по количеству сервисов на них — уйма VLAN'ов и своих датчиков, но в отличие от тех же свитчей и головных кабельных станций они работают «из коробки», тогда как для части прочего оборудования приходится вручную добавлять SNMP OID'ы.
                    0
                    Вот у меня такое впечатление о системе и сложилось, что она больше подходит для мониторинга сетевого оборудования, отсюда NMS в названии. А когда в парке больше серверов, чем сетевого железа, для сбора базовых параметров типа cpu, ram etc. проще развернуть агенты системы мониторинга, чем snmp-сервер.

                    Будем ждать продолжения.
          0
          Зачем ему постгре, если графики рисует с помощью rrdtool? если метаданные, то какие бд может использовать вместо pg?
            0
            В базе данных OpenNMS хранит ноды, интерфейсы, категории и, конечно же, события для всех наблюдаемых систем. OpenNMS на данный момент жёстко привязана к использованию PostgreSQL.
            0
            Любопытно почитать дальше. У меня не энтерпрайз-сеть, а куча серваков и сервисов на обслугу одного приложения. И не прижился zabbix, nagios и прочие. Сейчас, в принципе, хватает munin+monit (куча самописных плагинов для munin), но есть желание на что-то более активное перейти.

              0
              Набор юзкейсов у меня в качестве плана для следующего материала есть, но я не хотел перегружать первый материал и засомневался, имеет ли смысл описывать интеграцию с Active Directory и чтение специфических данных с головных станций DOCSIS (омг, оно ещё живое). Пожалуй, однозначно пригодится разбиение по категориям, тонкостям provisioning'а и разные подходы к чтению, например, статистики nginx, mysql и postfix. Как на последней картинке с графиками в статье. Если есть какие-то пожелания — с удовольствием выслушаю.
                0
                Это все интересно, но достаточно стандартно. Мне интересна экзотика (в какой-то мере:), например:
                — выполнение скриптов на хостах, как по event, так и в рамках опроса. (как я понимаю тут надо смотреть в сторону NSClient)
                — Обработка логов, метрики из логов
                  0
                  Этим требованиям, мне кажется, не соответствует ни одна из более-менее популярных систем мониторинга. К любой придется приделывать те или иные костыли.

                  С обработкой логов и метриками из логов можно попробовать справиться средствами logstash+kibana. Хотя, эта связка больше подходит для сбора статистики, чем для мониторинга. Но даже стандартными плагинами можно сделать оповещения о событиях.
                    0
                    logstah+kibana достаточно нетривиальная обвязка, с ней я уже заморочился. Любая система не будет комплексной и удобной, везде нужны костыли… к сожалению. Особенно если для аналитики привязывать метрики сервера с БД, к обращениям в кеш и логу app-сервера (есть у меня в задачах и такая экзотика).

                    Когда логов гигабайты и гигабайты, когда на них завязан еще и биллинг, тут никакая реляционная СУБД не справится (я в холивар вступать не буду, ибо когда данных дохера, шардинги, мастер-слейвы-мастеры и прочие таблицы есть зло, костыли и кошмар).
                0
                Если у вас не прижился Zabbix и Nagios у вас ничего не приживецца. Вам значит просто не нужен мониторинг. Для выполнение скриптов и прочей автоматизации вам нужны другие вещи.
                  0
                  Я уже писал, меня сейчас устраивает monit+munin. Что-то другое интересно попробовать. Но момент в том, то обычные энтерпрайз системы у нас не приживутся скорее всего, и в первую очередь мне нужна нормальная система обработки логов и статистики по метрикам. Тут я уже смотрю в сторону hadoop+d3js. Но если будет что-то инетересное для промежуточного этапа, почемуж не глянуть.
                0
                Отличный обзор!

                Но минимальное требование в 2 Ghz, в совокупностью с Java c Perl очень ограничивают применение на VPS (с OpenVMZ/KVM) c ограниченными системными ресурсами.
                  +1
                  На 512 запускается и работает замечательно. Даже на 800мгц железке. Около 50 нод держала спокойно.
                    0
                    Тогда, ОК. Просто в тексте стоит:
                    2 Gb RAM (это самый-самый минимум)
                      +1
                      Дополнил информацию о системных требованиях официальными (зря не указал сразу). Но запуск на минимальных конфигурациях, скорее всего, не доставит удовольствия и потребует тюнинга параметра START_TIMEOUT, который я описал в материале. Опять же, возможно, я сужу со своей колокольни, но мне кажется нецелесообразным развёртывать OpenNMS для мониторинга небольших систем.
                  0
                  Что-то не получается.
                  В окне «Configure SNMP by IP»
                  поле First IP Address: указываю ip-адрес
                  Community String: stat
                  Получаю сообщение: OpenNMS does not need to be restarted.

                  snmpwalk -v 2c -c stat localhost вываливает кучу данных.

                  В events и nodes list пустота.
                    0
                    Сам спросил, сам отвечаю. Новую ноду удалось добавить через «Add Node» в главном меню.

                  Only users with full accounts can post comments. Log in, please.