Установка#

Выбор способа установки#

Установка дистрибутива производится с использованием одного из вариантов:

• Ручная установка без использования скриптов развертывания;

• Ручная установка с использованием инструмента установки Platform V Monitor, расположенного в дистрибутиве по пути package/bh/installer/deploy-pvm.zip (инструкция по его использованию находится внутри архива);

• Автоматическая установка (опционально) компонентом Deploy tools в составе Platform V DevOps Tools.

• Установка отдельного Push Collector

• Установка отдельного Pull Collector

Установка на стенды k8s#

Ниже в разделе - Конфигурирование указаны стендозависимые параметры для заполнения, которые применимы для различных сред контейнеризации, в том числе и k8s. Автоматическая установка Единого коллектора телеметрии в среде k8s возможна с помощью компонента Deploy tools. Для применения специфичных конфигураций k8s необходимо выполнить донастройку multiCluster.json в common-репозитории. А именно, добавить секцию overrides с пустым значением и проверить корректность значения указанной ControlPlane. Пример:

{
   "datacenters": {
      "stands-vdc01-(st-xxxx-01-k8s)": {
         "openshiftCluster": "https://api.k8s.xxxxx.wwwww.zzz:6443",  
         "openshiftSATokenCred": "xxxx-st-sa-k8s",
         "openshiftProjectName": "tribe-om-st-xxxxx-01",
         "openshiftAppsDomain": "apps.k8s.xxxxx.wwwww.zzz",
         "openshiftControlPlane": "gt-xxx-eee-controlplane-01",
         "openshiftWebConsole": "https://console.apps.k8s.xxxxx.wwwww.zzz/k8s/cluster/projects",
         "openshiftRoutersFQDN": [
            "0.0.0.0"
         ],
         "overrides": [
            ""
         ]
      }
   }
}

Также необходимо проверить заполнение параметров в конфигурационном файле telemetry-collector.all.conf

Параметры отвечают за SecurityContext для pod в Kubernetes

* fs-group (spec.securityContext.fsGroup) - Group ID владельца файлов в Volume. Определяет группу, в которой Kubernetes будет изменять разрешения для всех файлов в томах, когда тома монтируются в Pod  
  telemetry-collector.k8s.deployment.spec.template.spec.securityContext.fsGroup=
* uid  (spec.securityContext.runAsUser) - ID пользователя в контейнере.  
  telemetry-collector.k8s.deployment.spec.template.spec.securityContext.runAsUser=

Подготовка окружения#

Настройка Apache Kafka#

Статическая конфигурация#

Для корректной работы Единого коллектора необходимы настройки Apache Kafka. Выполнить их можно автоматически или вручную.

Автоматизированная настройка представляет собой автоматическое создание приведенных ниже топиков Apache Kafka и добавление прав. Чтобы воспользоваться автоматизированной настройкой, нужно сконфигурировать и выбрать playbook при установке Единого коллектора компонентом Deploy tools. Подробно конфигурирование описано в документе Руководство по установке -> Подготовка окружения -> Настройка точки расширения, который поставляется в рамках документации на компонент Alert Manager (ALRT).

Для настройки Apache Kafka вручную, когда отсутствует возможность выдачи прав на CLUSTER необходимо отключить создание ACL (acl_mode=false) при создании топиков и вручную назначить права для клиентского сертификата, который будет использоваться приложением:

Параметр для указания {prefix} указан ниже.

Примеры команд для добавления прав:

sudo ./kafka-acls --authorizer kafka.security.auth.SimpleAclAuthorizer --authorizer-properties zookeeper.connect=zookeeper:2181 \ --add --allow-principal User:* --operation WRITE --operation DESCRIBE --transactional-id TC_TX \ --resource-pattern-type prefixed
sudo ./kafka-acls --authorizer kafka.security.auth.SimpleAclAuthorizer --add --allow-principal User:* --operation IdempotentWrite --cluster

В процессе работы Единый коллектор будет взаимодействовать со следующими топиками Kafka:

Все перечисленные топики обязательны, кроме {prefix}.runtime-secret-refresh, он необходим только при интеграции с Secman. Подробная информация о создании и настройке представлена в Руководстве оператора сервиса Abyss (LGDB).

{prefix} - префикс, задается:

• для топиков {prefix}.metamodel* - параметром collector_push.ose.configmap.collector_push.audit_metamodel_cache.kafka.topic_prefix в конфигурационном файле telemetry-collector.collector-push.conf, имеет значение по умолчанию «metamodels».

• для всех остальных топиков параметром telemetry_collector.ose.common.kafka_internal_topic_prefix в конфигурационном файле telemetry-collector.all.conf, имеет значение по умолчанию «telemetry-collector».

Для топиков необходимо обязательно выставить ACLs для чтения и записи.

*Для топика {prefix}.metamodel-cache необходимо настроить уникальность по ключу метамоделей (модуль, версия).

Настройка: cleanup.policy=[delete,compact]

Пример команды:

bin/kafka-configs –zookeeper zookeeper:2181 –entity-type topics –entity-name metamodels.metamodel-cache –alter –add-config „cleanup.policy=[compact,delete]“

Также настраивается максимальный размер топика {prefix}.metamodel-cache из расчета 2000 метамоделей размером 2Мб.

Настройка: retention.bytes=4000000000

Пример команды:

bin/kafka-configs –zookeeper zookeeper:2181 –entity-type topics –entity-name test-topic –alter –add-config „retention.bytes=4000000000“

При использовании варианта отправки событий аудита напрямую в Kafka проверить наличие топиков (если отсутствуют обратиться к сопровождению аудита):

• audit-metamodels-proxy-v6 // для отправки метамоделей

• audit-events-proxy-v6 // для отправки событий аудита

При необходимости создать топики для системных задач сбора данных:

• self-logs-pipe

• self-osiris-system-pipe

• self-tracing-pipe

• self-monitoring-pipe

Подробнее про создание системных задач в пункте - Системные задачи сбора данных Единого коллектора телеметрии.

Динамическая конфигурация#

Динамические топики, на текущий момент необязательны. Нужны они только, если какой-либо проект будет использовать pull-processing, с распределением через Kafka (способ запуска проверок - CRON_ASYNC_KAFKA). Для их работоспособности нужно будет вручную создать топик с именем вида: «{prefix}.pull-processing-queries_» + project_name, где project_name - это имя соответствующего проекта.

Также есть возможность при установке Единого коллектора указать идентификатор группы Kafka consumer для каждого проекта. Для этого в конфигурационном файле telemetry-collector.collector-pull.conf необходимо задать collector_pull.ose.configmap.kafka_consumer_groups, в котором ключами являются имена проектов, а значениями - идентификаторы групп Kafka consumer. Например,

 '{"test-project": "test-project_pull_processing_group", "projectWithConsumerGroupId": "projectWithConsumerGroupId_pull_processing_group"}'. 

Если идентификатор группы Kafka consumer для проекта не будет задан, то для задачи сбора данных будет сгенерирован новый идентификатор вида «pull_processing_group» + pipeline_id, где pipeline_id - идентификатор задачи сбора данных.

Количество партиций должно быть минимум равно количеству instance pull-коллектора текущей инсталляции.

Retention-policy может быть небольшим, например, 1 час.

Подключение к внутренней Apache Kafka#

Сервис предусматривает возможность использования различных инсталляций Apache Kafka:

• для внутренних нужд;

• для распределения нагрузки Pull Collector рекомендуется использовать одну инсталляцию, для этого нужно для различных параметров задать одинаковые параметры (см. таблицу ниже).

resources/telemetry-collector.all.conf

Настройка второго плеча (при использовании геобалансировщика и Secman PKI)#

Сертификаты, выдаваемые PKI Secman для второго плеча имеют CN отличный от первого плеча. Для того чтобы модули Единого коллектора успешно работали на втором плече необходимо:

• завести ACL на kafka с указанием нового DN

• прописать новый DN в настройках cloudera в параметре «Kafka Broker Advanced Configuration Snippet (Safety Valve) for ssl.properties»

• перезапустить kafka

Без вышеуказанных действий модули Единого коллектора на втором плече будут уходить в рестарт с ошибкой: Caused by: org.apache.kafka.common.errors.TransactionalIdAuthorizationException: Transactional Id authorization failed.

Конфигурирование#

Ниже представлено описание стендозависимых параметров, содержащихся в конфигурационных файлах:

resources/telemetry-collector.all.conf

Инсталляция аудита на базе Platform V Monitor подразумевает, наличие в инсталляции COTE c настроенной задачей сбора для событий аудита. Подробнее конфигурация задачи описана в документе - Руководство прикладного разработчика->Подключение и конфигурирование->Сбор данных по аудиту.

Чтобы отключить использование API-ключей, необходимо указать значение false для параметров:

authentication.api-key.enabled=false; 
collector_push.ose.configmap.collector_push.service_core_project_enable=false; 
collector_push.ose.configmap.collector_push.authorization_enabled=false;

Для включения необходимо указать значение true для тех же параметров.

resources/telemetry-collector.collector-pull.conf

resources/telemetry-collector.ott-sidecar.all.conf

resources/telemetry-collector.collector-push.conf

resources/telemetry-collector.istio.all.conf

resources/telemetry-collector.management-app.conf

в файле conf/custom_property.conf.yaml при необходимости включить нужные параметры:

# Флаг запуска удаления колонок БД после миграции
COTE_LIQUIBASE_ALTER_COLUMN_ENABLE: false

# Режим миграции секретов в Vault
# dry-run - отладочный, без сохранения в DB и Vault. Возможность проверить на конфликт или некорректность имен секретов и внести корректировки в случае необходимости в данные
# vault - промежуточный, сохранение секретов в Vault, данные в DB не обновляются
# full - полный, сохранение и в DB, и в Vault.
# disable - отключен
COTE_SECRETS_VAULT_MIGRATION: "DISABLE"

# Флаг для создания emum, которые не поддерживались в релизах 5.1.38(39) (список доступных security protocol для kafka и виды критичных проверок при валидации метамодели)
COTE_LIQUIBASE_ADD_ENUMS_ENABLE: false

Настройка Platform V Pangolin SE#

Сервис работает с БД двумя различными способами:

• хранение своих данных (конфигурации pipeline, настройки, квоты и др.);

• синхронизация распределенного scheduling.

Для подключения к БД можно использовать hikari pool, либо pgbouncer (только при наличии SSM).

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

В текущем релизе при подключении к PostgreSQL через pgbouncer будет использоваться только дефолтная схема БД (независимо от того, какая указана в значении параметров database.pvm_collector.schema, database.shedlock.schema)

В случае использования схемы cluster-patroni-etcd-pgbouncer необходимую логику по выбору ведущего сервера необходимо реализовать через строчку подключения к БД, на примере JDBC драйвера:

jdbc:postgresql://127.0.0.1:6544,127.0.0.2:6544/dbname?targetServerType=master&prepareThreshold=0

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

• prepareThreshold = int - определяет количество выполнений PreparedStatement, необходимых перед переключением на использование подготовленных операторов на стороне сервера. Значение по умолчанию - 5, что означает начало использования подготовленных операторов на стороне сервера при пятом выполнении того же объекта PreparedStatement. До версии PostgreSQL SberEdition 5.1.0 рекомендованное значение 0, так как pgBouncer не умеет работать с подготовленными транзакциями.

• targetServerType = String - позволяет открывать соединения только к серверам с указанной ролью, разрешенные значения: any, master, primary, slave, secondary, preferSlave, preferSecondary. Различие между primary и secondary в настоящее время выполняется путем проверки того, разрешает ли сервер запись. Значение preferSecondary пытается подключиться к ведомому серверу, если таковые имеются, в противном случае позволяет подключиться к ведущему.

• currentSchema = String - не работает при использовании pgBouncer. Рекомендуется назначать search_path для пользователя.

  ALTER USER <имя_пользователя> SET SEARCH_PATH TO <значение_параметра>;
  

Для работы Единого Коллектора и для работы скриптов развертывания в БД необходимо создать технологические учетные записи (ТУЗ), имена указаны для примера, можно задать другие:

DDL накатываются автоматически, но базу необходимо проинициализировать.
Пример скрипта для инициализации:

CREATE USER pvm_collector_user WITH PASSWORD 'pvm_collector_password';

CREATE DATABASE pvm_collector OWNER pvm_collector_user;
GRANT ALL PRIVILEGES ON DATABASE pvm_collector TO pvm_collector_user;

CREATE SCHEMA IF NOT EXISTS pvm_collector;

CREATE EXTENSION IF NOT EXISTS "uuid-ossp" WITH SCHEMA pvm_collector;

ALTER DATABASE pvm_collector SET SEARCH_PATH TO 'pvm_collector';
ALTER ROLE pvm_collector_user SET SEARCH_PATH TO 'pvm_collector';

GRANT ALL PRIVILEGES ON SCHEMA pvm_collector TO pvm_collector_user;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA pvm_collector TO pvm_collector_user;
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA pvm_collector TO pvm_collector_user;
GRANT ALL PRIVILEGES ON ALL FUNCTIONS IN SCHEMA pvm_collector TO pvm_collector_user;
GRANT ALL PRIVILEGES ON ALL ROUTINES IN SCHEMA pvm_collector TO pvm_collector_user;
GRANT ALL PRIVILEGES ON ALL PROCEDURES IN SCHEMA pvm_collector TO pvm_collector_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA pvm_collector GRANT ALL PRIVILEGES ON TABLES TO pvm_collector_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA pvm_collector GRANT ALL PRIVILEGES ON SEQUENCES TO pvm_collector_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA pvm_collector GRANT ALL PRIVILEGES ON FUNCTIONS TO pvm_collector_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA pvm_collector GRANT ALL PRIVILEGES ON ROUTINES TO pvm_collector_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA pvm_collector GRANT ALL PRIVILEGES ON TYPES TO pvm_collector_user;

CREATE USER management_app_user WITH PASSWORD 'management_app_password';
GRANT USAGE ON SCHEMA pvm_collector TO management_app_user;
GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA pvm_collector TO management_app_user;
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA pvm_collector TO management_app_user;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA pvm_collector TO management_app_user;
GRANT EXECUTE ON ALL ROUTINES IN SCHEMA pvm_collector TO management_app_user;
GRANT EXECUTE ON ALL PROCEDURES IN SCHEMA pvm_collector TO management_app_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA pvm_collector GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE ON TABLES TO management_app_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA pvm_collector GRANT ALL PRIVILEGES ON SEQUENCES TO management_app_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA pvm_collector GRANT EXECUTE ON FUNCTIONS TO management_app_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA pvm_collector GRANT EXECUTE ON ROUTINES TO management_app_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA pvm_collector GRANT USAGE ON TYPES TO management_app_user;

, где пароли, имена схем, пользователей и БД могут быть (пароли должны) выставлены на усмотрение администратора. Скрипт должен соответствовать статической конфигурации сервиса.

Далее необходимо сделать резервную копию БД Единого Коллектора следующим, либо другим удобным способом:

pg_dump -h [имя_хоста] -p [номер_порта] -U [имя_пользователя] -n [имя_схемы] -v -f [имя_файла_c_backup].sql [имя_бд]

Пример:

pg_dump -h st-abyss-name-01.opsmon.sss -p 5432 -U postgres -n cote -v -f namedb.sql namedb_db

Eсли используется георезервирование или БД, которая состоит из нескольких нод, то для корректной работы необходимо в настройке pgbouncer в параметр ignore_startup_parameters добавить search_path.
Пример:

ignore_startup_parameters = extra_float_digits*,search_path*

Ошибка, которая возникает при отсутствии search_path*, указана в Часто встречающиеся проблемы и пути их устранения.

Настройка облачного окружения#

Необходимо создать namespace в кластере Kubernetes, Platform V DropApp (далее DropApp). Также необходимо подключить созданный namespace к Istio Control Plane (istiod).

Ручная установка без использования скриптов развертывания#

Рекомендуем использовать скрипты для автоматизации установки. Скрипты расположены в дистрибутиве, в папке bh/installer в архиве deploy-pvm.zip. В архиве также находится документация по использованию скриптов.

Для установки компонента Единый коллектор телеметрии вручную необходимо:

• Получить дистрибутив компонента Единый коллектор телеметрии;

• Заказать схему БД PostgreSQL или СУБД Platform V Pangolin SE для Единого коллектора (Приложению требуется СУБД Postgres, рекомендуется использовать Platform V Pangolin SE. Требования по инсталляции СУБД отсутствуют, т.е. схему можно создать в любой инсталляции, на усмотрение клиента);

• Выполнить скрипты инициализации БД, расположенные в архиве, в директории db дистрибутива;

• Сделать резервную копию БД Единого Коллектора следующим, либо другим удобным способом:

pg_dump -h [имя_хоста] -p [номер_порта] -U [имя_пользователя] -n [имя_схемы] -v -f [имя_файла_c_backup].sql [имя_бд]

Пример:

pg_dump -h st-abyss-name-01.opsmon.sss -p 5432 -U postgres -n cote -v -f namedb.sql namedb_db

• Во всех файлах .yaml расположенных в директориях заполнить значения переменных;

• Для настройки окружения - внести изменения в файл telemetry-collector.all.conf;

• Для файлов вида *-certs.yaml, необходимо вручную создать yaml;

• Создать секреты с именем из secret-telemetry-collector и значениями из секции secrets файла distrib.yaml;

• Необходимо подключить проект к Istio Control Panel (Platform V Synapse Service Mesh);

• Заполнить значения переменных для всех файлов *.yaml из директории k8s;

• Далее необходимо установить все заполненные файлы *.yaml в платформе приложений-контейнеров с помощью команды;

• Применить все yaml-конфигурации.

Конфигурирование Platform V DevOps Tools (DOT)#

Сервис устанавливается с помощью стандартного Platform V DevOps Tools (DOT).

Секреты, пароли, сертификаты#

При установке Единого коллектора доступно выбрать способ хранения секретов, паролей и сертификатов:

1. Secret Management System (SecMan);

2. Common-репозиторий.

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

Для корректной работы Единого Коллектора используются следующие сертификаты:

• Сертификат Apache Kafka;

• Сертификат OTT;

• Сертификат Istio для Pull Collector;

• Сертификат Istio;

• Сертификат для БД.

Общий корневой сертификат расположен в common-репозитории и используется независимо от способа хранения секретов (в Secman или в common-репозитории).

Рекомендованное расположение цепочки сертификатов УЦ, указано в конфигурационном файле telemetry-collector.all.conf:

В этот файл необходимо поместить цепочку сертификатов УЦ в формате PEM для Apache Kafka, Istio, OTT, БД.

Secman#

Для хранения сертификатов в Secman необходимо в конфигурационных файлах заполнить общие параметры:

telemetry-collector.vault-agent-sidecar.all.conf:

Обращаем внимание, что для параметров нотаций указанных выше должны быть предварительно созданы секреты с сертификатами или указанными свойствами.

Для внутренних взаимодействий Единого коллектора телеметрии ссылку на Api-key в Secman нужно указать в параметре vault.authentication.api_key.internal_key.

Также необходимо проверить наличие топика для сообщений об изменении секретов - {prefix}.runtime-secret-refresh. Описание характеристик топика указано в разделе - Статическая конфигурация.

При работе в режиме генерации сертификатов через PKI#

1. Создать PKI в Secman для вашего приложения (если оно еще не существует).

2. Для выпуска сертификатов можно использовать роль по имени «role-название-созданной-группы-в-AD» (в данном случае, в отличие от остальных, важен регистр). У данной роли разрешены домены sbt и gt, а также выпуск сертификатов для поддоменов. Если требуется, то можно создать собственную роль (отличается от роли для доступа к vault), которая будет содержать параметры выпуска сертификатов.

В конфигурационном файле telemetry-collector.vault-agent-sidecar.all.conf необходимо заполнить параметры:

telemetry-collector.istio.all.conf:

Параметры ttl по-умолчанию имеют значение 1800h, их нужно переопределить на стенде, так как на Secman может стоять ограничение.

При работе с хранилищем KV#

Разместить в Secman данные (логины, пароли, сертификаты, и т. д.):

1. Создать в Secman хранилище KV для вашего приложения (если оно еще не существует).

2. Создать в UI Secman в KV secret для хранения секретов (кнопка Create secret+)

   • можно задать любое имя секрета, например cote-secret (это имя необходимо указать в нотациях сервисов)

   • ingressgateway-certs

   • egressgateway-certs

В конфигурационных файлах задать значения параметров:

telemetry-collector.vault-agent-sidecar.all.conf:

telemetry-collector.istio.all.conf:

3. Добавить в созданный на предыдущем шаге secret необходимые секреты в текстовом формате, где

   • Key - имя файла сертификата, по которому будет происходить lookup сертификата и его нужно будет указать в нотациях сервисов

   • Value - тело сертификата

Следующие параметры задаются в secret с произвольным именем (например cote-secret):

В случае, если сервис авторизации и сервис валидации Api-key это один и тот же сервис, то для параметров:

Параметр для указания пароля пользователя при аутентификации в сервис авторизации в процессе валидации Api ключа
Параметр для указания имени пользователя при аутентификации в сервис авторизации в процессе валидации Api ключа

используется учетная запись администратора Abyss - config.env.service.core.user, config.env.service.core.password.

Имена следующих сертификатов (Key) изменять не рекомендуется.

API key можно получить или создать в Abyss. Подробнее о создании API ключей в Руководстве оператора, инструкция поставляется в рамках компонента Abyss (LGDB) в составе продукта Platform V Monitor (OPM). Наименование заголовка API ключа X-PVM-API-KEY.

В случае необходимости ротации сертификатов, добавьте ключ ttl в secret Secman со значением времени перечитывания хранилища.

При использовании ОТТ#

Необходимо добавить новый secret и сертификаты для ОТТ.

1. Создать в UI Secman в KV новый secret для хранения сертификатов telemetry-collector-ott-certs (кнопка Create secret+)

Задать значения параметров в конфигурационных файлах:

telemetry-collector.ott-sidecar.all.conf:

telemetry-collector.vault-agent-sidecar.all.conf:

2. Добавить сертификаты:

Common-репозиторий#

Таблица со списком секретов:

Для работы с паролями и секретами Platform V DevOps Tools (DOT) можно использовать файл _passwords.conf, который хранится в зашифрованном виде в common-репозитории.

database.pvm_collector.password=PWD
database.shedlock.password=PWD
database.pvm_collector.liquibase.password=PWD
service.core.secure.auth.basic.pass=admin
ott.certstore.private.key.pwd=PWD
ott.certstore.pwd=PWD
ott.trust.store.pwd=PWD
authentication.enabled.api-key.validation.auth.basic.pass=PWD
database.ssl.privateKeyPassword
service.kafka.ssl.privateKeyPassword
crypt.password.key
pull.ssl.privateKeyPassword

В файле openShift.conf добавить параметры:

# Настройка для указания priorityClassName для pods
global.ose.deployment.spec.template.spec.priorityClassName=
# Процент минимально доступных pod для конфигурации PodDisruptionBudget
global.common.poddisruptionbudget.minAvailable=
# имя проекта, где развернут control-plane
global.ufs.synapse.controlPlane.project=
# URL OTT с маской для получения токена
global.ott.service.url=https://stub-host:stub-port/ott-service/rest/token
# Хосты ОТТ
global.ott.service.hosts=
# Порт ОТТ
global.ott.grpc.port=

Все сертификаты, кроме Istio, необходимо положить в common-репозиторий для того, чтобы Platform V DevOps Tools (DOT) их смог найти и установить в инфраструктуру. Istio-сертификат настраивается отдельно, стандартно для Platform V DevOps Tools (DOT) способом.

В telemetry-collector.all.conf должны быть прописаны пути к:

• файлам Kafka в common-репозитории

telemetry_collector.ose.secret.secret-telemetry-collector-kafka-certs.key_location=ansible/files/ssl/pg-key.pem
telemetry_collector.ose.secret.secret-telemetry-collector-kafka-certs.cert_location=ansible/files/ssl/pg-cert.pem

• файлам БД в common-репозитории

telemetry_collector.ose.secret.secret-telemetry-collector-db-certs.key_location=ansible/files/ssl/pg-key.pem
telemetry_collector.ose.secret.secret-telemetry-collector-db-certs.cert_location=ansible/files/ssl/pg-cert.pem

• общим корневым сертификатам

service.common.ssl.rootCertificatePath=/app/ssl/certs/caCertificates.pem

• к сертификатам для Kafka, в которую отправляются собственные события аудита

telemetry_collector.ose.secret.secret-telemetry-collector-audit-kafka-certs.key_location=ansible/files/ssl/kafka-key.pem
telemetry_collector.ose.secret.secret-telemetry-collector-audit-kafka-certs.cert_location=ansible/files/ssl/kafka-cert.pem

Конфигурация окружения#

Значения database.pvm_collector.name и database.shedlock.name должны быть одинаковы, если имя базы данных для database.shedlock.name отличается, то требуется убедиться, что в БД присутствует таблица shedlock:

В случае работы с несколькими репликами БД и необходимости переключения между master/slave, следует установить параметр для БД targetServerType=master. Пример dbname?targetServerType=master&prepareThreshold=0

В common-репозитории в common.conf.yaml указать значения параметров для подключения к БД, в которую будет происходить миграция liquibase-скриптов: TLMCLTR_POSTGRES_DB_URL: «jdbc:postgresql://…» - url для подключения к БД TLMCLTR_POSTGRES_DB_SCHEMA: «telemetry_schema» - схема БД для которой применяются скрипты TLMCLTR_POSTGRES_DB_LIQUIBASE_USER: «tlmclrt_user» - пользователь с правами на CRUD-операции с таблицами БД

В состав дистрибутива входят конфигурационные файлы с рекомендуемыми значениями не стендозависимых параметров для настройки продукта. Их изменение может нарушить безопасность продукта. Пример типовой конфигурации:

• telemetry-collector.all.conf

• telemetry-collector.collector-pull.conf

• telemetry-collector.collector-push.conf

• telemetry-collector.istio.all.conf

• telemetry-collector.kafka_fp.conf

• telemetry-collector.management-app.conf

• telemetry-collector.ott-sidecar.all.conf

• telemetry-collector.vault-agent-sidecar.all.conf

Запуск Platform V DevOps Tools (DOT)#

Установка сервиса происходит через установку дистрибутива Единого коллектора централизованным Platform V DevOps Tools (DOT).

1. Выполнить миграцию конфигураций, используя playbook: MIGRATION_FP_CON.

2. Выполнить конфигурирование параметров и окружения.

3. Создать системные задачи сбора данных.

4. Выполнить установку дистрибутива Единого коллектора телеметрии в среде контейнеризации, используя playbook: DB_UPDATE, OPENSHIFT_INGRESS_EGRESS_DEPLOY, OPENSHIFT_DEPLOY (параметр применим, для DropApp, Kubernetes, OpenShift), DEBUG (опционально, для подробных логов при отладке).

Проверка установки и диагностика#

После завершения работы Platform V DevOps Tools (DOT), необходимо произвести проверку результата выполнения. Должно быть развернуто минимум по одному pod:

• telemetry-collector-management-app;

• telemetry-collector-pull;

• telemetry-collector-push.

Количество pod может меняться и задается в конфигурации сервисов параметром replicas.

Рекомендуется проверить логи сервисов management-app, push-collector, pull-collector.

Настройка обслуживания сервиса#

Единый коллектор предоставляет в стандартном виде информацию о своем состоянии:

• Трассировки в формате Zipkin;

• Логи, JSON формат, допустимый для fluent-bit;

• Метрики в формате Prometheus;

• Для нормальной эксплуатации сервиса эти данные необходимо собирать и сохранять в Abyss, для возможности дальнейшей визуализации.

Для сбора данных необходим проект в Abyss. Этот проект должен быть использован для конфигурирования, которое описано далее. Также на проект нужна достаточная квота. Подробности о создании проектов и квот в интерфейсе Abyss можно выяснить в документации Abyss в документе «Руководство оператора». Все телеметрические данные самомониторинга должны записываться в хранилище Abyss.

Подробнее о создании системных задач сбора данных описано в пункте Системные задачи сбора данных Единого коллектора телеметрии.

Трассировки#

Сбор данных происходит с помощью Spring Zipkin. Трассировки пишутся для всех приложений сервиса: pull/push collector, management application.

Конфигурация (статическая конфигурация сервиса):

spring.zipkin.enabled: true
spring.zipkin.base-url: http://{HOST}:{PORT}/push/project/{projectName}/pipeline/{pipelineName}
spring.zipkin.api-path: /
spring.zipkin.sender.type: WEB

, где {projectName} - это имя проекта, используемого для сбора данных, {pipelineName} - это имя pipeline.

Конфигурация pipeline для импорта:

{
  "quota": {
    "limitTrafficPerMin": 10000000
  },
  "name": "self-tracing-pipe",
  "input": {
    "typeName": "standard-http-api",
    "config": "{}"
  },
  "processors": [
    {
     "typeName": "http-jackson-converter",
     "config": "{\"httpConverterConfig\":{\"required\": false, \"headersToEnrich\": []}}",
     "order": 1
    },
    {
      "typeName": "pipeline-data-enrichment-processor",
      "config": "{}",
      "order": 2
    },
    {
      "typeName": "json-flattener-processor",
      "config": "{\"jsonFlattenerConfig\":{\"flattenMode\": \"KEEP_ARRAYS\", \"standardFlatteningForFieldsWithDots\": false}}",
      "order": 3
    } 
  ],
  "outputs": [
    {
      "typeName": "kafka-output",
      "config": "{\"kafkaProducerConfig\":{\"acks\": -1, \"topic\": \"collect.self-tracing\", \"clientId\": \"cid-3\", \"lingerMs\": 0, \"batchSize\": 16384, \"maxBlockMs\": 60000, \"keySerializer\": \"org.apache.kafka.common.serialization.StringSerializer\", \"sslClientAuth\": false, \"requestTimeout\": 30000, \"deliveryTimeout\": 120000, \"valueSerializer\": \"org.springframework.kafka.support.serializer.JsonSerializer\", \"bootstrapServers\": \"KAFKA_ADDRESS_AND_PORT\", \"securityProtocol\": \"SSL\", \"idempotenceEnabled\": true, \"sslEnabledProtocols\": \"TLSv1.2\", \"maxInFlightRequestsPerConnection\": 5, \"sslEndpointIdentificationAlgorithm\": \"https\"}}"
    }
  ]
}

, где TRACING_TOPIC_NAME - это имя топика Apache Kafka для записи трассировок (нужно создать через UI Abyss), KAFKA_ADDRESS_AND_PORT - список bootstrap серверов kafka Abyss (можно запросить у администратора PVM).

Установка отдельного Push Collector#

Существует возможность установки Push Collector, отдельно от Management Application и Pull Collector. Это может потребоваться для реализации установки n-экземпляров Единого коллектора в разных сетевых зонах. Установка осуществляется обычным способом, описанном в разделе Автоматическая установка, при этом требуется переопределение некоторых параметров:

Не рекомендуется одновременно запускать установку отдельного Push Collector и Pull Collector

1. Установить значение true в параметре для управления установкой отдельного Push Collector (в конфигурационном файле telemetry-collector.all.conf): telemetry_collector.push_only=true

2. Указать значение host Management Application: management_app.host=<host> Необходимо переопределить значение по умолчанию на host из route Management Application из главной зоны (PRIMARY_ZONE), к которому будет обращаться Push Collector для получения конфигурации.

3. Сетевая зона collector_push.ose.configmap.cote_cm_telemetry_collector_push.global.network.zone=<название_зоны> По умолчанию указано PRIMARY_ZONE, если производится полная инсталляция.

После выполнения установки в namespace будут присутствовать следующие Deployment:

• cote-telemetry-collector-push

• egw-cote-{имя проекта}

• igw-cote-{имя проекта} А также набор манифестов, который нужны для работы Push Collector.

Установка отдельного Pull Collector#

В связи с необходимостью работы нескольких экземпляров СОТЕ с одним кластером Abyss есть возможность установить Pull Collector в отдельный namespace. Установка Pull Collector возможна в другой namespace только той же сетевой зоны. Pull Collector должен быть настроен на те же кластера Kafka, Secman и БД, что и основная инсталляция COTE. Также должны совпадать служебные топики и префиксы для них.

Не рекомендуется одновременно запускать установку отдельного Push Collector и Pull Collector

1. Установить значение true в параметре для управления установкой отдельного Pull Collector (в конфигурационном файле telemetry-collector.all.conf): telemetry_collector.pull_only=true

2. Указать значение host Management Application: management_app.host=<host> Необходимо переопределить значение по умолчанию на host из route Management Application из главной зоны (PRIMARY_ZONE), к которому будет обращаться Pull Collector для получения конфигурации.

3. Указать значение host Push Collector: push_app.host=<host> Необходимо переопределить значение по умолчанию на host из route Push Collector из главной зоны (PRIMARY_ZONE), к которому будет обращаться Pull Collector для отправки телеметрии.

4. В конфигурационном файле telemetry-collector.collector-pull.conf задать значение зоны для pull-сбора отличное от главной инсталляции collector_pull.ose.configmap.cote_cm_telemetry_collector_pull.global.work.zone=

После выполнения установки в namespace будут присутствовать следующие Deployment:

• cote-telemetry-collector-pull

• egw-cote-{имя проекта} А также набор манифестов, который нужны для работы Pull Collector.

Метрики#

Есть два варианта сбора и отправки метрики самомониторинга COTE:

1. Unimon-agent (MONA) - данные предоставляются в формате Actuator Prometheus. Эти данные необходимо собирать с помощью Prometheus-агента (Unimon-агент (MONA). Конфигурация носит информативный характер. Пример конфигурация Unimon-агента (фактически в scrape_configs нужно оставить kubernetes-pods и kubernetes-pods-https и далее задать endpoint).

kind: ConfigMap
apiVersion: v1
metadata:
  name: unimon-agent-config.r4
  labels:
    app: unimon-agent
data:
  prometheus.yml: |-
    global:
        scrape_interval: %GLOBAL_SCRAPE_INTERVAL%
        scrape_timeout: %GLOBAL_SCRAPE_TIMEOUT%
    scrape_configs:
        - job_name: 'kubernetes-pods'
          kubernetes_sd_configs:
            - role: endpoints
              namespaces:
                names:
                  - "ci02707148-idevgen-audit-mmv"
          relabel_configs:
            - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
              regex: true
              action: keep
            - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
              regex: (.+)
              target_label: __metrics_path__
              action: replace
            - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
              action: drop
              regex: https
            - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
              action: replace
              target_label: __address__
              regex: ([^:]+)(?::\d+)?;(\d+)
              replacement: $1:$2
            - source_labels: [__meta_kubernetes_namespace]
              separator: ;
              regex: (.*)
              target_label: namespace
              replacement: $1
              action: replace
            - source_labels: [__meta_kubernetes_pod_name]
              separator: ;
              regex: (.*)
              target_label: pod
              replacement: $1
              action: replace
            - source_labels: [__meta_kubernetes_service_name]
              separator: ;
              regex: (.*)
              target_label: service
              replacement: $1
              action: replace
            - source_labels: [__meta_kubernetes_pod_node_name]
              separator: ;
              regex: (.*)
              target_label: nodeName
              replacement: $1
              action: replace
            - action: labelmap
              regex: __meta_kubernetes_pod_label_(.+)
            - source_labels: [__address__]
              separator: ;
              regex: (.*)
              target_label: unimonVersion
              action: replace
              replacement: "D-04.000.00-2373_client"
            - source_labels: [__address__]
              separator: ;
              regex: (.*)
              target_label: tenant
              action: replace
              replacement: "undefined"
            - source_labels: [__address__]
              separator: ;
              regex: (.*)
              target_label: source
              action: replace
              replacement: OpenShift
        - job_name: 'kubernetes-pods-https'
          scheme: https
          tls_config:
            ca_file: /etc/prom-certs/root-cert.pem
            cert_file: /etc/prom-certs/cert-chain.pem
            key_file: /etc/prom-certs/key.pem
            insecure_skip_verify: true
          kubernetes_sd_configs:
            - role: endpoints
              namespaces:
                names:
                  - "ci02707148-idevgen-audit-mmv"
          relabel_configs:
            - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
              regex: true
              action: keep
            - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
              regex: (.+)
              target_label: __metrics_path__
              action: replace
            - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
              action: keep
              regex: https
            - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
              action: replace
              target_label: __address__
              regex: ([^:]+)(?::\d+)?;(\d+)
              replacement: $1:$2
            - source_labels: [__meta_kubernetes_namespace]
              separator: ;
              regex: (.*)
              target_label: namespace
              replacement: $1
              action: replace
            - source_labels: [__meta_kubernetes_pod_name]
              separator: ;
              regex: (.*)
              target_label: pod
              replacement: $1
              action: replace
            - source_labels: [__meta_kubernetes_service_name]
              separator: ;
              regex: (.*)
              target_label: service
              replacement: $1
              action: replace
            - source_labels: [__meta_kubernetes_pod_node_name]
              separator: ;
              regex: (.*)
              target_label: nodeName
              replacement: $1
              action: replace
            - action: labelmap
              regex: __meta_kubernetes_pod_label_(.+)
            - source_labels: [__address__]
              separator: ;
              regex: (.*)
              target_label: unimonVersion
              action: replace
              replacement: "D-04.000.00-2373_client"
            - source_labels: [__address__]
              separator: ;
              regex: (.*)
              target_label: tenant
              action: replace
              replacement: "undefined"
            - source_labels: [__address__]
              separator: ;
              regex: (.*)
              target_label: source
              action: replace
              replacement: OpenShift
    remote_write:
      - url: "http://unimon-sender:10098/monitoring/v1/metrics/send" // Endpoint unmion-sender

2. Отправка метрик в Apache Kafka напрямую (без задачи сбора данных).

Пример настроек:

management_app.kafka.metric.push.topic=collect.self-monitoring-metrics
management_app.kafka.metric.push.ssl=${management_app.ose.configmap.management_app.kafka_ssl_enabled} 
management_app.kafka.metric.push.bootstrap_servers=${kafka.internal.bootstrap-servers} 

collector_push.kafka.metric.push.topic=collect.self-monitoring-metrics
collector_push.kafka.metric.push.ssl=${collector_push.ose.configmap.collector_push.kafka_ssl_enabled}
collector_push.kafka.metric.push.bootstrap_servers=${kafka.internal.bootstrap-servers}

collector_pull.kafka.metric.push.topic=collect.self-monitoring-metrics
collector_pull.kafka.metric.push.ssl=${collector_pull.ose.configmap.collector_pull.kafka_ssl_enabled}
collector_pull.kafka.metric.push.bootstrap_servers=${kafka.internal.bootstrap-servers

Чтобы отключить функциональность отправки метрик напрямую в Kafka нужно изменить значения параметров на:

management_app.kafka.metric.push.enabled=false 
collector_push.kafka.metric.push.enabled=false 
collector_pull.kafka.metric.push.enabled=false

Настройка индексирования данных#

Топик для хранения метрик нужно проиндексировать с помощью сервиса Abyss. Документацию по этому процессу можно найти в документе «Руководство оператора» Abyss.

Чтобы панели мониторинга компонента Единый коллектор телеметрии работали в компоненте Indicator, необходимо при создании аналитического индекса выполнить следующие условия:

1. В разделе «Столбцы» после выполнения «Сгенерировать автоматически» изменить тип столбца value на double;

2. В разделе «Конфигурация» указать нужный проект, «Имя таблицы» collector_table_name, «Столбец времени» timestamp;

3. После создания индекса зайти в редактирование и в разделе «Безопасность» отметить «Данный ресурс является публичным» или добавить ниже пользователя (группу), которому необходимо предоставить доступ к данным.

Панели мониторинга в UI Indicator находятся в разделе «V.Инструменты эксплуатации»

Настройка взаимодействия c Indicator#

• в Indicator настроить Datasource приложения с доступом к endpoint Management Application (подробнее в документации Indicator - Руководство оператора -> Руководство оператора приложения «Источники данных» -> Параметры настройки);

• в Nginx Abyss прописать endpoint Management Application (подробнее в документации по установке Abyss)

Настройка логирования (компонент Журналирование (LOGA) в составе продукта Platform V Monitor (OPM))#

Логи приложений записываются в файл в формате JSON и в лог в обычном формате.

На файлы логов подписан fluent-bit sidecar, который отправляет логи дальше через pipeline.

Конфигурация fluent-bit, носит информативный характер:

[SERVICE]
   Flush        1
   Daemon       Off
   Parsers_File /fluent-bit/etc/parsers.conf
   HTTP_Server  On
   HTTP_Listen  0.0.0.0
   HTTP_PORT    8085
[INPUT]
   Name tail
   Tag file.tail
   Path /fluent-bit/etc/logs/*.json
   Mem_Buf_Limit 10MB
   Skip_Long_Lines On
   Refresh_Interval 2
   Rotate_Wait 1
   Read_from_Head Off
   DB /fluent-bit/etc/logs/kube.db
   Parser custom
[OUTPUT]
   Name stdout
   Match *
[OUTPUT]
   Name             http
   Match            file.tail
   Host             telemetry-collector-push-service
   Port             8083
   URI              push/project/{projectName}/pipeline/{pipelineName}
   Format           json

, где OUTPUT - это настройка вывода логов до Apache Kafka через единый коллектор, {projectName} - имя проекта, используемого для сбора данных, {pipelineName} - имя pipeline, который будет обрабатывать логи.

Конфигурация logback.xml, носит информативный характер:

<configuration debug="true" scan="true" scanPeriod="30 seconds">
        <property scope="context" resource="application.yml"/>
        <appender name="JSON" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
            <providers>
                <timestamp>
                    <fieldName>serverEventDatetime</fieldName>
                    <pattern>[UNIX_TIMESTAMP_AS_NUMBER]</pattern>
                </timestamp>
                <logLevel>
                    <fieldName>level</fieldName>
                </logLevel>
                <loggerName>
                    <fieldName>logger</fieldName>
                </loggerName>
                <threadName>
                    <fieldName>thread</fieldName>
                </threadName>
                <message/>
                <stackTrace>
                    <fieldName>stackTrace</fieldName>
                    <throwableConverter class="net.logstash.logback.stacktrace.ShortenedThrowableConverter">
                        <maxDepthPerThrowable>30</maxDepthPerThrowable>
                        <maxLength>4096</maxLength>
                        <rootCauseFirst>true</rootCauseFirst>
                    </throwableConverter>
                </stackTrace>
                <mdc>
                    <excludeMdcKeyName>serverEventDatetime</excludeMdcKeyName>
                    <excludeMdcKeyName>level</excludeMdcKeyName>
                    <excludeMdcKeyName>logger</excludeMdcKeyName>
                    <excludeMdcKeyName>thread</excludeMdcKeyName>
                </mdc>
            </providers>
            </encoder>
            <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
                <fileNamePattern>/fluent-bit/etc/logs/log_%d{yyyy-MM-dd}_%i.json</fileNamePattern>
                <maxFileSize>5MB</maxFileSize>
                <maxHistory>5</maxHistory>
                <totalSizeCap>50MB</totalSizeCap>
            </rollingPolicy>
        </appender>

        <appender name="active_check_system_data_file" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <encoder>
                <pattern>%msg%n</pattern>
            </encoder>
 
            <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
                <fileNamePattern>/fluent-bit/etc/logs/active_check_system_data_logs/log_%d{yyyy-MM-dd}_%i.log</fileNamePattern>
                <maxFileSize>5MB</maxFileSize>
                <maxHistory>20</maxHistory>
                <totalSizeCap>100MB</totalSizeCap>
            </rollingPolicy>
        </appender>
 
        <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
            <encoder>
                <pattern>%date %level [%thread] %logger{5} - %msg %n %xEx</pattern>
                <charset>UTF-8</charset>
            </encoder>
        </appender>
 
        <root level="INFO">
            <appender-ref ref="STDOUT"/>
            <appender-ref ref="JSON"/>
        </root>
 
        <logger name="active-check-system-data-logger" level="INFO">
            <appender-ref ref="active_check_system_data_file"/>
        </logger>
 
    </configuration>

• Pipeline для обработки всех логов

Конфигурация pipeline для импорта:

{
  "quota": {
    "limitTrafficPerMin": 10000000
  },
  "name": "self-logs-pipe",
  "input": {
    "typeName": "standard-http-api",
    "config": "{}"
  },
  "processors": [
    {
      "typeName": "http-jackson-converter",
      "config": "{\"httpConverterConfig\":{\"required\":false,\"headerToFieldEnrich\": [],\"idGenerationConfig\":{}}}",
      "order": 1
    },
    {
      "typeName": "pipeline-data-enrichment-processor",
      "config": "{}",
      "order": 2
    },
    {
      "typeName": "json-flattener-processor",
      "config": "{\"jsonFlattenerConfig\":{\"flattenMode\": \"KEEP_ARRAYS\", \"standardFlatteningForFieldsWithDots\": false}",
      "order": 3
    }
  ],
  "outputs": [
    {
      "typeName": "kafka-output",
      "config": "{\"kafkaProducerConfig\":{\"acks\": -1, \"topic\": \"collect.self-logs-pipe\", \"clientId\": \"cid-3\", \"lingerMs\": 0, \"batchSize\": 16384, \"maxBlockMs\": 60000, \"keySerializer\": \"org.apache.kafka.common.serialization.StringSerializer\", \"sslClientAuth\": false, \"requestTimeout\": 30000, \"deliveryTimeout\": 120000, \"valueSerializer\": \"org.springframework.kafka.support.serializer.JsonSerializer\", \"bootstrapServers\": \"KAFKA_ADDRESS_AND_PORT\", \"securityProtocol\": \"SSL\", \"idempotenceEnabled\": true, \"sslEnabledProtocols\": \"TLSv1.2\", \"maxInFlightRequestsPerConnection\": 5, \"sslEndpointIdentificationAlgorithm\": \"https\"}}"
    }
  ]
}

, где LOGS_TOPIC_NAME - это имя топика Apache Kafka для записи логов (подробнее о создании топика в Руководстве оператора, инструкция поставляется в рамках компонента Abyss (LGDB) в составе продукта Platform V Monitor), KAFKA_ADDRESS_AND_PORT - список bootstrap серверов Apache Kafka Abyss (можно запросить у администратора PVM).

• Pipeline для сбора системных логов активных проверок

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

Конфигурация pipeline для импорта:

{
  "quota": {
    "limitTrafficPerMin": 10000000
  },
  "name": "self-active-check-system-pipe",
  "input": {
    "typeName": "standard-http-api",
    "config": "{}"
  },
  "processors": [
    {
      "typeName": "http-jackson-converter",
      "config": "{\"required\": false, \"headersToEnrich\": []}",
      "order": 1
    },
    {
      "typeName": "pipeline-data-enrichment-processor",
      "config": "{}",
      "order": 2
    }
  ],
  "outputs": [
    {
      "typeName": "kafka-output",
      "config": "{\"kafkaProducerConfig\": {\"acks\": -1, \"topic\": \"ACTIVE_CHECK_LOGS_TOPIC_NAME\", \"clientId\": \"cid-4\", \"lingerMs\": 0, \"batchSize\": 16384, \"maxBlockMs\": 60000, \"keySerializer\": \"org.apache.kafka.common.serialization.StringSerializer\", \"sslClientAuth\": false, \"requestTimeout\": 30000, \"deliveryTimeout\": 120000, \"valueSerializer\": \"org.springframework.kafka.support.serializer.JsonSerializer\", \"bootstrapServers\": \"KAFKA_ADDRESS_AND_PORT\", \"securityProtocol\": \"SSL\", \"idempotenceEnabled\": true, \"sslEnabledProtocols\": \"TLSv1.2\", \"maxInFlightRequestsPerConnection\": 5, \"sslEndpointIdentificationAlgorithm\": \"https\"}}"
    }
  ]
}

, где ACTIVE_CHECK_LOGS_TOPIC_NAME - это имя топика Apache Kafka для записи системных логов активных проверок (подробнее о создании топика в Руководстве оператора, инструкция поставляется в рамках компонента Abyss (LGDB) в составе продукта Platform V Monitor), KAFKA_ADDRESS_AND_PORT - список bootstrap серверов Apache Kafka Abyss (можно запросить у администратора PVM).

Настройка обработки ошибок в задачах сбора данных#

При работе задач сбора данных возможны ошибки. Ошибки могут возникать на различных этапах работы задачи сбора данных: инициализация, компоненты (input/processor/output), завершение. Для обработки таких ошибок можно сконфигурировать задачу, которую далее можно будет использовать в других задачах сбора данных.

1. В конфигурационном файле telemetry-collector.management-app.conf задать настройки:

# Имя задачи для обработки ошибок 
management_app.error.handling.pipeline.name=
# Проект задачи для обработки ошибок
management_app.error.handling.pipeline.project=

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

При создании задачи для обработки ошибок рекомендуется указывать нулевые квоты, так как для них они не учитываются. На одну задачу сбора данных можно задать только одну задачу для обработки ошибок. Это значит, что нельзя настроить принципиально разные виды обработки ошибок для одной задачи сбора данных.

Пример задачи для обработки ошибок: