Partager via

Échantillonnage dans Azure Monitor Application Insights avec OpenTelemetry

Application Insights inclut un échantillonneur personnalisé et s’intègre à OpenTelemetry pour réduire le volume de télémétrie, réduire les coûts et conserver les données de diagnostic dont vous vous souciez.

Important

Pour plus d’informations sur l’échantillonnage lors de l’utilisation des kits de développement logiciel (SDK) d’API Classic Application Insights, consultez Échantillonnage d’API classique.

Conditions préalables

Avant de continuer, assurez-vous d’avoir :

Pourquoi l’échantillonnage est important

L’échantillonnage est essentiel pour les applications générant de grandes quantités de données de télémétrie.

Sans échantillonnage, l’ingestion excessive des données peut :

  • Augmenter les coûts de stockage et de traitement
  • Entraîner une limitation de télémétrie par Application Insights

L’échantillonnage efficace conserve suffisamment de données pour les diagnostics significatifs tout en contrôlant les coûts.

L’échantillonnage n’est pas activé par défaut dans les distributions OpenTelemetry d’Application Insights. Vous devez activer et configurer explicitement l’échantillonnage pour gérer votre volume de télémétrie.

Remarque

Si vous voyez des frais inattendus ou des coûts élevés dans Application Insights, ce guide peut vous aider. Il couvre les causes courantes telles que le volume de télémétrie élevé, les pics d’ingestion de données et l’échantillonnage mal configuré. Il est particulièrement utile si vous résolvez des problèmes liés aux pics de coûts, au volume de télémétrie, à l’échantillonnage qui ne fonctionne pas, aux limites de données, à l’ingestion élevée ou à la facturation inattendue. Pour commencer, consultez Résoudre les problèmes d’ingestion de données élevées dans Application Insights.

Échantillonneur personnalisé Application Insights

La distribution basée sur Azure Monitor OpenTelemetry comprend un échantillonneur personnalisé.

  • Les métriques en temps réel et les SDKs de l'API classique d'Application Insights nécessitent cet échantillonneur pour la compatibilité.
  • L’échantillonneur est désactivé par défaut. Vous devez activer et configurer explicitement l’échantillonnage pour utiliser l’échantillonneur.
  • Il utilise un algorithme à taux fixe. Par exemple, un taux de 10 % envoie environ 10% de traces à Azure Monitor.
  • Le service Azure Monitor Application Insights s’appuie sur cet échantillonneur pour vous montrer les traces complètes et éviter celles qui ne le sont pas.

Avantages

  • Décisions d’échantillonnage cohérentes lors de l’interopérabilité avec les applications à l’aide des kits de développement logiciel (SDK) d’API Classic Application Insights.
  • Compatibilité complète avec les métriques actives , car l’échantillonneur est conscient des exigences en matière de métriques actives.

Pour configurer le pourcentage d’échantillonnage, reportez-vous à Activer l’échantillonnage dans Application Insights avec OpenTelemetry.

Pour obtenir des informations plus détaillées et des cas limites d’échantillonnage, consultez Questions fréquemment posées.

L'échantillonnage d'entrée est une solution de secours lorsque le contrôle au niveau de la source n'est pas possible. Il supprime les données au point d’ingestion Azure Monitor et n’offre aucun contrôle sur les traces et segments qui sont conservés. Cela augmente la probabilité de rencontrer des traces rompues.

Les scénarios où il s’agit de la seule option viable ou la plus pratique sont les suivants :

  • Vous ne pouvez pas modifier le code source de l’application.
  • Vous devez réduire immédiatement le volume de télémétrie sans redéployer des applications.
  • Vous recevez des données de télémétrie provenant de plusieurs sources avec des configurations d’échantillonnage incohérentes ou inconnues.

Pour configurer l’échantillonnage d’ingestion :

  1. Accédez à Application Insights>Utilisation et estimation des coûts.
  2. Sélectionnez Échantillonnage des données.
  3. Choisissez le pourcentage de données à conserver.

Définir un plafond quotidien

Définissez une limite quotidienne pour éviter les coûts inattendus. Cette limite arrête l’ingestion de télémétrie lorsqu’elle atteint le seuil.

Utilisez cette limite comme contrôle de dernier recours, pas un remplacement de l’échantillonnage. Une augmentation soudaine du volume de données peut déclencher le cap, créant un écart dans la télémétrie jusqu'à ce qu'il soit réinitialisé le lendemain.

Pour configurer la limite, consultez Définir une limite quotidienne pour Azure Monitor.

Questions fréquentes

L’échantillonneur personnalisé Application Insights intervient-il en fin de workflow ?

L’échantillonneur personnalisé Application Insights prend des décisions d’échantillonnage après la création d’un segment plutôt qu’avant, donc il ne suit pas une approche traditionnelle d’intervention en début de workflow. Au lieu de cela, il applique des décisions d’échantillonnage à la fin de la génération d’un segment, c’est-à-dire une fois que le segment est complet, mais avant l’exportation.

Bien que ce comportement ressemble d’une certaine façon à un échantillonnage en fin de workflow, l’échantillonneur n’attend pas de collecter plusieurs segments à partir de la même trace pour décider. Au lieu de cela, il utilise un hachage de l’ID de trace pour garantir l’exhaustivité de la trace.

Cette approche équilibre l’exhaustivité et l’efficacité des traces et évite le coût plus élevé associé à l’échantillonnage complet basé sur la queue.

Pour prendre des décisions d’échantillonnage basées sur le résultat d’une trace entière (par exemple, déterminer si un segment au sein de la trace a échoué), un échantillonnage complet en fin de workflow est requis dans un agent ou un collecteur en aval. Cette fonctionnalité n’est actuellement pas prise en charge, mais vous pouvez la demander en tant que nouvelle fonctionnalité via le Hub de commentaires.

Quelles sont les différences entre l’échantillonneur personnalisé Application Insights et l’échantillonnage en début ou en fin de workflow d’OpenTelemetry ?

Méthode d’échantillonnage Point de décision Points forts Faiblesses
En début de workflow Avant qu’un segment ne commence Latence faible, surcharge minimale Peut échantillonner les traces souhaitées, y compris les échecs
En fin de workflow Une fois que les segments sont mis en mémoire tampon sur la base de seuils de durée ou de volume Permet des critères d’échantillonnage de trace hautement sélectifs Coût plus élevé et retard de traitement ajouté
Échantillonneur personnalisé App Insights Fin de la génération d’un segment Trouve l’équilibre entre les traces complètes et l’efficacité Requis pour la compatibilité des métriques actives et des API classiques

Puis-je échantillonner des dépendances, des demandes ou d’autres types de télémétrie à différents taux ?

Non, l’échantillonneur applique un taux fixe sur tous les types de télémétrie dans une trace. Les requêtes, dépendances et autres segments suivent le même pourcentage d’échantillonnage. Pour appliquer différents taux par type de télémétrie, envisagez d’utiliser des processeurs de segments OpenTelemetry ou des (transformations de durée d’ingestion)[opentelemetry-overview.md#telemetry-routing].

Comment l’échantillonneur personnalisé Application Insights propage-t-il les décisions d’échantillonnage ?

L’échantillonneur personnalisé Application Insights propage les décisions d’échantillonnage à l’aide de la norme de contexte de trace W3C par défaut. Cette norme permet aux décisions d’échantillonnage de circuler entre les services. Toutefois, étant donné que l’échantillonneur prend des décisions d’échantillonnage à la fin de la génération d’un segment (après l’appel aux services en aval), la propagation comporte des informations d’échantillonnage incomplètes. Cette limitation est conforme à la spécification de contexte de trace W3C, mais les services en aval ne peuvent pas utiliser de manière fiable cette décision d’échantillonnage propagée.

L’échantillonneur personnalisé Application Insights respecte-t-il les décisions d’échantillonnage des services en amont ?

Non, l’échantillonneur personnalisé Application Insights prend toujours une décision d’échantillonnage indépendante, même si le service en amont utilise le même algorithme d’échantillonnage. Les décisions d'échantillonnage des services en amont, y compris celles qui utilisent des en-têtes de contexte de traçage W3C, n'influencent pas la décision du service en aval. Toutefois, il effectue un échantillonnage à partir d’un hachage de l’ID de trace pour s’assurer que la trace est complète. Pour améliorer la cohérence et réduire le risque de traces interrompues, configurez tous les composants du système pour utiliser le même échantillonneur et le même taux d’échantillonnage.

Pourquoi certaines traces apparaissent-elles incomplètes même lors de l’utilisation de l’échantillonneur personnalisé Application Insights ?

Il existe plusieurs raisons pour lesquelles les traces peuvent apparaître incomplètes :

  • Différents nœuds d’un système distribué utilisent différentes approches d’échantillonnage qui ne coordonnent pas les décisions. Par exemple, un nœud applique l’échantillonnage basé sur la tête OpenTelemetry, et un autre nœud applique l’échantillonnage via l’échantillonneur personnalisé Azure Monitor.
  • Différents nœuds sont définis sur des taux d’échantillonnage différents, même s’ils utilisent la même approche d’échantillonnage.
  • Vous définissez des limites de filtrage, d'échantillonnage ou de débit dans le pipeline côté serveur, et cette configuration échantillonne de manière aléatoire des traces sans tenir compte de leur exhaustivité.

Si un composant applique un échantillonnage en début de workflow sans propager la décision d’échantillonnage (via les en-têtes de contexte de trace W3C), les services en aval échantillonnent la trace indépendamment, ce qui peut aboutir à l’abandon de segments. Par conséquent, certaines parties de la trace ne sont pas toujours disponibles lorsqu’elles sont consultées dans Application Insights.

Étapes suivantes