Surveillance de l'API GraphQL Qui Repère les Échecs Cachés par le HTTP 200

La plupart des implémentations GraphQL renvoient HTTP 200 même en cas d’échec de la requête. Les erreurs se trouvent dans le corps de la réponse — dans le tableau errors, ou sous forme de valeurs null dans l’objet data — pas dans le code d’état. Une surveillance uniquement uptime considère les API GraphQL défaillantes comme saines. Une vraie surveillance GraphQL doit inspecter la charge utile de la réponse. Voir la surveillance REST API →

Envoyez une charge utile de requête spécifique, puis vérifiez le corps de la réponse. Contrôlez si le tableau de premier niveau errors est présent ou rempli, validez les invariants spécifiques à la requête dans la réponse, et signalez les valeurs null dans les champs non nuls. Certains serveurs GraphQL codent les erreurs métiers dans l’objet data plutôt que de peupler errors — les deux signaux sont vérifiés.

Oui. Chaque moniteur exécute une requête ou mutation définie. Surveillez vos mutations les plus critiques (placeOrder, processPayment) individuellement pour suivre la latence par opération, le taux d’erreur, et le taux d’échec partiel.

Tous les schémas d’authentification courants : Bearer Token (le plus commun pour GraphQL), OAuth 2.0 avec rafraîchissement automatique, JWT, API Key, Auth Basic, Signature AWS v4, mTLS, et en-têtes personnalisés. Les secrets sont masqués via Secure Vault. Voir matrice d’authentification →

Oui. Surveillez le point de terminaison supergraph pour vérifier la santé de la passerelle de fédération, et surveillez les points de terminaison de sous-graphes individuels pour isoler quel service échoue quand une requête fédérée échoue. Fonctionne avec Apollo Federation et architectures similaires.

La latence totale de la requête est suivie, avec percentiles P95/P99 par requête. Pour identifier les résolveurs lents individuellement, combinez la surveillance avec votre traçage APM — la surveillance synthétique confirme la lenteur côté client ; l’APM identifie le résolveur goulot d’étranglement.

Oui. Déployez des Agents Privés dans votre VPC ou centre de données — courant pour les services GraphQL backend-for-frontend (BFF) non exposés publiquement.

La surveillance peut inclure des requêtes à différents niveaux de profondeur et complexité pour vérifier que vos limites de throttling et de complexité sont appliquées. Combinez avec votre WAF ou middleware de complexité de requête pour une protection complète.

Les abonnements GraphQL utilisent généralement WebSocket — consultez notre surveillance WebSocket pour l’établissement de la connexion, la livraison des messages et les vérifications de keepalive.

Surveillez le point de terminaison supergraph pour vérifier que la passerelle de fédération est saine ET surveillez séparément les points de terminaison des sous-graphes individuels afin d’isoler quel service aval échoue lorsqu’une requête fédérée échoue. Les deux moniteurs partagent des itinéraires d’alerte pour une réponse consolidée aux incidents.

Les abonnements GraphQL utilisent le transport WebSocket. Utilisez notre produit de surveillance WebSocket pour valider que la connexion d’abonnement s’établit correctement, reçoit les événements attendus et reste active pendant les sessions de longue durée.

Oui. Configurez les identifiants de requête persistante (Apollo Persisted Queries ou hachages de style Relay) dans la requête et Dotcom-Monitor les enverra comme référence d’opération plutôt que la chaîne de requête complète.

Créez des moniteurs à des profondeurs et complexités de requêtes croissantes pour vérifier que votre middleware de limite de complexité applique correctement le seuil. Associez la configuration du moniteur aux règles de complexité de votre serveur GraphQL.