Partager via

Remplacements d’échantillonnage - Azure Monitor Application Insights pour Java

  • Article

Remarque

La fonctionnalité de remplacements d’échantillonnage est en disponibilité générale, à partir de la version 3.5.0.

Les remplacements d’échantillonnage vous permettent de remplacer le pourcentage d’échantillonnage par défaut, par exemple :

  • Définissez le pourcentage d’échantillonnage sur 0 (ou une valeur faible) pour les contrôles d’intégrité bruyants.
  • Définissez le pourcentage d’échantillonnage sur 0 (ou une valeur faible) pour les appels de dépendance bruyants.
  • Définissez le pourcentage d’échantillonnage sur 100 pour un type de requête important (par exemple, /login) même si vous avez configuré l’échantillonnage par défaut sur une valeur inférieure.

Terminologie

Avant d’en apprendre davantage sur les remplacements d’échantillonnage, vous devez comprendre le terme étendue. Une étendue est un terme général désignant l’un de ces trois éléments :

  • Une requête entrante.
  • Une dépendance sortante (par exemple, un appel distant à un autre service).
  • Une dépendance « in-process » (par exemple, une tâche effectuée par les sous-composants du service).

Pour les remplacements d’échantillonnage, les composantes d’étendue suivants sont importants :

  • Attributs

Les attributs d’étendue représentent à la fois les propriétés standard et personnalisées d’une requête ou d’une dépendance donnée.

Prise en main

Pour commencer, créez un fichier de configuration nommé applicationinsights.json. Enregistrez-le dans le même répertoire que le fichier applicationinsights-agent-*.jar. Utilisez le modèle suivant.

{
  "connectionString": "...",
  "sampling": {
    "percentage": 10,
    "overrides": [
      {
        "telemetryType": "request",
        "attributes": [
          ...
        ],
        "percentage": 0
      },
      {
        "telemetryType": "request",
        "attributes": [
          ...
        ],
        "percentage": 100
      }
    ]
  }
}

Fonctionnement

telemetryType(telemetryKind dans Application Insights 3.4.0) doit être l’un de request, dependency, trace (journal) ou exception.

Au démarrage d’une étendue, le type d’étendue et les attributs présents dessus sont utilisés pour vérifier si l’un des remplacements d’échantillonnage correspond.

Les correspondances peuvent être strict ou regexp. Les correspondances des expressions régulières sont effectuées par rapport à la valeur entière de l’attribut. Par conséquent, si vous souhaitez faire correspondre une valeur contenant abc n’importe où dans celle-ci, vous devez utiliser .*abc.*. Un remplacement d’échantillonnage peut spécifier plusieurs critères d’attributs, auquel cas tous doivent être satisfaits pour que le remplacement d’échantillonnage soit en correspondance.

Si un des remplacements d’échantillonnage est en correspondance, son pourcentage d’échantillonnage est utilisé pour décider d’échantillonner ou non l’étendue.

Seul le premier remplacement d’échantillonnage correspondant est utilisé.

Si aucun remplacement d’échantillonnage ne correspond :

Exemple : supprimer la collecte de télémétrie pour les contrôles d’intégrité

Cet exemple supprime la collecte de télémétrie pour toutes les requêtes de /health-checks.

Cet exemple supprimera également la collecte des étendues en aval (dépendances) qui seraient normalement collectées sous /health-checks.

{
  "connectionString": "...",
  "sampling": {
    "overrides": [
      {
        "telemetryType": "request",
        "attributes": [
          {
            "key": "url.path",
            "value": "/health-check",
            "matchType": "strict"
          }
        ],
        "percentage": 0
      }
    ]
  }
}

Exemple : supprimer la collecte de télémétrie pour un appel de dépendance bruyant

Cet exemple supprime la collecte de télémétrie pour tous les appels redis de GET my-noisy-key.

{
  "connectionString": "...",
  "sampling": {
    "overrides": [
      {
        "telemetryType": "dependency",
        "attributes": [
          {
            "key": "db.system",
            "value": "redis",
            "matchType": "strict"
          },
          {
            "key": "db.statement",
            "value": "GET my-noisy-key",
            "matchType": "strict"
          }
        ],
        "percentage": 0
      }
    ]
  }
}

Exemple : collecter 100 % de la télémétrie pour un type de demande important

Cet exemple recueille 100 % des données télémétriques pour /login.

Étant donné que les étendues en aval (dépendances) respectent la décision d’échantillonnage du parent (sans remplacement d’échantillonnage pour cette étendue en aval), elles sont également collectées pour toutes les demandes « /login ».

{
  "connectionString": "...",
  "sampling": {
    "percentage": 10
  },
  "sampling": {
    "overrides": [
      {
        "telemetryType": "request",
        "attributes": [
          {
            "key": "url.path",
            "value": "/login",
            "matchType": "strict"
          }
        ],
        "percentage": 100
      }
    ]
  }
}

Attributs d’étendue disponibles pour l’échantillonnage

Les noms d’attributs d’étendue sont basés sur les conventions sémantiques OpenTelemetry. (HTTP, messagerie, base de données, RPC)

https://github.com/open-telemetry/semantic-conventions/blob/main/docs/README.md

Remarque

Pour voir l’ensemble exact d’attributs capturés par Application Insights Java pour votre application, définissez le niveau auto-diagnostics sur débogage, et recherchez les messages de débogage commençant par le texte « exporting span ».

Remarque

Seuls les attributs définis au début de l’étendue sont disponibles pour l’échantillonnage. Par conséquent, les attributs, tels que http.response.status_code ou la durée de la requête, qui sont capturés ultérieurement, peuvent être filtrés via les extensions OpenTelemetry Java. Voici un exemple d’extension qui filtre les étendues en fonction de la durée de la requête.

Exemple : exposition d’attributs d’étendue pour supprimer les appels de dépendance SQL

Cet exemple décrit l’expérience de recherche d’attributs disponibles pour supprimer les appels SQL bruyants. La requête ci-dessous illustre les différents appels SQL et le nombre d’enregistrements associés au cours des 30 derniers jours :

dependencies
| where timestamp > ago(30d)
| where name == 'SQL: DB Query'
| summarize count() by name, operation_Name, data
| sort by count_ desc

SQL: DB Query    POST /Order             DECLARE @MyVar varbinary(20); SET @MyVar = CONVERT(VARBINARY(20), 'Hello World');SET CONTEXT_INFO @MyVar;    36712549    
SQL: DB Query    POST /Receipt           DECLARE @MyVar varbinary(20); SET @MyVar = CONVERT(VARBINARY(20), 'Hello World');SET CONTEXT_INFO @MyVar;    2220248    
SQL: DB Query    POST /CheckOutForm      DECLARE @MyVar varbinary(20); SET @MyVar = CONVERT(VARBINARY(20), 'Hello World');SET CONTEXT_INFO @MyVar;    554074    
SQL: DB Query    GET /ClientInfo         DECLARE @MyVar varbinary(20); SET @MyVar = CONVERT(VARBINARY(20), 'Hello World');SET CONTEXT_INFO @MyVar;    37064

Dans les résultats ci-dessus, il peut être observé que toutes les opérations partagent la même valeur dans le champ data : DECLARE @MyVar varbinary(20); SET @MyVar = CONVERT(VARBINARY(20), 'Hello World');SET CONTEXT_INFO @MyVar;. Le point commun entre tous ces enregistrements en fait un bon candidat pour un remplacement d’échantillonnage.

En définissant l’autodiagnostic pour déboguer, les entrées de journal suivantes sont visibles dans la sortie :

2023-10-26 15:48:25.407-04:00 DEBUG c.m.a.a.i.exporter.AgentSpanExporter - exporting span: SpanData{spanContext=ImmutableSpanContext...

La zone d’intérêt de ces journaux est la section « attributs » :

{
  "attributes": {
    "data": {
      "thread.name": "DefaultDatabaseBroadcastTransport: MessageReader thread",
      "thread.id": 96,
      "db.connection_string": "apache:",
      "db.statement": "DECLARE @MyVar varbinary(20); SET @MyVar = CONVERT(VARBINARY(20), 'Hello World');SET CONTEXT_INFO @MyVar;",
      "db.system": "other_sql",
      "applicationinsights.internal.item_count": 1
    }
  }
}

À l’aide de cette sortie, vous pouvez configurer un remplacement d’échantillonnage similaire à celui ci-dessous qui filtrera nos appels SQL bruyants :

{
  "connectionString": "...",
  "preview": {
    "sampling": {
      "overrides": [
        {
          "telemetryType": "dependency",
          "attributes": [
            {
              "key": "db.statement",
              "value": "DECLARE @MyVar varbinary(20); SET @MyVar = CONVERT(VARBINARY(20), 'Hello World');SET CONTEXT_INFO @MyVar;",
              "matchType": "strict"
            }
          ],
          "percentage": 0
        }
      ]
    }
  }
}

Une fois les modifications appliquées, la requête suivante nous permet de déterminer la dernière fois que ces dépendances ont été ingérées dans Application Insights :

dependencies
| where timestamp > ago(30d)
| where data contains 'DECLARE @MyVar'
| summarize max(timestamp) by data
| sort by max_timestamp desc

DECLARE @MyVar varbinary(20); SET @MyVar = CONVERT(VARBINARY(20), 'Hello World');SET CONTEXT_INFO @MyVar;    11/13/2023 8:52:41 PM

Dépannage

Si vous utilisez regexp et que le remplacement d’échantillonnage ne fonctionne pas, essayez avec .* regex. Si l’échantillonnage fonctionne maintenant, cela signifie que vous rencontrez un problème avec le premier regex et lisez cette documentation regex.

S’il ne fonctionne pas avec .*, il se peut que vous ayez un problème de syntaxe dans votre application-insights.json file. Consultez les journaux Application Insights pour voir si vous remarquez des messages d’avertissement.