Conceptos básicos de la recopilación de datos de Azure Monitor Application Insights
Artículo
Para poder supervisar la aplicación, debe instrumentarse.
En las secciones siguientes, tratamos algunos aspectos básicos de la recopilación de datos de Azure Monitor Application Insights.
Opciones de instrumentación
En un nivel básico, la "instrumentación" simplemente permite que una aplicación capture telemetría.
Hay dos métodos para instrumentar la aplicación:
Instrumentación automática (autoinstrumentación)
Instrumentación manual
La Autoinstrumentación habilita la recopilación de telemetría mediante configuración sin tocar el código de la aplicación. Aunque es más conveniente, tiende a ser menos configurable. Tampoco está disponible en todos los lenguajes. Consulte Entornos y lenguajes compatibles con la autoinstrumentación. Cuando la instrumentación automática está disponible, es la manera más fácil de habilitar Azure Monitor Application Insights.
Sugerencia
Actualmente, Autenticación de Microsoft Entra no está disponible con la instrumentación automática. Si necesita autenticación de Microsoft Entra, deberá usar la instrumentación manual.
La instrumentación manual consiste en crear código para Application Insights o la API de OpenTelemetry. En el contexto de un usuario, normalmente hace referencia a la instalación de un SDK específico del lenguaje en una aplicación. Esto significa que tiene que administrar las actualizaciones de la versión más reciente del paquete por su cuenta. Puede usar esta opción si necesita realizar llamadas de dependencia personalizadas o llamadas API que no se capturan de forma predeterminada con la implementación automática. Hay dos opciones para la instrumentación manual:
Aunque consideramos OpenTelemetry como nuestra dirección futura, no tenemos planes de dejar de recopilar datos de SDK más antiguos. Todavía tenemos un camino por recorrer antes de que la distribución de OpenTelemetry de Azure alcance la paridad de características con los SDK de Application Insights. En muchos casos, los clientes siguen optando por utilizar los SDK de Application Insights durante bastante tiempo.
Importante
"Manual" no significa que se le pedirá que escriba un código complejo para definir los intervalos de los seguimientos distribuidos (aunque sigue siendo una opción). Las bibliotecas de instrumentación empaquetadas en nuestras distribuciones le permiten capturar fácilmente señales de telemetría en marcos y bibliotecas comunes. Estamos trabajando activamente para instrumentar los SDK de servicio de Azure más populares mediante OpenTelemetry, por lo que estas señales están disponibles para los clientes que usan la distribución OpenTelemetry de Azure Monitor.
Tipos de telemetría
La telemetría, los datos recopilados para observar la aplicación, se puede dividir en tres tipos o "pilares":
Seguimiento distribuido
Métricas
Registros
Una historia de observabilidad completa incluye los tres pilares, y Application Insights desglosa aún más estos pilares en tablas basadas en nuestro modelo de datos. Nuestros SDK de Application Insights o las distribuciones de OpenTelemetry de Azure Monitor incluyen todo lo que necesita para impulsar la supervisión del rendimiento de las aplicaciones en Azure. La instalación del paquete en sí es gratuita y solo pagará por los datos que ingiera en Azure Monitor.
Hay dos maneras de enviar los datos a Azure Monitor (o a cualquier proveedor):
Mediante un exportador directo
Mediante un agente
Un exportador directo envía datos de telemetría en proceso (desde el código de la aplicación) directamente al punto de conexión de ingesta de Azure Monitor. La principal ventaja de este enfoque es la simplicidad de la incorporación.
Los SDK de Application Insights y las distribuciones de OpenTelemetry de Azure Monitor disponibles actualmente se basan en un exportador directo.
Si tiene previsto usar OpenTelemetry-Collector para el muestreo o el procesamiento de datos adicional, es posible que pueda obtener estas mismas funcionalidades integradas en Azure Monitor. Los clientes que han migrado a Application Insights basado en el área de trabajo pueden beneficiarse de las transformaciones en tiempo de ingesta. Para habilitarlas, siga los detalles del tutorial y omita el paso que muestra cómo configurar una configuración de diagnóstico, ya que con Application Insights centrado en el área de trabajo, esto ya está configurado. Si está filtrando menos del 50 % del volumen total, no supone un costo adicional. A partir del 50 %, hay un coste, pero mucho menor que la tarifa estándar por GB.
OpenTelemetry
Microsoft está encantado de adoptar OpenTelemetry como futuro de la instrumentación de telemetría. Nuestros clientes pidieron instrumentación neutral del proveedor y estamos encantados de asociarnos con la comunidad de OpenTelemetry para crear API y SDK coherentes en todos los lenguajes.
Microsoft ha colaborado con las partes interesadas del proyecto procedentes de dos proyectos de telemetría de código abierto anteriormente populares, OpenCensus y OpenTracing. Juntos, hemos ayudado a crear un único proyecto, OpenTelemetry. OpenTelemetry incluye contribuciones de todos los principales proveedores de administración del rendimiento de aplicaciones y de la nube (APM) y reside en la base de software de código abierto Cloud Native Computing Foundation (CNCF). Microsoft es miembro Platinum de CNCF.
Para conocer la terminología, consulte el glosario en las especificaciones de OpenTelemetry.
Algunos términos heredados de Application Insights son confusos debido a la convergencia del sector en OpenTelemetry. En la tabla siguiente se destacan estas diferencias. Los términos de OpenTelemetry reemplazan los términos de Application Insights.
Azure Monitor Exporter usa EventSource para su registro interno. Los registros del exportador están disponibles para cualquier EventListener al participar en el origen denominado OpenTelemetry-AzureMonitor-Exporter. Puede consultar los pasos para solucionar distintos problemas en Solución de problemas de OpenTelemetry en GitHub.
Paso 2: Probar la conectividad entre el host de la aplicación y el servicio de ingesta
Tanto los SDK como los agentes de Application Insights envían telemetría para ingerirse como llamadas de REST en los puntos de conexión de ingesta. Para probar la conectividad entre el servidor web o el equipo host de la aplicación y los puntos de conexión del servicio de ingesta, use comandos cURL o solicitudes REST sin procesar de PowerShell. Para obtener más información, consulte Solución de problemas de telemetría de aplicaciones que faltan en Application Insights de Azure Monitor.
Problemas conocidos
Los siguientes puntos son problemas conocidos para los exportadores de OpenTelemetry de Azure Monitor:
Falta el nombre de la operación de la telemetría de dependencias. El nombre de la operación que falta provoca errores y afecta negativamente a la experiencia de la pestaña de rendimiento.
Falta el modelo de dispositivo de la telemetría de solicitudes y dependencias. El modelo de dispositivo que falta afecta negativamente al análisis de cohortes de dispositivos.
Paso 1: Habilitar el registro de diagnóstico
Azure Monitor Exporter usa EventSource para su registro interno. Los registros del exportador están disponibles para cualquier EventListener al participar en el origen denominado OpenTelemetry-AzureMonitor-Exporter. Puede consultar los pasos para solucionar distintos problemas en Solución de problemas de OpenTelemetry en GitHub.
Paso 2: Probar la conectividad entre el host de la aplicación y el servicio de ingesta
Tanto los SDK como los agentes de Application Insights envían telemetría para ingerirse como llamadas de REST en los puntos de conexión de ingesta. Para probar la conectividad entre el servidor web o el equipo host de la aplicación y los puntos de conexión del servicio de ingesta, use comandos cURL o solicitudes REST sin procesar de PowerShell. Para obtener más información, consulte Solución de problemas de telemetría de aplicaciones que faltan en Application Insights de Azure Monitor.
Problemas conocidos
Los siguientes puntos son problemas conocidos para los exportadores de OpenTelemetry de Azure Monitor:
Falta el nombre de la operación de la telemetría de dependencias. El nombre de la operación que falta provoca errores y afecta negativamente a la experiencia de la pestaña de rendimiento.
Falta el modelo de dispositivo de la telemetría de solicitudes y dependencias. El modelo de dispositivo que falta afecta negativamente al análisis de cohortes de dispositivos.
Paso 2: Probar la conectividad entre el host de la aplicación y el servicio de ingesta
Tanto los SDK como los agentes de Application Insights envían telemetría para ingerirse como llamadas de REST en los puntos de conexión de ingesta. Para probar la conectividad entre el servidor web o el equipo host de la aplicación y los puntos de conexión del servicio de ingesta, use comandos cURL o solicitudes REST sin procesar de PowerShell. Para obtener más información, consulte Solución de problemas de telemetría de aplicaciones que faltan en Application Insights de Azure Monitor.
Problemas conocidos
Si descarga la biblioteca cliente de Application Insights para la instalación desde un explorador, a veces el archivo JAR descargado está dañado y es aproximadamente la mitad del tamaño del archivo de origen. Si experimenta este problema, descargue el archivo JAR ejecutando el comando curl o wget, como se muestra en las llamadas de comando de ejemplo siguientes:
Las llamadas de comando de ejemplo se aplican a Application Insights para Java versión 3.4.11. Para buscar el número de versión y la dirección URL de la versión actual de Application Insights para Java, visite https://github.com/microsoft/ApplicationInsights-Java/releases.
Los pasos siguientes son aplicables a las aplicaciones nativas de Spring Boot.
Paso 1: Comprobar la versión de OpenTelemetry
Es posible que observe el siguiente mensaje durante el inicio de la aplicación:
WARN c.a.m.a.s.OpenTelemetryVersionCheckRunner - The OpenTelemetry version is not compatible with the spring-cloud-azure-starter-monitor dependency.
The OpenTelemetry version should be <version>
En este caso, debe importar las listas de materiales de OpenTelemetry siguiendo la documentación de OpenTelemetry en Spring Boot starter.
Paso 2: Habilitar el autodiagnóstico
Si algo no funciona según lo previsto, puede habilitar el autodiagnóstico en el nivel de DEBUG para obtener información. Para ello, establezca el nivel de autodiagnóstico en ERROR, WARN, INFO, DEBUG o TRACE mediante la variable de entorno APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL.
Para habilitar el autodiagnóstico en el nivel de DEBUG al ejecutar un contenedor Docker, ejecute el siguiente comando:
docker run -e APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL=DEBUG <image-name>
Nota:
Reemplace <image-name> por el nombre de la imagen de Docker según corresponda.
Aviso de declinación de responsabilidades sobre la información de terceros
Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.
Paso 1: Habilitar el registro de diagnóstico
Azure Monitor Exporter usa el registrador de la API de OpenTelemetry para los registros internos. Para habilitar el registrador, ejecute el siguiente fragmento de código:
Paso 2: Probar la conectividad entre el host de la aplicación y el servicio de ingesta
Tanto los SDK como los agentes de Application Insights envían telemetría para ingerirse como llamadas de REST en los puntos de conexión de ingesta. Para probar la conectividad entre el servidor web o el equipo host de la aplicación y los puntos de conexión del servicio de ingesta, use comandos cURL o solicitudes REST sin procesar de PowerShell. Para obtener más información, consulte Solución de problemas de telemetría de aplicaciones que faltan en Application Insights de Azure Monitor.
Problemas conocidos
Los siguientes puntos son problemas conocidos para los exportadores de OpenTelemetry de Azure Monitor:
Falta el nombre de la operación de la telemetría de dependencias. El nombre de la operación que falta provoca errores y afecta negativamente a la experiencia de la pestaña de rendimiento.
Falta el modelo de dispositivo de la telemetría de solicitudes y dependencias. El modelo de dispositivo que falta afecta negativamente al análisis de cohortes de dispositivos.
Falta el nombre del servidor de bases de datos del nombre de la dependencia. Dado que no se incluye el nombre del servidor de bases de datos, los exportadores de OpenTelemetry agregan tablas que tienen el mismo nombre incorrectamente en servidores diferentes.
Paso 1: Habilitar el registro de diagnóstico
Microsoft Azure Monitor Exporter usa la Biblioteca de registro estándar de Python para sus registros internos. A la API de OpenTelemetry y a los registros de Azure Monitor Exporter se les asigna un nivel de gravedad WARNING o ERROR para las actividades irregulares. El nivel de gravedad INFO se usa con relación a las actividades normales o correctas.
De manera predeterminada, la biblioteca de registro de Python establece el nivel de gravedad en WARNING. Por lo tanto, debe cambiar el nivel de gravedad para ver los registros en esta configuración de gravedad. En el código de ejemplo siguiente, se muestra cómo generar registros de todos los niveles de gravedad en la consola y en un archivo:
Paso 2: Probar la conectividad entre el host de la aplicación y el servicio de ingesta
Tanto los SDK como los agentes de Application Insights envían telemetría para ingerirse como llamadas de REST en los puntos de conexión de ingesta. Para probar la conectividad entre el servidor web o el equipo host de la aplicación y los puntos de conexión del servicio de ingesta, use comandos cURL o solicitudes REST sin procesar de PowerShell. Para obtener más información, consulte Solución de problemas de telemetría de aplicaciones que faltan en Application Insights de Azure Monitor.
Paso 3: Evitar la telemetría duplicada
La telemetría duplicada suele deberse a que se crean varias instancias de procesadores o exportadores. Asegúrese de ejecutar solo un exportador y procesador a la vez para cada pilar de telemetría (registros, métricas y seguimiento distribuido).
En las secciones siguientes, se describen escenarios que pueden generar telemetría duplicada.
Registros de seguimiento duplicados en Azure Functions
Si ve un par de entradas para cada registro de seguimiento en Application Insights, probablemente habilitó los siguientes tipos de instrumentación de registro:
La instrumentación de registro nativa en Azure Functions
La instrumentación de registro azure-monitor-opentelemetry dentro de la distribución
Para evitar la duplicación, puede deshabilitar el registro de la distribución, pero dejar habilitada la instrumentación de registro nativa en Azure Functions. Para ello, establezca la variable de entorno OTEL_LOGS_EXPORTER en None.
Telemetría duplicada en "Always On" de Azure Functions
Si la configuración Always On de Azure Functions está establecida en Activada, Azure Functions mantiene algunos procesos en ejecución en segundo plano una vez completada cada ejecución. Por ejemplo, supongamos que tiene una función de temporizador de cinco minutos que llama a configure_azure_monitor cada vez. Después de 20 minutos, es posible que tenga cuatro exportadores de métricas que se ejecutan al mismo tiempo. Esta situación podría ser el origen de la telemetría de métricas duplicadas.
En esta situación, establezca el valor Always On en Desactivadao intente apagar manualmente los proveedores entre cada llamada configure_azure_monitor. Para apagar cada proveedor, ejecute llamadas de apagado para cada medidor, seguimiento y proveedor de registrador actuales, como se muestra en el código siguiente:
Azure Workbooks y Jupyter Notebooks pueden mantener los procesos de los exportadores en ejecución en segundo plano. Para evitar la telemetría duplicada, borre la memoria caché antes de realizar más llamadas a configure_azure_monitor.
Paso 4: Asegurarse de que se recopilan los datos de solicitud de Flask
Si implementa una aplicación de Flask, es posible que no pueda recopilar datos de la tabla Requests de Application Insights mientras usa la biblioteca cliente de distribución de OpenTelemetry de Azure Monitor para Python. Este problema podría producirse si no estructura correctamente las declaraciones import. Es posible que esté importando el marco de aplicación web flask.Flask antes de llamar a la función configure_azure_monitor para instrumentar la biblioteca de Flask. Por ejemplo, el código siguiente no instrumenta correctamente la aplicación de Flask:
from azure.monitor.opentelemetry import configure_azure_monitor
from flask import Flask
configure_azure_monitor()
app = Flask(__name__)
En su lugar, se recomienda importar el módulo flask en su conjunto y, después, llamar a configure_azure_monitor para configurar OpenTelemetry para usar Azure Monitor antes de acceder a flask.Flask:
from azure.monitor.opentelemetry import configure_azure_monitor
import flask
configure_azure_monitor()
app = flask.Flask(__name__)
Como alternativa, puede llamar a configure_azure_monitor antes de importar flask.Flask:
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor()
from flask import Flask
app = Flask(__name__)
Soporte técnico
Seleccione una pestaña para el idioma que prefiera para detectar las opciones de soporte técnico.
En caso de problemas de OpenTelemetry, póngase en contacto directamente con la comunidad de OpenTelemetry.
Para obtener una lista de problemas abiertos relacionados con la instrumentación automática de Java de Azure Monitor, consulte la página de problemas de GitHub.
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.