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 añade soporte de Vista Previa para aplicaciones de monitorización que se ejecutan en Azure Kubernetes Service (AKS) utilizando el Protocolo OpenTelemetry (OTLP) para la instrumentación y la recogida 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 datos de telemetría (identidades administradas, registros de aplicaciones/entidades de servicio de Microsoft Entra, asignaciones de roles de RBAC). Para incorporar cargas de trabajo en el espacio de nombres o el ámbito de implementación (etiquetas, anotaciones o recursos de configuración) siga 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 lanzamiento de las aplicaciones cuando sea necesario para aplicar cambios de supervisión a pods o implementaciones.
Opere y solucione problemas de componentes de plataforma (Agente de Azure Monitor/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). Defina sus propios SLOs y alertas para la aplicación y utilice herramientas como 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.
  • Acuerde los límites de rendimiento y coste (estrategia de muestreo, nivel de detalle de los registros y cardinalidad de métricas) y quién debe realizar qué cambios cuando se superen dichos 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.
  • Azure CLI 2.78.0 o posterior. Instale o actualice mediante las instrucciones de Instalar la documentación de Azure CLI.
    Compruebe la versión: 
    az version
  • extensión aks-preview Azure CLI:
    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. Necesitas instalar esta aks-preview extensión antes de poder registrar la función 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 las métricas y registros de Azure Monitor. Usa Habilitar la monitorización para clústeres de AKS en Azure Monitor (Application Insights todavía no es obligatorio).
  2. Activa Habilitar soporte para Autoinstrumentación y Habilitar soporte para la recogida de datos desde SDKs OpenTelemetry neutrales para proveedores (Vista previa), y luego selecciona Revisar + activar.

Si no estabas previamente en el clúster, puedes activar Prometheus gestionado, Registros de contenedores y monitorización de aplicaciones al mismo tiempo.

Una captura de pantalla de la página de configuración de Azure que muestra la opción de habilitar la aplicación.

captura de pantalla Una captura de pantalla de la página de revisión de configuración de Azure mostrando la opción de habilitar la aplicación.

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í.
    Captura de pantalla de Creación de un recurso de Application Insights con la opción habilitar seleccionada.

Importante

  • Utilice un área de trabajo de 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.

Una captura de pantalla de la lista de namespaces de Azure en recursos de Kubernetes.

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

Cuando activas OTLP, Application Insights añade soporte para SDKs OpenTelemetry y endpoints OTLP de código abierto y neutrales para el proveedor, y almacena métricas en un espacio de trabajo Azure Monitor.

Si no habilita OTLP, Application Insights solo usa Azure Monitor para la autoinstrumentación y la inclusió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, consulta Incorporaciónpor despliegue.
    • Instrumentación automática de Java para todas las implementaciones para la inyección automática de la distribución de Azure Monitor OpenTelemetry en aplicaciones Java.
    • Instrumentación automática de Node.js para todas las implementaciones permite la inyección automática de la distribución OpenTelemetry de Azure Monitor en aplicaciones Node.js.

    Nota:

    El portal de Azure solo permite aplicar la autoinstrumentación o la autoconfiguración a un único espacio de nombres. Si necesita usar ambas opciones, consulte las 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.
    Captura de pantalla del panel de configuración de la aplicación con selecciones de recursos e idioma.

4.3 Reiniciar implementaciones para aplicar cambios

Reiniciar despliegues en el espacio de nombres de destino desde el comando Run en el portal o desde tu terminal:

kubectl rollout restart deployment -n <your-namespace>

captura de pantalla Una captura de pantalla de la pantalla de comandos de Azure run mostrando el comando de reinicio de despliegue.

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.

Captura de pantalla de la lista de despliegues de aplicaciones y su 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, que incluyen paneles y consultas precompilados, requieren y esperan métricas de OTLP con temporalidad delta 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.

Captura de pantalla de la vista del controlador que muestra las métricas de rendimiento.

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

Captura de pantalla de la vista del controlador en la que se muestran las solicitudes con errores.

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 más información, consulta Incorporaciónpor despliegue.

Autoinstrumentación (Java, Node.js)

Siga las instrucciones de incorporación para todo el espacio de nombres o por implementación que se incluyen en el artículo vinculado anteriormente para inyectar la distribución de Azure Monitor OpenTelemetry en sus 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: Configura el recurso personalizado de Instrumentación con una lista vacía de plataformas. 
    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 connection string 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

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.

  • Last updated on