Русский
Русский
English
Статистика
Реклама

Zabbix мониторинг

Внедрение Zabbix в системы комплексного мониторинга. Опыт компании КРОК

26.08.2020 10:09:33 | Автор: admin

image
Валентин Нык, Руководитель отдела систем управления ИТ-инфраструктурой, КРОК


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


Проблема


Крупные компании давно используют разные СКМ. Однако пользоваться ими стало невыгодно. Ниже расскажем, почему.


После кризиса в 2014 г. курсы валют выросли примерно в два раза. Автоматически подорожали и промышленные решения. Поэтому компании пытаются оптимизировать решения или модель владения ими.


Иностранные разработки не ориентированы на российский рынок. Клиенты из России в среднем занимают 1% от глобального рынка. Поэтому разработчики неохотно решают их проблемы.


В стране действуют санкции, а государство ведёт политику импортозамещения. Из-за этого бизнесу труднее использовать иностранное ПО.


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

Валентин Нык, руководитель отдела систем управления ИТ-инфраструктурой ДИТ

Задача


Чтобы решить проблему, нужно разработать СКМ на альтернативном стеке решений. Такой стек может включать в себя СПО, решения с открытым исходным кодом и собственные разработки.


Требования к СКМ


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


Решение


При создании СКМ в КРОК опирались на накопленный опыт. Концептуальная архитектура СКМ в целом повторяет промышленные решения иностранных вендоров и состоит из трех основных уровней:


  1. сбор данных,


  2. анализ данных,


  3. представление результатов мониторинга.




Архитектура СКМ


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


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


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


С помощью Zabbix компания КРОК создала СКМ, которая:


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

Где ещё можно использовать Zabbix


Ниже представлены кейсы компании КРОК, в которых использована система Zabbix.


  • Zabbix и SOC**.** По статистике, основной источник событий, связанных с информационной безопасностью, события из ИТ-инфраструктуры. Если интегрировать SOC с Zabbix, то система мониторинга станет источником этих событий для SOC. Такая интеграция позволяет принимать взвешенные решения по отработке инцидентов ИБ.
  • Zabbix и система управления. Любую систему управления можно сделать более гибкой. Для этого нужны данные интеллектуального мониторинга. Система проанализирует их и будет принимать решения, которые учитывают реальную ситуацию в ИТ-инфраструктуре.
  • Zabbix и управление мощностями. Развивающемуся бизнесу часто требуются новые мощности. Покупать дополнительное оборудование и софт дорого. Выгоднее оптимизировать те, что уже есть.

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


  • Мониторинг как услуга. В России начинают развиваться management services, платные услуги ИТ-компаний для бизнеса. Мониторинг тоже можно продавать в качестве такой услуги. В этом случае Zabbix будет отличным источником данных для расчёта стоимости владения, оказания платных ИТ-услуг.

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




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


Штаб-квартира: Россия, Москва
Количество сотрудников: 1 777
Дата основания: 1992 г.

Подробнее..

Zabbix Summit 2020 пройдёт онлайн

03.09.2020 10:04:27 | Автор: admin

image


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


Программа


Программа Zabbix Summit Online 2020 будет в основном посвящена релизу Zabbix 5.2 (ожидается, что он будет анонсирован до начала мероприятия). Команда инженеров Zabbix охватит множество технических тем, а также расскажет о возможностях нового релиза. Традиционно, с докладами выступят эксперты Zabbix со всего мира и поделятся самыми интересными и сложными случаями применения Zabbix.


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


Как все будет происходить


В отличие от обычного двухдневного мероприятия, в этом году саммит пройдет в течение одного дня и таким образом, что в нем смогут принять участие гости со всего мира.
Мы начнем с докладов команды и членов сообщества Zabbix из Японии, когда в европейской части земного шара будет раннее утро. Следующим присоединится китайское представительство Zabbix и продемонстрирует интересные кейсы использования, реализованные экспертами Zabbix в этом регионе. Третий блок саммита будет наиболее продолжительным. Он объединит выступления представителей Европы и России. Во время этой части саммита выступят также исполнительный директор Zabbix Алексей Владышев и технические инженеры Zabbix. После европейского сегмента саммит продолжится выступлениями докладчиков из Бразилии. А заключительная секция будет посвящена США. Посетители получат возможность ознакомиться с интересными примерами использования Zabbix местными компаниями и лично обсудить с местными экспертами насущные вопросы.


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


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


Что еще вы должны знать


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


  • Став спонсором мероприятия
  • Приобретая пакет фаната Zabbix

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


Возможности участия


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


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


Присоединяйтесь к Zabbix Summit Online 2020 и узнайте о лучших мировых практиках применения Zabbix в прямом эфире.

Подробнее..

Низкоуровневое обнаружение (LLD) в Zabbix через SQL-запросы

16.11.2020 14:12:10 | Автор: admin


Привет, Хабр! В этой статье поделюсь полезным подходом мониторинга в Zabbix через обнаружение элементов данных в ответе на SQL-запрос. Этот тип мониторинга обычно используется в бизнес-мониторинге, когда собираются показатели производительности бизнес-процесса: количество пользователей, транзакций или выполняется контроль статуса операций. В целом, это универсальный подход, про который администраторы Zabbix иногда забывают. А он есть. Добро пожаловать под кат.

Что будем делать в этой статье:

  • Клонируем репозиторий pg_stat_monitor от Percona и соберём этот плагин из исходников;
  • Добавим плагин pg_stat_monitor в БД PostgreSQL, на которой работает Zabbix;
  • Создадим шаблон для выполнения SQL-запроса в pg_stat_monitor;
  • Создадим правило низкоуровневого обнаружения для разбора ответа от SQL-запрос;
  • Создадим зависимые прототипы элементов данных для мониторинга некоторых характеристик производительности БД.

На сервере предварительно уже установлен Zabbix 5.2, работающий на PostgreSQL 12.

Установка и настройка плагина pg_stat_monitor для PostgreSQL


Pg_stat_monitor плагин для сбора статистики от Percona, основанный на pg_stat_statements. Можно сказать, что pg_stat_monitor это pg_stat_statements на стероидах. Основной недостаток pg_stat_statements отсутствие агрегированной статистики (и гистограмм в т.ч.) по накопленным запросам и статистике по ним. Соответственно, pg_stat_monitor лишен такого недостатка. Объём статистики, которая может собираться, настраивается в конфигурации плагина. Работает плагин следующим образом:

  • собирается статистика и объединяется в корзину (агрегат);
  • корзина собирается и хранится заданный период времени;
  • когда время истекает, pg_stat_monitor сбрасывает всю накопленную статистику и начинает собирать её заново.

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

Исходный код плагина доступен в репозитории Percona на Github. Мы его оттуда клонируем, соберём на тестовом сервере и подключим к имеющемуся инстансу PostgreSQL.

Листинг установки плагина
# dnf -y install gcc git libpq-devel postgresql-server-devel # cd /tmp# git clone git://github.com/Percona/pg_stat_monitor.git# cd pg_stat_monitor# make USE_PGXS=1# make USE_PGXS=1 install# sudo -i -u postgres psql# postgres=# alter system set shared_preload_libraries=pg_stat_monitor;# postgres=# \q# systemctl restart postgresql# sudo -i -u postgres psql# postgres=# create extension pg_stat_monitor;# postgres=# \q


После установки можно убедиться, что всё работает и спросить у плагина его настройки:



Ещё можно спросить, что он вообще может показать:



Некоторые из данных со скриншота выше мы будет потом забирать в Zabbix.

Создание шаблона в Zabbix для работы с БД по ODBC


Теперь установим на сервер с БД драйвер ODBC:

# dnf -y install postgresql-odbc

И проверим как там называется драйвер:



Теперь можно перейти в Zabbix, добавить некоторые макросы:



И создать мастер-элемент данных, из которого потом будут разбирать всё необходимое зависимые элементы:



В результате получим вывод в формате JSON:



Создание LLD-правила и прототипов элементов данных


На следующем шаге добавим к шаблону правило дискаверинга:



Добавим LLD-макрос для создания новых объектов по полю queryid:



Создаём один из прототипов элементов данных:



И шаги препроцессинга:



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



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



Некоторые из запросов окрашены в серый, потому что queryid с ними более не обнаруживаются. Можно настроить минимальное время хранения таких объектов и удалять их сразу после отправки оповещения о длительном SQL-запросе.

Заключение


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

А ещё можно почитать:

Zabbix под замком: включаем опции безопасности компонентов Zabbix для доступа изнутри и снаружи

Добавляем CMDB и географическую карту к Zabbix

Структурированная система мониторинга на бесплатных решениях

Мониторинг принтеров в Zabbix

Как сократить объем дискового пространства, занимаемого БД Zabbix

Как снизить количество шумовых событий в Zabbix
Подробнее..

Мониторинг с высокой доступностью. Опыт компании СберСервис

05.01.2021 16:09:52 | Автор: admin

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

О чем эта статья?

Как следует из названия, в статье предлагается концепция организации мониторинга с высокой доступностью. В роли подопытного выступает Zabbix Server, для организации Active-Active кластера применяется Corosync и Pacemaker, а работает это всё на Linux. Данное ПО является OpenSource, поэтому такое решение доступно каждому.

В процессе эксплуатации Zabbix для мониторинга высоконагруженной ИТ-инфраструктуры (рост количества элементов данных, рост числа узлов сети, большая глубина хранения сырых данных, постоянно растущие потребности пользователей) многие сталкиваются с проблемами производительности сервера Zabbix во время старта или перезапуска. В условиях High Load (>60k NVPS) обычная перезагрузка сервера Zabbix превращается в весьма длительную, хотя и штатную процедуру. Время от запуска службы до появления данных в мониторинге может достигать 15-20 минут.

Столкнувшись с этим, и проанализировав ситуацию, команда мониторинга пришла к решению, что поможет кластеризация по принципу Active-Active. Кроме того, была поставлена цель добиться Disaster Recovery путем переноса на разные ЦОДы.

Задача

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

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

Требования

При создании кластера необходимо учесть два важных критерия:

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

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

Встроенный функционал схемы кластеризации ресурсов в режиме Active-Passive с использованием Pacemaker и Corosync рассматривался уже много раз и в частности на Хабре естьподробная статьядля случая кластеризации БД истатья про кластеризацию Заббикса(вместо Corosync использовался cman, но смысл тот же).

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

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

Полученное решение реализует два важных для системы мониторинга свойства:

  • Непрерывность мониторинга

  • Отказоустойчивость мониторинга

Рассмотрим реализацию решения High Available ZabbixServer в режиме Active-Active без LoadBalancerПринципиальная схема взаимодействия компонентов:

Принцип работы

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

В кластере существует 2 ноды. При подготовке нод следует учитывать свойства stonith и quorum их необходимо отключить.
Свойство quorum применяется для схемы кластера от 3х нод и более. Если в схеме кластера, состоящего из 2х нод использовать данное свойство, тогда при падении одной ноды произойдёт выключение всех ресурсов.

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

ocf::heartbeat:ZBX-IPaddressocf::heartbeat:ZBX-Instance

При аварийном выходе из строя основной ноды, кластерные ресурсы перемещаются на резервную ноду. Ресурс ZBX-IPaddress управляет виртуальным ip-адресом и входит в стандартный набор кластерных ресурсов (IPaddr2). ZBX-Instance самописный кластерный ресурс для сервиса zabbix-server и управления подключениями к БД. На каждом Zabbix-сервере в конфигурационном файле прописаны разные пользователи БД, при этом, в любой момент времени пользователь основного Zabbix-сервера имеет права Read/Write, а пользователь резервного права ReadOnly, поэтому на обеих нодах служба zabbix-server может находиться в запущенном состоянии (привет, Active-Active).

Перевод кластерных ресурсов в случае сбоя выглядит следующим образом. Ресурс ZBX-IP-address переводит виртуальный IP-адрес на другую ноду, а ресурс ZBX-Instance переводит пользователя БД резервного zabbix-сервера в режим Read/Write, а пользователя БД основного zabbix-сервера в режим ReadOnly, при этом закрывая имеющиеся к БД старые сессии подключения. Таким образом мониторинг инфраструктуры не прекращается. Непрерывность записи информации достигается за счет буферизации снятых метрик с объектов мониторинга на стороне ZabbixProxy. После того как прокси получает подключение к серверу, он передает накопленные данные.

Важный нюанс применение данной схемы подходит только в случае нахождения master и slave ZabbixServer-нод в одной подсети.

Рассмотрим реализацию решения High Available ZabbixServer в режиме Active-Active с LoadBalancer

Принципиальная схема взаимодействия компонентов:

Принцип работы

Решение с применением аппаратной балансировки сетевой нагрузки на основе сигнального порта выглядит следующим образом. Аппаратный балансировщик нагрузки отправляет трафик на ноду, на которой доступен сигнальный порт, если порт доступен на обеих нодах, LoadBalancer не будет отправлять трафик на какую-либо из нод. Решение можно использовать, когда ноды кластера находятся в разных подсетях, что позволило развернуть высокодоступный кластер для работы в географически распределенном ЦОД.

В Pacemaker создаются кластерные ресурсы:

ocf::heartbeat:ZBX-Cluster-Socketocf::heartbeat:ZBX-Instance

Ресурс ZBX-Cluster-Socket управляет сигнальным портом на ноде нужен для работы LoadBalancer-а.

Ресурс ZBX-Instance управляет процессом zabbix-server-а и правами доступа к БД.

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

Ресурс ZBX-Cluster-Socket создаётся с помощью встроенной в Pacemaker функциональности по созданию ресурсов из системного процесса (службы). Служба сигнального порта обыкновенная самописная служба, которая просто открывает на хосте соответствующий порт, за состоянием которого будет наблюдать LoadBalancer. Осуществлена привязка ресурса ZBX-Cluster-Socket к ресурсу ZBX-Instance посредством ограничения (constraint) для того, чтобы кластерные ресурсы перемещались совместно. Corosync, управляя ресурсом ZBX-Cluster-Socket, поддерживает в открытом состоянии только порт 101 на основной Master-node и в закрытом состоянии порт 201 на резервной Slave-node. Для LoadBalancer сигналом на переключение/отправку трафика являются: открытый порт 101 на первой ноде или открытый порт 201 на второй ноде, если оба порта на обеих нодах открыты, или оба закрыты, трафик никуда не отправляется.

Переключение ресурсов с текущей Master-node на текущую Slave-node происходит следующим образом:

При падении Master-node, порт 101 становится недоступным, тогда сигналом для LoadBalancer на переключение трафика будет являться открытый порт 201 на Slave-node. Corosync, определив, что Master-node недоступна, переключает ресурсы ZBX-Instance и ZBX-Cluster-Socket вместе на Slave-node, а благодаря скрипту resource_movement, на основе которого Pacemaker создал ресурс ZBX-Instance происходит смена прав пользователей User_A и User_B в базе данных, при этом закрываются все старые сессии подключения к БД.

Что произойдет в случае потери связности между нодами кластера при условии полной работоспособности нод?

Схема та же: кластер состоит из 2-х нод Master-node (пользователь User_A) и Slave-node (User_B), на Master-node запущены кластерные ресурсы.

При потере связи каждая из нод определит, что другая нода недоступна, тогда обе запустят у себя кластерные ресурсы. Master-node перезапускать ничего не будет и продолжит работу, определяя свою роль главной. Slave-node тоже посчитает себя главной и запустит у себя кластерные ресурсы. При этом LoadBalancer определит, что на Master-node и Slave-node доступны порты ZabbixServer и управляющий порт, соответственно LoadBalancer прекратит передачу сетевого трафика.

Следует отметить важный момент какими будут права доступа к базе данных соответствующих пользователей? Одна из нод по-прежнему будет иметь доступ к БД с правами Read/Write, а другая с правами ReadOnly, так как:

  • Если связь Slave-node с БД не была потеряна, то Slave-node во время включения у себя кластерных ресурсов произведет смену прав пользователей: для User_A права изменятся на ReadOnly, а для User_B права изменятся на Read/Write.

  • Если связь Slave-node с БД потеряна, следовательно Slave-node не сможет выполнить переключение прав пользователей.

  • После восстановления связности кластерные ресурсы снова переместятся на Master-node, LoadBalancer определит, что управляющий порт доступен только на Master-node и начнёт передавать ей сетевой трафик.

Заключение

Данный кейс иллюстрирует принципиальную идею и концепцию придуманного решения (а точнее 2-х реализаций), и не является прямым руководством к действию. Инфраструктуры и ограничения у всех разные, а инженеры, перед которыми ставятся похожие задачи не нуждаются в How to.

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

Подробнее..

Зонтичная Grafana скрещиваем Zabbix и Microsoft SCOM

18.03.2021 18:13:59 | Автор: admin
Если у вас есть Grafana и несколько систем мониторинга, то почему бы не визуализировать все имеющиеся данные и статусы в едином интерфейсе?

image

Покажем на примере нашего тестового стенда как скрестить Zabbix и SCOM в единой Grafana и сделать сервисный мониторинг (с точки зрения здоровья сервисов). Подробности и скриншоты под катом.

На скриншоте ниже информационные системы компании. Здесь электронная почта, DNS, Active Directory, Sharepoint и другие. Каждый квадрат это агрегированный статус информационной системы. Ниже мы покажем за счет чего так получается. Обращаем внимание, что различные системы могут быт охвачены различными системами мониторинга. В нашем случае это Zabbix и SCOM.

image

Начнём c Zabbix. Там есть возможность создавать группы узлов. Каждому узлу соответствует набор триггеров. Что мы делаем дальше? Ищем наихудший статус триггера на узле и отдаём его значение в специальный элемент данных. Следом проводим аналогичное действие по агрегированию наихудшего статуса триггера для группы узлов и получаем агрегированный статус здоровья группы.

image

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

image

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

Интеграция Grafana со SCOM реализована при помощи SQL-запросов в базы OperationsManager и OperationsManagerDW. Первая для кратковременного хранения, вторая для долговременного. При помощи SQL-запроса получим список узлов, которые находятся на мониторинге в SCOM.

image

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

image

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

image

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

image

Ещё можно использовать вот такое представление с событиями одновременно для Zabbix и Microsoft SCOM.

image

Спасибо за внимание! Надеюсь, было интересно.

А ещё у нас есть:

Описание комплексного решения по мониторингу на открытых системах

Zabbix под замком: включаем опции безопасности компонентов Zabbix для доступа изнутри и снаружи

Добавляем CMDB и географическую карту к Zabbix


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

Zabbix OPC DA

25.05.2021 00:13:35 | Автор: admin

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

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

Для чего нам Zabbix

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

Взаимодействие с OPC серверами

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

Установка OpenOPC

Как было сказано ранее, речь идет о стандарте OPC DA, а значит, о технологии DCOM и, соответственно, ОС Windows. В нашем случае установка OpenOPC производилась на машину с Windows XP, где и находится проприетарный OPC сервер. После завершения установки необходимо добавить путь до opc.exe в системную переменную среды PATH.

Проверим работу утилиты. Для начала выведем в консоль список доступных OPC серверов:

C:\Users\Администратор> opc.exe -qMerz.OPC_SAIA_S-BUS.1C:\Users\Администратор>

Теперь попробуем получить теги в удобном нам формате - csv:

C:\Users\Администратор>opc.exe -o csv -s Merz.OPC_SAIA_S-BUS.1 ATP.Register.OAT ATP.Register.OAT,197,Good,05/24/21 07:16:15C:\Users\Администратор>opc.exe -o csv -s Merz.OPC_SAIA_S-BUS.1 ATP.Register.OAT ATP5.Register.T_inlet ATP5.Register.T_outletATP.Register.OAT,198,Good,05/24/21 07:16:41ATP5.Register.T_inlet,627,Good,05/24/21 07:16:41ATP5.Register.T_outlet,654,Good,05/24/21 07:16:41C:\Users\Администратор>

Если что-то пошло не так

В ходе экспериментов с opc.exe выяснились некоторые моменты. Первое: каждый OPC клиент запускал новую копию OPC сервера, а их параллельная работа невозможна. Так как запустить используемый нами OPC сервер как службу не получилось, то через DCOM был настроен запуск OPC сервера от определенного пользователя. Все OPC клиенты - SCADA и агент Zabbix - были также настроены на запуск от этого пользователя. Второе: выявлены некоторые недостатки в работе самого OpenOPC. Например, клиент не вычитывает теги, в названии которых присутствуют символы, отличающиеся от латинских. С этим пока пришлось смириться и решать такие проблемы путем переименования тегов в OPC сервере.

Установка Zabbix агента

На ту же машину установим Zabbix агент, который сможет работать под Windows XP, например, zabbix_agent-5.2.0-windows-i386-openssl.msi. Агент будет выполнять активные проверки. Чтобы облегчить дальнейшую конфигурация агента, во время установки заполним следующие поля:

  • Ноst name - уникальное имя хоста, совпадающее с именем узла сети на Zabbix сервере.

  • Zabbix server IP/DNS - IP-адреса Zabbix сервера.

  • Server or Proxy for active checks - IP-адрес Zabbix сервера для активных проверок.

Конфигурирование Zabbix агента

В конфигурационный файл C:\Program Files\Zabbix Agent\zabbix_agentd.conf были внесены некоторые изменения.

  1. Увеличено время выполнения скрипта.

    ### Option: Timeout#Spend no more than Timeout seconds on processing.## Mandatory: no# Range: 1-30# Default:# Timeout=3Timeout=30
    
  2. Создан параметр для мониторинга.

    #User-defined parameter to monitor. There can be several user-defined parameters.#Format: UserParameter=<key>,<shell command>## Mandatory: no# Default:# UserParameter=UserParameter=opc[*],opc.exe -o csv -s $1 $2
    

Узел сети и элементы данных на сервере Zabbix

На Zabbix сервере создадим узел сети. Имя узла сети должно совпадать с Ноst name, указанном при установке агента, интерфейс - IP-адрес агента.

Далее к созданному узлу сети добавим элемент данных c типом Zabbix агент (активный). Ключом должна являться конструкция типа: opc[<ИМЯ OPC СЕРВЕРА>, <ЗАПРАШИВАЕМЕ ТЕГИ ЧЕРЕЗ ПРОБЕЛ>].

Значениями элемента данных будут строки, разделенные запятыми:

ATP2.Register.OAT,273,Good,05/24/21 15:21:33ATP2.Register.GVS.T_inlet_W,501,Good,05/24/21 15:21:33ATP2.Register.GVS.T_outlet_W,445,Good,05/24/21 15:21:33ATP2.Register.T_outlet_w_com,404,Good,05/24/21 15:21:33ATP2.Register.RAD.T_outlet_W,256,Good,05/24/21 15:21:33ATP2.Register.P_in_W_com,39,Good,05/24/21 15:21:33ATP2.Register.P_out_W_com,36,Good,05/24/21 15:21:33ATP2.Register.RAD.P_outlet_W,43,Good,05/24/21 15:21:33ATP2.Register.FIRE.P_gidrant,68,Good,05/24/21 15:21:33

Зависимые элементы данных

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

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

function (value){    var nr_line = 4;    var lines = value.split('\n');    var fields = lines[nr_line].split(',');    if(typeof fields[2] != "undefined" &&  fields[2] == "Good"){    return (typeof fields[1] != "undefined") ? fields[1] : null;    }    return null;}

Пример визуализации полученных данных:

Заключение

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

Подробнее..

Поддержка черных и белых списков для метрик на стороне агента в Zabbix 5.0

15.09.2020 16:23:12 | Автор: admin


Поддержка черных и белых списков для метрик на стороне агента


Тихон Усков, Инженер интеграции, Zabbix


Проблемы безопасности данных


В Zabbix 5.0 появилась новая функция, которая позволяет улучшить безопасность в системах с использованием Zabbix Agent и заменяет старый параметр EnableRemoteCommands.


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


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

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



Доступ к данным с помощью утилиты zabbix_get


ПРИМЕЧАНИЕ. Данные могут быть получены, только если агент имеет права на чтение соответствующего файла. Но, например, файл /etc/passwd/ доступен для чтения всем пользователям.


  • Агент также может выполнять потенциально опасные команды. Например, ключ *system.run[]** позволяет выполнять любые удаленные команды на узлах сети, в том числе запускать из веб-интерфейса Zabbix скрипты, которые также выполняют команды на стороне агента.

# zabbix_get -s my.prod.host -k system.run["wget http://malicious_source -O- | sh"]# zabbix_get -s my.prod.host -k system.run["rm -rf /var/log/applog/"]

  • В Linux агент по умолчанию запускается без root-привилегий, тогда как в Windows он запускается как сервис от имени System и имеет неограниченный доступ к файловой системе. Соответственно, если после установки в параметры Zabbix Agent не внесены изменения, агент имеет доступ к реестру, файловой системе и может выполнять WMI запросы.

В более ранних версиях параметр EnableRemoteCommands=0 позволял только отключать метрики с ключом *system.run[]** и выполнение скриптов из веб-интерфейса, но при этом было не было возможности ограничить доступ к отдельным файлам, разрешить или запретить отдельные ключи, которые устанавливались вместе с агентом, или ограничить использование отдельных параметров.



Использование параметра EnableRemoteCommand в ранних версиях Zabbix


AllowKey/DenyKey


Zabbix 5.0 помогает защититься от такого несанкционированного доступа благодаря белым и черным спискам для разрешения и запрета метрик на стороне агента.


В Zabbix 5.0 все ключи, включая *system.run[]**, разрешены, и добавлены два новых параметра конфигурации агента:


AllowKey= разрешенные проверки;


DenyKey= запрещенные проверки;


где паттерн имени ключа с параметрами, в котором используются метасимволы (*).

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


Последовательность правил


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


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



2 разных правила с одинаковым паттерном и ключ vfs.file.size[/tmp/file]


Порядок использования ключей AllowKey/DenyKey:


  1. точные правила,
  2. общие правила,
  3. запрещающее правило.

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



Правильная последовательность


Если необходимо разрешить запуск 2 утилит через *system.run[]**, и в первую очередь будет указано запрещающее правило, утилиты запускаться не будут, потому что первый паттерн будет всегда соответствовать любому ключу, и последующие правила будут игнорироваться.



Неправильная последовательность


Паттерны


Основные правила


Паттерн выражение с подстановочными знаками (wildcard). Метасимвол (*) соответствует любому количеству любых символов в определенной позиции. Метасимволы могут использоваться как в имени ключа, так и в параметрах. Например, можно жестко определить текстом первый параметр, а последующий указать как wildcard.


Параметры должны быть заключены в квадратные скобки [].


  • system.run[* неверно
  • vfs.file*.txt] неверно
  • vfs.file.*[*] верно

Примеры использования wildcard.


  1. В имени ключа и в параметре. В данном случае ключ не соответствует аналогичному ключу, который не содержит параметр, поскольку в паттерне мы указали, что хотим получить некое окончание имени ключа и некий набор параметров.
  2. Если в паттерне не использованы квадратные скобки, паттерн разрешает все ключи, которые не содержат параметры и запрещает все ключи с указанным параметром.
  3. Если ключ записан полностью, а параметры указаны как wildcard, он будет соответствовать любому аналогичному ключу с любыми параметрами и не будет соответствовать ключу без квадратных скобок, т. е. будет разрешен или запрещен.


Правила заполнения параметров.


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


Особенности написания ключей с параметрами


  • Если ключ указан с параметрами, но параметры являются необязательными и указаны как метасимвол, ключ без параметров будет разрешен. Например, если вы хотите запретить получение информации о нагрузке на CPU и указываете, что ключ system.cpu.load[*] должен быть запрещен, не забывайте, что ключ без параметров вернет среднее значение нагрузки.


Правила заполнения параметров


Заметки


Настройка


  • Некоторые правила не могут быть изменены пользователем, например, правила обнаружения (discovery) или авторегистрации агентов. Правила AllowKey/DenyKey не затрагивают следующие параметры:
    HostnameItem
    HostMetadataItem
    HostInterfaceItem

ПРИМЕЧАНИЕ. Если администратор запрещает какой-либо ключ, при запросе Zabbix не выдает информации о том, по какой причине метрика или ключ попадают в категорию 'NOTSUPPORTED'. В log-файлах агента информация о запретах на выполнение удаленных команд также не отображается. Это сделано из соображений безопасности, но может осложнить отладку, если метрики попадают в неподдерживаемую категорию по каким-либо причинам.


  • Не стоит рассчитывать на какой-то определенный порядок подключения внешних файлов конфигурации (например, в алфавитном порядке).

Утилиты командной строки


После настройки правил необходимо удостовериться, что все настроено верно.


Можно воспользоваться одним из трех вариантов:


  • Добавить метрику в Zabbix.
  • Протестировать с помощью zabbix_agentd. Zabbix agent c опцией -print (-p) показывает все ключи (которые разрешены по умолчанию), кроме тех, которые не разрешены конфигурацией. А с опцией -test (-t) для запрещенного ключа вернет 'Unsupported item key'.
  • Протестировать с помощью zabbix_get. Утилита zabbix_get с опцией -k вернет 'ZBX_NOTSUPPORTED: Unknown metric'.

Разрешать или запрещать


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



**


ПРИМЕЧАНИЕ. Кавычки в параметре игнорируются.


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



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


Вопросы и ответы


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


Ответ. Это вопрос производительности regex, поскольку агент, как правило, один, и он проверяет огромное количество метрик. Regex достаточно тяжелая операция, и мы не можем проверять тысячи метрик таким образом. Wildcards универсальное, шороко применяемое и простое решение.


Вопрос. Разве файлы Include подключаются не в алфавитном порядке?


Ответ. Насколько мне известно, предсказать последовательность применения правил, если вы разносите правила по разным файлам, фактически невозможно. Я рекомендую собрать все правила AllowKey/DenyKey в одном файле Include, потому что они взаимодействуют друг с другом, и подключать этот файл.


Вопрос. В Zabbix 5.0 опция 'EnableRemoteCommands=' в конфигурационном файле отсутствует, и доступны только AllowKey/DenyKey?


Ответ. Да, все верно.


Спасибо за внимание!

Подробнее..

Procmeminfo gawk удобный JSON для discovery метрик в zabbix

04.12.2020 20:21:06 | Автор: admin

В работе над одной задачей, понадобилось добавить в мониторинг все счетчики памяти из /proc/meminfo с нескольких linux хостов, для отслеживания состояние памяти в течении времени

root@server:~# cat /proc/meminfo                MemTotal:        8139880 kBMemFree:          146344 kBMemAvailable:    4765352 kBBuffers:          115436 kBCached:          6791672 kBSwapCached:         9356 kBActive:          4743296 kBInactive:        2734088 kBActive(anon):    2410780 kBInactive(anon):   340628 kBActive(file):    2332516 kBInactive(file):  2393460 kBUnevictable:           0 kBMlocked:               0 kBSwapTotal:       3906556 kBSwapFree:        3585788 kBDirty:               804 kBWriteback:             0 kBAnonPages:        567172 kBMapped:          2294276 kBShmem:           2182128 kBKReclaimable:     198800 kBSlab:             340540 kBSReclaimable:     198800 kBSUnreclaim:       141740 kBKernelStack:        7008 kBPageTables:        90520 kBNFS_Unstable:          0 kBBounce:                0 kBWritebackTmp:          0 kBCommitLimit:     7976496 kBCommitted_AS:    5171488 kBVmallocTotal:   34359738367 kBVmallocUsed:       25780 kBVmallocChunk:          0 kBPercpu:            24480 kBHardwareCorrupted:     0 kBAnonHugePages:         0 kBShmemHugePages:        0 kBShmemPmdMapped:        0 kBFileHugePages:         0 kBFilePmdMapped:         0 kBCmaTotal:              0 kBCmaFree:               0 kBHugePages_Total:       0HugePages_Free:        0HugePages_Rsvd:        0HugePages_Surp:        0Hugepagesize:       2048 kBHugetlb:               0 kBDirectMap4k:      773632 kBDirectMap2M:     7606272 kBDirectMap1G:     2097152 kBroot@server:~#

Набор счетчиков должен приезжать в мониторинг автоматически при помощи discovery прямиком с файла /proc/meminfo

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

Первое что пришло на ум - создать скрипт, запилить в нем всю логику, разложить на сервера и добавить юсер-параметр zabbix агента, но это уже не спортивно, так как эту же штуку можно сделать используя лишь gawk

Создадим шаблон в мониторинге, переходим во вкладку макросы, создаем три макроса:

макрос {$PATH} нужен для того чтобы gawk нашелся при попытке его запустить

Содержание макроса:

PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin; LANG=en_US.UTF-8;

макрос {$S} нужен будет в discovery ( простыню про gawk, BEGIN я объясню в конце статьи )

gawk  'BEGIN {FS=":";ORS="";print "{\"data\": [ " }{b=gensub(/ +/,"","g",gensub(/kB/,"","g",$2) );$1=gensub(/\(|\)/,"_","g",$1);printf "%s{\"{#TYPE}\": \"%s\", \"{#VALUE}\": \"%s\"}",separator, $1, b;separator = ",";} END { print " ]}" }' /proc/meminfo

макрос {$VALUE} нужен будет при получении метрик раз в минуту

gawk  'BEGIN { FS=":"; ORS = ""; print "{" } { b=gensub(/ +/,"","g",gensub(/kB/,"","g",$2) ); $1=gensub(/\(|\)/,"_","g",$1); printf "%s\"%s\":\"%s\"",separator,$1,b;separator=",";} END { print "}" }' /proc/meminfo

вот наш шаблон

Создадим обычную метрику meminfo system.run[{$PATH} {$VALUE},wait]

Обратите внимание на конструкцию вызова system.run а внутри два макроса {$PATH} {$VALUE} очень коротко, лаконично и удобно

Метрика meminfo является источником данных для метрик которые будут обнаружены

С метрикой пока все

Создаем правило обнаружения meminfo

Перейдем в фильтр и добавим {#TYPE} [не равно] VmallocTotal|VmallocChunk это делается для исключения двух ненужных нам параметров

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

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

Линкуем созданный шаблон с хостом

Пробуем

Должно получится

метрики нашлись, данные по ним распределились в правильном исчислении то есть в байтах

можем посмотреть и графики

Теперь самое интересное, как использовать gawk для создания JSON для discavery и для базовой метрики

Вот полный честный вывод JSON для discavery

root@server:~# gawk  'BEGIN {FS=":";ORS="";print "{\"data\": [ " }{b=gensub(/ +/,"","g",gensub(/kB/,"","g",$2) );$1=gensub(/\(|\)/,"_","g",$1);printf "%s{\"{#TYPE}\": \"%s\", \"{#VALUE}\": \"%s\"}",separator, $1, b;separator = ",";} END { print " ]}" }' /proc/meminfo{"data": [ {"{#TYPE}": "MemTotal", "{#VALUE}": "8139880"},{"{#TYPE}": "MemFree", "{#VALUE}": "147628"},{"{#TYPE}": "MemAvailable", "{#VALUE}": "4764232"},{"{#TYPE}": "Buffers", "{#VALUE}": "115316"},{"{#TYPE}": "Cached", "{#VALUE}": "6789504"},{"{#TYPE}": "SwapCached", "{#VALUE}": "9356"},{"{#TYPE}": "Active", "{#VALUE}": "4742408"},{"{#TYPE}": "Inactive", "{#VALUE}": "2733636"},{"{#TYPE}": "Active_anon_", "{#VALUE}": "2411644"},{"{#TYPE}": "Inactive_anon_", "{#VALUE}": "340828"},{"{#TYPE}": "Active_file_", "{#VALUE}": "2330764"},{"{#TYPE}": "Inactive_file_", "{#VALUE}": "2392808"},{"{#TYPE}": "Unevictable", "{#VALUE}": "0"},{"{#TYPE}": "Mlocked", "{#VALUE}": "0"},{"{#TYPE}": "SwapTotal", "{#VALUE}": "3906556"},{"{#TYPE}": "SwapFree", "{#VALUE}": "3585788"},{"{#TYPE}": "Dirty", "{#VALUE}": "368"},{"{#TYPE}": "Writeback", "{#VALUE}": "0"},{"{#TYPE}": "AnonPages", "{#VALUE}": "568164"},{"{#TYPE}": "Mapped", "{#VALUE}": "2294960"},{"{#TYPE}": "Shmem", "{#VALUE}": "2182128"},{"{#TYPE}": "KReclaimable", "{#VALUE}": "198800"},{"{#TYPE}": "Slab", "{#VALUE}": "340536"},{"{#TYPE}": "SReclaimable", "{#VALUE}": "198800"},{"{#TYPE}": "SUnreclaim", "{#VALUE}": "141736"},{"{#TYPE}": "KernelStack", "{#VALUE}": "7040"},{"{#TYPE}": "PageTables", "{#VALUE}": "90568"},{"{#TYPE}": "NFS_Unstable", "{#VALUE}": "0"},{"{#TYPE}": "Bounce", "{#VALUE}": "0"},{"{#TYPE}": "WritebackTmp", "{#VALUE}": "0"},{"{#TYPE}": "CommitLimit", "{#VALUE}": "7976496"},{"{#TYPE}": "Committed_AS", "{#VALUE}": "5189180"},{"{#TYPE}": "VmallocTotal", "{#VALUE}": "34359738367"},{"{#TYPE}": "VmallocUsed", "{#VALUE}": "25780"},{"{#TYPE}": "VmallocChunk", "{#VALUE}": "0"},{"{#TYPE}": "Percpu", "{#VALUE}": "24480"},{"{#TYPE}": "HardwareCorrupted", "{#VALUE}": "0"},{"{#TYPE}": "AnonHugePages", "{#VALUE}": "0"},{"{#TYPE}": "ShmemHugePages", "{#VALUE}": "0"},{"{#TYPE}": "ShmemPmdMapped", "{#VALUE}": "0"},{"{#TYPE}": "FileHugePages", "{#VALUE}": "0"},{"{#TYPE}": "FilePmdMapped", "{#VALUE}": "0"},{"{#TYPE}": "CmaTotal", "{#VALUE}": "0"},{"{#TYPE}": "CmaFree", "{#VALUE}": "0"},{"{#TYPE}": "HugePages_Total", "{#VALUE}": "0"},{"{#TYPE}": "HugePages_Free", "{#VALUE}": "0"},{"{#TYPE}": "HugePages_Rsvd", "{#VALUE}": "0"},{"{#TYPE}": "HugePages_Surp", "{#VALUE}": "0"},{"{#TYPE}": "Hugepagesize", "{#VALUE}": "2048"},{"{#TYPE}": "Hugetlb", "{#VALUE}": "0"},{"{#TYPE}": "DirectMap4k", "{#VALUE}": "773632"},{"{#TYPE}": "DirectMap2M", "{#VALUE}": "7606272"},{"{#TYPE}": "DirectMap1G", "{#VALUE}": "2097152"} ]}root@server:~#

Вот так выглядит JSON для discavery

{"data": [ {"{#TYPE}": "MemTotal", "{#VALUE}": "8139880"},{"{#TYPE}": "MemFree", "{#VALUE}": "147628"},{"{#TYPE}": "MemAvailable", "{#VALUE}": "4764232"},{"{#TYPE}": "Buffers", "{#VALUE}": "115316"},{"{#TYPE}": "Cached", "{#VALUE}": "6789504"},{"{#TYPE}": "SwapCached", "{#VALUE}": "9356"},.....{"{#TYPE}": "DirectMap4k", "{#VALUE}": "773632"},{"{#TYPE}": "DirectMap2M", "{#VALUE}": "7606272"},{"{#TYPE}": "DirectMap1G", "{#VALUE}": "2097152"} ]}root@server:~# 
root@server:~# gawk 'BEGIN {FS=":";ORS="";print "{\"data\": [ " }{b = gensub(/ +/,"","g",  gensub(/kB/,"","g",$2) );$1=gensub(/\(|\)/,"_","g",$1);printf "%s{\"{#TYPE}\": \"%s\", \"{#VALUE}\": \"%s\"}",separator, $1, b;separator = ",";}END { print " ]}" }' /proc/meminfo

BEGIN {FS=":";ORS="";print "{\"data\": [ " }

FS=":"; - разделяет строку на части и передает разделившеся части в $1, $2 ... $n

print "{\"data\": [ " - выполняется только один раз, в самом начале

Дальше происходит магия gawk организует сам цикл с перечислением всех полученных строк, принимая во внимание то что строки будут разделятся по ":" то мы в $1 получать всегда имя параметра, а в $2 всегда его значение, правда не очень в удобном формате

собственно это выглядит как: есть строка из цикла CommitLimit: 7976496 kB которая разделяется:

$1=CommitLimit

$2= 7976496 kB

Нужно предобработать обе строки

b = gensub(/ +/,"","g", gensub(/kB/,"","g",$2) ); содержится две функции gensub

Вложенная функция gensub(/kB/,"","g",$2) исключает из вывода kB а базовая gensub(/ +/,"","g", ........ ); исключает пробелы, получаем чистую цифиру.

Следом в имени параметров {#TYPE} нужно предусмотреть что недолжно быть символов скобок ( ) так как мониторинг их не перевариват, ни при создании метрик, ни при разнесении данных.

Сказанно - сделано, регуляркой уберем скобки из имени параметра, заменим поджопником нижней чертой _ $1=gensub(/\(|\)/,"_","g",$1);

После подготовленные параметры, собираем JSON и выводим

printf "%s{\"{#TYPE}\": \"%s\", \"{#VALUE}\": \"%s\"}",separator, $1, b;separator = ",";}

После того как все строки обработаны, gawk выполняет END { print " ]}" что закрывает JSON и финализирует.

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

Подробнее..

Мониторинг распределенной системы с помощью Zabbix на примере Apache Ignite

01.12.2020 06:16:56 | Автор: admin

Вступление

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

Наиболее распространенные проблемы:

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

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

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

Общие рекомендации при построении системы мониторинга:

  • Проще лучше.

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

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

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

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

Создание шаблона

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

Apache Ignite это in-memory computing platform, платформа используемая как кэш, распределённая вычислительная система и база данных. Начать более подробное изучение продукта можно с официальной документации. Ключевые внешние показатели производительности системы это практически стандартный набор:

  • Загрузка CPU

  • Утилизация RAM

  • Утилизация дисков в случае persistence

  • Сеть

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

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

Так как Ignite написан на Java, основным способом мониторинга для него будет являться JMX. Если мы просто скачаем и запустим Ignite, jmx-порт будет открыт на первом свободном порту между 49112 и 65535. Для мониторинга нас такой подход не устраивает, так как, как правило, порт настраивается заранее и способов его автоматического определения по умолчанию нет. После ознакомления со скриптом запуска становится понятно, что для того, чтобы самому указать необходимый порт, можно использовать переменную окружения IGNITE_JMX_PORT. Таким образом, выполнив команду export IGNITE_JMX_PORT=49112 и запустив узел, мы получим доступ к JMX на известном нам статическом порту.

Начиная с версии Ignite 2.10, jmx-порт задаётся по другому

Начиная с версии 2.10, это поведение изменено и в будущих версиях необходимо использовать переменную JVM_OPTS. Открыть jmx-порт можно следующим образом:

export JVM_OPTS="-Dcom.sun.management.jmxremote \-Dcom.sun.management.jmxremote.port=49112 \-Dcom.sun.management.jmxremote.authenticate=false \-Dcom.sun.management.jmxremote.ssl=false"

Особенность, на которую стоит обратить внимание, по умолчанию в пути к mbean присутствует classloader, который будет меняться после каждого перезапуска узла. Он добавлялся для возможности запуска нескольких инстансов Ignite в рамках одной JVM, чтобы избежать конфликта метрик, но сейчас это не наш случай. Для нас же это будет значить, что zabbix будет обнаруживать метики заново после каждого перезапуска. Решить эту проблему можно, добавив JMX-опцию -DIGNITE_MBEAN_APPEND_CLASS_LOADER_ID=false, она уберёт classloader из пути.

mbean с classloadermbean с classloader

Ignite находится в opensource, поэтому если вы уверены, что какая-то функциональность должна работать по-другому, то вы можете принять участие в разработке. В данном случае я так считаю и сразу завёл задачу в JIRA ASF.

В результате дерево метрик будет выглядеть следующим образом:

Интерфейс jconsoleИнтерфейс jconsole

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

Описание объектаОписание объекта

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

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

Создание правила обнаруженияСоздание правила обнаружения

В качестве значения {HOST.CONN}:{HOST.PORT} zabbix будет подставлять адрес, по которому доступен узел, с применённым шаблоном и указанное в качестве jmx-порта значение.

Дебаг jmx discovery

Если возникнет необходимость отдебажить обнаружение в JMX, это можно сделать с помощью команды zabbix_get. Пример discovery-запроса списка дата-регионов:

zabbix_get -s localhost -p 10052 -k '{"request":"java gateway jmx","jmx_endpoint":"service:jmx:rmi:///jndi/rmi://HOST:49112/jmxrmi","keys":["jmx.discovery[beans,\"org.apache:group=DataRegionMetrics,name=*\"]"]}' 

Результат будет выглядеть следующем образом следующий результат:

{   "{#JMXDOMAIN}":"org.apache",   "{#JMXOBJ}":"org.apache:group=DataRegionMetrics,name=sysMemPlc",   "{#JMXNAME}":"sysMemPlc",   "{#JMXGROUP}":"DataRegionMetrics"},{   "{#JMXDOMAIN}":"org.apache",   "{#JMXOBJ}":"org.apache:group=DataRegionMetrics,name=default",   "{#JMXNAME}":"default",   "{#JMXGROUP}":"DataRegionMetrics"},{   "{#JMXDOMAIN}":"org.apache",   "{#JMXOBJ}":"org.apache:group=DataRegionMetrics,name=TxLog",   "{#JMXNAME}":"TxLog",   "{#JMXGROUP}":"DataRegionMetrics"}

Пример шаблона метрики:

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

Параметры {#JMXNAME} и аналогичные zabbix берёт из результата discovery-запроса.

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

  • Дата-регионы

  • Кэш-группы

  • Кэши

  • Пулы потоков

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

Развертывание и автоматизация

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

Как это всё будет работать:

  1. Zabbix server регистрирует новый узел после получения первого запроса от zabbix agent.

  2. Zabbix server выполняет скрипт, который добавляет jmx-порт и применяет шаблоны к новому узлу.

  3. Zabbix server начинает посылать запросы на Java gateway, который, в свою очередь, опрашивает приложение и возвращает метрики.

  4. Zabbix agent получает от сервера список собираемых активных метрик и начинает их отправлять на zabbix server.

  5. Zabbix server запрашивает значения пассивно собираемых метрик у zabbix agent.

Метрики от приложения поступают по JMX, новые узлы регистрируются после первого обращения zabbix agent к серверу.

Подробнее о том почему в п.2 используется самописный скрипт
  • Изначально было желание использовать функционал zabbix, но zabbix из коробки не умеет присваивать jmx port новым узлам, а без этого нельзя привязать шаблон, использующий JMX. Предложение по доработке есть в jira zabbix с 2012 года, но оно до сих пор в open.

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

  • Вариант через базу данных, описанный в тикете, возможно, применим для postgresql, но не работает на Oracle, MySQL и MariDB, так как в этих БД нельзя настроить триггер, который будет делать вставку в ту же таблицу, на которой он сработал.

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

Схема тестового окруженияСхема тестового окружения

Как установить:

  1. Скачиваем и устанавливаем docker и docker-compose, если они ещё не установлены.

  2. Скачиваем все необходимые файлы из репозитория.

  3. Переходим в скачанную папку.

  4. Запускаем сборку образа: docker-compose -f docker-compose-zabbix.yml build

  5. Запускаем кластер и сервер мониторинга: docker-compose -f docker-compose-zabbix.yml up

  6. Через несколько секунд zabbix будет доступен на 80 порту. Учётная запись по умолчанию Admin / zabbix.

Как импортировать шаблоны:

  1. Идём на вкладку Configuration->Templates->Import и импортируем шаблон ignite_jmx.xml (находится в папке, скачанной ранее). Вместе с самим шаблоном будет добавлена группа Templates/Ignite autoregistration, это название будет использоваться далее для добавления шаблонов из этой группы к новым узлам.

  2. В каждом шаблоне, который должен быть применён, указываем созданную на предыдущем шаге группу. Шаблон Template App Ignite JMX в ней уже содержится, я добавил Template App Generic Java JMX и Template OS Linux by Zabbix agent.

Создаём скрипт для авторегистрации агентов:

  1. В интерфейсе zabbix переходим на вкладку Configuration->Actions, в выпадающем списке выбираем Autoregistration actions и создаём новое действие.

  2. Даем название действию. Можем настроить условия добавления узла.

  3. В операциях добавляем пункт Add host. Это создаст новый узел в zabbix в случае выполнения условий, указанных ранее.

  4. Добавляем запуск скрипта autoreg.php, который будет добавлять jmx-порт в настройки и применять шаблоны из указанной группы к переданному узлу. Для тех, кто разворачивает тестовый кластер из образа, он будет находиться в папке /var/lib/zabbix, для тех, кто устанавливает самостоятельно, в репозитории, указанном выше. Запускаться в моём случае он будет командой php /var/lib/zabbix/autoreg.php {HOST.HOST} 'Templates/Ignite autoregistration' '{HOST.METADATA}'. Должно получиться так:

Добавление запуска скрипта в правило авторегистрацииДобавление запуска скрипта в правило авторегистрации

Если всё было сделано корректно, узлы должны появиться в zabbix с настроенным jmx-портом и применёнными шаблонами из группы. Если что-то пошло не так, первое, что рекомендую проверить, Reports->Audit log.

Результаты и куда двигаться дальше

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

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

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

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

Что почитать

  1. Site Reliability Engineering

  2. Zabbix documentation portal

  3. Готовый инструмент для мониторинга и управления Ignite и Gridgain

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru