Главная Случайная страница


Категории:

ДомЗдоровьеЗоологияИнформатикаИскусствоИскусствоКомпьютерыКулинарияМаркетингМатематикаМедицинаМенеджментОбразованиеПедагогикаПитомцыПрограммированиеПроизводствоПромышленностьПсихологияРазноеРелигияСоциологияСпортСтатистикаТранспортФизикаФилософияФинансыХимияХоббиЭкологияЭкономикаЭлектроника






Глава 1. Исследование и анализ существующих систем мониторинга ИТ-инфраструктуры

ВВЕДЕНИЕ

В настоящее время ИТ­ресурсы становятся все более доступными.

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

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

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

Поэтому исследование и моделирование систем мониторинга ИТ-инфраструктуры предприятия является актуальной темой.


 

Глава 1. Исследование и анализ существующих систем мониторинга ИТ-инфраструктуры

Сравнительный анализ выбранных систем мониторинга систем мониторинга ИТ-инфраструктуры

Система Microsoft SCOM

System Center Operations Manager – система сквозного мониторинга от 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-разрядной платформы, Red Hat 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 (для безопасного обслуживания агента).

 

Рисунок 1 - Настрока визуального представления панели SCOM

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

Однако у данной системы есть ряд недостатков с точки зрения решения конкретной технической задачи:

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

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

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

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

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

Также существенный недостаток системы состоит в высокой стоимости данного программного продукта.

Система 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, для запуска требует наличия веб-сервера, представлен на рисунке 2.

Рисунок 2 - Веб-интерфейс мониторинга Zabbix

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

Таблица 1 - Поддерживаемые платформы

Платформа ZABBIX-сервер ZABBIX-агент
AIX Поддерживается Поддерживается
FreeBSD Поддерживается Поддерживается
HP-UX Поддерживается Поддерживается
Linux Поддерживается Поддерживается
Mac OS X Поддерживается Поддерживается
Novell Netware - Поддерживается
Open BSD Поддерживается Поддерживается

 

Платформа ZABBIX-сервер ZABBIX-агент
SCO Open Server Поддерживается Поддерживается
Solaris Поддерживается Поддерживается
Tru64/OSF Поддерживается Поддерживается
Windows NT 4.0, Windows 2000, Windows 2003, Windows XP, Windows Vista - Поддерживается

 

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

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

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

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

Рисунок 3 - Карты сетей в Zabbix

 

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

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

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

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

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

 

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

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

В качестве дополнительного минуса стоит отметить сложность делегирования прав – машина с сервисом зачастую управляется операционной системой семейства *nix, что делает трудоёмким взаимодействие с доменными пользователями и правами из Active Directory (Windows системы).

Система Nagios

Nagios (первоначально Netsaint) – свободно распространяемая программа для мониторинга систем и сетей. Изначально разработана для операционных систем на базе

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

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

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

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

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

Ø возможность построение карт сетей (пример на рисунке 4);

Рисунок 4 - Карта сети в Nagios

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

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

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

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

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

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

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

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

Отказом от использования системы послужить следующие причины:

Ø «общий» характер мониторинга показателей;

Ø проблема взаимодействия с серверами под управлением Windows;

Ø «сетевая» направленность мониторинга;

 

Система Cacti

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

Cacti написан в инфраструктуре Apache-PHP-MySql, позволяет настраивать сбор и отображение данных мониторинга на основе веб-интерфейса, представленного на рисунке 5, с юзер-френдли организацией. Есть возможность дописывания собственных агентов сбора данных.

Рисунок 5 - Интерфейс Cacti

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

Достоинства Cacti:

Ø высокая скорость развертывания при минимальном дополнительном кодировании;

Ø простота и удобство интерфейса просмотра диаграмм и их настройки.

Недостатки Cacti:

Ø довольно быстрое нарастание количества однотипных настроек в случае большого числа сред и серверов;

Ø ограниченная производительность «неродных» JMX решений для Cacti;

Ø отсутствие возможности инвентаризации.

Логика работы системы основана на обслуживании ряда устройств (Devices — в терминологии Cacti). Каждое устройство — это хост, к которому есть доступ по сети, то есть оно характеризуется IP-адресом или DNS-именем. С устройством ассоциированы хранилища данных (Data Sources). Каждое такое хранилище обслуживает один график (Graph), причем на этом графике может рисоваться несколько переменных — хранилище для них всех будет одно. Хранилище создается на основе шаблона данных (Data Template), который задает соответствие входных величин (полученных из SNMPзапросов или из скриптов) полям в базе данных и устанавливает дополнительные параметры хранения этих величин. Сами же входные величины получаются из методов сбора данных (Data Input Methods) или запросов (Data Queries). Первые предназначены для величин, количество которых заранее известно (например, количество процессов — это всегда одно целое число), а вторые — наоборот (например, статистика с сетевых интерфейсов, число которых может быть различным). График генерируется из круговой базы данных (хранилища) каждый раз заново, когда загружается страничка. Алгоритм и параметры его создания задаются шаблоном графика (Graph Template). Шаблоны хостов (Host Templates) упрощают работу с однотипными устройствами и позволяют привязать определенные шаблоны графиков и запросы к данному типу хоста. Например, для маршрутизаторов Cisco — один набор графиков, а для UNIX-серверов — другой.

Cacti позволяет завести несколько пользователей и разграничить их права как на просмотр статистики, так и на управление системой. Логика разделения доступа позволяет для каждого пользователя установить общую политику («Запретить» или «Разрешить»), а затем сделать из нее исключения.

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

 

1.2.5. Сравнительный анализ свободно распространяемых систем

Таблицы 2,3,4 позволяют оценить функционал существующих свободно распространяемых систем комплексного мониторинга ИТ-инфраструктуры.

Таблица 2 – Функционал свободно распространяемых систем мониторинга

Название Диаграммы Отчёты SLA Логическая группировка События Прогнозирование событий
Cacti Да Да Да Да Да
Nagios Да Через плагин Да Да Нет
Zabbix Да Да Да Да Да
Microsoft SCOM Да Через плагин Да Да Да

 


 

Таблица 3 - Функционал свободно распространемых систем мониторинга

Название Автоматическое обнаружение Агент SNMP Syslog Внешние скрипты
Cacti Через плагин Нет Да Через плагин Да
Nagios Через плагин Да Через плагин Через плагин Да
Zabbix Да Поддерживается Да Да Да
Microsoft SCOM Нет Да Да Нет Да

Таблица 4 - Функционал свободно распространяемых систем мониторинга

Название Плагины Сложность создания плагинов Триггеры / Тревоги Инвентаризация Карты
Cacti Да Средний Да Нет Через плагин (Weathermap)
Nagios Да Лёгкий Да Через плагин Динамические и настраиваемые
Zabbix Да Лёгкий Да Через плагин Да
Microsoft SCOM Да Средний Да Нет Нет

Исходя из таблицы 2, 3, 4 все эти системы предоставляют примерно одинаковые минимальные базовые функционалы, такие как:

Ø Мониторинг сети

Ø Группировка устройств

Ø Автоматическое обнаружения

Ø Гибкое конфигурирование

Ø Визуализация данных и доступ через web-интерфейс

Ø События и реакция на них в виде оповещений и выполнения команд

Ø Возможность расширения существующей функциональности через плагины

Ø Хранения конфигурации и истории мониторинга в БД

Ø Создание карт сети и управление доступом

1.3 Выводы по первой главе:

1. Система мониторинга Cacti предназначена для малых предприятии с меньшим количеством узлов.

2. Система мониторинга Microsoft SCOM по количеству узлов, как и система Cacti от 150-500 единиц. Система мониторинга Microsoft SCOM плохо интегрируется с linux подобными операционными системами

3. Система мониторинга Zabbix мощная система для мониторинга крупных предприятии. Количество узлов может быть до 10 000 единиц.

4. Система мониторинга Nagios на сегодняшний день является самой мощной системой мониторинга.

Для работы с системой нужен опытный специалист.


 

Введение

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

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

Zabbix состоит из:

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

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

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

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

 

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


Рис. 2.2.1

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

 


Рис 2.2.2

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

 

Рис. 2.2.3

Создавать элементы данных для каждого из множества серверов — сложно, поэтому можно создать узлы-шаблоны. Эти узлы тоже содержат элементы данных, но они не мониторятся напрямую. Вместо этого реальный хост связывается с одним или несколькими шаблонами, и все параметры шаблона автоматически наследуются хостом. Так, элемент ping хранится именно в шаблоне, и можно просто связывать все хосты с шаблоном template_ping.

Рис. 2.2.4

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

Рис. 2.2.5

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


Рис. 2.2.6

По данным любого параметра система сможет построить график изменения, причем не за предопределенные и жестко заданные временные интервалы а за любой промежуток времени с максимальным разрешением. Хотите посмотреть в деталях, как изменялась нагрузка на сервер во время хабраэффекта месяц назад? Пожалуйста, график с разрешением в 30 секунд(именно таков интервал опроса по умолчанию) к вашим услугам. Хотите общую картину? Выберите интервал в месяц и посмотрите на среднюю величину, и разброс колебаний до максимума и минимума. Можно создавать сложные графики, отображающие на одном поле несколько параметров, и вы сразу увидите, что пиковые значения Load Average соответствуют пикам трафика.


Рис. 2.2.7

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

Рис. 2.2.8

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


Рис. 2.2.9

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

Элементы данных

Контролируемые объекты называются узлами или хостами. Их можно группировать. Узел может входить в несколько групп. Профиль (profile) узла - набор сведений для инвентаризации о типе оборудования, модели, расположении, серийном номере и прочие. Заполняется вручную. Каждый контролируемый параметр узла называется элементом данных (ЭД). Текущее значение элементов данных опрашивается в дискретные моменты времени с заданным интервалом. Система позволяет посмотреть очередь невыполненных запросов (меню администратора).

Если нам понадобиться мониторить с нескольких узлов один и тот же параметр, то удобнее их группировать (Рис 2.3.2).

Рис 2.3.2 Схема группировки элементов данных

Триггер (trigger) задаётся с помощью логического выражения от значений элементов данных. Приложение (application) есть множество элементов данных узла, связанных с одним реальным приложением. Элемент данных может входит в несколько приложений. Используется для группировки в веб-интерфейсе и выражениях триггеров. Событием (event) называется изменение состояния триггера от FALSE к TRUE или от TRUE к FALSE (возможно с промежуточным состоянием UNKNOWN). Действие (action) является реакцией системы на событие. Определяется для события или группы событий.

Реализован распределённый мониторинг. Главный узел конфигурирует подчинённые и собирает с них данные.

Каждый контролируемый параметр узла называется элементом данных (item). Данные могут собираться сервером напрямую (простые проверки, SNMP, IPMI), внешними скриптами и с помощью агентов (клиентов zabbix), работающими на контролируемых серверах. Агенты могут собирать данные встроенными средствами и с помощью скриптов. Веб-мониторинг позволяет извлекать данные с HTML страниц (специальный модуль). Имеется некоторое количество внутренних проверок работоспособности самого сервера zabbix и агрегированные проверки. Некоторые типы (key) элементов данных могут иметь параметры, заключаемые в квадратные скобки. Часть параметров является необязательной. Не все типы элементов данных поддерживаются на всех типах ОС. При добавлении элемента данных в общем случае указывается

· описание, может содержать макросы: $N - N-ый параметр элемента данных

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

· тип данных

o целое 64 бита без знака (u)

o плавающее число (d)

o строка до 255 байт (s, Latin1?)

o текст неограниченной длины (t)

o журнал (m) - специальная модификация текста для хранения журналов

· основание счисления для целых чисел (десятичное, восьмеричное или шестнадцатеричное)

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

o b или bps

o unixtime (секунды абсолютные, выводится в формате yyyy.mm.dd hh:mm:ss)

o uptime (секунды относительные, выводится в формате N days, hh:mm:dd)

o s (секунды относительные, выводится в формате YYyMMmDDdHHhMMm)

· на сколько надо умножать входные данные

· интервал опроса (в секундах)

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

· время хранения данных (в сутках)

· время хранения суммированных данных (трендов, ежечасные max, min и avg)

· активировать или нет (может быть переведён в состояние неподдерживаемого)

· что хранить (полученные данные, изменения между измерениями, изменения за секунду)

· данных

Специальный тип данных "status", который определяется, если для узла мониторится хотя бы один параметр (0 - узел доступен, 2 - узел недоступен).

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

UserParameter=уникальное-имя-типа-данных,незакавыченная команда оболочки с параметрами

Команда может иметь позиционные параметры (при использовании указываются в квадратных скобках, так же как и для встроенных типов данных):

UserParameter=уникальное-имя-типа-данных[*],команда оболочки с использованием $1 - $10

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

· tcp|ftp|http|imap|nntp|pop|smtp|ssh,ip-адрес,порт (0 - соединение не принято, 1 - соединение принято, 2 - время ожидания истекло)

· ftp_perf|http_perf|imap_perf|nntp_perf|pop_perf|smtp_perf|ssh_perf,ip-адрес,порт (0 - сервер недоступен, иначе число милисекунд, потраченных на соединение)

· icmpping (0 - неудача, 1 - успех)

· icmppingsec (время оборота)

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

· описание

· тип агента (SNMPv1, SNMPv2 или SNMPv3)

· SNMP комьюнити для чтения

· OID (рекомендуется в числовом виде); возможен динамический поиск OID в формате (от такого поиска некоторые устройства со слабым CPU могут умереть):

· базовая-часть-OID["index","базовая часть OID, в которой будет вестись поиск","строка поиска"]

· ifInOctets["index","ifDescr","GigabitEthernet0/1"]

· порт (по умолчанию 161)

· тип (key), под которым этот OID будет известен (можно сам OID)

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

имя-скрипта[строка параметров]

Внутренние самопроверки сервера:

· zabbix[boottime] (время в формате UNIX)

· zabbix[items] (количество элементов данных в БД)

· zabbix[items_unsupported]

· zabbix[queue] (необработанных заданий в очереди)

· zabbix[triggers] (количество триггеров в БД)

· zabbix[uptime] (время жизни процесса zabbix_server)

Триггеры

Триггер (trigger) задаётся с помощью логического выражения от значений единиц данных и может принимать значения FALSE, TRUE и UNKNOWN. Есть традиция определять триггеры так, чтобы значение TRUE указывало на наличие проблемы. Выражение перевычисляется каждый раз при получении очередного значения единицы данных, используемой в выражении. Выражения строятся с использованием бинарных операторов и функций над элементами данных, а также констант (числа и числа с двоичными множителями (K, M, G)). Для задания приоритета вычислений необходимо использовать круглые скобки. Синтаксис извлечения значения элемента данных:

{имя-хоста:имя-типа-элемента-данных.имя-функции(параметры)}

Операторы (перечислены в порядке убывания приоритета, преобразование типов - ?):

· /

· *

· -

· +

· <

· >

· # (приближённо не равно)

· = (приближённо равно)

· &

· |

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

· abschange (абсолютная разница между последним и предпоследним значением; для строк: 0 - значения равны, 1 - не равны)

· avg (среднее значение за указанный интервал в секундах или за указанное количество отсчётов (число предваряется символом '#'))

· delta (разность между максимумом и минимумом за указанный интервал в секундах или за указанное количество отсчётов (число предваряется символом '#'))

· change (разница между последним и предпоследним значением; для строк: 0 - значения равны, 1 - не равны)

· date (дата в формате YYYYMMDD)

· dayofweek (1 - понедельник, 7 - воскресенье)

· diff (0 - последнее и предпоследнее значения равны; 1 - различаются)

· fuzzytime (1 - временной штамп элемента данных различается от времени сервера не более указанного числа секунд)

· max (максимум за указанный интервал в секундах или за указанное количество отсчётов (число предваряется символом '#'))

· min (минимум за указанный интервал в секундах или за указанное количество отсчётов (число предваряется символом '#'))

· nodata (1 - если за указанное число секунд не было полученно данных; нельзя указывать менее 30 секунд)

· now (время в формате UNIX)

· prev (предпоследнее значение; last (#2))

· regexp (1 - указанное в качестве первого параметра регулярное выражение соответствует значению элемента данных за указанный интервал в секундах или за указанное количество отсчётов (число предваряется символом '#'); с учётом регистра символов)

· sum (сумма значений за указанный интервал в секундах или за указанное количество отсчётов (число предваряется символом '#'))

· time (текущее время в формате HHMMSS)

Триггер может зависеть от других триггеров, т.е. он не меняет своё состояние в соответствии со значением выражения, а событие не генерируется, есл<

Последнее изменение этой страницы: 2016-08-28

lectmania.ru. Все права принадлежат авторам данных материалов. В случае нарушения авторского права напишите нам сюда...