Разработка системы мониторинга IT-активов и оборудования

Размещено на http://www.allbest.ru/

Федеральное агентство связи

Федеральное государственное бюджетное образовательное учреждение

высшего образования

«Поволжский государственный университет телекоммуникаций и информатики»

Факультет Заочного обучения

Направление (специальность) Информационные системы и технологии

Кафедра Программное обеспечение и управление в технических системах

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

Разработка системы мониторинга IT-активов и оборудования

Разработал

А.А. Баклушин

Самара 2017



Введение

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

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

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

Задачи, решаемые в связи с указанной целью:

· определить понятие мониторинга;

· провести анализ методов мониторинга;

· провести анализ существующих систем мониторинга;

· привести обоснование выбора системы мониторинга;

· описать работу мониторинга жестких дисков;

· описать процедуру установки и настройки сервера Zabbix.

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

Данная работа написана на основе официальных открытых источников по программному продукту Zabbix и PowerShell.

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



1. Исследование предметной области

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

1.1 Постановка задачи

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

· серверы;

· маршрутизаторы;

· коммутаторы;

· персональные компьютеры;

· доступ в интернет;

· всевозможные сервисы (зависит от направления работы).

Необходимо разработать системы мониторинга, отвечающую следующим требованиям:

· кроссплатформенность клиентов;

· консолидированный сбор информации;

· просмотр событий в реальном времени;

· возможность отображения информации в графическом виде;

· встроенное средство e-mail оповещений о неисправностях;

· легкий понятный интерфейс;

· быстрая установка ПО и сервера.

Среди дополнительных требований можно выделить:

· SMART мониторинг состояния жестких дисков;

· RAID мониторинг состояния установленного RAID контроллера в системе.

1.2 Определение мониторинга сети

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

Рис. 1.1 - Топология локальной сети

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

· отправлен сигнал тревоги системному администратору;

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

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

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

· пассивный мониторинг, предполагающий ожидание от устройств

сообщений о событиях, происходящих в системе. Чаще всего такие сообщения присылаются устройствами посредством простого протокола сетевого управления (SNMP). Это протокол прикладного уровня, который является составной частью протокола TCP/IP и позволяет администраторам руководить производительностью сети, находить и устранять сетевые проблемы.

Обычно на практике в системах мониторинга данные виды комбинируются.

1.3 Методы мониторинга сети

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

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

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

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

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

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

· экспертные системы. Этот вид систем аккумулирует человеческие знания о выявлении причин аномальной работы сетей и возможных способах приведения сети в работоспособное состояние;

· экспертные системы часто реализуются в виде отдельных подсистем различных средств мониторинга и анализа сетей: систем управления сетями, анализаторов протоколов, сетевых анализаторов;

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

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

В общем случае можно говорить о таких элементах как:

1. проверка физической доступности оборудования;

2. проверка работоспособности служб и сервисов, которые в настоящее время работают в сети;

3. детальная проверка важных критериев функционирования сети (загрузки, производительности и других);

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

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

Следующим этапом является проверка работоспособности критичных служб. Обычно это означает TCP-подключение к тому порту сервера, где должна быть запущена служба, а также отправка выполнение тестового запроса. Далее происходит проверка нагрузки, где выясняются также данные о памяти и загруженности процессора, свободном дисковом пространстве, статусах принтеров у сервера печати и другие принципиально важные проверки. И, наконец, многие окружения требуют еще и специфических проверок, таких как запросы, к базе данных, которые контролируют работу какого-либо приложения, проверка файловых отчетов или значений настроек, отслеживание наличия некоторого файла (к примеру, создаваемого при возникающих проблемах в системе). [5]

Системы управления сетью позволяют в автоматическом режиме контролировать сетевой трафик и управлять коммуникационным оборудованием сети. Большинство современных систем управления сетью построены на основе протокола SNMP. [3]

1.4 Анализ существующих систем мониторинга

1.4.1 System Center Operations Manager

System Center Operations Manager (рис.1.2) - система сквозного мониторинга от Microsoft, в том числе активного слежения за состоянием сетей (наблюдение за любыми сетевыми устройствами, поддерживающими SNMP, вплоть до уровня портов, а также обнаружение виртуальных локальных сетей и коммутаторов в таких сетях). В последних версиях появилась возможность слежения не только за системами, под управлением операционных систем семейства Windows, но и за гетерогенными средами, включающими UNIX и Linux. System Center Operations Manager предназначен главным образом для организаций с числом машин более 500 и числом серверов более 30. Для меньших организаций существует продукт System Center Essentials, включающий в себя часть функционала продуктов System Center Operations Manager и System Center Configuration Manager, но предназначенный для малых и средних предприятий. Сам продукт, начиная с версии 2012 года, является сервисом высокой доступности, благодаря отсутствию серверов управления. В пуле с несколькими серверами нагрузка балансируется и обеспечивается доступность. На каждом сервере работает служба конфигурации, причём хранение данных реализовано не в памяти или XML-файлах, а в базе данных. Microsoft также предоставляет возможность интеграции продукта с System Center Service Manager, благодаря чему появляется возможность автоматического создания инцидентов на основе оповещений SCOM. Что касается тонкого слежения за виртуальными средами, есть средства для интеграции с пакетом System Center Virtual Machine Manager, который будет передавать System Center Operations Manager информацию о виртуальных машинах, службах, частных облаках и узлах. Основные преимущества:

· исключительная производительность и работоспособность приложений для программных сред Microsoft;

· обеспечивает сквозное управление службами для сервисов вашего центра обработки данных;

· способствует улучшению эффективности и управления средами центров обработки данных;

· унифицированный контроль в рамках частных и общедоступных облачных сервисов.

· поддержка Windows PowerShell 2.0 с набором новых командлетов.

Одно из главных достоинств System Center Operations Manager - продвинутая визуализация всего огромного собранного набора данных, в основном в виде графиков и диаграмм, причём визуализация доступна не только в специальной консоли программы, но и через веб-интерфейс. Элементы представления же можно подвергать тонкой настройке, пример интерфейса на рисунке 1. Версия 2012 поддерживает расширенное наблюдение за смешанными средами, а именно за машинами под управлением Unix и Linux (так называемых «систем *nix: агент *nix поддерживает HP-UX 11i версии 2 или 3 на базе PA-RISC и IA64, Sun Solaris 9 на базе SPARC и 10 на базе SPARC и 32-разрядной платформы, RedHat Enterprise Linux 4, 5 и 6 на 32- и 64-разрядных платформах, Novell SuSE Linux Enterprise Server 9 на 32-разрядной платформе, 10 SP1 и 11 на 32- и 64-разрядных платформах, а также IBM AIX 5.3, 6.1 и 7.1 на базе POWER. Для мониторинга используются 2 ключа: sudo (для конфигурирования стандартной учётной записи с нужным уровнем доступа) и SSH (для безопасного обслуживания агента).

Итак, можно сказать, что System Center Operations Manager - это мониторинг высокой доступности с упрощённой инфраструктурой, использующийся в организациях с большим парком машин под управлением различных семейств операционных систем, включающий множество разнообразных средств слежения, в том числе за сетевым оборудованием, а также расширенные средства представления собранной информации. Однако у данной системы есть ряд недостатков с точки зрения решения конкретной технической задачи:



Рис. 1.2 - Внешний вид окна System Center Operations Manager

· система мониторинга охватывает множество общих показателей системы, но непригодна для слежения за специфическими параметрами;

· до сих пор работа с операционными системами вне семейства Windows нестабильна;

· необходимость установки сервиса агента;

· невероятная громоздкость и трудоёмкость настройки продукта «под себя»: система дольше подходит для мониторинга общего состояния и сбора основных сведений о большой структуре (например, множество клиентских и серверных машин в домене).

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

1.4.2 ZABBIX

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

· сервер мониторинга (ядро) - выполняет периодический опрос и получение данных, обрабатывает их, анализирует, также осуществляет запуск скриптов для рассылки оповещений. Может удаленно проверять сетевые сервисы, является хранилищем, в котором хранятся все конфигурационные, статистические и оперативные данные. Не может располагаться на сервере под управлением операционной системы семейства Windows, а также OpenBSD;

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

· агент - специальный демон, который запускается на отслеживаемых объектах и предоставляет данные серверу, осуществляя контроль локальных ресурсов и приложений (таких как жесткие диски, память, статистика процессора и т. д.) на сетевых системах, т.е. эти системы должны работать с запущенным Zabbix агентом (однако мониторинг можно производить не только с помощью него, но и по SNMP версий 1, 2, 3, запуском внешних скриптов, выдающих данные, и несколько видов предопределенных встроенных проверок, таких как ping, запрос по http, ssh, ftp и другим протоколам, а так же замер времени ответа этих сервисов. Zabbix агенты являются чрезвычайно эффективными из-за использования встроенных системных вызовов для сбора информации о статистике. Zabbix-агенты поддерживаются не только на *nix операционных системах, но и на AIX и Windows. Поддерживаемые платформы указаны в таблице 1;

· веб-интерфейс - средство визуального представления Zabbix, реализован на PHP, для запуска требует наличия веб-сервера, представлен на рис. 1.3

Рис. 1.3 - Главная страница Zabbix



Zabbix поддерживает платформы, указанные в табл. 1.1

Таблица 1.1 Поддержка операционных систем

Платформа	ZABBIX-сервер	ZABBIX-агент
AIX	Поддерживается	Поддерживается
FreeBSD	Поддерживается	Поддерживается
HP-UX	Поддерживается	Поддерживается
Linux	Поддерживается	Поддерживается
Mac OS X	Поддерживается	Поддерживается
NovellNetware	-	Поддерживается
Open BSD	Поддерживается	Поддерживается
SCO OpenServer	Поддерживается	Поддерживается
Solaris	Поддерживается	Поддерживается
Tru64/OSF	Поддерживается	Поддерживается
Windows	-	Поддерживается

С помощью Zabbix можно осуществлять распределённый мониторинг до 10 00 узлов, где конфигурация младших узлов контролируется старшими в иерархии. Также продукт включает централизованный мониторинг лог-файлов, возможность создавать карты сетей (вручную по шаблону), выполнение запросов в различные базы данных, генерацию отчётов и тенденций, выполнение сценариев на основе мониторинга, поддержку интеллектуального интерфейса управления платформами (IPMI). Zabbix предоставляет гибкие возможности по настройке условий-триггеров, которые включаются при авариях и неполадках, и система начинает моргать лампочками (на самом деле красными квадратиками), оповещая администратора о возможной поломке. Также, при включении триггера, веб-интерфейс даже начинает попискивать на манер будильника, Zabbix достаточно самостоятелен и сможет отправить уведомление на почту, в jabber или sms с помощью gsm-модема, или даже попытаться самостоятельно поднять упавший сервис, выполнив заранее определенные действия, которые запускаются при срабатывании определенных триггеров.



Рис. 1.4 - Логическая структура сети в Zabbix

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

Автоматическое обнаружение: автоматическое обнаружение по диапазону IP-адресов, доступным сервисам и SNMP проверка;

· автоматический мониторинг обнаруженных устройств;

· автоматическое удаление отсутствующих хостов;

· распределение по группам и шаблонам в зависимости от возвращаемого результата.

В запасе у Zabbix есть еще полдесятка функций, которые позволяют еще больше упростить наблюдение за сетью, такие как мониторинг состояния веб-сайта с помощью автоматического выполнения сценария вроде имитации пользовательских действия на сайте. В итоге это одна из мощнейших и обширнейших систем мониторинга. В итоге мы получаем наиболее подходящую для наших целей систему, которую также можно использовать в качестве «скелета» к своим собственным скриптам мониторинга. Однако в очередной раз стоит отметить громоздкость сервиса, отсутствие полной документированности возможностей проекта, а также необходимость установки агентского программного обеспечения на все машины. В качестве дополнительного минуса стоит отметить сложность делегирования прав - машина с сервисом зачастую управляется операционной системой семейства *nix, что делает трудоёмким взаимодействие с доменными пользователями и правами из Active Directory (Windows системы).

1.4.3 Nagios

Nagios (первоначально Netsaint) - свободно распространяемая программа для мониторинга систем и сетей. Изначально разработана для операционных систем на базе Linux, сейчас одинаково хорошо работает также и под SunSolaris, FreeBSD, AIX и HPUX. С помощью этой программы доступны комплексное наблюдение за всей ИТ- инфраструктурой, выявление проблем сразу после их возникновения, возможность делиться полученным при наблюдении данными с заинтересованными лицами, мониторинг безопасности системы, и, как следствие, сокращение времени простоя и коммерческих потерь.

Возможности:

· мониторинг сетевых служб (SMTP, POP3, HTTP, NNTP, ICMP, SNMP);

· мониторинг состояния хостов (загрузка процессора, использование диска, системные логи) в большинстве сетевых операционных систем;

· поддержка удаленного мониторинга через шифрованные туннели SSH или SSL;

· возможность построение карт сетей (рис. 1.5);



Рис. 1.5 - Карта сети Nagios

· простая архитектура модулей расширений (плагинов) позволяет, используя любой язык программирования по выбору (Shell, C++, Perl, Python, PHP, C# и другие), легко разрабатывать свои собственные способы проверки служб;

· параллельная проверка служб;

· возможность определять иерархии хостов сети с помощью «родительских» хостов, позволяет обнаруживать и различать хосты, которые вышли из строя, и те, которые недоступны;

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

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

· автоматическая ротация лог-файлов;

· возможность организации совместной работы нескольких систем мониторинга с целью повышения надёжности и создания распределенной системы мониторинга;

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

Рис. 1.6 - Отображение хостов в Nagios

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

Простая архитектура модулей плагинов позволяет добавлять свои способы проверки служб и обработчики событий, а принцип «родительских» узлов позволяет находить зависимости между хостами. В итоге благодаря вышесказанному появляется возможность отличать узлы, которые оказались в аварийной ситуации от тех, которые недоступны системе мониторинга из-за проблем на промежуточных пунктах. Nagios обладает, как и конкуренты, огромным спектром по визуальному отображению анализа собираемых данных, таких как визуальные карты сети (рис. 1.7), комплексные отчеты, различные графики наблюдаемых параметров, многочисленные диаграммы и многое другое.

Рис. 1.7 - Карта сети в Nagios

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

definehost{

usemain A-server

host_name MainAserver

address 97.127.158.23}

define host{

usemain B-server

host_name Main Bserver

address 97.127.158.22 }

define host group{

hostgroup_name main-servers

alias Main Servers

members Main B server, Main As erver}

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

defineservice{

uselocal-service;

hostgroupsmain-servers;

service_description PING ;

check_command check_ping!100.0,20%!500.0,60%;

notifications_enabled 1 }

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

1.4.4 Cacti

Cacti - бесплатное приложение мониторинга, позволяющее собирать статические данные за определённые временные интервалы и отображать их в графическом виде при помощи RRDtool утилиты, предназначенной для работы с круговыми базами данных (RoundRobin Database), которые используются для хранения информации об изменении одной или нескольких величин за определенный промежуток времени. Стандартные шаблоны сбора включают статистику по загрузке процессора, выделению оперативной памяти, количеству запущенных процессов, использованию входящего/исходящего трафика. Cacti написан в инфраструктуре Apache-PHP-MySql, позволяет настраивать сбор и отображение данных мониторинга на основе веб-интерфейса, представленного на рис. 1.8, с юзер-френдли организацией. Есть возможность дописывания собственных агентов сбора данных

Интерфейс отображения статистики, собранной с устройств, представлен в виде дерева, структура которого задается самим пользователем. Как правило, графики группируют по определенным критериям, причем один и тот же график может присутствовать в разных ветвях дерева. Есть вариант просмотра заранее составленного набора графиков, и есть режим предпросмотра. Каждый из графиков можно рассмотреть отдельно, при этом он будет представлен за последние день, неделю, месяц и год. Возможно самому выбрать временной промежуток, за который будет сгенерирован график. Достоинства Cacti: высокая скорость развертывания при минимальном дополнительном кодировании; простота и удобство интерфейса просмотра диаграмм и их настройки. Недостатки Cacti: довольно быстрое нарастание количества однотипных настроек в случае большого числа сред и серверов; ограниченная производительность «неродных» JMX решений для Cacti; отсутствие возможности инвентаризации. Логика работы системы основана на обслуживании ряда устройств (Devices -- в терминологии Cacti). Каждое устройство -- это хост, к которому есть доступ по сети, то есть оно характеризуется IP-адресом или DNS-именем. С устройством ассоциированы хранилища данных (DataSources). Каждое такое хранилище обслуживает один график (Graph), причем на этом графике может рисоваться несколько переменных -- хранилище для них всех будет одно. Хранилище создается на основе шаблона данных (DataTemplate), который задает соответствие входных величин (полученных из SNMP- запросов или из скриптов) полям в базе данных и устанавливает дополнительные параметры хранения этих величин. Сами же входные величины получаются из методов сбора данных (DataInputMethods) или запросов (DataQueries). Первые предназначены для величин, количество которых заранее известно (например, количество процессов -- это всегда одно целое число), а вторые -- наоборот (например, статистика с сетевых интерфейсов, число которых может быть различным). График генерируется из круговой базы данных (хранилища) каждый раз заново, когда загружается страничка. Алгоритм и параметры его создания задаются шаблоном графика (GraphTemplate). Шаблоны хостов (HostTemplates) упрощают работу с однотипными устройствами и позволяют привязать определенные шаблоны графиков и запросы к данному типу хоста. Например, для маршрутизаторов Cisco -- один набор графиков, а для UNIX-серверов -- другой. Cacti позволяет завести несколько пользователей и разграничить их права как на просмотр статистики, так и на управление системой. Логика разделения доступа позволяет для каждого пользователя установить общую политику («Запретить» или «Разрешить»), а затем сделать из нее исключения. В итоге Cacti позволяет рисовать графики только основных показателей производительности, тогда как попытки мониторинга нестандартных показателей сильно снижают производительность продукта. Также проекту очень часто необходима инвентаризация (перераспределение ресурсов и планирование модернизации), а в данном пакете она отсутствует.

Рис. 1.8 - Главная страница Cacti

1.4.5 WhatsUpGold

WhatsUpGold - программа для сетевого управления и мониторинга программного обеспечения. Она осуществляет комплексное управление как физических, так и 19 виртуальных сетей, систем и приложений, позволяет наблюдать за сетью в режиме реального времени, а также имеет целый спектр функций по уведомлению и отчетам. Вся сетевая информация сохраняется в реляционную базу данных для быстрого и гибкого управления устройствами и отчетности. Используется простой протокол управления сетью (SNMP) и инструментарии управления Windows (WMI). Программа WhatsUpGold предназначена для максимального упрощения задач управления сетями и представляет собой богатое возможностями, простое в использовании и интуитивное в применении приложение, призванное облегчать жизнь сетевым администраторам. [13] Имеется возможность удаленного администрирования, в том числе и через Web. Кроме того, в наличии поддержка всевозможных отчетов по состоянию сети, а также построение графических отображений, полученных данных (рис. 1.9).

Рис. 1.9 - Главная страница WhatsUpGold

Основные свойства и возможности работы WhatsUpGold:

Обнаружение - автоматическое обнаружение всех ресурсов (сетевых устройств, систем и их взаимосвязей) и построение топографической карты подключений с использованием сетевых технологий 2/3 уровня, в том числе ARP, SNMP, ICMP, SSH, LLDP, WMI, Telnet, и т.д.

Отображение - полное отображение сети и автоматическое создание топологической карты 2/3 уровня с видимостью физических и IP-соединения, в том числе VMware и VLAN-информации.

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

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

Построение отчетов - стандартные и настраиваемые отчеты обеспечивают полный обзор состояния сетевой инфраструктуры [14]

Рис. 1.10 - Графические средства представления данных в WhatsUpGold

Среди достоинств WhatsUpGold в сравнении с конкурентами на рынке стоит отметить наличие комплексных средств мониторинга систем VMware, а также возможность интеграции с Active Directory. Главным недостатком данной системы мониторинга является ее высокая стоимость, особенно если приобретать лицензию менее, чем на 500 рабочих станций.

Она составляет 7495 долларов за 500 устройств, 2695 долларов за 100 устройств, 2195 долларов за 25 устройств. В то время как рассматриваемые в этой работе аналоги Zabbix и Nagios являются полностью бесплатными и свободными без каких-либо платных дополнений или расширений.

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



1.5 Обоснование выбора системы мониторинга

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

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

· бесплатность платформы;

· кросплатформенный агент для сбора данных;

· простота изучения;

· понятный интерфейс с возможностью графического отображения информации.



2. Программная среда разрабатываемого продукта

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

2.1 Powershell

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

В отличие от большинства оболочек, которые принимают и возвращают текст, оболочка Windows PowerShell, разработанная на основе среды CRL.NET и платформы.NET Framework, принимает и возвращает объекты.NET. Это фундаментальное изменение делает возможными совершенно новые средства и методы администрирования и конфигурирования систем Windows.

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

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

Командлет -- это команда Windows PowerShell, предназначенная для работы с объектами и выполняющая единственную функцию. Командлеты можно идентифицировать по их именам, которые составлены из глагола и существительного, разделенных дефисом (-), например, Get-Help, Get-Process и Start-Service.

В традиционных оболочках команды представляют собой исполняемые программы, которые могут быть как совсем простыми (например, attrib.exe), так и очень сложными (netsh.exe).

Большинство командлетов Windows PowerShell очень просты, и предполагается, что они будут использоваться вместе с другими командлетами. Например, командлеты категории «get» только возвращают данные, командлеты «set» только задают или изменяют значения элементов данных, командлеты «format» только форматируют данные, а командлеты «out» только направляют вывод в указанное место назначения.

Оболочка Windows PowerShell позволяет выполнять имеющиеся в Windows программы командной строки и запускать программы Windows с графическим пользовательским интерфейсом, такие как «Блокнот» и «Калькулятор». Создаваемый этими программами текст можно перехватывать и использовать в оболочке почти так же, как и при работе с Cmd.exe.

Хотя на первый взгляд это не очевидно, при работе с оболочкой Windows PowerShell на самом деле вы имеете дело с объектами.NET. По мере накопления опыта достоинства обработки объектов станут для вас более очевидными, и вы начнете даже думать «объектами».

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

Например, при возврате службы средствами оболочки Windows PowerShell на самом деле возвращается объект, представляющий соответствующую службу. При просмотре сведений о службе отображаются свойства объекта-службы. При запуске службы, то есть при изменении ее свойства Status на «started», выполняется метод объекта-службы.

Все объекты одного типа имеют одни и те же свойства и методы, однако значения свойств каждого экземпляра объекта могут быть разными. Например, каждый объект-служба имеет свойства Name и Status. Однако имя и статус одной службы могут отличаться от имени и статуса любой другой службы.

Получить сведения об объектах несложно. Чтобы узнать, объект какого типа получен командлетом, передайте результат выполнения команды «get» команде Get-Member с помощью оператора конвейерной обработки (|). Например, следующая команда передает объекты, возвращенные командой Get-Service, команде Get-Member:

get-service | get-member

Команда Get-Member отобразит сведения об объекте-службе, в том числе имя типа объекта и список его свойств и методов.

TypeName: System.ServiceProcess.ServiceController

Name MemberType Definition

Name AliasProperty Name = ServiceName

add_Disposed Method System.Void add_Disposed(EventHandler value)

Close Method System.Void Close()

Continue Method System.Void Continue()

Чтобы получить сведения о классе объекта, скопируйте и вставьте имя типа (например, System.ServiceProcess. ServiceController) в MSDN. Обнаружив нужный класс, можно просмотреть подразделы MSDN со сведениями о свойствах и методах объектов, основанных на этом классе и аналогичных объектам оболочки Windows PowerShell.

Чтобы узнать значения всех свойств конкретного объекта, передайте результат выполнения команды «get» команде Format-List или Format-Table с помощью оператора конвейерной обработки (|). Вводя при этом командлеты форматирования, укажите параметр Property со значением «все» (*). Например, чтобы просмотреть значения всех свойств службы Schedule, введите следующую команду:

get-service | get-member

В результате будут возвращены подобные данные:

TypeName: System.ServiceProcess.ServiceController

Name MemberType Definition

Name AliasProperty Name = ServiceName

add_Disposed Method System.Void add_Disposed(EventHandler value)

Close Method System.Void Close()

Continue Method System.Void Continue()

При знакомстве с оболочкой Windows PowerShell не требуется понимать все нюансы работы с объектами -- достаточно не терять из виду общую концепцию. Скоро вы сможете использовать объекты по-настоящему эффективно.

2.2 SNMP

SNMP (англ. Simple Network Management Protocol -- простой протокол управления сетью) -- это протокол управления сетями связи на основе архитектуры TCP/IP.

На основе концепции TMN в 1980--1990 гг. различными органами стандартизации был выработан ряд протоколов управления сетями передачи данных с различным спектром реализации функций TMN. К одному из типов таких протоколов управления относится SNMP. Протокол SNMP был разработан с целью проверки функционирования сетевых маршрутизаторов и мостов. Впоследствии сфера действия протокола охватила и другие сетевые устройства, такие как хабы, шлюзы, терминальные сервера, LAN Manager сервера, машины под управлением Windows NT и т.д. Кроме того, протокол допускает возможность внесения изменений в функционирование указанных устройств.

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

При использовании SNMP присутствуют управляемые и управляющие системы. В состав управляемой системы входит компонент, называемый агентом, который отправляет отчёты управляющей системе. По существу, SNMP агенты передают управленческую информацию на управляющие системы как переменные (такие как «свободная память», «имя системы», «количество работающих процессов»).

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

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

Аппаратный агент - встроенная аппаратура (с процессором и памятью), в которой хранятся программные агенты.

Переменные, доступные через SNMP, организованы в иерархии. Эти иерархии и другие метаданные (такие, как тип и описание переменной) описываются Базами Управляющей Информации (Management Information Bases (MIBs)).

На сегодня существует несколько стандартов на базы данных управляющей информации [3, 4]. Основными являются стандарты MIB-I и MIB-II, а также версия базы данных для удаленного управления RMON MIB. Кроме этого, существуют стандарты для специальных MIB устройств конкретного типа (например, MIB для концентраторов или MIB для модемов), а также частные MIB конкретных фирм-производителей оборудования.

Первоначальная спецификация MIB-I определяла только операции чтения значений переменных. Операции изменения или установки значений объекта являются частью спецификаций MIB-II.

Версия MIB-I (RFC 1156) определяет до 114 объектов, которые подразделяются на 8 групп:

1. System - общие данные об устройстве (например, идентификатор поставщика, время последней инициализации системы).

2. Interfaces - описываются параметры сетевых интерфейсов устройства (например, их количество, типы, скорости обмена, максимальный размер пакета).

3. AddressTranslationTable - описывается соответствие между сетевыми и физическими адресами (например, по протоколу ARP).

4. InternetProtocol - данные, относящиеся к протоколу IP (адреса IP-шлюзов, хостов, статистика об IP-пакетах).

5. ICMP - данные, относящиеся к протоколу обмена управляющими сообщениями ICMP.

6. TCP - данные, относящиеся к протоколу TCP (например, о TCP-соединениях).

7. UDP - данные, относящиеся к протоколу UDP (число переданных, принятых и ошибочных UPD-дейтаграмм).

8. EGP - данные, относящиеся к протоколу обмена маршрутной информацией ExteriorGatewayProtocol, используемому в сети Internet (число принятых с ошибками и без ошибок сообщений).

Из этого перечня групп переменных видно, что стандарт MIB-I разрабатывался с жесткой ориентацией на управление маршрутизаторами, поддерживающими протоколы стека TCP/IP.

SNMP помогает определить:

· загрузку каналов передачи данных свитчей и маршрутизаторов (номер порта, пропускную способность);

· параметры ИБП (пинг, напряжение, заряд аккумуляторов, состояние и режим работы и так далее);

· параметры RAID-массива или внешнего хранилища данных (вид, состояние работы, загрузку и прочее);

· параметры принтера или МФУ (пинг, количество тонера, сетевое имя), принт-сервера, телефонной станции. [16]

2.3 ZABBIX

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

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

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

2. базы данных (MySQL, PostgreSQL, SQLite или Oracle)

3. веб-интерфейса на PHP

4. агента -- демона, который запускается на отслеживаемых объектах и предоставляет данные серверу. Агент опционален, мониторинг можно производить не только с помощью него, но и по SNMP (версий 1, 2, 3), запуском внешних скриптов, выдающих данные, и несколько видов предопределенных встроенных проверок, таких как ping, запрос по http, ssh, ftp и другим протоколам, а также замер времени ответа этих сервисов.

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

Рис. 2.1 - Список узлов сети Zabbix

Узлы объединяются в группы, например, веб-сервера или сервера баз данных. Группы служат для вывода только определенных серверов при наблюдении.



Рис. 2.2 - Главная страница Zabbix

Каждый узел имеет несколько Элементов данных (items) -- параметров, за которыми ведется мониторинг. К примеру, на всех серверах у меня есть параметр ping, (он получается с помощью встроенной проверки), который равняется 1, если ответ на последний ping-запрос был получен, иначе 0. А на одном из серверов у меня есть параметр «количество пользователей онлайн», который собирается самописным скриптом из базы данных сайта. Для каждого элемента данных можно указать свой период обновления, способ хранения (сам параметр или скорость его изменения), множитель, временной интервал сбора (например, только в рабочее время). Создавать элементы данных для каждого из множества серверов -- сложно, поэтому можно создать узлы-шаблоны. Эти узлы тоже содержат элементы данных, но они не мониторятся напрямую (рис. 2.3). Вместо этого реальный хост связывается с одним или несколькими шаблонами, и все параметры шаблона автоматически наследуются хостом. Так, элемент ping у меня хранится именно в шаблоне, и я просто связываю все хосты с шаблоном template_ping.



Рис. 2.3 - Страница с последними данными Zabbix

Рис. 2.4 - Страница с измененными данными Zabbix

Человек -- не робот, и следить за тысячами параметров и думать, не выходит ли это значение за допустимые границы, просто нереально. Но и тут Zabbix предоставляет гибкие возможности по настройке условий-триггеров, которые включаются при авариях и неполадках, и система начинает моргать лампочками (на самом деле красными квадратиками) и изо всех сил пытается показать администратору, что что-то случилось. Между прочим, при включении триггера веб-интерфейс даже начинает попискивать на манер будильника, наверное, чтобы разбудить заснувших на клавиатуре наблюдателей. Так что колонки здесь, наверное, не помешают. А в упомянутом выше моем шаблоне template_ping есть и триггер, который реагирует на отсутствие пинга больше, чем на две минуты.

Рис. 2.5 - События в Zabbix

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



Рис. 2.6 - Таблица событий Zabbix

Скучно сидеть и вглядываться в квадратики и бесконечно бегающие цифры? По данным любого параметра система сможет построить график изменения, причем не за предопределенные и жестко заданные временные интервалы (вспомните mrtg/rrdtool: daily, weekly, monthly, yearly), а за любой промежуток времени с максимальным разрешением. Хотите посмотреть в деталях, как изменялась нагрузка на сервер вовремя хабраэффекта месяц назад? Пожалуйста, график с разрешением в 30 секунд (именно таков интервал опроса по умолчанию) к вашим услугам. Хотите общую картину? Выберите интервал в месяц и посмотрите на среднюю величину, и разброс колебаний до максимума и минимума. Сравнить? Можно создавать сложные графики, отображающие на одном поле несколько параметров, и вы сразу увидите, что пиковые значения LoadAverage соответствуют пикам трафика.



Рис. 2.7 - Мониторинг внешних сайтов Zabbix

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

Рис. 2.8 - Карта сети Zabbix



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

Рис. 2.9 - Карта сети с дополнениями из графиков Zabbix

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

...