Documentation
Découvrez le mode zéro configuration

APM et traces distribuées

L’APM et le tracing distribué de ServicePilot permettent d’analyser en temps réel le comportement des applications et les problèmes de performance.

Les traces distribuées sont les enregistrements des chemins que prennent chacune des requêtes au travers des multiples microservices qui constituent l'application. Le traçage devient très complexe à observer et analyser dès que l'on rencontre ce genre d'architecture. Il est certain que lorsqu'une application est constituée de centaines de microservices communiquant avec autant voire plus d'hôtes, il n'est plus possible de se baser sur la trace unique. D'autant plus, les pages statiques sont servies par CDN ce qui bloque complètement la visibilité sur certaines parties de l'application. En comparaison aux applications plus "classiques", plus monolithiques, où le tracing est trivial, la complexité naturelle des architectures modernes fait de celui-ci un réel défi.

Distributed Traces

Sur le schéma suivant, pour une même transaction, plusieurs requêtes sont envoyées par un utilisateur. Ces requêtes se propagent ensuite à travers toute l’application. Par conséquent, si un problème quelconque survient, il est impossible d’en identifier la cause sans les traces distribuées.

Il faut donc des outils modernes pour comprendre la complexité et c'est dans ce cadre que vient s'inscrire ServicePilot Technologies, en offrant une solution concrète et simple basée sur du Root Cause Analysis performant.

Les traces distribuées sont automatiquement mises en corrélation avec les logs, les Checks synthétiques ainsi que les métriques réseau et infrastructure.

Les Types d'APM

APM & RUM

Afin d'avoir une vision complète du comportement de son application, il est important de savoir ce qu'il se passe dans l'intégralité de celle-ci, que ce soit côté client ou serveur. C'est pour cette raison que le RUM et l'APM vont de pairs et se complètent parfaitement.
En couplant RUM et APM, il est possible de tirer un maximum de la puissance du tracing distribué afin d'avoir une vision d'ensemble précise sur chacune des étapes de chaque transaction. L'un sans l'autre engendre une grosse perte d'information sur les requêtes et rend le troubleshooting beaucoup plus difficile.

APM & Synthetic Monitoring

Le Synthetic Monitoring est une technique de supervision qui simule une action ou une série d'actions qu'un utilisateur pourrait effectuer sur un site web. Du fait que ces actions sont supervisées de manière continue, des métriques de disponibilité, de temps de réponse, et de performances peuvent être surveillées 24/7.
Lorsqu'on ajoute des technologies telles que l'APM au Synthetic Monitoring, il est possible d'avoir une vision beaucoup plus profonde de la performance et de la disponibilité des fonctionnalitées et des services délivrés par un site web.

APM & Application Traces

Pour mieux comprendre les actions des microservices et des hôtes répartis au sein d'une infrastructure, il est nécessaire d'utiliser APPTrace. En effet cet outil permet à l'utilisateur de ServicePilot de tracer toutes les requêtes effectuées par les microservices et de connaître les liaisons entre clients et serveurs et principalement de savoir qui envoie quoi à qui et comment.
Si l'on rassemble APPTrace et APM, il est possible d'avoir une vision d'ensemble sur tous les microservices qui composent les applications situées dans l'infrastructure.

APM & Logs des serveurs Web

Les logs des serveurs Web au format W3C peuvent être intégrées à l'instrumentation APM de ServicePilot. Il est quand même préférable d'instrumenter le code d'application web avec les traces applicatives comme ci-dessus. Les traces applicatives permettent la corrélation d'appel de sous-application, par exemple des requêtes à une base de données.

Les logs W3C peuvent être étendues avec des Request Headers si les applications web sont instrumentées pour le RUM. Pour la supervision APM du serveur Web, ajoutez un Agent ServicePilot sur le serveur et un package de supervision W3C.

APM & Network Traces

Le Network Tracing est une technique de supervision qui vise à étudier tous les flux de données entrants et sortants d'un un hôte ou d'un groupe d'hôtes. Il est possible grâce à cette méthode d'avoir un suivi visuel des communications au sein d'un réseau et de récupérer toutes les données dans un fichier pcap.
Quand on joint Nettrace et APM, il est possible d'obtenir une large quantité d'informations sur son réseau et les hôtes qui l'occupent, avec différents moyens de visualisation et de filtres des données.

Instrumentation pour le Tracing

La technologie APM de ServicePilot permet de corréler plusieurs technologies dépendantes :

  • Browser : supervision passive de toutes les interactions d'un utilisateur avec une application.
  • Synthetic Monitoring : supervision active de la disponibilité et de la performance d'un site web.
  • Traces applicatives : supervision de toutes les transactions et requêtes entre les différents microservices d'une application monitorée.
  • Traces réseaux : supervision de toutes les communications réseaux entrantes et sortantes des hôtes monitorés.
  • Métriques Systèmes : supervision des systèmes, tels que les CPU Load, Memory usage, Disk I/O ... des serveurs.

Le choix de l'instrumentation des applications est important et peut être très simple même avec des applications très complexes :

Intégrez des scripts pour rapporter les métriques RUM dans des pages web. Ceci peut être fait :

  • Automatiquement en utilisant un plugin pour intégrer le script de rapport des métriques RUM dans les pages web desservies par Tomcat et Jetty
  • En paramétrant les serveurs web ou les proxies pour réécrire les pages web servies afin d'y intégrer le script RUM (par example en utilisant l'extension IIS URL Rewrite)
  • En ajoutant manuellement le script RUM dans les pages web clés

Voir les instructions RUM de ServicePilot sous PARAMÈTRES > Configuration > Basique > Intrumentation APM > Intrumentation RUM

Afin de mettre en place le Synthetic monitoring, différents packages peuvent être utilisés.

  • Le package user-webcheck permet de superviser les réponses d'un serveur à l'aide d'une requête HTTP(S) émise par l'agent ServicePilot.
  • Il est également possible d'utiliser le package user-web-scenario qui offre la supervision des temps de réponse d'un serveur via une série de requêtes HTTP(S) émises par l'agent ServicePilot.

Toutes les requêtes sont émises par l'agent ServicePilot selon un intervalle défini, permettant une supervision en continu de la performance et de la disponibilité d'un site web.

Afin de récolter les traces réseaux, il suffit d'utiliser le provisioning-auto de ServicePilot. Lors de la création d'une règle de provisioning-auto, veillez bien à mettre le type de découverte sur SP Agent et de cocher la case NPM sous l'onglet Instrumentation APM/NPM.
NETTRACE Auto Prov

Afin de récolter les traces applicatives, il suffit d'utiliser le provisioning-auto de ServicePilot. Lors de la création d'une règle de provisioning-auto, veillez bien à mettre le type de découverte sur SP Agent et de cocher les cases nécessaires sous l'onglet Instrumentation APM/NPM.

Afin de récolter les métriques systèmes, le principe est le même que pour les traces réseaux, cette fois-ci il faut s'assurer que la case Packages Systèmes est bien cochée.
System Auto Prov

Afin de récolter des traces APM provenant de serveurs web tels que IIS ou Apache, il est possible de déployer le package apptrace-appservice-w3c.
Le package récupère des logs situées au chemin défini lors de sa configuration.
APM W3C

Traces applicatives

Comment collecter les traces distribuées

En fonction de l'application à surveiller, il existe trois façons d'instrumenter le code de l'application :

  1. Fully automatic : Pour Linux, l'agent ServicePilot modifie automatiquement les variables d'environnement du programme et la ligne de commande pour insérer les bibliothèques APM. Le programme devra être redémarré pour que cette modification prenne effet.
  2. Automatic : L'instrumentation de surveillance APM est insérée dans le code de l'application automatiquement après que l'opérateur a modifié les variables d'environnement du programme et la ligne de commande et que le programme a été redémarré avec ces nouveaux paramètres.
  3. Manual : L'instrumentation de surveillance APM doit être ajoutée manuellement au code de l'application.

ServicePilot utilise plusieurs technologies d'instrumentation Open Source pour vous permettre de choisir quels librairies d'instrumentation et méthodes vous préférez pour collecter les données :

Cas où une intrumentation Open Source existe

Si vous utilisez déjà les technologies d'instrumentation listées précédemment, l'agent ServicePilot s'intègre nativement avec celles-ci.

Cas où une intrumentation n'existe pas

Si vous n'avez pas encore instrumenté votre application, ServicePilot supporte plusieurs langages :

Langage Fully automatic Automatic Manual
.NET X X X
Java X X X
Node.js X X X
Python X X
PHP X X
Ruby X X
Go X

Pour plus d'informations, contactez le support technique.

Datadog

Les Agents ServicePilot peuvent recevoir des traces et des métriques APM de Datadog Tracing Libraries.

Afin de récolter les traces applicatives, il suffit d'utiliser le provisioning-auto de ServicePilot. Lors de la création d'une règle de provisioning-auto, veillez bien à mettre le type de découverte sur SP Agent et de cocher les cases nécessaires sous l'onglet Instrumentation APM/NPM.

  • Selectionnez les ports APM pour la collection Datadog : 8125, 8126
  • Selectionnez le téléchargement automatique des librairies en fonction du langage de l'application à instrumenter
  • Pour les librairies qui ne supportent pas l'instrumentation centralisée, suivez la documentation Datadog pour envoyer des traces APM à l'Agent ServicePilot sur les ports 8125, 8126

OpenTelemetry

OpenTelemetry, également connu sous le nom d'OTel, est un framework d'Observabilité open-source neutre pour l'instrumentation, la génération, la collecte et l'exportation de données télémétriques telles que les traces, les métriques et les logs. Les Agents ServicePilot agissent comme des Collecteurs OTel pour les traces envoyées par le code d'application instrumenté à l'aide de l'instrumentation automatique OTel, de l'instrumentation avec une librairie OTel ou par l'envoi manuel de données à l'aide des protocoles OTLP/HTTP ou Zipkin/HTTP.

L'instrumentation automatique OpenTelemetry est disponible pour un certain nombre de langues avec des librairies et du code documenté sur le site Web d'OpenTelemetry.

Afin de récolter les traces applicatives, il suffit d'utiliser le provisioning-auto de ServicePilot. Lors de la création d'une règle de provisioning-auto, veillez bien à mettre le type de découverte sur SP Agent et de cocher les cases nécessaires sous l'onglet Instrumentation APM/NPM.

  • Selectionnez les ports APM pour la collection OpenTelemetry : 4318
  • Selectionnez le téléchargement automatique des librairies en fonction du langage de l'application à instrumenter
  • Pour les librairies qui ne supportent pas l'instrumentation centralisée, suivez la documentation OpenTelemetry pour envoyer des traces APM à l'Agent ServicePilot sur le port 4318.

Zipkin

Zipkin est un système de traçage distribué. Il permet de collecter les données temporelles nécessaires au dépannage des problèmes de latence dans les architectures de service. Les Agents ServicePilot agissent comme des Collecteurs Zipkin pour les traces envoyées par du code applicatif instrumenté à l'aide des librairies d'instrumentation de Zipkin ou par l'envoi manuel de données en utilisant le protocole Zipkin/HTTP.

Zipkin Tracers and Instrumentation documente les librairies supportant l'instrumentation du code d'application pour envoyer des traces à un Agent ServicePilot.

Afin de récolter les traces applicatives, il suffit d'utiliser le provisioning-auto de ServicePilot. Lors de la création d'une règle de provisioning-auto, veillez bien à mettre le type de découverte sur SP Agent et de cocher les cases nécessaires sous l'onglet Instrumentation APM/NPM.

  • Selectionnez les ports APM pour la collection Zipkin : 9411
  • Suivez la documentation Zipkin pour envoyer les traces APM vers l'Agent ServicePilot sur le port 9411

Comment voir les traces APM

Monitor topologie (live)

Dépendances des services

L'information est représentée sous deux différentes formes : les dépendances verticales et les dépendances horizontales. Les dépendances verticales sont représentées telles un système de couches avec pour chaque couche une catégorie. On retrouve en haut les Applications ensuite les Services puis les Processes etc... Tandis que les dépendances verticales représenteront les communications entre les éléments d'une même couche comme des liens entre les différents hôtes.

Identification des problèmes et Root Cause Analysis (temps réel)

Grâce à la page Topologie, un affichage relationnel par section de vos différents systèmes se crée. Il est possible d'identifier les différents problèmes que pourraient rencontrer les systèmes monitorés sur votre réseau. Vous pouvez par la suite et grâce à l'affichage de l'architecture trouver très rapidement quel serveur est à l'origine de l'incident et résoudre le problème dans les plus brefs délais.

Sept onglets permettent de naviguer à travers les vues verticales : Applications, Services, Processes, Hosts, Network, Security et Misc.

Dans chacun de ces onglets, il y a le code couleur d'alertes des éléments affichés dans la partie centrale de la page. Chaque couleur peut être sélectionnée et permet d'afficher uniquement les éléments de la couleur demandée.
Fullstack tab

Dépendance Explication
View Dependencies Affichage des différents éléments des onglets en fonction de l'étage de vue dans lequel ils se trouvent dans la hiérarchie de vues. Par exemple un élément dans MAIN > France retrouvera le même chemin dans cette dépendance. Fullstack view
APP Dependencies Affichage des différentes liaisons entre les éléments par rapport à leurs traces applicatives. Un élément en communication avec un autre se verra en dépendance avec celui-ci Fullstack APP
NET Dependencies Affichage des différentes liaisons entre les éléments selon leur communication réseau. Un élément en communication avec un autre se verra en dépendance avec celui-ci Fullstack NET
Table Affichage sous forme de tableau. Il permet d'obtenir : "status", "ressource", "package", "hote", "Mbps", "TCPReject", "TcpStartPublic", "RPM", "AvgDuration" et "erreurs" Fullstack table
Métriques Explication
Spring layout Affichage des dépendances selon une architecture découverte dynamiquement. Les éléments se placent automatiquement en fonction de leurs liaisons Fullstack Spring layout
Horizontal layout Affichage d'une vue avec des éléments organisés de gauche à droite. Les éléments en communication sont représentés par une architechture plus structurée que l'affichage Spring layout Fullstack Horizontal layout

Tooltip : en survolant une pastille, cette dernière renvoie des informations la concernant comme son type (Linux ou Windows par exemple), son hôte, sa ressource et son package.

Sur l'écran de droite se trouve un affichage séparé en deux. En haut l'affichage des dépendances verticales permet de voir une arborescence représentant les différentes couches.

En dessous, un menu avec trois onglets permet d'obtenir des informations complémentaires sur le serveur sélectionné.

Note : c'est lors de la sélection d'un élément que les dépendance verticales et les détails s'affichent.

Section Contenu
Status Détails de l'élément sélectionné Fullstack details
Cause Causes des différents statuts Fullstack cause

Tableaux de bord de métriques APM (Analyse historique)

Les pages Tableaux de bord de métriques APM présentent de manière synthétique toutes les données liées aux traces applicatives et réseaux qui ont pu être récoltées. Afin d'accéder aux tableaux APM il suffit de se rendre dans ANALYSES > Traces et sélectionner des ressources APPTrace et NetTrace.

Les données récoltées peuvent être consultées globalement en sélectionnant la catégorie souhaitée. Category selection
Les données peuvent également être consultées pour un élément spécifique d'une catégorie. Unique selection

Trois catégories sont présentées ici, AppService, NetProcess ainsi que NetServer.

AppService

C'est dans cette catégorie que se trouve l'analyse des traces applicatives des applications supervisées et la prise en charge par la technologie APM. Les données présentées offrent une analyse précise de la performance et du comportement des applications supervisées, notamment avec le nombre de requêtes par minutes, la satisfaction utilisateur et d'autres métriques applicatives.

AppService page

NetProcess

Dans la catégorie NetProcess sont disponibles les données liées aux traces réseaux de chaque processus des applications supervisées. Plusieurs métriques sont affichées notamment la quantité de paquets "Retransmits" et "Rejected" mais également le débit maximal ainsi que le volume de données circulant dans les processus supervisés.

NetProcess page

NetServer

La catégorie NetServer affiche les mêmes métriques que NetProcess cependant dans cette catégorie, les données concernent chaque serveur dans leur ensemble et non pas uniquement les processus supervisés.

NetServer page

Page Transactions (Analyse historique)

La page Transactions présente une analyse de toutes les transactions ayant eu lieu entre les clients et les machines supervisées par la technologie APM de ServicePilot. Afin d'accéder à la page Transactions, il suffit de se rendre dans ANALYSES > Traces et ensuite choisir l'onglet Transactions.

Données présentées

Cette page Transactions offre une mise en avant des diverses transactions et notamment des différentes réponses HTTP(S), du temps de réponse, des hôtes impliqués, des méthodes utilisées ainsi que les chemins empruntés. Les données sont synthétisées sur des graphiques offrant une visibilité complète du déroulement des transactions au sein d'une application.
Il est également possible d'obtenir le détail de chacune des transactions avec toutes les données pertinentes (traceID, duration, httppath, httpstatuscode...) :

Transactions details

Filtrer les transactions

Cette page est munie d'une fonctionnalité de filtre offrant la possibilité d'affiner les données pour mieux comprendre et analyser les multiples transactions.

La partie gauche de la page permet de sélectionner des filtres prédéfinis en fonction des transactions enregistrées. Il suffit de cliquer sur un filtre pour l'appliquer. Pour enlever un filtre il suffit de le déselectionner. Pour des filtres plus poussés il est possible d'utiliser la barre de requêtes.

Page APPTrace (Analyse traces temps réel)

L'onglet APPtrace permet d'analyser en temps réel les applications sur des serveurs, qui sont monitorées par provisioning-auto ou par des packages étant taggés comme microservices. Cette page offre une vue d'ensemble sur les applications supervisées et permet de mieux comprendre leur fonctionnement et leurs communications avec l'extérieur. Afin d'accéder à la page APPTrace, il suffit de se rendre dans ANALYSES > Traces et ensuite choisir l'onglet APPTrace.

Explorateur

Grâce au menu de gauche, il est possible de naviguer à travers les différents hôtes et microservices possédant l'APPTrace. Il est possible d'obtenir des informations venant de tous les hôtes en même temps, d'en obtenir venant seulement d'un hôte et seulement d'un microservice précis.

Menu principal

Dans l'interface principale, 3 types de données sont accessibles. Pour chaque type de données, le détail de chaque trace applicative est disponible avec des informations sur les hôtes impliqués dans la trace collectée (IP du client, IP du serveur, nom d'hôte...). Chaque type de données a en complément des données spécifiques :

Type de données Description
Hosts button - Hosts Affiche les traces applicatives par host. Sont affichées des informations sur le système et les process responsables des traces récoltées mais également des indications sur les requêtes en elles-même (méthode HTTP, code de réponse HTTP, temps des requêtes...)
Processes button - Processes Affiche les traces applicatives par process. Les informations disponibles sont identiques à celles décrites pour les traces par hosts (Une donnée supplémentaire est le port utilisé par le process se trouvant le server)
Conversations button - Conversations Affiche les traces applicatives par conversation. Sont affichées des informations sur les requêtes (méthode HTTP, code de réponse HTTP, temps des requêtes, chemin de la requête...)

Les Différentes vues

Les données peuvent être affichées selon différents modes à l'aide des 5 boutons dans la partie supérieure droite de l'interface.

Mode d'affichage Description
Details button - Details Présente les données sous forme de tableau détaillant chacune des traces récoltées
Topo graph button - Topo graph Présente les données sous forme de graphe dynamique
Topo top-down button - Topo top-down Présente les données sous forme de graphe hiérarchisé de haut en bas
Topo left-right button - Topo left-right Présente les données sous forme de graphe hiérarchisé de gauche à droite
Host map button - Host map Présente les données sur une carte du monde géolocalisant les hosts (la Host map est principalement utile et utilisable pour les microservices utilisant des adresses IP public)

Il est possible de mettre en pause la capture à tout moment en appuyant sur le bouton pause, situé en haut à droite de la fenêtre. Vous pouvez aussi rafraichir les données de la page afin d'effacer les données actuelles.

Page NetTrace (Analyse traces temps réel)

La page NetTrace permet de voir en direct les traces réseaux des ressources supervisées par des agents ServicePilot. Afin d'accéder à la page NetTrace, il suffit de se rendre dans ANALYSES > Traces et ensuite choisir l'onglet NetTrace.

La page NetTrace offre une visualisation précise et rapide de tout le trafic transitant en live dans un réseau. Plus précisément, NetTrace permet la visualisation des différentes connexions établies entre serveurs supervisés par agents ServicePilot et clients. Pour chaque connexion détectée, plusieurs données seront disponibles telles que les IP des hôtes communiquants entre eux, mais également des données plus précises (conversations, connexions bloquées, rejetées, octets par secondes...)
La mise en évidence et la résolution de problème au sein de l'infrastructure réseau est beaucoup plus triviale avec l'utilisation de NetTrace.

Nettrace data

Les données peuvent être visualisées de manière plus ou moins globales :

Les données récoltées peuvent être consultées sur un réseau entier en sélectionnant le réseau souhaité. Nettrace network
Les données peuvent également être consultées pour un hôte spécifique d'un réseau. Nettrace host

Après sélection du réseau ou de l'hôte, il est possible de visualiser les données et les différents liens associés de plusieurs manières, sous forme de tableau pour des détails plus poussés sur chacune des communications, ou sous forme de graphes pour une vue d'ensemble sur l'état du réseau sélectionné.
Nettrace graphs

NetTrace offre également une fonctionnalité très intéressante permettant à tout moment de capturer le trafic réseau et en faire une trace PCAP selon divers filtres pouvant être renseignés (IP, ports, protocole...) :

1. Ouvrez ANALYSES > Traces
2. Ouvrez l'onglet NetTrace
3. Sélectionnez le serveur sur lequel la capture sera effectuée depuis la liste de gauche.
4. Cliquez sur le bouton Trace situé en haut à gauche, ou à coté d'un hôte.
5. Modifiez ou ajouter des filtres sur les IPs et/ou les ports.
6. Lancez la trace le temps que vous souhaitez.
7. Stoppez la trace, elle se télécharge ensuite automatiquement sous forme de fichier PCAP.