GraphQL API モニタリング が隠す失敗をキャッチする HTTP 200

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

特定のクエリペイロードを送信し、その後レスポンスボディに対してアサーションを行います。トップレベルのerrors配列が存在または入力されているか、レスポンス内のクエリ固有のデータ不変条件を検証し、非nullフィールド内のnullをフラグします。一部のGraphQLサーバーはエラーを入力せずにドメインの失敗をdataオブジェクト内にエンコードするため、両方のシグナルをチェックします。

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

すべての一般的な認証スキーム：Bearerトークン（GraphQLで最も一般的）、自動更新付きOAuth 2.0、JWT、APIキー、ベーシック認証、AWSシグネチャ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サーバーの複雑度ルールと組み合わせて使用します。