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

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

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

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

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

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

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

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

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

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

トピック

• Lambda 環境の更新後に Canary が失敗する
• Canary が AWS WAF によってブロックされている
• 要素が表示されるのに時間がかかる
• ノードが表示されない、または 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
• 内部エンドポイントにアクセスしたい
• Canary ランタイムバージョンのアップグレードおよびダウングレードの問題
• クロスオリジンリクエスト共有 (CORS) の問題
• VPC での Canary のトラブルシューティング

Lambda 環境の更新後に Canary が失敗する

CloudWatch Synthetics Canary は、アカウントに Lambda 関数として実装されます。これらの Lambda 関数は、セキュリティ更新プログラム、バグ修正、その他の改善を含む Lambda ランタイムの定期的な更新の対象です。Lambda は、既存の関数との後方互換性を備えたランタイム更新を提供するように努めていますが、ソフトウェアパッチと同様に、ランタイム更新が既存の関数に悪影響を及ぼす状況がまれに発生します。Canary が Lambda ランタイム更新の影響を受けたと思われる場合は、(サポートされているリージョン内で) Lambda ランタイム管理手動モードを使用して、Lambda ランタイムバージョンを一時的にロールバックできます。そうすることで、Canary 関数が引き続き機能し、中断が最小限に抑えられるので、最新のランタイムバージョンに戻る前に非互換性を修正する時間を確保できます。

Lambda ランタイムの更新後に Canary が失敗した場合、最良の解決策は、最新の Synthetics ランタイムのいずれかにアップグレードすることです。最新のランタイムの詳細については、「Synthetics のランタイムバージョン」を参照してください。

別の方法として、Lambda ランタイム管理コントロールが使用可能なリージョンでは、ランタイム管理コントロールの手動モードを使用して、Canary を古い Lambda マネージドランタイムに戻すことができます。手動モードは、AWS CLI または Lambda コンソールを使用して、以下のセクションのステップに従って設定できます。

警告

ランタイム設定を手動モードに変更すると、Lambda 関数は自動モードに戻るまで自動セキュリティ更新を受信しなくなります。この間、Lambda 関数はセキュリティの脆弱性の影響を受けやすくなる可能性があります。

前提条件

• jq のインストール

• AWS CLI の最新バージョンをインストールします。詳細については「AWS CLI のインストールと更新の手順」を参照してください。

ステップ 1: Lambda 関数 ARN を取得する

以下のコマンドを実行して、レスポンスから EngineArn フィールドを取得します。この EngineArn は、Canary に関連付けられている Lambda 関数の ARN です。この ARN は次のステップで使用します。

aws synthetics get-canary --name my-canary | jq '.Canary.EngineArn'

EngingArn の出力例:

"arn:aws:lambda:us-west-2:123456789012:function:cwsyn-my-canary-dc5015c2-db17-4cb5-afb1-EXAMPLE991:8"

ステップ 2: 最後の正常な Lambda ランタイムバージョン ARN を取得する

Canary が Lambda ランタイム更新の影響を受けたかどうかを理解するには、ログの Lambda ランタイムバージョンの ARN 変更日時が、Canary への影響が確認された日時にと一致するかどうかを確認します。一致しない場合、問題の原因は Lambda ランタイムの更新ではない可能性があります。

Canary が Lambda ランタイム更新の影響を受けている場合は、以前使用していた、正常に動作する Lambda ランタイムバージョンの ARN を特定する必要があります。「Identifying runtime version changes」の手順に従って、以前のランタイムの ARN を見つけます。ランタイムバージョン ARN を記録してステップ 3 に進み、ランタイム管理設定を設定します。

Canary が Lambda 環境の更新の影響をまだ受けていない場合は、現在使用している Lambda ランタイムバージョンの ARN を確認できます。以下のコマンドを実行して、レスポンスから Lambda 関数の RuntimeVersionArn を取得します。

aws lambda get-function-configuration \
--function-name "arn:aws:lambda:us-west-2:123456789012:function:cwsyn-my-canary-dc5015c2-db17-4cb5-afb1-EXAMPLE991:8" | jq '.RuntimeVersionConfig.RuntimeVersionArn'

RuntimeVersionArn の出力例:

"arn:aws:lambda:us-west-2::runtime:EXAMPLE647b82f490a45d7ddd96b557b916a30128d9dcab5f4972911ec0f"

ステップ 3: Lambda ランタイム管理設定を更新する

AWS CLI または Lambda コンソールを使用して、ランタイム管理設定を更新できます。

AWS CLI を使用して Lambda ランタイム管理設定の手動モードを設定するには

以下のコマンドを入力して、Lambda 関数のランタイム管理を手動モードに変更します。function-name と qualifier は、ステップ 1 で確認した値の Lambda 関数 ARN と Lambda 関数のバージョン番号にそれぞれ置き換えてください。また、runtime-version-arn もステップ 2 で確認したバージョン ARN に置き換えます。

aws lambda put-runtime-management-config \
    --function-name "arn:aws:lambda:us-west-2:123456789012:function:cwsyn-my-canary-dc5015c2-db17-4cb5-afb1-EXAMPLE991" \
    --qualifier 8 \
    --update-runtime-on "Manual" \
    --runtime-version-arn "arn:aws:lambda:us-west-2::runtime:a993d90ea43647b82f490a45d7ddd96b557b916a30128d9dcab5f4972911ec0f"

Lambda コンソールを使用して Canary を手動モードに変更するには

1. AWS Lambda コンソールを https://console.aws.amazon.com/lambda/ で開きます。

2. [バージョン] タブで ARN に対応するバージョン番号リンクを選択し、[コード] タブを選択します。

3. [ランタイム設定] までスクロールし、[ランタイム管理設定] を展開して、[ランタイムバージョン ARN]をコピーします。

   

4. [ランタイム管理設定を編集]、[手動] の順に選択し、前にコピーしたランタイムバージョン ARN を[ランタイムバージョン ARN] フィールドに貼り付けます。次に、[Save] (保存) を選択します。

   

Canary が AWS WAF によってブロックされている

AWS WAF が Canary をブロックしないようにするには、文字列 CloudWatchSynthetics を許可する AWS WAF 文字列一致条件を設定します。詳細については、AWS WAF ドキュメントの「Working with string match conditions」を参照してください。

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

ログとスクリーンショットを分析した後、要素が画面に表示されるまで待機しているスクリプトがタイムアウトしてしまう場合には、関連するスクリーンショットを参照して、要素がページに表示されているかどうかを確認します。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 を VPC エンドポイントのある VPC にデプロイしている場合は、Amazon VPC S3 ゲートウェイエンドポイントポリシーにもこれらと同じアクセス権限が必要です。

• 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 のログを表示するには

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

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

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

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

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

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

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

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

注記

Canary のランタイムバージョンをアップグレードまたはダウングレードする場合は、まず Canary をクローンし、複製された方の Canary でランタイムバージョンを変更することをお勧めします。新しいランタイムバージョンのクローンが機能することを確認したら、元の 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 に渡す起動パラメータをオーバーライドできます。