Configuration des traceurs à l'aide du fichier de configuration de l'agent

Par défaut, Instana ne collecte pas les en-têtes d' HTTP s lorsqu'il trace les appels à HTTP.

Si nécessaire, vous pouvez activer cette fonctionnalité en appliquant la configuration suivante dans le fichier de configuration de l'agent :

com.instana.tracing:
  extra-http-headers:
    - 'x-request-id'
    - 'x-loadtest-id'
    - ...

Les valeurs ne sont pas sensibles à la casse. Les en-têtes enregistrés apparaissent dans les détails de l'appel (dans la section « Détails de l'appel » ). Vous pouvez également utiliser les noms des en-têtes et leurs valeurs pour rechercher des appels et des traces (dans l'interface utilisateur ou via l' API ) ainsi que pour la configuration des services.

Cette fonctionnalité est actuellement soumise aux restrictions suivantes :

• Tous les traceurs enregistrent les en-têtes de requête au niveau des entrées « HTTP » (les appels HTTP s reçus par le processus instrumenté).
• Certains traceurs peuvent enregistrer les en-têtes de réponse lors des requêtes sur HTTP. Pour plus d'informations, voir le tableau 1.
• Certains traceurs peuvent enregistrer les en-têtes de requête et de réponse lors des sorties d' HTTP s (appels HTTP où le processus instrumenté joue le rôle du client). Pour plus d'informations, voir le tableau 1.
• Si un même en-tête apparaît à la fois dans les en-têtes de requête et dans les en-têtes de réponse, il se peut que l'une des deux valeurs ne soit pas enregistrée par l'outil de traçage.

Vous pouvez configurer le format des en-têtes de corrélation de trace d' Kafka, utilisés par les traceurs d' Instana, à l'aide du paramètre com.instana.tracing.kafka.header-format. Les valeurs valides sont binary, string, ou both. Voir l'exemple suivant :

com.instana.tracing:
  kafka:
    header-format: string # possible values: binary, both, string

Vous ne devez pas désactiver complètement la corrélation de trace d' Kafka. com.instana.tracing.kafka.trace-correlation: falseToutefois, si vous devez désactiver complètement la corrélation des traces d' Kafka, définissez alors. Voir l'exemple suivant :

com.instana.tracing:
  kafka:
    trace-correlation: false

header.converter=org.apache.kafka.connect.storage.StringConverter

Pour plus d'informations, consultez la section Migration des en-têtes Kafka.

Vous pouvez désactiver le traçage pour un type de segment spécifique (frameworks, bibliothèques ou instruments) ou pour des groupes entiers de bibliothèques (catégorie de segments). Par exemple, pour exclure complètement le redis paquet du traçage ou désactiver le traçage pour toutes les bibliothèques liées à la journalisation, utilisez l'option disable de configuration.

Pour configurer ce paramètre, définissez les types ou catégories que vous souhaitez désactiver dans la com.instana.tracing.disable section de votre fichier de configuration d'agent, comme le montre l'exemple suivant :

com.instana.tracing:
  disable:
    redis: true         # Disable Redis
    console: false      # Keep console enabled
    logging: true       # Disable the entire logging category

où :

• true: Désactive le traçage pour le type ou la catégorie spécifié(e).
• false: Permet de maintenir explicitement le type ou la catégorie spécifié(e) activé(e).

Dans l'exemple précédent, la configuration désactive toutes les instrumentations de la logging catégorie, à l'exception de console, qui est explicitement activée. De plus, cette configuration exclut également toutes redis les sections associées du traçage. Aucune période n'est enregistrée ni communiquée pour les bibliothèques ou catégories désactivées.

Par défaut, les traceurs d' Instana traitent et propagent les en-têtes tracestate W3C traceparent et afin de permettre la corrélation des traces distribuées. Vous pouvez désactiver la corrélation, la propagation ou les deux à la fois dans « W3C » de manière indépendante à l'aide du fichier de configuration de l'agent.

Vous pouvez configurer la capture de la trace de pile pour les segments de sortie dans l'ensemble de vos services. Par défaut, les traceurs enregistrent les 10 derniers points d'appel pour chaque intervalle de sortie capturé.

Vous pouvez configurer deux aspects de la capture de la trace de pile :

• Longueur de la trace de pile : nombre de points d'appel à capturer.
  • Valeurs prises en charge : 0 à 500
  • Valeur par défaut : 10
• Mode trace de pile : comment les traces de pile sont capturées.
  • Valeurs prises en charge :
    • all: Récupère la trace de pile pour tous les segments de sortie (par défaut).
    • error: Ne recueille la trace de la pile que pour les segments présentant des erreurs.
    • none: Ne recueille pas la trace de la pile.

Pour configurer la capture de la trace de pile, définissez les paramètres dans la com.instana.tracing.global section de votre fichier de configuration d'agent, comme le montre l'exemple suivant :

com.instana.tracing:
  global:
    stack-trace-length: 15
    stack-trace: 'error'

Dans l'exemple précédent, la configuration définit la profondeur de la trace de pile à 15 sites d'appel pour tous les intervalles de sortie et utilise le error mode.

Vous pouvez exclure certains points de terminaison du traçage. Par exemple, si vous utilisez le redis paquet et que vous souhaitez désactiver le suivi des commandes telles que GET, TYPE, ou d'autres, vous pouvez utiliser l'option ignore-endpoints de configuration.

Pour plus d'informations sur les paquets et les traceurs spécifiques prenant en charge cette fonctionnalité, consultez la section « Informations sur la prise en charge ».

Par défaut, Instana ne considère pas les réponses de type « HTTP » 4xx comme des erreurs lors des appels à HTTP. Vous pouvez activer cette fonctionnalité pour surveiller les erreurs côté client, telles que les réponses 403 Forbidden répétées ou 401 Unauthorized .

Les options de configuration suivantes sont disponibles sous com.instana.tracing.http.exit:

• classify-all-4xx-as-errors: Signale toutes les réponses de type « 4xx » comme des erreurs.
• classify-as-errors: Ne signale comme erreurs que les codes d'état « 4xx » spécifiés.

Lorsque ces deux options sont activées, classify-as-errors a la priorité, et seuls les codes répertoriés sont considérés comme des erreurs. Les codes d'état pour classify-as-errors doivent se situer dans l'intervalle 400–499. Tout code ne se situant pas dans cette plage est ignoré.