services

1. Dans la barre latérale, cliquez sur « Applications » et sélectionnez l'onglet « Services ».
2. Cliquez sur Configurer les services
3. Cliquez sur Ajouter une règle de service personnalisé.
4. Dans la liste déroulante, sélectionnez les balises.

Les règles de service personnalisées, tout comme les règles prédéfinies, sont prises en compte par ordre décroissant de priorité pour chaque appel. Le nom de service attribué à un appel est déterminé en fonction de la règle de priorité la plus élevée qui correspond.

L'une des raisons pour lesquelles vous utilisez une règle de service personnalisé est l'utilisation des méta-informations existantes de vos composants d'infrastructure. Par exemple, si vous libellez vos conteneurs Docker avec des informations spécifiques au domaine, telles que com.acme.service-name:myservice, pour mapper des services à partir de ce libellé, sélectionnez les balises docker.label et com.acme.service-name . Tous les appels qui passent un conteneur avec le libellé com.acme.service-name sont associés à un service, qui est nommé par cette valeur, par exemple, myservice. Il existe plusieurs balises pour créer un mappage de service personnalisé.

Vous pouvez également ajouter plusieurs clés pour le mappage de service. Plusieurs balises sont concaténées avec un tiret. Notez que toutes les clés doivent correspondre. Par exemple, si vous souhaitez séparer vos services de préproduction en fonction de la zone d'hôte, vous pouvez ajouter deux clés : host.zone + docker.label:com.acme.service-name. Vos services seront alors nommés en concaténant les valeurs de la zone d'hôte, suivies de l'étiquette « docker ». Ainsi, vous séparerez les deux services, par exemple prod-myservice et dev-myservice.

A l'aide d'une balise spéciale service.default_name, une règle de service personnalisée peut également être utilisée pour étendre les règles de service par défaut avec d'autres balises. Par exemple, pour fractionner les services créés automatiquement par des zones d'hôte, créez la règle de service personnalisé à l'aide des balises service.default_name et host.zone.

Vous pouvez définir un nom de service pour tous les appels associés à un service. Le nom du service ne peut être défini que pour les processus surveillés par un traceur Instana.

Pour définir le nom de service de tous les appels entrants et sortants d'un service, définissez la variable d'environnement INSTANA_SERVICE_NAME sur le processus.

Lorsque vous définissez le nom du service, le nom du processus n'est pas modifié. Pour renommer le processus, utilisez la variable d'environnement INSTANA_PROCESS_NAME .

Vous pouvez définir un nom de service global pour les traceurs suivants à l'aide de la configuration dans le code:

• Go
• Node.js
• PHP
• Haskell

Pour plus d'informations sur les variables d'environnement prises en charge par Instana, consultez la section Variables d'environnement.

Vous pouvez définir un nom de service pour chaque appel. Lorsque vous modifiez le nom de service d'un appel, le service source ou de destination de l'intervalle d'entrée ou de sortie cible est modifié.

Pour modifier le nom de service d'un appel, ajoutez une balise personnalisée (custom.tags.service) à la plage cible. Choisissez l'un des SDK de traceur cible suivants:

• Java
• .NET
• Python
• Ruby
• PHP
• Go
• Node.js
• Haskell

Pour définir un nom de service dans OpenTelemtry ou OpenTracing, utilisez la fonction setTag.

Exemple:span.setTag('service', 'my-service')

En définissant l'en-tête « X-Instana-ServiceHTTP » lors d'un appel, la destination (le service qui reçoit la requête HTTP ) est associée à la valeur fournie dans cet en-tête.

Les appels vers un service non surveillé par Instana sont redirigés vers un service à l'aide de balises d'appel.

Par exemple, les requêtes HTTP adressées à un site tiers API, tel que [ www.google.com ...], sont redirigées vers le service [...] www.google.com , en fonction de host l'en-tête HTTP (call.http.host balise). Les appels vers www.google.fr ou www.google.de sont redirigés vers des services différents, car les en-têtes host HTTP sont différents.

Vous pouvez mapper tous les appels à différents domaines vers un service nommé "Google" en ajoutant la configuration de service manuelle suivante:

{
    "tagFilterExpression": {
        "type": "TAG_FILTER",
        "name": "call.http.host",
        "value": "www.google.",
        "operator": "STARTS_WITH",
        "entity": "NOT_APPLICABLE"
    },
    "unmonitoredServiceName": "Google",
    "description": "Map calls to different google domains to Google service",
    "enabled": true
}
 

Si une base de données ou un système de messagerie est surveillé par Instana, les appels vers cette base de données ou ce système de messagerie doivent être mappés à un service en fonction de la balise d'infrastructure (par exemple MySQL@3306 on demo-host) grâce à la corrélation des infrastructures. Mais il arrive parfois que, en raison de la présence d'un proxy ou d'un équilibreur de charge, la corrélation au niveau de l'infrastructure ne fonctionne pas, car Instana ne surveille ni n'instrumentalise ce composant et ne sait pas comment les requêtes sont acheminées. Par conséquent, les appels seront mappés à un service basé sur les balises d'appel (par exemple, call.database.schema, call.database.connection ou call.messaging.address) comme si le service de destination n'était pas surveillé.

Dans ce cas, vous trouverez un autre service créé à partir de l'entité d'infrastructure sans appel. Vous pouvez utiliser la configuration de service manuelle suivante pour mapper des appels à ce service existant:

{
    "tagFilterExpression": {
        "type": "TAG_FILTER",
        "name": "call.database.connection",
        "value": "jdbc:mysql://10.128.0.1:3306",
        "operator": "CONTAINS",
        "entity": "NOT_APPLICABLE"
    },
    "existingServiceId": "a880d1875389b78b49b19387ef7ab815b313764f", // service id of "MySQL@3306 on demo-host" service, can be found in the "serviceId" url parameter of the service dashboard
    "description": "Link calls to MySQL@3306 on demo-host service",
    "enabled": true
}
 

La mappe de flux de services 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 services peut afficher des données inexactes.

Cela provient du fait que l'agent n'est pas exécuté en mode APM ou qu'aucun agent n'est installé. Par conséquent, aucune trace n'a été collectée, ou si un agent est installé, aucune trace n'a été collectée au cours de la période sélectionnée.

Pour vérifier si un agent est installé et en cours d'exécution, cliquez sur Infrastructure pour afficher les hôtes de la mappe d'infrastructure qui peuvent avoir un agent, ou cliquez sur Plus > Agents pour afficher la liste des agents installés. Si aucun agent n'apparaît dans la liste, consultez la documentation pour savoir comment installer un agent ou créer une perspective d'application.

Le mappage de service repose sur les données d'infrastructure. Toutefois, dans certains scénarios, les données de trace ne peuvent pas être enrichies avec des données d'infrastructure. Par exemple, il se peut que les données de trace ne soient pas encore enrichies peu après le démarrage d'un agent d' Instana, ou d'un processus surveillé. Cela prend un certain temps jusqu'à ce que l'application surveillée soit entièrement instrumentée et que les traceurs et les détecteurs commencent à collecter des données. Si les premières traces sont collectées avant que tous les détecteurs ne deviennent actifs, il se peut que certaines ou même toutes les données d'infrastructure soient manquantes dans ces traces. Dans ce cas, le nom du service utilisé est moins précis; par exemple, un hôte HTTP plutôt qu'un nom d'application SpringBoot.

Un mécanisme appelé « mappage résilient » est utilisé pour éviter les problèmes de mappage des services liés au redémarrage des agents d' Instana s ou des processus surveillés. Le mappage résilient prend effet si les données d'infrastructure pour le mappage des appels au service approprié ne sont pas disponibles. La cartographie résiliente peut attribuer un appel au service approprié en s'appuyant sur un cache contenant les résultats des cartographies précédentes. Toutefois, cela peut entraîner un nom de service inattendu, par exemple, si le cache contient des données d'infrastructure obsolètes. Le service attendu revient automatiquement lorsque le cache Resilient est mis à jour.