Привет, Хабр!

С вами снова Илья Вязников, инженер сопровождения СОФРОС. Продолжаю делится практическими приёмами и полезными настройками платформы. Сегодня рассмотрим интеграцию платформы с Zabbix.

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

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

В этой статье покажем, как интегрировать Datareon Platform с Zabbix через API Центра мониторинга. В результате вы сможете:

  • централизованно отслеживать состояние компонентов Datareon Platform;

  • получать технические и эксплуатационные метрики;

  • настраивать автоматические оповещения о возникающих проблемах;

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

  • сократить время обнаружения и устранения инцидентов.

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


Архитектура интеграции

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

  1. Zabbix обращается к API Центра мониторинга Datareon Platform.

  2. API возвращает значения доступных метрик.

  3. Zabbix сохраняет полученные данные в элементы данных (Items).

  4. На основе значений метрик создаются триггеры и уведомления.

  5. При возникновении отклонений ответственные специалисты получают оповещения.


Что получится в результате настройки примера:

В рамках статьи настроим мониторинг адаптера 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 Центра мониторинга предоставляет гибкий способ получения эксплуатационных показателей платформы и позволяет адаптировать контроль под требования конкретной организации. Благодаря этому специалисты могут не только отслеживать текущее состояние системы, но и своевременно реагировать на потенциальные проблемы до того, как они начнут влиять на бизнес-процессы.

Комментарии (0)