Configuration du collecteur « Node.js »

Dans la plupart des cas, vous devez initialiser le collecteur Instana Node.js et require('@instana/collector')(); conserver les options de configuration par défaut.

Ordre de priorité des paramètres

À partir de la version 6, lorsque vous définissez plusieurs configurations, l'ordre de priorité suivant s'applique (du plus élevé au plus faible) :

  1. Variables d'environnement (priorité maximale; elles prévalent sur les autres configurations)
  2. Configuration en code
  3. Configuration de l'agent
  4. Valeurs par défaut
Remarque : le comportement en matière de priorité de configuration diffère dans les versions antérieures à la version 6. Selon l'option de configuration choisie, la configuration de l'agent peut, dans certains cas, prévaloir sur d'autres sources de configuration.

Communication avec l'agent

Vous pouvez configurer le collecteur pour modifier l'hôte et le port de l'agent.

Hôte de l'agent

Le collecteur tente de communiquer avec l'agent Instana via l'adresse IP 127.0.0.1 et via la passerelle par défaut de l'hôte en tant qu'option de secours. Si l'agent n'est pas disponible via l'une de ces adresses IP, indiquez l'option agentHost pour utiliser une adresse IP personnalisée.

require('@instana/collector')({
  agentHost: '::1' // use IPv6 to contact via localhost
});
 

Ou tirez parti d'une variable d'environnement.

require('@instana/collector')({
  agentHost: process.env.HOST_IP
});
 

S'il n'est pas configuré, le collecteur Instana recherche une variable d'environnement appelée INSTANA_AGENT_HOST et utilise ce qui est défini dans cette variable d'environnement pour communiquer avec l'agent. S'il n'existe pas de variable d'environnement de ce type, il va d'abord essayer de contacter l'agent sur localhost, puis sur la passerelle par défaut.

Port de l'agent

Le collecteur tente de communiquer avec l'agent Instana via le port 42699. Si le port a été modifié, vous pouvez utiliser l'option agentPort pour modifier le port.

require('@instana/collector')({
  agentPort: 42699
});
 

S'il n'est pas configuré, le collecteur Instana recherche une variable d'environnement appelée INSTANA_AGENT_PORT et utilise ce qui est défini dans cette variable d'environnement pour communiquer avec l'agent. S'il n'existe pas de variable d'environnement de ce type, il bascule sur le port par défaut 42699.

Kubernetes et Red Hat OpenShift

Si votre application Node.js et l'agent Instana s'exécutent dans un cluster Kubernetes, consultez la documentation relative à l'accès réseau à l'adresse Kubernetes pour obtenir des informations sur la configuration requise dans ce contexte.

Désactivation des événements de fin de ligne (EOL) d' Node.js

Dans les environnements non « serverless » équipés d'un agent Instana, le Tracer d' Node.js déclenche des événements d'incident lorsqu'il détecte que la version d' Node.js en cours d'exécution a atteint sa fin de vie (EOL).

Pour désactiver ces événements EOL, vous pouvez les désactiver à l'aide de la variable d'environnement suivante :

INSTANA_TRACING_DISABLE_EOL_EVENTS=true
 

Pour obtenir la liste complète des versions d' Node.js en fin de vie, consultez la page officielle des versions d' Node.js.

Traçage

Le traçage offre une visibilité de bout en bout sur votre application en enregistrant des informations détaillées sur les requêtes à mesure qu'elles transitent par les différents services et composants.

Le traçage est activé par défaut. Pour désactiver le traçage, que ce soit de manière globale ou sélective, consultez la section consacrée à la désactivation du traçage pour connaître les options de configuration.

Autoriser une section de sortie racine sans section d'entrée

Remarque : cette fonctionnalité est disponible pour la version 4.0 et les versions ultérieures de l'outil de collecte de données « Instana ».

Par défaut, l'outil Tracer de Instana Node.js ne capture que les segments de sortie pour lesquels il existe un segment d'entrée actif. Vous pouvez activer cette fonction pour permettre au traceur de tracer des travées de sortie autonomes.

Pour activer cette fonction, utilisez l'une des options suivantes :

  • Définissez la variable INSTANA_ALLOW_ROOT_EXIT_SPAN d'environnement.

  • Configurer la fonction par le biais de la fonction d'initialisation du traceur :

    require('@instana/collector')({
    tracing: {
      allowRootExitSpan: true
    }
    });
     

Si INSTANA_ALLOW_ROOT_EXIT_SPAN est configuré sur 1 ou true, ou si allowRootExitSpan est défini sur true, le traceur capture les segments de sortie même en l'absence de segment d'entrée actif.

Cette fonctionnalité est utile dans les cas suivants, où les tâches sont déclenchées par un mécanisme qui n'est pas pris en charge par l'instrumentation automatique d' Instana :

  • Messages entrants provenant de bibliothèques de messagerie non prises en charge
  • Les requêtes effectuées via des protocoles non pris en charge, tels que le protocole « raw » Transmission Control Protocol ( TCP ) ou WebSocket
  • Les tâches planifiées qui sont lancées en interne par l'application en utilisant des mécanismes tels que " setTimeout, " setInterval ou des bibliothèques de planification Node.js non prises en charge

Ignorer les points de terminaison

À partir de l'outil de traçage d' Node.js ( Tracer 4.9.0 ), vous pouvez réduire l'ingestion de données superflues en excluant certaines traces ou certains appels. Ce mécanisme de filtrage affine la collecte de vos traces. Pour désactiver les traces, définissez ces paramètres dans les paramètres de configuration de Tracer de l' Node.js :

  • Technologie : Indiquez la technologie concernée, par exemple, Kafka, Redis DynamoDB, ou HTTP.
  • Méthode : Identifiez la méthode à exclure. Par exemple, excluez ces méthodes pour les technologies suivantes :
    • Kafka: send, consume
    • Redis: get, type
    • DynamoDB: query, scan
    • HTTP: get, post
  • Terminal (le cas échéant) : affinez davantage le filtrage en fonction de terminaux spécifiques. Par exemple, les points de terminaison pour les technologies suivantes sont définis comme suit :
    • Kafka: Le point de terminaison correspond au nom du sujet.
    • HTTP: Le point de terminaison correspond au chemin d'accès URL.
  • Connexion (facultatif) : exclure les traces d'une connexion spécifique. Par exemple, la connexion pour les technologies suivantes est définie comme suit :
    • Redis: La connexion correspond à la chaîne de connexion.
    • HTTP: La connexion comprend l'hôte et le port.
Restriction :

La fonctionnalité permettant d'ignorer des points de terminaison est soumise aux restrictions suivantes :

  • Cette fonctionnalité est actuellement disponible pour Redis, DynamoDB,, Kafka et HTTP. Cependant, seuls Kafka et HTTP prennent en charge le filtrage à la fois par méthode et par point de terminaison.
  • La bibliothèque ` Kafka.js ` prend en charge la méthode ` sendBatch `, qui permet d'envoyer des messages à plusieurs sujets à la fois. Lorsque vous filtrez les traces en utilisant à la fois la méthode et le point de terminaison, indiquez tous les points de terminaison (sujets) concernés dans la configuration. Si un sujet est omis, le traçage n'est pas ignoré.
  • Le filtrage des connexions n'est actuellement pris en charge que pour Redis et HTTP.
  • Le filtrage des appels d'entrée de type « HTTP » est actuellement pris en charge.

Règles de filtrage

Les règles de filtrage des traces sont les suivantes :

  • Lorsqu'une trace est ignorée, toutes les traces suivantes en aval sont également ignorées.
  • Utilisez * pour ignorer tous les points de terminaison, toutes les méthodes ou toutes les connexions.
  • Les valeurs des points de terminaison (telles que les noms de sujets d' Kafka ) restent cohérentes d'un service à l'autre.
  • Les noms des méthodes peuvent varier en fonction du langage de programmation et de la technologie utilisés. Consultez l'interface utilisateur d' Instana pour déterminer la méthode et le point de terminaison appropriés pour votre service.

La capture d'écran suivante de l'interface utilisateur d' Instana fournit une référence visuelle permettant d'identifier la méthode et le point de terminaison appropriés pour la configuration :

Méthodes et paramètres d'évaluation dans l'interface utilisateur

Options de configuration

Vous pouvez activer l'exclusion des points de terminaison en utilisant l'une des options suivantes :

  • Variables d'environnement
  • Configuration en code
  • Configuration de l'agent
Variables d'environnement

Vous pouvez configurer les points de terminaison à ignorer en utilisant les variables d'environnement suivantes pour filtrer les points de terminaison par service :

  • INSTANA_IGNORE_ENDPOINTS_PATH
  • INSTANA_IGNORE_ENDPOINTS
INSTANA_IGNORE_ENDPOINTS_PATH

Grâce à cette variable d'environnement, vous pouvez configurer le filtrage via un fichier d' YAML s externe, comme le montre l'exemple suivant :

INSTANA_IGNORE_ENDPOINTS_PATH=/absolute/path/to/config.yaml
 

Dans l'exemple précédent, le config.yaml fichier doit comporter un chemin d'accès absolu et respecter la structure de configuration indiquée.

L'exemple suivant illustre le filtrage par méthode :

tracing:
  ignore-endpoints:
    redis:
      - get
      - type
    dynamodb:
      - query
    kafka:
      - send 
    http:
      - get
 

Cette configuration filtre les traces suivantes :

  • GET et TYPE les commandes pour Redis
  • QUERY commande pour DynamoDB
  • SEND méthode pour Kafka et toutes les traces en aval
  • GET méthode pour HTTP et toutes les traces en aval

L'exemple suivant illustre le filtrage par méthode, point de terminaison et connexion :

tracing:
  ignore-endpoints:
    kafka: 
      - methods: ["consume"]
        endpoints: ["topic1", "topic2"]

      - methods: ["consume", "send"]
        endpoints: ["topic3"]

      - methods: ["*"] # Applied to all methods
        endpoints: ["topic4"]

      - methods: ["consume"]
        endpoints: ["*"] # Applied to all endpoints

    http:
      - methods: ["get"]
        endpoints: ["/status"]

      - methods: ["get", "post"]
        endpoints: ["/status", "/v1/status"]

      - methods: ["*"]
        connection: ["localhost:3000"]

    redis:
      - methods: ['get']
        connections: ['192.168.0.1:9191']
 

Cette configuration filtre les traces suivantes :

  • CONSUME méthode pour topic1 et topic2 dans Kafka et toutes les traces en aval
  • CONSUME et SEND les méthodes pour topic3 dans Kafka et toutes les traces en aval
  • Toutes les méthodes (*) pour topic4 dans Kafka et toutes les traces en aval
  • CONSUME méthode pour tous les sujets (*) dans Kafka et toutes les traces en aval
  • GET méthode vers l' URL/status dans HTTP et toutes les traces en aval
  • GET et POST les méthodes aux URL /status , ainsi que /v1/statusHTTP dans toutes les traces en aval
  • Toutes les méthodes de connexion (*) localhost:3000 et toutes les traces en aval
  • GET méthode à l'établissement de la connexion 192.168.0.1:9191 pour Redis

Vous pouvez combiner les deux options de filtrage (méthode uniquement et méthode et point de terminaison) dans le même fichier de configuration.

Cette configuration est compatible avec la structure d' configuration.yaml de l'agent.

INSTANA_IGNORE_ENDPOINTS

Grâce à cette variable d'environnement, vous pouvez exclure des traces en vous basant uniquement sur les noms des méthodes.

INSTANA_IGNORE_ENDPOINTS=redis:get,type
 

Cette configuration exclut les GET commandes TYPE et du redis paquet de la journalisation.

Pour configurer des exclusions pour plusieurs paquets, utilisez les configurations indiquées dans l'exemple suivant.

INSTANA_IGNORE_ENDPOINTS=redis:get,type;dynamodb:query,scan;kafka:send;http:get
 

Cette configuration filtre les traces suivantes :

  • GET et TYPE les commandes dans Redis
  • QUERY et SCAN les commandes dans DynamoDB
  • SEND méthode dans Kafka
  • GET méthode dans HTTP
Configuration en code

Vous pouvez configurer les points de terminaison à ignorer en utilisant la configuration intégrée au code pour filtrer les points de terminaison par service.

L'exemple suivant illustre le filtrage par méthode :

require('@instana/collector')({
  tracing: {
    ignoreEndpoints: {
      redis: ['get', 'type'],
      dynamodb: ['query', 'scan'],
      kafka: ['send'],
      http: ['get']
    }
  }
});
 

Cette configuration filtre les traces suivantes :

  • GET et TYPE les commandes dans Redis
  • QUERY et SCAN les commandes dans DynamoDB
  • SEND méthode dans Kafka et toutes les traces en aval
  • GET méthode dans HTTP et toutes les traces en aval

L'exemple suivant illustre le filtrage par méthode et par point de terminaison :

require('@instana/collector')({
  tracing: {
    ignoreEndpoints: {
      kafka: [
        { methods: ['consume'], endpoints: ['topic1', 'topic2'] },
        { methods: ['send'], endpoints: ['topic3'] }
      ],
      http: [
        {
          methods: ['get'], endpoints: ['/status']
        }
      ]
    }
  }
});
 

Cette configuration filtre les traces suivantes :

  • CONSUME méthode pour topic1 et topic2 dans Kafka et toutes les traces en aval
  • SEND méthode pour topic3 dans Kafka et toutes les traces en aval
  • GET méthode vers l' URL/status dans HTTP et toutes les traces en aval

Vous pouvez utiliser les deux options de filtrage (méthode uniquement et méthode et point de terminaison) dans la même configuration.

Configuration de l'agent

Vous pouvez également ignorer de manière centralisée les points de terminaison de tous vos services en les configurant via l'agent. Veillez toutefois à bien prendre connaissance des règles applicables avant de poursuivre. Pour plus d'informations, consultez la section « Ignorer des terminaux à l'aide de l'agent ».

Désactiver le traçage

Remarque : ces instructions s'appliquent à Node.js Tracer 4.17.0 et aux versions ultérieures.

Pour désactiver le traçage, vous pouvez soit le désactiver complètement, soit exclure de manière sélective certaines instrumentations ou des groupes entiers, tels que les bases de données, la messagerie ou la journalisation. Cette flexibilité vous permet d'ajuster le traçage en fonction des besoins de votre application.

Pour appliquer la configuration permettant de désactiver le traçage, utilisez l'une des méthodes suivantes :

  • Variables d'environnement
  • Configuration en code
  • Configuration de l'agent ( YAML )

Désactiver tout le traçage

La désactivation du traçage empêche totalement le traçage d' Instana s de collecter ou de signaler des segments. Cette approche peut s'avérer utile dans certains cas, par exemple pour le débogage, les tests ou lorsque le traçage n'est temporairement pas nécessaire.

Lorsque le traçage est désactivé, ni l'instrumentation automatique ni le SDK de traçage ne sont actifs. Tous les appels au SDK sont ignorés sans générer d'erreurs ni de segments.

Pour désactiver tout le traçage, utilisez l'une des méthodes suivantes :

  • Variable d'environnement : définissez les variables d'environnement INSTANA_TRACING_DISABLE sur true.

    INSTANA_TRACING_DISABLE=true
     
  • Configuration dans le code : passez l'option suivante lors de l'initialisation du traceur :

    require('@instana/collector')({
    tracing: {
      disable: true
    }
    });
     

Désactivation de certains instruments

Utilisez l'option suivante pour désactiver le traçage pour des instrumentations spécifiques ou pour un paquet en particulier. Pour trouver les noms appropriés, consultez les Instrumentation identifier valeurs répertoriées dans la section « Bibliothèques prises en charge ».

Pour désactiver certaines instrumentations, utilisez l'une des méthodes suivantes :

  • Variable d'environnement : définissez la variable INSTANA_TRACING_DISABLE_INSTRUMENTATIONS d'environnement comme indiqué dans l'exemple suivant :

    INSTANA_TRACING_DISABLE_INSTRUMENTATIONS=redis,graphql
     

    Dans cet exemple, le traçage est désactivé pour redis et graphql avec cette configuration. Aucune portée n'est enregistrée ni communiquée pour ces deux instruments.

  • Configuration dans le code : passez l'option suivante lors de l'initialisation du traceur :

    require('@instana/collector')({
    tracing: {
      disable: {
        instrumentations: ['redis', 'graphql']
      }
    }
    });
     

Désactivation des groupes d'instrumentation

Vous pouvez désactiver des catégories entières d'instruments associés en indiquant des noms de groupes. Cette approche est utile lorsque vous souhaitez désactiver le traçage pour un ensemble plus large de bibliothèques à l'aide d'une seule configuration.

La désactivation au niveau du groupe est actuellement limitée aux catégories suivantes :

Pour désactiver certains groupes d'instrumentation, utilisez l'une des méthodes suivantes :

  • Variable d'environnement : définissez la variable INSTANA_TRACING_DISABLE_GROUPS d'environnement comme indiqué dans l'exemple suivant :

    INSTANA_TRACING_DISABLE_GROUPS=logging,database
     

    Dans cet exemple, toutes les instrumentations des groupes logging databases et sont désactivées avec cette configuration. Aucune donnée de portée n'est collectée ni communiquée pour les instruments appartenant à ces groupes.

  • Configuration dans le code : passez l'option suivante lors de l'initialisation du traceur :

    require('@instana/collector')({
    tracing: {
      disable: {
        groups: ['logging', 'database']
      }
    }
    });
     

Désactivation du traçage via la configuration de l'agent

Vous pouvez également désactiver globalement les instrumentations ou les groupes pour tous vos services en les configurant via l'agent. Pour plus d'informations, consultez la section « Désactivation du traçage ».

Désactiver le traçage à l'aide d'une liste plate unique

Avec le format de liste plate, vous pouvez désactiver plusieurs instrumentations ou groupes en utilisant une liste séparée par des virgules.

Remarque : cette méthode est prise en charge, mais n'est pas recommandée en raison de son manque de structure.

Pour désactiver le traçage sous forme de liste plate unique, utilisez l'une des méthodes suivantes :

  • Variable d'environnement : définissez la variable d'environnement INSTANA_TRACING_DISABLE comme indiqué dans l'exemple suivant :

    INSTANA_TRACING_DISABLE=redis,graphql,logging,database
     

    Dans cet exemple, le traçage est désactivé tant pour les instrumentations individuelles (redis et graphql) que pour les groupes entiers (logging et database). Aucune plage n'est enregistrée pour aucune des entrées spécifiées.

  • Configuration dans le code : passez l'option suivante lors de l'initialisation du traceur :

    require('@instana/collector')({
    tracing: {
      disable: ['redis', 'graphql', 'logging', 'database']
    }
    });
     

Désactivation du traçage automatique

Le traçage automatique est également activé par défaut. Pour désactiver uniquement le traçage automatique (en laissant le traçage manuel activé avec le kit SDK ou openTraing), indiquez l'option suivante dans la fonction d'initialisation :

require('@instana/collector')({
  tracing: {
    automaticTracingEnabled: false
  }
});
 

Enfin, vous pouvez désactiver le traçage automatique en définissant la variable d'environnement INSTANA_DISABLE_AUTO_INSTR=true.

Lorsque le traçage automatique est désactivé, vous pouvez toujours utiliser le kit SDK ou l'API OpenTracing pour créer des étendues manuellement.

Désactivation de l'intégration d' OpenTelemetry

L'intégration d'Opentelemetry est activée par défaut. Pour désactiver l'intégration, transmettez l'option suivante à la fonction d'initialisation:

require('@instana/collector')({
  tracing: {
    useOpentelemetry: false
  }
});
 

De plus, vous pouvez désactiver l'intégration d' OpenTelemetry en définissant la variable INSTANA_DISABLE_USE_OPENTELEMETRY sur true. Pour plus d'informations, consultez la section « Variables d'environnement » sur Instana.

Désactivation du traçage des threads de travail

Pour empêcher le collecteur Instana Node.js de tracer les threads de travail, définissez la variable d'environnement suivante :

INSTANA_DISABLE_WORKER_THREADS=true

Cette configuration désactive le traçage pour tous les threads de travail, mais le processus principal continue d'être tracé automatiquement. Utilisez cette configuration lorsque les threads de travail exécutent des tâches internes ou en arrière-plan que vous souhaitez exclure du traçage.

Capture des traces de pile

Par défaut, le collecteur enregistre les 10 derniers points d'appel pour chaque intervalle de sortie capturé. Cette valeur peut être augmentée ou diminuée selon vos besoins.

Remarque : les traces de pile ne sont pas collectées pour les intervalles d'entrée d' HTTP, car ceux-ci ne contiennent que des appels internes au cœur d' Node.js et ne fournissent aucune information utile au niveau de l'application.

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 acceptées : 0 à 500
    • Valeur par défaut : 10
  • Mode de trace de pile : comment les traces de pile sont-elles capturées?
    • Valeurs prises en charge :
      • all: Récupère la trace de pile pour tous les segments de sortie (par défaut).
        # Captures stack trace for all spans.
        INSTANA_STACK_TRACE=all
      • error: Ne recueille la trace de la pile que pour les segments présentant des erreurs.
        # Captures stack trace only for erroneous spans.
        INSTANA_STACK_TRACE=error
      • none: Ne recueille pas la trace de la pile.
        # Disable collection of stack trace.
        INSTANA_STACK_TRACE=none

Vous pouvez configurer la capture de la trace de pile en utilisant l'une des options suivantes :

  • Variables d'environnement
  • Configuration en code
  • Configuration de l'agent

Configuration de la longueur de la trace de pile

Vous pouvez ajuster le nombre de points d'appel enregistrés dans les traces de pile en configurant la longueur de la trace de pile. Pour configurer la longueur de la trace de pile, utilisez l'une des méthodes suivantes :

  • Variable d'environnement : définissez la variable d'environnement INSTANA_STACK_TRACE_LENGTH comme indiqué dans l'exemple suivant :
    INSTANA_STACK_TRACE_LENGTH=15
  • Configuration dans le code : passez l'option suivante lors de l'initialisation du traceur :
    require('@instana/collector')({
      tracing: {
        global: {
          stackTraceLength: 15
        }
      }
    });
  • Configuration de l'agent : voir « Configuration via l'agent ».

Configuration du mode de trace de pile

Vous pouvez définir les situations dans lesquelles les traces de pile sont enregistrées en configurant le mode de trace de pile.

Pour configurer le mode de trace de pile, utilisez l'une des méthodes suivantes :

  • Variable d'environnement : définissez la variable d'environnement INSTANA_STACK_TRACE comme indiqué dans l'exemple suivant :
    INSTANA_STACK_TRACE='error'
  • Configuration dans le code : passez l'option suivante lors de l'initialisation du traceur :
    require('@instana/collector')({
      tracing: {
        global: {
          stackTrace: 'none'
        }
      }
    });
  • Configuration de l'agent : voir « Configuration via l'agent ».

Configuration d'un chemin d'accès personnalisé à l' package.json

Le collecteur « Instana » tente de localiser le fichier package.json principal de votre projet afin d'en extraire des informations importantes, telles que le nom de votre application. Si vous devez définir un chemin personnalisé pour votre fichier package.json ou si le collecteur ne parvient pas à localiser le fichier, vous pouvez utiliser l'option de configuration nommée packageJsonPath.

require('@instana/collector')({
  packageJsonPath: 'absolute/path/to/package.json'
});
 

Vous pouvez également configurer le chemin du fichier package.json en définissant la variable d'environnement INSTANA_PACKAGE_JSON_PATH .

Nom du service

Les services sont un concept central dans Instana. Les appels, les étendues et les traces sont étroitement associés aux services. Par défaut, le collecteur Node.js utilise les attributs name et version à partir du fichier principal package.json. Pour personnaliser le nom du service, vous pouvez configurer la propriété serviceName.

require('@instana/collector')({
  serviceName: 'shop'
});
 

Vous pouvez également configurer un nom de service personnalisé en définissant la variable d'environnement INSTANA_SERVICE_NAME. Pour plus d'informations sur la configuration d'un service personnalisé, consultez la section « Définition du nom du service au niveau global ».

Kafka en-têtes de corrélation de trace

À partir de la version 4.x du collecteur, les en-têtes de corrélation de la trace Kafka sont toujours envoyés dans le format " string, ce qui élimine le support du format " binary. Pour plus d'informations, voir Migration des en-têtesKafka.

Supprimer toutes les configurations qui font référence à la variable d'environnement " INSTANA_KAFKA_HEADER_FORMAT et à l'option de configuration " tracing: { kafka: { headerFormat: .... }}}.

Définition du nom de processus

Utilisez la variable d'environnement INSTANA_PROCESS_NAME pour définir un libellé personnalisé pour l'entité d'infrastructure qui représente le processus Node.js.

Signalement des rejets de promesses non gérés

Le collecteur Instana Node.js peut signaler les rejets de promesses non gérés sous forme de tickets à l'adresse Instana. Un rejet de promesse non géré est une promesse qui est rejetée mais pour laquelle aucun gestionnaire de rejet n'a été défini (c'est-à-dire que la chaîne de promesses ne comporte pas de .catch(...)).

Par défaut, cette fonction est désactivée. Si elle est activée et qu'un rejet de promesse non géré est détecté, cela est signalé comme un problème de gravité "avertissement" à Instana.

Notez que l'appel qui est en cours au moment du rejet de la promesse n'est pas marqué comme une erreur due au rejet non géré. La raison en est double :

  1. Les rejets non gérés n'entraînent pas d'erreur dans l'environnement d'exécution Node.js. Même si des rejets non gérés se produisent lors du traitement d'une demande, la demande peut toujours être traitée avec succès.
  2. L'environnement d'exécution Node.js ne permet pas de détecter les rejets non gérés dans le cadre d'appels spécifiques. En fait, les rejets non gérés ne sont détectés que plus tard, lorsque la promesse concernée est sur le point d'être nettoyée de la mémoire. A ce stade, la demande qui a déclenché le rejet non géré est déjà terminée et traitée.

Cette fonction peut être activée avec l'option reportUnhandledPromiseRejections, comme suit :

require('@instana/collector')({
  reportUnhandledPromiseRejections: true
});
 

À partir de la version Node.js 12.0.0, un paramètre de ligne de commande --unhandled-rejections permet de contrôler la manière dont les rejets de promesses non gérés sont traités. La génération de rapports sur les rejets non gérés n'est pas prise en charge avec --unhandled-rejections=strict, car dans ce mode, Node.js convertit les rejets non gérés en exceptions non interceptées.

Journalisation

Pour modifier la configuration par défaut de la journalisation, consultez les sections suivantes :

Configuration du niveau de journalisation

Si vous souhaitez modifier le niveau de journalisation par défaut, vous pouvez le configurer via :

require('@instana/collector')({
  level: 'debug'
});
 

Vous pouvez également configurer le niveau de consignation en affectant à la variable d'environnement INSTANA_LOG_LEVEL la valeur debug, info, warn ou error. Enfin, la définition de INSTANA_DEBUG avec une chaîne non vide va définir le niveau de journalisation sur debug.

Notez que le niveau de journalisation par défaut est info. Si vous constatez la présence de journaux de débogage inattendus liés à Instana (lignes de journal contenant "name":"@instana/collector" et "level":20), vérifiez si vous avez défini le niveau de journalisation sur « debug » dans votre configuration ou si INSTANA_LOG_LEVEL=debug ou INSTANA_DEBUG est activé. Si vous fournissez votre propre consignateur (voir ci-dessous), vous êtes responsable de la définition du niveau de journalisation sur ce consignateur comme vous le souhaitez.

AutoProfile

Depuis la version 1.98.1. Requiert au moins la version 6.4.0 de Node.js

Cette fonction est actuellement en phase de test de l'aperçu public.

Pour activer l'option « autoProfile: trueAutoProfile », ajoutez-la lors de l'initialisation du collecteur.

require('@instana/collector')({
  autoProfile: true
});
 

Vous pouvez également activer l'option « AutoProfile » en définissant la variable d'environnement INSTANA_AUTO_PROFILE sur true

Agrégation automatique des appels de sortie courts

Depuis : 1.108.0.

Le traceur « Node.js » prend en charge l'agrégation automatique des appels de base de données très courts (< 10 ms) et à haute fréquence. Cela permet de conserver une valeur minimale de surcharge des performances de traçage dans les scénarios où des appels de ce type sont exécutés en succession rapide. A l'heure actuelle, cette fonction est incluse et doit être activée de façon explicite. Elle deviendra le comportement par défaut dans l'une des versions suivantes.

Pour l'activer immédiatement, utilisez l'une des méthodes suivantes :

  • Définissez la variable d'environnement INSTANA_SPANBATCHING_ENABLED=true.
  • Utiliser la configuration dans le code :
    require('@instana/collector')({
      tracing: {
        spanBatchingEnabled: true
      }
    });
     
  • Ajouter le contenu suivant à l'agent configuration.yaml :
    com.instana.plugin.nodejs:
      span-batching-enabled: true
     

Notez que ces options de configuration seront ignorées lorsque ce comportement sera défini par défaut.

En raison du mode de fonctionnement de cette fonction, il est possible que l'activation de cette option ait un impact sur l'extraction des noeuds finaux, en modifiant le nombre d'appels vers des noeuds finaux de base de données à faible temps d'attente.

Délai de transmission des données

Vous pouvez configurer la fréquence à laquelle les métriques sont transmises du collecteur Node.js vers l'agent Instana à l'aide de la variable INSTANA_METRICS_TRANSMISSION_DELAY d'environnement ou de l'option config.metrics.transmissionDelay de configuration.

Valeur par défaut : 1 000 millisecondes (1 seconde)

Valeur maximale : 5 000 millisecondes (5 secondes)

Cette valeur est exprimée en millisecondes. Vous pouvez configurer le délai de transmission afin d'ajuster la fréquence des mises à jour des métriques. Augmentez le délai pour réduire la fréquence de mise à jour. Cette approche s'avère utile dans les situations de forte charge et permet de réduire au minimum le trafic réseau et les coûts liés à l'ingestion des données.

Vous pouvez configurer le délai de transmission des métriques en utilisant l'une des méthodes suivantes :

  • Définissez la variable d'environnement INSTANA_METRICS_TRANSMISSION_DELAY (valeur en millisecondes) :
    INSTANA_METRICS_TRANSMISSION_DELAY=5000
  • Utiliser la configuration dans le code (valeur en millisecondes) :
    require('@instana/collector')({
      metrics: {
        transmissionDelay: 5000
      }
    });

Dans les exemples précédents, le système transmet les métriques toutes les 5 000 millisecondes (5 secondes) au lieu des 1 000 millisecondes (1 seconde) par défaut.

Désactiver le recours aux modules complémentaires natifs précompilés

Si les dépendances facultatives du module complémentaire natif ne sont pas installées correctement, le package @instana/collector tente automatiquement d'utiliser les fichiers binaires préconfigurés qui correspondent au système d'exploitation, à la version Node.js et à la variante libc . Vous pouvez désactiver l'utilisation des prégénérations en définissant INSTANA_COPY_PRECOMPILED_NATIVE_ADDONS=false.

Référence de configuration complète

Voici toutes les valeurs de configuration possibles, avec leurs valeurs par défaut :

{
  agentHost: '127.0.0.1',
  agentPort: 42699,
  serviceName: null,
  packageJsonPath: null,
  // the log level:
  level: 'info',
  tracing: {
    enabled: true,
    automaticTracingEnabled: true,
    // Spans are batched and sent to the agent once every second, or if ${forceTransmissionStartingAt} spans have been collected (whichever happens earlier)
    forceTransmissionStartingAt: 500,
    // If more than ${maxBufferedSpans} have been buffered and the collector has not been able to send them to the agent, it will start to drop spans to avoid causing memory issues.
    maxBufferedSpans: 1000,
    http: {
      // This is usually configured at the agent level (configuration.yaml).
      extraHttpHeadersToCapture: []
    },
    // How many stack trace frames are to be captured. Can also be 0 to disable collecting stack traces.
    stackTraceLength: 10,
    // To disable individual tracing plug-ins.
    disabledTracers: [],
     // Can also be configured at the agent level (configuration.yaml).
    spanBatchingEnabled: false
  },
  metrics: {
    timeBetweenHealthcheckCalls: 3000,
    transmissionDelay: 1000
  },
  // This is usually configured at the agent level (configuration.yaml).
  secrets: {
    matcherMode: 'contains-ignore-case',
    keywords: ['key', 'pass', 'secret']
  },
  autoProfile: false
}
 

Voici la liste de toutes les variables d'environnement prises en charge par le collecteur Node.js :

Variable d'environnement Option de configuration équivalente
INSTANA_AGENT_HOST config.agentHost
INSTANA_AGENT_PORT config.agentPort
INSTANA_SERVICE_NAME config.serviceName
INSTANA_PACKAGE_JSON_PATH config.packageJsonPath
INSTANA_PROCESS_NAME
INSTANA_DISABLE_AUTO_INSTR=true config.tracing.automaticTracingEnabled = false
INSTANA_TRACING_DISABLE config.tracing.disable
INSTANA_STACK_TRACE_LENGTH config.tracing.global.stackTraceLength
INSTANA_STACK_TRACE config.tracing.global.stackTrace (all,error,none)
INSTANA_LOG_LEVEL config.level
INSTANA_DEBUG config.level = debug
INSTANA_AUTO_PROFILE=true config.autoProfile = true
INSTANA_SPANBATCHING_ENABLED=true config.tracing.spanBatchingEnabled = true
INSTANA_TRACE_IMMEDIATELY=true config.tracing.activateImmediately = true
INSTANA_COPY_PRECOMPILED_NATIVE_ADDONS
INSTANA_ALLOW_ROOT_EXIT_SPAN config.tracing.allowRootExitSpan = true
INSTANA_IGNORE_ENDPOINTS config.tracing.ignoreEndpoints
INSTANA_METRICS_TRANSMISSION_DELAY config.metrics.transmissionDelay