Résoudre les problèmes d’OpenTelemetry dans Python

Cet article explique comment résoudre les problèmes d’OpenTelemetry dans Python.

Liste de pour la résolution des problèmes

Étape 1 : Activer la journalisation des diagnostics

L’exportateur Microsoft Azure Monitor utilise la bibliothèque de journalisation standard Python pour sa journalisation interne. Les journaux de l’API OpenTelemetry et de l’exportateur Azure Monitor se voient attribuer un niveau de gravité de WARNING ou ERROR pour une activité irrégulière. Le INFO niveau de gravité est utilisé pour une activité régulière ou réussie.

Par défaut, la bibliothèque de journalisation Python définit le niveau de gravité sur WARNING. Par conséquent, vous devez modifier le niveau de gravité pour afficher les journaux sous ce paramètre de gravité. L’exemple de code suivant montre comment générer des journaux de tous les niveaux de gravité vers la console et un fichier :

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

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

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

Étape 3 : Éviter les données de télémétrie en double

Les données de télémétrie en double sont souvent provoquées si vous créez plusieurs instances de processeurs ou d’exportateurs. Veillez à n’exécuter qu’un seul exportateur et processeur à la fois pour chaque pilier de télémétrie (journaux, métriques et suivi distribué).

Les sections suivantes décrivent les scénarios qui peuvent entraîner des données de télémétrie en double.

Journaux de trace en double dans Azure Functions

Si vous voyez une paire d’entrées pour chaque journal de suivi dans Application Insights, vous avez probablement activé les types d’instrumentation de journalisation suivants :

• Instrumentation de journalisation native dans Azure Functions
• Instrumentation azure-monitor-opentelemetry de journalisation au sein de la distribution

Pour éviter la duplication, vous pouvez désactiver la journalisation de la distribution, mais laisser l’instrumentation de journalisation native dans Azure Functions activée. Pour ce faire, définissez la OTEL_LOGS_EXPORTER variable d’environnement sur None.

Données de télémétrie dupliquées dans Azure Functions « Always On »

Si le paramètre Always On dans Azure Functions est défini sur Activé, Azure Functions maintient certains processus en cours d’exécution en arrière-plan une fois chaque exécution terminée. Par exemple, supposons que vous ayez une fonction de minuteur de cinq minutes qui appelle configure_azure_monitor à chaque fois. Après 20 minutes, vous pouvez alors avoir quatre exportateurs de métriques qui s’exécutent en même temps. Cette situation peut être la source de vos données de télémétrie en double.

Dans ce cas, définissez le paramètre Always On sur Désactivé ou essayez d’arrêter manuellement les fournisseurs entre chaque configure_azure_monitor appel. Pour arrêter chaque fournisseur, exécutez des appels d’arrêt pour chaque compteur actuel, suivi et fournisseur d’enregistreurs d’événements, comme indiqué dans le code suivant :

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

Classeurs Azure et notebooks Jupyter

Les classeurs Azure et les notebooks Jupyter peuvent maintenir l’exécution des processus d’exportateur en arrière-plan. Pour éviter les données de télémétrie en double, effacez le cache avant d’effectuer d’autres appels à configure_azure_monitor.

Étape 4 : Vérifier que les données de requête Flask sont collectées

Si vous implémentez une application Flask, vous constaterez peut-être que vous ne pouvez pas collecter les données de la table Requests à partir d’Application Insights lorsque vous utilisez la bibliothèque de client de distribution OpenTelemetry Azure Monitor pour Python. Ce problème peut se produire si vous ne structurez pas correctement vos import déclarations. Vous importez peut-être l’infrastructure flask.Flask d’application web avant d’appeler la configure_azure_monitor fonction pour instrumenter la bibliothèque Flask. Par exemple, le code suivant n’instrumente pas correctement l’application Flask :

from azure.monitor.opentelemetry import configure_azure_monitor
from flask import Flask

configure_azure_monitor()

app = Flask(__name__)

Au lieu de cela, nous vous recommandons d’importer le flask module dans son ensemble, puis d’appeler configure_azure_monitor pour configurer OpenTelemetry afin d’utiliser Azure Monitor avant d’accéder à flask.Flask:

from azure.monitor.opentelemetry import configure_azure_monitor
import flask

configure_azure_monitor()

app = flask.Flask(__name__)

Vous pouvez également appeler configure_azure_monitor avant d’importer flask.Flask:

from azure.monitor.opentelemetry import configure_azure_monitor

configure_azure_monitor()

from flask import Flask

app = Flask(__name__)

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.