Ce guide fournit des instructions pas à pas pour migrer des applications à partir des kits SDK Application Insights (API classique) vers Azure Monitor OpenTelemetry.
Vous bénéficiez d’une expérience similaire avec l’instrumentation Azure Monitor OpenTelemetry, comme avec les kits sdk Application Insights. Pour plus d’informations et une comparaison de fonctionnalités par fonctionnalité, consultez l’état de publication des fonctionnalités.
Utilisez Application Insights .NET kit de développement logiciel (SDK) 3.x pour effectuer une mise à niveau à partir d’Application Insights .NET SDK 2.x vers une implémentation basée sur OpenTelemetry (OTel). Le SDK 3.x conserve la plupart des interfaces de programmation d’applications TelemetryClient et TelemetryConfiguration et utilise les Azure Monitor OpenTelemetry Exporter pour envoyer des données de télémétrie à Application Insights.
La plupart des appels classiques Track* continuent de fonctionner après la mise à niveau, mais ils sont routés via une couche de mappage interne qui émet des signaux OpenTelemetry.
Si vous créez une nouvelle application ou que vous utilisez déjà le Azure Monitor OpenTelemetry Distro, utilisez plutôt le Azure Monitor OpenTelemetry Distro. N'utilisez pas Application Insights .NET SDK 3.x et la Azure Monitor distribution OpenTelemetry dans la même application.
Vue d’ensemble d’Application Insights .NET SDK 3.x
Application Insights .NET SDK 3.x fournit ces packages NuGet :
-
Microsoft.ApplicationInsights pour TelemetryClient et TelemetryConfiguration
-
Microsoft.ApplicationInsights.AspNetCore pour les applications Web ASP.NET (Active Server Pages .NET) Core
-
Microsoft.ApplicationInsights.WorkerService pour les applications de service de travail et de console
-
Microsoft.ApplicationInsights.Web pour les applications ASP.NET sur .NET Framework
-
Microsoft.ApplicationInsights.NLogTarget pour l’intégration de NLog (bêta)
Pour obtenir des exemples de code et des instructions détaillées sur la migration, consultez la documentation du référentiel :
Mettre à niveau vers la version 3.x
Étape 1 : Supprimer les références aux packages incompatibles
Supprimez ces packages, car ils ne sont pas compatibles avec le Kit de développement logiciel (SDK) 3.x :
Microsoft.ApplicationInsights.WindowsServer.TelemetryChannelMicrosoft.ApplicationInsights.DependencyCollectorMicrosoft.ApplicationInsights.EventCounterCollectorMicrosoft.ApplicationInsights.PerfCounterCollectorMicrosoft.ApplicationInsights.WindowsServerMicrosoft.Extensions.Logging.ApplicationInsightsMicrosoft.ApplicationInsights.Log4NetAppenderMicrosoft.ApplicationInsights.TraceListenerMicrosoft.ApplicationInsights.DiagnosticSourceListenerMicrosoft.ApplicationInsights.EtwCollectorMicrosoft.ApplicationInsights.EventSourceListener
Sdk 3.x ne publie pas les versions 3.x de ces packages. Utilisez les packages 3.x pris en charge répertoriés dans Application Insights .NET SDK 3.x vue d’ensemble à la place. Les sections suivantes décrivent les remplacements prévus pour ces packages. Dans certains cas, la fonctionnalité est intégrée aux packages 3.x pris en charge ou remplacée par les API OpenTelemetry.
Note
Cette liste inclut uniquement les packages Microsoft. Si vous utilisez des packages tiers qui dépendent de Microsoft.ApplicationInsights la version 2.x (par exemple Serilog.Sinks.ApplicationInsights), vérifiez que ces packages prennent en charge SDK 3.x avant la mise à niveau. Suivez les conseils des mainteneurs de paquets.
Étape 2 : Mettre à niveau les versions du package vers 3.x
Mettez à niveau les packages Application Insights restants pris en charge vers la dernière version 3.x.
Important
Ne mélangez pas les packages Application Insights 2.x et 3.x dans la même application. Effectuez la mise à niveau de toutes les références de modules Application Insights ensemble.
Étape 3 : Mettre à jour le code et la configuration afin de prendre en compte les changements cassants
Consultez à la fois la référence des changements cassants et le guide détaillé de migration. La plupart des applications doivent mettre à jour le code ou la configuration dans un ou plusieurs des domaines suivants :
| API, paramètre ou modèle 2.x |
Conseils 3.x |
TrackPageView |
Supprimez les TrackPageView appels. Le suivi de la vue de page est supprimé dans le Kit de développement logiciel (SDK) .NET 3.x. |
TrackEvent, TrackException, et TrackAvailability surcharges qui incluent IDictionary<string, double> metrics |
Supprimez le paramètre de métriques personnalisées. Suivez les métriques séparément à l’aide de TrackMetric(). |
GetMetric surcharges qui utilisent MetricConfiguration ou MetricAggregationScope |
Utilisez les surcharges simplifiées GetMetric overloads. La configuration et l’agrégation des métriques sont gérées en interne dans le Kit de développement logiciel (SDK) 3.x. |
InstrumentationKey configuration ou TelemetryClient.InstrumentationKey |
Utilisez TelemetryConfiguration.ConnectionString et fournissez une chaîne de connexion au lieu d’une clé d’instrumentation. Le SDK 3.x nécessite une chaîne de connexion et peut échouer au démarrage si elle n’est pas configurée. Pour les scénarios de test, vous pouvez utiliser une chaîne de connexion factice telle que InstrumentationKey=00000000-0000-0000-0000-000000000000. |
TelemetryClient() ou TelemetryConfiguration.Active |
Créez une configuration explicitement en utilisant TelemetryConfiguration.CreateDefault(), puis passez-la à new TelemetryClient(config). |
TelemetryModule, TelemetryInitializer,ouTelemetryProcessorpersonnalisation |
Les initialiseurs ou processeurs personnalisés doivent être migrés vers des processeurs basés sur OpenTelemetry. Les références aux processeurs 2.x intégrés, aux initialiseurs et aux modules doivent être supprimées. Pour plus d’informations, consultez les instructions de migration. |
ITelemetryChannel ou TelemetryConfiguration.TelemetryChannel |
L’abstraction de canal classique est supprimée, car 3.x intègre en interne l’exportateur Azure Monitor. Pour les tests, utilisez une validation compatible avec OpenTelemetry, telle qu'un exportateur en mémoire. |
EnableAdaptiveSampling |
Remplacez l’échantillonnage adaptatif par TracesPerSecond ou SamplingRatio. |
Microsoft.ApplicationInsights.Web ciblant .NET Framework 4.5.2 |
Cible .NET Framework 4.6.2 ou version ultérieure. |
| Conventions de nommage des noms de métriques et des espaces de noms |
Pour suivre la syntaxe de nommage des instruments OpenTelemetry, mettez à jour les valeurs name, metricId, et metricNamespace utilisées avec TrackMetric(), GetMetric(), et MetricIdentifier. Les noms de métriques et les espaces de noms doivent commencer par une lettre et ne peuvent contenir que des lettres, des chiffres, _, .ou -/. Les espaces ne sont pas autorisés. |
Remplacer les points d’extensibilité supprimés
Application Insights .NET SDK 2.x a fourni des types d’extensibilité spécifiques à Application Insights, tels que les modules de télémétrie, les initialiseurs, les processeurs et les canaux. Application Insights .NET SDK 3.x utilise plutôt l’extensibilité OpenTelemetry.
Pour obtenir des instructions détaillées sur le remplacement de points d’extensibilité 2.x, y compris les cas de périphérie, consultez les instructions de migration.
Conseil / Astuce
Les valeurs basées sur des ressources telles que les métadonnées de rôle peuvent transiter par des mappages de ressources OpenTelemetry au lieu d’apparaître sur chaque élément de télémétrie. Si vous avez besoin d’une paire clé-valeur sur chaque élément de télémétrie, utilisez GlobalProperties ou un processeur personnalisé.
Application Insights .NET SDK 3.x prend en charge deux modes d’échantillonnage pour les traces (demandes et dépendances) :
- Définissez
SamplingRatio (0,0 à 1,0) pour l’échantillonnage basé sur des pourcentages.
- Défini
TracesPerSecond pour l’échantillonnage limité à la fréquence (valeur par défaut : cinq traces par seconde).
Sdk 3.x applique les mêmes paramètres d’échantillonnage aux demandes et aux dépendances. Sdk 3.x ne prend pas en charge les paramètres d’échantillonnage distincts pour les demandes et les dépendances.
Lorsqu’une requête ou une dépendance fait l’objet d’un échantillonnage, le SDK 3.x applique par défaut la décision d’échantillonnage de la trace parente aux journaux d’activité associés. Pour désactiver ce comportement, définissez EnableTraceBasedLogsSampler sur false.
Vous pouvez définir SamplingRatio, TracesPerSecondet EnableTraceBasedLogsSampler dans TelemetryConfiguration, appsettings.jsonou applicationinsights.config.
Dépannage d’une mise à niveau
Procédez comme suit pour valider les données de télémétrie lors d’une mise à niveau vers sdk 3.x :
- Vérifiez qu’une chaîne de connexion complète est configurée avant le démarrage. Si vous validez la télémétrie dans les tests sans ressource réelle, utilisez une chaîne de connexion factice.
- Collectez les journaux de diagnostic automatique Application Insights pour identifier les erreurs de configuration et les échecs d’exportation.
- Ajoutez l’exportateur de console OpenTelemetry afin de vérifier que les traces, les mesures et les journaux d’activité s’affichent conformément aux attentes avant de vous appuyer sur l’ingestion Azure Monitor.
- Si vous avez précédemment testé la télémétrie unitaire en simulant
ITelemetryChannel, basculez vers une validation compatible avec OpenTelemetry, comme les exportateurs de test en mémoire ou d’autres exportateurs de test dans des environnements non-production.
- Vérifiez que les paramètres d’échantillonnage se comportent comme prévu en validant les décisions de trace parent-enfant.
- Validez les attributs de ressource tels que le nom de service, le nom du rôle, l’instance de rôle et l’environnement pour garantir une attribution correcte dans Application Insights.
- Si vous avez migré un enrichissement personnalisé, vérifiez que vos propriétés apparaissent là où vous vous attendez. Les mappages basés sur des ressources peuvent différer du comportement 2.x.
Pour obtenir des conseils détaillés sur la résolution des problèmes et des exemples, utilisez les ressources suivantes :
Il n’y a généralement aucune modification du code lors de la mise à niveau vers la version 3.x. Les dépendances du kit de développement logiciel (SDK) 3.x sont versions d’API no-op des dépendances du SDK 2.x. Toutefois, lorsqu’il est utilisé avec l’agent 3.x Java, l’agent 3.x Java fournit l’implémentation pour eux. Par conséquent, votre instrumentation personnalisée est corrélée avec la nouvelle autoinstrumentation fournie par l’agent 3.x Java.
Étape 1 : Mettre à jour les dépendances
| Dépendance 2.x |
Action |
Remarques |
applicationinsights-core |
Mettre à jour la version vers 3.4.3 ou une version ultérieure |
|
applicationinsights-web |
Mettez à jour la version vers 3.4.3 ou une version ultérieure, puis supprimez le filtre web Application Insights de votre web.xml fichier. |
|
applicationinsights-web-auto |
Remplacer par 3.4.3 ou version ultérieure de applicationinsights-web |
|
applicationinsights-logging-log4j1_2 |
Supprimez la dépendance et supprimez l’appender Application Insights de votre configuration Log4j. |
L’appender Log4j 1.2 n’est pas nécessaire, car l’agent Java 3.x auto-instrumente Log4j 1.2. |
applicationinsights-logging-log4j2 |
Supprimez la dépendance et supprimez l’appender Application Insights de votre configuration Log4j. |
L’appender Log4j 2 n’est pas nécessaire, car l’agent Java 3.x auto-instrumente Log4j 2. |
applicationinsights-logging-logback |
Supprimez la dépendance et supprimez l’appender Application Insights de votre configuration Logback. |
L’appender Logback n’est pas nécessaire, car l’agent Java 3.x auto-instrumente Logback. |
applicationinsights-spring-boot-starter |
Remplacer par 3.4.3 ou version ultérieure de applicationinsights-web |
Le nom du rôle cloud n’est plus défini par défaut sur spring.application.name. Pour savoir comment configurer le nom du rôle cloud, consultez la page Configurer Azure Monitor OpenTelemetry. |
Étape 2 : Ajouter l’agent 3.x Java
Ajoutez l’agent de ligne de commande 3.x Java à vos arguments de ligne de commande JVM (Java Virtual Machine), par exemple :
-javaagent:path/to/applicationinsights-agent-3.7.8.jar
Si vous utilisez l'agent Application Insights 2.x Java, remplacez simplement votre -javaagent:... existant par l'exemple précédent.
Note
Si vous utilisez applicationinsights-spring-boot-starter, vous pouvez utiliser l’intégration spring Boot au lieu de l’agent Java. Pour obtenir des conseils, accédez à 3.x Spring Boot.
Consultez Configurer Azure Monitor OpenTelemetry.
Autres remarques
Le reste de ce document décrit les limitations et les modifications que vous pouvez rencontrer lors de la mise à niveau de 2.x vers 3.x, et certaines solutions de contournement utiles.
TelemetryInitializers
Les telemetryInitializers du Kit de développement logiciel (SDK) 2.x ne s’exécutent pas lorsque vous utilisez l’agent 3.x. De nombreux cas d’usage qui nécessitaient auparavant l’écriture d’une TelemetryInitializer peuvent être résolus dans Application Insights Java 3.x en configurant des dimensions customes ou à l’aide d’attributs inherited.
TelemetryProcessors
Les telemetryProcessors du Kit de développement logiciel (SDK) 2.x ne s’exécutent pas lorsque vous utilisez l’agent 3.x. La plupart des cas d’usage qui nécessitaient précédemment l’écriture d’un fichier TelemetryProcessor peuvent être résolus dans Application Insights Java 3.x en configurant les remplacements d’échantillonnage.
Plusieurs applications dans une seule machine virtuelle JVM
Vous pouvez prendre en charge ce cas d’usage dans Application Insights Java 3.x à l’aide des remplacements de nom de rôle cloud (préversion) et des remplacements de chaîne de connexion (préversion).
Noms des opérations
Dans le Kit de développement logiciel (SDK) Application Insights Java 2.x, les noms des opérations incluent parfois le chemin complet. Par exemple:
Les noms d’opérations dans Application Insights Java 3.x fournissent généralement une meilleure vue agrégée dans le portail Application Insights U/X. Par exemple:
Toutefois, pour certaines applications, vous préférerez peut-être encore la vue agrégée dans l’interface utilisateur qu’offraient les anciens noms d’opération. Dans ce cas, utilisez la fonctionnalité processeurs de télémétrie (préversion) dans la version 3.x pour répliquer le comportement précédent.
L’extrait de code suivant configure trois processeurs de télémétrie qui se combinent pour répliquer le comportement précédent.
Les processeurs de télémétrie effectuent les actions suivantes (dans l’ordre) :
Le premier processeur de télémétrie est un processeur d’attributs (a un typeattribute), ce qui signifie qu’il s’applique à toutes les données de télémétrie qui ont des attributs (actuellement requests etdependencies, bientôt aussi).traces
Elle correspond à toutes les données de télémétrie qui ont des attributs nommés http.request.method et url.path.
Ensuite, il extrait l’attribut url.path dans un nouvel attribut nommé tempName.
Le deuxième processeur de télémétrie est un processeur d’étendue (a le type span), ce qui signifie qu’il s’applique à requests et dependencies.
Il correspond à n’importe quelle étendue qui a un attribut nommé tempPath.
Ensuite, il met à jour le nom de l’étendue à partir de l’attribut tempPath.
Le dernier processeur de télémétrie est un processeur d’attributs, même type que le premier processeur de télémétrie.
Elle correspond à toutes les données de télémétrie qui ont un attribut nommé tempPath.
Ensuite, il supprime l’attribut nommé tempPath. L’attribut apparaît sous la forme d’une dimension personnalisée.
{
"preview": {
"processors": [
{
"type": "attribute",
"include": {
"matchType": "strict",
"attributes": [
{ "key": "http.request.method" },
{ "key": "url.path" }
]
},
"actions": [
{
"key": "url.path",
"pattern": "https?://[^/]+(?<tempPath>/[^?]*)",
"action": "extract"
}
]
},
{
"type": "span",
"include": {
"matchType": "strict",
"attributes": [
{ "key": "tempPath" }
]
},
"name": {
"fromAttributes": [ "http.request.method", "tempPath" ],
"separator": " "
}
},
{
"type": "attribute",
"include": {
"matchType": "strict",
"attributes": [
{ "key": "tempPath" }
]
},
"actions": [
{ "key": "tempPath", "action": "delete" }
]
}
]
}
}
Échantillonnage et journaux manquants
À compter de la version 3.4, l’agent active l’échantillonnage limité par défaut. Cet échantillonnage peut entraîner une absence inattendue de logs.
Exemple de projet
Ce projet sdk Java 2.x est migré vers a nouveau projet à l’aide de l’agent 3.x Java.
Ce guide fournit deux options pour effectuer une mise à niveau à partir du Kit de développement logiciel (SDK) Application Insights Node.js SDK 2.X vers OpenTelemetry.
Nettoyer l’installation
Acquérez les connaissances préalables sur l'interface de programmation d'applications (API) et le Kit de développement logiciel (SDK) JavaScript OpenTelemetry.
Désinstallez la dépendance applicationinsights de votre projet.
npm uninstall applicationinsights
Supprimez l’implémentation du Kit de développement logiciel (SDK) 2.X de votre code.
Supprimez toutes les instrumentations Application Insights de votre code. Supprimez les sections dans lesquelles le client Application Insights est initialisé, modifié ou appelé.
Activez Application Insights avec la distribution OpenTelemetry Azure Monitor.
Important
Avant d’importer autre chose, appelez useAzureMonitor. Si vous importez d’autres bibliothèques en premier, vous risquez de perdre des données de télémétrie.
Suivez le guide de démarrage pour l’intégration à la distribution OpenTelemetry Azure Monitor.
Modifications et limitations de la distribution OpenTelemetry d'Azure Monitor
- Les API du Kit de développement logiciel (SDK) Application Insights 2.X ne sont pas disponibles dans la Azure Monitor distribution OpenTelemetry. Bien que le Kit de développement logiciel (SDK) Application Insights 3.X fournit un chemin de mise à niveau sans arrêt pour l’ingestion de télémétrie (par exemple, les événements personnalisés et les métriques), la plupart des API sdk 2.X ne sont pas prises en charge et nécessitent des modifications de code apportées aux API OpenTelemetry.
- Le filtrage des dépendances, des journaux et des exceptions par nom d’opération n’est pas encore pris en charge.
Mise à niveau
Mettre à niveau la dépendance de package applicationinsights.
npm update applicationinsights
Régénérez votre application.
Testez votre application.
Pour éviter d’utiliser des options de configuration non prises en charge dans le Kit de développement logiciel (SDK) 3.X Application Insights, consultez Propriétés non prises en charge.
Si le Kit de développement logiciel (SDK) journalise les avertissements relatifs à une utilisation non prise en charge de l’API suite au lancement d’une version principale, et que vous avez besoin des fonctionnalités associées, continuez à utiliser le Kit de développement logiciel (SDK) 2.X Application Insights.
Modifications et limitations
Les modifications et limites suivantes s’appliquent aux deux chemins d’accès de mise à niveau.
prise en charge des versions de Node.js
Le SDK Application Insights 3.x prend en charge une version Node.js lorsque les Kit de développement logiciel (SDK) Azure pour JavaScript et OpenTelemetry prennent en charge cette version Node.js. Pour connaître la prise en charge actuelle du runtime OpenTelemetry, consultez les runtimes pris en charge par OpenTelemetry.
Si vous utilisez une version antérieure de Node.js telle que Node 8, les solutions OpenTelemetry peuvent s'exécuter, mais sont susceptibles de produire un comportement inattendu ou des changements majeurs. Le Kit de développement logiciel (SDK) Application Insights s'appuie sur les Kit de développement logiciel (SDK) Azure pour JavaScript et la stratégie de prise en charge Kit de développement logiciel (SDK) Azure pour JavaScript ne garantit pas la prise en charge des versions Node.js qui ont atteint la fin de vie. Pour plus d’informations, consultez Kit de développement logiciel (SDK) Azure pour la stratégie de support JS.
Options de configuration
Le Kit de développement logiciel (SDK) Application Insights version 2.X offre des options de configuration qui ne sont pas disponibles dans le Azure Monitor Distribution OpenTelemetry ou dans la mise à niveau de version majeure vers le SDK Application Insights 3.X. Pour trouver ces modifications, ainsi que les options que le SDK prend toujours en charge, consultez la documentation de configuration du KIT SDK.
Métriques étendues
Le Kit de développement logiciel (SDK) Application Insights 2.X prend en charge les métriques étendues. Toutefois, la prise en charge de ces métriques se termine à la fois dans la version 3.X du Kit de développement logiciel (SDK) ApplicationInsights et dans la distribution openTelemetry Azure Monitor.
Processeurs de télémétrie
Bien que le Distro Azure Monitor OpenTelemetry et le kit SDK 3.X Application Insights ne prennent pas en charge TelemetryProcessors, ils vous permettent de passer des processeurs de traces (span) et d'enregistrements de journal. Pour plus d’informations, consultez le projet de distribution OpenTelemetry Azure Monitor.
Cet exemple montre l’équivalent de la création et de l’application d’un processeur de télémétrie qui attache une propriété personnalisée dans le Kit de développement logiciel (SDK) 2.X Application Insights.
const applicationInsights = require("applicationinsights");
applicationInsights.setup("YOUR_CONNECTION_STRING");
applicationInsights.defaultClient.addTelemetryProcessor(addCustomProperty);
applicationInsights.start();
function addCustomProperty(envelope: EnvelopeTelemetry) {
const data = envelope.data.baseData;
if (data?.properties) {
data.properties.customProperty = "Custom Property Value";
}
return true;
}
Cet exemple montre comment modifier une implémentation Azure Monitor OpenTelemetry Distro pour transmettre un SpanProcessor à la configuration de la distribution.
import { Context, Span} from "@opentelemetry/api";
import { ReadableSpan, SpanProcessor } from "@opentelemetry/sdk-trace-base";
const { useAzureMonitor } = require("@azure/monitor-opentelemetry");
class SpanEnrichingProcessor implements SpanProcessor {
forceFlush(): Promise<void> {
return Promise.resolve();
}
onStart(span: Span, parentContext: Context): void {
return;
}
onEnd(span: ReadableSpan): void {
span.attributes["custom-attribute"] = "custom-value";
}
shutdown(): Promise<void> {
return Promise.resolve();
}
}
const options = {
azureMonitorExporterOptions: {
connectionString: "YOUR_CONNECTION_STRING"
},
spanProcessors: [new SpanEnrichingProcessor()],
};
useAzureMonitor(options);
Suivez ces étapes pour migrer des applications Python vers la distribution OpenTelemetry Azure Monitor.
Étape 1 : Désinstallez les bibliothèques OpenCensus
Désinstallez toutes les bibliothèques liées à OpenCensus, y compris tous les packages PyPI qui commencent par opencensus-*.
pip freeze | grep opencensus | xargs pip uninstall -y
Étape 2 : Supprimez OpenCensus de votre code
Supprimez toutes les instances du Kit de développement logiciel (SDK) OpenCensus et de l’exportateur Azure Monitor OpenCensus de votre code.
Vérifiez les instructions d’importation commençant par opencensus pour repérer toutes les intégrations, tous les exportateurs et toutes les instances de l’API/du SDK OpenCensus que vous devez supprimer.
Les exemples suivants montrent les instructions d’importation que vous devez supprimer.
from opencensus.ext.azure import metrics_exporter
from opencensus.stats import aggregation as aggregation_module
from opencensus.stats import measure as measure_module
from opencensus.ext.azure.trace_exporter import AzureExporter
from opencensus.trace.samplers import ProbabilitySampler
from opencensus.trace.tracer import Tracer
from opencensus.ext.azure.log_exporter import AzureLogHandler
Étape 3 : Familiarisez-vous avec les API et kits sdk OpenTelemetry Python
La documentation suivante fournit des connaissances préalables sur les API et kits sdk OpenTelemetry Python :
Note
OpenTelemetry Python et OpenCensus Python ont différentes surfaces d’API, fonctionnalités de collecte automatique et instructions d’intégration.
Étape 4 : Configurer la distribution Azure Monitor OpenTelemetry
Suivez l’article de prise en main pour l’intégration à la distribution OpenTelemetry Azure Monitor.
Modifications et limitations
Les modifications et limitations suivantes peuvent se produire lors de la migration d’OpenCensus vers OpenTelemetry.
versions Python antérieures à la version 3.10
La Azure Monitor distribution OpenTelemetry pour Python nécessite Python 3.10 ou version ultérieure. Pour connaître les prérequis et les versions prises en charge, consultez la bibliothèque de client de distribution Opentelemetry Azure Monitor pour Python.
Pour connaître l’état des versions de Python et leurs dates de fin de vie, accédez à Support des versions de Python.
Si vous restez sur Python 2.7, 3.4, 3.5 ou 3.6, les solutions OpenTelemetry peuvent s'exécuter, mais peuvent entraîner des changements inattendus ou des incompatibilités que Microsoft ne prend pas en charge.
Pour OpenCensus, la dernière version publiée de opencensus-ext-azure s’exécute sur ces versions Python. Le projet ne publie pas de nouvelles versions.
Configurations
OpenCensus Python fournit des options de configuration relatives à la collecte et à l’exportation de données de télémétrie. Vous pouvez obtenir les mêmes configurations, et bien plus encore, à l’aide de l’api openTelemetry Python et du SDK. OpenTelemetry Azure monitor Python Distro est un point d’arrêt pour les besoins de surveillance les plus courants pour vos applications Python. Étant donné que la distribution encapsule les API et sdk OpenTelemetry, certaines configurations pour des cas d’usage plus rares peuvent ne pas être prises en charge actuellement. À la place, vous pouvez choisir d’adopter l’exportateur OpenTelemetry Azure Monitor, qui, en utilisant les API et SDK OpenTelemetry, devrait être en mesure de couvrir vos besoins en matière de supervision. Certaines de ces configurations comprennent :
- Les propagateurs personnalisés
- Échantillonneurs personnalisés
- Ajout de traces supplémentaires, de processeurs de journaux et de lecteurs de métriques
Cohésion avec Azure Functions
Pour fournir des fonctionnalités de suivi distribuées pour Python applications qui appellent d’autres applications Python au sein d’une fonction Azure, le package opencensus-extension-azure-functions crée un graphique distribué connecté.
Actuellement, les solutions OpenTelemetry pour Azure Monitor ne prennent pas en charge ce scénario. Pour contourner ce problème, vous pouvez propager manuellement le contexte de trace dans votre application de fonctions Azure, comme illustré dans l’exemple suivant.
from opentelemetry.context import attach, detach
from opentelemetry.trace.propagation.tracecontext import \
TraceContextTextMapPropagator
# Context parameter is provided for the body of the function
def main(req, context):
functions_current_context = {
"traceparent": context.trace_context.Traceparent,
"tracestate": context.trace_context.Tracestate
}
parent_context = TraceContextTextMapPropagator().extract(
carrier=functions_current_context
)
token = attach(parent_context)
...
# Function logic
...
detach(token)
Extensions et exportateurs
Le Kit de développement logiciel (SDK) OpenCensus fournit des intégrations pour collecter les données de télémétrie et les exportateurs afin d’envoyer des données de télémétrie. Dans OpenTelemetry, les intégrations sont appelées instrumentations. OpenTelemetry utilise également le terme exportateurs.
Les instruments et exportateurs de OpenTelemetry Python couvrent un ensemble OpenCensus et ajoutent d’autres bibliothèques. OpenTelemetry fournit une mise à niveau directe dans la couverture et les fonctionnalités de la bibliothèque.
La distribution Azure Monitor OpenTelemetry comprend plusieurs instrumentations Python OpenTelemetry populaires. Utilisez ces instrumentations sans ajouter de code. Microsoft prend en charge ces instrumentations.
Comme pour les autres instrumentations OpenTelemetry Python qui ne sont pas incluses dans cette liste, vous pouvez toujours instrumenter manuellement avec eux. Toutefois, la stabilité et le comportement ne sont pas garantis ou pris en charge dans ces cas. Utilisez-les donc à votre discrétion.
Si vous souhaitez suggérer une bibliothèque d’instrumentation communautaire à inclure dans la distribution, publiez une idée ou votez pour une idée existante dans la communauté de retours. Concernant les exportateurs, la distribution Azure Monitor OpenTelemetry est fournie avec l’exportateur Azure Monitor OpenTelemetry. Si vous souhaitez également utiliser d’autres exportateurs, vous pouvez les utiliser avec la distribution, comme dans cet exemple.
Processeurs de télémétrie
Le monde OpenTelemetry n’a pas de processeurs de télémétrie, mais il a des API et des classes que vous pouvez utiliser pour répliquer le même comportement.
Définition du nom du rôle cloud et de l’instance de rôle cloud
Pour définir le nom du rôle cloud et l’instance de rôle cloud pour vos données de télémétrie, consultez la configuration d’OpenTelemetry. OpenTelemetry Azure Monitor Distro récupère automatiquement les valeurs des variables d’environnement et remplit les champs respectifs.
Modification des étendues avec SpanProcessors
À venir.
Modifier des métriques avec Aperçus
À venir.
L’exportateur openCensus Python Azure Monitor collecte automatiquement les métriques liées au système et aux performances appelées compteurs de performances. Ces métriques apparaissent dans performanceCounters au sein de votre instance Application Insights. Dans OpenTelemetry, vous n’envoyez plus ces métriques explicitement à performanceCounters. Les métriques liées aux demandes entrantes et sortantes sont disponibles sous les métriques standard. Si vous souhaitez que OpenTelemetry enregistre automatiquement les métriques liées au système, vous pouvez utiliser l’instrumentation des métriques système expérimentales, contribuée par la communauté OpenTelemetry Python. Ce package est expérimental et n'est pas officiellement pris en charge par Microsoft.
Support
Pour passer en revue les étapes de résolution des problèmes, les options de support ou pour fournir des commentaires sur OpenTelemetry, consultez Découvrir la résolution des problèmes, la prise en charge et les commentaires pour Azure Monitor Application Insights.
Le tableau suivant met en évidence les termes hérités utilisés dans Application Insights et leurs remplacements OpenTelemetry.