Ayuda, soporte técnico y comentarios de OpenTelemetry

Artigo
10/14/2024

En este artículo se proporcionan opciones de ayuda, soporte técnico y comentarios para OpenTelemetry en Application Insights de Azure Monitor para aplicaciones de .NET, Java, Node.js y Python.

Consulte las preguntas más frecuentes
Completar pasos para solucionar problemas
Obtener soporte
Proporcionar comentarios

Preguntas más frecuentes

¿Qué es OpenTelemetry?

Es un nuevo estándar de código abierto dirigido a la observabilidad. Obtenga más información en OpenTelemetry.

¿Por qué Microsoft Azure Monitor invierte en OpenTelemetry?

Microsoft está invirtiendo en OpenTelemetry por las siguientes razones:

Es neutral con respecto a los proveedores y proporciona API y SDK coherentes en todos los idiomas.
Con el tiempo, creemos que OpenTelemetry permitirá a los clientes de Azure Monitor observar las aplicaciones escritas en lenguajes más allá de los lenguajes admitidos.
Expande los tipos de datos que puede recopilar a través de un amplio conjunto de bibliotecas de instrumentación.
Los kits de desarrollo de software (SDK) de OpenTelemetry tienden a ser más eficaces a escala que sus predecesores, los SDK de Application Insights.
OpenTelemetry se alinea con la estrategia de Microsoft para adoptar el código abierto.

¿Cuál es el estado de OpenTelemetry?

Ver el Estado de OpenTelemetry.

¿Qué es la distribución de OpenTelemetry de Azure Monitor?

Puede considerarlo como un contenedor fino que agrupa todos los componentes de OpenTelemetry para una experiencia de primera clase en Azure. Este contenedor también se denomina una distribución en OpenTelemetry.

¿Por qué debería usar la distribución de OpenTelemetry de Azure Monitor?

El uso de la Distribución de OpenTelemetry de Azure Monitor tiene varias ventajas sobre la OpenTelemetry nativa de la comunidad:

Reduce el esfuerzo de habilitación
Compatible con Microsoft
Incorpora características específicas de Azure como:
- Muestreo compatible con SDK clásicos de Application Insights
- Autenticación de Microsoft Entra
- Almacenamiento sin conexión y reintentos automáticos
- Statsbeat
- Métricas estándar de Application Insights
- Detección de metadatos de recursos para rellenar automáticamente el Nombre del rol en la nube y la Instancia de rol en la nube en varios entornos de Azure
- Live Metrics

Siguiendo el espíritu de OpenTelemetry, diseñamos la distribución para que sea abierta y ampliable. Por ejemplo, puede agregar:

Un exportador de OpenTelemetry Protocol (OTLP) y enviar a un segundo destino simultáneamente
Otras bibliotecas de instrumentación no incluidas en la distribución

Dado que la distribución proporciona una distribución de OpenTelemetry, la distribución admite cualquier cosa compatible con OpenTelemetry. Por ejemplo, puede agregar más procesadores de telemetría, exportadores o bibliotecas de instrumentación, si OpenTelemetry los admite.

Nota:

La distribución establece el tomador de muestras en una toma personalizada de frecuencia fija para Application Insights. Puede cambiar esto a otro tomador de muestras, pero si lo hace, puede deshabilitar algunas de las funcionalidades incluidas de la distribución. Para más información sobre el tomador de muestras admitido, consulte la sección Habilitar muestreo de Configuración de OpenTelemetry de Azure Monitor.

En el caso de los lenguajes sin un exportador de OpenTelemetry independiente compatible, la distribución de OpenTelemetry de Azure Monitor es la única manera admitida actualmente para usar OpenTelemetry con Azure Monitor. En el caso de los idiomas con un exportador de OpenTelemetry independiente compatible, tiene la opción de usar la distribución de OpenTelemetry de Azure Monitor o el exportador de OpenTelemetry independiente adecuado en función del escenario de telemetría. Para más información, consulte ¿Cuándo debo usar el exportador de OpenTelemetry de Azure Monitor?.

¿Cómo puedo probar la Distribución de OpenTelemetry de Azure Monitor?

Consulte nuestros documentos de habilitación para .NET, Java, JavaScript (Node.js) y Python.

¿Debería usar OpenTelemetry o el SDK de Application Insights?

Se recomienda usar la distribución de OpenTelemetry, a menos que necesite una característica que solo esté disponible con soporte técnico formal en el SDK de Application Insights.

Adoptar OpenTelemetry ahora evita tener que migrar más adelante.

¿Cuándo debo usar el exportador OpenTelemetry de Azure Monitor?

Para ASP.NET Core, Java, Node.js y Python, se recomienda usar la distribución de OpenTelemetry de Azure Monitor. Es una línea de código para empezar.

Para todos los demás escenarios de .NET, incluidos los ASP.NET clásicos, las aplicaciones de consola, Windows Forms (WinForms), etc., se recomienda usar el exportador de OpenTelemetry de Azure Monitor de .NET: Azure.Monitor.OpenTelemetry.Exporter.

Para escenarios de telemetría de Python más complejos que requieren configuración avanzada, se recomienda usar el Exportador de OpenTelemetry de Azure Monitor de Python.

¿Cuál es el estado actual de las características de la Distribución de OpenTelemetry de Azure Monitor?

En el gráfico siguiente, se desglosa la compatibilidad de características de OpenTelemetry para cada lenguaje.

Característica	.NET	Node.js	Python	Java
Seguimiento distribuido	✅	✅	✅	✅
Métricas personalizadas	✅	✅	✅	✅
Métricas estándar	✅	✅	✅	✅
Muestreo de frecuencia fija	✅	✅	✅	✅
Almacenamiento sin conexión y reintentos automáticos	✅	✅	✅	✅
Informes de excepciones	✅	✅	✅	✅
Recopilación de registros	✅	⚠️	✅	✅
Eventos personalizados	⚠️	⚠️	⚠️	✅
Autenticación de Microsoft Entra	✅	✅	✅	✅
Live metrics	✅	✅	✅	✅
Filtrado de métricas dinámicas	✅	❌	❌	❌
Detección del contexto de recursos para VM/VMSS y App Service	✅	❌	✅	✅
Detección del contexto de recursos para Azure Kubernetes Service (AKS) y Functions	❌	❌	❌	✅
Eventos de pruebas de disponibilidad generados mediante la API de seguimiento de disponibilidad	❌	❌	❌	✅
Filtrar solicitudes, dependencias, registros y excepciones por identificador de usuario anónimo y origen sintético	❌	❌	❌	✅
Filtrar las dependencias, los registros y las excepciones por nombre de la operación	❌	❌	❌	✅
muestreo adaptable	❌	❌	❌	✅
Generador de perfiles	❌	❌	❌	⚠️
Depurador de instantáneas	❌	❌	❌	❌

Clave

✅ Esta característica está disponible para todos los clientes con soporte técnico formal.
⚠ Esta característica está disponible como versión preliminar pública. Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure.
❌ Esta característica no está disponible o no es aplicable.

¿Se puede usar OpenTelemetry para exploradores web?

Sí, pero no se recomienda y Azure no lo admite. OpenTelemetry para Javascript está muy optimizado para Node.js. En su lugar, se recomienda usar el SDK de JavaScript para Application Insights.

¿Cuándo podemos esperar que el SDK de OpenTelemetry esté disponible para su uso en navegadores web?

El SDK web de OpenTelemetry no tiene una escala de tiempo de disponibilidad determinada. Es probable que falten varios años para que exista un SDK para navegadores que sea una alternativa viable al SDK de JavaScript Application Insights.

¿Puedo probar hoy OpenTelemetry en un explorador web?

El espacio aislado web de OpenTelemetry es una bifurcación diseñada para que OpenTelemetry funcione en un explorador. Todavía no es posible enviar telemetría a Application Insights. El SDK no define eventos de cliente generales.

¿Ejecuta Application Insights junto con agentes de la competencia como AppDynamics, DataDog y NewRelic compatibles?

Esta práctica no es algo que tengamos previsto probar o admitir, aunque nuestras distribuciones le permiten exportar a un punto de conexión OTLP junto con Azure Monitor simultáneamente.

¿Se pueden usar las características en vista previa (GB) en entornos de producción?

Esta opción no se recomienda. Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure.

¿Cuál es la diferencia entre la instrumentación manual y la automática?

Consulte la Introducción a OpenTelemetry.

¿Puedo usar OpenTelemetry-Collector?

Algunos clientes usan OpenTelemetry Collector como alternativa con agente, aunque Microsoft todavía no admite oficialmente un enfoque basado en agente para la supervisión de aplicaciones. Mientras tanto, la comunidad de código abierto contribuyó con un exportador de Azure Monitor de OpenTelemetry Collector que algunos clientes usan para enviar datos a Application Insights de Azure Monitor. Microsoft no admite esto.

¿Cuál es la diferencia entre OpenCensus y OpenTelemetry?

OpenCensus es el precursor de OpenTelemetry. Microsoft ayudó a juntar OpenTracing y OpenCensus para crear OpenTelemetry, un único estándar de observabilidad para el mundo. El SDK de Python recomendado para producción actual para Azure Monitor se basa en OpenCensus. Microsoft se ha comprometido a hacer que Azure Monitor se base en OpenTelemetry.

En Grafana, ¿por qué veo `Status: 500. Can't visualize trace events using the trace visualizer`?

Podría intentar visualizar registros de texto sin formato en lugar de seguimientos de OpenTelemetry.

En Application Insights, la tabla "Seguimientos" almacena registros de texto sin procesar con fines de diagnóstico. Ayudan a identificar y correlacionar seguimientos asociados a solicitudes de usuario, otros eventos e informes de excepciones. Sin embargo, la tabla "Seguimientos" no contribuye directamente a la vista de transacciones de un extremo a otro (gráfico en cascada) en herramientas de visualización como Grafana.

Con la creciente adopción de prácticas nativas de la nube, hay una evolución en la recopilación de telemetría y la terminología. OpenTelemetry se convirtió en un estándar para recopilar e instrumentar datos de telemetría. En este contexto, el término "Seguimientos" tomó un nuevo significado. En lugar de los registros sin procesar, "Seguimientos" en OpenTelemetry hacen referencia a una forma más completa y estructurada de telemetría que incluye intervalos, que representan unidades de trabajo individuales. Estos intervalos son cruciales para construir vistas de transacciones detalladas, lo que permite una mejor supervisión y diagnóstico de aplicaciones nativas de la nube.

Solución de problemas

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

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

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-3.6.2.jar https://github.com/microsoft/ApplicationInsights-Java/releases/download//applicationinsights-agent-3.6.2.jar
```
```
wget --output-document=applicationinsights-agent-3.6.2.jar https://github.com/microsoft/ApplicationInsights-Java/releases/download//applicationinsights-agent-3.6.2.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>

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

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

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.

Habilitar 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)
...

Prueba de la conectividad entre el host de la aplicación y el servicio de ingesta

Evitar 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.

Falta telemetría de las solicitudes de aplicaciones FastAPI o Flask

Si le faltan datos de las tablas de peticiones pero no de otras categorías, es probable que el marco http no esté siendo instrumentado. Esto puede ocurrir en aplicaciones FastAPI y Flask mediante la biblioteca cliente de Distribución de OpenTelemetry de Azure Monitor para Python si no estructura import correctamente las declaraciones. Es posible que importe fastapi.FastAPI o flask.Flask respectivamente, antes de llamar a la configure_azure_monitor función para instrumentar las bibliotecas FastAPI y Flask. Por ejemplo, el código siguiente no instrumenta correctamente las aplicaciones FastAPI y Flask:

# FastAPI

from azure.monitor.opentelemetry import configure_azure_monitor
from fastapi import FastAPI

configure_azure_monitor()

app = FastAPI()

# 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 fastapi o flask en su conjunto y, después, llamar a configure_azure_monitor para configurar OpenTelemetry para usar Azure Monitor antes de acceder a fastapi.FastAPI o flask.Flask:

# FastAPI

from azure.monitor.opentelemetry import configure_azure_monitor
import fastapi

configure_azure_monitor()

app = fastapi.FastAPI(__name__)

# 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 fastapi.FastAPI o flask.Flask:

# FastAPI

from azure.monitor.opentelemetry import configure_azure_monitor

configure_azure_monitor()

from fastapi import FastAPI

app = FastAPI(__name__)

# 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 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.

Comentarios de OpenTelemetry

Para proporcionar comentarios:

Rellene la encuesta de comentarios de los clientes de la comunidad de OpenTelemetry.
Únase a la comunidad de usuarios pioneros de OpenTelemetry y cuente su experiencia a Microsoft.
Interactúe con otros usuarios de Azure Monitor en Microsoft Tech Community.
Realice una solicitud de característica en el foro de comentarios de Azure.

Compartir por

Ayuda, soporte técnico y comentarios de OpenTelemetry

Preguntas más frecuentes

¿Qué es OpenTelemetry?

¿Por qué Microsoft Azure Monitor invierte en OpenTelemetry?

¿Cuál es el estado de OpenTelemetry?

¿Qué es la distribución de OpenTelemetry de Azure Monitor?

¿Por qué debería usar la distribución de OpenTelemetry de Azure Monitor?

¿Cómo puedo probar la Distribución de OpenTelemetry de Azure Monitor?

¿Debería usar OpenTelemetry o el SDK de Application Insights?

¿Cuándo debo usar el exportador OpenTelemetry de Azure Monitor?

¿Cuál es el estado actual de las características de la Distribución de OpenTelemetry de Azure Monitor?

¿Se puede usar OpenTelemetry para exploradores web?

¿Cuándo podemos esperar que el SDK de OpenTelemetry esté disponible para su uso en navegadores web?

¿Puedo probar hoy OpenTelemetry en un explorador web?

¿Ejecuta Application Insights junto con agentes de la competencia como AppDynamics, DataDog y NewRelic compatibles?

¿Se pueden usar las características en vista previa (GB) en entornos de producción?

¿Cuál es la diferencia entre la instrumentación manual y la automática?

¿Puedo usar OpenTelemetry-Collector?

¿Cuál es la diferencia entre OpenCensus y OpenTelemetry?

En Grafana, ¿por qué veo Status: 500. Can't visualize trace events using the trace visualizer?

Solución de problemas

Paso 1: Habilitar el registro de diagnóstico

Paso 2: Probar la conectividad entre el host de la aplicación y el servicio de ingesta

Problemas conocidos

Soporte técnico

Comentarios de OpenTelemetry

Comentarios

Recursos adicionais

En Grafana, ¿por qué veo `Status: 500. Can't visualize trace events using the trace visualizer`?