Observabilité des Applications

Les Piliers de l’Observabilité

L'observabilité est essentielle pour garantir la fiabilité, les performances et la résilience des applications et infrastructures. Elle permet aux équipes de diagnostiquer et de résoudre les problèmes applicatifs de manière proactive, en collectant et en analysant des données provenant de diverses sources, telles que les métriques, les traces et les logs.

Dans le contexte du développement d'applications modernes, l'observabilité fait référence à la collecte et à l'analyse de ces données pour fournir des informations détaillées sur le comportement des applications. Elle est essentielle aux architectures dynamiques et aux environnements informatiques multi-Cloud d'aujourd'hui, permettant aux équipes d'ingénierie logicielle, informatiques, DevOps et SRE de collaborer pour prendre des décisions rapides basées sur des données télémétriques.

La plateforme ServicePilot fournit un ensemble complet de fonctionnalités d’observabilité et d’APM (Application Performance Monitoring) permettant de superviser, diagnostiquer et optimiser l’ensemble du cycle de vie des services numériques. En combinant plusieurs sources de données (métriques, traces, logs, flux réseau, données utilisateur, infra...), les interfaces de ServicePilot permettent une vue unifiée et corrélée de vos systèmes / applications.

Afin d'unifier les 3 dimensions que sont les métriques, les traces et les logs, ServicePilot peut s’appuyer sur cinq principaux types de monitoring pour offrir une observabilité complète des applications :

1. Synthetic Monitoring
Ce type de monitoring simule des parcours utilisateurs grâce à des scripts ou des robots. Il permet de tester en continu la disponibilité, la latence et le comportement fonctionnel des services, indépendamment du trafic réel.
Objectif : tester pour détecter les problèmes avant qu’ils n’affectent les utilisateurs.

2. Real User Monitoring (RUM)
Le RUM collecte des données directement depuis les navigateurs ou applications mobiles des utilisateurs réels. Cela permet de comprendre leur expérience (temps de chargement, erreurs JS, lenteurs, géolocalisation) dans le contexte réel d’utilisation.
Objectif : Observer l’impact des performances applicatives sur les utilisateurs finaux.

3. Traces (Distributed Tracing)
Le tracing distribué suit les appels entre microservices ou composants d'une application, en mesurant précisément la latence et les dépendances. Cela permet d’identifier les goulots d’étranglement ou les services défaillants.
Objectif : comprendre les performances transactionnelles d’un système complexe.

4. Flux des applications
L’observation des flux réseau sur les serveurs ou les Hosts offre une visibilité sur le trafic inter-applicatif, les volumes échangés, les temps de réponse réseau et les comportements suspects.
Objectif : visualiser la connectivité, optimiser les performances réseau et renforcer la sécurité.

5. Logs des applications
L’analyse centralisée des logs (système, applicatif, sécurité...) permet de diagnostiquer les incidents, d’enrichir les alertes ou d’investiguer des comportements anormaux.
Objectif : fournir un historique contextuel et détaillé des événements.

Pourquoi combiner ces approches ?
Chaque pilier couvre une facette spécifique de l’environnement numérique. En les combinant, ServicePilot permet :

• une corrélation intelligente des données
• une détection proactive des anomalies
• une analyse RCA (Root Cause Analysis) rapide et pertinente
• une observabilité orientée expérience utilisateur

Monitoring Synthétique

Qu'est ce que le Monitoring Synthétique ?

Le Synthetic Monitoring est une technique de supervision qui simule une ou plusieurs actions utilisateurs sur un site Web, indépendamment du trafic réel. Tester des pages critiques ou des parcours utilisateurs à intervalles de temps réguliers permet de surveiller la disponibilité, la performance et le bon fonctionnement applicatif des services Web.

Mise en Œuvre du Synthetic Monitoring

ServicePilot propose plusieurs packages pour mettre en place une supervision synthétique adaptée à vos besoins :

webcheck – Vérification HTTP(S)

Le package user-webcheck permet de superviser les réponses d'un serveur à l'aide d'une requête HTTP(S) émise par un Agent ServicePilot :

• Collecte de code HTTP, temps de réponse, informations certificat SSL.
• Supporte les requêtes GET/POST, avec en-têtes personnalisés, code HTTP attendu...
• Permet d’extraire des données numériques de la page (ex. : nombre d’éléments, valeur d’un compteur).

Bien qu’élémentaire en apparence, ce package peut devenir un puissant levier de supervision lorsqu’il est déployé stratégiquement. En multipliant les points de test (via des agents ServicePilot positionnés dans différentes zones géographiques, derrière des proxies ou sur des réseaux à latence variable), il est possible d'obtenir une vision assez réelle et distribuée de l’expérience utilisateur.

web-scenario – Scénarios Multi-étapes

Le package user-web-scenario 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. Chaque étape du scénario peut aussi être personnalisée selon les besoins.

Toutes les requêtes sont exécutées par l’Agent ServicePilot à un intervalle régulier, offrant une supervision continue des performances.

Intégration de Tests Fonctionnels Externes

Pour compléter les packages natifs, ServicePilot propose différents packages standards pour intégrer les résultats de tests fonctionnels provenant d’outils tiers. Ces résultats peuvent être remontés dans ServicePilot sous forme de rapports horodatés, enrichissant les tableaux de bord avec les données des tests automatisés.

Logiciels Tiers	Description	Packages ServicePilot
Lighthouse	Outil d’audit automatisé développé par Google pour évaluer la performance, l’accessibilité, le SEO et les bonnes pratiques des pages web.	Intégration Lighthouse
Puppeteer	Librairie Node.js permettant d’automatiser un navigateur Chrome ou Chromium via une API haut niveau même dans des SPAs et sur des contenus dynamiques. Cela permet d’émuler des scénarios complexes avec navigation, clics, saisies, délais, et captures d’écran.	Intégration Puppeteer
NightWatchJS	Framework E2E basé sur Node.js et Selenium. Idéal pour valider les flux critiques avec des assertions (présence de texte, statut HTTP, champs remplis, etc.).	Intégration NightWatchJS
Playwright	Solution multi-navigateurs permettant de tester sur Chrome, Firefox, Safari. Supporte les tests parallèles, les assertions visuelles et les interactions riches (drag & drop, uploads...).	Intégration Playwright
SikuliX	Utilise la reconnaissance visuelle pour automatiser des interactions basées sur l'interface graphique (UI). Très utile lorsque les éléments DOM sont inaccessibles ou dynamiques (idéal pour les applications legacy ou non HTML).	Intégration SikuliX

Visualisation des Données Synthetic Monitoring

ServicePilot propose des tableaux de bord standards, avec des vues consolidées ou individuelles des données sous la section DASHBOARDS dans User Experience > Resources > Web-Scenario ou WebCheck.

Les données du Synthetic Monitoring provenant d'outils tiers sont centralisés dans des tableaux de bord dédiés sous la section DASHBOARDS dans Appmon > Resources > [nom du package].

Real User Monitoring (Web RUM)

Qu'est ce que le Real User Monitoring ?

Le Real User Monitoring (RUM) permet d’observer les performances et le comportement des utilisateurs réels de vos applications web, directement depuis leur navigateur. Contrairement au Synthetic Monitoring, qui repose sur des tests simulés, le RUM mesure l'expérience utilisateur telle qu’elle est réellement vécue, en tenant compte des conditions réseau, du type de terminal, de la géographie et de l’environnement du client.

Avec le RUM, ServicePilot collecte des données précieuses telles que :

• Le temps de chargement des pages (TTFB, DOM Load, Page Load…)
• Les erreurs JavaScript rencontrées
• Les performances réseau et applicatives
• La géolocalisation des utilisateurs
• Les types de navigateurs, OS, et résolutions d’écran

Cela permet de comprendre, mesurer et améliorer la véritable expérience utilisateur en continu, à la fois d’un point de vue technique et ergonomique.

Qu'est ce que le Session Replay RUM ?

Mise en Œuvre du Script RUM ServicePilot

Pour collecter les métriques Real User Monitoring (RUM) dans vos pages web, il est nécessaire d’intégrer le script RUM ServicePilot.

Selon votre environnement, plusieurs méthodes d'intégration sont possibles :

• Serveurs d'applications Java (Tomcat, Jetty). Utilisez un plugin ServicePilot dédié pour injecter automatiquement le script RUM dans les réponses HTML générées par vos applications. Aucune modification manuelle du code n’est nécessaire. Cela permet une intégration centralisée et transparente dans des environnements Java Web classiques basés sur JSP, servlets ou des frameworks comme Spring MVC.
• Serveurs Web / Proxys (Apache, NGINX, IIS, HAProxy...). Configurez vos serveurs ou proxies pour modifier les pages HTML servies, en injectant dynamiquement le script RUM. Cette méthode peut être privilégiée lorsque vous ne pouvez pas modifier le code applicatif mais que vous contrôlez la couche de livraison web. Par exemple, IIS permet d'utiliser l'extension URL Rewrite avec un module d'injection HTML, Apache avec le Module mod_substitute ou NGINX avec l'utilisation d’un module tiers comme sub_filter.
• Pages Web statiques ou applications SPA. Ajoutez manuellement le script RUM dans le code source de vos pages web, idéalement dans la section . Cela convient pour les sites HTML statiques, les Single Page Applications (React, Angular, Vue.js...) ou les intégrations CMS (WordPress, Drupal…). L'insertion manuelle dans le code permet aussi d'établir une instrumentation fine, page par page ou conditionnelle selon l’environnement.

Où récupérer le script RUM ?

Les instructions détaillées pour l’instrumentation RUM sont accessibles depuis l’interface ServicePilot sous la section CONFIGURATION dans Paramètres > Règles APM > Instrumentation RUM. Vous y trouverez le script prêt à l'emploi ainsi que les options de configuration adaptées à vos cas d’usage.

Activation du Session Replay

L’option du Session Replay est activable dans la configuration du script JavaScript RUM. Une fois que le script est mis à jour et déployé sur les pages ciblées, les sessions des utilisateurs de l'application supervisée seront collectées.

Visualisation des Données RUM & Session Replay

Les données collectées sont disponibles depuis plusieurs interfaces de ServicePilot, offrant à la fois des tableaux de bord globaux et des interfaces dédiées pour un diagnostic contextualisé.

Les tableaux de bord standards du RUM ServicePilot avec des vues consolidées ou individuelles sont disponibles sous la section DASHBOARDS dans User Experience > Resources > Rum.

Davantage d'interfaces permettent une exploration granulaire des sessions sous la section DASHBOARDS dans User Experience > Browser ou User Experience > RUM.

La colonne Replay contient une icône lorsqu'une rediffusion de type Session Replay est disponible.

Traces des Applications

Qu'est ce que le Tracing des Applications ?

Dans des architectures dynamiques basées sur des microservices et des composants distribués, comprendre le chemin complet d’une requête utilisateur à travers l’application peut être un défi majeur. Les traces applicatives permettent de suivre chaque requête, du frontend jusqu’au backend, en enregistrant son parcours à travers l’ensemble des services, API, bases de données et Hosts impliqués. Il fournit une cartographie détaillée et chronologique des échanges entre les composants.

Pourquoi les Traces des Applications sont essentielles ?

Grâce aux technologies AppTrace, on peut facilement superviser :

• Les relations client/serveur (qui appelle qui)
• Combien de temps prend chaque étape d’une requête
• Où se situent les lenteurs ou erreurs dans le parcours d’exécution

On peut visualiser la chaîne complète d’exécution d’une transaction complexe et rapidement isoler :

• Des services lents ou surchargés
• Des dépendances externes défaillantes
• Des timeouts ou des appels bloqués

Collecte des Traces APM dans ServicePilot

L’instrumentation des applications est une étape essentielle pour activer le tracing distribué (APM) et récolter des traces précises de vos applications. Grâce à ServicePilot, cela peut être rapide, souple et adapté même à des environnements complexes.

Dans le cas où une application est déjà instrumentée avec un standard Open Source du tracing comme OpenTelemetry, Datadog ou Zipkin, ServicePilot peut s’intégrer nativement pour collecter les traces APM de l'instrumentation existante.

Dans le cas où l'application n'est pas encore instrumentée, l’agent ServicePilot peut automatiquement injecter les bibliothèques nécessaires selon le mode d’instrumentation choisi.

La méthode la plus simple pour collecter les traces APM dans ServicePilot consiste à utiliser une règle de provisioning automatique ainsi qu'une règle APM:

1. Créez une règle de Provisioning-auto depuis l’interface ServicePilot sous la section CONFIGURATION dans Paramètres > Provisioning-auto
2. Activez l'option nécessaire AppTrace en renseignant les ports de collecte
3. Enfin, créez une Règle APM depuis Paramètres pour affiner les définitions de l'application et les détails de l'instrumentation

Une fois configurées, l’Agent ServicePilot pourra collecter les traces APM d'instrumentations existantes (OpenTelemetry, Datadog ou Zipkin) ou injectera automatiquement les librairies sélectionnées.

Mode d’Instrumentation APM par Langage

ServicePilot propose trois niveaux d’instrumentation selon vos contraintes techniques et votre niveau de contrôle :

1. Fully Automatic

   • L’Agent ServicePilot modifie automatiquement la ligne de commande et les variables d’environnement du programme.
   • Nécessite simplement un redémarrage de l’application.
   • Idéal pour les déploiements Linux en production sans intervention directe sur le code.

2. Automatic

   • L’opérateur configure manuellement la ligne de commande et les variables d’environnement.
   • L’Agent injecte alors automatiquement les bibliothèques APM sans modifier le code source.
   • Adapté aux environnements Windows et Linux contrôlés ou containerisés.

3. Manual

   • L’instrumentation est directement intégrée au code source via des SDK ou des wrappers.
   • Utile pour les environnements spécifiques ou langages comme C++, pour un contrôle total sur ce qui est tracé.

ServicePilot prend en charge plusieurs langages selon le mode d’instrumentation souhaité :

Langage	Fully automatic	Automatic	Manual
.NET	✓	✓	✓
Java	✓	✓	✓
Node.js	✓	✓	✓
Python		✓	✓
PHP		✓	✓
Ruby		✓	✓
Go			✓
C++			✓
Custom			✓

Pour les langages non listés ou les cas non présentés dans le tableau, contactez le support technique.

ServicePilot vous permet de choisir une librairie d'instrumentation Open Source parmi plusieurs standards pour collecter les données :

• OpenTelemetry
• Datadog
• Zipkin

Instrumentation par Framework de Tracing

Instrumentation avec 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.

• 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.

Instrumentation avec Datadog

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

• 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

Instrumentation avec 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.

• 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

Visualisation des Données des Traces APM

Les données collectées sont disponibles depuis plusieurs interfaces de ServicePilot, offrant à la fois des tableaux de bord globaux et des interfaces dédiées pour un diagnostic contextualisé.

Tableaux de bord Standards APM

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

Davantage d'Interfaces pour les Traces APM

Davantage d'interfaces spécifiques permettent une exploration granulaire des requêtes sous la section DASHBOARDS dans AppTrace > Applications ou AppTrace > Requêtes ou AppTrace > L7 Map ou AppTrace > Profiler.

Lorsque la colonne Traceid contient une icône de loupe, on peut effectuer un drill-down vers la trace APM pour afficher les détails des transactions d'une requête.

Flux Réseaux des Applications

Que sont les Flux Réseaux des Applications ?

NetTrace est la technologie de ServicePilot qui permet de capturer et analyser en profondeur les échanges réseau entrants et sortants d'une machine (Windows / Linux / IBM z/OS). En supervisant les flux réseaux de plusieurs serveurs, on peut observer les échanges entre des groupes de Hosts et entre les composants applicatifs des systèmes.

Grâce à la surveillance des flux réseaux sur les serveurs et/ou les containers, on peut analyser :

• Qui parle à qui ?
• Sur quels ports et protocoles ?
• A quelle fréquence ?
• Avec quels volumes de données...

L'agent ServicePilot capture les flux IP et produit des résumés de conversation réseau structurés en plus des interfaces détaillées temps réel. Les interfaces Web fournissent des visualisations claires et interactives des communications réseau au sein des infrastructures.

À quoi ça sert ?

NetTrace est un outil système de visibilité réseau orienté applicatif, qui permet notamment de :

• Cartographier les dépendances entre applications, services, serveurs ou microservices
• Identifier les problèmes : latence, saturation, retransmissions TCP, erreurs, etc.
• Détecter des comportements anormaux ou suspects : échanges inattendus, ports non standards, flux vers l’extérieur, etc.
• Valider la conformité des flux réseau (par rapport aux règles de sécurité, segmentation, pare-feu ou zones de confiance)
• Uniformiser la supervision des flux des systèmes quel que soit le choix d'hébergement (Cloud, Hybride, On-Premise)

Mise en Œuvre de la Capture des Flux Réseaux

Afin de récolter les traces réseaux, il suffit d'utiliser le provisioning-auto de ServicePilot depuis l’interface ServicePilot sous la section CONFIGURATION dans Paramètres > Provisioning-auto. Lors de la création d'une règle de provisioning-auto, veillez à cocher la case NetTrace.

Visualisation des Données NetTrace

Les données collectées sont disponibles depuis plusieurs interfaces de ServicePilot, offrant à la fois des tableaux de bord globaux et des interfaces dédiées pour un diagnostic contextualisé.

Tableaux de bord Standards NetTrace

Davantage d'Interfaces NetTrace

Grâce à la page NetTrace L4 Map, 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 ou quel service est à l'origine de l'incident pour résoudre le problème dans les plus brefs délais.

La page NetTrace Public affiche les communications entrantes / sortantes depuis / vers des IP publiques.

Logs des Applications

Les logs applicatifs, systèmes et de sécurité sont une source importante pour diagnostiquer des incidents en profondeur ou enrichir des alertes avec du contexte. Dans une approche moderne d’observabilité, les logs viennent compléter les traces applicatives, les métriques et les tests synthétiques.

Pourquoi centraliser les logs dans ServicePilot?

La centralisation des logs dans ServicePilot permet de :

• Rechercher rapidement dans les journaux de vos systèmes ou vos applications
• Corréler les logs avec les traces, alertes et événements réseau
• Avoir un historique détaillé de chaque événement technique pour les audits, les diagnostics ou l’analyse de comportements anormaux

Collecte des Logs W3C

ServicePilot prend en charge l’ingestion des logs au format W3C, utilisés notamment par les serveurs web comme IIS ou Apache. Ces logs peuvent inclure des informations sur les requêtes HTTP, les statuts, les délais de traitement ou encore les adresses IP sources. Si le site est déjà instrumenté avec RUM, les logs W3C peuvent être enrichis avec des headers de requête personnalisés pour améliorer le suivi utilisateur.

Le package apptrace-appservice-w3c permet de collecter automatiquement les logs W3C présents sur le serveur, selon un chemin défini lors de la configuration.

Il permet notamment de :

• Visualiser les requêtes HTTP
• Analyser les temps de réponse
• Identifier les erreurs applicatives (codes 4xx/5xx)

Visualisation des données de Logs W3C

Les tableaux de bord standards des Logs W3C sont disponibles avec des vues consolidées ou individuelles sous la section DASHBOARDS dans AppTrace > Resources > appservice-w3c.

Davantage d'interfaces permettent une exploration granulaire des requêtes sous la section DASHBOARDS dans AppTrace > Applications ou AppTrace > Requêtes ou AppTrace > L7 Map.