Руководство прикладного разработчика#

Компонент App Hub Application Controller, (AHAC) предназначен для автоматического разворачивания в кластере Kubernetes, или других платформ оркестрации контейнеров на основе Kubernetes компонентов облачных (low-code) приложений.

Термины и определения#

Термин/Аббревиатура

Определение

CRD

Custom Resource Definition

YAML

Yet another markup language, язык для хранения информации в формате понятном человеку

JSON

JavaScript Object Notation, текстовый формат обмена данными, основанный на JavaScript

API

Application Programming Interface

HTTP

HyperText Transfer Protocol, протокол передачи гипертекста

REST

Representational State Transfer, архитектурный стиль взаимодействия компонентов распределенного приложения в сети

URI

Uniform Resource Identifier, унифицированный идентификатор ресурса

URL

Система унифицированных адресов электронных ресурсов

Service Mesh

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

Системные требования#

Требования к системному программному обеспечению приведены в разделе Системные требования документа «Руководство по установке»

Подключение и конфигурирование#

Порядок подключения#

Для подключения компонента в кластер необходимо выполнить его установку из дистрибутива, как описано в документе Руководство по установке.

Миграция на текущую версию#

Для миграции на текущую версию требуется:

  1. Уточнить в разделе «Примечания к релизу» необходимость внесения изменений в конфигурацию контроллера при переходе на текущую версию.

  2. Подготовить файл конфигурации для helm, в котором заменить ссылку на docker-образ контроллера и инсталлера в репозитории

  3. При необходимости подготовить файл с новой конфигурацией для helm. ссылкой на Docker-образ с текущей версией.

  4. Если это указано в разделе «Примечания к релизу», изменить значения выделяемых ресурсов.

  5. Обновить контроллер.

Дополнительно:

Порядок действий при обновлении описан в разделе «Обновление» документа «Руководство по установке».

Быстрый старт#

Установку и запуск компонентов приложения по команде контроллера выполняет компонент - Application Installer (установщик). Могут быть реализованы различные типы Installer для различных способов установки. В настоящее время поддерживается только один тип установщика - Helm (Helm-Installer), который выполняет установку из Helm-чартов.

Для использования контроллера для разворачивания приложений, требуется модуль Helm-Installer, который должен быть установлен в соответствии с Руководством по установке

Разработка первого приложения с использованием программного компонента#

Для развертывания приложения необходимо подготовить артефакт CRD типа Application c описанием разворачиваемого приложения (Application Definition).

Создать helm-чарт приложения Chart.yaml:

apiVersion: v2
appVersion: 0.1.0
dependencies:
  - alias: busybox
    condition: busybox.enabled
    name: busybox
    repository: oci://host/url/chart
    tags:
      - busybox
    version: 0.4.0
description: Busybox helm charts for Kubernetes
name: busybox-app
type: application
version: 0.1.0

Создать в папке charts чарт компонента Chart.yaml

apiVersion: v1
appVersion: "1.0"
description: A Helm chart for Kubernetes
name: busybox
version: 0.1.0

Добавить основной чарт в OCI-registry можно командами:

helm registry login host –username <логин> –password <пароль>

helm package имя_компонента

helm push имя_компонента-0.1.0.tgz oci://host/url/chart

helm registry logout host

Пример Application Definition приложения:

apiVersion: apps.synapse.sber/v1alpha1
kind: Application
metadata:
  name: application-sample
spec:
  type: helm
  image: oci://host/url/chart/busybox-app
  version: "0.1.0"
  digest: "sha256:d1ad45021bcc298ae534bcbf698d55cae0c7098ada28831aa3be80ab65b93c13"
  components:
    - name: busybox
      repository: oci://host/url/chart/helm-charts
      chartVersion: 0.1.0
      values: |-
        image:
          repository: host/url/busybox
          tag: stable
          pullPolicy: Always

Образы компонентов должны быть доступны в доверенном Docker-registry. Helm-чарт с конфигурацией приложения должен быть доступен в OCI-registry.

Использование программного компонента#

Для развертывания приложения с помощью компонента App Hub Application Controller, (AHAC) в целевой проект должен быть загружен артефакт Custom Resource Definition типа Application, который является единой точкой управления составом компонентов интеграции и их параметрами как единым целым. Application — это описание компонентов приложения, которое будет развёрнуто в кластере Kubernetes. Оно содержит всю необходимую информацию для установки и настройки приложения, а также его компонентов.Формат описания задаётся схемой с помощью Custom Resource Definition (CRD). В этом формате указываются параметры приложения: версия API, тип артефакта, метаданные, свойства и параметры.

Пример Application:

apiVersion: apps.synapse.sber/v1alpha1 # версия расширения KubeAPI, фиксирована для релиза компонента **App Hub Application Controller, (AHAC)**
kind: Application # тип артефакта
metadata:
  name: application-sample #имя развертываемого приложения
spec:
  type: helm
  image: "ссылка"
  version: "номер версии"
  digest: "sha256:d1ad45021bcc298ae534bcbf698d55cae0c7098ada28831aa3be80ab65b93c13"
  components:
    - name: busybox
      repository: oci://host/url/chart
      chartVersion: "номер версии"
      values: |-
        secrets:
          - type: truststore
            name: secret
            destination:
              host:
                type:
                properties: |
                  file_path: /u01/kafka/ssl
            values:
              - name: kafka.truststore.jks
                value: AES256

Описание полей спецификации (spec)#

  • image - указывает ссылку на контейнерный образ интеграции, который хранится в OCI-Registry. Это helm-чарт с помощью которого будет установлена интеграция

  • version - версия приложения, которое будет установлено. Версии помогают управлять обновлениями и совместимостью приложения. Вы указываете конкретную версию, чтобы контролировать, какая именно версия будет установлена в среде.

  • digest - контрольная сумма для чартов, которая позволяет убедиться, что устанавливается правильный компонент. Digest используется для проверки целостности и аутентичности загружаемого компонента. Это обеспечивает безопасность и защиту от подмены.

  • components - секция, описывающая компоненты интеграции, их зависимости и параметры. Внутри этой секции перечислены все компоненты, необходимые для работы интеграции.

    • name - имя компонента, которое будет использоваться в зависимостях Чарта интеграции(dependencies). Используется для связи компонентов name с alias в чарте интеграции.

    • repository - ссылка на Helm-chart зависимости, находящейся в OCI-Registry. Это поле указывает, откуда нужно загрузить Helm-chart, который будет использоваться для развертывания компонента. Helm-chart — это пакет, который содержит всё необходимое для установки компонента. Необязательный параметр, только если нужно использовать источник, отличный от того, что прописан в чарте интеграции.

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

    • values - содержит параметры конфигурации компонента, специфичные для конкретного стенда (окружения). Эти параметры переопределяют значения по умолчанию, заданные в чарте.

  • secrets - представляет собой список объектов, каждый из которых описывает конкретный секрет, используемый в приложении. В разделе 3 мы рассмотрим детальнее, общее описание такое: name - это уникальное имя, под которым будет храниться секрет. Имя используется для идентификации секрета в приложении.

    • type - определяет, какого рода данные содержатся в секрете и как они будут использоваться. Например, это может быть обычный секрет для паролей (Opaque) или секрет для хранения сертификатов (truststore).

    • destination - указывает, куда будет направлен секрет. Это может быть кластер Kubernetes или конкретный сервер. Здесь задаются параметры, определяющие, где и как секрет будет использоваться.

    • values - это список ключей и значений, которые содержатся в секрете. Ключи представляют собой имена параметров, а значения — их зашифрованное содержимое.

Экземпляр Application описывает интеграцию, которая будет развёрнута в кластере Kubernetes. Он содержит всю необходимую информацию для установки и настройки интеграции, а также его компонентов

Статус Application#

В поле status Application записывается информация о последнем состоянии интеграции. Status содержит информацию о времени старта и завершения обработки Application, версии развёрнутого приложения, имени и состоянии задания (Job), выполнявшего установку(обновление) интеграции, уникальный идентификатор задания и информацию об успешном выполнении или возникших ошибках. Для определения, в каком статусе находится Application, используется статус (Status) и события (Event) Job Installer`a.

status:
  completionTime: 2024-11-19 10:42:25 +0000 UTC
  deployedVersion: 1
  jobName: esb-install-job-application-service-sample-jkm2n
  jobState: installerSucceeded
  jobUID: 8fa9d7ae-354e-4105-b7b0-3839f631e10e
  message: |+
    message: основной алгоритм инсталлера отработал корректно
    lastLogs: |+
        Пустая env KUBECAFILE, задаем из /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        Путь REPOSITORY_CONFIG не задан в ENV. Конфигурация repositories.yaml не будет использована при установке
        ошибка helm status application-service-sample: Error: release: not found

  startTime: 2024-11-19 10:42:04.36386099 +0000 UTC
  status: deployed

Описание полей статуса (status)#

  • completionTime: время, когда процесс развёртывания завершился.

  • deployedVersion: версия развёрнутого Kubernetes-приложения.

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

  • jobState: состояние задания после развёртывания. Варианты: «installerSucceeded» - означает, что инсталлер успешно выполнил свою задачу, «installerFailed» - в процессе работы инсталлера произошла ошибка

  • jobUID: уникальный идентификатор задания.

  • message: сообщение об успешной установке или возникшей ошибке. В этом поле также содержится информация о последних логах.

  • startTime: время начала процесса развёртывания.

  • status: статус развёртывания. Варианты: «deployed» - означает, что приложение развёрнуто, pending-deploy - в процессе установки, pending-upgrade - в процессе обновления и failed - означает, что в процессе развёртывания произошла ошибка.

Примерная структура чартов приложения и компонентов приложения выглядит так:

busybox-app
    │   Chart.yaml # helm-чарт приложения
    │
    └───charts # helm-чарты компонентов, составляющих приложение
        │
        ├───busybox # Busybox
        │   │   .helmignore
        │   │   Chart.yaml # helm-chart компонента
        │   │   readme.md
        │   │   values.yaml

Папка charts может отсутствовать, если в dependencies указаны ссылки для загрузки чартов.

Запуск компонента Installer выполняется путем запуска Job с передачей в переменных окружения набора необходимых параметров:

kind: Job
apiVersion: batch/v1
spec:
  template:
    spec:
      containers:
        - resources: {}
          terminationMessagePath: /dev/termination-log
          name: installer
          env:
            - name: OPERATION # вид выполняемой операции
              value: install
            - name: CRD_UID # идентификатор артефакта с описанием приложения
              value: d65761d9-6017-448d-8fed-927d941b6a19
            - name: CRD
              value: /opt/application.yaml # точка монтирования артефакта
            - name: WORKDIR
              value: /opt/workdir # точка монтирования рабочего каталога (если emptyDir, то надо менять точку монтирования)
            - name: NAMESPACE
              value: esb-test # Имя проекта, в котором разворачивается приложение
            - name: REGISTRY_CONFIG
              value: /mnt/secrets/config.json
            - name: JOB_NAMESPACE
              value: esb-test # Имя проекта, в котором разворачивается job
            - name: ISTIO_ENABLED
              value: true # Включен ли istio, по умолчанию true
            - name: SIDECAR_TERM_TIMEOUT
              value: 30s # Таймаут выключения sidecar
            - name: NAME
              value: test-job # Имя job
          args:
            - "-l"
            - trace

При установке компонента App Hub Application Controller, (AHAC) из helm-чарта, в целевой проект развертывается его конфигурация по умолчанию:

sidecarTerminationTimeout: 5s # время ожидания отключения сайдкара istio-proxy
istioEnabledInInstaller: true # включение монтирования сайдкара istio-proxy в под установщика
installers: # Список поддерживаемых типов установщиков с необходимыми им параметрами
  helm:
    image: host/url/helm_installer:0.0.49 # ссылка на образ приложения установщика
    serviceAccountName: ahac-installer # Service-account от имения которого будет запущен под установщика
    authorizationSecretName: pull-secret # секрет для доступа к oci-registry компонентов приложения Application
    args: # аргументы запуска приложения установщика
      - -l
      - trace
    resources: # лимиты пода установщика
      limits:
        cpu: 400m
        memory: 500M
      requests:
        cpu: 150m
        memory: 250M
    securityContexts:
      podSecurityContext:
        fsGroup: 10001
      securityContext:
        runAsGroup: 10001
        runAsUser: 10001

Порядок развертывания, обновления, удаления приложения#

При старте контроллера осуществляется формирование списка прослушиваемых пространств имен на основе метки synapse.sber/cpref, значения которых должны соответствовать наименованию пространства имен, где будет развернут контроллер.

После старта контроллер начинает получать из Kubernetes события Reconcilation(Request), содержащие идентификатор Application (namespaced name), и события, содержащие идентификатор Namespace (namespaced name), которые были созданы, изменены или удалены.

Контроллер реагирует на обновление generation в метаданных. Generation автоматически изменяется средствами Kubernetes при изменении любого поля в секции spec, включая digest и components. Это позволяет контроллеру отслеживать изменения в конфигурации приложения и предпринимать соответствующие действия для поддержания актуального состояния интеграции.

При получении событий, содержащих идентификатор Namespace, Controller инициирует проверку наличия в метаданных метки synapse.sber/cpref и соответствие её наименованию пространства имен, в котором будет развернут контроллер. В зависимости от результатов Controller добавит наименование пространства имен в перечень прослушиваемых пространств или удалит его из перечня.

При получении событий, содержащих идентификатор Application, Controller инициирует проверку наименования пространства имен полученного события Reconcilation на его наличие в прослушиваемых Controller перечне пространств имен.

В случае нахождения наименования пространства имен, Controller инициирует поиск нужного Application, проверяет наличие соответствующего релиза, и в зависимости от результатов производит проверку контрольной суммы (digest) образа Application обращаясь к Registry API. В случае если сверка проходит успешно, происходит запуск Job нужного типа, создавая в проекте артефакт типа job, заполняя его нужными параметрами.

Внутри Job разворачивается и запускается модуль Installer, который выполняет указанную в параметрах job операцию для запуска, обновления, или удаления компонентов приложения, так же сравнивая контрольную сумму (digest) загруженного Helm чарта интеграции со значением в Application

Job добавит аннотацию synapse.sber/recid в манифесты Workloads(Deployment, DaemonSet, StatefulSet, ReplicaSet, Pod). При применении таких манифестов Kubernetes выполнит перезапуск их подов (Pod). Добавление аннотации synapse.sber/recid можно отключить настройкой recIdDisabled в конфигурации AHAC.

В компоненте Installer есть возможность предварительного просмотра изменений, перед установкой, обновлением и удалением компонентов приложений через флаг Helm –dry-run. Он активирует функцию предварительного просмотра изменений, которые Helm внесёт в конфигурацию Kubernetes, без фактического применения этих изменений. Эта функция позволяет выполнить предварительную проверку корректности формирования манифестов Kubernetes.

По умолчанию предварительный просмотр включён. Изменить это состояние можно через конфигурацию с помощью флага -d в поле args. Если отключить использование параметра –dry-run, то предварительный просмотр манифестов производиться не будет — изменения будут применяться сразу.

Пример отключение -dry-run:

installers: # Список поддерживаемых типов установщиков с необходимыми им параметрами
  helm:
    args:
      - -d

Контроль состояния релиза#

Контроллер сохраняет описание и статус установки развернутого приложения в артефакте типа Secret в объекте Release в JSON-формате. Release содержит часть параметров исходного описания приложения и generation артефакта application, использованного для развертывания, статус развертывания (pending-deploy, deployed, failed) и UID job, которым выполнялась операция. Release Secret по умолчанию хранится в пространстве (namespace) Application, расположение можно изменить настройкой namespaceToStoreReleaseInfo: controller - в этом случае Secret будет храниться в namespace Application Controller`a.

namespaceToStoreReleaseInfo: application|controller

При получении события Reconcilation(Request) Application Controller по идентификатору находит Application.

Если Application пустой, то это значит, что описание приложения было удалено, и само приложение тоже должно быть удалено. Сами артефакты компонентов приложения удаляются автоматически по owner references, но Controller тем не менее запускает job с операцией удаления, чтобы почистить в проекте компоненты, которые могли зависнуть и не удалиться.

Если Application не пуст, Controller выполняет поиск соответствующего Release, и если он не найден, то запускает job с операцией установки.

Если Application не пуст и соответствующий Release найден, Controller производит сверку параметров, и в случае различий запускает job с операцией обновления.

Если различий не найдено, то Controller не выполняет никаких действий.

Алгоритм перезапуска контроллера#

В случае принудительного перезапуска Controller сигналом Kubernetes или администратором проекта, Controller после старта формирует список прослушиваемых пространств имен и считывает все существующие экземпляры Application и сравнивает их параметры с сохраненными в Release.

Если Application был изменен (его параметр Generation и/или CreationTimestamp не совпадает с сохраненным) и пространство имен присутствует в списке прослушиваемых пространств имен, то Controller выполняет обновление приложения.

Если изменений не было, то Controller не выполняет никаких действий

Если существует Release, для которого нет Application, то это интерпретируется как удаление, и Controller выполняет удаление развернутого приложения.

Загрузка зависимостей чарта интеграции#

В процессе работы с Helm чартами может возникнуть необходимость в обновлении зависимостей. Обновление будет выполняться только в том случае, если в Application в разделе spec.components[n] указаны репозиторий и версия чарта для загрузки зависимости. И только для тех компонентов, где они указаны.

Логика работы:

  • Если в поле spec.components[n].repository указан альтернативный источник, а также указана версия чарта (chartVersion) и она выше версии компонента из файла Chart.yaml, то выполняется загрузка зависимости из указанного источника.

  • Если родительский чарт содержит только описание зависимости или зависимость не содержит в себе template, то выполняется загрузка зависимости из указанного источника

  • Иначе загрузка зависимости из внешнего источника не выполняется, используется загруженная вместе с родительским чартом

Алгоритм работы с секретами в Репозитории#

Для аутентификации в репозитории необходимо настроить registryAuth из раздела Руководством по установке

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

registryAuth: #настройки для аутентификации в репозитории
  name: "pull-secret" #имя секрета для доступа к репозиторию
  create: false #указывает, нужно ли создавать новый секрет для доступа к репозиторию
  secret: #содержит данные .dockerconfigjson для авторизации в репозитории
    .dockerconfigjson: "ew0KICAgICJhdXRocyI6IHsNCiAgICAgICAgImh0dHA6Ly9yZWdpc3RyeS5ob3N0L2RldiI6IHsNCiAgICAgICAgICAgICJhdXRoIjogInRlc3Q6dGVzdCINCiAgICAgICAgfQ0KICAgIH0NCn0="

Существует 2 варианта настройки секрета: создать его или подключиться уже к готовому секрету из кластера, указав его имя. В поле .dockerconfigjson содержатся данные для авторизации в репозитории, внутри закодированная строка base64, пример:

{
  "auths": {
    "http://registry.host/dev": {
      "auth": "test:test"
    }
  }
}

Также есть возможность определить дополнительные параметры для репозитория настройкой repository из раздела Руководством по установке.

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

repository: #определяет параметры для Helm репозитория
  name: "" #имя репозитория,
  create: false #указывает, нужно ли создавать секрет для доступа к Helm репозиторий
  secret: #содержит данные для доступа к репозиторию, такие как repository.yaml
    repository.yaml: "cmVwb3NpdG9yaWVzOg0KICAtIG5hbWU6IHJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgdXJsOiBvY2k6Ly9yZWdpc3RyeS5ob3N0L2Rldi8gICAgICAgICAgICAgICAgICANCiAgICBwbGFpbl9odHRwOiB0cnVlICA="

Аналогично как и с аутентификацией, создать секрет или использовать уже готовый в кластере. В поле repository.yaml указать данные о репозиториях списком, внутри закодированная строка base64, пример:

#Не рекомендуется использовать `username` и `password` в этом файле, настройка должна быть выполнена через `registryAuth`.
repositories:
  - name: registry #имя репозитория.
    url: oci://registry.host/dev/ #URL репозитория. Используется для сравнения с хостом из Application и применения параметров к репозиторию
    username: "" #имя пользователя для аутентификации в репозитории. Это поле используется, если репозиторий требует аутентификации.
    password: "" #пароль для аутентификации в репозитории. Это поле используется, если репозиторий требует аутентификации.
    certFile: "" #путь к файлу сертификата. Это поле используется, если репозиторий требует сертификата для аутентификации
    certFileData: "" #данные сертификата. Это поле используется, если репозиторий требует сертификата для аутентификации.
    keyFile: "" #путь к файлу ключа. Это поле используется, если репозиторий требует ключа для аутентификации.
    keyFileData: "" #данные ключа. Это поле используется, если репозиторий требует ключа для аутентификации.
    caFile: "" #путь к файлу сертификата центра сертификации. Это поле используется, если репозиторий требует сертификата центра сертификации для аутентификации.
    caFileData: "" #данные сертификата центра сертификации. Это поле используется, если репозиторий требует сертификата центра сертификации для аутентификации.
    insecure_skip_tls_verify: false #флаг, указывающий, следует ли пропустить проверку TLS. Если этот флаг установлен, Helm пропустит проверку TLS при доступе к репозиторию
    pass_credentials_all: false #флаг, указывающий, следует ли передавать учетные данные для всех запросов. Если этот флаг установлен, Helm будет передавать учетные данные для всех запросов к репозиторию.
    plain_http: false #флаг, указывающий, следует ли использовать HTTP вместо HTTPS. Если этот флаг установлен, Helm будет использовать HTTP вместо HTTPS при доступе к репозиторию
  - name: local
    insecure_skip_tls_verify: true
    url: oci://local.host/dev/

Пример с использованием HTTP подключения к репозиторию вместо HTTPS:

repositories:
  - name: registry
    url: oci://registry.host/dev/
    plain_http: true

Пример с самоподписанным или невалидным сертификатом:

repositories:
  - name: registry
    url: oci://registry.host/dev/
    insecure_skip_tls_verify: true

Логирование#

В процессе работы компонент фиксирует события в логах.

Системное логирование#

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

Доступ к системному логу можно получить через веб-интерфейс Kubernetes (Workloads->Pods->Имя pod->вкладка Logs).

Системный лог может быть выгружен через консоль клиента Kubernetes командой:

kubectl logs -c <имя контейнера> <имя pod> > /var/logs/ahac/<имя файла>.log

Также уровень системного и прикладного логирования можно изменить, задав его в конфигурации компонента:

logging:
  level: debug
  file:
    enabled: true # Включен ли прикладной лог, по умолчанию выключен
    path: "/var/logs/ahac/application.log" # путь до файлов с логами по умолчанию
    rotate: true # Включает перезапись старых лог файлов, по умолчанию включен
    mode: 0o644 # Мод с которым создаются файлы по умолчанию
    datetimeFormat: "2006-01-02 15:04:05.000000" # Формат даты в логах по умолчанию

Прикладное логирование#

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

Прикладной лог пишется на смонтированный в контейнер приложения ресурс. По умолчанию прикладной лог пишется в файлы:

/var/logs/ahac/application*.log

Также уровень системного логирования можно изменить, задав его в конфигурации Контроллера:

logging:
  level: debug

Более подробно с настройками логирования можно ознакомиться в разделе Руководство по установке

Прикладные логи могут быть извлечены из контейнера приложения и отправлены в подсистему журналирования платформы. Для этого в AHAC должен быть сконфигурирован sidecar-контейнер с компонентом платформы Synapse — Агентом журналирования.

Порядок подключения и использования Агента журналирования приведены в разделе Подключение и конфигурирование документа Руководство прикладного разработчика на компонент Сервис Журналирование (LOGA) Platform V Monitor.

Горизонтальное масштабирование#

Горизонтальное масштабирование компонента возможно посредством создания новых артефактов Deployment в разных пространствах имен. Каждый из артефактов Deployment должен прослушивать свой уникальный перечень пространств имен, наименования которых не должны прослушиваться остальными контроллерами. Запуск нескольких реплик компонента возможен, но все реплики кроме основной будут простаивать, readiness - пробы на них будут опущены.

Метрики#

Для дополнительного мониторинга параметров контроллера в нем реализован механизм сбора метрик его работы. Метрики публикуются на HTTP-интерфейсе компонента и доступны по URI /actuator/prometheus (метод GET).

Порт, на котором поднимается HTTP-сервис, устанавливается через helm чарт, по умолчанию 8080:

synapseMetricsAnnotations:
  metrics.synapse.sber.port: "8080"

Получить текущий актуальный список метрик можно, выполнив в терминале контейнера компонента команду:

curl localhost:<номер HTTP порта>/metrics

–>

Часто встречающиеся проблемы и пути их устранения#

Информация о часто встречающихся проблемах и путях их решения — в разделе «Часто встречающиеся проблемы и пути их устранения» документа «Руководство по системному администрированию».