Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
Также умеет принимать syslog и генерировать события по нему.
Трапы конфигурируются легко и красиво.
Подключали к ней много Luminato и прочего оборудования. Сказка просто.
Трапы конфигурируются легко и красиво.
Подключали к ней много Luminato и прочего оборудования. Сказка просто.
Перезапуск для обновления конфигурации — это, конечно, сильно.
Как настроить, например, проверку отдачи веб-сервером правильного контента? Какие действия для этого требуются?
Как настроить, например, проверку отдачи веб-сервером правильного контента? Какие действия для этого требуются?
К сожалению, да, перезапуск нужен и он довольно ресурсоёмкий. Но главным камнем преткновения чаще всего становится сам процесс конфигурации. Хотя динамика развития в этом направлении положительная.
По умолчанию при обнаружении HTTP сервиса, OpenNMS начинает мониторить его состояние — доступность и время отклика. Плюс проверяет код ответа, в случае чего, генерируя эвент типа:
Проверять содержимое веб-страницы тоже возможно, для этого настраивается «HTTP коллектор» и/или «HTTP монитор». В случае несоответствия ответа ожидаемому (по коду или по контенту), генерируется событие nodeLostService. Если грубо, то для настройки такой проверки потребуется изменить два конфигурационных файла: отвечающий за provisioning (поиск и регистрацию сервисов на интерфейсах) и polling (регулярный опрос сервисов по заданным параметрам).
По умолчанию при обнаружении HTTP сервиса, OpenNMS начинает мониторить его состояние — доступность и время отклика. Плюс проверяет код ответа, в случае чего, генерируя эвент типа:
Проверять содержимое веб-страницы тоже возможно, для этого настраивается «HTTP коллектор» и/или «HTTP монитор». В случае несоответствия ответа ожидаемому (по коду или по контенту), генерируется событие nodeLostService. Если грубо, то для настройки такой проверки потребуется изменить два конфигурационных файла: отвечающий за provisioning (поиск и регистрацию сервисов на интерфейсах) и polling (регулярный опрос сервисов по заданным параметрам).
Судя по скрину он просто делает «GET /» и проверяет код ответа/время отклика на этот запрос? Проверяется ли наличие процессов и открытые порты без дополнительной настройки?
В любом случае, пишите еще. Интересно будет сравнить с используемым в данный момент Zabbix'ом. У меня OpenNMS давно в списке на изучение, но пока не было острой необходимости.
PS: Я какое-то время пытался подружиться с Nagios, но после нескольких месяцев правки текстовых конфигов забросил это занятие и перешел на Заббикс, прельстившись веб-интерфейсом. Теперь приходится делать и то, и другое %)
В любом случае, пишите еще. Интересно будет сравнить с используемым в данный момент Zabbix'ом. У меня OpenNMS давно в списке на изучение, но пока не было острой необходимости.
PS: Я какое-то время пытался подружиться с Nagios, но после нескольких месяцев правки текстовых конфигов забросил это занятие и перешел на Заббикс, прельстившись веб-интерфейсом. Теперь приходится делать и то, и другое %)
Этот скриншот просто под руку подвернулся — на одном из тестовых серверов я прибил 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 и т.д. и т.п. Причём поиск идёт в заданных диапазонах подсетей, отлавливая новые девайсы и проверяя уже существующие девайсы на появление новых сервисов.
Я отдельно акцентировал внимание на том, что из веб-интерфейса сделать можно далеко не всё. Так что в случае с OpenNMS — это 300+ XML-конфигов. Все править не придётся, но пока непонятно где что лежит — выглядит пугающе :)
В дефолтной конфигурации он проверяет только код ответа и его наличие вообще. Проверка контента в его обязанности не входит. HTTP коллекторы по умолчанию ищут как HTTP, HTTP-8080 и HTTP-8000, но можно и добавить портов, буде на то насущная необходимость.
Если же требуется проверка именно содержимого страницы, то тут придётся повозиться чуть больше, но это всё равно возможно. И если со страницы пропадает какая-то критичная информация, то генерировать аларм. В официальной документации есть забавный пример мониторинга цены товара на eBay с рисованием графиков и срабатыванием аларма.
Проверяется ли наличие процессов и открытые порты без дополнительной настройки?
Если Вы имеете в виду, ищет ли OpenNMS иные сервисы кроме SNMP и HTTP, то да, ищет. Процесс discovery включает в себя довольно шустрый поиск открытых портов на предмет сервисов баз данных, почтовых систем, ftp, http, ad и т.д. и т.п. Причём поиск идёт в заданных диапазонах подсетей, отлавливая новые девайсы и проверяя уже существующие девайсы на появление новых сервисов.
Я какое-то время пытался подружиться с Nagios, но после нескольких месяцев правки текстовых конфигов забросил это занятие и перешел на Заббикс, прельстившись веб-интерфейсом. Теперь приходится делать и то, и другое %)
Я отдельно акцентировал внимание на том, что из веб-интерфейса сделать можно далеко не всё. Так что в случае с OpenNMS — это 300+ XML-конфигов. Все править не придётся, но пока непонятно где что лежит — выглядит пугающе :)
Если Вы имеете в виду, ищет ли OpenNMS иные сервисы кроме SNMP и HTTP, то да, ищет.
Я имел в виду именно поведение http коллектора сразу после обнаружения сервиса.
В дефолтной конфигурации он проверяет только код ответа и его наличие вообще. Проверка контента в его обязанности не входит. HTTP коллекторы по умолчанию ищут как HTTP, HTTP-8080 и HTTP-8000, но можно и добавить портов, буде на то насущная необходимость.
А какое примерно соотношение типов устройств, которые вы мониторите? Сетевое оборудование, вин-серверы, линукс и т.п. Если это не секретная информация, конечно.
А какое примерно соотношение типов устройств, которые вы мониторите? Сетевое оборудование, вин-серверы, линукс и т.п. Если это не секретная информация, конечно.
Подавляющее большинство устройств — L2 и L3 коммутаторы. В location и description указаны адреса и координаты устройств, поэтому при проблеме на устройстве, саппорту сразу виден адрес. Некоторым портам ставятся специфические description'ы и на них распространяются свои правила мониторинга — сбор статистики или ассоциация с SLA. Намного меньше, но тоже есть — оптические усилители с IP интерфейсом, но у них адски топорная реализация SNMP и пока они только место занимают.
В процентном отношении головного оборудования на порядок меньше — несколько почтовых, DNS и веб серверов, базы данных, маленькая хостинговая площадка. Почти все сервера на линуксе и только пара специфических под Win. Эти ребята отдают подробную статистику обо всём — от количества запросов и очереди mailq до трафика на сетевых интерфейсах. Из узкой специфики — головные станции для DOCSIS (кабельные модемы) и мониторинг внутренней системы управления клиентами, чтобы предотвращать перерасход IPv4 адресов в клиентских подсетях. На критические точки настроены алармы с определёнными реакциями.
Пограничные и агрегирующие устройства — самые большие по количеству сервисов на них — уйма VLAN'ов и своих датчиков, но в отличие от тех же свитчей и головных кабельных станций они работают «из коробки», тогда как для части прочего оборудования приходится вручную добавлять SNMP OID'ы.
Вот у меня такое впечатление о системе и сложилось, что она больше подходит для мониторинга сетевого оборудования, отсюда NMS в названии. А когда в парке больше серверов, чем сетевого железа, для сбора базовых параметров типа cpu, ram etc. проще развернуть агенты системы мониторинга, чем snmp-сервер.
Будем ждать продолжения.
Будем ждать продолжения.
Любопытно почитать дальше. У меня не энтерпрайз-сеть, а куча серваков и сервисов на обслугу одного приложения. И не прижился zabbix, nagios и прочие. Сейчас, в принципе, хватает munin+monit (куча самописных плагинов для munin), но есть желание на что-то более активное перейти.
Набор юзкейсов у меня в качестве плана для следующего материала есть, но я не хотел перегружать первый материал и засомневался, имеет ли смысл описывать интеграцию с Active Directory и чтение специфических данных с головных станций DOCSIS (омг, оно ещё живое). Пожалуй, однозначно пригодится разбиение по категориям, тонкостям provisioning'а и разные подходы к чтению, например, статистики nginx, mysql и postfix. Как на последней картинке с графиками в статье. Если есть какие-то пожелания — с удовольствием выслушаю.
Это все интересно, но достаточно стандартно. Мне интересна экзотика (в какой-то мере:), например:
— выполнение скриптов на хостах, как по event, так и в рамках опроса. (как я понимаю тут надо смотреть в сторону NSClient)
— Обработка логов, метрики из логов
— выполнение скриптов на хостах, как по event, так и в рамках опроса. (как я понимаю тут надо смотреть в сторону NSClient)
— Обработка логов, метрики из логов
Этим требованиям, мне кажется, не соответствует ни одна из более-менее популярных систем мониторинга. К любой придется приделывать те или иные костыли.
С обработкой логов и метриками из логов можно попробовать справиться средствами logstash+kibana. Хотя, эта связка больше подходит для сбора статистики, чем для мониторинга. Но даже стандартными плагинами можно сделать оповещения о событиях.
С обработкой логов и метриками из логов можно попробовать справиться средствами logstash+kibana. Хотя, эта связка больше подходит для сбора статистики, чем для мониторинга. Но даже стандартными плагинами можно сделать оповещения о событиях.
logstah+kibana достаточно нетривиальная обвязка, с ней я уже заморочился. Любая система не будет комплексной и удобной, везде нужны костыли… к сожалению. Особенно если для аналитики привязывать метрики сервера с БД, к обращениям в кеш и логу app-сервера (есть у меня в задачах и такая экзотика).
Когда логов гигабайты и гигабайты, когда на них завязан еще и биллинг, тут никакая реляционная СУБД не справится (я в холивар вступать не буду, ибо когда данных дохера, шардинги, мастер-слейвы-мастеры и прочие таблицы есть зло, костыли и кошмар).
Когда логов гигабайты и гигабайты, когда на них завязан еще и биллинг, тут никакая реляционная СУБД не справится (я в холивар вступать не буду, ибо когда данных дохера, шардинги, мастер-слейвы-мастеры и прочие таблицы есть зло, костыли и кошмар).
Если у вас не прижился Zabbix и Nagios у вас ничего не приживецца. Вам значит просто не нужен мониторинг. Для выполнение скриптов и прочей автоматизации вам нужны другие вещи.
Я уже писал, меня сейчас устраивает monit+munin. Что-то другое интересно попробовать. Но момент в том, то обычные энтерпрайз системы у нас не приживутся скорее всего, и в первую очередь мне нужна нормальная система обработки логов и статистики по метрикам. Тут я уже смотрю в сторону hadoop+d3js. Но если будет что-то инетересное для промежуточного этапа, почемуж не глянуть.
Отличный обзор!
Но минимальное требование в 2 Ghz, в совокупностью с Java c Perl очень ограничивают применение на VPS (с OpenVMZ/KVM) c ограниченными системными ресурсами.
Но минимальное требование в 2 Ghz, в совокупностью с Java c Perl очень ограничивают применение на VPS (с OpenVMZ/KVM) c ограниченными системными ресурсами.
На 512 запускается и работает замечательно. Даже на 800мгц железке. Около 50 нод держала спокойно.
Тогда, ОК. Просто в тексте стоит:
2 Gb RAM (это самый-самый минимум)
Дополнил информацию о системных требованиях официальными (зря не указал сразу). Но запуск на минимальных конфигурациях, скорее всего, не доставит удовольствия и потребует тюнинга параметра
START_TIMEOUT, который я описал в материале. Опять же, возможно, я сужу со своей колокольни, но мне кажется нецелесообразным развёртывать OpenNMS для мониторинга небольших систем.
Что-то не получается.
В окне «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 пустота.
В окне «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 пустота.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Система мониторинга OpenNMS