失敗した Canary のトラブルシューティング
Canary が失敗した場合は、以下を確認しトラブルシューティングしてください。
一般的なトラブルシューティング
-
Canary の詳細ページを開き、詳細を確認します。CloudWatch コンソールのナビゲーションウィンドウで [Canaries] をクリックし、詳細ページを開きたい Canary の名前を選択します。[可用性] タブで [SuccessPercent] メトリクスを参照し、発生している問題が持続的か断続的かを確認します。
同じ [可用性] タブで、失敗したデータポイントを選択することで、失敗した実行のスクリーンショット、ログ、および (それがある場合には) ステップレポートを見ることができます。
ステップがスクリプトの一部でありステップレポートを使用できる場合は、どのステップが失敗したかを確認し、顧客側に表示されたメッセージを見るために関連するスクリーンショットを参照します。
HAR ファイルをチェックして、失敗が 1 つ以上のリクエストで発生しているかどうかを確認することもできます。ログを使用すると、失敗したリクエストとエラーの詳細について、より深く掘り下げることができます。最後に、これらのアーティファクトと、を成功した Canary 実行のアーティファクト比較して問題を特定します。
CloudWatch Synthetics は、デフォルトで、UI Canary の各ステップのスクリーンショットをキャプチャします。ただし、スクリーンショットを無効にするようにスクリプトが構成されている場合もあり得ます。その場合は、デバッグ中にスクリーンショットを再度有効にします。同様に、API Canary のデバッグ中に、HTTP リクエストと応答ヘッダー、あるいは本文を表示する必要性が生じることもあります。このデータをレポートに含める方法については、「executeHttpStep(stepName, requestOptions, [callback], [stepConfig])」を参照してください。
アプリケーションに最近デプロイしている場合には、一度ロールバックし、後にデバッグを行います。
エンドポイントに手動で接続し、同じ問題を再現できるかどうかを確認します。
トピック
- Canary ランタイムバージョンのアップグレードおよびダウングレードの問題
- 要素が表示されるのに時間がかかる
- ノードが表示されない、または page.click() での HTMLElement ではない
- アーティファクトを S3 にアップロードできない (Exception: Unable to fetch S3 bucket location: Access Denied)
- Error: Protocol error (Runtime.callFunctionOn): Target closed.
- Canary Failed. Error: No datapoint - Canary Shows timeout error
- 内部エンドポイントにアクセスしたい
- クロスオリジンリクエスト共有 (CORS) の問題
- VPC での Canary のトラブルシューティング
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 ではない
ノードが非表示になっているか、page.click()
での HTMLElement
ではない場合は、要素を参照するために使用している xpath
を確認します。また、要素が画面の下部に表示されている場合は、ビューポートを調整します。CloudWatch Synthetics では、デフォルトで 1920 × 1080 のビューポートが使用されます。ビューポートの設定変更は、ブラウザの起動時に行うことができます。または Puppeteer の page.setViewport
関数を使用しても変更できます。
アーティファクトを S3 にアップロードできない (Exception: Unable to fetch S3 bucket location: Access Denied)
Amazon S3 でのエラーが原因で Canary が失敗した場合は、アクセス許可に問題が生じるために、Canary 用に作成されたスクリーンショットやログ、またはレポートなどを、CloudWatch Synthetics がアップロードできなくなります。以下をチェックしてください。
s3:ListAllMyBuckets
アクセス許可、適切な Amazon S3 バケットへのs3:GetBucketLocation
アクセス許可、および Canary がアーティファクトを保存するバケットへのs3:PutObject
アクセス許可が、Canary の IAM ロールに付与済みであることを確認します。Canary がビジュアルモニターリングを実行する場合、ロールにはバケットへのs3:GetObject
アクセス許可も必要です。Canary が、暗号化用に標準の AWS 管理キー (デフォルト) ではなく AWS KMS 顧客管理キーを使用している場合、その Canary の IAM ロールは、対象のキーを使用して暗号化または復号を行うための許可を持っていないことがあります。詳細については、「Canary アーティファクトの暗号化」を参照してください。
バケットポリシーで、Canary が使用する暗号化メカニズムが許可されていない可能性があります。例えば、バケットポリシーで特定の暗号化メカニズムまたは KMS キーの使用が必須となっている場合は、Canary に対しても、同じ暗号化モードを選択する必要があります。
Canary がビジュアルモニターリングを実行する際の詳細については、「ビジュアルモニターリング使用時のアーティファクトの場所と暗号化の更新」を参照してください。
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 を作成または更新する際に、[スケジュール] で実行間隔とタイムアウト値 の両方を調整します。
Lambda コールドスタートと canary インストルメンテーションの起動にかかる時間を許容するために、canary タイムアウト値が 15 秒以上であることを確認してください。
このエラーが発生した場合、Canary のアーティファクトは、CloudWatch Synthetics コンソール上に表示されなくなります。CloudWatch Logs を使用して、Canary のログを表示できます。
CloudWatch Logs を使用して Canary のログを表示するには
CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/
) を開きます。 左側のナビゲーションペインで、[ロググループ] をクリックします。
フィルターボックスに 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 に渡す起動パラメータをオーバーライドできます。