Установка#

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

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

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

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

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

Установка на стенды 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": [
            "1.1.1.1"
         ],
         "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. Подробно конфигурирование описано в документе Автоматизированная настройка Apache Kafka, который поставляется в рамках документации на компонент 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} - префикс, задается параметром telemetry_collector.ose.common.kafka_internal_topic_prefix в конфигурационном файле telemetry-collector.all.conf, имеет значение по умолчанию "telemetry-collector".

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

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

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

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

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

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

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

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

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

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

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

resources/telemetry-collector.all.conf

resources/telemetry-collector.collector-pull.conf

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

resources/telemetry-collector-push.conf

resources/telemetry-collector.istio.all.conf

resources/telemetry-collector.management-app.conf

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

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

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

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

Подключение к БД рекомендуется выполнять через hikari pool.

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

В случае использования схемы 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;

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

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

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

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

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

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

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

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

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

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

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

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

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. Secure Password Manager (далее - 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:

Также необходимо проверить наличие топика для сообщений об изменении секретов - {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):

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

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

В случае необходимости ротации сертификатов, добавьте ключ 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-репозитории.

ssl.ose.keyStore.mq.password=PWD
ssl.kubernetes.keyStore.mq.password=PWD
ssl.istio.keyStore.ingress.password=PWD
ssl.istio.keyStore.egress.password=PWD
ssl.ose.istio.keyStore.ingress.password=PWD
ssl.ose.istio.keyStore.egress.password=PWD
ssl.kubernetes.istio.keyStore.ingress.password=PWD
ssl.kubernetes.istio.keyStore.egress.password=PWD
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

Все сертификаты, кроме 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

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

config.env.service.common.ssl.rootCertificatePath=/etc/ssl/certs/caCertificates.pem

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

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

В 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 DEBUG (опционально, для подробных логов при отладке). Данный параметр применим, как для Kubernetes, так и для OpenShift.

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

После завершения работы 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": "{\"required\": false, \"headersToEnrich\": []}",
      "order": 1
    },
    {
      "typeName": "pipeline-data-enrichment-processor",
      "config": "{}",
      "order": 2
    },
    {
      "typeName": "json-flattener-processor",
      "config": "{\"flattenMode\": \"KEEP_ARRAYS\", \"standardFlatteningForFieldsWithDots\": false}",
      "order": 3
    }
  ],
  "outputs": [
    {
      "typeName": "kafka-output",
      "config": "{\"acks\": -1, \"topic\": \"TRACING_TOPIC_NAME\", \"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).

Метрики#

Данные предоставляются в формате Actuator Prometheus. Эти данные необходимо собирать с помощью Prometheus-агента (Unimon-агент).

Конфигурация носит информативный характер. Пример конфигурация 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://{HOST}:{PORT}/push/project/{projectName}/pipeline/{pipelineName}/prometheus-proto"

, где http://{HOST}:{PORT}/push/project/{projectName}/pipeline/{pipelineName}/prometheus-proto – это http-endpoint push-коллектора для отправки метрик, , {projectName} - имя проекта, используемого для сбора данных, {pipelineName} - имя pipeline.

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

{
  "quota": {
    "limitTrafficPerMin": 10000000
  },
  "name": "self-monitoring-pipe",
  "input": {
    "typeName": "standard-http-api",
    "config": "{}"
  },
  "processors": [
    {
      "typeName": "prometheus-unimon-converter",
      "config": "{\"allowNan\": false, \"required\": false, \"headersToEnrich\": []}",
      "order": 1
    },
    {
      "typeName": "jackson-mapper-processor",
      "config": "{}",
      "order": 2
    },
    {
      "typeName": "pipeline-data-enrichment-processor",
      "config": "{}",
      "order": 3
    },
    {
      "typeName": "json-flattener-processor",
      "config": "{\"flattenMode\": \"KEEP_ARRAYS\", \"standardFlatteningForFieldsWithDots\": false}",
      "order": 4
    }
  ],
  "outputs": [
    {
      "typeName": "kafka-output",
      "config": "{\"acks\": -1, \"topic\": \"METRICS_TOPIC_NAME\", \"clientId\": \"cidddd\", \"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\"}"
    }
  ]
}

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

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

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

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

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

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

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

Панели мониторинга в компоненте 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": "{\"required\": false, \"headersToEnrich\": []}",
      "order": 1
    },
    {
      "typeName": "pipeline-data-enrichment-processor",
      "config": "{}",
      "order": 2
    },
    {
      "typeName": "json-flattener-processor",
      "config": "{\"flattenMode\": \"KEEP_ARRAYS\", \"standardFlatteningForFieldsWithDots\": false}",
      "order": 3
    }
  ],
  "outputs": [
    {
      "typeName": "kafka-output",
      "config": "{\"acks\": -1, \"topic\": \"LOGS_TOPIC_NAME\", \"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": "{\"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).