# 失敗した Canary のトラブルシューティング
Canary が失敗した場合は、以下を確認しトラブルシューティングしてください。
**一般的なトラブルシューティング**
+ Canary の詳細ページを開き、詳細を確認します。CloudWatch コンソールのナビゲーションウィンドウで [**Canaries**] をクリックし、詳細ページを開きたい Canary の名前を選択します。[**可用性**] タブで [**SuccessPercent**] メトリクスを参照し、発生している問題が持続的か断続的かを確認します。
同じ [**可用性**] タブで、失敗したデータポイントを選択することで、失敗した実行のスクリーンショット、ログ、および (それがある場合には) ステップレポートを見ることができます。
ステップがスクリプトの一部でありステップレポートを使用できる場合は、どのステップが失敗したかを確認し、顧客側に表示されたメッセージを見るために関連するスクリーンショットを参照します。
HAR ファイルをチェックして、失敗が 1 つ以上のリクエストで発生しているかどうかを確認することもできます。ログを使用すると、失敗したリクエストとエラーの詳細について、より深く掘り下げることができます。さらに、これらのアーティファクトと成功した Canary 実行のアーティファクトを比較すれば、問題の特定が可能です。
CloudWatch Synthetics は、デフォルトで、UI Canary の各ステップのスクリーンショットをキャプチャします。ただし、スクリーンショットを無効にするようにスクリプトが構成されている場合もあり得ます。その場合は、デバッグ中にスクリーンショットを再度有効にします。同様に、API Canary のデバッグ中に、HTTP リクエストと応答ヘッダー、あるいは本文を表示する必要性が生じることもあります。このデータをレポートに含める方法については、「[executeHttpStep(stepName, requestOptions, [callback], [stepConfig])](CloudWatch_Synthetics_Canaries_Library_Nodejs.md#CloudWatch_Synthetics_Library_executeHttpStep)」を参照してください。
+ アプリケーションに最近デプロイしている場合には、一度ロールバックし、後にデバッグを行います。
+ エンドポイントに手動で接続し、同じ問題を再現できるかどうかを確認します。
**Topics**
+ [Lambda 環境の更新後に Canary が失敗する](#Troubleshoot_upgradeLambda)
+ [Canary が AWS WAF によってブロックされている](#Canary_Blocked_WAF)
+ [要素が表示されるのに時間がかかる](#CloudWatch_Synthetics_Canaries_Troubleshoot_waiting)
+ [ノードが表示されない、または page.click() での HTMLElement ではない](#CloudWatch_Synthetics_Canaries_Troubleshoot_notvisible)
+ [アーティファクトを S3 にアップロードできない (Exception: Unable to fetch S3 bucket location: Access Denied)](#CloudWatch_Synthetics_Canaries_Troubleshoot_noupload)
+ [Error: Protocol error (Runtime.callFunctionOn): Target closed。](#CloudWatch_Synthetics_Canaries_Troubleshoot_protocolError)
+ [Canary Failed。Error: No datapoint - Canary Shows timeout error](#CloudWatch_Synthetics_Canaries_Troubleshoot_nodatapoint)
+ [内部エンドポイントにアクセスしたい](#CloudWatch_Synthetics_Canaries_Troubleshoot_internalendpoint)
+ [Canary ランタイムバージョンのアップグレードおよびダウングレードの問題](#CloudWatch_Synthetics_Canaries_Troubleshoot_upgradeissues)
+ [クロスオリジンリクエスト共有 (CORS) の問題](#CloudWatch_Synthetics_Canaries_CORS)
+ [Canary 競合状態に関する問題](#CloudWatch_Synthetics_Canaries_RaceCondition)
+ [VPC での Canary のトラブルシューティング](#CloudWatch_Synthetics_Canaries_VPC_troubleshoot)
+ [自動再試行 Canary のトラブルシューティング](#CloudWatch_Synthetics_Canaries_autoretry)
## Lambda 環境の更新後に Canary が失敗する
CloudWatch Synthetics Canary は、アカウントに Lambda 関数として実装されます。これらの Lambda 関数は、セキュリティ更新プログラム、バグ修正、その他の改善を含む Lambda ランタイムの定期的な更新の対象です。Lambda は、既存の関数との後方互換性を備えたランタイム更新を提供するように努めていますが、ソフトウェアパッチと同様に、ランタイム更新が既存の関数に悪影響を及ぼす状況がまれに発生します。Canary が Lambda ランタイム更新の影響を受けたと思われる場合は、(サポートされているリージョン内で) Lambda ランタイム管理手動モードを使用して、Lambda ランタイムバージョンを一時的にロールバックできます。そうすることで、Canary 関数が引き続き機能し、中断が最小限に抑えられるので、最新のランタイムバージョンに戻る前に非互換性を修正する時間を確保できます。
Lambda ランタイムの更新後に Canary が失敗した場合、最良の解決策は、最新の Synthetics ランタイムのいずれかにアップグレードすることです。最新のランタイムの詳細については、「[Synthetics のランタイムバージョン](CloudWatch_Synthetics_Canaries_Library.md)」を参照してください。
別の方法として、Lambda ランタイム管理コントロールが使用可能なリージョンでは、ランタイム管理コントロールの手動モードを使用して、Canary を古い Lambda マネージドランタイムに戻すことができます。手動モードは、AWS CLI または Lambda コンソールを使用して、以下のセクションのステップに従って設定できます。
**警告**
ランタイム設定を手動モードに変更すると、Lambda 関数は自動モードに戻るまで自動セキュリティ更新を受信しなくなります。この間、Lambda 関数はセキュリティの脆弱性の影響を受けやすくなる可能性があります。
**前提条件**
+ [jq](https://jqlang.github.io/jq/) のインストール
+ AWS CLI の最新バージョンをインストールします。詳細については「[AWS CLI のインストールと更新の手順](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html#getting-started-install-instructions)」を参照してください。
### ステップ 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](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-update.html#runtime-management-identify.html)」の手順に従って、以前のランタイムの 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/](https://console.aws.amazon.com/lambda/) を開いてください。
1. **[バージョン]** タブで ARN に対応するバージョン番号リンクを選択し、**[コード]** タブを選択します。
1. **[ランタイム設定]** までスクロールし、**[ランタイム管理設定]** を展開して、**[ランタイムバージョン ARN]**をコピーします。
![画面の [ランタイム設定] セクションを示し、このセクションの [ランタイムバージョン ARN] が表示される場所を示します。](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/SyntheticsManual1.png)
1. **[ランタイム管理設定を編集]**、**[手動]** の順に選択し、前にコピーしたランタイムバージョン ARN を**[ランタイムバージョン ARN]** フィールドに貼り付けます。次に、**[Save (保存)]** を選択します。
![[ランタイム管理設定] 画面を示し、以前にコピーした [ランタイムバージョン ARN] を貼り付ける場所を示します。](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/SyntheticsManual2.png)
## Canary が AWS WAF によってブロックされている
AWS WAF 経由の Canary トラフィックを許可するには、指定したカスタム文字列を許可する AWS WAF 文字列の一致の状態を作成します。詳細については、AWS WAF ドキュメントの「[Working with string match conditions](https://docs.aws.amazon.com/waf/latest/developerguide/classic-web-acl-string-conditions.html)」を参照してください。
デフォルト値ではなく、独自のカスタムユーザーエージェント文字列を使用することを強くお勧めします。その場合、AWS WAF フィルタリングをより詳細に制御し、セキュリティを向上させることができます。
カスタムユーザーエージェント文字列を設定するには、以下を実行します。
+ Playwright ランタイムの場合、Synthetics 設定ファイルを使用して、AWS WAF 承認済みのカスタム user-agent 文字列を追加できます。詳細については、「[CloudWatch Synthetics の設定](Synthetics_WritingCanary_Nodejs_Playwright.md#Synthetics_canary_configure_Playwright_script)」を参照してください。
+ Puppeteer または Selenium ランタイムの場合、サポートされているライブラリ関数を使用してカスタム user-agent 文字列を追加できます。Puppeteer ランタイムについては、「[async addUserAgent(page, userAgentString);](CloudWatch_Synthetics_Canaries_Library_Nodejs.md#CloudWatch_Synthetics_Library_addUserAgent)」を参照してください。Selenium ランタイムについては、「[add\_user\_agent(user\_agent\_str)](CloudWatch_Synthetics_Canaries_Library_Python.md#CloudWatch_Synthetics_Library_add_user_agent)」を参照してください。
## 要素が表示されるのに時間がかかる
ログとスクリーンショットを分析した後、要素が画面に表示されるまで待機しているスクリプトがタイムアウトしてしまう場合には、関連するスクリーンショットを参照して、要素がページに表示されているかどうかを確認します。`xpath` に誤りがないことを確認します。
Puppetteer 関連の問題については、[Puppeteer の GitHub ページ](https://github.com/puppeteer/puppeteer/issues)、またはインターネットのフォーラムを参照してください。
## ノードが表示されない、または 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 アーティファクトの暗号化](CloudWatch_Synthetics_artifact_encryption.md)」を参照してください。
+ バケットポリシーで、Canary が使用する暗号化メカニズムが許可されていない可能性があります。例えば、バケットポリシーで特定の暗号化メカニズムまたは KMS キーの使用が必須となっている場合は、Canary に対しても、同じ暗号化モードを選択する必要があります。
Canary がビジュアルモニターリングを実行する際の詳細については、「[ビジュアルモニターリング使用時のアーティファクトの場所と暗号化の更新](CloudWatch_Synthetics_artifact_encryption.md#CloudWatch_Synthetics_artifact_encryption_visual)」を参照してください。
## 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/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. 左側のナビゲーションペインで、[**ロググループ**] をクリックします。
1. フィルターボックスに Canary 名を入力して、ロググループを検索します。Canary のロググループの名前は、**/aws/lambda/cwsyn-{{canaryName}} -randomId** です。
## 内部エンドポイントにアクセスしたい
Canary が内部ネットワーク上のエンドポイントにアクセスできるようにするには、CloudWatch Synthetics で VPC を使用するようにセットアップすることをお勧めします。詳細については、「[VPC で Canary を実行する](CloudWatch_Synthetics_Canaries_VPC.md)」を参照してください。
## Canary ランタイムバージョンのアップグレードおよびダウングレードの問題
最近、ランタイムバージョン `syn-1.0` から新しいバージョンに Canary をアップグレードした場合は、クロスオリジンリクエスト共有 (CORS) の問題が発生する可能性があります。詳細については、「[クロスオリジンリクエスト共有 (CORS) の問題](#CloudWatch_Synthetics_Canaries_CORS)」を参照してください。
最近、Canary を古いランタイムバージョンにダウングレードした場合は、使用している CloudWatch Synthetics 関数が、古い方のランタイムバージョンでも利用可能であることを確認します。例えば、`executeHttpStep` 関数はランタイムバージョン `syn-nodejs-2.2` 以降であれば使用が可能です。関数の可用性を確認するには、「[Canary スクリプトの作成](CloudWatch_Synthetics_Canaries_WritingCanary.md)」を参照してください。
**注記**
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` フラグパラメータを渡すことができます。詳細については、「[Puppeteer を使用した Node.js Canary スクリプト用のライブラリ関数](CloudWatch_Synthetics_Canaries_Library_Nodejs.md)」を参照してください。
**注記**
ランタイムバージョン `syn-nodejs-2.1` 以降を使用している場合は、CloudWatch Synthetics に渡す起動パラメータをオーバーライドできます。
## Canary 競合状態に関する問題
CloudWatch Synthetics を使用するときに満足できるエクスペリエンスを得るには、Canary 用に記述されたコードがべき等性であることを確認します。そうしないと、まれに、Canary が複数の実行で同じリソースとやりとりを行うと、Canary の実行で競合状態が発生することがあります。
## VPC での Canary のトラブルシューティング
VPC 内で Canary を作成または更新した後に問題が発生した場合は、以下のいずれかのセクションを参照して問題のトラブルシューティングを行ってください。
### 新しい Canary がエラー状態になるか、Canary を更新できない
VPC で実行する Canary を作成した場合に、すぐにエラー状態になったり、VPC で実行するように Canary を更新したりできないときは、Canary のロールに適切なアクセス許可がない可能性があります。Canary を VPC で実行する場合には、アクセス許可として ` ec2:CreateNetworkInterface`、`ec2:DescribeNetworkInterfaces`、および ` ec2:DeleteNetworkInterface` が必要です。これらのすべてのアクセス許可は、` AWSLambdaVPCAccessExecutionRole` 管理ポリシーに含まれています。詳細については、「[実行ロールおよびユーザーアクセス許可](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html#vpc-permissions)」を参照してください。
Canary の作成時にこの問題が発生した場合は、この Canary を削除して新しい Canary を作成する必要があります。CloudWatch コンソールを使用して新しい Canary を作成する場合は、[**アクセス許可**]、[**新しいロールの作成**] の順に選択します。Canary の実行に必要なすべてのアクセス許可を備えた新しいロールが作成されます。
この問題が Canary の更新時に発生した場合は、Canary を再度更新して、必要なアクセス許可を備えた新しいロールを指定できます。
### 「テスト結果が返されませんでした」エラー
Canary に「テスト結果が返されませんでした」というエラーが表示される場合は、次のいずれかの問題が原因である可能性があります。
+ VPC にインターネットアクセスがない場合は、VPC エンドポイントを使用して CloudWatch および Amazon S3 へのアクセスを Canary に許可する必要があります。これらのエンドポイントアドレスを正しく解決するには、VPC で [**DNS 解決**] オプションと [**DNS ホスト名**] オプションを有効にする必要があります。詳細については、「[VPC での DNS の使用](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html)」および「[インターフェイス VPC エンドポイントでの CloudWatch および CloudWatch Synthetics の使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-interface-VPC.html)」を参照してください。
+ Canary は、VPC 内のプライベートサブネットで実行する必要があります。これを確認するには、VPC コンソールで [**サブネット**] ページを開きます。Canary の設定時に選択したサブネットを確認します。インターネットゲートウェイ (**igw-**) へのパスがある場合、これらはプライベートサブネットではありません。
これらの問題のトラブルシューティングを行うには、Canary のログを参照してください。
**Canary のログイベントを表示するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、[**Log groups**] (ロググループ) を選択します。
1. Canary のロググループの名前を選択します。ロググループ名は ` /aws/lambda/cwsyn-{{canary-name}}` で始まります。
## 自動再試行 Canary のトラブルシューティング
次のトラブルシューティングのステップを実行することで、Canary が失敗した理由を把握し、試行が失敗した原因を分析できます。
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、**[Application Signals]**、**[Synthetics Canary]** の順に選択します。
1. **[Canary]** を選択します。
1. **[可用性]** タブから、次のいずれかの方法で実行の詳細を確認できます。
+ [Canary 実行] グラフで任意の位置を選択する
+ **[問題]** で、レコードを選択する。再試行にはタグが付けられており、タイムスタンプが該当のスケジュール実行と同じになっています。
追加情報は **[ステップ]**、**[スクリーンショット]**、**[ログ]**、**[HAR ファイル]**、または **[トレース] **(アクティブトレースが有効な場合) から確認できます。
1. **[Canary アーティファクトと Amazon S3 の場所]** からアーティファクトにアクセスし、有効なリンクを使用して Amazon S3 フォルダやバケットに移動できます。
1. **[Canary 実行]** グラフでは、次のようなステータスが色付きの点で表されます。
+ 青色の点 – スケジュールされた実行が 100% 安定して成功していることを示します。
+ 赤色の点 – スケジュールされた実行とすべての再試行がどちらも 0% で失敗していることを示します。
+ オレンジ色の点 – 0% または 100% のいずれかが表示されます。0% は前回の試行が失敗し再試行中であることを、100% は再試行後に成功したことを示します。