.. _config_description: Описание конфигурационного файла Агента СМЭВ4 ============================================= Состав и содержание файлов конфигурирования ------------------------------------------- Состав дистрибутива Агента СМЭВ4 в архиве с конфигурационными файлами (``/distr/einfahrt``): - ``/distr/einfahrt/customLogLevels.xml`` – файл описания настроек логирования; - ``/distr/einfahrt/conf/*.yml`` – заготовки конфигурационных файлов для Потребителя и Поставщика, для тестовой и продуктивной среды. В директории ``/distr/einfahrt/conf/`` дистрибутива находятся типовые заготовки конфигурационного файла: - шаблоны конфигурационного файла Агента для продуктивной среды: - ``conf/prod-consumer-application.yml`` – для Потребителя. - ``conf/prod-producer-application.yml`` – для Поставщика. - шаблоны конфигурационного файла Агента для продуктивной среды (Подключение только к одному ЦОД): - ``conf/prod-singleDC-consumer-application.yml`` – для Потребителя. - ``conf/prod-singleDC-producer-application.yml`` – для Поставщика. - шаблоны конфигурационного файла Агента для тестовой среды: - ``conf/test-consumer-application.yml`` – для Потребителя. - ``conf/test-producer-application.yml`` – для Поставщика. После распаковки дистрибутива необходимо скопировать выбранный файл в каталог ``/distr/einfahrt`` под именем ``application.yml``. В скопированном конфигурационном файле ``application.yml`` задаются необходимые параметры (в заготовке обозначены звездочками ``*``). Более подробное описание необходимых настроек файла ``application.yml`` приведено в разделах ниже. .. _changes_reestr: Реестр изменений файлов конфигурирования ----------------------------------------- :numref:`tab_3` содержит Реестр изменений. .. _tab_3: .. table:: Реестр изменений файлов конфигурирования +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Версия | Перечень изменений (относительно предыдущей версии) | +========+============================================================================================================================================================+ | 3.0.0 | - Добавлены параметры подключения к Ядру ``data-center.nodes.node*.broker-addresses``; | | | | | | - Версия Java обновлена до 17.0.5. | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.1.0 | В Агент добавлена дополнительная точка подключения API gateway - порт 8172 (:numref:`connect_smev`). | | | | | | Указана возможность изменения портов для обращения ИС Инициатора к Агенту при обмене через API Gateway (:numref:`api_gateway`). | | | | | | В файл конфигурации добавлен параметр ``podd-client.pool.size``. | | | | | | Добавлены разделы по настройке и развертыванию NTP-сервера: | | | | | | - настройка подключения к NTP; | | | | | | - настройка и запуск NTP-сервера БЕЗ использования Docker; | | | | | | - настройка и запуск NTP-сервера с использованием Docker. | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.2.0 | Добавлен раздел ``podd-client.routes`` в конфигурационные файлы для подключения к одному ЦОД. | | | | | | Исключены параметры: | | | | | | - ``datamart-registration.datamarts.registrationFlow``; | | | | | | - ``data-center.default-node.pulsar.auth.keycloak-connection.tls-verify-host-name``; | | | | | | - ``data-center.signature.additional-properties``; | | | | | | - ``allowance.enabled``. | | | | | | Добавлен конфигурационный файл ``postgresql.json``. | | | | | | Добавлен раздел по заданию настроек в файле ``postgresql.json``: | | | | | | - настройка предустановленного профиля Витрины в Агенте СМЭВ4. | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.2.1 | Изменений нет | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.3.0 | Исключены параметры: | | | | | | - ``api-gateway.client.options.pipelining``; | | | | | | - ``api-gateway.client.options.pipeliningLimit``. | | | | | | С данного релиза возможно использование ключей CryptoPro, содержащих пробелы в алиасе. | | | | | | Изменён ``systemd unit`` для запуска агента, (:numref:`agent_start`). | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.4.0 | Изменений нет | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.5.0 | Добавлен раздел ``spring.profiles.active`` для настройки активного функционала Агента СМЭВ4. | | | | | | Добавлены параметры управления созданием топиков Apache Kafka: | | | | | | - ``datamart.create-topics.config``; | | | | | | - ``datamart.create-topics.query``; | | | | | | - ``datamart.create-topics.replication``; | | | | | | - ``datamart-registration.create-topics``; | | | | | | - ``replication.create-topics``; | | | | | | - ``query.create-topics``; | | | | | | Исключен параметр ``datamart.enabled`` (начиная с данной версии отключение производится с помощью выбора необходимой функции параметром | | | ``spring.profiles.active``). | | | | | | Версия JDK обновлена до 17.0.6. При варианте установки без использования Docker требуется обновление JDK на сервере, на котором устанавливается Агент. | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.6.0 | Изменений нет | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.7.0 | Версия JDK обновлена до 17.0.7. При варианте установки без использования Docker требуется обновление JDK на сервере, на котором устанавливается Агент. | | | | | | Изменен формат указания подключения к keycloak: ``nodes.ID.pulsar.auth.keycloak-oauth.auth-server-url`` изменен на список адресов URL в параметре | | | ``nodes.ID.pulsar.auth.keycloak-oauth.auth-server``. | | | | | | Добавлены параметры времени активации Агента (:numref:`time_set`). | | | | | | Добавлен параметр управления используемым транспортом (Rsocket/Pulsar): ``agent.use-ca`` (:numref:`common_settings`) | | | | | | Удален параметр настройки передачи событий Витрины в СЦЛ через Rsocket ``cls.datamart.use-ca``, транспорт определяется общим параметром ``agent.use-ca`` | | | (:numref:`common_settings`). | | | | | | Добавлено ограничение на использование транспорта Rsocket при обмене по Регламентированным REST-запросам (:numref:`connect_smev`): | | | | | | - значение параметра ``agent.use-ca`` должно быть ``true`` как на стороне Потребителя, так и на стороне Поставщика (:numref:`common_settings`); | | | | | | - версия Агента Потребителя и Поставщика должна быть не ниже 3.8.0; | | | | | | - Потребитель и Поставщик должны использовать единый транспорт (Rsocket/Pulsar). | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.8.0 | Добавлен параметр для управления возможностью получения метаданных Витрин при использовании JDBC-драйвера: ``query.metadata.storeToDb``. | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.9.0 | Изменений нет | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.9.1 | Изменений нет | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.10.0 | Добавлено описание параметров создания топиков Kafka (:numref:`topic_set_params`). | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.11.0 | Изменений нет | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.12.0 | Исключен параметр ``query.metadata.storeToDb``. | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.13.0 | Исключены параметры: | | | | | | - ``datamart-registration.datamarts.registrationFlow``; | | | | | | - ``datamart-registration.datamarts.definedProfile``. | | | | | | Исключен файл ``postgresql.json`` | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.14.0 | Исключены параметры: | | | | | | - ``trust-store.path``; | | | | | | - ``trust-store.password``; | | | | | | - ``data-center.default-node.pulsar.auth.keycloak-oauth.auth-type``; | | | | | | - ``data-center.default-node.pulsar.auth.keycloak-oauth.auth-protocol``; | | | | | | - ``data-center.signature.keystoreType``. | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.15.0 | Добавлены параметры: | | | | | | - ``datamart.integration.blobAdapter.host``; | | | | | | - ``datamart.integration.blobAdapter.port``; | | | | | | - ``datamart.integration.prostore.host``; | | | | | | - ``datamart.integration.prostore.port``; | | | | | | - ``datamart.integration.type``. | | | | | | Параметр ``datamart.kafka-bootstrap-servers`` изменен на ``datamart.integration.kafka.kafka-bootstrap-servers``. | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.16.0 | Добавлены опциональные параметры: | | | | | | - ``notarius.target-host``; | | | | | | - ``notarius.target-port``. | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.17.0 | Изменений нет | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.18.0 | Исключены параметры: | | | | | | - ``agent.use-ca``; | | | | | | - ``nodes.*node*.pulsar.*``; | | | | | | - ``rest-query-endpoint.blobAutoresolve``; | | | | | | - ``rest-query-endpoint.jdbc-url``; | | | | | | Добавлен параметр: | | | | | | - ``nodes.*node*.auth.*``. | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.19.0 | Изменений нет | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.20.1 | Исключен параметр ``datamart.zero-base-chunk-num``. | | | | | | Значение параметра ``query.default-query-timeout`` по умолчанию установлено в 20 секунд . | | | | | | Изменены способы включения и настройки логирования для платформы Гостех (:numref:`gostech_logging`). | | | | | | Добавлена возможность сохранения тел запросов во внешнюю систему (Clickhouse) (:numref:`clickhouse_logging`). | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.21.0 | Исключены параметры | | | | | | - ``core.mnemonic``; | | | | | | - ``core.broadcast-tenant``. | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.22.0 | Изменений нет | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.23.0 | Добавлен параметр ``replication.default-rest-timeout``. | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.24.0 | Изменений нет | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.25.0 | Добавлен блок параметров ``legal-evidence`` в рамках обеспечения возможности подтверждения неизменности данных (:numref:`legal_evidence`). | | | | | | В разделы :numref:`agent_set_start`, :numref:`agent_start` добавлено описание использования каталога временных файлов, для исключения | | | проблем связанных с ограничениями операционных систем. | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.26.0 | Исключено использование таблицы роутинга (раздел ``routes:`` в конфигурационном файле). | | | | | | Исключено использование "протокол 1" для интерфейса API Gateway, и соответствующего ему порта 8171 (:numref:`api_gateway`). | | | | | | Добавлено описание необходимости использования внешнего балансировщика при использовании API Gateway в случае использования | | | масштабированного агента (:numref:`api_gateway`). | | | | | | Добавлено явное указание подключения ко всем брокерам Ядра СМЭВ4, а также добавлен опциональный блок адресов broker-cross-addresses, для | | | тех соединений с Ядром СМЭВ4, где возможно резервное кросс-ЦОД подключение (:numref:`geo_config_set`). | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 3.27.0 | Исключен параметр ``agent-info.instanceId`` в конфигурационном файле, :numref:`multiple_instances`. | | | | | | Добавлена возможность переопределения вывода логов в файл, а также их ротации, без использования механизмов systemd, :numref:`file_logging`. | | | | | | Расширены настройки логирования в формате "Гостех" (ротация и хранение логов), см. :numref:`gostech_logging`. | | | | | | Добавлен параметр ``Restart=on-success`` в пример файла einfahrt.service (см. :numref:`agent_start`). | +--------+------------------------------------------------------------------------------------------------------------------------------------------------------------+ .. _config: Формирование конфигурационного файла Агента СМЭВ4 ------------------------------------------------- .. _common_settings: Общие настройки Агента ~~~~~~~~~~~~~~~~~~~~~~ .. _select_profiles: 1. При необходимости настройте список активного функционала Агента СМЭВ4. .. note:: Предоставляемый шаблон конфигурационного файла имеет настройку по умолчанию для данного параметра. Применять изменения следует только в случае, если значения по умолчанию не подходят для данного Агента СМЭВ4. Параметр необязательный и может отсутствовать в конфигурационном файле. По умолчанию (при отсутствии в конфигурационном файле данного параметра) активен весь функционал Агента СМЭВ4. В предлагаемых шаблонах конфигурационных файлов указаны профили **QueryConsumer**, **ApiGwConsumer**, **ApiGwProvider** только для файлов конфигурации ``prod/*-consumer-*.yml``. Для файлов ``*-producer-*.yml`` данный блок отсутствует. .. code-block:: yaml # Общие настройки агента # Оставить только нужные профили (т.е. только профили используемого функционала) spring: profiles: active: # потребитель SQL-запросов - QueryConsumer # поставщик ответов на SQL-запросы - QueryProvider # потребитель уведомлений - ReplicationConsumer # поставщик дельт по подпискам - ReplicationProvider # потребитель REST РЗ - ApiGwConsumer # поставщик ответов по REST РЗ - ApiGwProvider Пример: в случае использования Агента СМЭВ4 только как Инициатора (Потребителя), укажите в данном списке конфигурационного файла только значения ``*Consumer``. 2. Укажите идентификатор Агента СМЭВ4: - идентификатор Агента (мнемоника соответствующей ИС из ЛК УВ); - ОГРН Агента (ОГРН организации владельца ИС из ЛК УВ) .. code-block:: yaml agent: # Идентификатор (мнемоника) агента # При использовании id или ogrn состоящих только из цифр, их следует заключать в одинарные или двойные кавычки id: '*** ИДЕНТИФИКАТОР (МНЕМОНИКА) АГЕНТА ***' ogrn: '*** ОГРН АГЕНТА ***' .. _multiple_instances: Использование нескольких экземпляров Агента СМЭВ4 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Агент СМЭВ4 поддерживает одновременную работу нескольких экземпляров приложения с одинаковой мнемоникой и ОГРН. Такой подход может быть полезен, когда: 1. **Необходимо разделить потоки данных**: например, один экземпляр работает с внутренней базой данных организации, а второй — с внешней информационной системой той же организации. Ключевым условием для такой конфигурации является разделение функционала между экземплярами. Наборы активных профилей (``spring.profiles.active``) в их конфигурационных файлах не должны пересекаться. Это позволяет логически и физически разделить обязанности. Например, один экземпляр может быть сконфигурирован исключительно как Потребитель, а второй — исключительно как Поставщик. Пример конфигурации: - Конфигурационный файл первого экземпляра (только Потребитель): .. code-block:: yaml spring: profiles: active: - QueryConsumer - ReplicationConsumer - ApiGwConsumer - Конфигурационный файл второго экземпляра (только Поставщик): .. code-block:: yaml spring: profiles: active: - QueryProvider - ReplicationProvider - ApiGwProvider 2. **Необходимо реализовать горизонтальное масштабирование** системы для повышения отказоустойчивости и производительности. Наборы активных профилей (``spring.profiles.active``) в их конфигурационных файлах идентичны. При использовании Агента СМЭВ4, каждый экземпляр КриптоПро CSP 5 R3 должен работать под лицензией и не нарушать лицензионных условий производителя (:numref:`software_list`). .. _cryptopro_set: Настройка ключей CryptoPro ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Укажите идентификатор и пароль контейнера ключа CryptoPro: .. code-block:: yaml keys: alias: '*** ИДЕНТИФИКАТОР КЛЮЧА CryptoPro ***' password: '*** ПАРОЛЬ КЛЮЧА CryptoPro ***' Подробная информация об идентификаторе ключа и о том, как получить контейнер закрытого ключа электронной подписи находится `на портале ЕСКС `_. .. note:: Указывать параметр password не требуется, если используется сервис подписания и верификации сообщений (:numref:`auth_type_set`). В случае, если идентификатор ключа CryptoPro содержит пробелы, его следует заключить в одинарные кавычки. .. _geo_config_set: Настройка подключения к Ядру СМЭВ4, в том числе для работы в гео-распределенной конфигурации ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Предоставляемый шаблон конфигурационного файла имеет настройку по умолчанию для данного параметра. Применять изменения следует только в случае, если значения по умолчанию не подходят для данного Агента СМЭВ4.* Для настройки Агентов необходимо перечислить все Ядра СМЭВ4 (nodes), к которым подключается Агент СМЭВ4, с указанием адресов брокеров и сервиса авторизации Ядра СМЭВ4. Пример раздела конфигурации: .. code-block:: yaml # Настройки подключения ко всем ЦОД с установленным ПО Ядра СМЭВ4 data-center: … nodes: - node-id: {{ node1_name }} # Адреса брокеров broker-addresses: - host: {{ broker1-host }} port: {{ broker1-port }} - host: {{ broker2-host }} port: {{ broker2-host }} # Адреса брокеров с использованием кросс-ЦОД подключения. При отсутствии возможноси кросс-ЦОД подключения, параметр не указывается broker-cross-addresses: - host: {{ broker1-host cross-connect }} port: {{ broker1-port cross-connect }} - host: {{ broker2-host cross-connect }} port: {{ broker2-host cross-connect }} auth: oauth: auth-server: # список адресов серверов авторизации. # Может быть указано несколько адресов списком. - url: {{ authentication_kernel1_address_1 }} - url: {{ authentication_kernel1_address_2 }} - node-id: {{ node2_name }} broker-addresses: {...} broker-cross-addresses: {...} auth: oauth: auth-server: # Может быть указано несколько адресов списком. - url: {{ authentication_kernel2_address_1 }} - url: {{ authentication_kernel2_address_2 }} {...} .. note:: Предоставляемые шаблоны конфигурационных файлов содержат предустановленные значения для данных параметров, и в общем случае не требуют изменения. .. note:: В тех случаях, когда Агент СМЭВ4 размещается за NAT или Reverse Proxy, значения параметров в списках ``broker-addresses``, и (при использовании) ``broker-cross-addresses``, следует заменить на адреса и порты используемого NAT/RP, строго соответствующие тем адресам и портам брокеров, на которые осуществляет трансфер соединений упомянутый NAT/RP .. attention:: При использовании NAT/RP, каждый коннект к каждому брокеру (host:port) должен пробрасываться индивидуально. Недопустимо использовать один порт NAT/RP для передачи данных на несколько разных адресов (портов) брокеров. В блоке ``data-center.default-node`` описаны параметры, общие для подключения ко всем Ядрам СМЭВ4. Как правило, их изменение не требуется относительно значений по умолчанию. .. _ntp_set: Настройка подключения к NTP-серверу ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Предоставляемый шаблон конфигурационного файла имеет настройку по умолчанию для данного параметра. Применять изменения следует только в случае, если значения по умолчанию не подходят для данного Агента СМЭВ4.* В данном разделе необходимо указать один или более IP-адресов или HOSTNAME NTP-сервера. .. code-block:: yaml ntp: - host: {{ IP адрес или HOSTNAME NTP }} В случае, если используется поставляемый в комплекте с Агентом СМЭВ4 пакет **chrony**, в данном параметре конфигурационного файла Агента СМЭВ4 следует указать IP-адрес, на котором работает **chrony**. .. _reg_set: Взаимодействие с Витринами данных через Apache Kafka (версия Витрины 1.x) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Для обеспечения взаимодействия Агента СМЭВ4 с Витриной (версия Витрины 1.x), необходимо выполнить настройку подключения к Apache Kafka. .. attention:: указание адреса сервера(серверов) Apache Kafka (параметр ``datamart.integration.kafka.kafka-bootstrap-servers``) обязателен, если используется хотя бы один профиль из списка: **QueryProvider**, **ReplicationConsumer**, **ReplicationProvider**. Список включенных профилей определяется параметром ``spring.profiles.active`` (:numref:`multiple_instances`). .. _topic_set: Настройка создания топиков Агентом СМЭВ4 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Далее приведено описание раздела конфигурации для настройки создания топиков Агентом СМЭВ4. Доступна настройка взаимодействия нескольких схем Витрины данных через одну группу топиков. Схемы Витрины могут общаться через одну группу топиков только в случае, если относятся к одному Компоненту «Витрина данных» и являются схемами одной (физической) Витрины. Блок параметров ``datamarts.create-topics`` может отсутствовать в конфигурационном файле, в этом случае используются значения по умолчанию: включено автоматическое создание топиков для всех видов информационного обмена (Регламентированные SQL-запросы, Рассылки), отключено автоматическое создание топиков регистрации и настройки Витрин. :numref:`tab_params` содержит соответствие создаваемых топиков Apache Kafka параметрам конфигурационного файла. .. _tab_params: .. table:: Соответствие параметров конфигурационного файла и создаваемых топиков +---+----------------------------------+---------------------+-------------------------------------------------+ | № | Настройка | Параметр | Создаваемые топики [4]_ | +===+==================================+=====================+=================================================+ | 1 | Топики для информационного | query | - Топики для обеспечения информационного обмена | | | обмена с использованием | | с использованием SQL-запросов; | | | Регламентированных SQL-запросов | | | | | | | - Топики для получения статистики по Витринам; | | | | | | | | | | - Топики для получения событий Витрины. | +---+----------------------------------+---------------------+-------------------------------------------------+ | 2 | Топики для информационного | Replication, | - Топики для обеспечения информационного обмена | | | обмена с использованием Рассылок | | с использованием подписок (для Поставщика); | | | | ReplicationProvider | | | | | | - Топики для получения событий Витрины. | | | +---------------------+-------------------------------------------------+ | | | Replication, | - Топики для обеспечения информационного обмена | | | | | с использованием подписок (для Потребителя); | | | | ReplicationConsumer | | | | | | - Топики для получения событий Витрины. | +---+----------------------------------+---------------------+-------------------------------------------------+ | 3 | Топики регистрации и настройки | config | - Топики регистрации и настройки Витрин. | | | Витрин | | | +---+----------------------------------+---------------------+-------------------------------------------------+ .. [4] В соответствии с разделами 2.3 и 2.5 документа «Методические рекомендации по работе с СМЭВ4», размещенном на `портале ЕСКС `_ Для настройки создания топиков для обмена по Рассылкам только для Поставщика или Потребителя необходимо использовать настройки активного функционала Агента СМЭВ4 ``Replication``, указанные в :numref:`common_settings`. Если инициатором обмена по Рассылке является Витрина или ИС Потребителя для корректного осуществления обмена необходимо задать один из видов настроек: - при использовании режима COMPATIBLE прописать Витрину в блоке ``datamarts:``; - установить режим ENABLED для создания общей группы топиков при старте Агента. В случае отсутствия Витрин у Агента СМЭВ4 есть возможность отключить функционал в соответствии с :numref:`common_settings`. В этом случае раздел ``datamart-registration`` может полностью отсутствовать в конфигурационном файле. .. code-block:: yaml # Общие настройки витрин datamart: integration: # подключение к Kafka для взаимодействия с витринами kafka: kafka-bootstrap-servers: {{ kafka_link }} # автоматическое создание топиков витрины create-topics: # регистрация и настройка витрины config: false # информационный обмен с использованием SQL query: true # репликация replication: true # Настройки регистрации витрин. # - Витрины могут регистрироваться в агенте двумя способами: # - статически - витрина прописывается в конфиге агента (блок datamarts:), в этом случае используются # прописанные для данной витрины настройки, топики витрины создаются и слушаются агентом при старте; # - динамически - автоматическая регистрация, в этом случае используется общий набор настроек (блок dynamic:); # - Если агенту приходит сообщение из ядра для незарегистрированной витрины, агент регистрирует её динамически. # - Регистрация витрины также может быть инициирована со стороны витрины, через специальный топик, в # этом случае витрина регистрируется динамически, если она не прописана статически. Это позволяет # получать профиль запросом с витрины при динамической регистрации. # - Через некоторый таймаут (inactive-cleanup-delay) если к витрине не приходят запросы, агент её # деактивирует (выключаются потребители и удаляются топики) для экономии ресурсов; # - Если агенту приходит сообщение из ядра для деактивированной витрины, агент её активирует обратно. # - Профиль витрины отсылается в ядро каждый раз при старте агента для всех динамически и статически # зарегистрированных витрин, а также во время динамической регистрации витрин; datamart-registration: # Список статически регистрируемых витрин. # Можно задать пустой список [], параметры витрины: # id - *** ИДЕНТИФИКАТОР ВИТРИНЫ (мнемоника витрины в нижнем регистре) *** # inactive-cleanup-delay - задержка перед деактивацией витрины, 0 - никогда не деактивировать, по умолчанию 0; # topic-name-prefix - *** ЛИБО ИДЕНТИФИКАТОР ВИТРИНЫ (если не указывать, то по умолчанию id витрины) / ЛИБО ИДЕНТИФИКАТОР ГРУППЫ ВИТРИН *** datamarts: - id: {{ vitrine_id1 }} - id: {{ vitrine_id2 }} # Настройки для динамически регистрируемых витрин dynamic: # Режим работы динамической регистрации: # - ENABLED - динамическая регистрация включена, общие топики создаются и слушаются агентом при старте; # - COMPATIBLE - режим по умолчанию, для обратной совместимости. Если список статических витрин пуст (datamarts: []) # то работает аналогично как в режиме ENABLED. Если список статических витрин не пуст, то общие топики создаются # при первой динамической регистрации витрины; # - DISABLED - динамическая регистрация отключена; mode: COMPATIBLE # Задержка перед деактивацией витрины, 0 - никогда не деактивировать inactive-cleanup-delay: 0 # Префикс имен топиков, по умолчанию без префикса topic-name-prefix: '' Если схема Витрины не прописана в блоке ``datamart-registration.datamarts``, то она будет подключена через группу топиков, используемую по умолчанию. Если прописать в конфиге несколько Витрин статически, а префикс оставить по умолчанию, то будет создана отдельная группа топиков для каждой из прописанных статически Витрин (с соответствующим префиксом). Если прописать в конфиге несколько Витрин статически и задать префикс, то все Витрины, прописанные статически, будут общаться через общую группу с указанным префиксом. Схемы Витрины, указанные в блоке ``datamart-registration.datamarts``, могут быть сконфигурированы для общения через отдельную группу топиков или через группу топиков по умолчанию. Например: .. code-block:: yaml datamart-registration: datamarts: # подключение через группу топиков со значением префикса по умолчанию - id: {{ vitrine_id1 }} topic-name-prefix: 'vitrine_id1' # подключение нескольких схем Витрин через отдельную группу топиков - id: {{ vitrine_id2 }} topic-name-prefix: 'common' - id: {{ vitrine_id3 }} topic-name-prefix: 'common' # подключение через группу топиков по умолчанию, в соответствии с настройками в блоке dynamic - id: {{ vitrine_id4 }} topic-name-prefix: '' dynamic: mode: COMPATIBLE inactive-cleanup-delay: 0 topic-name-prefix: '' .. _topic_set_params: Настройка параметров создаваемых топиков (опционально) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Для создаваемых топиков имеется возможность указывать их параметры: фактор репликации, количество партиций и т.п. Параметры влияют на все топики, создаваемые агентом. Пример: .. code-block:: yaml kafka: topic: property: num.partitions: 1 # дефолтное значение 1 replication.factor: 1 # дефолтное значение 1 Также можно задавать и другие параметры топиков, описание которых находится по адресу https://kafka.apache.org/documentation/#topicconfigs. Пример: .. code-block:: yaml kafka: topic: property: cleanup.policy: delete Использование параметров не определенных в https://kafka.apache.org/documentation/#topicconfigs или ``num.partitions / replication.factor`` будет приводить к ошибке при создании топика. Настройка взаимодействия через пользовательские топики (опционально) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Для настройки взаимодействия с Витриной через пользовательские топики выполните следующие шаги: 1. Отключите автосоздание топиков Apache Kafka Агентом, указав следующие значения параметров в конфигурационном файле Агента СМЭВ4: .. code-block:: yaml datamart: # автоматическое создание топиков витрины create-topics: # регистрация и настройка витрин config: false # информационный обмен с использованием SQL query: false # репликация replication: false 2. Отключите возможность автосоздания топиков на стороне Apache Kafka. Для этого в конфигурации Apache Kafka укажите параметр ``auto.create.topics.enable=false`` в соответствии с https://kafka.apache.org/documentation/. 3. Создайте в Apache Kafka необходимые топики вручную в соответствии с https://kafka.apache.org/documentation/#basic_ops_add_topic. 4. Если имена созданных топиков отличаются от имен по умолчанию, укажите в конфигурационном файле Агента СМЭВ4 имена используемых топиков. В примере указаны имена топиков, используемые по умолчанию: .. code-block:: yaml replication: subscription: # Топик запросов на регистрацию подписки (Агент -> Витрина) registration-request-topic: replication.rq # Топик ответов с успешным результатом регистрации подписки (Витрина -> Агент) registration-result-topic: replication.rs # Топик ответов с ошибками регистрации подписки (Витрина -> Агент) registration-error-topic: replication.err # Топик запросов на отмену подписки у поставщика (Агент -> Витрина) cancel-request-topic: replication.cancel.rq # Топик ответов с результатом отмены подписки у поставщика (Витрина -> Агент) cancel-result-topic: replication.cancel.rs # Топик запросов на отмену подписки у потребителя (Агент -> Витрина) cancel-consumer-request-topic: replication.cancel.in.rq # Топик ответов с результатом отмены подписки у потребителя (Витрина -> Агент) cancel-consumer-result-topic: replication.cancel.in.rs # Топик команд по репликации посылаемых от витрины в сторону ядра (Витрина -> Агент) command-topic: command.podd # Параметры конфигурирования топиков для запросов/ответов на создание хранилищ реплик (Агент <-> Витрина) storage: # Топик запросов на создание структуры для хранения реплик (Агент -> Витрина) request-topic: replication.in.rq # Топик ответов с ошибками создания структуры хранения реплик (Витрина -> Агент) error-topic: replication.in.err # Топик ответов с успешным результатом создания структуры хранения реплик (Витрина -> Агент) response-topic: replication.in.rs # Параметры конфигурирования топиков работы с дельтами (Агент <-> Витрина) delta: # Топик запросов на получение дельт от поставщиков (Агент -> Витрина) request-topic: delta.rq # Топик запросов на получение дельт от поставщиков (Агент -> Витрина) request-tp-topic: delta.tp # Топик чанков с дельтами (Витрина -> Агент) response-topic: delta.rs # Топик ответов с ошибками для реплик (Витрина -> Агент) error-topic: delta.err # Топик чанков на применение дельты потребителем (Агент -> Витрина). # По умолчанию топик настроен под старую реализацию витрины. Для новой реализации витрины # которая поддерживает распределенные подписки, не важно, используете вы распределенные # подписки или обычные, в настройках агента за которым стоит новая реализация витрины # надо поменять имя топика на delta.in.tp: apply-request-topic: delta.in.rq # Топик чанков на применение дельты потребителем (Агент -> Витрина) apply-request-tp-topic: delta.in.tp # Топик ответов с ошибками применения дельты (Витрина -> Агент) apply-error-topic: delta.in.err # Топик ответов с успешным результатом применения дельты (Витрина -> Агент) apply-response-topic: delta.in.rs # Топик уведомлений о новых данных по подпискам от поставщика (Витрина -> Агент) notification-topic: delta.notification # Топик уведомлений потребителя о новых данных по подпискам (Агент -> Витрина) notification-datamart-topic: delta.notification.in # Настройки модуля обработки SQL подзапросов из ядра СМЭВ4 к витрине данных sub-query: # Настройки получения SQL подзапроса из ядра и отправки его в витрину request: # Топик отправки подзапросов к витрине (Агент -> Витрина) request-topic-name: query.rq # Топик подзапросов для вызова регламентированного запроса (хранимой процедуры) (Агент -> Витрина) regulated-query-request-topic-name: procedure.query.rq # Топик для передачи чанков табличного параметра (Агент -> Витрина) table-param-topic-name: query.tp # Топик для передачи чанков табличного параметра, нарезанных бинарно (Агент -> Витрина) binary-table-param-topic-name: query.tp.bin result: # Топик получения результатов исполнения SQL подзапросов от витрины (Витрина -> Агент) result-topic-name: query.rs # Топик получения ошибок исполнения SQL подзапросов от витрины (Витрина -> Агент) error-topic-name: query.err # Топик ответов с оценкой (статистикой) по исполнению подзапросов (Витрина -> Агент) query-estimation-topic-name: query.estimation.rs # Настройки модуля обработки SQL запросов отправляемых в ядро СМЭВ4 query: # Обработчик отмены SQL запросов cancel: # Топик нотификаций витрины об отмене SQL запроса (Агент -> Витрина) request-topic-name: cancel.rq # Топик передачи результата об отмене SQL запроса (Витрина -> Агент) result-topic-name: cancel.rs # Топик передачи ошибок отмены SQL запроса (Витрина -> Агент) error-topic-name: cancel.err # Настройки получения BLOB по ссылке load-reference-data: # Топик запроса по BLOB ссылке (Агент -> Витрина) request-topic-name: blob.rq # Ответный топик с данными (чанки) по BLOB ссылке (Витрина -> Агент) result-topic-name: blob.rs # Ответный топик с ошибками обработки запроса по BLOB ссылке (Витрина -> Агент) error-topic-name: blob.err # Настройки модуля сбора Статистики statistic: # Топик с запросами на сбор статистики (Агент -> Витрина) requestTopicName: statistic.rq # Топик с результатами сбора статистики (Витрина -> Агент) responseTopicName: statistic.rs # Конфиг модуля регистрации профиля витрины в ядре datamart-profile: # Топик с запросами профиля у витрины (Агент -> Витрина) datamartRequestTopic: profile.rq # Топик ответов за запросы профиля у витрины (Витрина -> Агент) datamartResponseTopic: profile.rs # Топик с неуспешными ответами на запросы профиля у витрины (Витрина -> Агент) datamartErrorTopic: profile.err cls: datamart-topic: scl.signal 5. Если имена созданных топиков отличаются от имён по умолчанию, укажите использование пользовательских топиков на стороне Витрины в конфигурации СМЭВ4-Адаптера – Модуль исполнения запросов, согласно разделу «Спецификация модуля СМЭВ4-адаптера – Модуль исполнения запросов» Руководства администратора Компонента «Витрина данных». Взаимодействие с Витринами данных по HTTP (версия Витрины 2.x) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Для обеспечения взаимодействия Агента СМЭВ4 с Prostore на стороне Витрины (версия Витрины 2.x), скопируйте данный блок в файл ``application.yml`` и заполните параметры ``datamart.integration.prostore.*`` актуальными данными: .. code-block:: yaml datamart: integration: type: HTTP prostore: host: '*** prostore_host ***' port: '*** prostore_port ***' Настройка организации информационного обмена с БЛОБ-адаптером (требуется только при включенном профиле QueryProvider) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Для обеспечения прямого взаимодействия Агента СМЭВ4 с БЛОБ-адаптером на стороне Витрины, скопируйте данный блок в файл ``application.yml`` и заполните параметры ``datamart.integration.blobAdapter.*`` актуальными данными: .. note:: Указание данного параметра требуется только при включенном профиле QueryProvder (:numref:`common_settings`). .. code-block:: yaml datamart: integration: blobAdapter: host: '*** blob_adapter_host ***' port: '*** blob_adapter_port ***' .. _printable_form_set: Настройка сервиса формирования документов ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Для настройки сервиса формирования документов (на стороне Поставщика) перечислите используемые сертификаты для данного модуля и данные о них. При отсутствии используемых печатных форм, данный раздел в конфигурации должен отсутствовать. Пример раздела конфигурации: .. code-block:: yaml printable-form: # Максимальный размер данных для подписания max-content-length: 268435456 # Настройка каким сертификатом подписать результат какого запроса. # Пары значений "название регламентированного запроса": "алиас сертификата" forms: {{ form1_name }}: {{ key1 }} {{ form2_name }}: {{ key2 }} {...} signature: printable-form-keys: - certificateAlias: {{ key1 }} privateKeyAlias: {{ key1 }} privateKeyPass: {{ key1_password }} - certificateAlias: {{ key2 }} privateKeyAlias: {{ key2 }} privateKeyPass: {{ key2_password }} {...} Настройка использования S3 для передачи БЛОБов (опционально) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ *Раздел применим только при использовании хранилища типа S3 (на стороне Поставщика). В случае если хранилище S3 не используется, данный раздел в конфигурационном файле может отсутствовать.* Для настройки использования S3 для передачи блобов укажите адрес точки доступа и ссылку на файл с учётными данными для подключения к S3. Bucket с соответствующим именем должен быть предварительно создан на стороне S3. Также в файле ``s3_creds.properties`` пропишите корректные значения логина и пароля для подключения к хранилищу S3. Данный файл создается вручную, при наличии необходимости в нем. Формат указания учетных данных в файле ``s3_creds.properties``: .. code-block:: bash accessKey = '*** логин ***' secretKey = '*** пароль ***' В случае, если S3 не используется (т.е. параметр ``blob-source`` имеет значение ``DATAMART``), адрес, bucket и путь могут быть указаны любые, либо отсутствовать. Пример раздела конфигурации: .. code-block:: yaml query: # Настройки получения BLOB по ссылке load-reference-data: # Источник получения данных для BLOB ссылок, # S3 - данные загружаются агентом из хранилища S3, DATAMART - запрос пересылается витрине blob-source: DATAMART # Настройки подключения к хранилищу S3 s3-storage: endpoint: http://{{ s3_url }}/ # Имя бакета bucket-name: {{ bucket name }} # Путь к файлу с данными для авторизации pathToCredentialFile: {{ /absolute/path/to/s3_creds.properties }} Настройки разбиения получаемой информации на чанки (опционально) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Предоставляемый шаблон конфигурационного файла имеет настройку по умолчанию для данного параметра. Применять изменения следует только в случае, если значения по умолчанию не подходят для данного Агента СМЭВ4.* Доступна возможность указания способа разбиения получаемой информации при выполнении Регламентированных SQL-запросов на чанки. Для настройки разбиения получаемой информации на чанки при выполнении запроса через REST-интерфейс в конфигурационном файле Агента СМЭВ4 задайте параметр ``rest-query-endpoint.tableParamChunkType``, который может принимать значения: - EXACTLY_CUT – позволяет разбивать информацию на чанки исходя из размера чанка (размер чанка указывается параметром ``rest-query-endpoint.tableParamChunkSize``, значение по умолчанию 900 KB); - EVEN_ROWS – запрещает разбиение информации между чанками (автономно десериализуемые чанки), не гарантируется соблюдение размера чанка. Пример раздела конфигурации для настройки выполнения запросов через REST-интерфейс: .. code-block:: yaml # Настройки REST сервера исполнения SQL запросов rest-query-endpoint: # Размер чанка пользовательского табличного параметра tableParamChunkSize: 900KB # Способ разбиения пользовательского табличного параметра на чанки tableParamChunkType: EXACTLY_CUT Для настройки разбиения получаемой информации на чанки для JDBC-драйвера добавьте в свойства драйвера параметр ``tableParamChunkType``, который может принимать значения: - ``EXACTLY_CUT`` – позволяет разбивать информацию на чанки исходя из размера чанка (размер чанка указывается дополнительным свойством в настройках драйвера ``tableParamChunkSize``, например ``tableParamChunkSize =100KB``); - ``EVEN_ROWS`` – запрещает разбиение информации между чанками (автономно десериализуемые чанки), не гарантируется соблюдение размера чанка. .. _api_gateway: Настройка организации информационного обмена через API Gateway (опционально) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Настройка информационного обмена через API Gateway для выполнения запросов к REST-сервису ИС Поставщика. .. attention:: Данная настройка опциональна, применяется только при использовании API Gateway; Некоторые шаги выполняются только при использовании **HTTPS** для коммуникации, подробнее см. в описании шагов Если требуется настройка, то: - шаги 1-4 выполняются в рамках организации информационного обмена через API Gateway **по HTTPS**; - шаг 5 только для Агента Поставщика/ответчика; - шаг 6 только для Агента Потребителя/инициатора запроса. 1. Скопируйте файл ``cacerts java`` в локальный каталог (Java должна быть установлена, :numref:`pre_requisites`): .. code-block:: bash cp /usr/lib/jvm/axiomjdk-java17.x86_64/lib/security/cacerts /distr/einfahrt/certs/cacerts 2. Произведите импорт сертификата в java cacerts. Пример раздела конфигурации: .. code-block:: bash keytool -importcert -keystore /distr/einfahrt/certs/cacerts -storepass changeit -alias api-gateway -file cert.crt - ``changeit`` - пароль по умолчанию для cacerts; - ``cert.crt`` – файл с сертификатом используемым на стороне HTTPS-сервера поставщика данных. 3. В параметры запуска агента добавьте ключи ``-Djavax.net.ssl.keyStore=certs/cacerts`` и ``-Djavax.net.ssl.trustStore=certs/cacerts``. При использовании systemd (:numref:`agent_start`) данные параметры добавьте в строку описания переменных окружения: ``Environment="JDK_JAVA_OPTIONS=…``. 4. Произведите настройку модуля для работы по HTTPS. Пример раздела конфигурации: .. code-block:: yaml # Настройка модуля API gateway api-gateway: # Параметры HTTP-клиента для отправки запросов на стороне поставщика client: impl: APACHE options: # указать адрес и порт http(s) сервера default-host: '*** адрес подключения к серверу ***' default-port: '*** адрес подключения к серверу ***' ssl: true # false при использовании http verifyHost: false maxPoolSize: 100 5. При необходимости настройки таймаутов укажите опциональные параметры (ниже приведены дефолтные значения, которые используются в случае, если параметры не указаны явно): .. code-block:: yaml # Настройка модуля API gateway api-gateway: # Параметры HTTP-клиента для отправки запросов на стороне поставщика client: options: connectTimeout: 10000 #таймаут подключения, мс idleTimeout: 60000 #таймаут бездействия, мс maxPoolSize: 100 #размер пула соединений maxWaitQueueSize: 0 #0 - не ждать, возвращает инициатору ошибку 503(service unavailable) #для impl=VERTX - число ожидающих запросов при исчерпании #пула соединений (-1 - неограниченная очередь), #для impl=APACHE - таймаут ожидания соединения #при исчерпании пула (-1 - неограниченное время #ожидания), мс 6. Маршрутизация запросов к разным REST-сервисам может быть реализована с помощью reverse proxy, например на основе Angie или Nginx. Это позволяет направлять трафик по префиксу URL (например, ``/api/v1/`` на сервис 1, ``/api/v2/`` на сервис 2) .. note:: Ниже приведен пример настройки, но в первую очередь следует руководствоваться инструкциями соответствующего производителя: `nginx `_, `angie `_. .. code-block:: bash http { # Определение первого REST сервиса upstream rest_service_1 { server 127.0.0.1: 8081; } # Определение второго REST сервиса upstream rest_service_2 { server 127.0.0.1: 8082; } server { listen 80; server_name example.com; # Маршрутизация на первый сервис location /api/v1/ { proxy_pass http: //rest_service_1; proxy_set_header Host $host; proxy_set_header X - Real - IP $remote_addr; } # Маршрутизация на второй сервис location /api/v2/ { proxy_pass http: //rest_service_2; proxy_set_header Host $host; proxy_set_header X - Real - IP $remote_addr; } } } 7. При необходимости изменения порта, используемого ИС Потребителя при обращении к Агенту СМЭВ4 по Регламентированным REST-запросам укажите значения следующих параметров: .. attention:: Версия Агента СМЭВ4 должна быть 3.8.0 или выше как у инициатора обмена, так и у ответчика. .. code-block:: yaml # Настройка модуля API gateway api-gateway: # Параметры HTTP-сервера для приёма запросов на стороне потребителя target-arch: server-port: 8172 .. note:: В случае использования более одного экземпляра агента ("масштабированный" агент), следует использовать внешний балансировщик запросов, например на основе angie или nginx. Для настройки балансировщика следует руководствоваться инструкциями соответствующего производителя: `nginx `_, `angie `_. .. _time_set: Настройка параметров времени активации Агента СМЭВ4 (опционально) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Данные параметры применяются для обеспечения обновления масштабированного Агента СМЭВ4 с нулевым временем простоя. В примере ниже указаны значения по умолчанию. .. code-block:: yaml agent-activation: # Таймаут ожидания активации экземпляра Агента при получении запроса component-activation-timeout: 1s # Код ошибки HTTP при попытке выполнения SQL запроса на неактивированном экземпляре агента inactive-query-http-error-code: 501 # Код ошибки HTTP при попытке выполнения APIGateway запроса на неактивированном экземпляре агента inactive-api-gw-http-error-code: 501 При последовательном обновлении экземпляров масштабированного Агента СМЭВ4 до новой мажорной версии, экземпляр Агента СМЭВ4 с новой версией не будет активирован до момента обновления других экземпляров. Выполнение запроса к не активированному экземпляру Агента СМЭВ4 приведет к ошибке (коды ошибок в соответствии с примером конфигурации выше), в таком случае система - инициатор запроса должна перенаправить запрос на другой экземпляр Агента СМЭВ4. .. _auth_type_set: Настройка подключения к сервису криптографии (опционально) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Агент СМЭВ4 может работать используя как встроенные средства криптографии, так и предоставляемые опциональным компонентом Notarius. В случае использования Notarius для средств криптографии, добавьте блок ``notarius`` в файл ``application.yml`` и заполните параметр ``notarius.target-host``. Пример раздела конфигурации (номер порта должен соответствовать указанному в конфигурационном файле Notarius, :numref:`notarius_config`): .. code-block:: yaml notarius: enabled: true endpoints: - target-host: '*** IP АДРЕС ПЕРВОГО СЕРВЕРА ПОДПИСАНИЯ И ВЕРИФИКАЦИИ СООБЩЕНИЙ СМЭВ4 ***' target-port: 8696 - target-host: '*** IP АДРЕС ВТОРОГО СЕРВЕРА ПОДПИСАНИЯ И ВЕРИФИКАЦИИ СООБЩЕНИЙ СМЭВ4 (при наличии) ***' target-port: 8696 {...} .. attention:: При использовании более одного экземпляра сервера подписания и верификации сообщений (Notarius), каждый экземпляр должен быть указан в вышеуказанном списке явным образом. НЕ ДОПУСКАЕТСЯ использование любого вида прокси и балансировщиков между Агентом СМЭВ4 и Сервером подписания и верификации сообщений СМЭВ4 (Notarius). При указании данного параметра внутренние криптографические функции в Агенте СМЭВ4 **не задействуются**. Настройка передачи информации аудита в ГосТех (опционально) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Для активации передачи информации аудита при работе Агента СМЭВ4 на платформе ГосТех скопируйте данный блок в файл ``application.yml`` и заполните параметры ``gostech.audit.*`` актуальными данными: .. code-block:: yaml gostech: enabled: true audit: host: '*** audit_server_host ***' port: '*** audit_server_port ***' Настройка параметров Сервиса проверки полномочий (опционально) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Для активации работы функций Сервиса проверки полномочий (:numref:`annex_b`), скопируйте данный блок в файл ``application.yml`` и заполните параметры ``allowance.prohibitor-client.*`` актуальными данными: .. code-block:: yaml allowance: enabled-sql: true enabled-api-gateway: true prohibitor-client: default-host: '*** prohibitor_server_host ***' default-port: '*** prohibitor_server_port ***' .. _metrics: Настройка таймаутов исполнения запросов по умолчанию (опционально) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Для изменения таймаутов по умолчанию (применяются при отсутствии таймаута в запросе) добавьте в конфигурацию Агента дополнительные параметры. (Примеры значений: 15s, 5m, 1h). При отсутствии параметра в конфигурации применяется значение по молчанию, указанное ниже. .. code-block:: yaml query: ... # Таймаут для SQL-запросов, включая запросы блобов через JDBC default-query-timeout: 20s # Таймаут для запросов блобов по ссылке через REST default-blob-query-timeout: 20s api-gateway: ... # Таймаут для API Gateway запросов default-apigw-query-timeout: 20s Настройка сбора метрик Агента СМЭВ4 (опционально) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Агент поддерживает возможность передачи метрик работы во внешнюю систему сбора метрик **Prometheus**. Для включения возможности передачи добавьте в конфигурационный файл следующие параметры: .. code-block:: yaml metrics: implementation: PROMETHEUS # порт, при обращении к которому Агент отдаёт значения метрик endpointPort: 8381 **Prometheus** следует настроить на опрос адреса, на котором запущен Агент СМЭВ4, по указанному порту. При запуске Агента под Docker добавьте указанный порт в список **expose ports** в скрипте запуска Агента. Список используемых метрик приведен в :numref:`annex_a`. .. _redefine_ports: Переопределение значений портов REST- и JDBC-интерфейсов Агента СМЭВ4 (опционально) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Порты REST- и JDBC-интерфейсов при необходимости можно изменить указанием следующих параметров в конфигурационном файле. Для REST-интерфейса (по умолчанию 8192): .. code-block:: yaml rest-query-endpoint: port: 8192 Для JDBC-интерфейса (по умолчанию 8183): .. code-block:: yaml query-server: port: 8183 В случае запуска Агента СМЭВ4 под Docker, измените значения портов в скрипте ``run_agent.sh`` (:numref:`start_docker`). .. _legal_evidence: Настройка возможности подтверждения неизменности данных (опционально) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ При необходимости включения возможности подтверждения неизменности данных [5]_ добавьте в конфигурационный файл следующие параметры: .. code-block:: yaml legal-evidence: exchange: # перечни РЗ заполняются только УВ с ролью Потребитель и Инициатор обмена regQueryMnemonics: # список SQL-РЗ, для которых Потребителю требуется подтверждение неизменности - datamart_1.1.0.rq_1 - datamart_2.rq_2 openApiPrefixes: # список REST-РЗ, для которых Инициатору требуется подтверждение неизменности - /rest-rq-one/api/v1 - /rest-rq-two/api/v1 # настройки подключения к хранилищу УВ storage: # вариант записи сообщений в хранилище: # DATABASE - включено сохранение сообщений в БД ClickHouse # S3 - включено сохранение сообщений в VK S3 # NONE - отключено сохранение сообщений type: DATABASE # параметры подключения к БД clickhouse click-house: url: jdbc:clickhouse://host:port/database_name user: user_login password: user_password # параметры подключения к VK S3 s3: endpoint: http://s3.fqdn bucket-name: name-of-the-bucket region: us-west-2 access-key: xxxxx secret-key: xxxxx .. [5] Описание функционала «Подтверждение неизменности данных, передаваемых при обменах по регламентированным запросам» приведено в документе «Методические рекомендации по работе с СМЭВ4», размещенном на портале ЕСКС Настройка Push-уведомлений при работе с SQL-РЗ (опционально) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ В случае если вызов SQL-РЗ происходил асинхронно и с использованием режима push, то в СМЭВ4 будет отрабатывать логика формирования и передачи push-уведомлений с результатами исполнения запроса. При необходимости включения функционала добавьте в конфигурационный файл следующие параметры: .. code-block:: yaml # Настройки передачи результата исполнения SQL запроса методом PUSH result-push: # Максимальное распараллеливание при обработке сообщений из ядра max-concurrency: 100 # Подключение к REST-сервису для приема push-уведомлений от Агента СМЭВ4 rest: base-url: http://127.0.0.1:8080/api/v1 # Максимальный размер тела одного push-уведомления max-push-size: 1MB # Количество повторных попыток отправки одного push-уведомления push-retry-count: 3 # Максимальный таймаут между попытками push-retry-timeout: 10s .. _logging_provider_setup: Настройка протоколирования тел запросов и ответов на стороне Поставщика (опционально) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. note:: Описание запуска Агента с данным протоколированием приведено в :numref:`clickhouse_logging` Для настройки функционала протоколирования тел запросов и ответов используются следующие параметры: .. code-block:: yaml # Настройки модуля "Протоколирование запросов/ответов" audit-req-resp: enabled: false # Лимит размера сообщений max-size-log-data: 1MB # Сохранение тела ответа save-response-body: true # Режим подтверждения сохранения события перед отправкой ответа на запрос в Ядро, # если true, то ответ отправляется в Ядро СМЭВ4 только после успешного сохранения. check-saved-log-data: false # Включение агрегации много-чанковых сообщений, принимаемых от витрины по Kafka. # Допускается включение только для Агента, работающего в одном экземпляре. Если Агент # масштабирован, полный набор чанков не может быть собран на экземпляре. single-instance: false queue: # Максимальный размер очереди ожидающих сообщений max-size: 1000 # Реестр агрегирования много-чанковых сообщений registry: cleaning-interval: 5M aggregated-message-ttl: 5M max-cache-size: 10000 # Запись событий в БД appender: # Количество повторных попыток записи события retry-count: 3 # Задержка между повторными попытками записи события retry-delay: 10MS # Настройки батчинга при записи событий batch: # Максимальный размер пачки size: 1000 # Максимальный период накопления period: 1S .. attention:: При интеграции Агента с Витриной данных через rest, выполняется агрегация чанков сообщений в памяти Агента. Перед значительным повышением лимита размера сообщений (max-size-log-data) необходимо сопоставить показатели выполняемых обменов и наличие ресурсов для внутренней памяти Агента СМЭВ4. Повышение лимита размера сообщений без оценки возможности ресурсов может привести к OOM на Агенте.