Corrélation d'infrastructure
Cette page décrit comment les mondes de la surveillance des applications et de la surveillance des infrastructures sont intégrés ensemble.
Pour plus d'informations, consultez les sections consacrées à la surveillance des applications et à la surveillance de l'infrastructure.
Bien que certains utilisateurs puissent s'appuyer principalement sur la surveillance d'application, il est parfois utile et nécessaire de mieux comprendre comment la couche logique est mappée à la couche physique pour résoudre les problèmes détectés au niveau de l'application, mais dont la cause principale se trouve dans la couche d'infrastructure.
Instana permet une navigation bidirectionnelle dans l'interface utilisateur entre la surveillance des applications et celle de l'infrastructure :
- Des applications et des services à la surveillance des infrastructures
- Des appels à la surveillance des infrastructures
- De la surveillance de l'infrastructure à la surveillance des applications
La corrélation d'infrastructure joue également un rôle important dans :
De même, la surveillance des applications et celle des sites web sont intégrées, comme expliqué plus en détail ici.
Navigation à partir des services
Dans sa forme la plus simple, un service est exécuté par un seul processus, par exemple, une application de démarrage Spring. Cependant, il est assez fréquent qu'il soit exécuté par plusieurs processus pour prendre en charge différents cas d'utilisation :
- augmenter le débit et la résilience. Plus il existe de processus mieux c'est ;
- pour diviser le travail en fonction de différents locataires ou configurations ;
- pour exécuter différentes versions de ce service, généralement dans des environnements différents :
Cela signifie qu'à partir d'un service, vous pouvez généralement naviguer jusqu'à un ou plusieurs processus sous-jacents et entités connexes telles que les hôtes, les conteneurs, les pods ckubernetes, etc.
Un point d'entrée est le Pile, à l'intérieur de l'onglet Infrastructure, qui vous indique tout ce que les éléments d'infrastructure prennent en charge pour l'exécution du service, y compris leur santé et les mesures importantes comme l'utilisation de l'unité centrale ou de la mémoire.
Un autre point d'entrée est l'onglet Infrastructure d'un tableau de bord de service, qui fournit une ventilation différente de celle de la pile, ainsi que des métriques de trace telles que le nombre d'appels, le taux d'erreurs et la latence moyenne, de l'hôte jusqu'au processus.
Ces deux widgets intègrent nativement les services « Kubernetes » et «Pivotal Cloud Foundry », vous offrant ainsi un accès direct aux entités associées, telles que les services « Kubernetes » ou les applications PCF.
Exemple de pile pour un service exécuté dans Kubernetes :
Exemple d'onglet Infrastructure pour un service exécuté dans Kubernetes :
Navigation à partir des appels
En général, les traces sont liées aux entités d'infrastructure. Plus spécifiquement, un appel peut être lié à 2 processus : la source à l'origine de l'appel et la destination qui traite l'appel. Par exemple, un processus NodeJS effectue un appel HTTP à un processus PHP.
Dans Vue de trace, vous pouvez sélectionner n'importe quel appel pour ouvrir le fichier Détails de l'appel. À partir des sections de source et de destination, vous êtes en mesure de connaître les éléments d'infrastructure concernés.
Dans cet exemple, la source est un processus PHP alors que la destination est une application d'amorçage Spring (processus Java) :
Parfois, la corrélation avec l'infrastructure n'est pas possible, ce qui signifie généralement que le processus sous-jacent n'est pas surveillé par Instana.
C'est toujours le cas de l'appel racine d'une trace, car un client externe non surveillé fait la demande initiale. Ici, le shipping service est appelé à partir d'un élément qui n'est pas surveillé par Instana :
Les appels sortants qui ciblent un service externe tiers est un autre cas. Dans ce cas, le service payment a appelé le service externe www.paypal.com.
Navigation à partir de l'infrastructure
Lorsque vous examinez des entités d'infrastructure ou de plateforme ( Kubernetes, Pivotal Cloud Foundry et vSphere ), vous pouvez utiliser Stack pour obtenir la liste des services qu'elles exécutent et des applications dont elles font partie, ainsi que des métriques telles que le nombre d'appels et d'erreurs.
En amont / en aval vous donne accès aux services et aux applications qui, respectivement, appellent et sont appelés par l'entité d'infrastructure en cours.
Fonctionnement
Avant toute chose, il est important de comprendre que la surveillance des applications et celle de l'infrastructure s'appuient sur deux flux de données distincts :
Surveillance des applications : les données (traces et « calls.md ») proviennent des traceurs d' Instana s ou de traceurs tiers.
Surveillance des infrastructures : les données (balises et metrics.md ) proviennent des capteurs de l' Instana.
Ces 2 environnements fusionnent de façon transparente grâce à un mécanisme que nous appelons la liaison d'infrastructure, où les appels sont liés à des entités d'infrastructure surveillées. La liaison se produit lorsqu'un identificateur commun des deux côtés est trouvé.
Services instrumentés
Les traceurs permettent de capturer les appels entrants et sortants. Ces appels sont ensuite signalés au back-end Instana où nous essayons de lier la source et la destination de ces appels à des entités d'infrastructure connues. Lorsque le processus source (ou processus de destination) est instrumenté, cela implique nécessairement que le processus source (ou le processus de destination) est également surveillé par un capteur Instana, qui sait tout à son sujet. Comme le traceur et le capteur sont colocalisés, ils connaissent tous les deux l'hôte et le processus, ce qui rend possible l'établissement d'une liaison d'infrastructure.
Par exemple, un processus Python est instrumenté par le traceur Python qui capture tous les appels entrants et sortants. Entre temps, plusieurs capteurs ont été activés sur l'hôte sur lequel le processus s'exécute : l'hôte, le processus et les capteurs python. Le traceur et les capteurs envoient des données séparément au back-end Instana, mais ils contiennent tous les deux le même identificateur pour le processus. Il est donc possible de lier la destination des appels entrants et la source des appels sortants au processus Python.
Services intégrant l' OpenTelementry
Dans de nombreux cas, la corrélation des infrastructures peut également être effectuée pour les services instrumentés à l'aide d' OpenTelemetry, plutôt qu'à l'aide des traceurs natifs d' Instana. Pour plus d'informations et pour connaître les meilleures pratiques, consultez la section « Mappages de services et corrélation de l'infrastructure » sur OpenTelemetry.
Bases de données, systèmes de messagerie et services cloud
Instana Les traceurs ne prennent pas en charge les bases de données, les systèmes de messagerie ni les services cloud. Cependant, les processus qui font appel à ces systèmes non tracés sont instrumentés, de sorte que les requêtes sortantes sont correctement associées aux appels. Par exemple, le traceur Java enregistre les requêtes sortantes envoyées par un processus Java vers une base de données MySQL. Ces requêtes sont traitées sous forme d'appels dont la source est le processus Java et la destination la base de données MySQL. Ces appels sont visibles dans Instana, et leurs destinataires sont souvent associés à l'entité d'infrastructure qui reçoit l'appel. Cette mise en correspondance n'est possible que si Instana est en mesure d'associer de manière univoque les informations d'adresse issues de la requête du client sortant à l'infrastructure surveillée :
D'une part, Instana surveille la base de données ou le système de messagerie à travers l'un des capteurs Instana et, par conséquent, connaît le processus, son port et l'hôte. D'autre part, Instana analyse une demande sortante qui peut contenir suffisamment d'informations pour déterminer le processus de destination, généralement le nom d'hôte ou l'adresse IP et le port transporté, par exemple, dans la chaîne de connexion.
Par exemple, une demande sortante vers une instance MySQL peut contenir la chaîne de connexion jdbc:mysql://10.128.0.6:3306.
La surveillance de l'infrastructure a détecté un processus MySQL correspondant exposant le port 3306 et l'exécution sur un hôte qui expose l'adresse IP 10.128.0.6.
Du fait de l'adresse IP et du port, les appels et l'instance MySQL sont liés ensemble :
Instana prend également en charge les chaînes de connexion qui contiennent un nom de service Kubernetes tel que jdbc:mysql://mysql-svc. En arrière-plan, il tente de qualifier entièrement le nom de service, afin d'identifier de manière unique le service dans tous les espaces de nom et les clusters. Le résultat est un appel dont la destination est liée au service Kubernetes, au lieu de l'être au processus final.
Pour les services cloud, il n'existe pas de processus, mais l'idée est la même : trouver un identificateur commun partagé par le service cloud surveillé et la demande sortante vers ce service. Il peut s'agir, par exemple, d'un identificateur de ressource tel qu'un nom ARN AWS.
Il n'est pas toujours possible de faire correspondre les informations relatives à l'adresse de la requête avec les données connues sur l'infrastructure. Dans certains cas, les services de base de données, de messagerie ou de cloud indiquent une infrastructure « non surveillée » alors même que les systèmes cibles sont équipés d'outils de surveillance, comme le montrent les exemples suivants :
Pour certaines bases de données, certains systèmes de messagerie ou certaines technologies cloud surveillés, la corrélation des infrastructures n'est pas prise en charge, car les traceurs n'extraient pas suffisamment d'informations d'adresse des appels pour identifier de manière unique l'infrastructure de destination. Par exemple, le traçage des appels de messagerie, comme Kafka, permet souvent de déterminer uniquement le nom de la file d'attente ou du sujet de destination, mais pas le cluster ou le serveur de messagerie concerné.
Il est parfois impossible de lier les appels à l'infrastructure lorsque l'hôte ou l'adresse IP fournis dans la chaîne de connexion ne correspond à aucun hôte ou à aucune adresse IP connus dans la surveillance de l'infrastructure. C'est généralement le cas lorsqu'il existe un niveau d'indirection dans lequel le processus appelant la base de données distante (ou le service de messagerie ou le service cloud) utilise un nom d'hôte qui est :
- une entrée dans le fichier
/etc/hostssystème - une entrée DNS CNAME ;
- un pointeur vers un proxy ou un équilibreur de charge ;
- un alias donné par un service de découverte de service tel que Consul ou Zookeeper.
De plus, il n'est pas possible d'associer des appels à une infrastructure lorsque les informations d'adresse fournies par le client correspondent à plusieurs entités d'infrastructure. Cette situation se produit souvent dans les configurations de bases de données à haute disponibilité où plusieurs instances de base de données utilisent la même adresse pour l'accès des clients. Comme la base de données elle-même n'est pas instrumentée, Instana ne peut pas déterminer laquelle des destinations potentielles a effectivement exécuté l'appel à la base de données.
Services externes
Par définition, les services externes ne sont pas surveillés par Instana et ne sont donc même pas visibles dans la surveillance de l'infrastructure. Comme nous ne savons rien à leur sujet, les appels à ces services ne sont tout simplement pas liés à des entités d'infrastructure connues.
Dans l'onglet Infrastructure, ces appels apparaissent « Non surveillés » :
Corrélation des infrastructures dans la cartographie des applications et des services
Quel est le rôle de la corrélation des infrastructures dans la cartographie des applications et des services?
Lorsque le système back-end Instana analyse les traces et les appels, il les lie d'abord à des entités d'infrastructure connues et les enrichit avec des balises d'infrastructure telles que host.name, springboot.name ou docker.label. Ces balises sont ensuite utilisées pour mapper automatiquement ces appels vers des services à l'aide de règles prédéfinies ou de règles définies par l'utilisateur. Par exemple, un appel lié à un processus d'amorçage Spring sera associé à un service qui obtient son nom du nom de l'application springboot. Vous pouvez également définir une étiquette « dockerservice-name » qui servira à créer une règle de mappage de services personnalisée afin de nommer la plupart de vos services exécutés sur Docker.
Il en va de même pour le mappage des applications, où vous pouvez utiliser ces balises d'infrastructure pour définir des applications, par exemple en utilisant la kubernetes.namespace balise :
Lorsque la liaison d'infrastructure n'est pas possible, le mappage de service ne peut pas s'appuyer sur les balises d'infrastructure et utilise des règles de substitution définies à l'aide de balises d'appel, telles que call.http.host ou call.database.schema.
Corrélation des infrastructures et incidents
Un incident regroupe des événements connexes à l'aide du graphe dynamique. La possibilité de lier les appels (et donc les applications et les services) aux entités d'infrastructure enrichit le graphique dynamique avec des connexions supplémentaires qui relient les deux environnements, ce qui se traduit par des incidents encore plus complets et une analyse plus rapide des causes principales.