Surveillance API GraphQL Qui détecte les échecs que le HTTP 200 masque

La plupart des implémentations GraphQL retournent HTTP 200 même lorsque la requête échoue. Les erreurs se trouvent dans le corps de la réponse — dans le tableau errors, ou sous forme de nulls dans l’objet data — et non dans le code status. La surveillance uniquement de la disponibilité marque les API GraphQL en échec comme opérationnelles. 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 faites une assertion sur le corps de la réponse. Vérifiez si le tableau errors de premier niveau est présent ou peuplé, validez les invariants spécifiques à la requête dans la réponse et signalez les valeurs nulles dans des champs non-nullables. Certains serveurs GraphQL encodent les échecs de domaine 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 par opération, le taux d’erreur et le taux d’échec partiel.

Tous les schémas d’authentification courants : Bearer Token (le plus courant pour GraphQL), OAuth 2.0 avec rafraîchissement automatique, JWT, clé API, Basic Auth, 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 de terminaison supergraph pour vérifier que la passerelle de fédération est saine, et surveillez les points de terminaison des sous-graphes individuels pour isoler quel service échoue lorsqu’une requête fédérée échoue. Fonctionne avec Apollo Federation et des architectures similaires.

La latence totale des requêtes est suivie, avec des percentiles P95/P99 par requête. Pour identifier les résolveurs individuels lents, associez la surveillance à 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 centre de données — fréquent pour les services GraphQL backend-for-frontend (BFF) qui ne sont pas exposés publiquement.

La surveillance peut inclure des requêtes à différentes profondeurs et niveaux de complexité pour vérifier que vos limites de limitation et de complexité sont appliquées. Associez 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 connexion, la livraison de 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 pour isoler quel service en aval échoue lorsqu’une requête fédérée échoue. Les deux moniteurs partagent les voies d’alerte pour une réponse aux incidents consolidée.

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 des identifiants de requêtes persistantes (Apollo Persisted Queries ou hachages style Relay) dans la requête et Dotcom-Monitor les enverra comme référence d’opération plutôt que comme chaîne de requête complète.

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