Автоинструментация для службы Azure Kubernetes (предварительная версия)

В этом руководстве описывается, как настроить Azure Monitor Application Insights для рабочих нагрузок Службы Azure Kubernetes (AKS) без изменения исходного кода.

Мы рассмотрим установку расширения Azure CLI для aks-preview, регистрации флага компонента AzureMonitorAppMonitoringPreview, подготовки кластера, подключения развертываний и перезапуска развертываний. Эти шаги приводят к тому, что в "pods" приложения автоматически внедряется дистрибутив Azure Monitor OpenTelemetry для создания телеметрии. Дополнительные сведения об автоинструментации и ее преимуществах см. в статье "Что такое автоинструментация для Azure Monitor Application Insights?".

Предпосылки

• Кластер AKS с развертыванием Kubernetes, использующим Java или Node.js, в публичном облаке Azure
• Ресурс Application Insights, основанный на рабочей области.
• Azure CLI 2.60.0 или более поздней версии. Дополнительные сведения см. в статье "Установка Azure CLI", " Какая версия Azure CLI установлена?", а также как обновить Azure CLI.

Установите расширение Azure CLI aks-preview

Чтобы установить расширение aks-preview, выполните следующую команду:

az extension add --name aks-preview

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

az extension update --name aks-preview

Регистрация флага компонента AzureMonitorAppMonitoringPreview

# Log into Azure CLI
az login

# Register the feature flag for Azure Monitor App Monitoring in preview
az feature register --namespace "Microsoft.ContainerService" --name "AzureMonitorAppMonitoringPreview"

# List the registration state of the Azure Monitor App Monitoring Preview feature
# It could take hours for the registration state to change from Registering to Registered
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/AzureMonitorAppMonitoringPreview')].{Name:name,State:properties.state}"

# Once the feature shows as Registered in the prior step, re-register the Microsoft.ContainerService provider to apply the new feature settings
az provider register --namespace "Microsoft.ContainerService"

# Check the registration state of the Microsoft.ContainerService provider
az provider show --namespace "Microsoft.ContainerService" --query "registrationState"

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

Чтобы подготовить кластер, выполните следующую команду Azure CLI.

az aks update --resource-group={resource_group} --name={cluster_name} --enable-azure-monitor-app-monitoring 

Развертывание на борту

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

Подключение по всему пространству имен

Чтобы включить все развертывания в пространстве имен, создайте один настраиваемый ресурс инструментирования под названием default в каждом пространстве имен. Обновите applicationInsightsConnectionString, чтобы она содержала строку подключения вашего ресурса Application Insights.

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

Как минимум, требуется следующая конфигурация:

• spec.settings.autoInstrumentationPlatforms: одно или несколько значений на основе языков, на которых выполняются модули pod.
• spec.destination.applicationInsightsConnectionString: строка подключений ресурса Application Insights.

Настройка при каждом развертывании

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

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

   Создайте пользовательские ресурсы для инструментирования, чтобы настроить Application Insights в каждом неймспейсе. Обновите applicationInsightsConnectionString, чтобы она содержала строку подключения вашего ресурса Application Insights.

   Подсказка

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

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

   Как минимум, требуется следующая конфигурация:

   • spec.destination.applicationInsightsConnectionString: строка подключений ресурса Application Insights.

   Подсказка

   spec.settings.autoInstrumentationPlatforms игнорируется в пользовательских ресурсах инструментирования, если они не по умолчанию. Заметка, которая связывает развертывание с пользовательским ресурсом, определяет язык.

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

   Внимание

   Чтобы избежать добавления их в заметки развертывания по ошибке, добавьте заметки на spec.template.metadata.annotations уровне развертывания.

   Примеры:

   • Java: instrumentation.opentelemetry.io/inject-java: "cr1"
   • Node.js: instrumentation.opentelemetry.io/inject-nodejs: "cr1"

   Размещение заметок должно выглядеть следующим образом.

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

Подключение в смешанном режиме

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

1. Реализуйте подключение по всему пространству имен для определения конфигурации по умолчанию.
2. Создайте конфигурации подключения для каждого развертывания , которые переопределяют конфигурацию по умолчанию для определенных ресурсов.

Перезапуск развертывания

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

kubectl rollout restart deployment <deployment-name> -n mynamespace1

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

Удаление автоматической инструментализации для AKS

Убедитесь, что у вас нет инструментированных развертываний. Чтобы неинструментировать инструментированное развертывание, удалите связанный пользовательский ресурс инструментирования и запустите kubectl rollout restart его в развертывании. Затем выполните следующую команду.

az aks update --resource-group={resource_group} --name={cluster_name} --disable-azure-monitor-app-monitoring 

Аннотации

Отключение автоинструментации

Следующие заметки отключают автоинструментацию для указанного языка.

• Java: instrumentation.opentelemetry.io/inject-java

• Node.js: instrumentation.opentelemetry.io/inject-nodejs

  instrumentation.opentelemetry.io/inject-java: "false"
  

Чтобы включить автоинструментацию после отключения.

instrumentation.opentelemetry.io/inject-java: "true"

Размещение заметок должно выглядеть следующим образом.

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

Включение журналов в Application Insights

Вы можете выбрать сбор журналов в Application Insights в качестве дополнения или замены журналов Container Insights.

Включение логов в Application Insights позволяет получить коррелированные логи, что обеспечивает пользователям легкий доступ к просмотру распределенных трассировок вместе с их связанными логами. Кроме того, некоторые микрослужбы не записывают журналы в консоль, поэтому Аналитика контейнеров не может собирать их, и только инструментация Application Insights собирает эти журналы.

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

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

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

Используйте следующую аннотацию для включения журналов в Application Insights

• monitor.azure.com/enable-application-logs

monitor.azure.com/enable-application-logs: "true"

Подготовьте кластер при создании кластера AKS

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

az aks create --resource-group={resource_group} --name={cluster_name} --enable-azure-monitor-app-monitoring --generate-ssh-keys

Часто задаваемые вопросы

Поддерживает ли автоинструментация AKS пользовательские метрики?

Если вы хотите использовать пользовательские метрики в Node.js, вручную оснастите приложения с помощью дистрибутива OpenTelemetry для Azure Monitor.

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

Работает ли автоинструментация AKS с приложениями, инструментированными с помощью SDK программного обеспечения с открытым исходным кодом (OSS) OpenTelemetry?

Автоинструментация AKS может нарушить работу телеметрии, отправляемой сторонним получателям через SDK OpenTelemetry с открытым исходным кодом.

Может ли AKS автоинструментирование сосуществовать с ручным инструментированием?

Автоинструментация AKS предназначена для совместного использования с обоими ручными вариантами инструментирования: классическим пакетом SDK API Application Insights и дистрибутивом OpenTelemetry.

Он всегда предотвращает дублирование данных и гарантирует работу пользовательских метрик.

См. эту диаграмму, чтобы определить, имеет ли приоритет автоинструментация или ручное инструментирование.

Как убедиться, что я использую последние и самые безопасные версии дистрибутива Azure Monitor OpenTelemetry?

Уязвимости, обнаруженные в дистрибутиве Azure Monitor OpenTelemetry, определяются по приоритету, исправлены и выпущены в следующей версии.

Автоинструментация AKS внедряет последнюю версию дистрибутива OpenTelemetry Azure Monitor в поды приложений каждый раз при изменении или перезапуске развертывания.

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

Как узнать больше о дистрибутиве OpenTelemetry в Azure Monitor?

Эта функция обеспечивает автоинструментацию путем внедрения дистрибутива Azure Monitor OpenTelemetry в поды приложений.

Для Java эта функция интегрирует автономный дистрибутив Azure Monitor OpenTelemetry для Java. Дополнительные сведения о двоичном инструментировании Java см. в нашей документации по дистрибутиву Java.

Для Node.js мы внедряем двоичный файл для автоинструментации на основе дистрибутива OpenTelemetry от Azure Monitor. Дополнительные сведения см. в документации по дистрибутивамNode.js. Помните, что у нас нет автономной автоинструментации для Node.js поэтому наша документация по дистрибутиву ориентирована на ручное инструментирование. Вы можете игнорировать шаги конфигурации на основе кода, связанные с ручной инструментализацией. Однако все остальное в нашей документации по дистрибутивам, таким как параметры по умолчанию, конфигурации переменных среды и т. д., применимо к этой функции.

Устранение неполадок

Отсутствуют данные телеметрии

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

1. Убедитесь, что модуль pod находится в состоянии выполнения.

2. Убедитесь, что развертывание инструментировано.

   Проверьте заметку monitor.azure.com/instrumentation о самом развертывании и последнем наборе реплик, принадлежащих к нему.

   Аннотация должна присутствовать с соответствующим JSON в следующем формате: {"crName": "crName1","crResourceVersion": "20177993","platforms":["Java"]}

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

   1. Подготовка кластера. Дополнительные сведения см. в разделе "Подготовка кластера".
   2. Убедитесь, что настраиваемый ресурс инструментирования находится в правильном пространстве имен, как и развертывание.
   3. Убедитесь, что кастомный ресурс инструментария содержит правильную строку подключения и платформу инструментирования.
   4. Перезапустите развертывание. Дополнительные сведения см. в разделе "Перезапуск развертывания".

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

3. Проверьте ошибки сети в журнале SDK, расположенном в томе журналов pod. /var/log/applicationinsights

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

   • Ingestion endpoint could not be reached.
   • Error: getaddrinfo ENOTFOUND eastus2-3.in.applicationinsights.azure.com
   • getaddrinfo ENOTFOUND eastus2-3.in.applicationinsights.azure.com

   Если этот тип ошибки существует, войдите в контейнер и проверьте подключение к конечной точке.

   kubectl exec -ti customer-java-1-1234567890-abcde -- /bin/bash

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

Проверьте соединение между хостом вашего приложения и службой приема

Пакеты SDK и агенты Application Insights отправляют данные телеметрии для обработки в виде вызовов REST к конечным точкам для обработки. Вы можете проверить подключение с веб-сервера или хост-компьютера приложения к конечным точкам службы приема, используя клиентов REST с помощью команд PowerShell или curl. См. устранение неполадок с отсутствующими данными телеметрии приложения в Azure Monitor Application Insights.

Следующие шаги

• Дополнительные сведения об Azure Monitor и Application Insights.
• Узнайте, что может сделать карта приложений для вашего бизнеса.