Настройка Компонента ====================== Настройка технических средств --------------------------------------- Серверы, на которых устанавливается Компонент «Витрина данных», должны соответствовать техническим характеристикам, указанным в документе «Техническое описание системы» в разделе :ref:`hard_soft_ware`, в котором приводятся требования к серверному оборудованию (CPU, RAM, HDD и т.д.), программному обеспечению и каналам связи. Необходимые настройки для серверов описаны в документе «Руководство по установке Компонента «Витрина данных»», в котором приводятся требования к серверам, доступности портов для каждого сервера, настройка протоколов, наличие библиотек и т.д. .. _software_settings: Настройка программных средств --------------------------------------- Предварительные действия необходимые перед установкой Компонента, процесс установки и проверка корректной установки Компонента описаны в документе «Руководство по установке компонента «Витрина данных»» в разделе «Подготовка к установке». .. attention:: Программные средства настраиваются в зависимости от используемой конфигурации. Состав компонентов приведен в разделе :ref:`distr_components` документа «Техническое описание компонента «Витрина данных»». Настройка Prostore (dtm-query-execution-core) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Настройка Сервиса исполнения запросов ) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Конфигурация инстанса сервиса исполнения запросов Prostore (dtm-query-execution-core) с описанием логики и порядка работы сервиса представляет собой текстовый YAML-файл, параметры которого организованы в древовидную структуру. Для наглядности конфигурация сервиса исполнения запросов разделена на отдельные секции. Пример файла конфигурации Prostore приведен в разделе `Конфигурация ноды `_ документации Prostore. Настройка коннекторов ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Следующие коннекторы требуют настройки конфигурации: - Kafka-Clickhouse writer connector; - Kafka-Postgres writer connector; - Kafka Jet writer connector. Конфигурация коннектора представляет собой текстовый YAML-файл, параметры которого организованы в древовидную структуру. Пример файла конфигурации коннекторов приведен в разделе `Конфигурация коннекторов `_ документации Prostore. Настройка Агента проверок ~~~~~~~~~~~~~~~~~~~~~~~~~~ .. Конфигурация Агента проверок (application.yml) .. Подключаем файл с настройками конфигурации Агента проверок .. include:: ../../modules/check-adapter/doc/check_adapter_config.rst .. Описание спецификации для взаимодействия с Агентом проверок .. Подключаем файл с описанием спецификации для взаимодействия с Агентом проверок .. include:: ../../modules/check-adapter/doc/check_adapter_anex_a.rst .. Описание служебной схемы, создаваемой Агентом проверок .. Подключаем файл с описанием служебной схемы, создаваемой Агентом проверок .. include:: ../../modules/check-adapter/doc/check_adapter_anex_b.rst Настройка Сервиса генерации уникального номера (Counter-provider) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. Конфигурация Сервиса генерации уникального номера (application.yml) .. Подключаем файл с настройками конфигурации Сервиса генерации уникального номера .. include:: ../../modules/counter-provider/doc/counter_provider_config.rst Настройка Сервиса формирования документов ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. Конфигурация Сервис формирования документов (application.yml) .. Подключаем файл с настройками конфигурации Сервис формирования документов .. include:: ../../modules/printable-form-service/doc/printable_form_service_config.rst Настройка СМЭВ3-адаптера ~~~~~~~~~~~~~~~~~~~~~~~~ .. Конфигурация СМЭВ-адаптер .. Подключаем файл с настройками конфигурации СМЭВ-адаптер .. include:: ../../modules/smev3-adapter/doc/smev3_adapter_config.rst Настройка СМЭВ QL Сервера ~~~~~~~~~~~~~~~~~~~~~~~~~~ .. Конфигурация СМЭВ QL Сервера .. Подключаем файл с настройками конфигурации СМЭВ QL Сервера .. include:: ../../modules/smev-ql/doc/smev_ql_config.rst .. Подключаем файл с настройками конфигурации Стейт-машины СМЭВ QL Сервера .. include:: ../../modules/smev-ql/doc/smev_ql_state_machine.rst .. Подключаем файл с описанием запросов СМЭВ QL Сервера .. include:: ../../modules/smev-ql/doc/smev_ql_request.rst .. Подключаем файл с описанием ответов СМЭВ QL Сервера .. include:: ../../modules/smev-ql/doc/smev_ql_responce.rst .. Подключаем файл с описанием API СМЭВ QL Сервера .. include:: ../../modules/smev-ql/doc/smev_ql_endpoints.rst .. Подключаем файл с описанием ошибок СМЭВ QL Сервера .. include:: ../../modules/smev-ql/doc/smev_ql_errors.rst Настройка стандартного загрузчика ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. Конфигурация стандартного загрузчика .. Подключаем файл с настройками конфигурации стандартного загрузчика .. include:: ../../modules/standard-loader/doc/standard_loader_config.rst Настройка BLOB-адаптера ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. Конфигурация BLOB-адаптер (application.yml) .. Подключаем файл с настройками конфигурации BLOB-адаптер .. include:: ../../modules/blob-adapter/doc/blob_adapter_config.rst Настройка CSV-Uploader ~~~~~~~~~~~~~~~~~~~~~~ .. Конфигурация CSV-Uploader (application.yml) .. Подключаем файл с настройками конфигурации CSV-Uploader .. include:: ../../modules/csv-uploader/doc/csv_uploader_config.rst Настройка DATA-Uploader – Модуль исполнения асинхронных заданий ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. Конфигурация DATA-Uploader – Модуль исполнения асинхронных заданий (application.yml) .. Подключаем файл с настройками конфигурации DATA-Uploader – Модуль исполнения асинхронных заданий .. include:: ../../modules/data-uploader/doc/data_uploader_config.rst Настройка DTM-Uploader ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. Конфигурация ETL .. Подключаем файл с настройками конфигурации ETL .. include:: ../../modules/etl/doc/etl_config.rst Настройка REST-Uploader – Модуль асинхронной загрузки данных из сторонних источников ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. Конфигурация REST-Uploader – Модуль асинхронной загрузки данных из сторонних источников (application.yml) .. Подключаем файл с настройками конфигурации REST-Uploader – Модуль асинхронной загрузки данных из сторонних источников .. include:: ../../modules/rest-uploader/doc/rest_uploader_config.rst .. Подключение ФЛК .. include:: ../../modules/rest-uploader/doc/rest_uploader_format_control.rst .. Подключаем файл спецификации .. include:: ../../modules/rest-uploader/doc/rest_uploader_specification.rst .. подключаем файл openapi.yml .. literalinclude:: ../../modules/rest-uploader/doc/specs/upload.yml :language: yaml .. _logset: Настройка сервиса журналирования ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Сервис журналирования позволяет работать с логами прикладных модулей запущенных в средах WildFly и Kubernetes/OpenShift. Настройка сервиса журналирования должна быть применена к каждому модулю. Ниже приведены шаги по настройке сервиса журналирования: 1. Подключите FluentBit к приложению как отдельный контейнер в OpenShift: .. code-block:: yaml containers: - name: fluent-bit image: fluent/fluent-bit:latest volumeMounts: #перенос конфигураций, и лог файла из проекта в контейнер - name: logger mountPath: /fluent-bit/logger/ - name: fluent-bit-config mountPath: /fluent-bit/etc/ terminationMessagePolicy: File envFrom: - configMapRef: name: logger-fluent-bit-config-env 2. Создайте файл ``logback.xml`` для логирования приложения ( подробнее см. `документацию `_): .. note:: Обязательно в appender FILE_FLUENT прописать путь до конфигураций FluentBit, иначе в контейнер логи не загрузятся. Например, ``name-project/docker/fluentbit/conf/log.log``. .. code-block:: xml %d{yyyy-MM-dd HH:mm:ss}%-5level %logger{36} - %msg%n docker/fluentbit/conf/log.log false x-b3-traceid=%X{X-B3-TraceId:-} x-b3-spanid=%X{X-B3-SpanId:-} x-b3-parentspanid=%X{X-B3-ParentSpanId:-} x-b3-sampled=%X{X-B3-Sampled:-} x-b3-flags=%X{X-B3-Flags:-} caller_file_name=%file serverEventDatetime="%d" logLevel=%level threadName=%thread message="%replace(%replace(%m){'\n','\u2028'}){'\"','\''}" exception="%replace(%replace(%ex){'\"','\u2028'}){'\n','\u2028'}%nopex" callerLine=%L callerMethod="%replace(%caller){'\n','\u2028'}" loggerName="%10.10logger" callerClass=%logger{40} levelStr="%level" levelInt="%level" mdc= \n 3. Добавьте описание конфигурации для FluentBit (подробнее см `документацию `_ ): .. code-block:: [SERVICE] Flush 1 Log_Level info Daemon off Parsers_File /fluent-bit/etc/parsers.conf [INPUT] Name tail Path /fluent-bit/logger/log.log Tag kafka-efs Buffer_Chunk_Size 400k Buffer_Max_Size 6MB Mem_Buf_Limit 6MB Parser logfmt Refresh_Interval 20 [FILTER] Name record_modifier Match kafka-efs Record subsystem ${SUBSYSTEM} Record distribVersion ${DISTRIBVERSION} Record deploymentUnit ${DEPLOYMENTUNIT} Record hostName ${HOSTNAME} Record ipAddress ${IPADDRESS} [FILTER] Name modify Match kafka-efs Hard_copy callerClass className [FILTER] Name record_modifier Match kafka-efs Whitelist_key serverEventDatetime Whitelist_key subsystem Whitelist_key distribVersion Whitelist_key deploymentUnit Whitelist_key hostName Whitelist_key ipAddress Whitelist_key logLevel Whitelist_key className Whitelist_key threadName Whitelist_key message Whitelist_key x-b3-traceid Whitelist_key x-b3-spanid [FILTER] Name lua Match kafka-efs script convert_date.lua call convert_date_efs [OUTPUT] Name stdout Match kafka-efs Format json json_date_key time [OUTPUT] Name http Match kafka-efs Host logstash-service.cloud.ru Port 80 Format json json_date_key time Для правильной работы подключите ``parsers.conf``. .. code-block:: [PARSER] Name logfmt Format logfmt 4. В конфигурационном файле ``convert_date.lua`` настройте форматирование даты: .. code-block:: lua function convert_date_efs(tag, timestamp, record) local pattern = "(%d+)-(%d+)-(%d+) (%d+):(%d+):(%d+),(%d+)" dt_str = record["serverEventDatetime"] local year, month, day, hour, minute, seconds, milliseconds = dt_str:match(pattern) ts = os.time{year = year, month = month, day = day, hour = hour, min = minute, sec = seconds } ts = (ts * 1000) + milliseconds record["serverEventDatetime"] = ts return 2, timestamp, record end function convert_date_pprb(tag, timestamp, record) local pattern = "(%d+)-(%d+)-(%d+) (%d+):(%d+):(%d+),(%d+)" dt_str = record["serverEventDatetime"] local year, month, day, hour, minute, seconds, milliseconds = dt_str:match(pattern) ts = os.time{year = year, month = month, day = day, hour = hour, min = minute, sec = seconds } ts = (ts * 1000) + milliseconds record["timestamp"] = ts return 2, timestamp, record end function convert_date_logstash(tag, timestamp, record) local pattern = "(%d+)-(%d+)-(%d+) (%d+):(%d+):(%d+),(%d+)" dt_str = record["serverEventDatetime"] local year, month, day, hour, minute, seconds, milliseconds = dt_str:match(pattern) ts = os.time{year = year, month = month, day = day, hour = hour, min = minute, sec = seconds } ts = (ts * 1000) + milliseconds record["time"] = ts return 2, timestamp, record end 5. Добавьте параметры модуля: .. code-block:: yaml kind: ConfigMap apiVersion: v1 metadata: name: logger-fluent-bit-config-env data: MODULEID: 1.0.0 MODULEVERSION: 1.0.0 NODEID: 12345 HOSTADDRESS: 0.0.0.0 SUBSYSTEM: LOGGER-TEST DISTRIBVERSION: 1.0.0 DEPLOYMENTUNIT: TEST-UNIT IPADDRESS: 0.0.0.1 6. Настройте конфигурацию для OpenShift. Чтобы Prometheus мог идентифицировать сервис и собирать с него информацию, создайте ``Service`` и укажите путь, на котором располагаются метрики приложения. .. code-block:: yaml apiVersion: v1 kind: Service metadata: name: monitoring-rest annotations: description: 'Exposes Prometheus App by CLuster Ip' prometheus.io.scrape: 'true' prometheus.io.path: '/monitoring-rest/metrics' prometheus.io.port: '8081' labels: app: monitoring-rest spec: type: LoadBalancer ports: - name: http port: 9837 targetPort: 9837 selector: app: monitoring-rest .. _monitoringset: Настройка сервиса мониторинга --------------------------------- Для мониторинга состояния работы Компонента «Витрина данных» используется связка Grafana + Prometheus. Prometheus — система мониторинга, обладающая возможностями тонкой настройки метрик. Prometheus используется для отслеживания состояния работы компонентов системы на низком уровне. Grafana — инструмент с открытым исходным кодом для визуализации данных из различных систем сбора статистики. Grafana используется для представления в графическом виде временных рядов и текстовых данных. .. note:: Описание установки системы мониторинга приведено в разделе :ref:`monitoring_install` документа «Руководство по установке Компонента «Витрина данных». Предоставление источника данных ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Существует два способа предоставления источника данных: - с помощью конфигурационного файла; - с помощью интерфейса Grafana. .. tab-set:: .. tab-item:: Настройка в конфигурационном файле Каждый файл конфигурации предоставления источника данных содержит *манифест*, в котором указывается желаемое состояние набора подготовленных источников данных. При запуске Grafana загружает файлы конфигурации и предоставляет источники данных, перечисленные в манифестах. Ниже приведен пример настройки источника данных TestData , который можно использовать для информационных панелей. 1. В директории ``provisioning/datasources/`` создайте файл ``dtm.yml`` со следующим содержимым: .. code-block:: yaml apiVersion: 1 datasources: - name: Prometheus type: prometheus access: proxy url: jsonData: httpMethod: POST manageAlerts: false prometheusType: Prometheus 2. Перезапустите Grafana, чтобы загрузить новые изменения. 3. На боковой панели наведите курсор на значок « Конфигурация» (шестеренка) и нажмите «Источники данных». TestData появится в списке источников данных. .. note:: Папка ``provisioning/datasources/`` находится в ``/etc/grafana/``. .. tab-item:: Настройка в интерфейсе Grafana Для работы Prometheus с Grafana необходимо добавить Prometheus в качестве источника получения данных в Grafana. 4. Откройте Grafana — Configuration — Data sources, нажмите **Add data source** и выберите **Prometheus**. .. _grafana_config: .. figure:: img/grafana_config.jpg :align: center :alt: Выбор Prometheus в качестве источника получения данных Выбор Prometheus в качестве источника получения данных 5. В поле URL введите адрес и порт, по которому доступен Prometheus. .. _prometheus_url: .. figure:: img/prometheus_url.jpg :align: center :alt: Ввод URL Prometheus Ввод URL Prometheus 6. Внизу страницы нажмите кнопку **Save & test** .. _save_test: .. figure:: img/save_test.jpg :align: center :alt: Применение настроек Применение настроек После успешной проверки Prometheus будет добавлен в Grafana. Предоставление информационной панели ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Определить поставщика информационных панелей можно также двумя способами: - с помощью конфигурационного файла; - с помощью интерфейса Grafana. .. tab-set:: .. tab-item:: Настройка в конфигурационном файле Каждый файл конфигурации информационной панели содержит *манифест*, который определяет желаемое состояние набора *поставщиков информационной панели*. Поставщик информационной панели сообщает Grafana, где найти и где разместить определения информационной панели. Grafana регулярно проверяет изменения в определениях панели мониторинга (по умолчанию каждые 10 секунд). В директории ``provisioning/dashboards/`` создайте файл ``dtm.yml`` со следующим содержимым: .. code-block:: yaml apiVersion: 1 providers: - name: 'DTM Metrics' # Уникальное идентифицируемое имя поставщика folder: 'dtm-metrics' # Папка, в которую помещаются дашборды type: file disableDeletion: false updateIntervalSeconds: 10 allowUiUpdates: false options: path: foldersFromFilesStructure: false .. note:: Папка ``provisioning/dashboards/`` находится в ``/etc/grafana/``. .. tab-item:: Настройка в интерфейсе Grafana 1. Нажмите на иконку ``+`` и выберите "Import dashboard". .. _import_dashboard: .. figure:: img/import_dashboard.jpg :align: center :alt: Меню импорта Панели Меню импорта Панели 2. В открывшемся окне нажмите на плашку "Upload dashboard JSON file" и загрузите файл нужной панели. .. _import_json: .. figure:: img/import_json.jpg :align: center :alt: Загрузка файла панели Загрузка файла панели .. _prometheus_config: Настройка конфигурационного файла Prometheus ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Пример конфигурационного файла ``prometheus.yml``: .. code-block:: bash global: scrape_timeout: 5s scrape_interval: 5s scrape_configs: - job_name: 'smevql-server' static_configs: - targets: ['ip:8080'] - job_name: 'blob-adapter' static_configs: # изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами - targets: ['ip:9837'] - job_name: 'counter-provider' static_configs: # изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами - targets: ['ip:9837'] - job_name: 'csv-uploader' static_configs: # изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами - targets: ['ip:9837'] - job_name: 'data-uploader' static_configs: # изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами - targets: ['ip:9837'] - job_name: 'podd-adapter-group-repl' static_configs: # изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами - targets: ['ip:9837'] - job_name: 'podd-adapter-group-tp' static_configs: # изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами - targets: ['ip:9843'] - job_name: 'podd-adapter-import-tp' static_configs: - targets: ['ip:19843'] - job_name: 'podd-adapter-mppr' static_configs: # изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами - targets: ['ip:9843'] - job_name: 'podd-adapter-mppw' static_configs: # изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами - targets: ['ip:9843'] - job_name: 'podd-adapter-query' static_configs: # изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами - targets: ['ip:9837'] - job_name: 'podd-adapter-replicator' static_configs: # изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами - targets: ['ip:9837'] - job_name: 'podd-avro-defragmentator' static_configs: # изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами - targets: ['ip:9837'] - job_name: 'printable-form-service' static_configs: # изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами - targets: ['ip:9837'] - job_name: 'rest-uploader' static_configs: # изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами - targets: ['ip:9837'] - job_name: 'smev3-adapter' static_configs: # изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами - targets: ['ip:9033'] Health check ^^^^^^^^^^^^^^^^^ В данной концепции приведены health check по СМЭВ3, СМЭВ4, REST, BLOB и сервису формирования документов. Каждый сервис, из перечисленных выше, дорабатывается таким образом, чтобы возвращать информацию **liveness** и **readiness** в виде метрик Prometheus. Дополнительно, по каждому сервису реализуется соответствующие REST запросы: ``../api/v1/health/liveness`` и ``..api/v1/health/readiness``, показывающим liveness и readyness проверки соответственно. Обращение к каждому конкретному сервису из представленных ниже по REST, обусловлено передачей хоста и порта в URL, соответствующих сервису согласно схеме развертывания. **liveness** возвращает информацию о работоспособности сервиса. **readiness** сообщает о готовности сервиса к работе. Готовность сервиса к работе характеризуется доступностью окружающих его сервисов, с которыми ведется прямое взаимодействие. Когда **liveness** проверка не проходит, то это сигнализирует о том что сервис мертв и должен быть как минимум перезагружен. Когда **readiness** проверка не проходит, то это говорит о том, что проверяемый сервис не готов к принятию входящего сетевого трафика. В будущем это приложение может прийти в готовность, но сейчас оно не должно принимать трафик. **Liveness** и **readiness** проверки проходят успешно только в том случае, если все входящие в них проверки (свои для каждого сервиса) прошли успешно. .. note:: Для управления всеми типами health check наружу выставляются рычаги/конфигурации, позволяющие включать/отключать проверки а также устанавливать частоту вызова и таймауты по каждой проверке. Readiness и Liveness проверки проходят в realtime. Таймауты для данных проверок должны быть выставлены с учетом того, что проверка сможет пройти в данный срок. **Liveness** Для **liveness** проверок вертиклов принимается следующее ограничение: Если, например, для работы вертикла требуется Kafka, и она в данный момент времени недоступна - то, при условии что вертикл задеплоен, проверка **liveness** вернет положительный ответ. Отловить подобную ситуацию можно будет только на проверке **Readiness**. BLOB-Adapter ############## **Liveness** Проверяется состояние вертиклов. В рамках проверки осуществляется корректность деплоя вертиклов. Берется список всех вертиклов по сервису, и выполняется проверка, что они есть в списке задеплоеных вертиклов. В случае если все вертиклы задеплоены - проверка проходит успешно. **Readiness** Хранилище (внешнее или внутренне). Получение адреса хранилища. Проверка, существует ли хранилище по конкретному адресу. Порт доступен, открыт и доступен для подключения. Сервис печатных форм ###################### **Liveness** Проверяется состояние вертиклов. В рамках проверки осуществляется корректность деплоя вертиклов. Берется список всех вертиклов по сервису, и выполняется проверка, что они есть в списке задеплоеных вертиклов. В случае если все вертиклы задеплоены - проверка проходит успешно. **Readiness** - Prostore: получения адреса, подключение по JDBC и проверка выполнения запроса "CHECK_VERSIONS()". - Kafka агента СМЭВ4: получение строк подключения. Проверка, что Kafka существует по конкретному адресу, порт доступен, открыт и доступен для подключения. СМЭВ3 адаптер ############## **Liveness** Проверяется состояние вертиклов. В рамках проверки осуществляется корректность деплоя вертиклов. Берется список всех вертиклов по сервису, и выполняется проверка, что они есть в списке задеплоеных вертиклов. В случае если все вертиклы задеплоены - проверка проходит успешно. **Readiness** - Prostore: получение адреса, подключение по JDBC и проверка выполнения запроса "CHECK_VERSIONS()". - VipNet Signer\CP: если в файле конфигурации указан доступ к VipNet, то по указанной строке подключения проверяется доступность VipNet. - Postgress: получения строки подключения, подключение по JDBC и проверка выполнения запроса "select 1". - СМЭВ3: проверить telnet порт СМЭВ3 на доступность командой: .. code-block::bash $ telnet опции хост порт Опционально, проверить зафиксированные результаты обращений вертикла ресивера в СМЭВ3.