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

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

モニタリングとログ記録

を監視するにはAWS AppSync GraphQL API とリクエストに関連する問題のデバッグに役立てれば、Amazon へのロギングを有効にできます CloudWatch ログ。

セットアップと設定

GraphQL API の自動ログ記録を有効にするには、AWS AppSync console.

  1. にサインインします。AWSAppSync コンソール

  2. リポジトリの []APIページで GraphQL API の名前を選択します。

  3. API のホームページのナビゲーションペインで、設定

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

    1. の有効化ログの有効化

    2. (オプション) リクエストレベルの詳細なログ記録については、[] チェックボックスをオンにします。詳細コンテンツを含める

    3. (オプション) の下フィールドリゾルバーのログレベルで、目的のフィールドレベルのログレベルを選択します (なし,エラー, またはすべて).

    4. []既存のロールを作成または既存のロールの使用で、新しいロール新しいを作成するにはAWS Identity and Access Managementそれを許可する (IAM)AWS AppSync CloudWatch にログを記録します。または、既存のロールで既存の IAM ロールの Amazon リソースネーム (ARN) を選択します。AWSアカウント.

  5. [Save.] を選択します。

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": "*" } ] }

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

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

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

5XXError

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

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

Latency

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

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

Requests

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

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

TokensConsumed

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

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

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

すべてのメトリクスは、1 つのディメンションで出力されます。GraphQLAPIId。これは、すべてのメトリクスが GraphQL API ID と結合されていることを意味します。以下のメトリクスは、純粋な WebSockets を介した GraphQL サブスクリプションに関連しています。

ConnectSuccess

成功したの数 WebSocket に接続します。AWSAppSync。サブスクリプションなしで接続することは可能です。

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

ConnectClientError

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

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

ConnectServerError

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

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

DisconnectSuccess

成功したの数 WebSocket の切り離しAWSAppSync。

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

DisconnectClientError

からのクライアントエラーの数AWS AppSync の切り離し WebSocket 接続。

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

DisconnectServerError

からのエラーの数AWS AppSync の切り離し WebSocket 接続。

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

SubscribeSuccess

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

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

SubscribeClientError

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

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

SubscribeServerError

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

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

UnsubscribeSuccess

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

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

UnsubscribeClientError

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

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

UnsubscribeServerError

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

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

PublishDataMessageSuccess

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

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

PublishDataMessageClientError

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

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

PublishDataMessageServerError

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

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

PublishDataMessageSize

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

Unit: Bytes

ActiveConnections

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

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

ActiveSubscriptions

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

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

ConnectionDuration

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

Unit: Milliseconds。接続期間を評価するために Average 統計を使用します。

InvalidationSuccess

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

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

[CloudWatch Logs]

任意の新規または既存の GraphQL API でリクエストレベルおよびフィールドレベルの 2 つのタイプでログ記録するように設定できます。

リクエストレベルログ

リクエストレベルのログ記録 (詳細コンテンツを含める) が設定されている場合、以下の情報がログに記録されます。

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

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

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

  • オペレーションの全体的なサマリー

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

フィールドレベルのログ

フィールドレベルのロギングが設定されている場合、次の情報がログに記録されます。

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

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

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

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

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

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

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

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

  • エラー-次の情報を記録しますのみエラーのあるフィールドについては、以下のようになります。
    • サーバーレスポンスのエラーセクション

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

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

  • すべて-次の情報をログに記録しますすべてクエリ内のフィールド:
    • フィールドレベルのトレース情報

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

モニタリングの利点

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

{ "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 }

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

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

競合検出と同期ロギング

もしあればAWS AppSync API にログ記録がある CloudWatch で設定されたログフィールドリゾルバーのログレベルに設定します。すべてとなる。AWS AppSync 競合の検出と解決の情報をロググループに送信します。これにより、どのように詳細なインサイトが得られます。AWS AppSync API が競合に応答しました。レスポンスを解釈しやすくするために、次の情報がログに出力されます。

conflictType

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

conflictHandlerConfigured

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

message

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

syncAttempt

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

data

コンフリクトハンドラが構成されている場合Automergeの場合、このフィールドはどのような決定を示すために入力されますAutomerge各フィールドに対してが取られました。提供されるアクションは、次のとおりです。

  • 拒否-時期Automergeサーバーの値を優先して受信フィールド値を拒否します。

  • 追加しました-時期Automergeサーバーに既存の値がないために、は、受信フィールドに追加します。

  • 追加されました-時期Automergeサーバーに存在するリストの値に着信値を追加します。

  • 合併した-時期Automerge受信した値を、サーバーに存在するセットの値にマージします。

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

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

リクエストごとのトークン数が多いほど、リクエストを最適化し、API のパフォーマンスを向上させる機会があることを示している可能性があります。リクエストごとのトークン数を増やす要因は次のとおりです。

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

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

  • リクエストあたりのリゾルバの呼び出し数。

  • リゾルバーから返されるデータの量。

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

  • 並列呼び出しまたはバッチ呼び出しではなく、連続するデータソース呼び出しを必要とするスキーマおよびクエリ設計。

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

注記

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

ログタイプのリファレンス

RequestSummary

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

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

  • StatusCode HTTP ステータスコードの応答。

  • レイテンシー リクエストのエンドツーエンドのレイテンシー (ナノ秒単位、整数)。

{ "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 形式)。

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

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

  • parsing:
    • startOffset: 呼び出しを基準とした解析の開始オフセット (ナノ秒単位、整数)。

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

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

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

{ "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: 呼び出しを基準としたナノ秒単位、フィールド解決の開始オフセット (呼び出しを基準とした整数)。

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

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

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

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

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

  • 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 ログインサイト

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

によるログの分析 OpenSearch サービス

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

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

ログ形式の移行

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

また、メトリクスフィルタに CloudWatch ログデータを数値に変換するには CloudWatch メトリクスを使用して、グラフの作成やアラームの設定に利用できるようになります。