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

Материал из Документация Ключ-АСТРОМ
Версия от 20:09, 20 августа 2025; IKuznetsov (обсуждение | вклад) (Новая страница: «Ключ-АСТРОМ обеспечивает автоматическое обнаружение облачных приложений и рабочих наг...»)
(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)

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

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

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

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

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

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

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

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

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

Правила обнаружения рабочей нагрузки для Kubernetes

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

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

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

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

Чтобы создать правило

  1. Перейдите в Настройки.
  2. Выберите Процессы и контейнеры > Облачные приложения и обнаружение рабочей нагрузки.
  3. Выберите Добавить правило.
  4. Используйте комбинацию пяти входных переменных, приведенных ниже, для расчета способа обнаружения групп процессов.
  • Имя пространства имен
  • Базовое имя пода (например, paymentservice- для paymentservice-5ff6dbff57-gszgq)
  • Имя контейнера (как определено в спецификации модуля)
  • Стадия (DT_RELEASE_STAGE)
  • Продукт (DT_RELEASE_PRODUCT)
    Если Продукт включен и не имеет значения, по умолчанию используется Base pod name.
  • Задайте оператор сопоставления и имя пространства имен, чтобы определить пространства имен, к которым вы хотите применить это правило.
  • Выберите Сохранить изменения.

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

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

Влияние на наименование группы процессов по умолчанию

ЕдиныйАгент версии 1.241+

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

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

Пример: "index.js emailservice PROD", где

  • index.js является <tech_prefix>
  • emailservice является <product>
  • PROD является <STAGE>
<base_pod_name> в данном случае не используется, поэтому не включен в {ProcessGroup:DetectedName}.

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

Пример — лучшие практики использования меток Kubernetes

Мы рекомендуем вам распространить метки Kubernetes на переменные среды в конфигурации развертывания с помощью Downward API:

  • app.kubernetes.io/version->DT_RELEASE_VERSION
  • app.kubernetes.io/name->DT_RELEASE_PRODUCT
  • app.kubernetes.io/stage->DT_RELEASE_STAGE
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 в одну группу процессов.

Источник — https://doc.fit4u.kz/index.php?title=Облачные_приложения_и_обнаружение_рабочей_нагрузки&oldid=5569