Partager via

  • Article

Mai 2017

Volume 32, numéro 5

Cet article a fait l'objet d'une traduction automatique

DevOps - Optimiser la télémétrie avec Application Insights

Par Victor Mushkatin | Mai 2017

L’importance de l’analyse de votre service est évident. Dans cet article, nous allons nous concentrer sur les techniques fondamentales pour faciliter la gestion de vos investissements de surveillance. Pour les besoins de cette discussion, « gérable » signifie que toute télémétrie collecte sur votre service, tandis qu’exploitables, ne consomme pas une quantité raisonnable de ressources.

Lorsque tout fonctionne correctement, vous ne pas nécessairement besoin de connaître les téraoctets de données de journaux collectées pour l’exécution du service. Vous n’en utilisent que les tendances générales. Toutefois, lorsque le service tombe en panne ou fonctionne mal, vous devez tout — et — pour diagnostiquer les problèmes. Comment garantir l’équilibre entre les données requises pour détecter le problème et doivent être récupérées tout le temps, à partir des données sont nécessaire pour résoudre le problème et doit être collecté, Eh bien, lorsqu’elle doit être collectées ?

Pour illustrer les techniques, nous allons utiliser le Service Microsoft Azure Application Insights et son modèle de kit de développement hautement extensible. Alors que nous abordons des concepts sont applicables à tous, notre objectif est d’aider à vous familiariser avec les capacités de l’emploi de Application Insights SDK et les points d’extensibilité qui vous permettent de faciliter la gestion de votre « télémétrie d’échappement ». Après avoir lu cet article, vous serez en mesure de comprendre le modèle de domaine d’Application Insights, mode de collecte de données de télémétrie et les techniques de codage sont disponibles pour réduire la quantité de données de télémétrie, tout en préservant les capacités de surveillance, précision analytique et la profondeur de diagnostic.

Volume indépendant de télémétrie

Prendre un service qui traite de 1 milliard de transactions par jour. Si vous vous connectez tous les détails sur chaque transaction, vous serez en mesure de répondre à toutes sortes de questions, par exemple, questions sur les transactions latence 95e centile d’un emplacement géographique particulier ou taux d’échec pour les utilisateurs qui exécutent un navigateur spécifique. Outre ces mesures de surveillance, vous serez en mesure de prendre en charge les utilisateurs lorsqu’ils appelant et poser des questions spécifiques sur la transaction a échoué en consultant les journaux. Plus de données que vous collectez, le plus grand nombre de questions que vous pouvez répondre en analysant les données de télémétrie application.

Mais tout cela a un prix. Même à bas prix pour la collecte de données (bit.ly/2nNhp3c), avez-vous vraiment besoin collecter les points de données de 1 milliard ? Ou pire, si chaque transaction effectue un appel à la base de données SQL, vraiment devez-vous collecter un points de données de 1 milliard supplémentaires pour tous les appels de base de données SQL ? Si vous ajoutez toute la télémétrie possible qui peut-être être nécessaires pour surveiller, dépanner et analyser l’exécution de votre service, vous constaterez l’infrastructure pour prendre en charge pour qu’il soit assez chers, affectent de manière significative du retour sur investissement de l’analyse.

En règle générale, des fonctions d’analyse, les personnes utilisent différents indicateurs de performance clés de service (KPI), par exemple, service charge, latence de transaction et le taux de défaillance. Pour exposer ces indicateurs de performance clés, le système de surveillance doit posséder une bonne connaissance de la structure de données de télémétrie. Il doit être en mesure de différencier les événements qui représentent l’exécution de la transaction à partir de, disons, les événements qui représentent des appels SQL. Avec la sémantique de télémétrie, vous pouvez efficacement convertir le volume de données de télémétrie indépendant en un ensemble d’indicateurs de performance clés que vous serez et peu onéreux de recueillir et de stocker et de disposer de suffisamment de données pour répondre à vos questions d’analyse facile à gérer.

Le Kit de développement logiciel Application Insights offre le modèle qui permet l’Application Insights Service restituer l’interface utilisateur efficace et intuitive pour prendre en charge votre analyse, dépannage et d’analyse des besoins, comme illustré Figure 1.

Modèle de données de télémétrie d’application

Figure 1 modèle de données de télémétrie d’Application

Nous allons nous concentrer sur les deux modèles d’application dans le cadre de cette révision, les applications avec un point de terminaison qui reçoivent des requêtes externes, généralement utilisés pour les Applications Web et les applications qui régulièrement « réveiller » pour traiter les données stockées quelque part, généralement utilisés pour les tâches Web ou des fonctions. Dans les deux cas, nous appelons à exécution unique une opération. Opération réussit ou échoue à l’exception, ou elle peut dépendre d’autres services/stockage pour effectuer sa logique métier. Pour refléter ces concepts, Application Insights SDK définit trois types de télémétrie : demande, les exceptions et les dépendances. Pour chacun de ces types, modèle de données de télémétrie définit les champs utilisés pour construire courantes : nom du KPI, durée, code d’état et la corrélation. Il permet également d’étendre chaque type avec les propriétés personnalisées. Voici certains champs par défaut pour chacun des types d’événements :

  • Demande (id de l’opération, nom, URL, durée, code d’état, [...])
  • Dépendances (id d’opération parent, nom, la durée, [...])
  • Exception (parent de l’id d’opération, classe d’exception, pile des appels, [...])

En règle générale, ces types sont définis par l’infrastructure d’application et sont automatiquement collectées par le Kit de développement logiciel. Par exemple, ASP.NET MVC définit la notion d’une demande de l’exécution dans son modèle-Vue-contrôleur plomberie – informatique définit lorsque demande démarre et s’arrête, les appels de dépendance SQL est définies par System.Data, et les appels aux points de terminaison HTTP sont définis par System.Net. Toutefois, il existe des cas où vous devrez peut-être exposer télémétrie unique pour votre application. Par exemple, vous pouvez mettre en œuvre de journalisation des diagnostics à l’aide d’une infrastructure familière-à-vous instrumentation, telles que Log4Net ou System.Diagnostics, ou vous pouvez souhaiter capturer l’interaction utilisateur avec votre service pour analyser les modèles d’utilisation. Application Insights reconnaît trois types de données supplémentaires pour aider à ce besoin, Trace, des événements et des mesures :

  • Trace (id d’opération, message, gravité, [...])
  • Mesures (id de l’opération, nom, valeur, [...])
  • Événement (id d’opération, nom, id d’utilisateur, [...])

En plus de la collecte de données, Application Insights est en corrélation automatiquement toutes les données de télémétrie à l’opération dont il fait partie. Par exemple, si vous apportez lors du traitement d’une application demande des certains appels de base de données SQL, les appels de Services Web et les informations de diagnostic enregistrées, tout est automatiquement en corrélation avec la demande en plaçant un id d’opération généré automatiquement dans la charge utile de télémétrie respectifs.

Le Kit de développement logiciel Application Insights dispose d’un modèle en couche où les types de télémétrie indiqués précédemment, points d’extensibilité et algorithmes de réduction de données sont définis dans le package NuGet Application Insights API (bit.ly/2n48klm). Discussion le focus sur les principes de base, nous allons utiliser ce SDK pour réduire le nombre de concepts de collecte de données spécifiques à la technologie autant que possibles.

Techniques de réduction

Il existe quatre techniques de réduction de données disponibles dans le Kit de développement logiciel Application Insights. En tant que développeur, vous pourrez les utiliser à l’aide d’une API d’extensibilité intégré. Nous allons illustrer l’utilisation de ces API plus loin dans cet article.

Agrégation et l’extraction de mesures est une technique qui vous permet de réduire les données localement en regroupant les métriques à partir des données de télémétrie et en envoyant uniquement les valeurs agrégées, au lieu des événements eux-mêmes. Imaginez que vous avez 100 demandes par minute. Si la seule chose qui que vous intéressent est le nombre de demandes par minute, cette technique vous permet de compter le nombre de demandes localement et d’envoyer la valeur une fois par minute, au lieu de l’envoi de chaque demande et le calcul de nombres à partir de la télémétrie brute.

L’échantillonnage est une technique qui collecte sélective des sous-ensembles de données télémétriques qui vous permet d’estimer les caractéristiques du service. Pour la plupart des services, vous pouvez rassembler chaque demande « n-th » pour obtenir la représentation sous forme de statistique bien distribuée de comportement de service. Cette technique, d’une part, vous permet de réduire le volume de la collection en fonction des heures « n » et d’autre part, conserve avec certaine validité statistique de la précision des mesures dérivées de ce type de télémétrie. Pour améliorer la précision, vous devez utiliser un modèle sophistiqué d’algorithme et les données.

Exemple consiste à collecter des exemples d’intérêt sans invalider la précision statistique de l’échantillonnage. Par exemple, vous souhaiterez toujours collecter les échecs de requêtes, quelle que soit la configuration d’échantillonnage. Ainsi, pendant que vous réduisez la charge de télémétrie par échantillonnage, vous pouvez conserver les données de dépannage utiles.

Le filtrage est la possibilité de réduire les données en filtrant la télémétrie que ne vous intéressent. Par exemple, vous souhaiterez ignorer toutes les données de télémétrie liées au trafic généré par des robots de recherche ou de surveillance synthétiques. De cette façon, vos mesures reflète l’interaction utilisateur true avec le service.

Application Insights SDK

Pour illustrer ces techniques de réduction, il est important de comprendre comment le SDK Application Insights traite la télémétrie. Il peut être regroupé logiquement dans quatre étapes, comme indiqué dans Figure 2.

Comment l’Application Insights SDK traite la télémétrie

Figure 2 comment l’Application Insights SDK traite la télémétrie

Collecte de données est implémentée comme un ensemble de modules de télémétrie, les ensembles de données particuliers, chacun d'entre eux. Par exemple, il est un module de télémétrie pour collecter les compteurs de performance, les exceptions et les dépendances et ainsi de suite.

Au cours de l’enrichissement des données de télémétrie, chaque élément est assorti de télémétrie. Par exemple, le Kit de développement logiciel Application Insights ajoutera automatiquement le nom du serveur comme l’une des propriétés de chaque élément de télémétrie. Jeux d’initialiseurs de télémétrie prédéfinies ; Toutefois, les développeurs peuvent ajouter n’importe quel nombre d’initialiseurs supplémentaires à inclure des propriétés qui aident à la surveillance, résolution des problèmes et les processus analytiques. Par exemple, pour les services répartis géographiquement, vous souhaiterez ajouter géolocalisation pour analyser le trafic traité séparément par chaque centre de données. Essentiellement, au cours de cette étape, vous augmentez la charge utile de l’élément de télémétrie.

Le pipeline de traitement des données de télémétrie est l’endroit où vous définissez la logique permettant de réduire la quantité de données de télémétrie envoyée au service. Le Kit de développement logiciel Application Insights fournit des processeurs de télémétrie d’échantillonnage pour réduire automatiquement les données de télémétrie recueillies sans compromettre la précision statistique.

Télémétrie transmissionis dernière étape du traitement de télémétrie où toutes les données de télémétrie traitées par une application en file d’attente, traités par lot, compressés et régulièrement envoyées à une ou plusieurs destinations. Le Kit de développement logiciel Application Insights prend en charge la transmission vers le Service d’Application Insights et d’autres canaux, comme le concentrateur d’événements, prête à l’emploi.

Dans cet article, nous concentrer sur les techniques disponibles pour le développeur de configurer d’échantillonnage de l’emploi et des processeurs supplémentaires de télémétrie pour optimiser la collecte des données aux besoins du service. Tous les exemples de cet article génèrent la configuration d’analyse dans le code à partir de zéro. Cependant, dans de nombreux environnements de production, la plupart des paramètres mentionnés est exposée en tant que paramètres de configuration qui peuvent être ajustés sans la recompilation de l’application.

Agrégation de mesures

Avant pour aller plus loin, que nous souhaitons aborder les concepts de type de données de télémétrie. En règle générale, vous pouvez fractionner toutes les données de télémétrie en deux catégories : événements et des mesures.

Une mesure est définie comme données de série chronologique, agrégées au préalable des intervalles spécifiés. Par exemple, supposons que vous souhaitez compter le nombre d’appels d’une fonction. Il s’agit d’une mesure simple qui est incrémentée chaque fois lorsque l’appel de fonction se produit. La valeur des mesures lui-même obtient agrégée sur une période donnée, par exemple, une minute, et à la fin de cette heure est envoyé.

Un événement est un enregistrement unique d’une occurrence est envoyé chaque fois. Dans de nombreux cas, les événements ont une structure très spécifique ou un type. Dans l’exemple d’Application Insights, l’événement de modèle de domaine d’un type de requête possède des propriétés différentes à l’événement d’un type d’Exception. Pour revenir à l’exemple précédent, si vous souhaitez capturer l’exécution de chaque fonction, vous pouvez envoyer événement avec le nom de la fonction et les paramètres de fonction chaque fois qu’elle est exécutée. Ces événements vous permettent de répondre à toutes sortes de questions sur l’exécution de la fonction. Par exemple, avec la télémétrie d’événements bruts, vous pouvez calculer combien de fois cette fonction a été appelée avec une valeur de paramètre particulier. Notez que plus fidèlement de données en plus de l’analyse simple, comme le nombre d’exécution de la fonction, vous pouvez désormais analyser le nombre d’exécution regroupé par le paramètre de fonction. 

Télémétrie brute est beaucoup plus riche et vous permet de fournir des informations plus efficacement, mais il existe un inconvénient liés au traitement et les coûts de stockage associés. Une façon de résoudre ce problème consiste à créer autant de mesures à l’avance que vous pensez que vous aurez besoin analyser votre application. Le problème avec cette approche est que votre entreprise est beaucoup plus dynamique et elle n’est pas toujours possible de savoir quelles mesures vous devrez peut-être à l’avance. Le Kit de développement logiciel Application Insights résout ce problème en fournissant un équilibre entre la télémétrie agrégé et raw : rassemble les indicateurs de performance clé de l’application et envoie échantillonnées télémétrie application brutes. Cette approche d’échantillonnage permet de réduire la charge de collecte de données brutes du Kit de développement logiciel et augmente le retour sur investissement des données collectées.

Échantillonnage

Il existe deux processeurs de télémétrie d’échantillonnage de l’emploi fournis par le Kit de développement logiciel Application Insights : fixe d’échantillonnage et d’échantillonnage adaptatif (bit.ly/2mNiDHS).

Taux fixe échantillonnage réduit le volume de données de télémétrie par nœud. Par exemple, vous souhaiterez collecter seulement 20 pour cent de toutes les données de télémétrie à partir de chaque nœud.

Samplingautomatically ADAPTATIF ajuste le volume de données de télémétrie par nœud. Par exemple, vous souhaiterez diminuer la collection lorsque la charge est supérieure à 5 eps ou nœud.

Remarque : Il 's également ingestion d’échantillonnage que télémétrie ignore, ce qui arrive à partir de votre application sur le point de terminaison ingestion. Nous n’allons pas aborder cette technique dans cet article, mais vous trouverez la documentation à bit.ly/2mNiDHS.

Les deux processeurs de télémétrie d’échantillonnage utilisent un algorithme courantes qui vous permet de combiner ces processeurs sans affecter la précision statistique des données. Pour déterminer si l’élément de télémétrie a à échantillonner entrant ou sortant, le Kit de développement utilise une fonction de hachage sans état et compare a retourné la valeur avec le rapport de configuration. Cela signifie que quel que soit le thread, un processus ou un serveur traite les données, données de télémétrie avec une valeur de hachage sous le seuil à constamment échantillonner dans. Sous forme simplifiée vous pouvez codifier cet algorithme comme suit :

If exist(UserID): Hash(UserID) = (returns value [0..100])
ElseIf exist(OperationID): Hash(OperationID) (returns value [0..100])
Else: Random [0..100]

Comme vous pouvez voir à partir de là, tant que UserID ou OperationID est partagé entre tous les éléments de télémétrie associés, tout aura la même valeur de hachage et constamment être échantillonnés entrant ou sortant. Application Insights par défaut permet d’échantillonnage ADAPTATIF lors de la collecte de données. Toutes les données de télémétrie stockées dans les services possède une colonne appelée itemCount. Il représente le taux d’échantillonnage au moment de la collecte de données. Étant donné que l’algorithme de calcul de hachage est sans état, ce numéro ne représente pas le nombre réel de l’échantillon des données de télémétrie, elle indique uniquement le rapport de statistique de télémétrie de l’échantillonnage. Pour analyser rapidement si vos données de télémétrie ont été échantillonnées, vous pouvez exécuter la requête suivante analytique pour comparer le nombre d’enregistrements stockés avec le nombre d’enregistrements traités par le service :

requests | summarize sum(itemCount),
     count()

Si vous voyez la différence entre ces deux nombres, puis l’échantillonnage a été activé et votre jeu de données a été réduit.

Réduction des données en Action

Passons en revue toutes ces techniques. Nous allons utiliser une application console pour mettre en évidence les principaux concepts. Les commandes ping application bing.com dans une boucle et stocke des données télémétrie dans Application Insights. Il traite chaque exécution de la boucle comme un télémétrie demande automatiquement collecte les données de dépendance et met en corrélation toutes les données de télémétrie à la demande « appropriée » auquel il appartient.

Pour initialiser le SDK Application Insights, vous devez effectuer les trois étapes simples. Tout d’abord, vous devez initialiser la configuration avec la clé d’Instrumentation. Clé d’instrumentation est un identificateur utilisé pour associer les données de télémétrie avec la ressource Application Insights et peut être obtenue dans le portail Azure lors de sa création :

// Set Instrumentation Key
var configuration = new TelemetryConfiguration();
configuration.InstrumentationKey = "fb8a0b03-235a-4b52-b491-307e9fd6b209";

Ensuite, vous devez initialiser le module de suivi des dépendances pour collecter automatiquement les informations de dépendance :

// Automatically collect dependency calls
var dependencies = new DependencyTrackingTelemetryModule();
dependencies.Initialize(configuration);

Enfin, vous devez ajouter un initialiseur de télémétrie qui ajoute des id de corrélation commun à toutes les données de télémétrie associées :

// Automatically correlate all telemetry data with request
configuration.TelemetryInitializers.Add(new                        
  OperationCorrelationTelemetryInitializer());

À ce stade, le Kit de développement logiciel Application Insights est entièrement initialisé et que vous pouvez accéder à toutes les API via TelemetryClient objet et le code de la boucle principale, comme indiqué dans Figure 3.

Figure 3 l’Instrumentation de Code typique pour l’analyse du traitement des boucles

var client = new TelemetryClient(configuration);
var iteration = 0;
var http = new HttpClient();
while (!token.IsCancellationRequested)
{
  using (var operation = client.StartOperation<RequestTelemetry>("Process item"))
  {
    client.TrackEvent("IterationStarted",
      properties: new Dictionary<string, string>(){{"iteration",
      iteration.ToString()}});
    client.TrackTrace($"Iteration {iteration} started", SeverityLevel.Information);
    try
    {
      await http.GetStringAsync("https://bing.com");
    }
    catch (Exception exc)
    {
      // This call will not throw
      client.TrackException(exc);
      operation.Telemetry.Success = false;
    }
    client.StopOperation(operation);
    Console.WriteLine($"Iteration {iteration}. Elapsed time:
      {operation.Telemetry.Duration}");
    iteration++;
  }
}

Lorsque vous exécutez cette application, vous verrez l’écran présenté à Figure 4 dans une fenêtre de console.

Boucle de traitement de la sortie de télémétrie : numéro d’itération et la durée de chaque Cycle.

Figure 4 boucle de sortie de télémétrie : numéro d’itération et la durée de chaque Cycle.

Toutes les données de télémétrie seront envoyée vers le nuage et sont accessibles via le portail. Pendant le développement, il est plus facile à analyser les données de télémétrie dans Visual Studio. Par conséquent, si vous exécutez le code dans Visual Studio sous le débogueur, vous verrez télémétrie immédiatement dans l’onglet Application Insights recherche. Il doit ressembler à ce qui est indiqué dans Figure 5.

Boucle de traitement de la sortie de télémétrie dans Application Insights

Figure 5 boucle de sortie de télémétrie dans Application Insights

L’analyse de ce journal, pour chaque demande, vous pouvez voir télémétrie de trace, événements et de dépendance avec le même id d’opération. À ce stade, vous avez une application qui envoie différents Application Insights télémétrie types automatiquement collecte les appels de dépendance et les met en corrélation tous pour les demandes appropriées. À présent, nous allons réduire le volume de données de télémétrie utilisant des processeurs de télémétrie d’échantillonnage de l’emploi.

Comme indiqué précédemment, le Kit de développement logiciel Application Insights définit le pipeline de traitement de télémétrie qui permet de réduire la quantité de télémétrie envoyée au portail. Toutes les données de télémétrie recueillies entre dans le pipeline et tous les processeurs télémétrie décide s’il faut passer davantage. Comme vous le verrez, la configuration d’échantillonnage avec les processeurs de télémétrie hors de la zone est aussi simple que de les inscrire dans le pipeline et nécessite seulement quelques lignes de code. Mais pour illustrer l’effet de ces processeurs, nous allons légèrement modifier le programme et introduire une classe d’assistance pour présenter le rapport.

Commençons par créer le traitement de télémétrie allez calculer la taille des éléments de télémétrie vont via, comme indiqué dans Figure 6.

Figure 6 télémétrie processeur pour le calcul de la taille d’élément

internal class SizeCalculatorTelemetryProcessor : ITelemetryProcessor
{
  private ITelemetryProcessor next;
  private Action<int> onAddSize;
  public SizeCalculatorTelemetryProcessor(ITelemetryProcessor next,
    Action<int> onAddSize)
  {
    this.next = next;
    this.onAddSize = onAddSize;
  }
  public void Process(ITelemetry item)
  {
    try
    {
      item.Sanitize();
      byte[] content =
        JsonSerializer.Serialize(new List<ITelemetry>() { item }, false);
      int size = content.Length;
      string json = Encoding.Default.GetString(content);
      this.onAddSize(size);
    }
    finally
    {
      this.next.Process(item);
    }
  }
}

Vous êtes maintenant prêt à créer le pipeline de traitement des données de télémétrie. Il se compose de quatre processeurs de télémétrie. Le premier d'entre eux calcule la taille et le nombre de télémétrie envoyée dans le pipeline. Ensuite, vous utiliserez le processeur de télémétrie d’échantillonnage fixe à échantillonner seuls 10 % des appels de dépendance (dans ce cas, un test ping à bing.com). En outre, vous allez activer d’échantillonnage adapté à tous les types de données de télémétrie, à l’exception des événements. Cela signifie que tous les événements seront collectés. Le processeur de télémétrie dernier calcule la taille et le nombre d’éléments de télémétrie qui est envoyé dans le canal de transmission suivante au service, comme indiqué dans Figure 7.

Figure 7 générant une chaîne de traitement de télémétrie avec des éléments d’échantillonnage

// Initialize state for the telemetry size calculation
var collectedItems = 0;
var sentItems = 0;
// Build telemetry processing pipeline
configuration.TelemetryProcessorChainBuilder
  // This telemetry processor will be executed
  // first for all telemetry items to calculate the size and # of items
  .Use((next) => { return new SizeCalculatorTelemetryProcessor(next,
    size => Interlocked.Add(ref collectedItems, size)); })
  // This is a standard fixed sampling processor that'll let only 10%
  .Use((next) =>
  {
    return new SamplingTelemetryProcessor(next)
    {
      IncludedTypes = "Dependency",
      SamplingPercentage = 10,
    };
  })
  // This is a standard adaptive sampling telemetry processor
  // that will sample in/out any telemetry item it receives
  .Use((next) =>
  {
    return new AdaptiveSamplingTelemetryProcessor(next)
    {
      ExcludedTypes = "Event", // Exclude custom events from being sampled
      MaxTelemetryItemsPerSecond = 1, // Default: 5 calls/sec
      SamplingPercentageIncreaseTimeout =
        TimeSpan.FromSeconds(1), // Default: 2 min
      SamplingPercentageDecreaseTimeout =
        TimeSpan.FromSeconds(1), // Default: 30 sec
      EvaluationInterval = TimeSpan.FromSeconds(1), // Default: 15 sec
      InitialSamplingPercentage = 25, // Default: 100%
    };
  })
  // This telemetry processor will be executed ONLY when telemetry is sampled in
  .Use((next) => { return new SizeCalculatorTelemetryProcessor(next,
    size => Interlocked.Add(ref sentItems, size)); })
  .Build();

Enfin, vous allez modifier légèrement la sortie pour afficher les données de télémétrie recueillies et envoyées et le taux de réduction de la console :

Console.WriteLine($"Iteration {iteration}. " +
  $"Elapsed time: {operation.Telemetry.Duration}. " +
  $"Collected Telemetry: {collectedItems}. " +
  $"Sent Telemetry: {sentItems}. " +
  $"Ratio: {1.0 * collectedItems / sentItems}");

Lors de l’exécution de l’application, vous pouvez voir que le rapport peut être aussi élevé que trois fois !

Maintenant, si vous accédez à la page d’Application Insights Analytique et exécutez la requête indiquée ici, vous pouvez voir les statistiques affichées dans Figure 8, prouvant que l’échantillonnage a fonctionné. Vous consultez uniquement quelques requêtes représentant de nombreux éléments de télémétrie.

Nombre d’éléments de télémétrie dans Application Insights et estimation du nombre d’éléments initialement collectées

Figure 8 nombre d’éléments de télémétrie dans Application Insights et estimation du nombre d’éléments initialement collectées

Exemple et le filtrage

Jusqu'à présent, nous avons parlé d’échantillonnage et que vous avez appris comment créer un processeur de télémétrie simple et de pipeline de traitement de télémétrie personnalisée. Sachant cela, vous pouvez Explorer deux autres techniques, de filtrage et exemple. Nous avons apporté quelques exemples pour illustrer ce que vous pouvez faire.

Tout d’abord, examinons l’exemple. Supposons que votre application dépend d’un service tiers, et elle garantit une performance SLA pour traiter les demandes. Avec l’approche existant, vous pouvez collecter des exemples d’appels de dépendance. Mais que se passe-t-il si vous souhaitez collecter toutes les preuves où ce service n’était pas compatible avec son contrat SLA ? À cet effet de la démonstration, nous avons créé un processeur de télémétrie d’exemple qui rassemble tous les appels de dépendance qui sont conformes à 100 ms SLA, comme indiqué dans Figure 9.

Figure 9 marquage ralentir les appels de dépendance pour la collecte et de les exclure de l’échantillonnage

internal class DependencyExampleTelemetryProcessor : ITelemetryProcessor
{
  private ITelemetryProcessor next;
  public DependencyExampleTelemetryProcessor(ITelemetryProcessor next)
  {
    this.next = next;
  }
  public void Process(ITelemetry item)
  {
    // Check telemetry type
    if (item is DependencyTelemetry)
    {
      var r = item as DependencyTelemetry;
      if (r.Duration > TimeSpan.FromMilliseconds(100))
      {
        // If dependency duration > 100 ms then "sample in"
        // this telemetry by setting sampling percentage to 100
        ((ISupportSampling)item).SamplingPercentage = 100;
      }
    }
    // Continue with the next telemetry processor
    this.next.Process(item);
  }
}

À la différence d’exemple, qui, en fait, augmente le volume des données de télémétrie recueillie pour les besoins de fidélité plus précise des données, le filtrage est plus radical, comme il supprime des éléments de télémétrie sur le sol, les rendant complètement invisibles pour le service. À des fins de démonstration, nous avons créé un processeur de télémétrie d’exemple qui supprime tous les appels de dépendance qui sont plus rapides que 100 ms, comme indiqué dans Figure 10.

Figure 10 filtrage de télémétrie d’appels de dépendance rapide

internal class DependencyFilteringTelemetryProcessor : ITelemetryProcessor
{
  private readonly ITelemetryProcessor next;
  public DependencyFilteringTelemetryProcessor(ITelemetryProcessor next)
  {
    this.next = next;
  }
  public void Process(ITelemetry item)
  {
    // Check telemetry type
    if (item is DependencyTelemetry)
    {
      var d = item as DependencyTelemetry;
      if (d.Duration < TimeSpan.FromMilliseconds(100))
      {
        // If dependency duration > 100 ms then stop telemetry
        // processing and return from the pipeline
        return;
      }
    }
    this.next.Process(item);
  }
}

Filtrage des données de télémétrie est efficace pour réduire la quantité de données de télémétrie et augmenter sa qualité. Lorsque vous savez que l’élément de télémétrie n’est pas exploitable, vous ne souhaitez voir en analytique. L’utilisation du processeur de télémétrie dans l’exemple précédent, vous ne verrez les appels de dépendance plus rapidement que 100 ms. Si vous essayez de calculer la durée moyenne du traitement de dépendance basée sur l’enregistrement de dépendance, vous obtiendrez des résultats incorrects.

Essayons de résoudre ce problème en agrégation de télémétrie d’appel de dépendance localement et en envoyant des métriques « true » pour le service. Pour ce faire, nous allons utiliser une API de nouvelles mesures et de modifier le processeur de télémétrie pour exposer des mesures avant de supprimer les données de télémétrie, comme indiqué dans Figure 11.

Figure 11 le filtrage de télémétrie d’appels rapides de dépendance avec regroupement préalable des mesures

internal class DependencyFilteringWithMetricsTelemetryProcessor
                                        : ITelemetryProcessor, IDisposable
{
  private readonly ITelemetryProcessor next;
  private readonly ConcurrentDictionary<string, Tuple<Metric, Metric>> metrics
    = new ConcurrentDictionary<string, Tuple<Metric, Metric>>();
  private readonly MetricManager manager;
  public DependencyFilteringWithMetricsTelemetryProcessor(
    ITelemetryProcessor next, TelemetryConfiguration configuration)
  {
    this.next = next;
    this.manager = new MetricManager(new TelemetryClient(configuration));
  }
  public void Process(ITelemetry item)
  {
    // Check telemetry type
    if (item is DependencyTelemetry)
    {
      var d = item as DependencyTelemetry;
      // Increment counters
      var metrics = this.metrics.GetOrAdd(d.Type, (type) =>
      {
        var dimensions = new Dictionary<string, string> { { "type", type } };
        var numberOfDependencies =
          this.manager.CreateMetric("# of dependencies", dimensions);
        var dependenciesDuration =
           this.manager.CreateMetric("dependencies duration (ms)", dimensions);
        return new Tuple<Metric, Metric>(
          numberOfDependencies, dependenciesDuration);
      });
      // Increment values of the metrics in memory
      metrics.Item1.Track(1);
      metrics.Item2.Track(d.Duration.TotalMilliseconds);
      if (d.Duration < TimeSpan.FromMilliseconds(100))
      {
        // If dependency duration > 100 ms then stop telemetry
        // processing and return from the pipeline
        return;
      }
    }
    this.next.Process(item);
  }
  public void Dispose()
  {
    this.manager.Dispose();
  }
}

Comme vous pouvez le voir, nous créons deux mesures : « # de dépendances » et « durée de dépendances (ms) », avec la dimensionnalité d’un type de dépendance. Dans notre cas, tous les appels de dépendance sont balisés avec type HTTP. Si vous accédez à Analytique, vous pouvez voir les informations recueillies pour vos mesures personnalisées, comme indiqué dans Figure 12.

Mesure Préagrégée collectée par Application Insights

Figure 12 de mesure agrégées au préalable collectée par Application Insights

Cet exemple vous permet de calculer le nombre total d’appels et durée que consacre lors de l’appel à des dépendances de votre application. Nom contient le nom des mesures, autrement dit, durée de la dépendance (ms) ; valeur est la somme de tous les appels http à bing.com; et customDimensions contient une dimension personnalisée appelée type avec la valeur HTTP. Il existait un total de 246 appels à l’appel d’API de suivi ; Toutefois, un seul enregistrement a été stocké par minute pour chaque mesure. L’efficacité du traitement et le coût sont des cas forts pour exposer la télémétrie d’application à l’aide de l’API MetricsManager. Le défi avec cette approche est que vous devez définir toutes vos mesures et dimensions en amont. Lorsque cela est possible, il est recommandée ; Toutefois, dans certains cas, il est pas possible ou la cardinalité de la dimension est trop élevée. Dans ce cas, appuyer sur échantillonnées télémétrie brute est le compromis raisonnable entre la précision et le volume de données de télémétrie.

Pour résumer

Réglage du volume de données de télémétrie d’analyse est un aspect important de fabrication bon retour sur investissement de votre analyse. Sur la collecte vous coûtera trop ; sous collecte vous empêche de pouvoir détecter, trier et diagnostiquer vos problèmes de production. Cette technique de l’article indiqué qui vous aident à gérer l’encombrement de collecte de données à l’aide du Kit de développement logiciel Application Insights et son modèle d’extensibilité. À l’aide des techniques de réduction des données, telles que l’échantillonnage, le filtrage, le regroupement des mesures et exemple, il a été démontré comment réduire considérablement le volume de données tout en conservant la précision de l’analyse, d’exactitude analytique et profondeur de diagnostics.

L’approche d’Application Insights est en cours adoptée par de nombreux nouveaux services de Microsoft et des infrastructures, telles que les fonctions d’Azure et Service Fabric (cette prise en charge est annoncé à la conférence Microsoft Build 2017 cette année) et une Communauté contribution Open source sur GitHub (bit.ly/2n1GFzF). En plus de .NET Framework, autres SDK sont disponibles, notamment JavaScript, Java et Node.js (améliorations Node.js Application Insights SDK comme mieux collecte TÉLÉMÉTRIQUE et corrélation, ainsi que l’accès à la plus simple dans Azure, ceux-ci seront annoncés à la Build 2017). Une collection de données cohérente, extensible et multiplates-Kit de développement logiciel, vous pouvez prendre le contrôle et « gérer » vos données de télémétrie dans votre environnement d’applications hétérogènes.

Victor Mushkatinest responsable de programme de groupe de l’équipe Application Insights. Son principal domaine d’expertise est technologies analyse de performances des applications et des pratiques de DevOps. Contactez-le à victormu@microsoft.com.

Sergey Kanzhelevest un développeur de logiciels principal de l’équipe Application Insights. Sa carrière a été entièrement dédié à la surveillance de l’application et de diagnostic. Il est passionné de connexion avec les clients, ainsi que d’un auteur du blog avid et collaborateur de GitHub. Contactez-le à sergkanz@microsoft.com.

Merci aux experts techniques suivants d'avoir relu cet article : Mario Hewardt, Vance Morrison et Mark Simms
Mario Hewardt est ingénieur de terrain Principal de Microsoft et auteur de débogage de Windows avancé et avancées de débogage .NET. Avec plus de 17 ans chez Microsoft, il a travaillé avec le développement de Windows à partir de Windows 98 jusqu'à Windows Vista. Avec l’arrivée du cloud computing, Mario a travaillé dans l’arène SaaS et remis Asset Inventory Service, ainsi qu’une équipe de développeurs qui créent la plate-forme de base pour le service de gestion en ligne de Microsoft génération suivante : Windows Intune. Mario a également travaillé en étroite collaboration avec les clients d’entreprise comme dédié développeur ingénieur de terrain afin de garantir que nos clients créent leurs solutions sur la pile Microsoft de manière plus efficace et fiable. 

Mark Simms est un membre de l’Application Platform équipe de conseil clientèle, but d’aider les clients et partenaires de créent des événements en temps réel par des applications à l’aide de StreamInsight, AppFabric et BizTalk.

Vance Morrison est l’architecte de performances pour le Runtime .NET chez Microsoft.  Il passe son temps à autre pour apprendre à éviter les pièges de performances à l’aide de .NET ou accélérer les divers aspects de l’exécution.   Il a été un impliqué dans les conceptions de composants du runtime .NET depuis sa création.  Auparavant, il a influencé la conception de .NET langage intermédiaire (IL) et a été responsable du développement de la seule dans le compilateur de temps pour l’exécution.