Surveillance du temps de réponse

Pourquoi le temps de réponse mérite sa propre alerte

Les alertes de disponibilité standard reposent sur un signal binaire : en ligne ou hors ligne. La zone grise entre les deux – en ligne, mais lentement – est là où survient la plupart des défaillances modernes. Une requête mal configurée vers la base de données commence à durer 4 secondes au lieu de 50 ms. Une fuite de mémoire provoque des pics dans le ramasse-miettes. L’API externe sollicitée par le backend commence à vaciller. Aucune de ces situations ne rend le site totalement inutilisable, mais elles le rendent inutilisable en pratique – et ce sont des signaux précoces d’un incident majeur à venir, parfois quelques heures à l’avance.

La surveillance du temps de réponse détecte le ralentissement avant qu’il ne devienne une panne. Vous configurez un seuil par moniteur, et lorsque le temps de réponse le dépasse lors de plusieurs vérifications consécutives, vous recevez une alerte. Avant que l’alerte ne soit envoyée, vous avez le temps d’enquêter, de scaler, de throttler l’appel problématique ou de revenir sur le déploiement à l’origine du problème.

Comment fonctionnent les seuils dans DiagnoSEO Uptime Monitoring

Chaque moniteur peut être configuré avec deux paramètres : rt_threshold_ms et rt_threshold_breaches. Le premier est le temps de réponse en millisecondes que vous jugez acceptable. Le second est le nombre de contrôles consécutifs nécessaires pour enclencher l’alerte si ce seuil est dépassé. Par défaut, le seuil est désactivé et le nombre de dépassements requis est fixé à trois.

Cette conception à deux paramètres protège contre les faux positifs. Des fluctuations réseau se produisent. Des pauses lors du ramassage des ordures aussi. Un pic unique à 1 seconde alors que le temps normal est de 200 ms ne mérite pas de réveiller quelqu’un à 3 h du matin. Mais trois réponses consécutives d’une seconde, oui – c’est un ralentissement persistant, pas un simple sursaut. Choisissez le seuil en fonction du comportement normal observé, plus une marge confortable : si le p95 est normalement à 400 ms, définissez le seuil à 1000 ms. Si le p95 est à 50 ms (API interne), seuil de 200 ms.

Avec quoi cela fonctionne-t-il bien ?

Les alertes de temps de réponse sont les plus efficaces lorsqu’elles sont combinées à d’autres signaux du moniteur. Une vue complète : le seuil du temps de réponse indique que le système se dégrade ; le code HTTP indique quand il casse réellement ; les alertes SSL/domaine – les incidents liés au temps ; les alertes de changement DNS – la dérive de configuration. Quatre signaux réunis sur le même moniteur transforment un simple « ça fonctionne » binaire en une observabilité totale.

Le tableau de bord y contribue également. Chaque moniteur affiche une sparkline des derniers temps de réponse – un indicateur visuel rapide des schémas de dégradation. La vue détaillée affiche les moyennes sur 24h, 7j et 30j. Si vous voyez la moyenne grimper semaine après semaine – c’est un signal précoce qui mérite une analyse, avant de dépasser le seuil d’alerte.

Seuils pratiques selon le type de page

• Pages d’atterrissage marketing: 1500 ms est raisonnable. Elles sont souvent lourdes en images et scripts de tracking ; la rapidité absolue importe moins que la stabilité.
• Pages produit / catégories e-commerce: 800–1200 ms. Un e-commerce lent tue la conversion ; des seuils plus serrés permettent de repérer plus vite les problèmes.
• Tableaux de bord applicatifs: 500–800 ms. Les utilisateurs attendent de la réactivité. Un tableau de bord lent donne l’impression d’un produit défaillant.
• API publiques: 200–400 ms pour des endpoints simples, plus pour des calculs lourds. Segmentez-les.
• Health checks de microservices internes: 50–100 ms. Ils doivent être quasiment instantanés ; une lenteur signale presque toujours un vrai souci.

Quel que soit votre choix, ne le définissez pas une fois pour toutes. Réévaluez-le chaque trimestre en fonction des tendances que vous observez réellement. Si vous recevez constamment des alertes de dépassement qui ne reflètent pas de vrais problèmes – le seuil est trop strict. Si une panne survient sans alerte préalable – le seuil était trop large.

Routage des alertes

Les alertes de dépassement de seuil empruntent les mêmes canaux que les alertes de panne/rétablissement : Email, Telegram, Slack, Discord, SMS. Elles respectent la même fenêtre de silence nocturne. Elles sont journalisées dans la même table d’alertes. La seule différence est le type d’événement (« threshold » au lieu de « down ») et le contenu du message – indique le temps de réponse actuel et le seuil configuré, afin de visualiser immédiatement l’ampleur du dépassement.

Configuration

Éditez n’importe quel moniteur. Dans le formulaire, réglez : « Seuil de temps de réponse (ms) » sur la valeur souhaitée. Ajustez si besoin « dépassements consécutifs » si la valeur par défaut de 3 ne vous convient pas. Enregistrez. Dès le prochain cycle, chaque contrôle comparera le temps de réponse au seuil, et une notification sera envoyée après le nombre de dépassements consécutifs configuré.

Questions fréquentes

• Quelle mesure du temps de réponse est enregistrée ?

  Time To First Byte (TTFB) — millisecondes entre l’envoi de la requête et la réception du premier octet de la réponse. Ainsi que le temps total pour télécharger la réponse complète. Le TTFB est la mesure unique la plus utile pour la santé d’un serveur.

• Quel est un « bon » temps de réponse ?

  Ça dépend de la localisation et du contenu. Pour un site statique avec CDN : en dessous de 100 ms, c’est excellent ; en dessous de 300 ms, c’est correct. Pour des applications dynamiques : en dessous de 500 ms, c’est bien ; en dessous de 1000 ms, acceptable ; au-dessus de 2000 ms, c’est lent. Comparez avec vos propres historiques plutôt qu’avec des valeurs absolues.

• Puis-je recevoir une alerte si le temps de réponse dépasse le seuil ?

  Oui. Chaque moniteur dispose d’un seuil de temps de réponse optionnel. Si 3 vérifications consécutives dépassent le seuil, vous recevez une alerte « slow response ». L’exigence de 3 contrôles prévient les fausses alertes dues à un simple sursaut réseau.

• D’où est mesuré le temps de réponse ?

  Depuis nos 13 points de vérification géographiques (Europe, Amérique du Nord, Asie, Amérique du Sud, Océanie). Pour un moniteur mono-région, les temps proviennent de la région la plus proche. Pour un multi-région, chaque région est mesurée séparément – utile pour détecter les problèmes régionaux de CDN.

• Le tableau de bord affiche-t-il les tendances de temps de réponse ?

  Oui — moyenne mobile sur 30 jours, maximum/minimum quotidiens et percentiles (p50, p95). Pratique pour la planification de capacité : si votre p95 passe de 800 ms à 1500 ms en un mois, vos serveurs commencent à être surchargés même si la disponibilité reste à 100%.