Surveillance de l’API GraphQL Qui Détecte les Échecs Que le HTTP 200 Cache

La plupart des implémentations GraphQL retournent un HTTP 200 même lorsque la requête échoue. Les échecs se trouvent dans le corps de la réponse — dans le tableau errors, ou sous forme de valeurs nulles dans l’objet data — pas dans le code de statut. La surveillance basée uniquement sur la disponibilité marque les API GraphQL défaillantes comme saines. Une vraie surveillance GraphQL doit inspecter la charge utile de la réponse. Voir la surveillance d’API REST →

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

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

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

Oui. Surveillez le point d’accès supergraph pour vérifier que la passerelle de fédération est saine, et surveillez les points d’accès des sous-graphes individuels pour isoler quel service échoue lorsqu’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 les percentiles P95/P99 par requête. Pour identifier les résolveurs individuels lents, combinez la surveillance avec votre traçage APM — la surveillance synthétique confirme la lenteur côté client; l’APM confirme quel résolveur est le goulot d’étranglement.

Oui. Déployez des Agents Privés dans votre VPC ou datacenter — courant pour les services GraphQL backend-for-frontend (BFF) qui ne sont pas exposés publiquement.

La surveillance peut inclure des requêtes à différents niveaux de profondeur et de complexité pour vérifier que vos limites de throttle 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 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 pour isoler quel service en aval échoue lorsqu’une requête fédérée rencontre un problème. Les deux moniteurs partagent des routes 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 lors de sessions de longue durée.

Oui. Configurez les identifiants de requête persistante (Apollo Persisted Queries ou hachages de type 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 à une profondeur et une complexité croissantes pour vérifier que votre middleware de limitation de complexité applique correctement le seuil. Associez la configuration du moniteur à vos règles de complexité du serveur GraphQL.