CloudWatch を使用して GraphQL APIデータをモニタリングおよびログに記録する - AWS AppSync

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

CloudWatch を使用して GraphQL APIデータをモニタリングおよびログに記録する

CloudWatch メトリクスとログAPIを使用して、GraphQL の CloudWatch ログ記録とデバッグを行うことができます。これらのツールを使用すると、デベロッパーはパフォーマンスのモニタリング、問題のトラブルシューティング、GraphQL オペレーションの効果的な最適化を行うことができます。

CloudWatch メトリクスは、APIパフォーマンスと使用状況をモニタリングするための幅広いメトリクスを提供するツールです。これらのメトリクスは、主に 2 つのカテゴリに分類されます。

  1. 一般的なAPIメトリクス: これには、クライアント4XXErrorとサーバーのエラー5XXErrorの追跡、応答時間Latencyの測定、合計API呼び出しRequestsのモニタリング、リソースの使用状況の追跡TokensConsumedのための と が含まれます。

  2. リアルタイムサブスクリプションメトリクス: これらのメトリクスは、 WebSocket 接続とサブスクリプションアクティビティに焦点を当てています。これには、接続リクエスト、成功した接続、サブスクリプション登録、メッセージ発行、アクティブな接続とサブスクリプションのメトリクスが含まれます。

このガイドでは、リゾルバーのパフォーマンス、データソースインタラクション、個々の GraphQL オペレーションに関するより詳細なデータを提供する拡張メトリクスも紹介しています。これらのメトリクスはより深いインサイトを提供しますが、追加コストが発生します。

CloudWatch Logs は、GraphQL のログ記録機能を有効にするツールですAPIs。ログは の 2 つのレベルで設定できますAPI。

  1. リクエストレベルのログ: HTTPヘッダー、GraphQL クエリ、オペレーション概要、サブスクリプション登録など、リクエスト全体の情報をキャプチャします。

  2. フィールドレベルのログ: リクエストとレスポンスのマッピング、各フィールドのトレース情報など、個々のフィールド解決に関する詳細情報を提供します。

ログ記録の設定、ログエントリの解釈、トラブルシューティングと最適化にログデータを使用できます。 は、クエリの実行、解析、検証、およびフィールド解決データを明らかにするさまざまなログタイプ AWS AppSync を提供します。

セットアップと設定

GraphQL で自動ログ記録を有効にするにはAPI、 AWS AppSync コンソールを使用します。

  1. にサインイン AWS Management Console し、AppSyncコンソール を開きます。

  2. APIs ページで、GraphQL の名前を選択しますAPI。

  3. APIのホームページのナビゲーションペインで、設定 を選択します。

  4. [ログ記録] で以下を行います。

    1. [ログを有効にする] をオンにします。

    2. リクエストレベルの詳細なロギングを行うには、[詳細な内容を含める] のチェックボックスをオンにします。(オプション)

    3. [フィールドリゾルバーのログレベル] で、希望するフィールドレベルのロギングレベル ([なし][エラー]、または [すべて]) を選択します。(オプション)

    4. 「既存のロールを作成または使用する」で「ロールを新規作成」を選択し、 が AWS AppSync にログを書き込むことを許可する新しい AWS Identity and Access Management (IAM) を作成します CloudWatch。または、既存のロールを選択して、 AWS アカウント内の既存のIAMロールの Amazon リソースネーム (ARN) を選択します。

  5. [保存] を選択します。

手動IAMロール設定

既存のIAMロールを使用する場合、ロールは にログ AWS AppSync を書き込むために必要なアクセス許可を付与する必要があります CloudWatch。これを手動で設定するには、 がログを書き込むときにロールを引き受けARNられるように AWS AppSync 、サービスロールを指定する必要があります。

IAM コンソール で、次の定義AWSAppSyncPushToCloudWatchLogsPolicyを持つ名前で新しいポリシーを作成します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "*" } ] }

次に、 という名前の新しいロールを作成しAWSAppSyncPushToCloudWatchLogsRole、新しく作成されたポリシーをロールにアタッチします。このロールの信頼関係を次のように編集します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "appsync.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }

ロールをコピーARNし、 AWS AppSync GraphQL のログ記録を設定するときに使用しますAPI。

CloudWatch メトリクス

CloudWatch メトリクスを使用して、HTTPステータスコードやレイテンシーの原因となる可能性のある特定のイベントをモニタリングし、アラートを提供できます。次のメトリクスが出力されます。

4XXError

クライアントの設定が正しくないためにリクエストが無効になったために発生するエラー。通常、GraphQL を実行する外部の任意の場所で、これらのエラーが発生します。例えば、これらのエラーは、リクエストに誤ったJSONペイロードや誤ったクエリが含まれている場合、サービスがスロットリングされている場合、または認証設定が誤って構成されている場合に発生する可能性があります。

単位: カウント これらのエラーの出現総数を取得するために、Sum 統計を使用します。

5XXError

GraphQL クエリの 実行中に発生したエラー。例えば、空のスキーマや不正確なスキーマに対してクエリを実行した場合に発生する可能性があります。また、Amazon Cognito ユーザープール ID または AWS リージョンが有効でない場合にも発生する可能性があります。または、リクエストの処理中に で問題 AWS AppSync が発生した場合にも発生する可能性があります。

単位: カウント これらのエラーの出現総数を取得するために、Sum 統計を使用します。

Latency

がクライアントからリクエスト AWS AppSync を受信してから、クライアントにレスポンスを返すまでの時間。エンドデバイスに到達するレスポンスに発生したネットワークレイテンシーは含まれません。

単位: ミリ秒 予測されるレイテンシーを評価するために Average 統計を使用します。

Requests

アカウントAPIs内のすべての が処理したリクエスト (クエリ + ミューテーション) のリージョン別の数。

単位: カウント 特定のリージョンで処理されたすべてのリクエストの数。

TokensConsumed

トークンは、Request が使用するリソースの量 (処理時間と使用量) に基づいて Requests に割り当てられます。通常、それぞれの Request が 1 つのトークンを消費します。ただし、Request が大量のリソースを消費する場合には、必要に応じて追加のトークンが割り当てられます。

単位: カウント 特定のリージョンで処理されたリクエストに割り当てられるトークンの数。

NetworkBandwidthOutAllowanceExceeded
注記

AWS AppSync コンソールのキャッシュ設定ページで、キャッシュヘルスメトリクスオプションを使用すると、このキャッシュ関連のヘルスメトリクスを有効にできます。

スループットが集約帯域幅制限を超えたためにネットワークパケットがドロップされました。これは、キャッシュ設定のボトルネックを診断するのに役立ちます。データは、 appsyncCacheNetworkBandwidthOutAllowanceExceededメトリクスAPI_Idで を指定APIすることで、特定の について記録されます。

単位: カウント ID でAPI指定された の帯域幅制限を超えた後にドロップされたパケットの数。

EngineCPUUtilization
注記

AWS AppSync コンソールのキャッシュ設定ページで、キャッシュヘルスメトリクスオプションを使用すると、このキャッシュ関連のヘルスメトリクスを有効にできます。

Redis OSSプロセスに割り当てられたCPU使用率 (パーセンテージ)。これは、キャッシュ設定のボトルネックを診断するのに役立ちます。データは、 appsyncCacheEngineCPUUtilizationメトリクスAPI_Idで を指定APIすることで、特定の について記録されます。

単位 : パーセント 。ID でAPI指定された の Redis OSSプロセスで現在使用されているCPU割合。

リアルタイムサブスクリプション

すべてのメトリクスは 1 つのディメンション G raphQLAPIIdで出力されます。つまり、すべてのメトリクスは GraphQL と結合されますAPIIDs。以下のメトリクスは、純粋な の GraphQL サブスクリプションに関連しています WebSockets。

ConnectRequests

成功した試行と失敗した試行の両方を含む AWS AppSync、 に対して行われた WebSocket 接続リクエストの数。

単位: カウント 接続リクエストの総数を取得するために Sum 統計を使用します。

ConnectSuccess

への正常な WebSocket 接続の数 AWS AppSync。サブスクリプションなしで接続することは可能です。

単位: カウント 成功した接続の出現総数を取得するために、Sum 統計を使用します。

ConnectClientError

クライアント側のエラー AWS AppSync により によって拒否された WebSocket 接続の数。これは、サービスがスロットリングされているか、承認設定が正しく構成されていないことを意味する可能性があります。

単位: カウント クライアント側の接続エラーの出現総数を取得するために、Sum 統計を使用します。

ConnectServerError

接続の処理 AWS AppSync 中に発生したエラーの数。これは通常、予期しないサーバー側の問題が発生した場合に発生します。

単位: カウント サーバー側の接続エラーの出現総数を取得するために、Sum 統計を使用します。

DisconnectSuccess

からの WebSocket 正常な切断の数 AWS AppSync。

単位: カウント 成功した切断の出現総数を取得するために、Sum 統計を使用します。

DisconnectClientError

接続の WebSocket切断 AWS AppSync 中に発生したクライアントエラーの数。

単位: カウント 切断エラーの出現総数を取得するために、Sum 統計を使用します。

DisconnectServerError

接続の WebSocket切断 AWS AppSync 中に発生したサーバーエラーの数。

単位: カウント 切断エラーの出現総数を取得するために、Sum 統計を使用します。

SubscribeSuccess

AWS AppSync を通じて に正常に登録されたサブスクリプションの数 WebSocket。サブスクリプションがなくても接続することはできますが、接続せずにサブスクリプションを持つことはできません。

単位: カウント 成功したサブスクリプションの出現総数を取得するために、Sum 統計を使用します。

SubscribeClientError

クライアント側のエラー AWS AppSync により によって拒否されたサブスクリプションの数。これは、JSONペイロードが正しくない場合、サービスがスロットリングされている場合、または認証設定が誤って構成されている場合に発生する可能性があります。

単位: カウント クライアント側のサブスクリプションエラーの出現総数を取得するために、Sum 統計を使用します。

SubscribeServerError

サブスクリプションの処理 AWS AppSync 中に発生したエラーの数。これは通常、予期しないサーバー側の問題が発生した場合に発生します。

単位: カウント サーバー側のサブスクリプションエラーの出現総数を取得するために、Sum 統計を使用します。

UnsubscribeSuccess

正常に処理されたサブスクリプション解除リクエストの数。

単位: カウント 成功したサブスクリプション解除リクエストの出現総数を取得するために、Sum 統計を使用します。

UnsubscribeClientError

クライアント側のエラー AWS AppSync により によって拒否されたサブスクリプション解除リクエストの数。

単位: カウント クライアント側のサブスクリプション解除リクエストのエラーの出現総数を取得するために、Sum 統計を使用します。

UnsubscribeServerError

サブスクリプション解除リクエストの処理 AWS AppSync 中に発生したエラーの数。これは通常、予期しないサーバー側の問題が発生した場合に発生します。

単位: カウント サーバー側のサブスクリプション解除リクエストのエラーの出現総数を取得するために、Sum 統計を使用します。

PublishDataMessageSuccess

正常に発行されたサブスクリプションイベントメッセージの数。

単位: カウント 正常に発行されたサブスクリプションイベントメッセージの合計を取得するために、Sum 統計を使用します。

PublishDataMessageClientError

クライアント側のエラーのために発行に失敗したサブスクリプションイベントメッセージの数。

Unit: カウント クライアント側のサブスクリプションイベント発行エラーの出現総数を取得するために、Sum 統計を使用します。

PublishDataMessageServerError

サブスクリプションイベントメッセージの発行 AWS AppSync 中に発生したエラーの数。これは通常、予期しないサーバー側の問題が発生した場合に発生します。

単位: カウント サーバー側のサブスクリプションイベント発行エラーの出現総数を取得するために、Sum 統計を使用します。

PublishDataMessageSize

発行されたサブスクリプションイベントメッセージのサイズ。

単位: バイト

ActiveConnections

クライアントから への 1 分間 AWS AppSync の同時 WebSocket 接続の数。

単位: カウント 開かれている接続の合計数を取得するために、Sum 統計を使用します。

ActiveSubscriptions

クライアントからの同時サブスクリプション数 (1 分間)。

単位: カウント アクティブなサブスクリプションの合計数を取得するために、Sum 統計を使用します。

ConnectionDuration

接続が開いたままになる時間。

単位: ミリ秒 接続期間を評価するために Average 統計を使用します。

OutboundMessages

正常に発行された計測メッセージの数。1 つの従量制メッセージは 5 kB の配信済みデータに相当します。

単位: カウント 正常に公開された従量制メッセージの総数を取得するために、Sum 統計を使用します。

InboundMessageSuccess

正常に処理されたインバウンドメッセージの数。ミューテーションによって呼び出されるサブスクリプションタイプごとに 1 つのインバウンドメッセージが生成されます。

単位: カウント 正常に処理されたインバウンドメッセージの総数を取得するために、Sum 統計を使用します。

InboundMessageError

240 kB のサブスクリプションペイロードサイズ制限を超えるなど、無効なAPIリクエストのために処理に失敗したインバウンドメッセージの数。

単位: カウント Sum 統計を使用して、 API関連の処理に失敗したインバウンドメッセージの合計数を取得します。

InboundMessageFailure

からのエラーが原因で処理に失敗したインバウンドメッセージの数 AWS AppSync。

単位: カウント Sum 統計を使用して、 AWS AppSync関連の処理に失敗したインバウンドメッセージの総数を取得します。

InboundMessageDelayed

遅延インバウンドメッセージの数。インバウンドメッセージは、インバウンドメッセージレートクォータまたはアウトバウンドメッセージレートクォータのいずれかに違反した場合に遅延する可能性があります。

単位: カウント Sum 統計を使用して、遅延したインバウンドメッセージの合計数を取得します。

InboundMessageDropped

ドロップされたインバウンドメッセージの数。インバウンドメッセージは、インバウンドメッセージレートクォータまたはアウトバウンドメッセージレートクォータのいずれかに違反した場合に削除できます。

単位: カウント Sum 統計を使用して、ドロップされたインバウンドメッセージの合計数を取得します。

InvalidationSuccess

$extensions.invalidateSubscriptions() とのミューテーションによって正常に無効 (購読解除) されたサブスクリプションの数。

単位: カウント サブスクライブが正常に解除されたサブスクリプションの総数を取得するには Sum 統計を使用します。

InvalidationRequestSuccess

正常に処理された無効化リクエストの数。

単位: カウント 正常に処理された無効化リクエストの総数を取得するために、Sum 統計を使用します。

InvalidationRequestError

無効なリクエストが原因で処理に失敗した無効化APIリクエストの数。

単位: カウント Sum 統計を使用して、 API関連の処理に失敗した無効化リクエストの総数を取得します。

InvalidationRequestFailure

からのエラーにより処理に失敗した無効化リクエストの数 AWS AppSync。

単位: カウント Sum 統計を使用して、 AWS AppSync関連の処理に失敗した無効化リクエストの合計数を取得します。

InvalidationRequestDropped

無効化リクエストのクォータを超えたときにドロップされた無効化リクエストの数。

単位: カウント ドロップされた無効化リクエストの総数を取得するために、Sum 統計を使用します。

インバウンドメッセージとアウトバウンドメッセージの比較

ミューテーションが実行されると、そのミューテーションの @aws_subscribe ディレクティブを含むサブスクリプションフィールドが呼び出されます。サブスクリプションの呼び出しごとに 1 つのインバウンドメッセージが生成されます。例えば、2 つのサブスクリプションフィールドで @aws_subscribe に同じミューテーションが指定されている場合、そのミューテーションが呼び出されると 2 つのインバウンドメッセージが生成されます。

1 つのアウトバウンドメッセージは、 WebSocket クライアントに配信される 5 kB のデータに相当します。例えば、15 kB のデータを 10 のクライアントに送信すると、30 のアウトバウンドメッセージ (15 kB * 10 のクライアント/メッセージあたり 5 kB = 30 メッセージ) になります。

インバウンドメッセージまたはアウトバウンドメッセージのクォータの引き上げをリクエストできます。詳細については、「 AWS 全般のリファレンスガイド」のAWS AppSync 「 エンドポイントとクォータ」および「Service Quotas ユーザーガイド」の「クォータの引き上げをリクエストする手順」を参照してください。 Service Quotas

拡張メトリクス

拡張メトリクスは、リクエスト数とエラー数、レイテンシー、キャッシュヒット/ミスなど AWS AppSync 、API使用状況とパフォーマンスに関する詳細なデータを生成します。拡張メトリクスデータはすべて CloudWatch アカウントに送信され、送信されるデータの種類を設定できます。

注記

拡張メトリクスを使用する場合、追加料金が適用されます。詳細については、「Amazon 料金表」の「詳細モニタリング料金階層」を参照してください。 CloudWatch

これらのメトリクスは、 AWS AppSync コンソールのさまざまな設定ページで確認できます。API 設定ページで、拡張メトリクスセクションでは、次の項目を有効または無効にできます。

リゾルバーメトリクスの動作: これらのオプションは、リゾルバーの追加メトリクスの収集方法を制御します。フルリクエストリゾルバーメトリクス (リクエスト内のすべてのリゾルバーに対して有効になっているメトリクス) またはリゾルバーごとのメトリクス (設定が有効に設定されているリゾルバーに対してのみ有効になっているメトリクス) を有効にすることができます。以下のオプションが利用できます。

GraphQL errors per resolver (GraphQLError)

リゾルバーごとに発生した GraphQL エラーの数。

メトリクスディメンション: API_IdResolver

単位: カウント

Requests per resolver (Request)

リクエスト中に発生した呼び出しの数。これはリゾルバーごとに記録されます。

メトリクスディメンション: API_IdResolver

単位: カウント

Latency per resolver (Latency)

リゾルバーの呼び出しを完了する時間。レイテンシーはミリ秒単位で測定され、リゾルバーごとに記録されます。

メトリクスディメンション: API_IdResolver

単位: ミリ秒

Cache hits per resolver (CacheHit)

リクエスト中のキャッシュヒットの数。これは、キャッシュが使用されている場合にのみ出力されます。キャッシュヒットはリゾルバーごとに記録されます。

メトリクスディメンション: API_IdResolver

単位: カウント

Cache misses per resolver (CacheMiss)

リクエスト中のキャッシュミスの数。これは、キャッシュが使用されている場合にのみ出力されます。キャッシュミスはリゾルバーごとに記録されます。

メトリクスディメンション: API_IdResolver

単位: カウント

データソースメトリクスの動作: これらのオプションは、データソースの追加メトリクスの収集方法を制御します。完全なリクエストデータソースメトリクス (リクエスト内のすべてのデータソースで有効になっているメトリクス) またはデータソースごとのメトリクス (設定が有効になっているデータソースでのみ有効になっているメトリクス) を有効にすることができます。以下のオプションが利用できます。

Requests per data source (Request)

リクエスト中に発生した呼び出しの数。リクエストはデータソースごとに記録されます。完全なリクエストが有効になっている場合、各データソースは に独自のエントリを持ちます CloudWatch。

メトリクスディメンション: API_IdDatasource

単位: カウント

Latency per data source (Latency)

データソースの呼び出しを完了する時間。レイテンシーはデータソースごとに記録されます。

メトリクスディメンション: API_IdDatasource

単位: ミリ秒

Errors per data source (GraphQLError)

データソースの呼び出し中に発生したエラーの数。

メトリクスディメンション: API_IdDatasource

単位: カウント

オペレーションメトリクス : GraphQL オペレーションレベルのメトリクスを有効にします。

Requests per operation (Request)

指定された GraphQL オペレーションが呼び出された回数。

メトリクスディメンション: API_IdOperation

単位: カウント

GraphQL errors per operation (GraphQLError)

指定された GraphQL オペレーション中に発生した GraphQL エラーの数。

メトリクスディメンション: API_IdOperation

単位: カウント

CloudWatch ログ

新規または既存の GraphQL では、APIリクエストレベルとフィールドレベルの 2 種類のログ記録を設定できます。

リクエストレベルログ

リクエストレベルのロギング (詳細な内容を含む) を設定すると、次の情報がログに記録されます。

  • 消費されたトークンの数。

  • リクエストヘッダーとレスポンスHTTPヘッダー

  • リクエストで実行中の GraphQL クエリ

  • オペレーション全体の要約

  • 登録された、新規および既存の GraphQL サブスクリプション

フィールドレベルログ

フィールドレベルのロギングを設定すると、以下の情報がログに記録されます。

  • 各フィールドに対してソースと引数で生成されたリクエストマッピング

  • 各フィールドの、変換されたレスポンスマッピングで、対象フィールドを解決した結果のデータが含まれます。

  • 各フィールドのトレース情報

ログ記録を有効にすると、 が CloudWatch ログ AWS AppSync を管理します。このプロセスには、ロググループとログストリームの作成、およびログとログストリームへのレポートが含まれます。

GraphQL のログ記録を有効にしてリクエストを行うAPIと、 はロググループとログストリームをロググループの下に AWS AppSync 作成します。ロググループの名前は /aws/appsync/apis/{graphql_api_id} 形式に従います。各ロググループ内で、ログはログストリームにさらに分割されます。これらは、ログデータがレポートされるときに Last Event Time によって順序付けされます。

すべてのログイベントは、そのリクエストの x-amzn- RequestIdでタグ付けされます。これにより、 のログイベントをフィルタリング CloudWatch して、そのリクエストに関するログに記録されたすべての情報を取得できます。は、すべての GraphQL AWS AppSync リクエストのレスポンスヘッダー RequestId から取得できます。

フィールドレベルのログ記録は次のログレベルで設定されます。

  • NONE - フィールドレベルのログがキャプチャされません。

  • ERROR - 次の情報のみがエラーがあるフィールドに対してログ記録されます。
    • サーバーレスポンスのエラーセクション

    • フィールドレベルエラー

    • エラーフィールドに対して解決された、生成リクエスト / レスポンス関数

  • ALL - 次の情報が、クエリのすべてのフィールドに記録されます。
    • フィールドレベルのトレース情報

    • 各フィールドに対して解決された、生成リクエスト / レスポンス関数

モニタリングのメリット

ログおよびメトリクスを使用して、GraphQL クエリを特定、トラブルシューティング、最適化できます。たとえば、クエリの各フィールドに記録されたトレース情報を使用して、レイテンシーの問題をデバッグできます。これを示すため、GraphQL クエリで 1 つまたは複数のリゾルバーをネストして使用しているとします。 CloudWatch Logs のサンプルフィールドオペレーションは次のようになります。

{ "path": [ "singlePost", "authors", 0, "name" ], "parentType": "Post", "returnType": "String!", "fieldName": "name", "startOffset": 416563350, "duration": 11247 }

これは GraphQL スキーマに対応します。次のようになります。

type Post { id: ID! name: String! authors: [Author] } type Author { id: ID! name: String! } type Query { singlePost(id:ID!): Post }

上記のログの結果で、path は、singlePost() という名前のクエリを実行して返されたデータの単一項目を示します。この例では、最初のインデックス (0) の name フィールドを表します。startOffset は、GraphQL クエリオペレーションの開始からのオフセットを提供します。duration は、フィールドを解決するのにかかる合計時間です。これらの値は、特定のデータソースからデータの実行が予測より遅い理由、または特定のフィールドがクエリ全体の処理速度を低下することのトラブルシューティングに役立つ可能性があります。例えば、Amazon DynamoDB テーブルのプロビジョニングスループットを向上させたり、オペレーション全体のパフォーマンスが低下する原因となっている特定のフィールドをクエリから削除したりすることができます。

2019 年 5 月 8 日現在、 はログイベントを完全構造化 として AWS AppSync 生成しますJSON。これにより、Logs Insights や Amazon OpenSearch Service CloudWatch などのログ分析サービスを使用して、GraphQL リクエストのパフォーマンスとスキーマフィールドの使用特性を理解するのに役立ちます。たとえば、パフォーマンスの問題の根本原因となっている可能性のある高いレイテンシーが発生しているリゾルバーの特定を簡単に行えます。また、スキーマ内で最も使用頻度の低いフィールドを特定し、GraphQL フィールドを廃止する場合の影響を評価することもできます。

競合の検出と同期ロギング

に AWS AppSync API、フィールドリゾルバーのログレベルがすべての に設定された CloudWatch ログへのログ記録がある場合、 は競合の検出と解決情報をロググループに AWS AppSync 出力します。 これにより、 が AWS AppSync API競合にどのように対応したかをきめ細かく把握できます。応答を解釈しやすくするため、ログには以下の情報が記録されます。

conflictType

バージョンの不一致またはお客様が指定した条件が原因で競合が発生したかどうかを詳細に示します。

conflictHandlerConfigured

リクエスト時にリゾルバーで設定された競合ハンドラーを示します。

message

競合をどのように検出し、解決したかに関する情報を提供します。

syncAttempt

リクエストを最終的に拒否する前に、サーバーがデータを同期するために試行した回数。

data

競合ハンドラーが Automerge に設定されていた場合、このフィールドは Automergee が各フィールドに対してどのような決定を行ったかを示すために入力されます。提供されるアクションは、次のとおりです。

  • REJECTED - が受信フィールド値Automergeを拒否し、サーバー内の値に優先する場合。

  • ADDED - サーバーに既存の値がないため、 が受信フィールドに Automergeを追加する場合。

  • APPENDED - がサーバーに存在するリストの値に受信値Automergeを追加する場合。

  • MERGED - が受信値をサーバーに存在するセットの値にAutomergeマージする場合。

トークン数を使用してリクエストを最適化する

1,500 KB 秒以下のメモリと vCPU 時間を消費するリクエストには、1 つのトークンが割り当てられます。リソース消費量が 1,500 KB 秒を超えるリクエストには、追加のトークンが渡されます。例えば、リクエストが 3,350 KB 秒を消費する場合、 はリクエストに 3 つのトークン (次の整数値に切り上げ) を AWS AppSync 割り当てます。デフォルトでは、 はデプロイ先の AWS リージョンに応じて、アカウントAPIs内の に 1 秒あたり最大 5,000 または 10,000 個のリクエストトークンを AWS AppSync 割り当てます。APIs それぞれが 1 秒あたり平均 2 つのトークンを使用している場合、それぞれ 1 秒あたり 2,500 または 5,000 リクエストに制限されます。1 秒あたりに割り当てられた量よりも多くのトークンが必要な場合は、リクエストを送信してリクエストトークンのレートのデフォルトクォータを増やすことができます。詳細については、「 AWS 全般のリファレンス ガイド」のAWS AppSync 「 エンドポイントとクォータ」および「Service Quotas ユーザーガイド」の「クォータの引き上げのリクエスト」を参照してください。 Service Quotas

リクエストごとのトークン数が多い場合は、リクエストを最適化して のパフォーマンスを向上させる機会があることを示している可能性がありますAPI。リクエスト 1 回あたりのトークン数を増やす要因には次のようなものがあります。

  • GraphQL スキーマのサイズと複雑さ。

  • リクエストとレスポンスのマッピングテンプレートの複雑さ。

  • 1 回のリゾルバー呼び出し回数。

  • リゾルバーから返されたデータ転送量。

  • ダウンストリームデータソースのレイテンシー。

  • (parallel 呼び出しやバッチ呼び出しとは対照的に) 連続したデータソース呼び出しを必要とするスキーマとクエリの設計。

  • ロギング設定、特にフィールドレベルおよび詳細なログコンテンツ。

注記

クライアントは、 AWS AppSync メトリクスとログに加えて、レスポンスヘッダー を介してリクエストで消費されたトークンの数にアクセスできますx-amzn-appsync-TokensConsumed

ログサイズの制限

デフォルトでは、ログ記録が有効になっている場合、 はリクエストごとに最大 1 MB のログ AWS AppSync を送信します。このサイズを超えるログは切り捨てられます。ログサイズを減らすには、フィールドレベルのERRORログのログ記録レベルを選択し、ログVERBOSE記録を無効にするか、不要な場合はフィールドレベルのログを完全に無効にします。ALL ログレベルの代わりに、拡張メトリクスを使用して特定のリゾルバー、データソース、または GraphQL オペレーションに関するメトリクスを取得したり、 が提供するログ記録ユーティリティを使用して必要な情報のみを AppSync ログ記録したりできます。

ログタイプリファレンス

RequestSummary

  • requestId: リクエストの一意の識別子。

  • graphQLAPIId: リクエストAPIを行う GraphQL の ID。

  • statusCode: HTTPステータスコードレスポンス。

  • レイテンシー: リクエストの E nd-to-end レイテンシー、ナノ秒、整数。

{ "logType": "RequestSummary", "requestId": "dbe87af3-c114-4b32-ae79-8af11f3f96f1", "graphQLAPIId": "pmo28inf75eepg63qxq4ekoeg4", "statusCode": 200, "latency": 242000000 }

ExecutionSummary

  • requestId: リクエストの一意の識別子。

  • graphQLAPIId: リクエストAPIを行う GraphQL の ID。

  • startTime: 3339 形式のリクエストの GraphQL RFC 処理の開始タイムスタンプ。

  • endTime: 3339 形式のリクエストの GraphQL RFC 処理の終了タイムスタンプ。

  • duration: GraphQL 処理の合計経過時間 (ナノ秒単位、整数)。

  • version: のスキーマバージョン ExecutionSummary。

  • parsing:
    • startOffset: 呼び出しに対するナノ秒単位の解析の開始オフセットを整数で表します。

    • duration: 解析にかかった時間 (ナノ秒単位、整数)。

  • validation:
    • startOffset: 検証の開始オフセット。呼び出しを基準にしたナノ秒単位の整数。

    • duration: 検証の実行にかかった時間 (ナノ秒単位、整数)。

{ "duration": 217406145, "logType": "ExecutionSummary", "requestId": "dbe87af3-c114-4b32-ae79-8af11f3f96f1", "startTime": "2019-01-01T06:06:18.956Z", "endTime": "2019-01-01T06:06:19.174Z", "parsing": { "startOffset": 49033, "duration": 34784 }, "version": 1, "validation": { "startOffset": 129048, "duration": 69126 }, "graphQLAPIId": "pmo28inf75eepg63qxq4ekoeg4" }

トレース

  • requestId: リクエストの一意の識別子。

  • graphQLAPIId: リクエストAPIを行う GraphQL の ID。

  • startOffset: フィールド解決の開始オフセット。呼び出しを基準にしたナノ秒単位の整数。

  • duration: フィールドの解決にかかった時間 (ナノ秒単位、整数)。

  • fieldName: 解決されるフィールドの名前。

  • parentType: 解決されるフィールドの親タイプ。

  • returnType: 解決されるフィールドの戻り値のタイプ。

  • path: レスポンスのルートから解決されるフィールドまでのパスセグメントのリスト。

  • resolverArn: フィールド解決に使用されるリゾルバーARNの 。ネストされたフィールドには存在しない場合があります。

{ "duration": 216820346, "logType": "Tracing", "path": [ "putItem" ], "fieldName": "putItem", "startOffset": 178156, "resolverArn": "arn:aws:appsync:us-east-1:111111111111:apis/pmo28inf75eepg63qxq4ekoeg4/types/Mutation/fields/putItem", "requestId": "dbe87af3-c114-4b32-ae79-8af11f3f96f1", "parentType": "Mutation", "returnType": "Item", "graphQLAPIId": "pmo28inf75eepg63qxq4ekoeg4" }

CloudWatch Logs Insights を使用したログの分析

以下は、GraphQL オペレーションのパフォーマンスとヘルスに関する実用的な洞察を得るために実行できるクエリの例です。これらの例は、Logs Insights CloudWatch コンソールのサンプルクエリとして使用できます。CloudWatch コンソール で、Logs Insights を選択し、GraphQL の AWS AppSync ロググループを選択しAPI、サンプルAWS AppSync クエリ でクエリを選択します。

以下のクエリは、レイテンシーが最大の上位 10 個の GraphQL リクエストを返します。

filter @message like "Tokens Consumed" | parse @message "* Tokens Consumed: *" as requestId, tokens | sort tokens desc | display requestId, tokens | limit 10

以下のクエリは、レイテンシーが最大の上位 10 個のリゾルバーを返します。

fields resolverArn, duration | filter logType = "Tracing" | limit 10 | sort duration desc

以下のクエリは、呼び出し頻度が最も高いリゾルバーを返します。

fields ispresent(resolverArn) as isRes | stats count() as invocationCount by resolverArn | filter isRes and logType = "Tracing" | limit 10 | sort invocationCount desc

以下のクエリは、マッピングテンプレートのエラーが最も多いリゾルバーを返します。

fields ispresent(resolverArn) as isRes | stats count() as errorCount by resolverArn, logType | filter isRes and (logType = "RequestMapping" or logType = "ResponseMapping") and fieldInError | limit 10 | sort errorCount desc

以下のクエリは、リゾルバーのレイテンシー統計を返します。

fields ispresent(resolverArn) as isRes | stats min(duration), max(duration), avg(duration) as avg_dur by resolverArn | filter isRes and logType = "Tracing" | limit 10 | sort avg_dur desc

以下のクエリは、フィールドのレイテンシー統計を返します。

stats min(duration), max(duration), avg(duration) as avg_dur by concat(parentType, '/', fieldName) as fieldKey | filter logType = "Tracing" | limit 10 | sort avg_dur desc

CloudWatch Logs Insights クエリの結果は、 CloudWatch ダッシュボードにエクスポートできます。

Service でログを分析する OpenSearch

Amazon OpenSearch Service で AWS AppSync ログを検索、分析、視覚化して、パフォーマンスのボトルネックと運用上の問題の根本原因を特定できます。レイテンシーが最大でエラーのあるリゾルバーを特定できます。さらに、 OpenSearch Dashboards を使用して、強力なビジュアライゼーションを備えたダッシュボードを作成できます。 OpenSearch Dashboards は、 OpenSearch Service で利用できるオープンソースのデータのビジュアライゼーションおよび探索ツールです。 OpenSearch Dashboards を使用すると、GraphQL オペレーションのパフォーマンスと正常性を継続的にモニタリングできます。例えば、GraphQL リクエストの P90 レイテンシーを可視化し、各リゾルバーの P90 レイテンシーにドリルダウンできるダッシュボードを作成できます。

OpenSearch サービスを使用する場合は、フィルターパターンとして「cwl*」を使用して OpenSearch インデックスを検索します。 OpenSearch サービスは CloudWatch 、Logs からストリーミングされたログに「cwl-」というプレフィックスを付けてインデックスを作成します。Service に送信された他のログと CloudWatch ログを区別 AWS AppSync APIするには OpenSearch 、検索graphQLAPIID.keyword=YourGraphQLAPIIDに のフィルター式を追加することをお勧めします。

ログ形式の移行

2019 年 5 月 8 日以降に が AWS AppSync 生成するログイベントは、完全に構造化された としてフォーマットされますJSON。2019 年 5 月 8 日より前の GraphQL リクエストを分析するには、GitHub サンプル で利用可能なスクリプトJSONを使用して、古いログを完全構造化に移行できます。2019 年 5 月 8 日より前のログ形式を使用する必要がある場合は、[Type (タイプ)] を [Account Management (アカウント管理)] に、[Category (カテゴリ)] を [General Account Question (一般的なアカウント質問)] に設定して、サポートチケットを作成します。

メトリクスフィルターを使用して CloudWatch ログデータを数値 CloudWatch メトリクスに変換し、ログデータをグラフ化またはアラームを設定することもできます。