翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon EventBridge スケジューラのトラブルシューティング
このセクションのトピックを使用して、Amazon EventBridge スケジューラの一般的な問題のトラブルシューティングを行えます。
**Topics**
+ [スケジュールがターゲットエラーで失敗する](#troubleshooting-target-errors)
+ [スケジュール実行ロールのアクセス許可の問題](#troubleshooting-perms)
+ [Service Quotas の理解と管理](#troubleshooting-quotas)
+ [スケジュールパターンとトリガータイミングの問題](#troubleshooting-timing)
+ [スケジュールパターンと cron 式の作成](#troubleshooting-patterns)
+ [ターゲットがトリガーされているか。](#troubleshooting-trigger-target)
+ [テンプレート化されたターゲットとユニバーサルターゲット](#troubleshooting-temp-universal-target)
+ [無効なユニバーサルターゲット入力設定](#troubleshooting-usi-target-input)
+ [予期しない呼び出しをトリガーする更新をスケジュールする](#troubleshooting-temp-universal-target-invoke)
+ [1 回限りのスケジュールの無効化または有効化](#troubleshooting-temp-universal-target-enable)
## スケジュールがターゲットエラーで失敗する
ターゲット呼び出しの失敗は、EventBridge スケジューラの最も一般的な問題の 1 つです。これらの障害は、以下のいくつかの理由で発生する可能性があります。
### 一般的な原因:
+ ターゲットパラメータがないか、正しくない。
+ ネットワーク接続の問題。
+ API スロットリング。
+ ターゲット設定が正しくない。
### トラブルシューティングのステップ
1. **デッドレターキュー (DLQ) を設定する**
+ DLQ は、失敗した呼び出しをキャプチャして分析するのに役立ちます。
+ 失敗した呼び出しは、詳細なエラーメッセージとともに DLQ に送信されます。
+ [DLQ を設定](configuring-schedule-dlq.md)するには、スケジュール設定に追加します。
```
{
"DeadLetterConfig": {
"Arn": "arn:aws:sqs:region:account-id:MyDLQ"
}
}
```
注: DLQ が KMS キーで暗号化されている場合は、キーポリシーで EventBridge スケジューラによる使用が許可されていることを確認してください。
```
{
"Sid": "Allow EventBridge Scheduler to use the key",
"Effect": "Allow",
"Principal": {
"Service": "scheduler.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*"
}
```
1. **API パラメータを確認する**
+ ターゲット API コールに必要なすべてのパラメータが存在し、正しくフォーマットされていることを確認します。
+ パラメータ値が許容範囲内であることを確認します。
+ VPC エンドポイントを使用している場合は、VPC から API エンドポイントにアクセスできることを確認します。
1. **ネットワーク設定を確認する**
+ 一時的なネットワークの問題が原因で呼び出しが失敗する場合は、[再試行](https://docs.aws.amazon.com/scheduler/latest/APIReference/API_RetryPolicy.html)ロジックを実装します。
+ 再試行ポリシーの例:
```
{
"RetryPolicy": {
"MaximumRetryAttempts": 3,
"MaximumEventAgeInSeconds": 3600
}
}
```
1. **ターゲット固有の設定を確認する**
+ テンプレート化されたターゲット (ECS タスクなど) の場合は、スケジュール作成 API の `Target.Input` パラメータを使用してオーバーライドを指定してください。
+ ターゲットサービスが[サポートされており](managing-targets-templated.md)、正しく設定されていることを確認します。
## スケジュール実行ロールのアクセス許可の問題
IAM ロールのアクセス許可の問題は、スケジュールの実行が失敗する一般的な理由です。これらの問題のトラブルシューティングと解決方法は次のとおりです。
### 一般的な原因
+ ターゲットサービスに必要なアクセス許可がない
+ スケジュールのロール設定が正しくない
+ EventBridge スケジューラサービスとの信頼関係がない
+ 暗号化されたリソースにアクセスするためのアクセス許可が不十分
### 症状
+ CloudWatch での `TargetErrorCount` メトリクスの増加
+ スケジュール設定で明らかな問題なくスケジュールを実行できない
### トラブルシューティングのステップ
1. **CloudWatch メトリクスのモニタリング**
+ CloudWatch で `TargetErrorCount` メトリクスをチェックします。
1. **デッドレターキュー (DLQ) を使用してアクセス許可の問題を確認する**
+ スケジュールに合わせて DLQ を設定します。
+ ターゲットにアクセス許可の問題があり、DLQ が正しく設定されている場合、DLQ に失敗した呼び出しとアクセス許可関連のエラーメッセージが表示されます。
+ CloudWatch メトリクスに失敗した実行にもかかわらず DLQ が空のままである場合、EventBridge スケジューラが DLQ 自体に書き込むことを妨げるアクセス許可の問題を示している可能性があります。
**注記**
DLQ 自体に正しいアクセス許可があるかどうかを確認します。暗号化されている場合は、EventBridge スケジューラに KMS キーを使用するアクセス許可があることを確認してください。
1. **信頼関係を検証する**
+ IAM ロールに EventBridge スケジューラとの正しい信頼関係があることを確認します。
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"Service": "scheduler.amazonaws.com"
},
"Action": "sts:AssumeRole"
}]
}
```
1. **スケジュール実行ロールのアクセス許可を確認する**
+ スケジュールの実行ロールには、さまざまなターゲットタイプを呼び出すための特定のアクセス許可が必要です。
+ スケジュールの実行ロールポリシーに含めるアクセス許可の例:
```
// For Lambda function targets - add to schedule execution role
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction"
],
"Resource": "arn:aws:lambda:region:account-id:function:function-name"
}]
}
// For SQS queue targets - add to schedule execution role
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:region:account-id:queue-name"
}]
}
```
1. **暗号化されたリソースアクセスを確認する**
+ ターゲットが暗号化されたリソース (KMS で暗号化された SQS キューなど) を使用している場合は、ロールに KMS キーを使用するアクセス許可があることを確認します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:region:account-id:key/key-id"
}
]
}
```
1. **ロール ARN 設定を確認する**
+ スケジュール設定のロール ARN が正しいことを確認します。
+ スケジュールと同じ AWS アカウント およびリージョンにロールが存在することを確認します。
## Service Quotas の理解と管理
スケジュールの作成や呼び出しのスロットリングに問題がある場合は、Service Quotas の制限に達している可能性があります。EventBridge スケジューラには、スケジュール数、スケジュールグループ、呼び出しレートのクォータがあり、リージョンによって異なる場合があります。
### クォータの問題の特定
クォータ制限に達しているかどうかを判断するには:
1. **CloudWatch メトリクスのモニタリング**
+ `InvocationThrottleCount` メトリクスを確認します。このメトリクスの増加は、呼び出しレートの制限を超えていることを示します。
+ `InvocationAttemptCount` メトリクスを確認して、現在の使用状況を把握します。
1. **特定のエラーメッセージを監視する**
+ スケジュールを作成または変更する場合、`LimitExceededException` はスケジュールまたはスケジュールグループの最大数に達したことを示します。
+ スロットリングエラーを返す API コールは、API リクエストのクォータを超えていることを示します。
### クォータの問題の解決
クォータ制限に達していると判断した場合:
1. 現在のスケジュールを確認して最適化します。同様のスケジュールを統合するか、未使用のスケジュールを削除することを検討してください。
1. API スロットリングの場合は、API コールに[バックオフによる再試行](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html)を実装します。
1. より高いクォータが必要な場合は、Service Quotas コンソールから引き上げをリクエストしてください。EventBridge スケジューラを選択し、引き上げるクォータを選択し、ビジネス上の理由とともにリクエストを送信します。
## スケジュールパターンとトリガータイミングの問題
ユーザーは、予定された時間にスケジュールがトリガーされない問題に遭遇することがあります。これは最も一般的に、スケジュールパターン、夏時間の変更、または柔軟な時間枠に関する誤解が原因である可能性があります。
### 一般的な原因
+ cron 式の誤解。
+ 夏時間の変更中の予期しない動作。
+ 柔軟な時間枠に関する混乱。
+ rate 式の誤解。
### トラブルシューティングのステップ
1. **cron 式を検証する**
+ cron 式の形式が正しいことを確認します。
+ cron 式では日フィールドと曜日フィールドの両方を同時に指定することはできないことに注意してください。
1. **タイムゾーンに関する考慮事項**
+ スケジュールの作成時に希望するタイムゾーンを選択します。
+ この調整は UTC に基づいているため、夏時間がスケジュールにどのように影響するかを理解します。
夏時間への影響の例: GMT 午前 7 時に実行するようにスケジュールを設定した場合:
+ 冬季: スケジュールは GMT 午前 7 時に実行されます (GMT = UTC)
+ 夏季: スケジュールは引き続き UTC 午前 7:00 に実行されます。現在は GMT/BST 午前 6:00 です。
スケジュールを一年中同じ現地時間で実行する必要がある場合は、スケジュールの作成時に適切なタイムゾーンを選択し、夏時間がどのようにそのタイムゾーンに影響するかを確認してください。
1. **柔軟な時間枠を理解する**
+ [柔軟な時間枠](managing-schedule-flexible-time-windows.md)により、EventBridge スケジューラは呼び出しを最適化できます。
+ スケジュールは、時間枠の開始時に正確にトリガーされない場合があります。
+ 実際の呼び出し時間をモニタリングして、動作を理解します。
1. **rate 式と cron 式を確認する**
+ rate 式の形式が正しいことを確認します (例: `rate(5 minutes)`、`rate(1 hour)`)。
+ rate 式と cron 式の両方でスケジュール呼び出しは 1 分間の 0 秒にクランプされないことに注意してください。
+ スケジュールは、指定された 1 分以内にトリガーされる場合がありますが、必ずしも 1 分の正確な開始時にトリガーされるとは限りません。
例えば、次のようになります。
+ `rate(1 hour)` を使用するスケジュールは、午後 2:00:45、午後 3:00:32、午後 4:00:18 などに実行される場合があります。
+ `0 * * * ? *` (1 時間ごと) に設定された cron スケジュールは、午後 2 時 00 分 15 秒、午後 3 時 00 分 7 秒、午後 4 時 00 分 52 秒などに実行される場合があります。
1. **CloudWatch メトリクスのモニタリング**
+ `InvocationAttemptCount` メトリクスを使用して、スケジュールがトリガーされているかどうかを確認します。
+ 呼び出しが失敗しているかどうか、`TargetErrorCount` を確認します。
+ デッドレターキューを設定している場合は、`InvocationsSentToDeadLetterCount` をモニタリングして、失敗した呼び出しを追跡します。
## スケジュールパターンと cron 式の作成
ユーザーが、特に cron 式でスケジュールパターンを作成するときに、問題が発生することがよくあります。一般的な問題とその対処方法は次のとおりです。
### 一般的な問題
+ cron 構文が正しくない
+ サポートされていない cron 機能の使用を試みる
+ 一緒に使用できるフィールドに関する混乱
### トラブルシューティングのステップ
1. **cron 式の構文を確認する**
+ cron 式が次のような正しい[形式](schedule-types.md#cron-based)であることを確認してください。`Minutes Hours Day-of-month Month Day-of-week Year`
+ EventBridge スケジューラは、追加の Year フィールドで cron 標準を使用することに注意してください。
1. **制限を理解する**
+ [ここ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-scheduled-rule-pattern.html#eb-cron-expressions)で説明するように、日フィールドと曜日フィールドの両方を同時に指定することはできません。
+ 1 分より短い間隔を導き出す cron 式はサポートされていません。
1. **スケジュールプレビュー機能を使用する**
+ スケジュールを作成または編集すると、EventBridge スケジューラは次の 10 の実行時間のプレビューを提供します。
+ このプレビューを使用して、スケジュールが意図した時間に実行されることを確認します。
+ プレビューが期待と一致しない場合は、cron 式を確認して調整します。
## ターゲットがトリガーされているか。
ターゲットがトリガーされているかどうかを確認するには:
1. CloudWatch メトリクスを確認します。
+ `InvocationAttemptCount` は、試行された呼び出しの数を示します
+ `TargetErrorCount` は、呼び出しが失敗したかどうかを示します
+ `TargetErrorThrottledCount` は、ターゲットがスロットリングされているかどうかを示します
+ `InvocationDroppedCount` は、呼び出しが削除されたかどうかを示します
1. 失敗した呼び出しをキャプチャして分析するよう[デッドレターキュー (DLQ) を設定](configuring-schedule-dlq.md)します。
## テンプレート化されたターゲットとユニバーサルターゲット
「提供されたリクエストが無効: [サービス] がターゲットでサポートされていないサービス」などのエラーが表示された場合は、サポートされていないサービスをテンプレート化されたターゲットとして使用しようとしている可能性があります。
これを解決するには:
1. 目的のサービスが[テンプレート化されたターゲット](managing-targets-templated.md)としてサポートされているかどうかを確認します。
1. サポートされていない場合は、代わりに[ユニバーサルターゲット](managing-targets-universal.md)を使用し、サービスに対して適切な API コールを行うように設定します。
## 無効なユニバーサルターゲット入力設定
[ユニバーサルターゲット](managing-targets-universal.md)を使用してスケジュールを作成すると、EventBridge スケジューラはターゲット ARN 形式を検証しますが、ダウンストリームサービスの API に対して `Input`フィールドの内容を検証しません。つまり、 にターゲットサービスが呼び出し時に拒否する値`Input`が含まれている場合でも、スケジュールは正常に作成できます。
無効なターゲット入力設定のスケジュールは、設定された式でトリガーされますが、呼び出しのたびに失敗します。スケジュールが呼び出されるまで、設定ミスを検出できない場合があります。これは、作成後数時間または数日になる可能性があります。
### 症状
+ スケジュールはエラーなしで作成されましたが、`TargetErrorCount`CloudWatch メトリクスは呼び出しごとに増加します。
+ DLQ メッセージには、 ではなく、ターゲットサービス ( `InvalidParameterValueException`や など`ValidationException`) からのエラーコードが含まれています`AWS.Scheduler.InternalServerError`。
+ DLQ メッセージの `ERROR_MESSAGE`は、特定の入力パラメータの検証の失敗を参照します。
### 例
次の例は、ユニバーサルターゲット () の AWS Lambda 一般的な無効な入力設定を示しています`arn:aws:scheduler:::aws-sdk:lambda:invoke`。
**修飾子の不一致**
次の入力のスケジュールでは、 `2`でバージョンを指定`FunctionName`し、 `Qualifier`フィールド`1`でバージョンを指定します。
```
{
"FunctionName": "MyFunction:2",
"Qualifier": "1"
}
```
このスケジュールは正常に作成されますが、すべての呼び出しは失敗します。DLQ メッセージには以下が含まれます。
+ `ERROR_CODE`: `InvalidParameterValueException`
+ `ERROR_MESSAGE`: `The derived qualifier from the function name does not match the specified qualifier.`
**無効な関数名**
次の入力のスケジュールは、 の空白のみの値を指定します`FunctionName`。
```
{
"FunctionName": " "
}
```
DLQ メッセージには以下が含まれます。
+ `ERROR_CODE`: `ValidationException`
+ `ERROR_MESSAGE`: 関数名が必須パターンと一致していないことを示す検証エラー。
### 解決方法
1. **DLQ を設定します。**ユニバーサルターゲットを使用するスケジュールには[、必ずデッドレターキューを設定します](configuring-schedule-dlq.md)。DLQ メッセージ属性 (`ERROR_CODE` および `ERROR_MESSAGE`) には、無効な入力パラメータを識別するターゲットサービスによって返される特定のエラーが含まれています。
1. **ターゲットサービス API に対して入力パラメータを検証します。**スケジュールを作成する前に、ターゲット API を直接呼び出して、 `Input`フィールドの JSON に有効な値が含まれていることを確認します。たとえば、 API を使用して同じパラメータで AWS Lambda 関数を AWS Lambda `Invoke`呼び出し、リクエストが成功したことを確認します。
1. **1 回限りのスケジュールでテストします。**1 回限りのスケジュールを作成して、定期的なスケジュールを設定する前にターゲット呼び出しが成功することを確認します。
1. **ターゲットサービス API リファレンスを確認します。**ターゲットとするサービスの API リファレンスをチェックして、必要なパラメータ、有効な値の範囲、制約を確認します。については AWS Lambda `Invoke`、「 *AWS Lambda デベロッパーガイド*」の[「呼び出し](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html)」を参照してください。
## 予期しない呼び出しをトリガーする更新をスケジュールする
スケジュールを変更すると、呼び出しに更新されたスケジュールがすぐには反映されない場合があります。変更が有効になるまで、しばらくお待ちください。例えば、元のトリガー時間に近いスケジュールを更新すると、元のスケジュール設定に基づいて呼び出しが表示されることがあります。
## 1 回限りのスケジュールの無効化または有効化
元のスケジュールされた時刻が経過した後に 1 回限りのスケジュールを再度有効にすると、スケジュールはすぐにターゲットを呼び出すことがあります。これは、スケジュールが元の実行時間より前に無効になっていても発生する可能性があります。
例えば、次のようになります。
+ 現在の時刻: 13:15 UTC
+ 1 回限りのスケジュールの作成: 13:30 UTC
+ スケジュールは 13:30 UTC より前に無効になりました
+ スケジュールが 14:00 UTC に再度有効になりました
+ 結果: ターゲットは、再度有効にするとすぐに呼び出される可能性があります