Ayuda, soporte técnico y comentarios de OpenTelemetry

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 kits de desarrollo de software (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 1: Habilitar el registro de diagnóstico

De manera predeterminada, el registro de diagnóstico está habilitado en Application Insights de Azure Monitor. Para más información, consulte Guía de solución de problemas: Application Insights de Azure Monitor para Java.

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:

  curl --location --output applicationinsights-agent-.jar https://github.com/microsoft/ApplicationInsights-Java/releases/download//applicationinsights-agent-.jar
  

  wget --output-document=applicationinsights-agent-.jar https://github.com/microsoft/ApplicationInsights-Java/releases/download//applicationinsights-agent-.jar
  

  Nota:

  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>

Aviso de declinación de responsabilidades sobre la información de terceros

Microsoft no otorga ninguna garantía, implícita o de otro tipo, sobre el rendimiento o la confiabilidad de estos productos de terceros independientes.

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:

const { diag, DiagConsoleLogger, DiagLogLevel } = require("@opentelemetry/api");
const { NodeTracerProvider } = require("@opentelemetry/sdk-trace-node");

const provider = new NodeTracerProvider();
diag.setLogger(new DiagConsoleLogger(), DiagLogLevel.ALL);
provider.register();

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:

...
import logging

logging.basicConfig(format = "%(asctime)s:%(levelname)s:%(message)s", level = logging.DEBUG)

logger = logging.getLogger(__name__)
file = logging.FileHandler("example.log")
stream = logging.StreamHandler()
logger.addHandler(file)
logger.addHandler(stream)
...

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 lograr este objetivo, 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:

get_meter_provider().shutdown()
get_tracer_provider().shutdown()
get_logger_provider().shutdown()

Azure Workbooks y Jupyter Notebooks

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__)

• En caso de problemas de Soporte técnico de Azure, abra una incidencia de Soporte técnico de Azure.
• En caso de problemas de OpenTelemetry, póngase en contacto con la comunidad de .NET de OpenTelemetry directamente.
• Para obtener una lista de problemas abiertos relacionados con el exportador de Azure Monitor, consulte la página de problemas de GitHub.

• En caso de problemas de Soporte técnico de Azure, abra una incidencia de Soporte técnico de Azure.
• En caso de problemas de OpenTelemetry, póngase en contacto con la comunidad de .NET de OpenTelemetry directamente.
• Para obtener una lista de problemas abiertos relacionados con el exportador de Azure Monitor, consulte la página de problemas de GitHub.

• En caso de problemas de Soporte técnico de Azure, abra una incidencia de Soporte técnico de Azure.
• Para obtener ayuda para solucionar problemas, consulte Pasos para la solución de problemas.
• 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.

• En caso de problemas de Soporte técnico de Azure, abra una incidencia de Soporte técnico de Azure.
• En caso de problemas de OpenTelemetry, póngase en contacto directamente con la comunidad de OpenTelemetry.
• Para obtener una lista de problemas abiertos con aplicaciones nativas de Spring Boot, consulte la página Problemas de GitHub.
• Para obtener una lista de problemas abiertos con aplicaciones nativas de Quarkus, consulte la página Problemas de GitHub.

• En caso de problemas de Soporte técnico de Azure, abra una incidencia de Soporte técnico de Azure.
• En caso de problemas de OpenTelemetry, póngase en contacto con la comunidad de JavaScript de OpenTelemetry directamente.
• Para obtener una lista de problemas abiertos relacionados con el exportador de Azure Monitor, consulte la página de problemas de GitHub.

• En caso de problemas de Soporte técnico de Azure, abra una incidencia de Soporte técnico de Azure.
• En caso de problemas de OpenTelemetry, póngase en contacto con la comunidad de Python de OpenTelemetry directamente.
• Para obtener una lista de problemas abiertos relacionados con la distribución de Azure Monitor, consulte la página de problemas de GitHub.