Мониторинг активного сетевого оборудования

ShareIT – поделись знаниями!

Полезно

Узнать IP – адрес компьютера в интернете

Онлайн генератор устойчивых паролей

Онлайн калькулятор подсетей

Калькулятор инсталляции IP – АТС Asterisk

Руководство администратора FreePBX на русском языке

Руководство администратора Cisco UCM/CME на русском языке

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Популярное и похожее

Пошаговый ввод в домен Windows 10

Погружение в Iptables – теория и настройка

Как включить RDP на Windows

Управляем лодкой: Kubernetes

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

Активное сетевое оборудование должно обеспечивать долгосрочное и бесперебойное функционирование корпоративной сети.

3 минуты чтения

Активное сетевое оборудование, должно обеспечивать долгосрочное и бесперебойное функционирование корпоративной сети. Своевременное выявление и устранение неисправностей является залогом успешной и эффективной работы компании. Именно поэтому очень важно уделить особое внимание системе мониторинга, которая бы отслеживала состояние активного оборудования и уведомляла об отклонении от нормальных показателей системного администратора по SMS, e-mail или другим средствам оповещения.

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

1) Доступность хоста

Путем периодической отправки запросов ICMP Echo-Request на адрес сетевого устройства

2) Доступность веб-сервера

Путем отправки HTTP запроса на получение страницы

3) Доступность почтовых сервисов

Путем периодической отправки диагностических SMTP сообщений

Кроме того, можно производить замер времени отклика данных сервисов.

Периодические проверки такого рода позволяют быстро определить на каком уровне возникла проблема и незамедлительно приступить к её устранению.

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

На приведенном выше рисунке показан простейший пример реализации системы мониторинга, контролирующей всего четыре устройства. В реальных же условиях парк активного оборудования может иметь куда больше узлов. Для осуществления грамотного мониторинга проводят объединение разных типов узлов в группы, например группа веб-серверов или группа маршрутизаторов. Такого рода разделение помогает систематизировать статистическую информацию и облегчает процесс наблюдения.

Большинство систем мониторинга позволяют автоматизировать проверку устройств по SNMP и осуществлять диагностику с помощью различных плагинов (в том числе созданных вручную).

Протокол SNMP (Simple Network Management Protocol) – был создан специально для нужд мониторинга сетевого оборудования. Все активные устройства L2 и L3 содержат так называемую Базу информации управления MIB (Management Information Base), в которой находятся основные параметры состояния оборудования. Например, загрузка CPU, статус интерфейсов, объем свободного места и др. Каждой такой записи соответствует уникальный идентификатор OID(Oject IDentifier). Имея нужный идентификатор, можно получить информацию об интересующем параметре по протоколу SNMP. Современные системы мониторинга позволяют автоматизировать данный процесс. Система, по протоколу SNMP, подключается к устройству, опрашивает его по интересующему OID, получает значение параметра и сравнивает его с заданным. Если обнаруживается несоответствие двух данных значений, то системы мониторинга реагирует и запускает процесс оповещения.

Перед непосредственным внедрением системы мониторинга, необходимо провести обследование ЛВС, результатом которого должен стать перечень наблюдаемого оборудования, параметров и утвержденный алгоритм эскалации событий мониторинга. На основе анализа сетевой инфраструктуры заказчика формируются первые решения определяющие архитектуру будущей системы мониторинга.

На следующем этапе осуществляется составление спецификаций и пакета проектной документации, с учетом пожеланий заказчика.

Читайте также:  Лучшие программы для перевода текста

Далее обычно следует внедрение разработанного решения на отдельном сегменте сети с ограниченным числом наблюдаемых узлов, с целью тестирования и отладки функционала предложенного решения.

Заключительным этапом является масштабирование системы мониторинга, то есть расширение объема наблюдаемой ИТ-инфраструктуры до необходимого заказчику.

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

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас 🙁 Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации 🙂 Просто оставьте свои данные в форме ниже.

Для небольшой компании (макс 50-70 наблюдаемых машин) необходимо выбрать систему мониторинга сети и ПО. Мониторить в первую очередь будем именно критически важное (24х7) ПО — логи, производительность и доступность.

Вопрос стоит в выборе. Есть большой соблазн использовать Zabbix, но все же хочется объективно оценить все плюсы и минусы каждой системы.

Кандидаты:
Cacti
Nagios
OpenNMS
AggreGate Network Manager
Zenoss
Pandora FMS
PRTG Network Monitor
NetDecision
Zabbix
Ganglia

Рад буду услышать отзывы о реальном (рекламные брошюры все уже прочитали) использовании этих систем. Интересуют такие качества как:
— простота установки и поддержки;
— расширяемость;
— производительность;
— надежность;
— визуализация данных;
— распределенный мониторинг;
— эскалация инцидентов;
— широкий набор оповещений;
— цена;

Также интересует, подходят ли для подобных целей «взрослое» ПО по управлению информационными системами, такое как IBM Tivoli или HP OpenView?

Буду рад слышать ваши ответы и предложения.

  • Вопрос задан более трёх лет назад
  • 39433 просмотра

Использовал nagios для мониторинга примерно 300+ машин
1) простота установки и поддержки — есть в пакетах во многих дистрибутивах, настраивается достаточно просто
2) расширяемость — много плагинов, в том числа для сетевого оборудования, можно писать свои, достаточно будет написать шелл-скрипт, который пишет данные в определенном формате.
3) производительность — для 300+ машин серверу хватало 256 Мб, при этом там еще работал OCS Inventory
4) надежность — как кирпич, очень надежно.
5) визуализация данных — присутствует, красота на любителя.
6) распределенный мониторинг — не совсем понял, что имеется ввиду. Если это то, о чем я подумал, то существует NRPE, который выполняет удаленно плагины на хосте и отдает ответ плагина серверу мониторинга. Если имеется ввиду использование нескольких серверов мониторинга в связке, то не уверен, что на предприятии в 50-70 машин это нужно.
7) эскалация инцидентов — не готов сказать что-то конкретное, не представляю, какая у вас на предприятии с этим ситуация, какова иерархия управления инцидентами. Исходя из размера компании, один технический специалист и пара-тройка человек руководства.
8) широкий набор оповещений — можно разделять пользователей на группы, указывать, на какие группы высылать оповещения, стандартно используется три состояния сервиса или параметра — OK, WARNING, CRITICAL. Есть еще статус UNKNOWN, возникающий в случае некорректной работы плагина.
9) цена — бесплатно
Плюс есть возможность выполнения скриптов удаленно в случае возникновения критической ситуации. Например, передернуть сервис.
Кроме того, можно использовать координатную отрисовку на карте. Задаешь координаты для всех машин и на схеме наблюдаешь где это находится. Правда, придется немного озаботиться с заданием координат.

Cacti больше подходит для мониторинга по SNMP, соответственно, удобнее им мониторить сетевое оборудование, я лично для этого использовал плагины для nagios’а.

Во время написания статьи пришел к выводу, что объяснить всю техническую часть по данной теме в одном посте практически невозможно, а может и никому не надо. Поэтому решил сделать данный пост обзорным над моей работой. Цель поста — показать, как не используя дополнительное финансирование компании и выпросив пару виртуальных серверов можно построить эффективную среду мониторинга активного оборудования большой сети в крупной компании.

Читайте также:  Микроволновая печь вред для здоровья мнение

Если вас интересует тема мониторинга сети или есть желание сравнить мою работу с имеющейся у вас, приглашаю под кат.

В маленькой «домашней» сети задачу мониторинга сети можно решить, используя любую из имеющихся свободных платформ для мониторинга. Однако, когда дело касается большого предприятия с больших количеством узлов, все не так прозрачно. И основная проблема — это нехватка физических ресурсов и отсутствие адаптированной под ваши требования системы. Чуть лучше ситуация обстоит с платными продуктами, но платные системы очень редко входят в расходы бизнеса на какой-то там мониторинг.

Система управления

Скелетом всего мониторинга будет система управления, позволяющая мышкой вносить изменение, удалять или добавлять новые узлы или связи.

При разработке всей системы в целом, учитывались следующие требования:

  • Минимальные настройка/перенастройка на активном оборудовании;
  • Обработка большого объема трафика по netflow;
  • Возможность детально исследовать какую-либо сетевую активность;
  • Оперативное обновление о происходящих инцидентах. Будь то падение канала или большая загрузка канала;
  • Возможность дорабатывать модули или отчеты для все возможных выборок;
  • Задействовать минимальное количество инфраструктуры;
  • Как можно меньше писать функционал самостоятельно.

Инфраструктура пробовалась разная, до тех пор, пока не была достигнута текущая конфигурация. Все испробованные варианты я описывать не буду, чтобы не растягивать пост.

Итог таков: Два виртуальных сервера под управлением CentOS 6.
Один для системы управления и отображения. 2 процессора, 4ГБ ОЗУ, 250ГБ диск.
Второй выполняющий функции коллектора netflow. 2 процессора, 4ГБ ОЗУ 150ГБ диск.
Конфигурация серверов вполне стандартная, веб сервер apache с php + mysql.

Кактус

Для системы управления был выбран Кактус. Чем привлек кактус:

  • Отсутствием сложного кода в WEB отображении (никакого flash, aciveX и прочих активных компонентов, что дает преимущество использования на мобильных устройствах);
  • Простая и понятная структура БД, к который можно легко привязать свой функционал;
  • Много плагинов именно для мониторинга активного оборудования;
  • Встроенная поддержка SNMP;
  • RRDTool в качестве источника для графиков (привет заббиксу);
  • отсутствует клиентская часть.

Установка Кактуса не представляет из себя никакой сложности. По этой теме очень много информации в интернете, ну и самой лучшей, конечно, является официальная документация.

Настройка так же не требует глубоких ИТ знаний. На странице Devices добавляются устройства, указывается тип SNMP и авторизация. Привязываются стандартные шаблоны.

Плагины к кактусу для работы с активным оборудованием

NetFlow

Syslog and Traps

Второй создает автономную базу данных с очень прозрачной структурой, к которой я привязал функционал, написанный самостоятельно, но об этом чуть позже.

Network Maps

Настройка NetFlow

В качестве нашего программного коллектора будет использоваться flow-tools. Данное ПО умеет не только захватывать трафик, но и анализировать его. Так же на основе этого пакета написано не мало GUI для отображения собранной информации в человеческом виде.

Управлять компонентом flow-capture я собирался с плагина кактуса flowview, поэтому после установки flow-tools, необходимо скопировать скрипт запуска сервиса с папки плагина в наш init.d на сервере.
Из-за чего вся эта возня с системой управления? Ведь проще поправить конфиг вручную и забить? Но не тут то было. Количество устройств порядка 500 штук с весьма большим объемом трафика. Если сложить все flow в одну папку, извлечение данных по одному часу трафика займет более 2-х часов, это неприемлемо.

Решено было разделить потоки от каждого устройства в отдельную папку, чтобы выборка происходила в определенной папке с нужным трафиком. Средствами flow-capture это делается путем разнесения потоков от устройств по портам. А это значит, каждое устройство нужно настроить с уникальным портом отдачи flow?

Читайте также:  Лучший тонометр на запястье отзывы врачей

Это так же неприемлемо, поэтому на помощь в решении данной проблемы приходит простая маленькая программка samplicator. Суть работы такова: принимает входящие UDP пакеты, сортирует их по адресу источника и транслирует в выбранный порт. А это значит, что настройку оборудования мы делаем типовую на один порт, а уже на самом сервере распределяем потоки по портам.

Синтаксис конфига: Source/Mask:Destination1/Port [Destination2/Port] и пример:

Flow собрали, с ужасом смотрим скорость заполнения наших дисков. Как теперь все это просмотреть?
Есть много способов, можно генерировать отчеты вручную через тот же пакет flow-tools. Но это могут сделать не все пользователи системы, да и тому, кто может, надо попотеть, чтобы написать человеческий отчет.

Я обратился к еще одному замечательному проекту FlowViewer.

Когда я его откопал и начал использовать, была версия 3.3 или что-то вроде того, 2006 года. Пока я разобрался с 3-й версии, проект неожиданно ожил и начал развиваться, 4-я версия была просто гениальна, по сравнению с 3-й. На момент написания статьи текущая версия 4.4 (у меня используется 4.1).

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

SNMP Traps

Потоки с flow — это очень хорошо и заманчиво, но использовать их для оповещения о проблемах невозможно. Только для анализа уже после устранения проблемы.

Ну и самый доступный способ оповещения — это SNMP трапы. Получать SNMP трапы от 500 устройств одним списком не очень приятное занятие, потеряешь в мусоре важную на данный момент информацию. Ясно, что надо делать какой-то фильтр. Тут готового решения, удовлетворяющего мои требования найдено не было. Но не беда, вспомнив тягу к программированию в институте решил написать анализатор трапов сам.

Технология получения фильтрованного списка такая: при получении трапа сервер мониторинга принимает (snmptrapd) его, анализирует (snmptt) в соответствии с загруженными MIB спецификациями и сразу кладет в базу данных.

mysql_dbi_enable = 1
mysql_dbi_host = localhost
mysql_dbi_port = 3306
mysql_dbi_database = cacti
mysql_dbi_table = plugin_camm_snmptt
mysql_dbi_table_unknown = plugin_camm_snmptt_unk
mysql_dbi_table_statistics = plugin_camm_snmptt_stat
mysql_dbi_username = cacti
mysql_dbi_password = cacti
mysql_ping_on_insert = 1
mysql_ping_interval = 300

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

Привлекательным выглядит вариант забирать с базы события, связывать их с имеющейся базой для информативности. Вооружившись блокнотом, начал придумывать логику. С ней особых проблем не возникло, проблемы возникли при выборки данных из БД. Которая начала занимать от 30 секунд. Ни о какой оперативности тут речь не шала. Теория оптимизации баз данных, оптимизация запросов, индексы, планы, умные советы моей спутницы(специалиста по сверхбольшим БД) сделали своё дело.

Основная мысль фильтровать Up/Down трапы, в описании которых встречаются имена интерфейсов (Eth, Serial, Gi, E), по идентификаторам и источнику ищем данные в таблице с SNMP. На выходе получаем красивую строку, когда, где и куда упал линк.

Все данные с базы оформляются в читабельным вид в виде html страничек.

Выборки с БД получая разные условия, формируют разные таблички отчетов.

Благодарю читателя, осилившего все моё сумбурное повествование. Отчасти связанное с тем, что система уже год с лишним работает без меня. Много забылось, что-то потеряло смысл. Но работает мониторинг до сих пор, собирает данные и обеспечивает выборки уже без моей поддержки.

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

Читайте также:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock detector