Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Résolution des problèmes liés à Amazon EventBridge Scheduler
Vous pouvez utiliser les rubriques de cette section pour résoudre les problèmes courants liés à Amazon EventBridge Scheduler.
**Topics**
+ [Mon planning échoue en raison d'erreurs de ciblage](#troubleshooting-target-errors)
+ [Problèmes d'autorisation liés aux rôles d'exécution du planning](#troubleshooting-perms)
+ [Comprendre et gérer les quotas de service](#troubleshooting-quotas)
+ [Problèmes de schéma de planification et de synchronisation des déclencheurs](#troubleshooting-timing)
+ [Création de modèles de planification et d'expressions cron](#troubleshooting-patterns)
+ [Ma cible est-elle déclenchée ?](#troubleshooting-trigger-target)
+ [Objectifs modélisés ou objectifs universels](#troubleshooting-temp-universal-target)
+ [Configurations d'entrée cible universelles non valides](#troubleshooting-usi-target-input)
+ [Planifier des mises à jour déclenchant des appels inattendus](#troubleshooting-temp-universal-target-invoke)
+ [Désactiver ou activer les plannings ponctuels](#troubleshooting-temp-universal-target-enable)
## Mon planning échoue en raison d'erreurs de ciblage
Les échecs d'invocation de Target sont l'un des problèmes les plus courants liés au EventBridge planificateur. Ces défaillances peuvent survenir pour plusieurs raisons :
### Causes courantes :
+ Paramètres cibles manquants ou incorrects.
+ Problèmes de connectivité réseau.
+ Limitation de l'API.
+ Configuration cible incorrecte.
### Étapes de résolution des problèmes
1. **Configuration d'une file d'attente de lettres mortes (DLQ)**
+ Un DLQ vous aide à capturer et à analyser les appels qui ont échoué.
+ Les appels ayant échoué sont envoyés au DLQ avec des messages d'erreur détaillés.
+ Pour [configurer un DLQ](configuring-schedule-dlq.md), ajoutez-le à votre configuration de planification :
```
{
"DeadLetterConfig": {
"Arn": "arn:aws:sqs:region:account-id:MyDLQ"
}
}
```
Remarque : Si votre DLQ est chiffrée avec une clé KMS, assurez-vous que la politique en matière de clés autorise EventBridge Scheduler à l'utiliser :
```
{
"Sid": "Allow EventBridge Scheduler to use the key",
"Effect": "Allow",
"Principal": {
"Service": "scheduler.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*"
}
```
1. **Vérifier les paramètres de l'API**
+ Assurez-vous que tous les paramètres requis pour vos appels d'API cibles sont présents et correctement formatés.
+ Vérifiez que les valeurs des paramètres se situent dans les plages autorisées.
+ Vérifiez que le point de terminaison de l'API est accessible depuis votre VPC si vous utilisez des points de terminaison VPC.
1. **Vérifiez la configuration du réseau**
+ Si les appels échouent en raison de problèmes réseau transitoires, implémentez une logique de [nouvelle tentative](https://docs.aws.amazon.com/scheduler/latest/APIReference/API_RetryPolicy.html).
+ Exemple de politique de nouvelle tentative :
```
{
"RetryPolicy": {
"MaximumRetryAttempts": 3,
"MaximumEventAgeInSeconds": 3600
}
}
```
1. **Vérifiez les configurations spécifiques à la cible**
+ Pour les cibles modélisées (comme les tâches ECS), assurez-vous de fournir des remplacements via le `Target.Input` paramètre de l'API de création de calendrier.
+ Vérifiez que votre service cible est [pris en charge](managing-targets-templated.md) et correctement configuré.
## Problèmes d'autorisation liés aux rôles d'exécution du planning
Les problèmes d'autorisation liés aux rôles IAM sont une cause fréquente d'échec de l'exécution du planning. Voici comment résoudre et résoudre ces problèmes :
### Causes courantes
+ Autorisations requises manquantes pour le service cible
+ Configuration de rôle incorrecte dans le planning
+ Relation de confiance manquante avec le service EventBridge Scheduler
+ Autorisations insuffisantes pour accéder aux ressources chiffrées
### Symptômes
+ `TargetErrorCount`Métrique accrue dans CloudWatch
+ Les plannings ne s'exécutent pas sans problèmes apparents dans la configuration des plannings
### Étapes de résolution des problèmes
1. **Surveiller CloudWatch les métriques**
+ Vérifiez la `TargetErrorCount` métrique CloudWatch.
1. **Utilisez Dead-Letter Queue (DLQ) pour confirmer les problèmes d'autorisation**
+ Configurez un DLQ pour votre emploi du temps.
+ Si votre cible présente des problèmes d'autorisation et que le DLQ est correctement configuré, vous verrez les appels ayant échoué dans le DLQ avec des messages d'erreur liés aux autorisations.
+ Si le DLQ reste vide alors que les échecs d'exécution apparaissent dans CloudWatch les métriques, cela indique probablement un problème d'autorisation empêchant le EventBridge Scheduler d'écrire dans le DLQ lui-même.
**Note**
Assurez-vous que le DLQ lui-même dispose des autorisations appropriées. S'il est chiffré, assurez-vous que EventBridge Scheduler est autorisé à utiliser la clé KMS.
1. **Vérifier la relation de confiance**
+ Assurez-vous que votre rôle IAM entretient la bonne relation de confiance avec EventBridge Scheduler :
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"Service": "scheduler.amazonaws.com"
},
"Action": "sts:AssumeRole"
}]
}
```
1. **Vérifier les autorisations des rôles d'exécution du calendrier**
+ Le rôle d'exécution du planning nécessite des autorisations spécifiques pour invoquer différents types de cibles.
+ Exemples d'autorisations à inclure dans la politique des rôles d'exécution de votre planning :
```
// 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. **Vérifiez l'accès aux ressources chiffrées**
+ Si votre cible utilise des ressources chiffrées (par exemple, des files d'attente SQS cryptées par KMS), assurez-vous que votre rôle est autorisé à utiliser la clé KMS :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:region:account-id:key/key-id"
}
]
}
```
1. **Vérifier la configuration de l'ARN du rôle**
+ Assurez-vous que l'ARN du rôle est correct dans la configuration de votre planification.
+ Vérifiez que le rôle existe dans la même Compte AWS région que votre emploi du temps.
## Comprendre et gérer les quotas de service
Si vous rencontrez des problèmes lors de la création de plannings ou si le nombre d'appels est limité, il se peut que vous atteigniez les limites du quota de service. EventBridge Le planificateur dispose de quotas pour le nombre de calendriers, de groupes d'horaires et de taux d'invocation, qui peuvent varier selon les régions.
### Identifier les problèmes liés aux quotas
Pour déterminer si vous atteignez les limites de quotas, procédez comme suit :
1. **Surveiller CloudWatch les métriques**
+ Vérifiez la `InvocationThrottleCount` métrique. Une augmentation de cette métrique indique que vous dépassez votre limite de taux d'invocation.
+ Passez en revue la `InvocationAttemptCount` métrique pour comprendre votre utilisation actuelle.
1. **Surveillez les messages d'erreur spécifiques**
+ Lorsque vous créez ou modifiez des plannings, a `LimitExceededException` indique que vous avez atteint le nombre maximum de plannings ou de groupes de plannings.
+ Les appels d'API renvoyant des erreurs de régulation indiquent que vous dépassez le quota de demandes d'API.
### Résolution des problèmes de quotas
Si vous déterminez que vous atteignez les limites de quotas :
1. Passez en revue et optimisez vos horaires actuels. Envisagez de consolider les programmes similaires ou de supprimer ceux qui ne sont pas utilisés.
1. Pour la régulation des API, implémentez une [nouvelle tentative avec interruption dans vos appels d'](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html)API.
1. Si vous avez besoin de quotas plus élevés, demandez une augmentation via la console Service Quotas. Sélectionnez EventBridge Scheduler, choisissez le quota que vous devez augmenter et soumettez une demande avec la justification de votre activité.
## Problèmes de schéma de planification et de synchronisation des déclencheurs
Les utilisateurs rencontrent parfois des problèmes lorsque les horaires ne se déclenchent pas aux heures prévues. Cela peut être le plus souvent dû à des malentendus concernant les modèles d'horaires, les changements d'heure d'été ou les fenêtres horaires flexibles.
### Causes courantes
+ Mauvaise interprétation des expressions cron.
+ Comportement inattendu lors des changements d'heure d'été.
+ Confusion au sujet des fenêtres horaires flexibles.
+ Mauvaise compréhension des expressions des taux.
### Étapes de résolution des problèmes
1. **Vérifier les expressions cron**
+ Assurez-vous que votre expression cron est correctement formatée.
+ Notez que vous ne pouvez pas spécifier day-of-month les deux day-of-week champs simultanément dans une expression cron.
1. **Considérations relatives au fuseau horaire**
+ Sélectionnez votre fuseau horaire préféré lors de la création du calendrier.
+ Comprenez l'impact de l'heure d'été sur votre emploi du temps, car cet ajustement est basé sur l'UTC.
Exemple d'impact de l'heure d'été : si vous configurez un calendrier pour qu'il soit exécuté à 7 h 00 GMT :
+ En hiver : l'horaire commence à 7 h 00 GMT (car GMT = UTC)
+ Pendant l'été : le programme fonctionne toujours à 7 h 00 UTC, soit maintenant 6 h 00 GMT/BST
Si vous souhaitez que l'horaire fonctionne à la même heure locale toute l'année, assurez-vous de sélectionner le fuseau horaire approprié lors de la création de l'horaire et de savoir comment le changement d'heure peut affecter ce fuseau horaire.
1. **Comprendre les fenêtres horaires flexibles**
+ Les [fenêtres temporelles flexibles](managing-schedule-flexible-time-windows.md) permettent au EventBridge planificateur d'optimiser les invocations.
+ Il est possible que le calendrier ne se déclenche pas exactement au début de la fenêtre.
+ Surveillez les temps d'invocation réels pour comprendre le comportement.
1. **Taux de révision et expressions cron**
+ Assurez-vous que les expressions de taux sont correctement formatées (par exemple,`rate(5 minutes)`,`rate(1 hour)`).
+ Pour les expressions rate et cron, sachez que les invocations de planning ne sont pas limitées à la dixième seconde de minute.
+ Les horaires peuvent être déclenchés dans la minute spécifiée, mais pas nécessairement au début exact de la minute.
Par exemple :
+ Un calendrier avec `rate(1 hour)` peut être établi à 14 h 00 45, 15 h 00 32, 16 h 00 18, etc.
+ Un calendrier cron défini pour `0 * * * ? *` (toutes les heures) peut fonctionner à 14 h 00 15, 15 h 00 07, 16 h 00 52, etc.
1. **Surveiller CloudWatch les métriques**
+ Utilisez la `InvocationAttemptCount` métrique pour vérifier si votre planning se déclenche.
+ Vérifiez `TargetErrorCount` si les invocations échouent.
+ Si vous avez configuré une file d'attente de lettres mortes, surveillez `InvocationsSentToDeadLetterCount` pour suivre les appels ayant échoué.
## Création de modèles de planification et d'expressions cron
Les utilisateurs rencontrent souvent des problèmes lors de la création de modèles de planification, en particulier avec les expressions cron. Voici quelques problèmes courants et la façon de les résoudre :
### Problèmes courants
+ Syntaxe cron incorrecte
+ Tentative d'utilisation de fonctionnalités cron non prises en charge
+ Confusion quant aux champs pouvant être utilisés ensemble
### Étapes de résolution des problèmes
1. **Réviser la syntaxe des expressions cron**
+ Assurez-vous que votre expression cron suit le bon [format](schedule-types.md#cron-based) :`Minutes Hours Day-of-month Month Day-of-week Year`.
+ N'oubliez pas que EventBridge Scheduler utilise le standard cron avec un champ Année supplémentaire.
1. **Comprendre les limites**
+ Vous ne pouvez pas spécifier à la fois day-of-week les champs day-of-month et comme indiqué [ici](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-scheduled-rule-pattern.html#eb-cron-expressions).
+ Les expressions cron qui entraînent des fréquences d'une rapidité supérieure à 1 minute ne sont pas prises en charge.
1. **Utiliser la fonction de prévisualisation du calendrier**
+ Lors de la création ou de la modification d'un calendrier, le EventBridge planificateur fournit un aperçu des 10 prochaines exécutions.
+ Utilisez cet aperçu pour vérifier que votre planning sera exécuté aux heures prévues.
+ Si l'aperçu ne correspond pas à vos attentes, revoyez et ajustez votre expression cron.
## Ma cible est-elle déclenchée ?
Pour vérifier si votre cible est déclenchée, procédez comme suit :
1. Vérifiez CloudWatch les métriques :
+ `InvocationAttemptCount`indique le nombre de tentatives d'invocation
+ `TargetErrorCount`indique si des invocations ont échoué
+ `TargetErrorThrottledCount`indique si votre cible est limitée
+ `InvocationDroppedCount`indique si des invocations ont été abandonnées
1. [Configurez une file d'attente de lettres mortes](configuring-schedule-dlq.md) (DLQ) pour capturer et analyser les appels ayant échoué.
## Objectifs modélisés ou objectifs universels
Si vous recevez un message d'erreur du type « Demande non valide fournie : [service] n'est pas un service pris en charge pour une cible », vous essayez peut-être d'utiliser un service non pris en charge comme modèle de cible.
Pour résoudre ce problème :
1. Vérifiez si le service que vous souhaitez est pris en charge en tant que [cible modèle](managing-targets-templated.md).
1. Si elle n'est pas prise en charge, utilisez plutôt une [cible universelle](managing-targets-universal.md) et configurez-la pour effectuer l'appel d'API approprié à votre service.
## Configurations d'entrée cible universelles non valides
Lorsque vous créez un calendrier avec une [cible universelle](managing-targets-universal.md), le EventBridge planificateur valide le format ARN cible mais ne valide pas le contenu du `Input` champ par rapport à l'API du service en aval. Cela signifie qu'un calendrier peut être créé avec succès même s'il `Input` contient des valeurs que le service cible rejettera au moment de l'appel.
Les programmes dont les configurations d'entrée cible ne sont pas valides sont déclenchés sur leur expression configurée mais échouent à chaque appel. Il se peut que vous ne découvriez pas la mauvaise configuration avant que le calendrier ne soit invoqué, ce qui peut prendre des heures ou des jours après sa création.
### Symptômes
+ Le calendrier a été créé sans erreur, mais la `TargetErrorCount` CloudWatch métrique augmente à chaque appel.
+ Les messages DLQ contiennent des codes d'erreur provenant du service cible (par exemple, `InvalidParameterValueException` ou`ValidationException`), mais non`AWS.Scheduler.InternalServerError`.
+ Le message contenu `ERROR_MESSAGE` dans le DLQ fait référence à des échecs de validation des paramètres d'entrée spécifiques.
### Exemples
Les exemples suivants montrent les configurations d'entrée non valides courantes pour une cible AWS Lambda universelle (`arn:aws:scheduler:::aws-sdk:lambda:invoke`).
**Des qualificatifs qui ne correspondent pas**
Un calendrier avec les entrées suivantes indique la version `2` dans le champ `FunctionName` et la version `1` dans le `Qualifier` champ :
```
{
"FunctionName": "MyFunction:2",
"Qualifier": "1"
}
```
Ce calendrier est créé avec succès, mais chaque appel échoue. Le message DLQ contient :
+ `ERROR_CODE`: `InvalidParameterValueException`
+ `ERROR_MESSAGE`: `The derived qualifier from the function name does not match the specified qualifier.`
**Nom de fonction non valide**
Un calendrier avec les entrées suivantes spécifie une valeur contenant uniquement des espaces blancs pour : `FunctionName`
```
{
"FunctionName": " "
}
```
Le message DLQ contient :
+ `ERROR_CODE`: `ValidationException`
+ `ERROR_MESSAGE`: une erreur de validation indiquant que le nom de la fonction ne correspond pas au modèle requis.
### Comment résoudre
1. **Configurez un DLQ.** [Configurez toujours une file d'attente de lettres mortes](configuring-schedule-dlq.md) pour les plannings utilisant des cibles universelles. Les attributs du message DLQ (`ERROR_CODE`et`ERROR_MESSAGE`) contiennent l'erreur spécifique renvoyée par le service cible, qui identifie le paramètre d'entrée non valide.
1. **Validez les paramètres d'entrée par rapport à l'API du service cible.** Avant de créer un planning, vérifiez que le JSON de votre `Input` champ contient des valeurs valides en appelant directement l'API cible. Par exemple, appelez votre AWS Lambda fonction avec les mêmes paramètres à l'aide de l' AWS Lambda `Invoke`API pour confirmer le succès de la demande.
1. **Effectuez un test selon un calendrier unique.** Créez un calendrier ponctuel pour vérifier que l'appel cible aboutit avant de configurer un calendrier récurrent.
1. **Consultez la référence de l'API du service cible.** Vérifiez la référence d'API du service que vous ciblez pour confirmer les paramètres requis, les plages de valeurs valides et les contraintes. Pour AWS Lambda `Invoke`, voir [Invoke](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) dans le *guide du AWS Lambda développeur*.
## Planifier des mises à jour déclenchant des appels inattendus
Lorsque vous modifiez un calendrier, les appels peuvent ne pas refléter immédiatement le calendrier mis à jour. Les modifications ne prennent pas effet instantanément. Par exemple, si vous mettez à jour un calendrier à une date proche de son heure de déclenchement initiale, il se peut que vous receviez un appel basé sur la configuration du calendrier d'origine.
## Désactiver ou activer les plannings ponctuels
Lors de la réactivation d'un calendrier ponctuel après l'expiration de son heure initialement prévue, le calendrier peut immédiatement invoquer sa cible. Cela peut se produire même si le planning a été désactivé avant son heure d'exécution initiale.
Par exemple :
+ Heure actuelle : 13:15 UTC
+ Programme unique créé pour : 13h30 UTC
+ Horaire désactivé avant 13h30 UTC
+ Calendrier réactivé à 14h00 UTC
+ Résultat : La cible peut être invoquée immédiatement après sa réactivation