モニタリングとログ記録 - AWS AppSync

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

モニタリングとログ記録

AWS AppSync GraphQL API をモニタリングし、リクエストに関連する問題をデバッグするには、Amazon CloudWatch Logs へのログ記録を有効にします。

セットアップと設定

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

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

  2. API] ページで、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。これを手動で設定するには、 がログを書き込むときにロールをAWS AppSync 引き受けられるように、サービスロール ARN を指定する必要があります。

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 ペイロードまたは誤ったクエリが含まれている場合、サービスがスロットリングされている場合、または Auth 設定が誤って構成されている場合に発生する可能性があります。

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

5XXError

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

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

Latency

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

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

Requests

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

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

TokensConsumed

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

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

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

すべてのメトリクスは、GraphQLAPIId という 1 つのディメンションで出力されます。これは、すべてのメトリクスが GraphQL API ID と結合されていることを意味します。以下のメトリクスは、純粋な での 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 リクエストが原因で処理に失敗したインバウンドメッセージの数。

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

InboundMessageFailure

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

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

InvalidationSuccess

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

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

InvalidationRequestSuccess

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

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

InvalidationRequestError

無効な API リクエストにより処理に失敗した無効化リクエストの数。

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

InvalidationRequestFailure

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

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

InvalidationRequestDropped

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

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

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

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

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

拡張メトリクス

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

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

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

    メトリクス メトリクスディメンション メトリクス名 単位 説明
    GraphQL errors per resolver API_Id, Resolver GraphQLError Count (カウント) The number of GraphQL errors that occured per resolver.
    Requests per resolver API_Id, Resolver Request Count (カウント) The number of invocations that occurred during a request. This is recorded on a per-resolver basis.
    Latency per resolver API_Id, Resolver Latency ミリ秒 The time to complete a resolver invocation. Latency is measured in milliseconds and is recorded on a per-resolver basis.
    Cache hits per resolver API_Id, Resolver CacheHit Count (カウント) The number of cache hits during a request. This will only be emitted if a cache is used. Cache hits are recorded on a per-resolver basis.
    Cache misses per resolver API_Id, Resolver CacheMiss Count (カウント) The number of cache misses during a request. This will only be emitted if a cache is used. Cache misses are recorded on a per-resolver basis.
  2. データソースメトリクスの動作: これらのオプションは、データソースの追加メトリクスの収集方法を制御します。完全なリクエストデータソースメトリクス (リクエスト内のすべてのデータソースで有効になっているメトリクス) またはデータソースごとのメトリクス (設定が有効に設定されているデータソースでのみ有効になっているメトリクス) を有効にすることを選択できます。以下のオプションが利用できます。

    メトリクス メトリクスディメンション メトリクス名 単位 説明
    Requests per data source API_Id, Datasource Request Count (カウント) The number of invocations that occured during a request. Requests are recorded on a per-data source basis. If full requests are enabled, each data source will have its own entry in CloudWatch.
    Latency per data source API_Id, Datasource Latency ミリ秒 The time to complete a data source invocation. Latency is recorded on a per-data source basis.
    Errors per data source API_Id, Datasource GraphQLError Count (カウント) The number of errors that occurred during a data source invocation.
  3. オペレーションメトリクス : GraphQL オペレーションレベルのメトリクスを有効にします。

    メトリクス メトリクスディメンション メトリクス名 単位 説明
    Requests per operation API_Id, Operation Request Count (カウント) The number of times a specified GraphQL operation was called.
    GraphQL errors per operation API_Id, Operation GraphQLError Count (カウント) The number of GraphQL errors that occurred during a specified GraphQL operation.

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

メトリクス メトリクスディメンション メトリクス名 単位 説明
NetworkBandwidthOutAllowanceExceeded API_Id appsyncCacheNetworkBandwidthOutAllowanceExceeded Count (カウント) The network packets dropped because the throughput exceeded the aggregated bandwidth limit. This is useful for diagnosing bottlenecks in a cache configuration.
EngineCPUUtilization API_Id appsyncCacheEngineCPUUtilization 割合 (%) The CPU utilization (percentage) allocated to the Redis process. This is useful for diagnosing bottlenecks in a cache configuration.

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 としてログイベントが生成されます。これは、 CloudWatch Logs Insights や Amazon OpenSearch Service などのログ分析サービスを使用して、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 秒あたり最大 2,000 個のリクエストトークンをAWS AppSync 割り当てます。各 API が 1 秒あたり平均 2 つのトークンを使用する場合、1 秒あたりのリクエスト数は 1,000 に制限されます。1 秒あたりに割り当てられた量よりも多くのトークンが必要な場合は、リクエストを送信してリクエストトークンのレートのデフォルトクォータを増やすことができます。詳細については、「 AWS 全般のリファレンスガイド」のAWS AppSync「 エンドポイントとクォータ」および「Service Quotas ユーザーガイド」の「クォータの引き上げのリクエスト」を参照してください。

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

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

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

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

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

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

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

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

注記

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

ログタイプリファレンス

RequestSummary

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

  • graphQLAPIId: リクエスト元の GraphQL API の ID。

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

  • レイテンシー: リクエストのnd-to-end レイテンシーをナノ秒単位で整数で表したものです。

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

ExecutionSummary

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

  • graphQLAPIId: リクエスト元の GraphQL API の ID。

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

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

  • 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: リクエスト元の GraphQL API の 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 オペレーションのパフォーマンスとヘルスに関する実用的な洞察を得るために実行できるクエリの例です。これらの例は、 CloudWatch Logs Insights コンソールのサンプルクエリとして使用できます。CloudWatch コンソール で、Logs Insights を選択し、GraphQL API のAWS AppSync ロググループを選択し、サンプル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 ダッシュボードにエクスポートできます。

OpenSearch サービスを使用してログを分析する

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

OpenSearch サービスを使用する場合は、フィルターパターンとして「cwl*」を使用して OpenSearch インデックスを検索します。 OpenSearch サービスは CloudWatch 、ログからストリーミングされるログに「cwl-」というプレフィックスを付けてインデックスを作成します。AWS AppSync API ログと OpenSearch サービスに送信される他の CloudWatch ログを区別するには、検索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 メトリクスに変換し、ログデータをグラフ化またはアラームを設定することもできます。