Surveillance des points de terminaison

Qu'est-ce qu'un "endpoint" ?

Un endpoint est tout ce qui est adressable sur Internet et peut être interrogé afin de vérifier sa disponibilité. Le cas classique est l’URL d’une page web — mais dans les infrastructures modernes, les choses dont vous prenez soin sont bien plus variées : API REST, endpoints GraphQL, serveurs de messagerie, écouteurs de bases de données, files de messages, ports de health-check de conteneurs, panneaux d’administration internes, destinataires de webhooks. DiagnoSEO Uptime Monitoring les traite de manière uniforme : vous définissez ce que signifie « sain » pour cet endpoint, vous planifiez la fréquence des vérifications, vous recevez une alerte en cas de panne.

Cette page décrit chaque type d’endpoint pris en charge par l’outil, à quoi il sert et quelles informations apporte sa surveillance.

Endpoints HTTP / HTTPS (sites web)

Le cas par défaut. Vous saisissez https://example.com et le moniteur effectue une requête GET à l'intervalle défini (1 minute, 5, 10, 30, ou 60 minutes selon le plan). Un contrôle réussi signifie : connexion TCP établie, handshake TLS terminé (pour HTTPS), une réponse HTTP reçue avec le code d’état attendu (par défaut : 2xx ou 3xx), et éventuellement un mot-clé présent (ou absent) dans le corps de la réponse. Un contrôle enregistre le Time To First Byte, le temps total de réponse, la taille du contenu, la chaîne des redirections et l’ensemble complet des en-têtes de réponse.

Les endpoints HTTP sont adaptés pour : les sites marketing, blogs, boutiques e-commerce, dashboards SaaS, portails de documentation — partout où les utilisateurs naviguent avec un navigateur web.

Endpoints API (REST / GraphQL / JSON-RPC)

Les API nécessitent plus que « a-t-il répondu » — elles ont besoin de « a-t-il répondu correctement ». Vous configurez le moniteur avec une méthode HTTP personnalisée (GET, POST, PUT, DELETE, PATCH), des en-têtes personnalisés (tokens d’authentification, content-type), un body de requête (payload JSON pour POST/PUT) et des assertions JSON sur la réponse (data.status doit être égal à "ok", result.count doit être supérieur à 0, errors[] doit être vide). Une API qui retourne un HTTP 200 avec un payload mauvais est le pire type de panne — cela a l’air sain pour un moniteur naïf mais cela coupe tous les clients. Les assertions JSON permettent de les détecter.

Voir le guide de surveillance des API pour les détails de configuration et la syntaxe des assertions.

Endpoints ports TCP

Pour les services non-HTTP : SMTP (port 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), écouteurs de bases de données (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), ports d’applications personnalisés. Le moniteur ouvre une connexion TCP vers le host:port fourni et signale un succès si la connexion est acceptée dans la fenêtre du timeout. Sans handshake au niveau du protocole — simplement « le démon écoute-t-il ».

C’est le moniteur approprié pour tout service basé sur TCP où la disponibilité compte et où vous n’avez pas besoin de contrôles au niveau du protocole. Pour vérifier une bannière SMTP ou effectuer des contrôles à la couche de requête de base de données, utilisez un moniteur heartbeat (votre service nous pingue lorsqu’il est sain, voir surveillance cron-job / heartbeat).

Endpoints ping (ICMP)

Contrôle de la disponibilité au niveau couche 3. Le moniteur envoie une requête ICMP echo vers le nom d’hôte ou IP cible et attend une réponse. Utile pour les routeurs, switches, appareils IoT, tout ce qui répond au ping sans faire tourner HTTP. Attention, de nombreux fournisseurs cloud (AWS, GCP, Azure) bloquent par défaut ICMP au niveau du security group même si l’hôte est par ailleurs sain — pour les workloads cloud, privilégiez les contrôles HTTP ou les ports TCP.

Endpoints hostname / DNS

Surveillance de résolution DNS. L’outil résout périodiquement les enregistrements A, AAAA, MX, NS, TXT et CNAME de votre domaine, fait un snapshot des résultats et alerte si l’un d’eux change. Cela permet de détecter : prises de contrôle DNS non autorisées, erreurs de configuration accidentelles lors de la migration d’un fournisseur DNS, services externes mettant à jour leurs endpoints sans notification (votre CDN qui bascule des blocs IP, par exemple), des enregistrements MX effacés à cause d’une faute de frappe.

La surveillance DNS ne concerne pas la disponibilité — votre fournisseur DNS est presque toujours plus fiable que l’origine. Il s’agit de détecter les changements. Voir la surveillance des changements DNS pour la description complète.

Endpoints certificats SSL

Chaque endpoint HTTPS bénéficie d’une surveillance automatique SSL en plus de son contrôle d’uptime. L’outil lit le certificat, analyse la période de validité et l’émetteur, et vous avertit à 30, 14, 7, 3 et 1 jour avant expiration. Voir la surveillance des certificats SSL pour plus de détails.

Endpoints expiration de domaine

Pour chaque URL surveillée, l’outil interroge également le WHOIS une fois par jour et suit la date d’expiration de l’enregistrement du domaine. Les alertes se déclenchent aux mêmes seuils que pour le SSL (30/14/7/3/1 jours). Les oublis de renouvellement sont catastrophiques — le domaine devient sans propriétaire et quelqu’un peut l’enregistrer dès la fin de la période de grâce. Voir la surveillance de l’expiration de domaine.

Choix du bon type d’endpoint

Si vous ne savez pas quel type de moniteur utiliser, commencez avec HTTP/HTTPS pour tout ce qui a une interface web, port TCP pour le reste, et ajoutez des contrôles heartbeat pour les tâches batch sans exposition réseau. Vous pouvez surveiller la même cible via différents types — par exemple, un check de port TCP sur le 443 détectera « le serveur est en ligne, mais le handshake TLS est cassé » que le check HTTP à la même URL relèvera également, tandis qu’un heartbeat de votre propre agent de monitoring interne confirmera que la logique de l’application fonctionne réellement.

Questions fréquentes

• Qu'est-ce qu'un endpoint ?

  Tout ce qui est adressable sur Internet : URLs HTTP/HTTPS, API REST, ports TCP (SMTP, MySQL, personnalisés), noms d’hôtes pour ping, enregistrements DNS, certificats SSL et enregistrements d’enregistrement de domaine. Configurez un moniteur par type d’endpoint.

• Faut-il utiliser un check HTTP ou un port TCP ?

  HTTP est un bon choix par défaut pour tout service web. Le port TCP est meilleur pour les services non-HTTP (bases de données, serveurs de courrier, protocoles personnalisés) lorsque vous vous souciez uniquement de « est-ce que le démon accepte les connexions ». Utilisez TCP pour la disponibilité bas niveau, HTTP pour « est-ce que l’application fonctionne vraiment correctement ».

• Qu’est-ce qui différencie les moniteurs heartbeat (cron-job) ?

  Le mode heartbeat est inversé — au lieu que nous interrogions votre service, c’est votre service qui nous pingue à une URL connue. Si nous ne recevons pas de ping dans la fenêtre attendue, nous vous alertons. Utilisé pour les cron jobs, tâches batch et tout ce qui tourne sur une planification sans exposition réseau à contrôler.

• Un URL peut-il avoir plusieurs moniteurs ?

  Oui. Vous pouvez surveiller la même cible par différents types de contrôles — par exemple, un check HTTP pour la disponibilité complète plus un check TCP port 443 qui capte les problèmes de handshake TLS. Chaque moniteur fonctionne et alerte indépendamment.

• Dois-je surveiller SSL et le domaine séparément ?

  Non — chaque endpoint HTTPS bénéficie automatiquement d’une surveillance SSL en plus de son contrôle d’uptime, et chaque URL surveillée bénéficie d’un suivi quotidien d’expiration de domaine. Les deux sont inclus, sans configuration supplémentaire. La surveillance de domaine est par domaine — plusieurs moniteurs sur un même domaine partagent les données WHOIS.