Ce guide fournit des instructions pas à pas pour migrer des applications à partir des kits SDK Application Insights (API classique) vers Azure Monitor OpenTelemetry.
Attendez-vous à une expérience similaire avec l’instrumentation OpenTelemetry d’Azure Monitor 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 le Kit de développement logiciel (SDK) Application Insights .NET 3.x pour effectuer une mise à niveau du Kit de développement logiciel (SDK) .NET Application Insights 2.x vers une implémentation basée sur OpenTelemetry (OTel). Le Kit de développement logiciel (SDK) 3.x conserve la plupart des TelemetryClient et TelemetryConfiguration interfaces de programmation d'applications (API) et utilise l'exportateur OpenTelemetry d'Azure Monitor pour envoyer des données de télémétrie à Application Insights.
Si vous générez une nouvelle application ou que vous utilisez déjà la distribution OpenTelemetry Azure Monitor, utilisez plutôt la distribution OpenTelemetry Azure Monitor . N’utilisez pas le Kit de développement logiciel (SDK) .NET Application Insights 3.x et la distribution OpenTelemetry Azure Monitor dans la même application.
Vue d’ensemble du Kit de développement logiciel (SDK) .NET Application Insights 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)
Utilisez la documentation du référentiel pour obtenir des exemples de code et des détails d’intégration OpenTelemetry :
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 plutôt les packages 3.x pris en charge dans la vue d’ensemble du Kit de développement logiciel (SDK) .NET Application Insights 3.x .
É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 référence des modifications perturbantes et supprimez ou remplacez les API et paramètres qui ne sont plus supportés.
Les modifications les plus courantes sont les suivantes :
- Supprimez les
TrackPageView appels.
- Mettez à jour les appels de
Track* pour supprimer le paramètre de métriques personnalisées.
- Remplacez la configuration de la clé d’instrumentation par une chaîne de connexion complète à l’aide de
TelemetryConfiguration.ConnectionString.
- Remplacez les personnalisations
TelemetryModule, TelemetryInitializer et TelemetryProcessor par les processeurs OpenTelemetry, les bibliothèques d'instrumentation et les détecteurs de ressources. La ApplicationInsightsServiceOptions classe inclut EnableQuickPulseMetricStream, , EnablePerformanceCounterCollectionModuleEnableDependencyTrackingTelemetryModuleet EnableRequestTrackingTelemetryModule. Ces ApplicationInsightsServiceOptions paramètres configurent le comportement de l’exportateur et n’utilisent TelemetryModule pas d’implémentations.
- Remplacez l’échantillonnage adaptatif (
EnableAdaptiveSampling) par TracesPerSecond ou SamplingRatio.
- Ciblez .NET Framework 4.6.2 ou version ultérieure pour les applications ASP.NET qui utilisent
Microsoft.ApplicationInsights.Web.
Remplacer les points d’extensibilité supprimés
Application Insights .NET SDK 2.x fournit des types d’extensibilité spécifiques à Application Insights, tels que les modules de télémétrie, les initialiseurs et les processeurs. Application Insights .NET SDK 3.x utilise plutôt l’extensibilité OpenTelemetry.
- Utilisez les options d’instrumentation et de configuration OpenTelemetry pour contrôler la collecte automatique.
- Utilisez des processeurs OpenTelemetry pour enrichir ou filtrer les données de télémétrie.
Sdk 3.x conserve uniquement un sous-ensemble de TelemetryContext propriétés. Vous pouvez définir ces propriétés sur des éléments de télémétrie individuels :
| Contexte |
Propriétés |
User |
Id, AuthenticatedUserIdUserAgent |
Operation |
Name |
Location |
Ip |
GlobalProperties |
(dictionnaire) |
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 :
- 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.
- 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 du service, le nom du rôle et l’environnement pour garantir une attribution correcte dans Application Insights.
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 Java 3.x, l’agent Java 3.x fournit l’implémentation pour celles-ci. Par conséquent, votre instrumentation personnalisée est corrélée avec la nouvelle autoinstrumentation fournie par l’agent Java 3.x.
É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. |
Non nécessaire, car Log4j 1.2 est autoinstrumenté dans l’agent Java 3.x. |
applicationinsights-logging-log4j2 |
Supprimez la dépendance et supprimez l’appender Application Insights de votre configuration Log4j. |
Il n’est plus nécessaire, car Log4j 2 est autoinstrumenté dans l’agent Java 3.x. |
applicationinsights-logging-logback |
Supprimez la dépendance et supprimez l’appender Application Insights de votre configuration Logback. |
Il n’est plus nécessaire, car Logback est autoinstrumenté dans l’agent Java 3.x. |
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 documentation de configuration 3.x. |
Étape 2 : Ajouter l’agent Java 3.x
Ajoutez l’agent Java 3.x à vos arguments de ligne de commande JVM (Java Virtual Machine), par exemple :
-javaagent:path/to/applicationinsights-agent-3.7.5.jar
Si vous utilisez l’agent Java Application Insights 2.x, remplacez simplement votre existant -javaagent:... 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 la configuration de la chaîne de connexion.
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 SDK 2.x ne s’exécutent pas lors de l’utilisation de l’agent 3.x. La plupart des cas d’usage qui nécessitaient auparavant l’écriture d’un fichier TelemetryInitializer peuvent être résolus dans Application Insights Java 3.x en configurant des dimensions personnalisées ou en utilisant des attributs hérités.
TelemetryProcessors
2.x SDK TelemetryProcessors ne s’exécute pas lors de l’utilisation de 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
Ce cas d’usage est pris en charge dans Application Insights Java 3.x à l’aide de remplacements de nom de rôle cloud (préversion) et/ou remplacements de chaîne de connexion (préversion).
Noms des opérations
Dans le Kit de développement logiciel (SDK) Java 2.x d’Application Insights, dans certains cas, les noms des opérations contenaient le chemin complet, par exemple :
Les noms des opérations dans Application Insights Java 3.x ont été modifiés pour fournir 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 toujours l’affichage agrégé dans l’U/X fourni par les noms d’opérations précédents. Dans ce cas, vous pouvez utiliser 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, et l’attribut s’affiche 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
L’échantillonnage à fréquence limitée est activé par défaut à partir de l’agent 3.4, ce qui peut entraîner des manquements inattendus de journaux.
Exemple de projet
Ce projet sdk Java 2.x est migré vers un nouveau projet à l’aide de l’agent Java 3.x.
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 Azure Monitor OpenTelemetry.
Important
Avant d’importer n’importe quoi d’autre, useAzureMonitor doit être appelé. Il peut y avoir une perte de télémétrie si d’autres bibliothèques sont importées en premier.
Suivez Bien démarrer pour intégrer la distribution Azure Monitor OpenTelemetry.
Modifications et limites de distribution d’Azure Monitor OpenTelemetry
- Les API du Kit de développement logiciel (SDK) 2.X Application Insights ne sont pas disponibles dans la distribution Azure Monitor 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 Kit de développement logiciel (SDK) Application Insights 3.x prend en charge une version Node.js lorsque le Kit de développement logiciel (SDK) Azure pour JavaScript et OpenTelemetry prend en charge cette version Node.js. Pour la prise en charge actuelle du runtime OpenTelemetry, accédez aux 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 le Kit de développement logiciel (SDK) Azure pour JavaScript et la stratégie de prise en charge du 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, accédez à la stratégie de prise en charge du Kit de développement logiciel (SDK) Azure pour JS.
Options de configuration
Le Kit de développement logiciel (SDK) version 2.X Application Insights offre des options de configuration qui ne sont pas disponibles dans la distribution Azure Monitor OpenTelemetry ou dans la mise à niveau de version majeure vers le Kit de développement logiciel (SDK) 3.X Application Insights. Pour accéder à ces modifications, ainsi qu’aux options que nous prenons toujours en charge, consultez la documentation de configuration du Kit de développement logiciel (SDK).
Métriques étendues
Les métriques étendues sont prises en charge dans le Kit de développement logiciel (SDK) 2.X Application Insights. Toutefois, elles ne sont plus disponibles dans la version 3.X du Kit de développement logiciel (SDK) Application Insights et dans la distribution Azure Monitor OpenTelemetry.
Processeurs de télémétrie
Bien que la distribution Azure Monitor OpenTelemetry et le Kit de développement logiciel (SDK) 3.X Application Insights ne prennent pas en charge TelemetryProcessors, ils vous permettent de passer des processeurs d’enregistrements span et log. Pour plus d’informations sur la méthode, consultez Projet de distribution Azure Monitor OpenTelemetry.
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 de distribution Azure Monitor OpenTelemetry pour envoyer 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 associé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 de votre code toutes les instances du SDK OpenCensus et de l’exportateur Azure Monitor OpenCensus.
Recherchez les instructions d’importation commençant par opencensus pour trouver l’ensemble des intégrations, exportateurs et instances de l’API/SDK OpenCensus à supprimer.
Voici des exemples d’instructions d’importation qui doivent être supprimées.
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/le SDK OpenTelemetry Python
La documentation suivante fournit des connaissances préalables pour les API/le SDK OpenTelemetry Python.
Note
OpenTelemetry Python et OpenCensus Python ont des surfaces d’API, des fonctionnalités de collecte automatique et des instructions d’intégration différentes.
Étape 4 : Configurez la distribution Azure Monitor OpenTelemetry
Suivez la page démarrage pour s'initier à la distribution OpenTelemetry d'Azure Monitor.
Modifications et limitations
Les modifications et limitations suivantes peuvent être rencontrées lors de la migration d’OpenCensus vers OpenTelemetry.
Versions de Python antérieures à la version 3.7
La supervision basée sur OpenTelemetry pour Python prend en charge Python 3.7 et versions ultérieures. OpenTelemetry ne prend pas en charge Python 2.7, 3.4, 3.5 ou 3.6.
Python 2.7, 3.4, 3.5 et 3.6 sont en fin de vie. Pour obtenir l’état de la version, accédez à la prise en charge 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 elles peuvent entraîner un comportement inattendu ou des modifications incompatibles que Microsoft ne prend pas en charge.
Pour OpenCensus, la dernière version publiée d’opencensus-ext-azure s’exécute sur ces versions de Python. Le projet ne publie pas de nouvelles versions.
Configurations
OpenCensus Python avait fourni des options de configuration liées à la collecte et à l’exportation de données de télémétrie. Vous obtenez les mêmes configurations et bien plus encore en utilisant les API et le SDK OpenTelemetry Python. La distribution Python Azure Monitor OpenTelemetry ressemble plus à un guichet unique pour les besoins de supervision les plus courants de vos applications Python. Étant donné que la distribution encapsule les API/SDk OpenTelemetry, certaines configurations pour des cas d’usage plus rares peuvent ne pas être actuellement prises en charge pour la distribution. Vous pouvez plutôt choisir d’intégrer l’exportateur Azure Monitor OpenTelemetry, qui, avec les API/le SDK OpenTelemetry, devrait être en mesure de répondre à vos besoins de supervision. Certaines de ces configurations comprennent :
- Les propagateurs personnalisés
- Échantillonneurs personnalisés
- Ajout de lecteurs supplémentaires d’étendue/de processeurs de journaux/de métriques
Cohésion avec Azure Functions
Afin de fournir des fonctionnalités de suivi distribué pour les applications Python qui appellent d’autres applications Python au sein d’une fonction Azure, le package opencensus-extension-azure-functions est fourni pour permettre un graphique distribué connecté.
Les solutions OpenTelemetry pour Azure Monitor ne prennent pas actuellement 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 instrumentations et exportateurs Python OpenTelemetry couvrent l’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 OpenTelemetry Azure Monitor comprend de plusieurs instrumentations Python OpenTelemetry populaires. Utilisez ces instrumentations sans ajouter de code. Microsoft prend en charge ces instrumentations.
Comme pour les autres instrumentations Python OpenTelemetry qui ne sont pas incluses dans cette liste, les utilisateurs peuvent toujours instrumenter manuellement avec eux. Toutefois, il est important de noter que 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 l’inclusion d’une bibliothèque d’instrumentation de la communauté dans notre distribution, publiez ou votez pour une idée dans notre communauté de commentaires. Pour 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.
TelemetryProcessors
Il n’existe aucun concept de processeurs de télémétrie dans le monde OpenTelemetry, mais il y a des API et des classes que vous pouvez utiliser pour répliquer ce même comportement.
Définir le nom du rôle cloud et l’instance de rôle cloud
Suivez les instructions fournies ici pour définir le nom du rôle cloud et l’instance de rôle cloud pour votre télémétrie. La distribution Azure Monitor OpenTelemetry 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 avait automatiquement collecté 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. Nous n’envoyons plus explicitement ces métriques vers performanceCounters dans OpenTelemetry. Les métriques associées aux demandes entrantes/sortantes se trouvent sous les métriques standard. Si vous souhaitez qu’OpenTelemetry récupère automatiquement les métriques liées au système, vous pouvez utiliser l’instrumentation des métriques système expérimentales fournie 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 dépannage et les options de support, ou pour fournir des commentaires sur OpenTelemetry, consultez Dépannage, support et commentaires OpenTelemetry pour Azure Monitor Application Insights.