Просмотр кода страницы Облачные приложения и обнаружение рабочей нагрузки

Ключ-АСТРОМ обеспечивает автоматическое обнаружение облачных приложений и рабочих нагрузок в средах '''Cloud Foundry''', '''Docker''' и '''Podman''', а также '''Kubernetes/OpenShift'''. Облачные приложения и рабочие нагрузки объединяют схожие процессы в группы процессов и сервисы, что позволяет проводить анализ версий.

Облачные приложения и обнаружение рабочей нагрузки обеспечивают

* Информация о пространствах имен, рабочих нагрузках и модулях '''Kubernetes'''
* Метрики ресурсов контейнеров для контейнеров '''Kubernetes''' и '''Cloud Foundry'''
* Определение версий для служб, работающих в рабочих нагрузках '''Kubernetes'''

<u>Начиная с Ключ-АСТРОМ версии 1.258 и ЕдиногоАгента версии 1.257</u>

* Эта функция включена по умолчанию.
* Вы можете настроить обнаружение облачных приложений и рабочих нагрузок независимо для '''Kubernetes''', '''Cloud Foundry''' и простых сред '''Docker''' и '''Podman''':
*# Перейдите в '''Настройки'''.
*# Выберите '''Процессы и контейнеры''' '''>''' '''Облачные приложения и обнаружение рабочей нагрузки'''.
*# '''Включите/выключите''' функцию '''Включить обнаружение облачных приложений и рабочей нагрузки […] для Cloud Foundry''', '''Docker''' и '''Podman''' или '''Kubernetes/OpenShift''' по мере необходимости.
*# Выберите '''Сохранить изменения'''.

<u>ЕдиныйАгент версии 1.256 и более ранних версий</u> не поддерживают независимую настройку для каждого типа среды. Для этих ЕдиныеАгенты обнаружение облачных приложений и рабочих нагрузок включено только в том случае, если эта настройка активирована для всех трёх сред: '''Cloud Foundry''', '''Docker''' и '''Podman''', '''Kubernetes/OpenShift'''.

<u>Начиная с Ключ-АСТРОМ версия 1.299 и ЕдиныйАгент версии 1.297</u> Ключ-АСТРОМ обеспечивает автоматическое обнаружение контейнеров на основе полученных метаданных поставщиков облачных решений, таких как '''AWS ECS''', '''AWS Fargate''', '''Azure Container Apps''' и многих других. Вы можете настроить обнаружение контейнеров следующим образом:

# Перейдите в '''Настройки'''.
# Выберите '''Процессы и контейнеры > Облачные приложения и обнаружение рабочей нагрузки'''.
# При необходимости '''включите/выключите''' '''обнаружение контейнеров для бессерверных контейнерных служб'''.
# Выберите '''Сохранить изменения'''.

Ниже описано, как использовать свойства рабочих нагрузок '''Kubernetes''' для группировки процессов со схожими рабочими нагрузками. Кроме того, общие правила обнаружения процессов по-прежнему применяются, игнорируя при этом свойства, специфичные для контейнера или платформы.

== Правила обнаружения рабочей нагрузки для Kubernetes ==
По умолчанию Ключ-АСТРОМ разделяет группы процессов и службы для каждой рабочей нагрузки '''Kubernetes'''.

Вы можете определить правила для поддержки своих стратегий выпуска, используя свойства рабочей нагрузки, такие как '''Имя пространства имён''', '''Базовое имя пода''' или '''Имя контейнера''', а также переменные среды '''Продукта''' <code>DT_RELEASE_PRODUCT</code> и '''Стадии''' <code>DT_RELEASE_STAGE</code> для группировки процессов схожих рабочих нагрузок. Вы также можете указать '''основную''' '''версию''' и '''версию сборки''' развёрнутой рабочей нагрузки, установив переменные среды <code>DT_RELEASE_VERSION</code> и <code>DT_RELEASE_BUILD_VERSION</code>. Это даёт вам расширенное представление влияния выпусков на ваши сервисы.

Правила ограничены пространствами имён '''Kubernetes''', что позволяет легко переносить существующее пространство имён среды по одному. Применяется первое подходящее правило в списке. Если ни одно правило не подходит, в качестве резервного варианта используется комбинация '''Имя пространства имён''', '''Базовое имя пода''' и '''Имя контейнера'''.

После изменения рабочей нагрузки

'''<u>Чтобы создать правило</u>'''

# Перейдите в '''Настройки'''.
# Выберите '''Процессы и контейнеры > Облачные приложения и обнаружение рабочей нагрузки'''.
# Выберите '''Добавить правило'''.
# Используйте комбинацию пяти входных переменных, приведенных ниже, для расчета способа обнаружения групп процессов.

* '''Имя пространства имен'''
* '''Базовое имя пода''' (например, <code>paymentservice-</code> для <code>paymentservice-5ff6dbff57-gszgq</code>)
* '''Имя контейнера''' (как определено в спецификации модуля)
* '''Стадия''' (<code>DT_RELEASE_STAGE</code>)
* '''Продукт''' (<code>DT_RELEASE_PRODUCT</code>)  <br />Если '''Продукт''' включен и не имеет значения, по умолчанию используется '''Base pod name'''.
* Задайте '''оператор''' '''сопоставления''' и '''имя пространства имен''', чтобы определить пространства имен, к которым вы хотите применить это правило.
* Выберите '''Сохранить изменения'''.

Обратите внимание, что для вступления в силу изменений в правилах обнаружения облачных приложений и рабочих нагрузок требуется перезапуск модулей.
{| class="wikitable"
|Изменение правил по умолчанию может привести к созданию новых идентификаторов для групп процессов и служб, а также к потере пользовательских конфигураций в существующих группах процессов.
|}
{| class="wikitable"
|Как только ваши группы процессов или службы получат новые идентификаторы, имейте в виду, что:

* Никакие пользовательские конфигурации не будут перенесены в новую группу процессов или службу. Это включает в себя имена, настройки мониторинга, а также настройки обнаружения ошибок и аномалий.
* Любые существующие пользовательские оповещения, пользовательские диаграммы на панелях мониторинга или фильтры, сопоставленные с перезаписанными идентификаторами отдельных групп процессов или служб, больше не будут работать или отображать данные мониторинга.
* Любые интеграции с API Ключ-АСТРОМ, в которых запрашиваются определенные группы процессов или службы, необходимо обновить.
|}

=== Влияние на наименование группы процессов по умолчанию ===
<u>ЕдиныйАгент версии 1.241+</u>

Ключ-АСТРОМ стремится предоставлять интуитивно понятные имена группам процессов, понятные DevOps-командам. Создание правил для рабочих нагрузок '''Kubernetes''' также влияет на состав осмысленных имён по умолчанию для групп процессов. Шаблон по умолчанию для <code>{ProcessGroup:DetectedName}</code> выглядит следующим образом: <code>“<tech_prefix> <product> <STAGE> <base_pod_name>”</code>, где

* <code><tech_prefix></code> относится к именам обнаруженных технологий, таким как имя технологии, исполняемого файла, пути и класса запуска.
* <code><product></code>, <code><STAGE></code>, <code><base_pod_name></code> являются необязательными переменными и используются только при включении в правило, примененное для соответствующего пространства имен '''Kubernetes'''.

Пример: <code>"index.js emailservice PROD"</code>, где

* <code>index.js</code> является <code><tech_prefix></code>
* <code>emailservice</code> является <code><product></code>
* <code>PROD</code> является <code><STAGE></code>

{| class="wikitable"
|<code><base_pod_name></code> в данном случае не используется, поэтому не включен в <code>{ProcessGroup:DetectedName}</code>.
|}
Если наименование группы процессов по умолчанию слишком общее или не отражает ваши стандарты наименования, вы всегда можете настроить его, создав правила наименования групп процессов.

=== Пример — лучшие практики использования меток Kubernetes ===
Мы рекомендуем вам распространить метки '''Kubernetes''' на переменные среды в конфигурации развертывания с помощью [https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/ Downward API]:

* <code>app.kubernetes.io/version</code>-><code>DT_RELEASE_VERSION</code>
* <code>app.kubernetes.io/name</code>-><code>DT_RELEASE_PRODUCT</code>
* <code>app.kubernetes.io/stage</code>-><code>DT_RELEASE_STAGE</code>

{| class="wikitable"
|apiVersion: apps/v1

kind: Deployment

metadata:

  name: emaildeploy

spec:

  selector:

    matchLabels:

      app: emailservice

  template:

    metadata:

      annotations:

        metrics.astromkey.com/path: /stats/prometheus

        metrics.astromkey.com/port: "15090"

        metrics.astromkey.com/scrape: "true"

      labels:

        app: emailservice

        app.kubernetes.io/version: 0.3.6

        app.kubernetes.io/stage: production

        app.kubernetes.io/name: emailservice

        app.kubernetes.io/part-of: online-boutique

    spec:

      serviceAccountName: default

      terminationGracePeriodSeconds: 5

      containers:

      - name: server

        image: gcr.io/google-samples/microservices-demo/emailservice:v0.3.6

        ports:

        - containerPort: 8080

        env:

        - name: PORT

          value: "8080"

        - name: DT_RELEASE_VERSION

          valueFrom:

            fieldRef:

              fieldPath: metadata.labels['app.kubernetes.io/version']

        - name: DT_RELEASE_PRODUCT

          valueFrom:

            fieldRef:

              fieldPath: metadata.labels['app.kubernetes.io/name']

        - name: DT_RELEASE_STAGE

          valueFrom:

            fieldRef:

              fieldPath: metadata.labels['app.kubernetes.io/stage']

        - name: DISABLE_TRACING

          value: "1"

        - name: DISABLE_PROFILER

          value: "1"

        readinessProbe:

          periodSeconds: 5

          exec:

            command: ["/bin/grpc_health_probe", "-addr=:8080"]

        livenessProbe:

          periodSeconds: 5

          exec:

            command: ["/bin/grpc_health_probe", "-addr=:8080"]

        resources:

          requests:

            cpu: 100m

            memory: 64Mi

          limits:

            cpu: 200m

            memory: 128Mi

---
|}
На следующем этапе эту конфигурацию можно легко использовать с помощью одного правила в колонке '''Итог''' — '''Namespace'''.

[[Файл:Image4000.png|граница]]

В результате примененной конфигурации Ключ-АСТРОМ объединит схожие процессы и сервисы с одинаковыми значениями '''Продукт''', '''Стадия''', '''Имя контейнера''' и '''Namespace'''. Поскольку все эти значения идентичны, это правило также обеспечивает объединение рабочих нагрузок из разных кластеров '''Kubernetes''' в одну группу процессов.