失敗した Canary のトラブルシューティング - Amazon CloudWatch

失敗した Canary のトラブルシューティング

Canary が失敗した場合は、以下を確認しトラブルシューティングしてください。

一般的なトラブルシューティング

  • Canary の詳細ページを開き、詳細を確認します。CloudWatch コンソールのナビゲーションウィンドウで [Canaries] をクリックし、詳細ページを開きたい Canary の名前を選択します。[可用性] タブで [SuccessPercent] メトリクスを参照し、発生している問題が持続的か断続的かを確認します。

    同じ [可用性] タブで、失敗したデータポイントを選択することで、失敗した実行のスクリーンショット、ログ、および (それがある場合には) ステップレポートを見ることができます。

    ステップがスクリプトの一部でありステップレポートを使用できる場合は、どのステップが失敗したかを確認し、顧客側に表示されたメッセージを見るために関連するスクリーンショットを参照します。

    HAR ファイルをチェックして、失敗が 1 つ以上のリクエストで発生しているかどうかを確認することもできます。ログを使用すると、失敗したリクエストとエラーの詳細について、より深く掘り下げることができます。最後に、これらのアーティファクトと、を成功した Canary 実行のアーティファクト比較して問題を特定します。

    CloudWatch Synthetics は、デフォルトで、UI Canary の各ステップのスクリーンショットをキャプチャします。ただし、スクリーンショットを無効にするようにスクリプトが構成されている場合もあり得ます。その場合は、デバッグ中にスクリーンショットを再度有効にします。同様に、API Canary のデバッグ中に、HTTP リクエストと応答ヘッダー、あるいは本文を表示する必要性が生じることもあります。このデータをレポートに含める方法については、「executeHttpStep(stepName, requestOptions, [callback], [stepConfig])」を参照してください。

  • アプリケーションに最近デプロイしている場合には、一度ロールバックし、後にデバッグを行います。

  • エンドポイントに手動で接続し、同じ問題を再現できるかどうかを確認します。

Canary ランタイムバージョンのアップグレードおよびダウングレードの問題

最近、ランタイムバージョン syn-1.0 から新しいバージョンに Canary をアップグレードした場合は、クロスオリジンリクエスト共有 (CORS) の問題が発生する可能性があります。詳細については、「」を参照してくださいクロスオリジンリクエスト共有 (CORS) の問題

最近、Canary を古いランタイムバージョンにダウングレードした場合は、使用している CloudWatch Synthetics 関数が、古い方のランタイムバージョンでも利用可能であることを確認します。例えば、executeHttpStep 関数はランタイムバージョン syn-nodejs-2.2 以降であれば使用が可能です。関数の可用性を確認するには、「Canary スクリプトの作成」を参照してください。

注記

Canary のランタイムバージョンをアップグレードまたはダウングレードする場合は、まず Canary をクローンし、複製された方の Canary でランタイムバージョンを変更することをお勧めします。新しいランタイムバージョンのクローンが機能することを確認したら、元の Canary のランタイムバージョンを更新し、クローンを削除できます。

要素が表示されるのに時間がかかる

ログとスクリーンショットを分析した後、要素が画面に表示されるまで待機しているスクリプトがタイムアウトしてしまう場合には、関連するスクリーンショットを参照して、要素がページに表示されているかどうかを確認します。xpath に誤りがないことを確認します。

Puppetteer 関連の問題については、Puppeteer の GitHub ページ、またはインターネットのフォーラムを参照してください。

ノードが表示されない、または page.click() での HTMLElement ではない

ノードが非表示になっているか、HTMLElement での page.click() ではない場合は、要素を参照するために使用している xpath を確認します。また、要素が画面の下部に表示されている場合は、ビューポートを調整します。CloudWatch Synthetics では、デフォルトで 1920 × 1080 のビューポートが使用されます。ビューポートの設定変更は、ブラウザの起動時に行うことができます。または Puppeteer の page.setViewport 関数を使用しても変更できます。

アーティファクトを S3 にアップロードできない (Exception: Unable to fetch S3 bucket location: Access Denied)

これは、アクセス権限に問題があるために、Canary 用に作成されたスクリーンショットやログまたはレポートを、CloudWatch Synthetics がアップロードできなかったことを意味します。Canary のロールに必要な権限が付与されていることを確認してください。詳細については、「」を参照してくださいCloudWatch Canary に必要なロールとアクセス許可

注記

このエラーで Canary が失敗した場合でも、CloudWatch メトリクス内でデータポイントが Passed として表示されることがあります。これは、CloudWatch Synthetics でスクリプトが通過したかのように、SuccessPercent メトリクスが Passed として公開されるためです。

アーティファクトのアップロードに失敗しても、スクリプトに問題があるとは限りません。したがって、これらのエラーにより Canary は失敗しますが、その Canary に設定されているアラームはトリガーされません。

CloudWatch Synthetics の addExecutionError 関数を使用して、独自の実行エラーを追加することができます。Canary スクリプトの成功または失敗を確認するために重要でない場合にのみ、エラーを実行エラーとして追跡するようにします。この関数の詳細については、「addExecutionError(errorMessage, ex);」を参照してください。

Error: Protocol error (Runtime.callFunctionOn): Target closed.

このエラーは、ページまたはブラウザを閉じた後に、ネットワークリクエストが送られた場合に表示されます。非同期オペレーションのための待機を行っていない可能性があります。スクリプトを実行した後、CloudWatch Synthetics はブラウザを閉じます。ブラウザを閉じた後に非同期オペレーションを実行すると、target closed error の原因となる可能性があります。

Canary Failed. Error: No datapoint - Canary Shows timeout error

これは、Canary の実行がタイムアウトしたことを意味します。CloudWatch Synthetics が成功率に関する CloudWatch メトリクスを公開したり、HAR ファイル、ログ、スクリーンショットなどのアーティファクトを更新したりする前に、Canary の実行が停止しています。タイムアウト値が小さすぎる場合は増加することができます。

デフォルトでは、Canary のタイムアウト値はその実行間隔と同じに設定されています。タイムアウト値は、手動で Canary の実行間隔以下になるように調整できます。Canary の実行間隔が小さい場合、タイムアウト値を増やすには実行間隔も大きくする必要があります。CloudWatch Synthetics コンソールを使用して Canary を作成または更新する際に、[スケジュール] で実行間隔とタイムアウト値 の両方を調整します。

このエラーが発生した場合、Canary のアーティファクトは、CloudWatch Synthetics コンソール上に表示されなくなります。CloudWatch Logs を使用して、Canary のログを表示できます。

CloudWatch Logs を使用して Canary のログを表示するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. 左側のナビゲーションペインで、[ロググループ] をクリックします。

  3. フィルターボックスに Canary 名を入力して、ロググループを検索します。Canary のロググループの名前は、/aws/lambda/cwsyn-canaryName-randomId です。

内部エンドポイントにアクセスしたい

Canary が内部ネットワーク上のエンドポイントにアクセスできるようにするには、CloudWatch Synthetics で VPC を使用するようにセットアップすることをお勧めします。詳細については、「」を参照してくださいVPC で Canary を実行する

クロスオリジンリクエスト共有 (CORS) の問題

UI Canary で、一部のネットワークリクエストが 403 または net::ERR_FAILED で失敗する場合は、Canary でアクティブなトレースが有効になっているかどうかを確認し、Puppeteer の page.setExtraHTTPHeaders 関数を使用してヘッダーを追加します。この場合、ネットワークリクエストの失敗は、クロスオリジンリクエスト共有 (CORS) に関する制限が原因となっている可能性があります。アクティブなトレースを無効にするか、余分な HTTP ヘッダーを削除することで、これが原因なのかどうかを確認できます。

なぜこれが起こるのですか?

アクティブなトレースを使用すると、送信されるすべてのリクエストに余分なヘッダーが追加されることで、呼び出しの追跡が行われます。トレースヘッダーを追加したことでリクエストヘッダーが変更されるか、Puppeteer の page.setExtraHTTPHeadersを使用して余分なヘッダーが追加されると、XMLHttpRequest (XHR) リクエストの CORS チェックが実行されます。

アクティブなトレースを無効にしたり、余分なヘッダーを削除したりしたくない場合は、ウェブアプリケーションを更新しクロスオリジンアクセスを許可します。あるいは、スクリプトから Chrome ブラウザーを起動し、その際に disable-web-security フラグを使用することでウェブセキュリティを無効にします。

CloudWatch Synthetics の起動関数を使用すると、CloudWatch Synthetics の起動パラメータをオーバーライドし、追加の disable-web-security フラグパラメータを渡すことができます。詳細については、「」を参照してくださいNode.js Canary スクリプト用のライブラリ関数

注記

ランタイムバージョン syn-nodejs-2.1 以降を使用している場合は、CloudWatch Synthetics に渡す起動パラメータをオーバーライドできます。