GraphQL APIモニタリング HTTP 200が隠す失敗を検出

ほとんどのGraphQL実装は、クエリが失敗してもHTTP 200を返します。失敗はステータスコードではなく、レスポンスボディ内のerrors配列やdataオブジェクト内のnullとして存在します。稼働時間のみの監視では失敗しているGraphQL APIが正常と見なされます。実際のGraphQL監視ではレスポンスペイロードの検査が必要です。REST API監視を見る →

特定のクエリペイロードを送信し、レスポンスボディに対して検証を行います。最上位のerrors配列の存在や中身の有無の確認、レスポンス内のクエリ固有のデータ不変条件の検証、非nullフィールドにおけるnullの検出を行います。一部のGraphQLサーバーはエラーを埋めずにdataオブジェクト内にドメイン失敗をエンコードするため、両方のシグナルをチェックします。

はい。各モニターは定義されたクエリやミューテーションペイロードを実行します。最も重要なミューテーション（placeOrder、processPaymentなど）を個別に監視して、操作ごとのレイテンシ、エラー率、部分的失敗率を追跡できます。

一般的なすべての認証方式：Bearer Token（GraphQLで最も一般的）、自動更新付きOAuth 2.0、JWT、APIキー、ベーシック認証、AWS Signature v4、mTLS、およびカスタムヘッダー。シークレットはSecure Vaultでマスクされています。認証マトリックスを見る →

はい。スーパーグラフエンドポイントを監視して連合ゲートウェイが正常かどうかを検証し、個々のサブグラフエンドポイントを監視して連合クエリが破損した際にどのサービスが失敗しているかを特定できます。Apollo Federationや類似のアーキテクチャに対応しています。

クエリ全体のレイテンシを追跡し、クエリごとにP95／P99パーセンタイルを計測します。個別の遅いリゾルバを特定するには、APMトレーシングとの併用を推奨します。合成監視は顧客が感じる遅延を確認し、APMはどのリゾルバがボトルネックかを特定します。

はい。VPCやデータセンター内にプライベートエージェントを展開可能です。これは公開されていないバックエンド・フォー・フロントエンド（BFF）GraphQLサービスに一般的です。

監視にはさまざまな深さや複雑度のクエリを含めることができ、スロットリングや複雑度制限が適用されているかを検証できます。WAFやクエリ複雑度ミドルウェアと組み合わせて完全な保護を実現してください。

GraphQLのサブスクリプションは通常WebSocketを使用します。接続確立、メッセージ配信、キープアライブチェックについては、WebSocket監視をご参照ください。

スーパグラフのエンドポイントを監視してフェデレーションゲートウェイの健全性を確認し、個々のサブグラフのエンドポイントも別々に監視して、フェデレーテッドクエリの障害時にどの下流サービスが失敗しているかを特定します。両方のモニターは統合インシデント対応のためにアラートルートを共有します。

GraphQLのサブスクリプションはWebSocketトランスポートを使用します。当社のWebSocket監視製品を使って、サブスクリプションの接続が正しく確立され、期待するイベントを受信し、長時間のセッションで接続が維持されていることを検証してください。

はい。永続化クエリ識別子（Apollo Persisted QueriesまたはRelayスタイルのハッシュ）をリクエストに設定すると、Dotcom-Monitorは完全なクエリ文字列の代わりにそれらを操作参照として送信します。

クエリの深さや複雑さを段階的に増やしてモニターを構築し、複雑さ制限のミドルウェアが閾値を正しく適用しているかを検証してください。GraphQLサーバーの複雑さルールとモニター設定を組み合わせてください。