📈 Uptrends – Monitoring Web, Synthétique & RUM

Qu'est-ce que Uptrends ?

Uptrends (faisant partie d'ITRS Group) est une plateforme de monitoring (supervision) en mode SaaS. Elle est spécialisée dans le DEM (Digital Experience Monitoring), c'est-à-dire la surveillance de l'expérience utilisateur finale, qu'elle soit simulée ou réelle.

Son objectif principal est de répondre à la question : "Mon site web (ou mon API) est-il disponible (UP), rapide (FAST) et fonctionnel (WORKING) pour mes utilisateurs, où qu'ils soient dans le monde ?"

Les Deux Piliers d'Uptrends

Uptrends (comme Datadog ou New Relic) divise sa supervision en deux approches complémentaires :

• 1. Monitoring Synthétique (Actif / Proactif) : (Voir 2.x)
  • Le Robot : Uptrends utilise ses propres serveurs (Checkpoints) pour simuler un utilisateur (un robot) qui teste votre site 24/7 (ex: toutes les 1 min).
  • Question : "Mon site est-il UP *maintenant* ?"
• 2. Real User Monitoring (RUM) (Passif / Réel) : (Voir 4.x)
  • Le Vrai Client : Un script JS sur votre site collecte les données de performance de vos visiteurs réels.
  • Question : "Comment mes utilisateurs en Australie ont-ils vécu la performance ce matin ?"

C'est la distinction fondamentale du "Digital Experience Monitoring". Vous avez besoin des deux pour une image complète.

Les Checkpoints sont le réseau mondial de serveurs (sondes) qu'Uptrends utilise pour exécuter le monitoring Synthétique.

Uptrends maintient plus de 230 checkpoints à travers le monde (Paris, Francfort, New York, Tokyo, Sydney...).

Objectif (Perspective Globale)

Problème : Si vous testez votre site (hébergé à Paris) depuis votre bureau (à Paris), il sera rapide. Mais est-il rapide pour vos clients à New York ?

Solution : Lors de la configuration d'un moniteur (ex: Uptime HTTP), vous sélectionnez les Checkpoints qui doivent l'exécuter (ex: "Tester depuis Paris, New York, et Singapour, toutes les 5 minutes").

Détection d'Erreurs (Anti-Faux Positifs)

Si un check échoue (ex: Timeout depuis New York), Uptrends ne déclenche pas l'alerte immédiatement.

Il re-teste immédiatement depuis un autre checkpoint (ex: Chicago) pour confirmer la panne. Si Chicago échoue aussi, l'alerte est "Confirmée" et envoyée. (Cela évite les fausses alertes dues à une micro-coupure réseau locale à New York).

C'est le type de monitoring le plus basique. "Est-ce que ça répond ?" (PING).

Uptrends vérifie la disponibilité à la fréquence définie (ex: 1 minute).

Types de Moniteurs "Uptime"

• Ping (ICMP) : (Couche 3) Vérifie si l'hôte (serveur) est joignable sur le réseau.
• HTTP / HTTPS : (Couche 7) Tente de charger une URL.
  • Vérifie le code de statut HTTP (ex: doit être 200 OK).
  • Vérifie le temps de réponse (ex: doit être < 2 secondes).
  • (HTTPS) Vérifie la validité du certificat SSL (Expiration, Chaîne).
  • (Optionnel) Vérifie la présence d'un mot-clé dans le corps (Body) (ex: "Bienvenue").
• TCP / UDP : (Couche 4) Vérifie si un port spécifique est ouvert (ex: TCP Port 3306 pour MySQL).
• DNS : Vérifie que le DNS résout correctement (ex: A Record).
• SMTP/POP3/IMAP : Teste les serveurs de messagerie.

Problème : Un check "HTTP" (2.1) vous dit que index.html (10 Ko) charge en 50ms (OK). Mais la page complète (avec 100 images, CSS, JS) prend 10 secondes à s'afficher (PAS OK).

Solution : Full Page Check (FPC). Uptrends charge l'URL dans un vrai navigateur (Chrome "headless") et mesure la performance de toutes les ressources (HTML, CSS, JS, Images, Polices...).

C'est le "Web Application Monitoring". Il ne teste pas 1 URL, mais un scénario métier complet (ex: "Se connecter", "Ajouter au panier", "Valider la commande").

Enregistreur de Transactions (Transaction Recorder)

Uptrends fournit une extension Chrome (Recorder) pour créer le script (sans code) :

1. (Développeur) : Démarrer l'enregistrement.
2. (Développeur) : Navigue sur le site (ex: /login).
3. (Développeur) : Clique sur le champ "Username" (Uptrends capture le Sélecteur CSS/XPath).
4. (Développeur) : Tape "mon_user".
5. (Développeur) : Clique sur "Submit".
6. (Développeur) : Ajoute une "Assertion" (Vérification) -> "Vérifier que le texte 'Bienvenue' est visible".
7. (Développeur) : Arrêter l'enregistrement.
8. (Uptrends) : Convertit cela en un script de scénario (multi-étapes).

Exécution

Le checkpoint (robot) rejoue ce scénario (clics, saisie) dans un vrai Chrome (headless) toutes les X minutes.

Alerte : Si l'assertion ("Bienvenue") échoue, le test est "Failed", même si le statut HTTP est 200. (Permet de détecter les pannes applicatives).

Similaire au "Transaction Monitoring", mais pour les APIs (REST, SOAP). Il permet de tester des scénarios (workflows) API en plusieurs étapes, sans navigateur.

Concept : Extraction & Assertions

Permet d'extraire des données (Variables) d'une étape pour les réutiliser dans la suivante (Corrélation).

Exemple (Workflow API)

• Étape 1 : POST /auth (Login)
  • Body : {"user":"...", "pass":"..."}
  • Assertion : Vérifier HTTP Status == 200.
  • Extraction : Extraire $.token (JSONPath) et le stocker dans la variable AUTH_TOKEN.
• Étape 2 : GET /api/users/me
  • Header : Authorization: Bearer (Réinjection de la variable).
  • Assertion : Vérifier HTTP Status == 200.
  • Assertion : Vérifier JSONBody.email == "user@test.com".

Problème : Les Checkpoints (1.3) sont publics (Internet). Ils ne peuvent pas tester vos applications internes (Intranet, Serveurs dans le LAN/DMZ qui ne sont pas exposés).

Solution

Uptrends vous permet d'installer votre propre sonde (Checkpoint Privé) (un logiciel Windows ou Linux) sur une machine à l'intérieur de votre réseau (LAN ou DMZ).

[INTERNET] <── [FIREWALL] ──> [LAN]
   │                         │
   │ (WAN Checks)            ├─ [Serveur Intranet (192.168.1.50)]
   │                         │
[Uptrends SaaS]              │
   │ (Config)                ├─ [Private Checkpoint (VM Interne)]
   │ (Résultats)             │    │
   └─────────────────────────(Push)┘  │ (Check local)
                                    └────────────────► (Ping 192.168.1.50)

Usage

• Superviser un Intranet (SharePoint, CRM interne).
• Superviser des serveurs internes (Ping, Port TCP) avant qu'ils ne soient visibles par le firewall.
• Superviser des équipements SNMP (Switchs, Routeurs) (voir 5.1).

C'est une fonctionnalité (optionnelle) qui transforme le Monitoring Synthétique (1 test à la fois) en Test de Charge léger (N tests en même temps).

Fonctionnement

Au lieu d'exécuter un "Full Page Check" (FPC) depuis 1 checkpoint, vous demandez à Uptrends d'exécuter 10 FPC simultanément (en "concurrence") depuis 10 checkpoints différents.

Usage

• Simulation de Charge : Simule un "petit" test de charge (ex: 10 utilisateurs concurrents) pour voir l'impact sur le temps de réponse (ex: p(90)).
• Test "Burst" : Vérifie comment le serveur (et le Load Balancer) réagit à un pic soudain de trafic.

Ce n'est pas un remplacement pour un outil de "stress test" (comme JMeter ou k6), mais c'est un bon test de "fumée" (smoke test) pour la performance sous charge.

RUM (Real User Monitoring), ou monitoring "passif", capture les données de performance directement depuis les navigateurs de vos utilisateurs réels.

Fonctionnement (Snippet JS)

1. Vous copiez/collez un snippet JavaScript (fourni par Uptrends) dans le <head> de votre site.
2. Un utilisateur (ex: à Sydney, sur un iPhone) visite votre site.
3. Le script JS (rum.js) se charge, collecte les métriques (Core Web Vitals, chargement...) dans son navigateur.
4. À la fin (ex: onLoad), le script envoie un "beacon" (un paquet de données) aux collecteurs Uptrends.

Données Collectées

Le RUM est puissant car il collecte non seulement la performance, mais aussi le contexte :

• Performance : Temps de chargement, LCP, INP, CLS...
• Contexte : Navigateur (Chrome, Firefox), OS (Windows, iOS), Type d'appareil (Mobile, Desktop), Géolocalisation (Pays, Région).

Le RUM est la source de vérité pour les Core Web Vitals (CWV), car il mesure ce que Google (CrUX) mesure : les vrais utilisateurs.

Dashboards RUM

L'interface RUM permet de "segmenter" (FACET) les données de performance pour trouver les "Long-tail problems" :

"Montre-moi le P75 (Percentile 75) du LCP..."
  ... "uniquement pour les utilisateurs Mobile"
  ... "uniquement en Australie"
  ... "uniquement sur Chrome"
  ... "uniquement sur la page /checkout"

Résultat (Diagnostic) : "Ah, notre LCP est excellent (1.5s) partout, sauf pour les utilisateurs Chrome en Australie (4.8s). C'est un problème de CDN/Routage vers l'Australie."

En plus de la performance, le RUM capture les erreurs "côté client" (Front-end).

Suivi des Erreurs JS

L'agent JS (RUM) agit comme un "try/catch" global (window.onerror). Il capture les exceptions JavaScript non gérées (ex: TypeError, ReferenceError) et les envoie.

Usage : Agrège les erreurs (ex: "'null' is not an object s'est produit 500 fois, 90% sur Safari iOS 15").

Suivi des Requêtes AJAX

L'agent "wrap" (enveloppe) les appels Fetch et XMLHttpRequest. Il monitore :

• Le temps de réponse des appels API (ex: GET /api/data).
• Les échecs (ex: 404 Not Found, 503 Service Unavailable) vus par le client.

C'est le Monitoring "On-Premise" d'Uptrends. Il permet de superviser la santé (CPU, RAM...) de vos serveurs et équipements réseau.

Le système d'alertes d'Uptrends est basé sur deux concepts : les Définitions (Conditions) et l'Escalade (Actions).

1. Définitions d'Alertes (Conditions)

Définit quand une alerte doit se déclencher.

• Simple : Si le moniteur (ex: Ping) est "Unconfirmed" (1 échec) ou "Confirmed" (2+ échecs).
• Basée sur les erreurs : (ex: Erreur SSL, Erreur 404).
• Basée sur la performance (Seuil) : (ex: Temps de Réponse > 5 secondes pendant 3 minutes).

2. Niveaux d'Escalade (Actions)

Définit qui alerter et comment.

Permet de créer des "niveaux" (ex: P1, P2...) basés sur la durée de la panne.

Exemple (Escalade P1) :
- SI (Alerte "Confirmed")
- ALORS (Niveau 1) : Envoyer un (Email) à "Support N1"
- SI (Alerte > 15 minutes)
- ALORS (Niveau 2) : Envoyer un (SMS) + (Slack) à "Support N2"
- SI (Alerte > 1 heure)
- ALORS (Niveau 3) : Appeler (PagerDuty) "Admin Astreinte"

Uptrends s'intègre nativement avec les outils de "dispatching" d'alertes et de collaboration (ChatOps).

Types d'Intégrations (Destinations)

• Email : (Base)
• SMS : (Alerte)
• ChatOps : (Collaboration)
  • Slack
  • Microsoft Teams
• Incident Management (Astreinte) : (Escalade)
  • PagerDuty
  • OpsGenie (Atlassian)
  • VictorOps (Splunk)
• Ticketing (ITSM) :
  • ServiceNow
  • JIRA
• Webhook (Générique) :
  • Envoyer un payload JSON (POST) à n'importe quelle API (ex: votre propre outil interne).

Les Dashboards (Tableaux de bord) sont l'interface de visualisation (Monitoring) d'Uptrends. Ils permettent de combiner des données de Synthetics, RUM, et Infra en une seule vue.

Types de Dashboards (Hubs)

• Synthétics Hub : Vue d'ensemble des moniteurs (Uptime, Transactions...).
• RUM Hub : Vue d'ensemble de l'expérience utilisateur réelle (Vitals, Géo...).
• Infrastructure Hub : Vue d'ensemble des serveurs/switchs.
• Custom Dashboards : Tableaux de bord personnalisés (Drag & Drop).

Statut Public (Public Status Page)

Permet de créer un dashboard public (ex: status.ideolab.com) qui affiche l'état (Up/Down) de vos services (sélectionnés) pour vos clients.

Les "Dashboards" sont pour le temps réel. Les Rapports (Reports) sont pour l'analyse historique (hebdomadaire, mensuelle), souvent utilisés pour le management (SLA).

Fonctionnalités

• Rapports SLA (Service Level Agreement) : Génère un rapport de disponibilité (ex: "Uptime de 99.95% ce mois-ci") et de performance (P90) pour prouver le respect des SLAs.
• Planification (Scheduling) : Permet d'envoyer automatiquement un rapport (ex: "Rapport PDF Hebdomadaire") par email à une liste de destinataires (ex: le client, le manager).
• Export : (PDF, Excel).

Checklist de Démarrage (Nouveau Site)

1. (Synthetics) Configurer un Moniteur "Uptime" (HTTPS) :
   • Intervalle : 1 ou 5 minutes.
   • Checkpoints : Sélectionner au moins 3-5 checkpoints (Géo).
   • Check : Vérifier (Assertion) le code de statut (200) ET la présence d'un mot-clé (ex: "Bienvenue").
2. (Synthetics) Configurer un Moniteur "Full Page Check" (Performance) :
   • Intervalle : 15 ou 30 minutes.
   • Checkpoints : 1 ou 2 (ex: "Paris").
   • Alerting : Mettre une alerte si Temps de chargement > 4 secondes.
3. (RUM) Déployer l'Agent RUM (JS) :
   • Copier/Coller le snippet JS dans le <head> de toutes les pages.
4. (Alerting) Configurer les Intégrations :
   • Ajouter l'intégration Slack (pour le N1/N2) et PagerDuty (pour l'astreinte N3).
   • Configurer les Niveaux d'Escalade.