Supervisión de aplicaciones de AKS con OTLP y Azure Monitor (versión preliminar)

OpenTelemetry proporciona una manera estandarizada de emitir seguimientos, registros y métricas. Azure Monitor agrega Preview compatibilidad para supervisar aplicaciones que se ejecutan en Azure Kubernetes Service (AKS) mediante OpenTelemetry Protocol (OTLP) para la instrumentación y recopilación de datos.

Importante

Esta característica es una versión preliminar. Las características en versión preliminar se proporcionan sin un contrato de nivel de servicio y no se recomiendan para cargas de trabajo de producción.

Para obtener más información, vea Supplemental Terms of Use for Microsoft Azure Previews.

Principales funcionalidades

• Habilite la supervisión de nivel de clúster para instalar componentes de Azure Monitor en el clúster de AKS.
• Cree un recurso de Application Insights con la importación de OTLP habilitada.
• Aplicaciones integradas en el espacio de nombres o en el ámbito de implementación utilizando cualquiera de las siguientes opciones:
  • Autoinstrumentation con la distribución de OpenTelemetry de Azure Monitor.
  • Configuración automática para aplicaciones ya instrumentadas con los Kits de desarrollo de software (SDK) openTelemetry de código abierto.
    • La configuración automática solo se aplica a las aplicaciones que ya están instrumentadas con OpenTelemetry. Al seleccionar la configuración automática, Azure Monitor no agrega instrumentación a la aplicación. En su lugar, establece variables de entorno en el nivel de plataforma para que los SDK de OpenTelemetry existentes exportan telemetría a Application Insights. Es responsable de instrumentar la aplicación (por ejemplo, mediante sdk o anotaciones de OpenTelemetry) antes de habilitar la configuración automática.

La telemetría fluye a Application Insights, donde se analiza el rendimiento de la aplicación en contexto con Container Insights.

Importante

Grupos de nodos no admitidos: Windows (cualquier arquitectura) .

Roles y responsabilidades

Use las instrucciones siguientes para separar las responsabilidades de la plataforma (clúster) de las responsabilidades de desarrollo de aplicaciones (carga de trabajo). Administrador de clústeres hace referencia al equipo responsable del clúster de AKS y de la canalización de telemetría de Azure Monitor. El desarrollador hace referencia al equipo que posee el código de la aplicación y su configuración de telemetría.

Responsabilidades del administrador del clúster	Responsabilidades del desarrollador
Habilite y mantenga la integración de supervisión de nivel de clúster (configuración o complementos de AKS Monitor).	Instrumente el código de la aplicación mediante SDK de OpenTelemetry (o adopte la instrumentación automática admitida cuando corresponda).
Cree, configure y controle los recursos de Azure compartidos que se usan para la ingesta y el almacenamiento (Application Insights, Azure Monitor área de trabajo, Log Analytics área de trabajo, DCR/DCE, si procede).	Configure la telemetría de la aplicación (atributos de recursos, muestreo, correlación de registros y configuración del exportador) y valide la corrección de la señal.
Administre identidades y permisos necesarios para la exportación de telemetría (identidades administradas, registros de aplicaciones/entidades de servicio de Microsoft Entra, asignaciones de roles de RBAC).	Incorpore cargas de trabajo en el espacio de nombres o el ámbito de implementación (etiquetas, anotaciones o recursos de configuración) siguiendo el patrón admitido de la plataforma.
Defina y aplique la gobernanza del clúster (espacios de nombres, directiva de red, controles de admisión, cuotas y límites) que pueden afectar a la recopilación de telemetría.	Realice reinicios de implementación de las aplicaciones cuando sea necesario para aplicar cambios de supervisión a pods o implementaciones.
Operar y solucionar problemas de componentes de plataforma (Azure Monitor Agente/Prometheus/recopiladores administrados implementados como complementos), incluidos los planes de actualización y reversión.	Solucione los problemas de telemetría de nivel de aplicación (faltan intervalos, métricas o registros, atributos incorrectos, alta cardinalidad y registros ruidosos) y corrija en el código o la configuración.
Proporcione configuraciones de línea de base recomendadas admitidas (puertos o puntos de conexión estándar, expectativas de temporalidad o agregación necesarias, exportadores o procesadores aprobados).	Gestione sus propios SLOs/alertas para la aplicación y utilice las experiencias de Azure Monitor o Application Insights para investigar las regresiones.

Fuera del ámbito de los administradores del clúster: cambiar el código de aplicación, seleccionar bibliotecas y definir la semántica de telemetría de nivel empresarial.

Fuera del ámbito de los desarrolladores: cambio de complementos de clúster, RBAC de plataforma, topología de recursos de ingesta compartida o redes de clúster.

Puntos de colaboración comunes:

• Acepte los estándares de nomenclatura y etiquetado (service.name, k8s.deployment.namey convenciones de espacio de nombres), por lo que los datos son consultables y los paneles funcionan en todos los equipos.
• Pónganse de acuerdo sobre el rendimiento y las directrices de costos (estrategia de muestreo, nivel de detalle de logs y cardinalidad de métricas) y quién hace cambios cuando se superan los límites.
• Defina un flujo de trabajo de soporte técnico para problemas de telemetría (lo que los desarrolladores comprueban primero frente a cuándo escalar al equipo de administración del clúster).
• Planee los cambios conjuntamente cuando abarcan ambas capas (por ejemplo, cambiar el método de ingesta, cambiar las expectativas de punto de conexión o temporalidad o introducir un recopilador).

Prerrequisitos

• Un clúster de AKS en Azure nube pública que ejecuta al menos una implementación de Kubernetes.
• CLI de Azure 2.78.0 o posterior. Instale o actualice mediante las instrucciones de Instalar la documentación de CLI de Azure.
  Compruebe la versión:

  az version
  

• extensión aks-preview CLI de Azure:

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

Nota:

Las API de la versión preliminar de Azure Kubernetes Service (AKS) están diseñadas para permitirle probar y proporcionar comentarios sobre las nuevas características antes de que estén disponibles con carácter general. Debe instalar esta aks-preview extensión antes de poder registrar el flag de características AzureMonitorAppMonitoringPreview.

1. Registrar las características en versión preliminar

Al registrar las características en versión preliminar, habilite la marca de características en la suscripción donde cree el recurso de Application Insights y en la suscripción que hospeda el clúster de AKS.

1. Inicie sesión y seleccione la suscripción de destino:

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

2. Registre la característica y el proveedor de la versión preliminar de 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. Registre las características y el proveedor de la versión preliminar de OTLP de Application Insights:

   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. Preparación del clúster

1. Asegúrese de que el clúster esté integrado en métricas y registros de Azure Monitor. Use Enable monitoring for AKS clusters in Azure Monitor (Application Insights todavía no es obligatorio).
2. Activa Habilitar soporte para Autoinstrumentation y Habilitar soporte para la recopilación de datos de SDKs neutrales en cuanto a proveedor con OpenTelemetry (Vista previa), y a continuación, seleccione Revisar y habilitar.

Si no ha incorporado previamente el clúster, puede habilitar Prometheus Administrado, Registros de Contenedor y Supervisión de Aplicaciones al mismo tiempo.

captura de pantalla

3. Creación de un recurso de Application Insights con compatibilidad con OTLP

Cree o seleccione un recurso de Application Insights que admita OTLP y use áreas de trabajo administradas.

1. En el portal de Azure, cree un nuevo recurso de Application Insights.
2. Activar Habilitar la compatibilidad con OTLP (versión preliminar).
3. Establezca Usar áreas de trabajo administradas en Sí.
   

Importante

• Utilice un área de trabajo Azure Monitor que sea diferente del área de trabajo que se usa para las métricas de infraestructura en el paso 2.
• Las áreas de trabajo administradas crean un área de trabajo de Azure Monitor independiente para la telemetría de aplicaciones de Application Insights mediante un área de trabajo distinta de la que se usa para las métricas de infraestructura.

4. Incorporación de aplicaciones a Application Insights

Puede incorporar todas las implementaciones en un espacio de nombres o seleccionar implementaciones individuales más adelante.

4.1 Abrir el espacio de nombres

1. En el recurso de AKS, expanda Recursos de Kubernetes.
2. Abra Espacios de nombres y, a continuación, seleccione el espacio de nombres que hospeda las cargas de trabajo.

captura de pantalla

4.2 Configurar la supervisión de aplicaciones (versión preliminar)

Al habilitar OTLP, Application Insights agrega compatibilidad con los SDK de OpenTelemetry de código abierto y neutrales para proveedores, así como con los puntos de conexión de OTLP, y almacena las métricas en un área de trabajo de Azure Monitor.

Si no habilita OTLP, Application Insights solo usa la autoinstrumentación de Azure Monitor y la ingestión clásica.

1. Seleccione Supervisión de aplicaciones (versión preliminar) .
2. Elija el recurso de Application Insights con OTLP habilitado que creó anteriormente en el paso 3. Si selecciona o crea un recurso de Application Insights sin OTLP mediante la opción Crear nuevo , no verá la opción Tipo de instrumentación en el paso siguiente.
3. Elija un tipo de instrumentación:
   • Instrumentación configurada por usuario por implementación
     • La configuración automática establece variables de entorno para que los SDK existentes exporten telemetría a Application Insights
     • Cada implementación ya debe tener anotaciones de autoinstrumentación o instrumentación manual. Para más información, consulte Incorporación por implementación.
   • Instrumentación automática de Java para todas las implementaciones para la inserción automática de la distribución de OpenTelemetry de Azure Monitor en aplicaciones Java.
     • Todas las implantaciones en el espacio de nombres usan la autoinstrumentación de Java de forma predeterminada. Use anotaciones para cambiar el idioma o excluir una implementación. Para obtener más información, consulte Instrumentación automática e Incorporación por despliegue.
   • Instrumentación automática de Node.js para todas las implementaciones para la inyección automática de la distribución de OpenTelemetry de Azure Monitor en aplicaciones Node.js.
     • Todas las implementaciones en el espacio de nombres utilizan la autoinstrumentación de Node.js por defecto. Use anotaciones para cambiar el idioma o excluir una implementación. Para obtener más información, consulte Instrumentación automática e integración por despliegue.

   Nota:

   El portal de Azure solo permite aplicar la autoinstrumentación o la configuración automática a un solo espacio de nombres. Si necesita usar ambas opciones, consulte opciones de incorporación por implementación.

4. Deje la opción Realizar reinicio del lanzamiento de todas las implementaciones sin marcar. El reinicio se realiza manualmente en el paso siguiente.
5. Seleccione Configurar.
   

4.3 Reiniciar implementaciones para aplicar cambios

Reinicie las implementaciones en el espacio de nombres de destino desde el comando Ejecutar en el portal o desde el terminal:

kubectl rollout restart deployment -n <your-namespace>

captura de pantalla

Confirmar el estado del instrumento

Volver a Supervisión de aplicaciones (versión preliminar) para el espacio de nombres. Expanda Implementaciones en este espacio de nombres y confirme que las implementaciones muestran el estado Instrumentado.

Sugerencia

Después de unos minutos, la telemetría aparece en el recurso de Application Insights conectado.

Importante

Las experiencias de Application Insights, incluidos los paneles y consultas creados previamente, esperan y requieren métricas de OTLP con temporalidad diferencial y agregación de histograma exponencial.

Al usar la instrumentación automática o la configuración automática de AKS, Azure Monitor usa automáticamente variables de entorno para configurar SDK para exportar métricas con temporalidad diferencial y histogramas exponenciales. No es necesario proporcionar ninguna configuración adicional.

Para obtener más información, consulte Metrics Exporters - OTLP.

5. Visualización de señales de aplicación en Container Insights

Explore el rendimiento de la aplicación en el contexto del clúster mediante Container Insights. En Supervisar en el recurso de AKS, abra Controladores y, a continuación, seleccione un controlador para revisar los errores de solicitud, las operaciones lentas y las investigaciones sugeridas.

Para profundizar en Container Insights, seleccione un nodo de componente de aplicación en el mapa de aplicaciones.

Seleccione el nodo, y luego Investigar pods en el icono de supervisión de AKS.

Incorporación avanzada (recursos personalizados)

Use los recursos personalizados de Kubernetes cuando necesite más control. Para obtener más información, consulte Incorporación por implementación.

Autoinstrumentation (Java, Node.js)

Siga las instrucciones de incorporación a nivel de espacio de nombres (namespace) o por implementación (per-deployment) en el artículo vinculado anteriormente para insertar la distribución de OpenTelemetry de Azure Monitor en los pods.

Para participar en la versión preliminar pública limitada de Autoinstrumentation para .NET o Python, consulte Enable AKS autoinstrumentation for Python and .NET (versión preliminar limitada).

Configuración automática (aplicaciones ya instrumentadas con SDK de OpenTelemetry)

La configuración automática establece variables de entorno para que los SDK existentes exporten telemetría a Application Insights a través del agente de Azure Monitor en el clúster. No coloca ningún SDK en el pod.

• A nivel de espacio de nombres: Establezca el recurso personalizado Instrumentación con una lista de plataformas vacía.

  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/"
  

• Para cada implementación: agregue la anotación a la implementación y haga referencia al recurso personalizado de instrumentación (reemplace cr1 con el nombre del recurso).

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

Cuando se usa la anotación inject-configuration, se omite la configuración de spec.settings.autoInstrumentationPlatforms en el recurso personalizado al que se hace referencia y la implementación está configurada para enviar datos de OTLP al cadena de conexión definido en applicationInsightsConnectionString. Utilice el valor de anotación "false" para excluir una implementación de autoconfiguración.

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

Limitaciones

Durante la versión preliminar, la característica está disponible en todas las regiones de nube pública, excepto:

• Centro de Israel
• Noroeste de Israel
• Qatar Central
• Norte de Emiratos Árabes Unidos
• Centro de Emiratos Árabes Unidos

Si necesita nombres de programación para estas regiones, consulte Azure lista de regiones.

Limits

• La característica solo acepta OTLP/HTTP con Protobuf binario. No admite cargas JSON ni OTLP/gRPC. Debe configurar el exportador de OTLP en consecuencia al usar la configuración automática con los SDK independientes del proveedor y de código abierto.
• La característica admite hasta 30 asociaciones de regla de recopilación de datos (DCR) por clúster de AKS.
• La escala probada para registros y seguimientos es de 50 000 eventos por segundo (EPS). Puede esperar aproximadamente 250 miB de uso adicional de memoria y 0,5 vCPU por clúster para esta característica.

Escenarios no soportados

• Compresión en exportadores del SDK de OpenTelemetry.
• Espacios de nombres con Istio mutual TLS (mTLS) habilitado.
• Puntos de conexión HTTPS en la configuración de instrumentación.

Escenarios no validados

• Clústeres de AKS que usan un proxy HTTP.
• Clústeres de AKS que usan Private Link.
• Clústeres de pila doble de AKS.

Pasos siguientes

• Obtenga información sobre cómo funciona la instrumentación sin código para Kubernetes y cómo incorporar implementaciones.
• Revise el artículo Habilitar la supervisión para clústeres de AKS para comprender la supervisión de la infraestructura con Azure Monitor.
• Aprenda a configurar la supervisión de aplicaciones con Azure Monitor y OTLP para otros entornos con el agente de Azure Monitor o el colector de OpenTelemetry de código abierto.

Support

Si la documentación y los pasos de este artículo no resuelven el problema o quiere proporcionar comentarios, envíe un correo electrónico al equipo de OpenTelemetry Azure Monitor en otel@microsoft.com.