Сервис аналитики

Сервис аналитики предназначен для сбора и представления событий работы Платформы со всех узлов в виде REST API. В кластере может быть несколько Сервисов аналитики. В каждом сервисе настраиваются условия отбора событий (задаются в виде списка фильтров при создании сервиса). Для хранения данных Сервиса аналитики используется СУБД MSSQL или PostgreSQL. Доставка событий для Сервиса аналитики выполняется с помощью базового сервиса для сбора событий.

Важно

Ознакомьтесь с требованиями к версиям используемых СУБД в разделе Ограничения и рекомендации.

Обязательные условия для сбора событий сервисом:

  1. Наличие лицензии на Сервис аналитики.

  2. Наличие Базового сервиса для сбора событий.

Сервис создается автоматически, в параметрах конфигурации сервиса должно быть указано: enabled = true; collectPeriodSec больше 0; collectMaxCount установлено значение по умолчанию (1000).

  1. В Параметрах сбора и хранения событий в конфигурации кластера включена опция Сохранять в формате Datareon.

  2. Наличие СУБД (MSSQL или PostgreSQL) для хранения данных Сервисом аналитики.

  3. Настроен Сервис аналитики.

  4. В Центре мониторинга установлено Рабочее состояние Сервиса аналитики и Базового сервиса для сбора событий.

    Внимание

    Если после настройки Сервис аналитики не запускается и в Центре мониторинга отображается сообщение:

    Невозможно получить данные с модуля {id_Сервиса аналитики}, так как модуль не найден ни на одном узле этого кластера.
    

    проверьте размещение модуля.

    Если в конфигурации кластера включено авторазмещение модулей (allocationOptions.auto = true) и используется привязка по адресу базы данных (useDbConnectAddress = true), модуль будет запускаться только на тех узлах, чей адрес совпадает с адресом MSSQL, указанным в параметрах сервиса.

    В этом случае добавьте Сервис аналитики в одну из групп серверов - это позволит разместить модуль на выбранном узле.

Создание сервиса

Чтобы создать Сервис аналитики:

  1. В ЦН перейдите в раздел Сервисы.

  2. Нажмите на кнопку + над таблицей сервисов. В рабочей области страницы отобразится интерфейс создания / редактирования сервиса, содержащий вкладки: Основные, Хранение данных, Сбор данных и Предоставление данных.

  3. На вкладке Основные заполните следующие поля:

  • Название: произвольное название сервиса, обязательно для заполнения.

  • Имя: уникальное имя сервиса, необязательно для заполнения.

  • Комментарий: описание сервиса, необязательно для заполнения, поддерживается многострочный ввод.

  • Включен: для активации сервиса установите флажок.

  • Правило обработки очередей: выбор настроенного Правила обработки очередей в разделе ЦН Обработка данных.

  • Настройка сервисов: для создания сервиса выберите вариант Сервис аналитики.

    ../../_images/analytics_serverr0.png
  1. На вкладке Хранение данных:

    • Выберите используемую СУБД:

      • MSSQL

        Примечание

        Если на сервере СУБД MSSQL отключен параметр оптимизированных запросов FILESTREAM, в журнале работы сервиса будет регистрироваться соответствующее предупреждение, не блокирующее работу сервиса. Для нормальной работы сервиса с оптимизированными запросами включите параметр FILESTREAM на стороне сервера СУБД. Если работа с оптимизированными сервисами не требуется, отключите параметр useMemoryOptimizedTable в конфигурации Банка данных для избежания регистрации предупреждений.

      • PostgreSQL

        Внимание

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

        Примечание

        Для работы сервиса с CУБД PostgreSQL пользователь должен обладать правами Вход разрешен (Can login) и Создание баз (Create databases).

    • Заполните следующие поля:

      • Сервер.

      • Экземпляр.

      • Порт.

      • Имя базы данных.

        Примечание

        Если база данных, указанная в настройках, не существует, Платформа самостоятельно создаст базу данных с указанным именем.

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

    • Настройте параметры аутентификации:

      • Установите флажок Вход по имени пользователя и паролю.

      • Введите имя пользователя и пароль, если для доступа требуется аутентификация.

      • Если данные пользователя хранятся в базовом сервисе Управление пользователями, установите флажок Получать пароль из модуля Credential. В результате поле Пароль отображаться не будет.

        Внимание

        Если проставлен флажок Получать пароль из модуля Credential, то пароль берется из Credential при условиях:

      ../../_images/authorization1.png
  2. На вкладке Сбор данных настраиваются параметры, определяющие, какие события и с какой периодичностью будут собираться Сервисом аналитики. Заполните:

  • Периодичность сбора (в секундах): указывается интервал, через который выполняется сбор и сохрание событий.

  • Условия сбора: настройка событий, которые будут собраны. Если условия не заданы, сервис собирает все события платформы.

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

  • Системы и сервисы: выбор из настроенных в ЦН Внешних систем и Сервисов.

  • Группы серверов: выбор из настроенных в ЦН Групп серверов.

  • Типы событий: выбор типа события.

  • Уровни логирования: выбор уровня логирования.

    Внимание

    Сервис Аналитики забирает данные из сервиса Сборщик событий. Если в настройках кластера параметр Уровень логирования событий для хранения не соответствует настройке Уровня логирования в сервисе Аналитики, то в сервис Аналитики будут переданы события в соответствии с настройкой в Кластере.

Для подтверждения выбора из выпадающего списка кликните на любую область вне окна настройки Условий сбора событий. После установки условий нажмите Сохранить.

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

Логика сбора данных по фильтрам:

  1. Между различными категориями фильтров → логические И (должны выполниться все условия одновременно).

  2. Между выбранными элементами внутри одного списка → логическое ИЛИ (подойдет любой из выбранных вариантов).

    ../../_images/analytics_server1.png
  1. На вкладке Предоставление данных заполните:

  • Порт для публикации API: указывается порт для API, обязательно для заполнения. Можно выбрать из перечня констант или ввести значение порта.

  1. Нажмите на кнопку Сохранить изменения.

  2. Нажмите на кнопку Применить конфигурацию.

Мониторинг работы Сервиса аналитики можно отслеживать после применения конфигурации в Сервисах Центра мониторинга.

Механизм сбора событий сервисом

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

Сервис для сбора событий регистриует все события в соответствии с настроенными в Сервисе аналитики фильтрами в своей технической очереди.

Очереди создаются в папке с данными хранилища событий:

Data\DatareonPlatformEventsStorage\12345678-0000-0000-0000-1234567890ea\EventsAnalytics

В папке EventsAnalytics для каждого Сервиса аналитики создаются папки для файлов очередей. При получении запроса из Сервиса аналитики выполняется передача накопленных событий для соответствующего Сервиса аналитики.

Собранные Сервисом аналитики события доступны с помощью REST API, опубликованное на порту в соответствии с конфигурацией, на сервере, где размещен Сервис аналитики. Ссылка на сервис и Swagger будут выведены в Центре мониторинга в Параметрах сервиса при рабочем состоянии сервиса.

Доступ к API разрешен только авторизованным пользователям в модуле Управление пользователями.

Методы для получения токена доступа также доступны в API Сервиса аналитики. В API представлены методы для получения списка событий и получения конкретного события.

Метод получения списка событий

Метод получения списка событий: [GET] /api/events/page

Метод позволяет получить события по заданным параметрам.

Параметры запроса:

  • creationDateStart (DateTime): начало периода (UTC), пример: 2025-11-18T00:00:00Z.

  • creationDateEnd (DateTime): конец периода (UTC), пример: 2025-11-19T00:00:00Z.

  • messageId (GUID): идентификатор сообщения, позволяет получить события, относящиеся к конкретному сообщению.

  • streamId (GUID): идентификатор потока, используется для поиска всех событий одной цепочки обработки.

  • moduleId (GUID): идентификатор модуля, сгенерировавшего событие. Фильтрует события по конкретному модулю.

  • dataTypeId (GUID): идентификатор типа данных, к которому относится сообщение. Используется при фильтрации событий только определенного типа данных.

  • systemDataTypeId (GUID): идентификатор внешнего типа данных. Актуально, если у одного DataType есть несколько внешних системных типов.

  • processId (GUID): идентификатор процесса обработки. Позволяет отфильтровать события, относящиеся к одному процессу.

  • initialSourceId (GUID): идентификатор исходного источника сообщения.

  • pageIndex (Integer): номер страницы. По умолчанию -1 (в ответе вернет последнюю страницу (свежие события)).

  • pageSize (Integer): количество событий на страницу. По умолчанию 200.

  • eventTypes (Array): тип события, выбор одного типа.

  • minIssueLevel (String): уровень логирования (Verbose, Debug, Info, Warning, Error, Fatal, None), выбор одного уровня.

  • orderBy (String): поле сортировки.

  • orderAsc (Boolean): сортировка событий, где true — по возрастанию, false — по убыванию.

Варианты использования:

  • Получить последние 200 событий за день.

Пример запроса:

curl -X 'GET' \
  'https://127.0.0.1:7207/api/events/page?creationDateStart=2025-11-18T00%3A00%3A00Z&creationDateEnd=2025-11-20T00%3A00%3A00Z&pageIndex=0&pageSize=200' \
  -H 'accept: */*' \
  -H 'Authorization: Bearer {токен}'

Request URL

https://127.0.0.1:7207/api/events/page?creationDateStart=2025-11-18T00%3A00%3A00Z&creationDateEnd=2025-11-20T00%3A00%3A00Z&pageIndex=0&pageSize=200

Метод возвращает до 200 последних событий за указанный день по всем модулям и типам событий.

  • Получить события только типа Error.

Пример запроса:

curl -X 'GET' \
  'https://127.0.0.1:7207/api/events/page?pageIndex=0&pageSize=200&minIssueLevel=Error' \
  -H 'accept: */*' \
  -H 'Authorization: Bearer {токен}'

Request URL

https://127.0.0.1:7207/api/events/page?pageIndex=0&pageSize=200&minIssueLevel=Error

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

Параметры ответа:

Поля события (HistoryEvent):

  • nodeId: идентификатор узла кластера, на котором зафиксировано событие.

  • timeStamp: дата и время регистрации события.

  • eventNumber: порядковый номер события в рамках журнала.

  • eventType: тип события.

  • eventSource: источник события — компонент/модуль, который его сгенерировал.

  • eventDetails: текстовое описание события (детали). В примере пусто.

  • message: объект внутреннего сообщения, с которым связано событие.

  • messageBodyLength: длина тела сообщения в байтах.

  • logLevel: уровень логирования события.

  • targetId: идентификатор узла или компонента, куда направлено сообщение/действие (получатель).

  • moduleId: идентификатор модуля Платформы, от имени которого выполняется обработка (конкретный сервис/система).

  • sourceId: идентификатор исходного источника события (если заполнен, можно отследить, кто инициировал событие).

  • processDescription: объект с описанием процесса, в контексте которого произошло событие.

  • id: идентификатор записи события в журнале.

Метод получения конкретного события

Метод получения конкретного события: [GET] /api/events/{eventId}

Параметры запроса:

  • eventId (string): ID события, обязательный параметр.

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

Пример запроса:

curl -X 'GET' \
  'https://127.0.0.1:7207/api/events/242C83C7-EC0F-45DE-9825-1BA47089B1DC' \
  -H 'accept: */*' \
  -H 'Authorization: Bearer {токен}'

Request URL

https://127.0.0.1:7207/api/events/242C83C7-EC0F-45DE-9825-1BA47089B1DC

где 242C83C7-EC0F-45DE-9825-1BA47089B1DC - ID события (eventId).

В ответе на запрос будет полная структура события.

Описание параметров ответа.