Анализ возможностей системы мониторинга ZABBIX для оператора связи

АННОТАЦИЯ

Работа содержит 76 страниц, 13 рисунков, 3 таблицы. Было использовано 22 источники.

Цель работы: провести анализ да возможности системы мониторинга Zabbix, да увидеть как за помощью Zabbix мониторинга проводить тестирование сети с улучшенными протоколами безопасности да составление аналитики на выход с лада оборудование сети.

Объект исследования: система мониторинга и безопасности Zabbix, какую роль играют тестирование телекоммуникационной сети систем мониторинга Zabbix.

Предмет исследование: анализ возможностей системы мониторинга Zabbix, решение проблемы с безопасностью да оборудованием телекоммуникационной сети. Также исследуются некоторые широко используемые методы мониторинга Zabbix серверов да собираю данных для измерение производительности в телекоммуникационных сетях.

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

ZABBIX, LINUX, ПРОИЗВОДИТЕЛЬНОСТЬ, APACHE, MYSQL, PHP, SNMP

СОДЕРЖАНИЕ

ПЕРЕЧЕНЬ СОКРАЩЕНИЙ 8

ВВЕДЕНИЕ 9

ВЫВОДЫ 73

ПЕРЕЧЕНЬ Ссылок 75

ПЕРЕЧЕНЬ СОКРАЩЕНИЙ

LLD - низкоуровневое обнаружение

API – прикладной программный интерфейс IPS - единица измерения скорости

IDS – системы управления базами данных WLAN – беспроводная локальная сеть LAN - локальная сеть

VPN - виртуальная частная сеть

WAN – телекоммуникационная сеть, охватывающая обширную территорию OSI - базовая модель открытых систем

Network Management – системы управления сетью System Management - средства управления системой

Embedded systems – встроенные системы диагностики и управления Protocol analyzers - анализаторы протоколов

IANA (Internet Assigned Numbers Authority) – распределения номеров в Интернете User-based Security Model - модель безопасности на основе пользователей

DM - распределенный мониторинг на основе узлов

ВВЕДЕНИЕ

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

Мониторинг да измерение сети становятся все более и более важными в современной сложной сети. В прошлом администраторы могли контролировать только несколько сетевых устройств или меньше сотни компьютеров. Пропускная способность сети может составлять всего 10 или 100 Мбит/с; однако теперь администраторам приходится иметь дело не только с беспроводной сетью (более 10 Гбит), но и с беспроводными сетями. Им нужны более сложные инструменты мониторинга да анализа сетевого трафика, чтобы поддерживать стабильность и доступность сетевой системы, например, для исправления ошибок вовремя возникают проблемы с сетью или чтобы избежать сбоев в сети, чтобы обеспечить надежность сети и принять правильные решение при планировании сети.

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

на этапе мониторинга выполняется более простая процедура - процедура сбора первичных данных о работу сети: статистики о количество

циркулирующих в сети кадров и пакетов разных протоколов, состояние портов концентраторов, коммутаторов и маршрутизаторов и т.е. п.

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

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

Zabbix - отличный продукт для администраторов больших программно- аппаратных комплексов Он настолько хорош, что может использоваться не не только крупным бизнесом, но и средне-малым бизнесом. В общем, у меня есть небольшой опыт работы с Zabbix'ом и я смело могу рекомендовать его к использование.

Zabbix удовлетворяет требования надежного инструмента мониторинга телекоммуникационной сети примерно на 90 процентов. Он осуществляет как мониторинг на основе как агентов, так и без агентов. Можно найти такие функции, как обнаружение низкого уровня, автоматическое обнаружение да логическое группировка.

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

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

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

Сервер - ядро, что сохраняет в себе все данные системы, включая статистические, оперативные и конфигурационные. Дистанционно управляет сетевыми сервисами, уведомляет администратора о существующих проблемах с оборудованием, что находятся под наблюдением.

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

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

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

В данном разделе определим какой есть мониторинг телекоммуникационной сети. Объясните, какие изменения вводятся с мониторингом сетей для ИТ-структуры. Кроме того, я буду конкретизировать разные типы мониторинга.

Несколько десятилетий назад информация о состоянии сети и эффективности инфраструктура была только собрана в одном месте. Роль "интеллектуального анализатора" лежала только на системных администраторам. Для того, чтобы иметь полный обзор системы, администратор должен был быть целым указателем, то есть ему приходилось контролировать все одновременно. Это занимало слишком много времени, чтобы узнать определенные проблемы и методы. Для того чтоб упростить работу администраторов и снизить объем времени на обработку данных начали вводить в сеть системы мониторинга

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

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

Существует общее непонимание, что мониторинг сети также дает аудит. безопасности и предотвращает несанкционированный доступ к сети. Для такого рода мониторинга безопасности используются системы профилактики вторжение (IPS) или системы обнаружение вторжений (IDS). Сеть мониторинга используется только для мониторинга использование сети да ее надежности.

Сетевой мониторинг поддерживает широкий спектр устройств, таких как серверы, маршрутизаторы, выключатели и даже конечные устройства. Кроме того, он может быть использован в любых сетях, таких как WLAN, LAN, VPN да даже WAN.

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

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

оборудование. Как следствие, это повышает качество обслуживание в телекоммуникационные сети.

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

В основном используются два типы мониторинга веб-сайта: внутренние да внешние. Внутренний мониторинг несет ответственность за выявление вопросов, связанных с внутренней структурой или для разработки определенных приложений. Наружный мониторинг несет ответственность за конечный мониторинг. Мониторинг веб-сайта несет ответственность за интернет- протоколы, такие как: HTTP, HTTPS, FTP, SNMP, STPM, SSH, TELNET, POP3, DNS, SSL, TCP, UDP.

Мониторинг с точки зрения конечного пользователя - это когда бот периодически эмитирует определенные действия пользователя. Есть он запускает специальный скрипт, как будто пользователь запускает меню и даже выполняет щелчки. Если бот нет может выполнять некоторые действия, конечный пользователь нет может это сделать. Одной из последних появившихся функций - это мониторинг на уровне кода. Такой модули могут определить задержку системных звонков, истоки памяти да задержки при реализации запросов SQL.

Важной частью мониторинга маршрутная аналитика. Маршрутно аналитика это набор инструментов, приложений и алгоритмов, контролирующих маршрутизацию внутри сети. Он работает на сетевом шаре.

Маршрутизация Analytics включает следующие системные мониторы. OSPF, IS-IS, EIGRP да протоколы маршрутизации BGP. Как результат, эта маршрутизация получает каждое обновленное сообщение как все другие

маршрутизаторы. Кроме того, он использует алгоритм Dijkstra, какой вычисляет полную карту топологии сети, включая все пути.

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

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

Контроль работы сети обычно делят на этапы мониторинга да анализа

На первом этапе выполняется более простая процедура - сбор первичных данных о работе: статистика циркулирующих в сети кадров и пакетов, состояние портов на оборудование, тому подобное.

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

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

Согласно рекомендациям ISO выделят следующие функции средств управление сетью:

Управление конфигурацией сети – конфигурация компонентов сети, например, настройка сетевых адрес да идентификаторов, управление параметрами сетевых ОС, поддержку топологии сети да именование объектов.

Обработка ошибок - обнаружение и дальнейшее устранение последствий сбоя сети.

Анализ производительности – на основе накопленной статистической информации разрешает оценивать время ответы системы для дальнейшего планирование развития сети.

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

Время работы сети - сочетает регистрацию и управление используемыми ресурсами и устройствами. Данная функция оперирует понятиями времени использование и платы за ресурсы

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

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

Инструменты управление сетью (NetworkManagement), нет можно путать с средствами управление компьютерных операционных систем (SystemManagement). Представителями средств управление есть системы HPOpenView, SunNetManager и IBMNetView.

Инструменты управления системой обычно выполняют следующие функции: Учет используемых аппаратных да программных средств.

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

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

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

Современные средства управление сетью отвечают за:

Недостаток систем управления в том, что: одна система отвечает только за часть сети, в то время как наличие нескольких систем приводит к проблемам получение данных с них, реакции на инциденты да управление их компонентами.

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

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

Или Задача есть областью задач управление сетью. Ряд программ сетевого мониторинга: ping, серверы SNMP, Zabbix (Open Source), NetXMS (Open Source) , Intellipool Network Monitor, ManageEngine OpManager, Packet Analyzer: HP OpenView Network, Network Traffic Monitoring, Analysis and Troubleshooting, NetVizor, NetDecision,.

В сетях Ethernet концентратор (т.е. концентратор, hub) и коммутаторы (switch) есть начальными точками подключение к сети компьютеров или других сетевых устройств. вместе данные компьютеры составляют сегмент сети позволяющий им «общаться» напрямую один с одним. Хаби - меньше «интеллектуальные» устройства, они просто принимают кадры через один порт и передают их на все порты. Это отлично подходит для мониторинга в режиме promiscuous (от англ. неразборчивый). В противоположность Им коммутаторы анализируют все фреймы по мере их поступления и проверяют MAC-адреса source и destination. Только затем пакет передается в нужен порт.

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

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

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

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

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

Сетевой мониторинг поддерживает широкий спектр устройств, таких как серверы, маршрутизаторы, выключатели и даже конечные устройства. Кроме того, он может быть использован в любых сетях, таких как WLAN, LAN, VPN да даже WAN.

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

Важной частью мониторинга маршрутная аналитика. Маршрутно аналитика это набор инструментов, приложений и алгоритмов, контролирующих маршрутизацию внутри сети. Он работает на сетевом шаре.

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

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

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

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

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

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

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

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

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

Процесс контроля работы сети обычно делят на два этапа. - мониторинг и анализ

на этапе мониторинга выполняется проще процедура - процедура сбора первичных данных о работу сети: статистики о число циркулирующих в сети кадров и пакетов разнообразных протоколов, состояние портов концентраторов, коммутаторов и маршрутизаторов и т.д. п.

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

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

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

сканеры и тестеры.

Разделим средства мониторинга и анализа вычислительных сетей на несколько крупных классов:

Системы управление сетью (Network Management Systems) - централизованные программные системы, которые собирают данные о состояние узлов и коммуникационных устройств сети, а также данные о трафике, циркулирующем в сети. Эти системы не только осуществляют мониторинг и анализ сети, но и выполняют в автоматическом или полуавтоматическом режиме действия по управлению сетью - включение и отключение портов устройств, изменение параметров мостов адресных таблиц мостов, коммутаторов и маршрутизаторов т.п. Примерами систем управление могут служить популярные системы HPOpenView, SunNetManager, IBMNetView.

Средства управления системой (System Management). Средства управления системой часто выполняют функции, аналогичные функциям систем управление,

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

Встроенные системы диагностики и управление (Embedded systems). Или системы выполняются в виде программно-аппаратных модулей, устанавливаемых в коммуникационное оборудование, а также в виде программных модулей, встроенных в операционные системы. Они выполняют функции диагностики и управление только одним устройством, и в этом их основная отличие от централизованных систем управления. Примером средств этого классу может служить модуль управления концентратором Distrebuted 5000, реализующий функции автосегментации портов при обнаружении неисправностей, приписывание портов внутренним сегментам концентратора и некоторые другие. Как правило, встроенные модули управление "за совместительством" выполняют роль SNMP-агентов, что поставляют данные о состояние устройства для систем управление.

Анализаторы протоколов (Protocol analyzers). Есть программными или аппаратно-программными системами, которые ограничиваются в отличие от систем управление только функциями мониторинга и анализа трафика в сетях. Хороший анализатор протоколов может захватывать и декодировать пакеты большой количества протоколов, б/у в сетях - конечно несколько десятков. Анализаторы протоколов позволяют установить некоторые логические условия для захвата отдельных пакетов и выполняют полное декодирование захваченных пакетов, то есть показывают в удобной для специалиста форме вложенность пакетов протоколов разных уровней один в одного с расшифровкой содержания отдельных полей каждого пакета.

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

приборы для сертификации кабельных систем, кабельные сканеры и тестеры (мультиметры).

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

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

Всю информацию протокол SNMP получает из базы управляющей информации (ManagementInformationBase, MIB). MIB представляет собой базу данных стандартизированной структуры База данных имеет древовидную структуру, а все переменные классифицированы за тематикой. каждое поддерево содержит определенную тематическую подгруппу переменных. Наиболее важные компоненты, что отвечают за работу сетевых узлов, объединены в подгруппе MIB-II.

Есть два типа MIB: стандартные и фирменные. Стандартные MIB определены комиссией с деятельности Интернет (Internet Activity Боард, IAB), а фирменные - производителем устройства. В базах данных, указанных в таблицы 1, присутствует множество переменных, которые могут быть полезны для диагностирование сети и сетевых устройств

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

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

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

Кроме этого, стоит отметить, что SNMPv 3 перенял модульную архитектуру от своих предшественников. Это обеспечивает поддержку предыдущих версий SNMP и, несмотря на то, что SNMPv 1 и SNMPv 2 не поддерживают аутентификацию и шифрование, у Вас будет возможность управления устройствами, которые поддерживают или версии.

В SNMPv 3 уже нет применяются сроки «агент» и менеджер, теперь используются сроки "сущности". Как и раньше одна сущность находится на управляемом устройстве, а вторая занимается опросом приложений.

В сущностей-агентов и сущностей-менеджеров теперь есть ядро, какое выполняет четыре основные функции:

Диспетчер - это просто система управление входящим и выходным трафиком. Для каждого выходного блока данных (PDU) он определяет тип необходимой обработки (SNMPv 1, SNMPv 2, SNMPv 3) и передает блок данных соответствующего модуля в системе обработки сообщений.

Система обработки сообщений получает от Диспетчера выходные блоки. данных (PDU), добавляет к них подходящий заголовок и возвращает их назад Диспетчеру.

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

Система контроля доступа управляет службами аутентификации для контроля доступа к MIB исходя из содержимого блоков данных.

Стандарт SNMP создан для решения задач обработки ошибок да анализа производительности и надежности.

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

Анализ производительности и надежности. Оценка на основе статистической информации таких параметров, как время реакции системы, пропускная способность каналов связи, интенсивность трафика в отдельных сегментах сети, вероятность искажения данных, коэффициент готовности служб сети Результаты такого анализа позволяют контролировать сделку о уровень обслуживание (Service Level Agreement, SLA).

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

Архитектуру распределенной системы можно описать в терминах обрабатывающих элементов (или компонентов), что соединяют элементов (или соединителей) и элементов данных. Перечислим составляющие элементы системы управление SNMP:

Проанализируем архитектуру SNMP с позиции достижение поставленных перед SNMP целей. Для этого используем понятие архитектурного стиля сетевого программного обеспечения Архитектурный стиль – это согласованный набор архитектурных ограничений, наложенных на роли и особенности архитектурных элементов (компонентов, соединителей и данных) и отношений между ими, какая проявляется в любой архитектуре, и какая удовлетворяет этом стиль.

Компоненты.

Архитектура SNMP предполагает построение системы управление за схемой

«менеджер-агент», есть использование архитектурного стиля «клиент- сервер». Система SNMP содержит множество управляемых узлов, на каждом из которых размещается достаточно простой сервер – агент SNMP, а также, по крайней мере, один узел, что содержит сложного клиента - менеджера SNMP.

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

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

сетями верхнего уровня, интегрируя получаемые от агентов данные. Это разрешает создавать многоуровневые системы управление, что отвечают архитектурном стиля «многоуровневый клиент-сервер».

Более подробная классификация компонентов:

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

Схема данных описывается структурой управляющей информации (Structure of Management Информация, SMI). Схема данных определяется, как выглядит управляющая информация, то есть описывает ее синтаксис. SMI базируется на Abstract Syntax Notation One. Конкретные наборы управляющей информации для разных типов устройств, протоколов и т.е. д. описываются базами управляющей информации (Management Information Bases, MIBs). Базы MIB определяют, какая управляющая информация существует. Например, для устройства, поддерживающего IP, MIB описывает таблицу маршрутизации, флажок активации функции маршрутизации, число переданных и принятых пакетов, число ошибок разного характера и т.д. д.

Таким образом, каждый устройство содержит набор значений переменных, определенных в некоторых количествах MIB, описанных по правилам SMI. Этот набор переменных и есть данным, что управляет информацией для протокола SNMP.

Важным вопросом является именование переменных. В SNMP каждой переменной присваивается уникальный идентификатор объекта (Object Identifier, OID). Пространство имен OID является иерархическим и контролируется организацией по распределению номеров в Интернете (Internet Assigned Numbers Authority, IANA). Каждый компонент имени есть числом. В текстовом виде имена записываются как десятичные числа, разделены точками, слева направо. Числам могут быть поставлены в соответствие текстовые строки для удобства восприятие. В целом, структура имени похожа на систему доменных имен Интернета (Domain Name System, DNS).

MIB определяет набор переменных, то есть определенную ветвь дерева OID, описывающую управляющую информацию в определенной области. Например, ветвь 1.3.6.1.2.1.1 описывает общую сведения о системе. Опишем некоторые переменные из этой ветви:

Переменные и сведения об их типе определены также в MIB. А сами типы переменных - в SMI.

Помимо непосредственно данных необходимо ввести операции над ними. Набор этих операций изменялся и расширялся по мере развития SNMP. Основными операциями есть:

Операции над данными в SNMP похожи на отдаленную отладку некоторой программы: состояние системы описывается определенным набором переменных, которые можно просматривать да изменять.

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

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

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

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

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

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

В этом разделе будет описан инструмент мониторинга сети Zabbix из общими фактами о Zabbix, его основные особенности да принципы работы. Кроме того, будут описаны ключевые преимущества, которые отличают Zabbix от других инструментов мониторинга.

Вообще Zabbix - это инструмент мониторинга сети, какой осуществляет централизованный мониторинг доступности да производительности сети да сетевых устройств. Если случилось ошибка, оповещение сообщит администратора сети через определенный гаджет или почтовый ящик. Zabbix – это совершенно бесплатный инструмент мониторинга сети. Нет ограничений в возможностях да количества контролируемых устройств. Официально разрешено вносить изменения на уровне исходного кода. Кроме того, Zabbix поддерживает любое какой размер сетевой установки: это может быть небольшая сеть или архитектура на уровне предприятия.

Zabbix был создан в 1998 году. В то время на рынке было только двое игроков: HP Open View и IBM BMC. Однако требовавшиеся решения были очень дорогими и слишком сложными для обслуживания и настройки инструментов для мониторинга с открытым кодом.

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

контролировать доступность устройства и его эффективность. Кроме того, Zabbix поддерживает мониторинг VMware. То есть VMware используется для мониторинга статистики виртуальных машин. Правила обнаружение низкого уровня используются для обнаружение виртуальных машин да гипервизоров.

Кроме того, Zabbix может также осуществлять мониторинг баз данных и веб-сервисы. В случае отказа сети или устройства Zabbix следует предупредить системного администратора. Zabbix поддерживает обнаружение сетевых устройств на низком уровне и может логически группировать их. Однако Zabbix не имеет прогнозирование тенденций. Вот почему Zabbix нет может заранее предупредить о возможны ошибки.

Zabbix складывается с таких компонентов, как: Zabbix Server, Zabbix Proxy, Zabbix Agent да веб-интерфейс. Каждый имеет заранее определенную роль в мониторинге. На рисунке 3.1 изображена полная архитектура, содержащая все компоненты Zabbix.

Zabbix Server есть основной частью Zabbix. Его главная цель - осуществлять удаленный мониторинг самой сети и его компонентов. Кроме того, он сохраняет конфигурации, исторические да эксплуатационные данные. Если случилось ошибка, Zabbix Server предупредить менеджера сети.

Zabbix Proxy собирает производительность данных от имени сервера Zabbix. на локальном уровне все данные собираются в буфер, который будет переадресован на Zabbix Server.

Прокси (Proxy) - это решение для централизованного удаленного мониторинг сети. Кроме того, Proxy распределяет рабочее нагрузка с Zabbix Server. Результатом является меньшая вычислительная мощность для сервера ввода-вывода.

Рисунок 3.1 - Компоненты Zabbix

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

Веб-интерфейс есть частью Zabbix Server. Обычно веб-интерфейс запускается на том же физическом сервере, где работает Zabbix Server. Веб-интерфейс нет есть традиционным интерфейс. Все операции считывание да записи направлены в базу данных, минуя Zabbix Server. Это значительно улучшает производительность Zabbix. С другого стороны, Zabbix Server нет работает без веб- интерфейса. рисунка 3.1 проиллюстрировано два дополнительные компоненты, нет связанные с Zabbix. Однако они играют важную роль в мониторинга сети.

Это медиасервер и база данных. Медиасервер (Media server) отвечает за отправка уведомлений по электронной почте да SMS, тогда как база данных используется для хранение конфигурационных да исторические данные.

В целом, комбинация этих компонентов разрешает Zabbix поддерживать три типа мониторинга: простая проверка, агент Zabbix и внешняя проверка. Просто проверка проверяет наличие разных служб, таких как SMTP или

HTTP без дополнительных установок на хосте. Агент Zabbix локально контролирует рабочая погрузка оборудования. Наружная проверка осуществляет удаленный мониторинг с помощью SNMP, TCP и ICMP через IPMI, SSH.

Хотелось бы указать, что мониторинг хоста также может осуществляться без прокси. В этом случае все данные мониторинга по хосту будут собираться непосредственно сервером Zabbix. Кроме того, графический интерфейс Zabbix, сервер Zabbix, медиасервер да база данных могут быть установлены в одной машине. Такой метод важен для малых и средних сетей.

Zabbix удовлетворяет требования надежного инструмента мониторинга телекоммуникационной сети примерно на 90 процентов. Он осуществляет как мониторинг на основе как агентов, так и без агентов. Можно найти такие функции, как обнаружение низкого уровня, автоматическое обнаружение и логическая группировка. Все вышеупомянутые функции делают Zabbix надежным инструментом мониторинга сети, полностью удовлетворяющей требования сети любого размера. Однако Zabbix не поддерживает прогнозирование тенденций. Эта функция не была включена командой Zabbix, поскольку она снижает общую эффективность. Zabbix - надежный и предполагаемый инструмент мониторинга сети. Если Zabbix предупредить пользователя о некоторые ошибки, то он может быть на 100 процентов уверен, что такая проблема существует. Те же принципы надежности применяются к восстановление и визуализации.

Кроме того, одним из главных преимуществ Zabbix является его масштабируемость, поскольку она применима для сред любого размера. Принцип масштабируемости применяется к производительности да удобства использование интерфейса Однако возможности Zabbix не ограничиваются только у ИТ. Zabbix как инструмент мониторинга сети можно сравнить с мозгом, получающий текущую информацию: ввод от датчиков, целых чисел данных да поточных файлов. Триггеры анализируют все или данные. Когда создается исходный результат из триггеров, результаты могут быть разными. Это может быть мак-адрес устройства, температура процессора или даже предупреждение или команда для запуска автономного сценария.

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

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

Прикладной программный интерфейс (API) может быть чрезвычайно медленным, особенно когда речь идет об операциях, связанных с связыванием шаблоны. Например, существует 10 000 хостов, и менеджер сети хотел бы связать их с простым шаблон. Это займет примерно 10-20 минут,

в зависимости от оборудования. Кроме того, это создаст слишком много запросов SQL. Их количество может достигать даже миллионов. Другая проблема состоит в том, что нет строгой проверки и слабой отчетности об ошибках. Например, пользователь допустил ошибку при наборе вызова API, который превратился на общую ошибку. В результате пользователь нет знает, какая именно ошибка произошло с API. В настоящее время API находится на интерфейсной части. Планируется переместить API на сторону сервера Zabbix. В результате это приведет к значительного улучшения производительности.

Безопасность Zabbix.

Главным методом в Zabbix, есть шифрование. Zabbix нет поддерживает шифрование и аутентификацию на прямую. В результате пользователи должны использовать сторонние инструменты, например Stunnel и Open VPN. Однако они нет должным образом интегрированные с Zabbix, и их тяжело поддерживать, особенно для больших сред.

Причина состоит в поэтому, что шифрование есть сложным процессом, поскольку

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

Связь между агентами уже достаточно велика для работы сети. Если добавить вещи, связанные с шифрованием, это окажет негативное влияние на работу сети да сервера Zabbix.

Zabbix на уровни кода.

Первый прототип Zabbix был выпущен как проект корпоративного банка. Однако, чтобы быть успешным коммерческим продуктом, нужно было изменить всю архитектуру. В результате была выбрана такая структура. Язык C использовалась для всех критических частей, таких как сторона сервера, сторона агента да сторона прокси. Для интерфейса было выбрано PHP. Он

использовался для визуализации и веб-интерфейса. Для базы данных было выбрано SQL. Структура появилась в Zabbix да стол базовой для всех следующих версий.

Zabbix да язык программирование С.

Язык C - язык низкого уровня. Благодаря хорошим навыкам Программирование можно создать эффективный код. Вот почему Zabbix быстр и не требует больших вычислительных ресурсов. Кроме того, язык C разрешает создавать приложение без каких-либо зависимостей.

Однако при разработке приложения на языке C следует учитывать следующие функции: управление памятью, журналы да общие ресурсы Как результат, это замедляет скорость.

PHP в Zabbix.

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

SQL в Zabbix.

При разработке самой первой версии выбор был между SQL и Round. Робин. Самым большим недостатком Round Robin было то, что он агрегирует информацию в базе данных, и существует необходимость установить правило агрегирование заранее. Когда требования изменяются, доступ к исходным данным больше не существует. Вот почему для Zabbix был выбран SQL. SQL – это механизм хранение транзакций. Это значит, что можно сделать огромное количество перемен, и все равно структура будет атомной. Как результат, это обеспечивает согласованность ограничений на уровни базы данных. Сам механизм проверяет, когда

данные противоречивые. Больше того, SQL имеет стандарт API. на Zabbix можно запускать MySQL, PostgreSQL, Oracle, DB2 и SQLite.

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

Сочетание языка программирования C, PHP и SQL оказывает положительное влияние на Zabbix. Как результат, Zabbix является довольно маленьким приложением, почти не имеет зависимостей. Использование языки C есть ключевым компонентом производительности Zabbix. Кроме того, этот инструмент мониторинга сети требует низкого использование ресурсов

Архитектура Zabbix обеспечивает разделение функций. Например, сбор данных уединенный от других компонентов, таких как хост, элементы да агенты. Как результат можно собирать данные, не влияя на другие компоненты. Больше того, Zabbix - это многопроцессный приложение. Такой компоненты, как Zabbix Server, Zabbix Proxy и Zabbix Agent, правильно масштабируются количеству ядер. Если аппаратное обеспечение заказчика имеет 32 или даже 128 ядер, Zabbix масштабирует его, чтобы получить все преимущества аппаратного обеспечение заказчика.

Архитектура Zabbix предоставляет значительные преимущества общий производительность, все же следует отметить некоторые недостатки. В Zabbix используются две разные технологии интерфейса. Несмотря на то, что PHP используется в интерфейсе, на (0,1) на языке C. Результат – дополнительные вызовы и влияние на скорость. Иногда встречаются ситуации, когда командам Zabbix приходится создавать дубликаты кода как на C, так и на PHP. Кроме того, дублирование кода частично влияет на регрессии. Другим вопросом архитектуры Zabbix есть то, что

используется интерфейсный PHP, какой есть динамически введенной да интерпретированной языке. В результате это вызывает некоторые дополнительные проблемы, например регрессии и неудачные проблемы. Теоретически, если PHP заменить другой языком, весь класс проблем исчезнет.

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

Zabbix использует технику кэширования. Кэш – это слой между сервером Zabbix или Zabbix Proxy и база данных. Хорошим примером может служить кэш конфигурации. Как показано на рисунке 3.2, для получения данных из базы данных звонки не направляются к базы данных.

Рисунок 3.2 - Методы кэширование

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

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

Групповые операции - это еще одна особенность, какая улучшает Производительность Zabbix – это кэш истории записи. Как показано на рисунке 3.3, вместо того, чтобы делать множественные вставки и обновления в базу данных, они сочетаются как одна массовая операция. Однако, как техника наличные, массовые операции используются только на задней панели. Вот почему он реализован только на Zabbix Server и Zabbix прокси.

Рисунок 3.3 - Массовые операции

Непрерывный мониторинг начинается, когда развертывание выполняется на производственных серверах С этого момента этот этап отвечает за мониторинг того, что происходит.

Nagios – это инструмент постоянного мониторинга с открытым выходным. кодом, какой контролирует сеть, приложения да серверы. Он может Найти да

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

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

В сравнении с Zabbix данная система имеет такие недостатки как:

Окончательный выбор системы мониторинга зависит от многих факторов. Мощь Nagios кроется в расширяемости, но при этом настройку можно считать непростой – система мониторинга целиком состоит из текстовых конфигурационных файлов, связи между которыми проходят насквозь, и не всегда просто Найти ошибку. Существует платно редакция Nagios XI, где есть графическое среда для настроек, но ее стоимость составляет (у версии Standard Edition) от $ 2000 к $ 5000, в зависимости от числа контролируемых узлов. Бесспорный плюс Zabbix в том, что система полностью бесплатна без любых ограничений функционала, а разработчик зарабатывает на сертификации партнеров и поддержки. К плюсам обеих систем можно отнести возможность интеграции с устройствами мониторинга микроклимата и управления электропитанием NetPing – что позволяет системам мониторинга не только получать сведения от разного ИТ оборудования и информационных систем, но и сведения о состоянии микроклимата серверных комнат / шкафов.

Выходя с всего выше сказанного, можно рекомендовать использовать Zabbix для ИТ специалистов с небольшим опытом в администрировании, учитывая небольшую сложности установки и конфигурации для большинства задач мониторинга. Nagios, как более сложное и тяжелое средство мониторинга, можно рекомендовать к использование более опытным специалистам и/или для использования в больших высоконагруженных сетях с большой количеством разнообразного оборудование.

Observium, как свидетельствует слоган на основном сайте, есть системой мониторинга да наблюдение за сетевыми устройствами и серверами. При этом список поддерживаемых устройств огромен и не ограничивается только сетевыми устройствами, главное условие – чтобы устройство поддерживало работу SNMP. Но и помимо SNMP собранная информация может быть дополнена другими способами и протоколами, например, syslog, rancid, unix-agent.

Поддерживается мониторинг некоторых систем виртуализации. В платной версии есть процесс для активных сообщений. Он не заменит такие системы, как Zabbix, так как на данный момент ограничен 5-ти минутными интервалами опроса устройств, но 60% нужд за сообщениями он способен обеспечить.

Основные преимущества системы: простота в установке, простой и удобный интерфейс, поддержка огромного количества разного оборудования. Наличие различных дополнительных инструментов) таких, как сбор, хранение и отображение журналируемой сообщений Syslog, конфигурационных файлов отслеживается оборудование с помощью Rancid, отслеживание протоколов маршрутизации (OSPF, BGP, EIGRP).

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

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

В сравнить с Zabbix есть минусы, среди них:

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

Вообще Zabbix - это инструмент мониторинга сети, какой осуществляет централизованный мониторинг доступности да производительности сети да сетевых устройств. Если случилось ошибка, оповещение сообщит администратора сети через определенный гаджет или почтовый ящик. Zabbix – это совершенно бесплатный инструмент мониторинга сети. Нет ограничений в возможностях и количества контролируемых устройств.

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

Zabbix удовлетворяет требования надежного инструмента мониторинга телекоммуникационной сети примерно на 90 процентов. Он осуществляет как мониторинг на основе как агентов, так и без агентов. Можно найти такие функции, как обнаружение низкого уровня, автоматическое обнаружение и логическая группировка. Все вышеупомянутые функции делают Zabbix надежным инструментом мониторинга сети, какой полностью удовлетворяет требования сети любого размера. Однако.

Zabbix нет поддерживает прогнозирование тенденций. Эта функция нет была включена командой Zabbix, поскольку она снижает общую эффективность. Zabbix – надежный и предполагаемый инструмент мониторинга сети. Если Zabbix предупредит пользователя о некоторых ошибках, то он может быть на 100 процентов уверен, что такая проблема существует. Те же принципы надежности применяются к обновлению и визуализации. Кроме того, одной из главных преимуществ Zabbix есть его масштабируемость, поскольку она применима для сред любого размера.

При выполнении технической части будем контролировать интерфейсы маршрутизаторов, а также память и использование центрального процессора Zabbix Server. Мониторинг будет осуществляться за помощью простого протокола управления сетью (SNMP). Поскольку в среде тестирования нету необходимости в функциях безопасности, которые предоставляет SNMP v3 - будет использовано SNMP v2. SNMP - это широко распространен интернет-протокол, используемый для управления устройствами в IP-сетях. В перечень устройств, что поддерживают SNMP, входят маршрутизаторы, коммутаторы, серверы, принтеры, ПК, разнообразные датчики да другие устройства.

Существует три поколение протокола SNMP.

SNMP v1 – это протокол управления 1-го поколения, дана версия испытала широкой критики через фактическую отсутствие безопасности. Аутентификация осуществлялась с помощью общей строчки. Совместная строка – это своего рода пароль, чтобы получить доступ к маршрутизатор, к того же пароль передавался в открытом виде.

SNMP v2 имеет улучшенными производительность, безопасность да конфиденциальность. Групповой запрос GetBulkRequest, реализуемый в версии 2 вместо GetNextRequest, разрешает получить большую количество необходимых данных в одному запросе. Однако на уровни с существенными улучшениями, нет обошлось и без спорных моментов, да новая система безопасности не получила широкого распространения через ее сложность.

SNMP v3 – это последняя версия протокола SNMP. Версия 3 обеспечивает радикальные улучшение безопасности при удаленном настройке. каждое сообщение SNMP версии 3 шифруется. Нет миновали стороной такие ключевые концепции безопасности, как конфиденциальность, целостность да аутентификация.

SNMP v3 имеет самый высокий уровень для RFC – стандарт Интернет, это значит что спецификация имеет большой да успешный опыт применение. Предыдущие версии протокола некоторые источники относят к историческим, однако Zabbix поддерживает все три поколения протоколов SNMP.

Прежде за все, след отразить фрагмент сети. на рисунка 4.1 представлен логический дизайн сети состоящей из PC1, Zabbix Server, одного коммутатора Cisco Catalyst да двух маршрутизаторов Cisco. Две дополнительные виртуальные машины станут частью сети: Ubuntu Server да Windows Server. Zabbix Server будет установлен на PC1 в качестве виртуального машины. Кроме того, серверы Ubuntu и Windows также будут установлены как виртуальные машины. Связь между PC1 да коммутатором осуществляется за с помощью прямого кабеля. Коммутатор будет связан с R1 и R2 также помощью прямого кабеля.

Рисунок 4.1 - Топология сети

Дальше необходимо активировать сервер SNMP на маршрутизаторы 1 да маршрутизатор 2. Это можно сделать с помощью команды в Cisco CLI: # snmp-server.

Прежде чем устанавливать Zabbix Server и Ubuntu Server, необходимо определиться с мощностями. Минимальные требования зависят от размера сети да количества контролируемых устройств. С течением времени количество сохраненных данных будет постепенно накапливаться. Поэтому вычислительные ресурсы да объем необходимой памяти нужно спланировать заранее.

Согласно документации Zabbix, Zabbix Server требует всего 128 МБ оперативная память и 256 МБ свободного пространства на жестком диске. Однако за реальных условий, данные значение относительными да зависят он ряды параметров В таблице 4.1 приведены рекомендованные требования к сетям разного размера.

Таблица 4.1 - Рекомендуемые характеристики для Zabbix Server

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

Например, на мониторинга находятся 1800 элементов, частота обновление для каждого элемента составляет 60 секунд. Поделив количество элементе на количество секунд, мы получим количество элементов добавленных ежесекундно в базу данных. В данном случае ежесекундно добавляется 30 новых значений.

Таблица 4.2 Планирование необходимой память

История – это фактически сохранение в течение фиксированного периода времени, например, недель или даже нескольких месяцев определенной информации. Например, существует необходимость сохранять данные в течении 10 дней. Ежесекундно получается

30 новых значений размером по 100 байт каждый. Соответственно к формулы истории:

10*30*24*3600*100 = 2 592 000 000 байт или 2.472 Гб значений. Тенденции отражают статистику изменения данных для каждого элемента,

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

равных 10, используя формулу с таблицы, получим:

10 *(1800/3600) * 24* 3600* 100= 4 320 000 байт или 4.119 Мегабайт

Каждое событие требует примерно 130 байт. Например, Zabbix генерирует событие ежесекундно. на основе формулы упомянутой раньше, мы можем рассчитать ориентировочный объем дискового пространства, который будет отведен под события. Размер одного события 130 байт следует умножить на 365*24*3600. результат, понадобится 4 ГБ дискового пространства для хранение событий собранных в течение года.

Добавив значение объемов памяти забранной во все четыре параметра описаны выше, мы получим ориентировочное значение какое позволит нам подобрать накопитель.

В этом подразделе был описан метод, помогающий заранее спланировать емкость памяти. Для Zabbix Server мы выбрали 20 ГБ дискового пространства. Согласно проведенным расчетам, данного объема дискового пространства имеет быть достаточно для хранение конфигурационных, исторических да тенденциозных, а также данных событий в течении нескольких лет активного мониторинга.

В этом разделе я опишу процесс установка Zabbix Server. на рисунка 4.5 приведено карту этапов установка. Сначала необходимо установить Ubuntu Server. После этого этаж будет установлен Zabbix Server. Последним этапом будет Вход в графический интерфейс Zabbix.

Рисунок 4.5 - Схема последовательности инсталляции

Мною было избрано Ubuntu Server 14.04.2 LTS. Его будет установлен как виртуальную машину в виртуальном окне Oracle. под время процесса установка Ubuntu Server требуется сделать несколько шагов, которые позволят позже установить Zabbix Server:

192.168.1.10, какая к того же будет адресом Zabbix Server-а.

Последним шагом является установка и настройка менеджера SNMP на сервере Ubuntu. Это позволило бы серверу Zabbix контролировать устройства по с помощью SNMP. Для того чтобы это можно было сделать, в командном строке Linux следует набрать указанный ниже список команд.

После выполнения данных шагов - сервер Ubuntu из SNMP установлен и настроены. Следующим этапом есть установка да настройка Zabbix Server.

Вторым этапом является установка Zabbix Server поверх Linux Server. Для того, чтобы скачать и установить сервер Zabbix, указанные команды нужно ввести в командном строке сервера Ubuntu.

В данном случае установлен пакет Zabbix v2.4, включающий следующие. компоненты, как Zabbix Server, интерфейс Zabbix (GUI), Zabbix Proxy, Medial Server и Zabbix Database. Кроме того, я установил Zabbix Agent локально на Zabbix Server. Это можно сделать с помощью этой команды: sudo apt-get install zabbix-agent zabbix-server-mysql zabbix-frontend-php snmpd php5-mysql php5-curl. Zabbix Agent будет осуществлять локальный мониторинг процессов на сервере Zabbix.

Прежде нож начать пользоваться Zabbix, остается два шаги.

Первый – это настройка часового пояса в соответствии с регионом, где установлен Zabbix Server. Это можно сделать за помощью команды

: sudo vi / etc /network/ interfaces.

Вторым шагом есть перезапуск сервера Apache. Это можно сделать, набрав команду: sudo service apache2 restart.Таким образом Zabbix Server было установлено и настроено. Кроме того, Zabbix Agent было установлено локально на Zabbix Server. Следующим шагом является вход в графический интерфейс Zabbix.

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

В этой части я буду осуществлять SNMP-мониторинг устройств за с помощью Zabbix Server. На рисунке 4.4 представлен план шагов, которые необходимо выполнить перед началом мониторинга.

Рисунок 4.4 - Шаги мониторинга SNMP

Создадим хост, элемент и график. Хост - это сетевое устройство, которое будет контролировать Zabbix. Элемент определяет для Zabbix то, что я хотел бы контролировать на хосты. В нашему случае будет создано несколько элементов для мониторинга использование центрального процессора, памяти, интерфейсов да пропускной способности.

Первым шагом есть создание хоста. Это сетевой устройство или услуга, которые будут контролироваться через сервер Zabbix. Первый маршрутизатор будет иметь имя R1, дана название будет использоваться в контексте мониторинга да среды Zabbix в целом. За помощью имени хоста мы сможем отрезать устройства между собой. R1 будет контролироваться через SNMP, поскольку на нем невозможно установить Zabbix Agent локально. Кроме того нужно указать IP-адрес устройства, В соответствии с плана логической сети, представленного на рисунка 1, IP-адрес маршрутизатора R1 - 192.168.1.1

Элемент аккумулирует да отображает в себе данные от хоста, например процессор, память и нагрузка пропускной способности Для мониторинга использование ЦП нужно создать два элементы. Первый - это простой процессора. Он измеряет объем доступных ресурсов. Второй – использование процессора.

Мониторинг процессора на маршрутизаторе производился с помощью SNMPv2. Интерфейс хоста назначается автоматически. Ключ создается вручную, и название его должно быть уникальным. Далее следует назначить номер OID. Это уникальный номер, используемый для имени конкретного процесса или параметр. Каждый процесс имеет свой уникальный номер OID. Zabbix Server, чтобы получить определенный параметр с устройства, отправляет на устройство номер OID этого параметра Он отвечает на Zabbix уже результатами параметров Номер OID для простоя CPU составляет 1.3.6.1.4.9.2.1.59.0. Номера OID можно Найти в официальной документации от производителя устройства.

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

Таблица 4.3 Параметры элементов

Не существует ни одной универсальной OID, каждый номер порта имеет собственный OID SMNP. Оба элемента имеют фиксированные части. Последняя цифра – это уникальный OID, который меняется в зависимости от порта. Команда #show snmp mib ifmib ifindex для устройств Cisco используется для получение номера индекса интерфейса Рисунок 4.5 показывает результат этой команды. Поскольку мой маршрутизатор подключен к коммутатора через порт FastInternet0 / 1-, индексный номер равно 2.

Рисунок 4.5 - Результат команды для индекса порта

Ручной конфигурация элементов да графиков - это трудоемкий процесс. Для ручного создания элементов требуется подробная сетевая документация которая должна содержать по меньшей мере типы устройств, имена и статусы. Кроме того, администратор сети должен иметь полный список OID SNMP для каждого устройства. Такой ограничение фактически делают невозможным масштабируемость мониторинга сеть, поэтому на практике часто используются шаблоны.

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

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

Второй преимущество состоит в поэтому, что один шаблон можно использовать для неограниченного количества хостов. Именно поэтому предназначение параметров мониторинга для хостов осуществляется одним щелчком. Кроме того, если есть

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

В данном разделе мы настроим шаблон для хоста R1. Созданный шаблон также будет использоваться для процессов мониторинга второго хоста – R2. На последнем шаге мы будем использовать шаблоны для мониторинга процессов на Ubuntu Server. На рисунке 4.6 приведена структурная схему.

Рисунок 4.6 - Структурно схема мониторинга

В данном разделе организуем мониторинг R1 с помощью шаблонов, выбрав шаблон устройств SNMP. Мониторинг этого шаблона основан на протокол SNMP. Поскольку мы используем этот шаблон на R1, нужно указать сообщество SNMP. Рисунок 4.7 иллюстрирует шаг назначения Template SNMP Devices на R1. Как результат, шесть новых элементов были автоматически созданы на R1. Кроме того, также добавлено графики да триггеры. Однако этот шаблон автоматически добавляет обнаружение да мониторинг интерфейсы.

Для отслеживания дополнительных элементов, например загрузки процессора и использованием памяти, можем воспользоваться одним из двух способов:

Первый – добавить эти элементы на шаблонные устройства SNMP. Однако это добавит ограничения на использование этого шаблона для других устройств. Вот почему мы добавляем еще два шаблоны на R1.

Рисунок 4.7 - Вставка шаблонов

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

как это было сделано для хоста. Для измерения производительности процессора нужно создать два элемента: CPU в режиме ожидания и загрузки процессора. Для использования памяти необходимо использовать память и свободную память. Из таблицы 4 я взял SNMP OID для необходимых элементов. След взять к внимания, что название и ключ для новых созданных элементов должны быть уникальными. Когда создаются новые элементы, нужно указать сообщество SNMP. Это можно сделать вручную на вкладке макросов. там необходимо указать, что строка ( SNMP_COMMUNITY) какой равно значению указанном имени. на основе новых элементов можно создавать графики. После этого на R1 можно назначить новый шаблон.

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

Возможности мониторинга Zabbix нет ограничивается сетевыми Устройствами, серверами также можно контролировать с помощью шаблонов. За по умолчанию Zabbix предлагает шаблоны для операционных систем на базе Linux и Windows. Мониторинг можно осуществить двумя способами: SNMP или Zabbix Agent.

В данном разделе мы будем отслеживать Ubuntu Server с шаблоном SNMP. В начале некоторые конфигурации нужно производить на сервере Ubuntu. Отметим – Ubuntu Server устанавливается как виртуальная машина. Сначала мы обновляем список пакетов Ubuntu Server с помощью команды: sudo apt- get update. Дальше нужно установить сервер SNMP: sudo apt-get install snmpd

snmp. Это позволит Zabbix Server контролировать Ubuntu Server за помощью SNMP.

Когда сервер SNMP установлен, нужно внести некоторые изменения к конфигурации. Редактирование нужно выполнить в файле конфигурации за помощью этой команды: sudo vi /etc/snmp/snmpd.conf. Существует необходимость прокомментировать строку об адресе агента: #agentAddress udp: 127.0.0.1:161. Это следует сделать из-за того, что сервер Ubuntu не собирается контролировать через агент Zabbix. Кроме того, нужно добавить строку: agentAddress udp : 161, udp6: [:: 1]: 161. Эта команда указывает номер порта 161. Это номер порта UDP для SNMP. Последняя строка, которую нужно добавить, - это сообщество SNMP: rocommunity. Нужно перезапустить службу SNMP: sudo service snmpd restart.

Следующим шагом является добавление сервера Linux как хоста в графическом. интерфейс Zabbix. Именем хоста был выбран Linux Server 1. Шаблон для мониторинга нового хоста был выбран SNMP OS Linux. В этом шаблоне нужно указать сообщества SNMP, он содержит все необходимые элементы, поэтому дополнительных редактирований делать не нужно. Шаблон автоматически создает элементы да графики хоста. Как результат, сервер Linux можно контролировать.

Можем сделать заключение, что в этом разделе мы смогли использовать шаблоны для мониторинга процессов на R1. Тот же набор шаблонов был использован на R2. Кроме того, мы имели возможность контролировать эффективность сервера Ubuntu, установленного как виртуальная машина. Шаблоны приносят значительную предпочтение для сети среднего да корпоративного уровня. Они помогают упростить процесс создание элементов для хоста. Для шаблона нужно настроить элементы только один раз. После этого элемент может быть легко использован многими хостами. Кроме того, если необходимы изменения в мониторинге, их нужно сделать только один раз по шаблону. Хосты, использующие этот шаблон, будут автоматически обновлены, вместо того, чтобы изменять элементы на каждом хосты вручную.

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

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

В этом разделе я буду проводить мониторинг с помощью агента Zabbix. Хостом будет Ubuntu Server установлен в качества виртуальной машины.

Первым шагом есть установка Zabbix Agent локально на Ubuntu Server с помощью команды: sudo apt-get install zabbix-agent. После Для завершения установки необходимо выполнить конфигурацию. В файле конфигурации /etc/zabbix/zabbix_agentd.conf мы указываем адрес, куда присылать данные, которые будет собирать Zabbix Agent, в моем случае это 192.168.1.10.

на втором этапе мы должны добавить сервер Ubuntu как хост. Назовем его Linux Server 2, далее назначаем ему шаблон OS Linux и IP-адрес - 192.168.1.20. С помощью этого шаблона мы можем контролировать загрузка процессора, использование диска да сетевого трафика.

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

Auto Discovery автоматически обнаруживает устройства в сети. Кроме того, обнаруженные устройства могут быть автоматически добавлены, поскольку хосты да шаблоны могут назначаться автоматически. Это позволяет находить устройства, которые контролируются как за помощью агента, да и за отсутствия агента. Auto Discovery широко используется в сетях среднего да корпоративного уровня Перед началом использования данной функции необходимо выполнить некоторые предварительные требования. Рекомендуется логически группировать хосты. Устройства, контролируемые SNMP, должны проверить название сообщества SNMP. Устройства, которые контролируются за принципом агента, должны проверить, работает агент Zabbix.

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

Рисунок 4.8 - Автоматическое обнаружение

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

Отметим, что Zabbix Server, Ubuntu Server1-3 устанавливаются как виртуальные машины на компьютере. На рисунке 4.9 они проиллюстрированы отдельно, чтобы предоставить обзор логических групп.

Рисунок 4.9 - Топология сети

Для тестирование мониторинга Zabbix, необходимо рассмотреть как он работает:

Рисунок 4.10 - Сеть мониторинга Zabbix

Устройство с одной стороны канала (Client) периодически отправляет ряд запросов на устройство (Server) на другой стороне канала, получает ответы (или нет получает) и сохраняет результаты. Запросы бывают следующих типов:

Первые два типы запросов относятся, очевидно, нет совсем к качества канала, а скорее к доступности да быстродействия web-сервисов, последние 4 запросы являются расширенными и требуют поддержки RPM со стороны устройства с ролью Server. Кроме поддержки RPM, для этих тестов также требуется и расширенная лицензия. В нашем случае для роли Client и роли Server – используем коммутаторы ex2200 с базовой лицензией и роль RPM Server для расширенных тестов применять не можем. Поэтому в этом разделе ограничимся запросами типа ICMP echo request. Тем более что это гораздо более универсальный сценарий. Роль Server может выполнить абсолютно любое сетевое устройство, которое умеет отвечать на ping. Схема тестирование изображена на рисунка 4.11.

Рисунок 4.11 - Схема тестирование

Есть два L2 канала между офисами от двух операторов связи. Client расположен слева. В принципе достаточно было бы использовать по одному устройства с каждого стороны, но да сложилось, что к момента организации тестирование устройства ex-isp1 и ex-isp2 уже использовались на этом участке сети.

Теперь можем перейти к конфигурирование RPM. на устройства ex2200- rpm прописываем следующую конфигурацию:

iddqd@ex2200-rpm> show configuration services rpm probe Gee {

test Jitter {

probe-type icmp-ping-timestamp;

target address 2.2.2.2; probe-count 15;

probe-interval 1; test -interval 15;

source -address 2.2.2.1; data-size 1400;

thresholds {

successive-loss 2;

}

hardware-timestamp;

}

}

probe BARS { test Jitter {

probe-type icmp-ping-timestamp;

target address 1.1.1.2;

probe-count 15;

probe-interval 1; test -interval 15;

source -address 1.1.1.1; data-size 1400;

thresholds {

successive-loss 2;

}

hardware-timestamp;

}

}

Конфигурация self-explanatory в особых объяснениях не нуждается. После чего делаем commit and-quit и через минуту уже можно собирать результаты тестов.

Теперь переходим к настройкам Zabbix для мониторинга RPM тестов. Встроенная функциональность SNMP в Zabbix недостаточна для автоопределения RPM тесты. Для автоопределения Zabbix использует метод snmp walk. Где в качества параметры, которые используются SNMP индексы да их значение. Например, для поиска по объекта ifDescr, пишем следующее:

$ snmpwalk -v 2c -c 192.168.1.1 IF-MIB :: ifDescr IF-MIB :: ifDescr. 4 = STRING: WAN

IF-MIB :: ifDescr.7 = STRING: LAN1 IF-MIB :: ifDescr.11 = STRING: LAN2

Метод discovery в Zabbix обнаружит индексы 4,7,11 и их значение WAN, LAN1 и LAN2. А вот для обнаружение тестов RPM, Juniper нет предоставил такого удобного объекта. Наиболее подходящий объект, что удалось обнаружить - это объект jnxRpmResSampleValue. После которого таблица возвращение объекта выглядеть следующим образом:

iddqd@ex2200-rpm> show snmp mib walk jnxRpmResSampleValue jnxRpmResSampleValue.3.71.101.101.6.74.105.116.116.101.114.1 = 1989

jnxRpmResSampleValue.3.71.101.101.6.74.105.116. 116.101.114.2 = -424

jnxRpmResSampleValue.3.71.101.101.6.74.105.116.116.101.114.3 = 810

jnxRpmResSampleValue.4.66.65.82.83.6.74.105.116.116.101.114.1 = 3352

jnxRpmResSampleValue.4.66.65.82.83.6.74.105.116.116.101.114.2 = 1612

jnxRpmResSampleValue.4.66.65.82.83.6.74.105.116.116.101.114.3 = 971

С приведенной таблички видно, что jnxRpmResSampleValue - это MIB объект, по котором мы проходим, цифры .3.66.101.101.6.74.105.116.116.101.114

- это название нашего теста. Кроме того, можем доказать. В качества SNMP index (последнее после точки число) выступает порядковый номер параметров теста:

Если посмотреть результаты RPM теста и сопоставить с числами, которые вернул snmpwalk, чтобы узнать OID (есть цифровое значение) MIB объектов в JunOS таких как jnxRpmResSampleValue, jnxRpmResultsSampleTable, jnxRpmHistorySummaryTable и любых других, можно запустить команду: show snmp mib walk jnxRpmResSampleValue. Есть, скрипт авто определение.

Следовательно, без внешней помощи Zabbix с обнаружением RPM тестов не справится. Необходимо для удобства оказать помощь в виде внешнего скрипт, скрипт написанный на Python 2.7 zbx_junper_rpm и использует всего одну внешнюю библиотеку – pysnmp. Данна библиотека присутствует в большинству дистрибутивов Ubuntu и его можно поставить командой: apt install python-pysnmp4 или в любому дистрибутивные через PIP менеджер командой: pip install pysnmp.

на Вход скрипта подаются 2 параметра hostname и community да возвращается JSON в следующем виде:

{

"data ": [

{

" {#RPMTEST} ":" Jitter ",

"{#RPMUUID} ":" 4.66.65.82.83.6.74.105.116.116.101.114 " , "{#RPMOWNER}": "BARS"

}

{

"{#RPMTEST}": "Jitter",

"{#RPMUUID}": "3.71.101.101.6.74.105.116.116.101.114", { {1}} "{#RPMOWNER}": "Gee"

}

]

}

Назначены для пользователя макросы {#RPMUUID}, {#RPMOWNER} и

{#RPMTEST} Дальше используются в названиям элементов, их ключах, триггерах и даже графикам. Скрипта нужно сделать chmod + x и разместить в директорию для внешних скриптов Zabbix в нашем случае это директория: /etc/zabbix/etc/externalscripts. Дальше не будем расписывать настройки Zabbix, а просто переходим к шаблонам. Шаблон включает в себя себя 3 элемента: RTT, Jitter и PacketLoss, для каждого RPM теста, которые он обнаруживает с помощью скрипта RPM, RPM тест не предполагает измерение Jitter, то этот параметр просто автоматически исключается с мониторинга.

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

В данном разделе было проведено и проанализировано техническое тестирование производительности протокола SNMP для Zabbix server. Мониторинг будет осуществляться с помощью простого протокола управления сетью SNMP v2, поскольку в среде тестирования нет необходимости в функциях безопасности, предоставляемых SNMP v3. SNMP – это стандартный Интернет-протокол, который используется для управление устройствами в IP-сетям. В диапазон устройств, что поддерживают SNMP, входят маршрутизаторы, коммутаторы, серверы, принтеры, ПК и другие устройства.

Первым этапом было создано новую сеть в какую входили такие элементы как PC1, Zabbix Server, один коммутатор Cisco Catalyst да два маршрутизаторы Cisco Более того, две дополнительные виртуальные машины станут частью сети: Ubuntu Server да Windows Server. Zabbix Server будет установлено на PC1 как виртуальная машина.

на втором этапе было осуществлено планирование конфигурации мощности да памяти используя определенные методы анализа Дальше были установке Linux Server и Zabbix Server.

на третьем этапе был осуществлен SNMP-мониторинг устройств за с помощью Zabbix Server а также расписанные шаги, которые необходимо выполнить перед началом мониторинга.

В данном разделе также был осуществлен мониторинг за помощью шаблоны и мониторинг маршрутизатора. Шаблон – это набор сущностей, которые можно применить к любому хосту. И наконец осуществленный мониторинг серверов Zabbix. Серверы также можно контролировать за помощью шаблоны. За по умолчанию Zabbix предлагает шаблоны для операционных систем на базе Linux и Windows.

ВЫВОДЫ

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

Zabbix предоставляет широкий спектр функций да возможностей. Поддерживает агентские да безагентные средства, что используются для мониторинга сетевых устройств, таких как маршрутизаторы, коммутаторы да сервер. Сетевые устройства должны поддерживать протокол SNMP. Zabbix может контролировать доступность устройства и его эффективность. Кроме того, Zabbix поддерживает мониторинг VMware. Есть VMware используется для мониторинга статистики виртуальных машин. Правила обнаружение низкого уровня используются для обнаружение виртуальных машин да гипервизоров.

Кроме того, Zabbix может также осуществлять мониторинг баз данных и веб-сервисы. В случае отказа сети или устройства Zabbix следует предупредить системного администратора. Zabbix поддерживает обнаружение сетевых устройств на низком уровне и может логически группировать их. Однако Zabbix не имеет прогнозирование тенденций. Вот почему Zabbix нет может заранее предупредить о возможны ошибки.

Zabbix удовлетворяет требования надежного инструмента мониторинга телекоммуникационной сети примерно на 90 процентов. Он осуществляет как мониторинг на основе как агентов, так и без агентов. Можно найти такие функции, как обнаружение низкого уровня, автоматическое обнаружение и логическая группировка. Все вышеупомянутые функции делают Zabbix надежным инструментом мониторинга сети, какой полностью удовлетворяет требования сети любого размера.

Кроме того, одним из главных преимуществ Zabbix является его масштабируемость, поскольку она применима для сред любого размера. Принцип

масштабируемости применяется к производительности и удобству использования и интерфейс.

ПЕРЕЧЕНЬ ЛИТЕРАТУРЫ

http://aggregate.tibbo.com/solutions/network_management/network_monitoring