gRPC

Présentation

Le monitor gRPC appelle la méthode standard grpc.health.v1.Health/Check de votre service et lit son statut de service. Contrairement à un check TCP sur le même port, il prouve que toute la pile fonctionne — TCP, TLS, HTTP/2 et gRPC lui-même — et que le service se déclare opérationnel.

Disponible à partir du plan Pro.

Format de la cible

La cible du monitor s’écrit en une seule chaîne :

[schéma://]hôte:port[/service]

Partie	Signification
schéma	grpcs ou https → TLS. grpc ou http → clair. Omis → TLS si le port est 443, clair sinon.
hôte:port	Où le service écoute. Sans port, 443 est utilisé en TLS et 80 en clair.
/service	Nom de service optionnel transmis dans la requête de santé. Omettez-le pour la santé globale du serveur, conformément au protocole de health-checking.

Exemples :

grpcs://api.example.com:443              santé globale du serveur, en TLS
grpcs://api.example.com/orders.v1.Orders un service précis
grpc://internal.svc:9090                 en clair, dans le cluster
api.example.com:443                      TLS déduit du port

Comment le résultat est décidé

Réponse de santé	Résultat
SERVING	Up
NOT_SERVING	Down, avec le statut rapporté dans l’erreur
SERVICE_UNKNOWN	Down — le nom passé dans /service n’est pas enregistré sur ce serveur
Unimplemented	Up — le serveur a répondu en gRPC mais n’expose pas de service de santé. Le transport, HTTP/2 et la pile gRPC fonctionnent, ce qu’un check d’uptime cherche justement à établir ; l’erreur est tout de même enregistrée pour être visible dans le journal.
Erreur de connexion, TLS ou timeout	Down

La fenêtre de réessai et la règle de majorité s’appliquent ensuite exactement comme pour n’importe quel autre monitor — voir Statut & uptime.

Paramètres

Paramètre	Description	Valeur par défaut
Cible	[schéma://]hôte:port[/service]	—
Port	Remplace le port de la cible	celui de la cible
Intervalle	Fréquence de vérification	le plus court permis par le plan
Timeout	Budget fixe du check (non configurable)	5s
Régions	Points de contrôle	une, selon votre plan

Cas d’usage

• API internes — Un backend gRPC sans surface HTTP à vérifier.
• Service mesh — Confirmer qu’un nom de service précis est enregistré et opérationnel, pas seulement que le port accepte des connexions.
• Terminaison TLS — Une cible grpc:// en clair et une grpcs:// sur le même service permettent de distinguer un problème de transport d’un problème applicatif.

Services privés

Un service gRPC injoignable depuis Internet se surveille depuis un agent privé — le check est identique, seul l’agent qui l’exécute change. Les régions publiques refusent les cibles qui résolvent vers des adresses privées.

Métriques

La durée complète de l’appel (connexion + TLS + appel de santé) est enregistrée à chaque vérification et alimente le même graphique de latence, les mêmes percentiles et les mêmes alertes qu’un monitor HTTP.