Noeuds finaux

Modifier en ligne

Les nœuds finaux définissent l'API d'un service et fournissent une vue précise des opérations exposées par les services. Chaque appel à un service se produit sur un seul nœud final. Chaque noeud final possède un seul type reconnu automatiquement: BATCH, SHELL, DATABASE, HTTP, MESSAGING, RPC. Tout comme les services, les noeuds finaux peuvent être visualisés dans la perspective d'une application.

Le nœud final peut être déclaré statiquement ou être basé sur des balises d'appel (par opposition au service, ce qui est généralement déterminé en utilisant des balises d'infrastructure, par exemple, nom SpringBoot). Par exemple, une combinaison de {call.http.method} {call.http.path} serait un nœud final standard d'un service HTTP.

Un autre avantage de définir des points de terminaison distincts pour un service réside dans le fait que, notamment dans le cas des « monolithes », les services peuvent intégrer de nombreux frameworks et technologies différents : API HTTP /REST, accès aux bases de données, intégration de bus de messages, etc. En créant au moins des points de terminaison par type d' API et, le cas échéant, en les subdivisant davantage (par exemple en fonction des détails du protocole), les métriques et les statistiques sont enregistrées pour chaque type d' API.

Instana mappe automatiquement les nœud finaux en fonction des règles par défaut. Pour plus d'informations, voir Mappage de noeud final.

Règles prédéfinies

Modifier en ligne

Instana mappe automatiquement les terminaux en fonction d'un ensemble de règles prédéfinies. Les règles suivantes sont prises en compte dans l'ordre décroissant. Lorsqu'une règle correspond, le noeud final respectif est créé.

Règle Étiquettes
Règle de noeud final personnalisée Balises définies par l'utilisateur (voir Mappage de noeud final personnalisé)
Nom de point de terminaison défini par l'utilisateur via l'en-tête « HTTP » {call.http.header.x-instana-endpoint}
Nom de noeud final défini par l'utilisateur dans les données d'étendue du SDK {call.tag.endpoint}
Nom de l'opération définie par OpenTelemetry {otel.operation}
Jaeger nom de l'opération défini {call.tag.jaeger.operation}
Nom de l'opération définie par Zipkin {call.tag.zipkin.operation}
SOAP En-tête « Action » HTTP {call.http.header.soapaction}
RPC avec les espaces de noms WSDL {call.rpc.method-1}
RPC {call.rpc.method}
GraphQL {call.graphql.operationType?} {call.graphql.operationName?}
Type de quartz de lot à la place du motif hexadécimal {call.batch.jobType}
Type de quartz de lot à la place de l'échéance {call.batch.jobType}
Lot hexadécimal avec préfixe {call.batch.job-1}
Suffixe numérique Batch Quartz {call.batch.job-1}
Travail par lots Spring {call.batch.job-1}
Lot {call.batch.job}
Modèle Prisma {call.database.statement-1}
Rétromigration du modèle Prisma Prisma
Instruction JDBC analysée {call.database.statement-1}
Résultat de l'instruction de procédure mémorisée JDBC {call.database.statement-1}
Instruction analysée Neo4j {call.database.statement-1}
Instruction analysée Cassandra {call.database.statement-1}
Commande Cosmos non-sql {call.database.schema-1}
ElasticSearch Plusieurs index {call.database.schema-1}
ElasticSearch -Index unique {call.database.schema}
Action ElasticSearch {call.database.commandType}
ElasticSearch Divers points de terminaison de l' API Divers points de terminaison de l' API
Collection MongoDB analysée à partir de la requête {call.database.schema-1}.{call.database.statement-2}
La collection MongoDB n'est pas analysable à partir de la requête {call.database.schema-1}
Collection MongoDB analysée à partir de l'espace de nom {call.database.schema}
Table DynamoDB {call.database.schema}
Commande Redis {call.database.statement}
Compartiment AWS S3 {call.database.schema}
AWS S3 fonctionnement Divers points de terminaison de l' API
Compartiment GCS {call.database.schema}
Opération GCS Divers points de terminaison de l' API
Azure Storage Conteneur {call.database.schema}
Azure Storage Fonctionnement Divers points de terminaison de l' API
Opération Memcache / Memcached / EhCache {call.database.commandType}
Compartiment Couchbase {call.database.schema}
Cache de la grille de données {call.database.schema}
Instruction Couchbase analysée {call.database.statement-1}
Instruction Aerospike {call.database.statement}
Base de données IMS avec instruction {call.database.statement}
IMS DB sans instruction base de données IMS
solution de secours pour la base de données {call.database.commandType}
Files d'attente de messagerie temporaire file d'attente temporaire
IBM MQ intervalle à partir d'une adresse {call.messaging.address-1}
IBM ACE intervalle à partir d'une adresse {call.messaging.address-1}
Echange de messagerie par défaut pour AzureQueue {call.messaging.exchangeType}
Apache RocketMQ intervalle à partir d'une adresse {call.messaging.address-1}
Messagerie générique {call.messaging.address}
Echange de messagerie par défaut pour RabbitMQ échange par défaut
Files d'attente de messagerie temporaire file d'attente temporaire
z/OS Se connecter API {call.zcee.apiName}
HTTP avec un modèle de chemin {call.http.method?} /{call.http.pathTemplate-1}
HTTP avec l'identifiant de l'itinéraire {call.http.routeId}
Premier segment de l'URL HTTP après la version API, le cas échéant {call.http.method?} {call.http.path-1}
HTTP Méthode avec chemin d'accès racine {call.http.method} /
HTTP Chemin d'accès {call.http.method?} /
Evénement générique {call.event.source}
Obtenir le nom binaire du shell sans arguments et le nom du script sans arguments {call.shell.command-1} {call.shell.command-2}
Obtenir le nom binaire de l'interpréteur de commandes sans arguments {call.shell.command}
Fonction en tant que service avec le nom et la version {faas.functionname}:{faas.functionversion}
Fonction en tant que service avec un nom uniquement {faas.functionname}
Fonction en tant que service avec identificateur {cloud.id}
SDK.name {call.sdk.name}

Mappage des nœuds finaux

Modifier en ligne

Les nœuds finaux sont automatiquement mappés en fonction de leur type.

Par exemple, Instana regroupe automatiquement les nœuds finaux HTTP basés sur le modèle de chemin, si accessible.

/hospital/1948/patient/291148
/hospital/728/patient/924892
/hospital/47/patient/25978
/hospital/108429/patient/1847

Dans l'exemple précédent, les points de terminaison susmentionnés, qui sont gérés par le même code d'application et présentent donc un profil de performances commun, seront regroupés et présentés ensemble comme suit :

/hospital/{hid}/patient/{pid}

Cette opération s'effectue automatiquement; aucune intervention de l'utilisateur n'est requise pour les frameworks connus.

Lorsque le modèle de chemin n'est pas disponible, les points d'extrémité sont mappés au premier segment de chemin ou peuvent être configurés selon les besoins.

Voici quelques exemples où le modèle de chemin n'est pas disponible:

  • Aucun modèle de chemin n'est utilisé dans le service surveillé.
  • Tracer ne prend pas en charge le modèle de chemin.
  • Traceur n'a pas accès aux informations du modèle de chemin dans certains cas de périphérie, tels que l'échec de l'authentification.
  • Le service de destination n'est pas surveillé et l'étendue d'exit du client ne connaît pas les modèles de chemin.

Si vous écrivez votre propre code de traçage, consultez nos bonnes pratiques en matière de traçage personnalisé pour savoir comment obtenir les mêmes résultats.

Personnalisation du mappage des nœuds finaux

Modifier en ligne

Pour chaque service, Instana permet de disposer d'une configuration qui contrôle la façon dont les nœuds finaux des services sont extraits. Pour accéder à la configuration, accédez à un tableau de bord des services et à l'onglet Nœuds finaux et cliquez sur « Configurer les nœuds finaux ».

Présentation de la mappe de dépendance d'application

Veuillez noter que les configurations de points de terminaison personnalisés ne sont disponibles que pour les services basés sur l' HTTP.

Règles de nœud final personnalisées

Modifier en ligne

Instana est fourni avec trois règles HTTP par défaut qui font toujours partie de la chaîne d'extraction :

  • Framework détecté : extrait les nœuds finaux spécifiés dans le framework détecté (si accessible).
  • / *: extrait les noeuds finaux en fonction du premier paramètre de chemin.
  • Non spécifié: les appels qui ne correspondent pas à une règle précédente sont affectés à ce noeud final.

Pour spécifier une configuration supplémentaire, vous pouvez définir plusieurs règles personnalisées. Pour ce faire, accédez à la boîte de dialogue de configuration des points de terminaison personnalisés depuis n'importe quel service HTTP, puis sélectionnez « Ajouter une règle d' HTTP personnalisée ». La boîte de dialogue qui s'affiche permet de définir un chemin spécifique (la règle) et plusieurs scénarios de test pour vérifier que le chemin défini fonctionne normalement. Pour le chemin, vous pouvez utiliser des segments statiques comme /api ou /myShopEndpoint, des paramètres de chemin tels que /{productId} ou faire correspondre n'importe quel segment avec /*.

Dans la partie de test de règle de la boîte de dialogue, vous pouvez définir plusieurs scénarios de test pour valider les règles. Par exemple, pour une requête /api/*/{version}, le cas de test établit une correspondance avec /api/anyName/123, mais pas avec /otherApi/anyName/123.

Présentation de la mappe de dépendance d'application

Évaluation séquentielle

Modifier en ligne

Les règles sont appliquées dans l'ordre, de la première à la dernière, et les appels sont attribués à la première règle qui correspond. La séquence de changement, il suffit de réorganiser les règles, mais il suffit de les faire glisser et de les déposer. Les règles par défaut d'Instana peuvent être désactivées, mais pas réorganisées.

Présentation de la mappe de dépendance d'application

Nœuds finaux synthétiques

Modifier en ligne

Les nœuds finaux qui reçoivent uniquement du trafic synthétique, tels que des appels à des nœuds finaux de contrôle d'intégrité, peuvent fausser les indicateurs clés de performance de l'application et services. Instana détecte automatiquement ces nœuds finaux et les marque comme étant synthétiques pour les empêcher d'affecter les indicateurs clés de performance de l'application et des services.

Utilisation des nœuds finaux synthétiques dans Instana

Modifier en ligne

Chaque appel déposé sous un nœud final synthétique est marqué comme étant synthétique dans Analyse illimitée et n'est pas inclus dans les indicateurs clés de performance des vues Perspective d'application, Service et Nœud final.

Nœuds finaux synthétiques

Bien que leurs appels ne soient pas incluent dans les indicateurs clés de performance des perspectives d'application et des services, les nœuds finaux synthétiques individuels ont leurs propres tableaux de bord comme leurs homologues non synthétiques.

Noeud final synthétique

Nœuds finaux synthétiques par défaut

Modifier en ligne

Par défaut, les nœuds finaux synthétiques sont identifiés par les modèles d'URL suivants :

Vous pouvez désactiver la règle intégrée et définir des règles personnalisées afin de marquer des points de terminaison supplémentaires comme « synthétiques ». Pour plus d'informations, consultez la documentation relative aux règles personnalisées pour les points de terminaison synthétiques. Pour accéder à la configuration des règles de point de terminaison intégrées et personnalisées, cliquez sur le bouton « Configurer les services » dans la liste des services.

Règles personnalisées des nœuds finaux synthétiques

Modifier en ligne
Remarque : les règles personnalisées s'appliquent globalement dans tous les services.

Pour faciliter la configuration, les nœuds finaux et les services affectés sont affichés.

Configuration des noeuds finaux synthétiques

Appels synthétiques

Modifier en ligne

Vous pouvez non seulement marquer des nœuds finaux entiers comme étant synthétiques, mais également des appels individuels. Cela est particulièrement pratique lorsque vos vérifications synthétiques utilisent des API de « production », ce qui est en général une excellente idée.

Règles d'appel synthétique

Modifier en ligne

Dans Instana, un appel est marqué comme étant synthétique si une ou plusieurs des conditions suivantes sont remplies :

Appels synthétiques dans Analyse illimitée

Modifier en ligne

Les appels synthétiques sont, par défaut, masqués dans Analyse illimitée, car ils ont tendance à être intéressants pour l'analyse des performances uniquement lorsqu'ils fonctionnent très mal. Pour que la requête Analyse illimitée soit également synthétique, vous devez l'accepter via le commutateur Appels masqués-> Appels synthétiques.

Consentement aux appels synthétiques dans Unbounded Analytics

Nœuds finaux non spécifiés

Modifier en ligne

Lorsque les informations sont insuffisantes pour associer automatiquement un appel à un nœud final (par exemple, les nœuds finaux instrumentés manuellement sans fournir de données suffisantes), ces appels sont associés au nœud final spécial « Non spécifié ».

Autres critères d'évaluation

Modifier en ligne

Lorsque trop de nœuds finaux sont détectés sur un service, les appels sont regroupés sous le nœud final « Autres ». Cette mesure de sécurité vise à maintenir l'ensemble des paramètres à une taille raisonnable.

Cela se produit généralement lorsqu'une des règles prédéfinies de Instana ou une règle personnalisée regroupe les appels en un grand nombre de terminaux qui ont chacun reçu un seul appel.

Par exemple, l'une des règles prédéfinies d' Instana consiste à rediriger les appels HTTP vers des points de terminaison dont les noms proviennent du premier segment de chemin trouvé dans le URL. Si ces segments sont générés à partir de valeurs dynamiques (par exemple, "GET /blue-item", "GET /red-item" ...), L'application de cette règle entraînerait un nombre élevé de points de terminaison, ce qui n'est pas utile.

Lorsqu'il s'agit de terminaux gérés par HTTP, il est possible d'améliorer la situation en modifiant la configuration des règles d'extraction des terminaux.

Nœuds finaux de déclenchement internes

Modifier en ligne

Les traces automatiquement capturées par Instana commencent généralement par un appel entrant vers un service. Toutefois, lorsque l'on utilise le SDK d' Instana, il est possible de lancer une trace à partir d'un appel sortant émis par un service. Dans ce cas, Instana crée un appel parent synthétique (associé au nœud final « Déclencheur interne ») vers ce service afin d'améliorer la lisibilité.

Noeud final de déclencheur interne

Carte des flux des points d'extrémité

Modifier en ligne

La mappe de flux de noeuds finaux affiche les noeuds finaux en amont et en aval d'un noeud final.

Limite de la carte des flux des points de terminaison

Modifier en ligne

La mappe de flux de noeuds finaux affiche actuellement des données précises uniquement pour les traces synchrones à exécution courte qui se terminent dans un délai de 20 secondes. Dans tous les autres cas, la mappe de flux de noeud final peut afficher des données inexactes.