Partager via

Aide, support et commentaires pour OpenTelemetry

  • Article

Cet article fournit des options d’aide, de support et de commentaires pour OpenTelemetry sur Azure Monitor Application Insights pour .NET, Java, Node.js et les applications Python.

Forum aux questions

Qu’est-ce qu’OpenTelemetry ?

C’est une nouvelle norme open source pour l’observabilité. Pour en savoir plus, rendez-vous sur OpenTelemetry.

Pourquoi Microsoft Azure Monitor investit-il dans OpenTelemetry ?

Microsoft investit dans OpenTelemetry pour les raisons suivantes :

  • Cette solution est indépendante des fournisseurs et fournit des API/SDK homogènes dans toutes les langues.
  • Au fil du temps, nous pensons qu’OpenTelemetry permettra aux clients d’Azure Monitor d’observer des applications écrites dans des langages autres que nos langages pris en charge.
  • Elle permet de recueillir un plus grand nombre de données grâce à un ensemble complet de bibliothèques d’instrumentation.
  • Les kits de développement logiciel (SDK) OpenTelemetry sont généralement plus performants à grande échelle que leurs prédécesseurs, les SDK Application Insights.
  • OpenTelemetry est conforme à la stratégie de Microsoft qui consiste à promouvoir les logiciels open source.

Quel est l’état d’OpenTelemetry ?

Consultez l’état d’OpenTelemetry.

Qu’est-ce que la Distribution Azure Monitor OpenTelemetry ?

Vous pouvez le considérer comme un wrapper mince qui regroupe tous les composants OpenTelemetry pour une expérience de première classe sur Azure. Ce wrapper est également appelé une distribution dans OpenTelemetry.

Pourquoi utiliser la distribution Azure Monitor OpenTelemetry ?

Il existe plusieurs avantages à utiliser la distribution Azure Monitor OpenTelemetry par rapport à OpenTelemetry natif de la communauté :

Dans l’esprit d’OpenTelemetry, nous avons conçu la distribution pour qu’elle soit ouverte et extensible. Par exemple, vous pouvez ajouter :

  • Un exportateur OTLP (OpenTelemetry Protocol) et l’envoi vers une seconde destination simultanément
  • Autres bibliothèques d’instrumentation non incluses dans la distribution

Étant donné que la distribution fournit une distribution OpenTelemetry, la distribution prend en charge tout ce qui est pris en charge par OpenTelemetry. Par exemple, vous pouvez ajouter d’autres processeurs de télémétrie, exportateurs ou bibliothèques d’instrumentation si OpenTelemetry les prend en charge.

Remarque

La distribution définit l’échantillonneur sur un échantillonneur personnalisé à taux fixe pour Application Insights. Vous pouvez le modifier pour un autre échantillonneur, mais cela peut désactiver certaines des fonctionnalités incluses de la distribution. Pour plus d’informations sur l’échantillonneur pris en charge, consultez la section Activer l’échantillonnage de Configurer Azure Monitor OpenTelemetry.

Pour les langues sans exportateur OpenTelemetry autonome pris en charge, la distribution OpenTelemetry d’Azure Monitor est la seule façon actuellement prise en charge d’utiliser OpenTelemetry avec Azure Monitor. Pour les langues avec un exportateur OpenTelemetry autonome pris en charge, vous avez la possibilité d’utiliser la distribution OpenTelemetry Azure Monitor ou l’exportateur OpenTelemetry autonome approprié en fonction de votre scénario de télémétrie. Pour plus d’informations, consultez Quand dois-je utiliser l’exportateur Azure Monitor OpenTelemetry ?.

Comment tester la distribution Azure Monitor OpenTelemetry ?

Consultez notre documentation sur l’activation pour .NET, Java, JavaScript (Node.js) et Python.

Dois-je utiliser le kit de développement logiciel (SDK) OpenTelemetry ou Application Insights ?

Nous vous recommandons d’utiliser la distribution OpenTelemetry, sauf si vous avez besoin d’une fonctionnalité disponible uniquement avec une prise en charge officielle dans le kit SDK Application Insights.

L’adoption d’OpenTelemetry empêche désormais la migration à une date ultérieure.

Quand utiliser l’exportateur OpenTelemetry Azure Monitor ?

Pour ASP.NET Core, Java, Node.js et Python, nous vous recommandons d’utiliser la distribution OpenTelemetry Azure Monitor. Il s’agit d’une ligne de code pour démarrer.

Pour tous les autres scénarios .NET, notamment les ASP.NET classiques, les applications console, Windows Forms (WinForms), etc., nous vous recommandons d’utiliser l’exportateur .NET Azure Monitor OpenTelemetry : Azure.Monitor.OpenTelemetry.Exporter.

Pour les scénarios de télémétrie Python plus complexes nécessitant une configuration avancée, nous vous recommandons utiliser l’Exportateur Azure Monitor OpenTelemetry.

Quel est l’état de publication actuel des fonctionnalités de la distribution Azure Monitor OpenTelemetry ?

Le graphique suivant présente la prise en charge des fonctionnalités OpenTelemetry pour chaque langage.

Fonctionnalité .NET Node.js Python Java
Traçage distribué ✅ ✅ ✅ ✅
Métriques personnalisées ✅ ✅ ✅ ✅
Métriques standard ✅ ✅ ✅ ✅
Échantillonnage à fréquence fixe ✅ ✅ ✅ ✅
Stockage hors connexion et nouvelles tentatives automatiques ✅ ✅ ✅ ✅
Rapports d’exceptions ✅ ✅ ✅ ✅
Collection de journaux ✅ ⚠️ ✅ ✅
Événements personnalisés ⚠️ ⚠️ ⚠️ ✅
Authentification Microsoft Entra ✅ ✅ ✅ ✅
Métriques temps réel ✅ ✅ ✅ ✅
Filtrage des métriques actives ✅ ❌ ❌ ❌
Détecter le contexte de ressource pour les VM/VMSS et App Service ✅ ❌ ✅ ✅
Détecter le contexte des ressources pour Azure Kubernetes Service (AKS) et Functions ❌ ❌ ❌ ✅
Évènements de test de disponibilité générés en utilisant l’API Suivi de la disponibilité ❌ ❌ ❌ ✅
Filtrer les demandes, dépendances, journaux et exceptions par identificateur d’utilisateur anonyme et source synthétique ❌ ❌ ❌ ✅
Filtrer les dépendances, les journaux et les exceptions par nom d’opération ❌ ❌ ❌ ✅
échantillonnage adaptatif ❌ ❌ ❌ ✅
.NET Profiler ❌ ❌ ❌ ⚠️
Débogueur de capture instantanée ❌ ❌ ❌ ❌

Clé

OpenTelemetry peut-il être utilisé pour les navigateurs web ?

Oui, mais cela n’est pas recommandé ou pris en charge par Azure. OpenTelemetry JavaScript est fortement optimisé pour Node.js. Au lieu de cela, nous vous recommandons d’utiliser le Kit de développement logiciel (SDK) JavaScript Application Insights.

Quand pouvons-nous nous attendre à ce que le Kit de développement logiciel (SDK) OpenTelemetry soit disponible pour être utilisé dans les navigateurs web ?

Le SDK web OpenTelemetry n’a pas de planning de disponibilité défini. Il faudra probablement attendre encore plusieurs années avant qu’un SDK pour navigateur ne constitue une alternative viable au SDK JavaScript d’Application Insights.

Puis-je tester OpenTelemetry dans un navigateur web aujourd’hui ?

Le bac à sable web OpenTelemetry est une duplication (fork) conçue pour permettre à OpenTelemetry de fonctionner dans un navigateur. Il n’est pas encore possible d’envoyer des données de télémétrie à Application Insights. Le SDK ne définit pas d’événements clients d’ordre général.

L’exécution d’Application Insights avec les agents concurrents tels que AppDynamics, DataDog et NewRelic est-elle prise en charge ?

Bien que nos distributions vous permettent d’exporter simultanément vers un point de terminaison OTLP et Azure Monitor, nous ne prévoyons pas de tester ou de prendre en charge cette pratique.

Puis-je utiliser les fonctionnalités d’évaluation dans les environnements de production ?

Nous ne le recommandons pas. Consultez Conditions d’utilisation supplémentaires des Préversions Microsoft Azure.

Quelle est la différence entre une instrumentation manuelle et automatique ?

Consultez la rubrique Présentation d’OpenTelemetry.

Est-il possible d’utiliser le collecteur OpenTelemetry ?

Certains clients utilisent le collecteur OpenTelemetry comme agent de substitution, même si Microsoft ne prend pas encore officiellement en charge une approche basée sur un agent pour la surveillance d’applications. En attendant, la communauté open source a contribué à créer un exportateur Azure Monitor de collecteur OpenTelemetry que certains clients utilisent pour envoyer des données à Azure Monitor Application Insights. Ce n’est pas pris en charge par Microsoft.

Quelle est la différence entre OpenCensus et OpenTelemetry ?

OpenCensus est le précurseur d’OpenTelemetry. Microsoft a contribué à réunir OpenTracing et OpenCensus pour créer OpenTelemetry, une norme d’observabilité unique et disponible à l’échelle mondiale. Le Kit de développement logiciel (SDK) Python actuellement recommandé en production pour Azure Monitor est basé sur OpenCensus. Microsoft s’engage à baser Azure Monitor sur OpenTelemetry.

Dans Grafana, pourquoi est-ce que je vois Status: 500. Can't visualize trace events using the trace visualizer ?

Vous essayez peut-être de visualiser des journaux en texte brut plutôt que des traces OpenTelemetry.

Dans Application Insights, la table « Traces » stocke les journaux en texte brut à des fins de diagnostic. Ils permettent d’identifier et de mettre en corrélation les traces associées aux demandes utilisateur, à d’autres événements et aux rapports d’exceptions. Cependant, la table « Traces » ne contribue pas directement à la vue des transactions de bout en bout (graphique en cascade) dans des outils de visualisation comme Grafana.

Avec l’adoption croissante des pratiques natives cloud, la collecte et la terminologie des données de télémétrie évoluent. OpenTelemetry est désormais la norme pour collecter et instrumenter des données de télémétrie. Dans ce contexte, le terme « Traces » prend un nouveau sens. Au lieu de désigner des journaux bruts, « Traces » dans OpenTelemetry fait référence à une forme de télémétrie plus riche et structurée qui inclut des étendues représentant des unités de travail individuelles. Ces étendues sont essentielles pour construire des vues de transaction détaillées, améliorant ainsi le monitoring et les diagnostics des applications natives cloud.

Dépannage

Étape 1 : activer la journalisation des diagnostics

L’exportateur Azure Monitor utilise EventSource pour sa journalisation interne. Les journaux d’activité de l’exportateur sont disponibles pour n’importe quel EventListener en choisissant de suivre la source nommée OpenTelemetry-AzureMonitor-Exporter. Pour obtenir les étapes de dépannage, consultez Résolution des problèmes d’OpenTelemetry sur GitHub.

Étape 2 : tester la connectivité entre l’hôte de votre application et le service d’ingestion

Les Kits de développement logiciel (SDK) Application Insights et les agents envoient les données de télémétrie pour une ingestion en tant qu’appels REST à nos points de terminaison d’ingestion. Pour tester la connectivité entre votre serveur web ou l’ordinateur hôte de votre application et les points de terminaison du service d’ingestion, utilisez des commandes cURL ou des requêtes REST brutes depuis PowerShell. Pour plus d’informations, consultez Résoudre les problèmes de données de télémétrie d’application manquantes dans Azure Monitor Application Insights.

Problèmes connus

Les éléments suivants sont des problèmes connus pour les exportateurs OpenTelemetry Azure Monitor :

  • Le nom de l’opération est manquant dans la télémétrie des dépendances. Le nom d’opération manquant provoque des échecs et affecte négativement l’expérience de l’onglet des performances.

  • Le modèle d’appareil est manquant dans les données de télémétrie de requête et de dépendance. Le modèle d’appareil manquant affecte négativement l’analyse des cohortes d’appareils.

Support

Sélectionnez un onglet correspondant à la langue de votre choix pour découvrir les options de support.

Commentaires sur OpenTelemetry

Pour fournir des commentaires :