Compartir por


Soporte técnico y comentarios de OpenTelemetry para Application Insights

En este documento se describen los recursos disponibles para obtener ayuda, canales de soporte técnico y mecanismos de comentarios relacionados con la integración de OpenTelemetry (OTel) con Application Insights de Azure Monitor para aplicaciones .NET, Java, Node.jsy Python.

Nota:

Para Azure Function Apps, consulte Uso de OpenTelemetry con Azure Functions.

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:

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 un muestreador diferente, pero al hacerlo, podría deshabilitar algunas de las capacidades incluidas en la Distro. Para más información sobre el muestreador admitido, consulte la sección Habilitar muestreo de Configurar 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 openTelemetry de Azure Monitor para los nuevos proyectos cuando sus funcionalidades se alinean con sus necesidades de supervisión. OpenTelemetry es un marco estándar del sector que mejora la observabilidad multiplataforma y proporciona un enfoque estandarizado para la recopilación de telemetría.

Sin embargo, los SDK de Application Insights siguen proporcionando ciertas funcionalidades que aún no están totalmente automatizadas en OpenTelemetry, entre las que se incluyen:

  • Seguimiento automático de dependencias: OpenTelemetry admite el seguimiento de dependencias, pero algunas dependencias requieren una configuración adicional en comparación con el seguimiento automático disponible en los SDK de Application Insights.
  • Los tipos de telemetría personalizados, como AvailabilityTelemetry y PageViewTelemetry : OpenTelemetry no tiene equivalentes directos. Se puede implementar una funcionalidad similar a través de la instrumentación manual.
  • Procesadores de telemetría e inicializadores: OpenTelemetry tiene procesadores y procesadores de intervalos, pero no reemplazan completamente los procesadores e inicializadores de telemetría de Application Insights en todos los escenarios.
  • Recopilación de métricas extendidas: aunque OpenTelemetry tiene un sistema de métricas seguros, algunas métricas integradas de los SDK de Application Insights requieren una configuración manual en OpenTelemetry.

OpenTelemetry también proporciona ventajas sobre los SDK de Application Insights, entre los que se incluyen:

  • Mejor estandarización entre plataformas
  • Un ecosistema más amplio de bibliotecas de instrumentación
  • Mayor flexibilidad en la recopilación y el procesamiento de datos
  • Se ha mejorado la neutralidad del proveedor, aunque la distribución de OpenTelemetry de Azure Monitor todavía está optimizada para Azure.

La integración de OpenTelemetry de Azure Monitor evoluciona continuamente y Microsoft sigue mejorando sus funcionalidades. Si está considerando una transición, evalúe cuidadosamente si OpenTelemetry cumple actualmente los requisitos de observabilidad o si el SDK de Application Insights sigue siendo el mejor adecuado para sus necesidades.

¿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. Pitón 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
Métricas dinámicas
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 Azure 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 de .NET ⚠️ ⚠️
Depurador de instantáneas

Clave

¿Se puede usar OpenTelemetry para exploradores web?

Sí, pero no se recomienda y Azure no lo admite. OpenTelemetry JavaScript está altamente 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.

¿Es compatible ejecutar Application Insights junto con agentes de la competencia como AppDynamics, DataDog y NewRelic?

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 de manera simultánea.

¿Puedo usar funcionalidades de previsualización 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 'Traces' 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 "Rastros" adquirió 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.

¿Cómo debo instrumentar Blazor Apps?

Para instrumentar una aplicación Blazor, primero identifique el modelo de hospedaje. Blazor Server admite instrumentación completa basada en OpenTelemetry. Blazor WebAssembly se ejecuta en el explorador y admite instrumentación limitada a través de JavaScript.

Solución de problemas

Soporte técnico

Seleccione una pestaña para el idioma que prefiera para detectar las opciones de soporte técnico.

Comentarios de OpenTelemetry

Para proporcionar comentarios: