
Привет, Хабр!
С вами снова Илья Вязников, инженер сопровождения СОФРОС. Продолжаю делится практическими приёмами и полезными настройками платформы. Сегодня рассмотрим интеграцию платформы с Zabbix.
Современные интеграционные платформы становятся критически важным элементом ИТ-ландшафта компании. Через них проходят бизнес-процессы, данные между информационными системами и внешними сервисами. Кратковременный сбой интеграционного контура может привести к задержкам обработки данных, ошибкам в бизнес-процессах и нарушению работы смежных систем.
Поэтому помимо функционального мониторинга самой платформы важно обеспечить централизованное наблюдение за её состоянием средствами корпоративного мониторинга. Одним из наиболее распространённых инструментов для этих задач является Zabbix.
В этой статье покажем, как интегрировать Datareon Platform с Zabbix через API Центра мониторинга. В результате вы сможете:
централизованно отслеживать состояние компонентов Datareon Platform;
получать технические и эксплуатационные метрики;
настраивать автоматические оповещения о возникающих проблемах;
использовать единые инструменты мониторинга для всей ИТ-инфраструктуры компании;
сократить время обнаружения и устранения инцидентов.
Рассмотрим полный сценарий настройки: от создания сервисного пользователя и получения токена доступа до получения метрик и настройки триггеров в Zabbix.
Архитектура интеграции
Схема взаимодействия выглядит следующим образом:
Zabbix обращается к API Центра мониторинга Datareon Platform.
API возвращает значения доступных метрик.
Zabbix сохраняет полученные данные в элементы данных (Items).
На основе значений метрик создаются триггеры и уведомления.
При возникновении отклонений ответственные специалисты получают оповещения.
Что получится в результате настройки примера:
В рамках статьи настроим мониторинг адаптера Datareon Platform, который будет:
автоматически получать токен авторизации;
запрашивать данные через API Центра мониторинга;
извлекать значение размера очереди;
формировать события в Zabbix при превышении заданного порога.
Предварительные требования:
Перед началом настройки убедитесь, что:
развернута и функционирует Datareon Platform;
доступен Центр мониторинга;
установлен и настроен сервер Zabbix;
имеется учетная запись администратора Datareon Platform;
имеется учетная запись с правами настройки объектов мониторинга в Zabbix.
1. Создание сервисного пользователя для доступа к API
Для интеграции рекомендуется использовать отдельную сервисную учетную запись вместо администратора платформы. Такой подход упрощает аудит действий и позволяет ограничить права доступа только необходимыми функциями Центра мониторинга.
1.1 Создание роли
В разделе Центра настройки DATAREON Platform Управление доступом - Роли создаем новую роль для центра мониторинга, даём ей все права на объекты:


1.2 Создание пользователя
В разделе Центра настройки DATAREON Platform Управление доступом - Пользователи создаем нового пользователя, и присваиваем созданную ранее роль.


Созданная учетная запись будет использоваться в Zabbix для авторизации в API Центра мониторинга.
2. Настройка хоста Zabbix
В веб интерфейсе Zabbix, в меню Data collection, в разделе Host group создаем новую группу узлов. Назовем её Platform:


Далее в разделе Host создадим новый узел сети, назовем его “platform_monitoring”.

Добавим новый интерфейс с типом "Agent", введите ip адрес платформы и порт центра мониторинга.

В поле Host groups укажем ранее созданную группу “Platform”:
В итоге созданный хост будет выглядеть следующим образом:

3. Получение токена доступа
Когда вы настроили узел сети, для получения реальных данных с платформы нужно добавить элементы данных.
Для обращения к API Центра мониторинга сначала настроим автоматическое получение токена авторизации.
Переходим в созданный хост, в раздел Items. Создаем новый элемент данных нажав кнопку "Create item":


Создаём элемент данных с указанными параметрами:
Тип: HTTP Agent,
Type of information: Text,
URL: https://ваш_ip_адрес_платформы:порт_Центра_мониторинга/api/session/token
Request type: POST,
Request body type: JSON data
-
Заголовки:
Content-Type: application/json
Accept: /
В поле Request body вставляем тело запроса (Логин и пароль созданного пользователя):
{ "login": "zabbix", "password": "Zabb1x" }

В поле Update interval записываем требуемый интервал выполнения запроса (по умолчанию раз в минуту)

Остальные параметры можно оставить без изменений.
Сохраняем элемент данных
Проверка работоспособности получения токена:
Нажмем кнопку "Test" в окне элемента данных чтобы протестировать работоспособность созданного элемента.
Ставим галочку "Get value from host", нажимаем кнопку "Get value"

В поле "Value" мы получили результат выполнения запроса.
В данном случае нас интересует реквизит "accessToken".

Нам необходимо извлечь токен из тела, для дальнейшего использования в последующих запросах.
Для этого в окне созданного элемента данных переходим во вкладку "Preprocessing".
Добавим новый шаг предобработки с типом JSONPath, в параметры запишем следующий код:
$.accessToken
Данный код возвращает значение поля accessToken

Более подробно с функционалом JSONPath в заббиксе можно ознакомиться в документации zabbix
Далее добавим второй шаг предобработки с типом JavaScript. Он представляет собой функцию с единственным параметром "value" и заданным пользователем телом функции.
В нашем случае value - это результат выполнения предыдущего шага предобработки.
Результатом шага предобработки является значение, которое возвращается из этой функции. В нашем случае мы вернем готовое значение заголовка для авторизации:
return “Bearer ” + value

Если всё настроено корректно, то при тестировании элемента мы получим такой результат:

4. Получение метрик через API Центра мониторинга
После получения токена можно приступить к получению метрик.
API Центра мониторинга предоставляет информацию о различных аспектах работы платформы, например:
состоянии сервисов;
доступности компонентов;
производительности;
очередях сообщений;
ошибках обработки;
иных эксплуатационных показателях.
Список доступных методов и возвращаемых данных можно посмотреть в Swagger-интерфейсе Центра мониторинга.
4.1 Схема получения данных:
Схема работы будет состоять из трёх уровней:
Элемент данных получает токен авторизации.
Зависимый элемент выполняет запрос к API Центра мониторинга.
Дополнительные зависимые элементы извлекают отдельные метрики из полученного JSON.
Такой подход позволяет выполнять один запрос к API и использовать его результат для получения множества показателей без дополнительной нагрузки на платформу.
4.2 Получение данных адаптера:
В качестве примера настроим получение данных по адаптеру “Расчет:1С”.
На странице заббикса Items, создадим зависимый элемент для нашего основного элемента с токеном.
Данный элемент будет выполнять запрос на получение различных метрик с адаптера с полученным токеном.

Назовем его для примера Расчет:1С. Указываем:
Name - Расчет:1С
Key - DP_Get_1C_BP
Type of information - Text.
Остальные параметры можно оставить без изменений.

В меню предобработки “Preprocessing” создаем шаг с типом JavaScript и вставляем следующий код:
var dataRequest = new HttpRequest(); dataRequest.addHeader('Authorization: ' + value); dataRequest.addHeader('Content-Type: application/json'); var dataResponse = dataRequest.get('https://ВашСервер:ПортЦентраМониторинга/api/diagnostic/ваш_Id_Адаптера/state'); // Ваш целевой URL if (dataRequest.getStatus() !== 200) { throw 'Data request failed with status: ' + dataRequest.getStatus(); } return dataResponse;
Данный код выполняет HTTP запрос на получение метрик адаптера.


ID адаптера можно получить в адресной строке, открыв систему в Центре мониторинга:

В результате выполнения получаем примерно такое тело:


Здесь есть вся необходимая нам информация: детализация состояния адаптера, количество сообщений в архивах, размер очередей.
4.3 Извлечение метрики через JSONPath
Далее необходимо извлечь нужную нам метрику, например, мы хотим получить информацию о размере очередей на адаптере, для этого:
Создаем подчиненный элемент для нашего Расчет:1С, который будет обрабатывать полученное на предыдущем шаге тело:

Name - Очереди адаптера
Key - DP_Get_1C_BP_Queue
Type of information - Numeric.
Остальные параметры можно оставить без изменений.

Создадим 2 шага предобработки JSONPath:

Первый шаг JSONPath: Получаем количество сообщений в очереди:
$.states[*].childComponentsData[?(@.name == 'Очереди')].childComponentsData[:].childComponentsData[?(@.name == 'Количество в очереди')].value
Выражение последовательно проходит по структуре JSON, находит раздел «Очереди» и извлекает значение поля «Количество в очереди». Для поиска собственных метрик можно использовать встроенное тестирование JSONPath в Zabbix.
Второй шаг JSONPath: Получаем первый элемент массива - нужное нам значение, поскольку возвращаемое значение на первом шаге - массив
$.[0]
В результате при тестировании элемента получаем количество сообщений в очереди адаптера:

После настройки первого элемента данных остальные метрики добавляются аналогичным образом.
Для каждой новой метрики достаточно определить соответствующее выражение JSONPath и создать новый зависимый элемент данных.
5. Настройка триггеров
Сбор метрик сам по себе не решает задачу мониторинга. Основная ценность появляется тогда, когда система автоматически выявляет отклонения и уведомляет ответственных сотрудников.
Триггеры нужны для анализа получаемых данных. У триггера есть 2 состояния:
ОК - нормальное состояние
Проблема - когда что-то случилось (например, количество сообщений в очереди превысило 50 штук).
У триггера есть 2 основных настраиваемых параметра:
Выражение - условие, по которому триггер принимает состояние "Проблема"
Важность - задает "уровень" проблемы. Например, “Предупреждение”, “Информация”, “Критический”.
Триггер вычисляет свое состояние каждый раз, когда привязанный к нему элемент получает новое значение.
В качестве примеров можно использовать триггеры для следующих сценариев:
недоступность сервиса Datareon Platform;
превышение времени обработки сообщений;
рост количества ошибок;
переполнение очередей;
отсутствие поступления данных в течение заданного периода времени.
Создание триггера:
Для создания триггера необходимо нажать на созданный элемент - Create trigger.

Зададим ему высокий уровень "High". и в поле выражение “Expression” запишем следующее:
last(/platform_monitoring/DP_Get_1C_BP_Queue) > 50
Это значит, что триггер получит важность "Высокий", если последнее значение подчиненного элемента > 50
Пороговые значения необходимо выбирать исходя из особенностей конкретной системы.
Например:
очередь до 10 сообщений может считаться нормой;
очередь от 10 до 50 сообщений — предупреждением;
более 50 сообщений — критическим состоянием.

Для каждого элемента можно создавать несколько триггеров.
Например, если настроить 2 триггера, один с уровнем “Высокий”, второй с уровнем “Критический”:

В таком случае:
Один триггер срабатывает с состоянием "Предупреждение", если количество сообщений в очереди >0 и <50.
Второй триггер с состоянием "Критический" срабатывает если сообщений >50
6. Настройка уведомлений
После создания триггеров рекомендуется настроить механизмы оповещения.
Настройка уведомлений выполняется стандартными средствами Zabbix через раздел Alerts - Media types.
Поскольку процесс не зависит от интеграции с Datareon Platform, подробно останавливаться на нём не будем.
Результат
После выполнения описанных шагов Zabbix будет автоматически получать данные из Datareon Platform через API Центра мониторинга, сохранять значения метрик и контролировать состояние интеграционного контура в режиме реального времени.
Такой подход позволяет оперативно выявлять проблемы, снижать время реакции на инциденты и обеспечивать стабильную работу интеграционных процессов.
Заключение
Интеграция Datareon Platform с Zabbix позволяет включить интеграционный слой в единый контур корпоративного мониторинга и получать полную картину состояния ИТ-инфраструктуры.
Использование API Центра мониторинга предоставляет гибкий способ получения эксплуатационных показателей платформы и позволяет адаптировать контроль под требования конкретной организации. Благодаря этому специалисты могут не только отслеживать текущее состояние системы, но и своевременно реагировать на потенциальные проблемы до того, как они начнут влиять на бизнес-процессы.