Мониторинг приложений AKS с помощью OTLP и Azure Monitor (предварительная версия)

OpenTelemetry предоставляет стандартный способ выдачи трассировок, журналов и метрик. Azure Monitor добавляет поддержку Preview для мониторинга приложений, работающих на Azure Kubernetes Service (AKS) с помощью протокола OpenTelemetry (OTLP) для инструментирования и сбора данных.

Ключевые возможности

• Включите мониторинг на уровне кластера для установки компонентов Azure Monitor на кластере AKS.
• Создайте ресурс Application Insights с включенным приемом OTLP.
• Подключите приложения к пространству имен или области развертывания, выбрав один из следующих способов:
  • Autoinstrumentation с распределением OpenTelemetry Azure Monitor.
  • Автоматическая настройка для приложений, уже инструментированных с помощью пакетов SDK с открытым исходным кодом OpenTelemetry.
    • Автонастройка применяется только к приложениям, которые уже инструментированы с помощью OpenTelemetry. При выборе автоматической настройки Azure Monitor не добавляет инструментирование в приложение. Вместо этого он задает переменные среды на уровне платформы, чтобы существующие пакеты SDK OpenTelemetry экспортируют данные телеметрии в Application Insights. Перед включением автоматической настройки вы несете ответственность за инструментирование приложения (например, с помощью пакетов SDK или заметок OpenTelemetry).

Потоки телеметрии поступают в Application Insights, где вы анализируете производительность приложения в контексте Container Insights.

Роли и обязанности

Используйте следующее руководство, чтобы разделить обязанности платформы (кластера) от обязанностей разработки приложений (рабочей нагрузки). Администраторы кластера означают команду, которая отвечает за кластер AKS и конвейер телеметрии Azure Monitor. Разработчик ссылается на команду, которая владеет кодом приложения и его конфигурацией телеметрии.

Вне области для администраторов кластера: изменение кода приложения, выбор библиотек и определение семантики телеметрии уровня бизнеса.

Вне компетенции разработчиков: изменение дополнений кластера, ролевой модели доступа платформы (RBAC), топологии совместного использования ресурсов для получения данных или сети кластера.

Общие точки совместной работы:

• Согласуйте стандарты именования и маркировки (service.name, k8s.deployment.name, и соглашения о пространстве имен), чтобы данные можно было запрашивать, а панели мониторинга работали во всех командах.
• Согласуйте параметры производительности и затрат (стратегия выборки, детализация журналов и кратность метрик) и кто что изменяет, когда пределы превышены.
• Определите рабочий процесс поддержки для проблем телеметрии: что разработчики проверяют в первую очередь, а что передавать команде администраторов кластера.
• Планируйте изменения совместно, когда они охватывают оба уровня (например, смена метода приема данных, изменение ожиданий относительно конечных точек и временных параметров, либо введение сборщика).

Предпосылки

• Кластер AKS в общедоступном облаке Azure с как минимум одним развертыванием Kubernetes.
• Azure CLI 2.78.0 или более поздней версии. Установите или обновите, воспользовавшись руководством в разделе Install the Azure CLI документации.
  Проверьте версию:

  az version
  

• расширение aks-preview Azure CLI:

  az extension add --name aks-preview
  az extension update --name aks-preview
  

1. Регистрация предварительных функций

При регистрации функций предпросмотра включите флаг функции в подписке, где создается ресурс Application Insights, и в подписке, где размещается кластер AKS.

1. Войдите и выберите целевую подписку:

   az login
   az account set --subscription "<subscription-name>"
   

2. Зарегистрируйте предварительную функцию AKS и поставщика.

   az feature register --namespace "Microsoft.ContainerService" --name "AzureMonitorAppMonitoringPreview"
   az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/AzureMonitorAppMonitoringPreview')].{Name:name,State:properties.state}"
   az provider register --namespace "Microsoft.ContainerService"
   az provider show --namespace "Microsoft.ContainerService" --query "registrationState"
   

3. Зарегистрируйте предварительные версии функций и поставщиков Application Insights OTLP:

   az feature register --name OtlpApplicationInsights --namespace Microsoft.Insights
   az feature list -o table --query "[?contains(name, 'Microsoft.Insights/OtlpApplicationInsights')].{Name:name,State:properties.state}"
   
   az provider register -n Microsoft.Insights
   

2. Подготовка кластера

1. Убедитесь, что кластер подключен к метрикам и журналам Azure Monitor. Используйте параметр Enable monitoring для кластеров AKS в Azure Monitor (подключение Application Insights пока не требуется).
2. Включите поддержку автоинструментации и включите поддержку сбора данных от поставщиков нейтральных пакетов SDK OpenTelemetry (предварительная версия) и нажмите кнопку "Проверить и включить".

Если вы ранее не подключены к кластеру, вы можете включить управляемый Prometheus, журналы контейнеров и мониторинг приложений одновременно.

3. Создание ресурса Application Insights с поддержкой OTLP

Создайте или выберите ресурс Application Insights, поддерживающий OTLP и использующий управляемые рабочие области.

1. На портале Azure создайте ресурс Application Insights.
2. Включите поддержку OTLP (предварительная версия).
3. Задайте управляемые рабочие области на «Да».
   

4. Подключение приложений к Application Insights

Вы можете подключить все развертывания в пространстве имен или нацелиться на отдельные развертывания позже.

4.1 Открытие пространства имен

1. В ресурсе AKS раскройте ресурсы Kubernetes.
2. Откройте пространства имен и выберите пространство имен, в котором размещаются рабочие нагрузки.

4.2 Настройка мониторинга приложений (предварительная версия)

При включении OTLP Application Insights добавляет поддержку основанных на открытом исходном коде, нейтральных по отношению к поставщикам пакетов OpenTelemetry SDK и конечных точек OTLP, а также сохраняет метрики в рабочей области Azure Monitor.

Если вы не включите OTLP, Application Insights использует только автоинструментацию Azure Monitor и прием данных в классическом режиме.

1. Выберите "Мониторинг приложений" (предварительная версия).
2. Выберите ресурс Application Insights с включенной функцией OTLP, созданной ранее на шаге 3. Если вы выбираете или создаете ресурс Application Insights без OTLP с помощью параметра "Создать" , вы не увидите параметр "Тип инструментирования " на следующем шаге.
3. Выберите тип инструментирования:
   • Настраиваемая пользователем инструментация для каждого развертывания
     • Автонастройка задает переменные среды, чтобы существующие пакеты SDK экспортируют данные телеметрии в Application Insights
     • Каждое развертывание должно иметь аннотации автозамеров или ручное инструментирование. Дополнительные сведения см. в разделе "Настройка для каждого развертывания".
   • Автоинструментация Java для всех развертываний для автоматического внедрения дистрибутива Azure Monitor OpenTelemetry в приложения Java.
     • Все развертывания в пространстве имен по умолчанию используют автоинструментирование Java. Используйте аннотации для изменения языка или исключения развертывания. Для получения дополнительной информации см. Автоматическая инструментация и Подключение для каждого развертывания.
   • Автоинструментация NodeJs для любых сред развертывания для автоматического внедрения дистрибутива Azure Monitor OpenTelemetry в приложения Node.js.
     • Все развертывания в пространстве имен по умолчанию используют автоинструментацию Node.js. Используйте аннотации для изменения языка или исключения развертывания. Для получения дополнительной информации см. Автоматическая инструментация и Подключение для каждого развертывания.

   Замечание

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

4. Оставьте пункт «Перезапуск развертывания для всех развёртываний» не отмеченным. Перезапуск выполняется вручную на следующем шаге.
5. Выберите и настройте.
   

4.3 Перезапуск развертываний для применения изменений

Перезапустите деплойменты в целевом пространстве имен из Run command на портале или из вашего терминала.

kubectl rollout restart deployment -n <your-namespace>

4.4 Подтверждение инструментированного состояния

Вернитесь к мониторингу приложений (предварительная версия) для пространства имен. Разверните развертывания в этом пространстве имен и убедитесь, что развертывания отображают состояние инструментированный.

5. Просмотр сигналов приложения в Container Insights

Изучите производительность приложения в контексте кластера с помощью Container Insights. В разделе "Монитор " в ресурсе AKS откройте контроллеры и выберите контроллер для проверки сбоев запросов, медленных операций и предлагаемых расследований.

Чтобы выполнить детализацию до Container Insights, выберите узел компонента приложения в карте приложений.

Выберите узел и проверьте Pod’ы на плитке мониторинга AKS.

Расширенная адаптация (пользовательские ресурсы)

Используйте настраиваемые ресурсы Kubernetes, если вам нужен дополнительный контроль. Дополнительные сведения см. в разделе "Настройка для каждого развертывания".

Автоинструментация (Java, Node.js)

Следуйте рекомендациям по подключению в масштабе пространства имен или для каждой развертки, изложенным в статье, связанной выше, чтобы внедрить дистрибутив Azure Monitor OpenTelemetry в модули pod.

Чтобы участвовать в ограниченной общедоступной предварительной версии автоинструментации для .NET или Python, см. статью Enable AKS autoinstrumentation для Python и .NET (ограниченная предварительная версия).

Автонастройка (приложения, уже инструментированные с помощью пакетов SDK для OpenTelemetry)

Автонастройка задает переменные среды, чтобы существующие пакеты SDK экспортируют данные телеметрии в Application Insights через агент Azure Monitor в кластере. Он не размещает пакет SDK в модуле pod.

• На уровне пространства имен: задайте ресурс Instrumentation с пустым списком платформам.

  apiVersion: monitor.azure.com/v1
  kind: Instrumentation
  metadata:
    name: cr1
    namespace: mynamespace1
  spec:
    settings:
      autoInstrumentationPlatforms: []
    destination: # required
      applicationInsightsConnectionString: "InstrumentationKey=11111111-1111-1111-1111-111111111111;IngestionEndpoint=https://eastus2-3.in.applicationinsights.azure.com/;LiveEndpoint=https://eastus2.livediagnostics.monitor.azure.com/"
  

• Для каждого развертывания: добавьте аннотацию к развертыванию и укажите на ваш настраиваемый ресурс инструментирования (замените cr1 вашим именем ресурса).

  apiVersion: apps/v1
  kind: Deployment
  ...
  spec:
    template:
      metadata:
        annotations:
          instrumentation.opentelemetry.io/inject-nodejs: "cr1"
  

При использовании аннотации inject-configuration параметр spec.settings.autoInstrumentationPlatforms для указанного настраиваемого ресурса игнорируется, а развертывание настроено для отправки данных OTLP в строку подключения, определенную в applicationInsightsConnectionString. Используйте значение аннотации "false", чтобы исключить развертывание из автоконфигурации.

apiVersion: apps/v1
kind: Deployment
...
spec:
  template:
    metadata:
      annotations:
        instrumentation.opentelemetry.io/inject-nodejs: "false"

Ограничения

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

• Israel Central
• Северо-Запад Израиля
• Qatar Central
• UAE North
• Центральная часть ОАЭ

Если вам нужны программные имена для этих регионов, см. список Azure регионов.

Ограничения

• Эта функция принимает только OTLP/HTTP с двоичным Protobuf. Он не поддерживает JSON-нагрузки или OTLP/gRPC. Необходимо настроить экспортер OTLP соответствующим образом при использовании автонастройки с SDK с открытым исходным кодом и нейтральностью к поставщикам.
• Эта функция поддерживает до 30 связей правил сбора данных (DCR) для каждого кластера AKS.
• Тестируемый масштаб для журналов и трассировок составляет 50 000 событий в секунду (EPS). Для этой функции можно ожидать примерно 250 МиБ дополнительного использования памяти и 0,5 виртуальных ЦП на кластер.

Неподдерживаемые сценарии

• Сжатие в экспортерах пакета SDK OpenTelemetry.
• Пространства имен с включенным Istio mutual TLS (mTLS).
• Конечные точки HTTPS в конфигурации инструментирования.

Сценарии не проверены

• Кластеры AKS, использующие прокси-сервер HTTP.
• Кластеры AKS, использующие Приватный канал.
• Кластеры с двойным стеком AKS.

Дальнейшие шаги

• Узнайте, как работает безкодовое инструментирование для Kubernetes и как налаживать развертывания.
• Ознакомьтесь со статьей Включение мониторинга для кластеров AKS, чтобы разобраться в мониторинге инфраструктуры с помощью Azure Monitor.
• Узнайте, как настроить мониторинг приложений с помощью Azure Monitor и OTLP для других сред с агентом Azure Monitor или сборщиком OpenTelemetry с открытым кодом.

Support

Если документация и действия, описанные в этой статье, не устраняют проблему или вы хотите предоставить отзыв, отправьте электронное письмо команде Azure Monitor OpenTelemetry по адресу otel@microsoft.com.