View a markdown version of this page

Résolution des problèmes liés à Amazon EventBridge Scheduler - EventBridge Planificateur
Erreurs de cibleAutorisations du rôleQuotas de serviceSynchronisation du schéma et du déclenchementCréation de motifsMa cible est-elle en train d'être déclenchée ?Cibles modélisées contre cibles universellesEntrée cible universelle non validePlanifiez des mises à jour qui déclenchent des appels inattendusDésactiver ou activer les planifications ponctuelles

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.

Mon planning échoue avec des erreurs de cible

Les échecs d'invocation de Target constituent l'un des problèmes les plus courants liés à EventBridge Scheduler. Ces défaillances peuvent survenir pour plusieurs raisons :

Causes courantes :

  • Paramètres cibles manquants ou incorrects.

  • Problèmes de connectivité réseau.

  • Limitation des API.

  • Configuration de la cible incorrecte.

Étapes de résolution des problèmes

  1. Configurer une Dead-Letter file d'attente (DLQ)

    • Un DLQ vous permet de capturer et d'analyser les appels ayant échoué.

    • Les appels échoués sont envoyés au DLQ avec des messages d'erreur détaillés.

    • Pour configurer un DLQ, ajoutez-le à votre configuration de planification :

    
{
    "DeadLetterConfig": {
        "Arn": "arn:aws:sqs:region:account-id:MyDLQ"
    }
}

    Remarque : Si votre DLQ est chiffrée à l'aide d'une clé KMS, assurez-vous que la politique de clé autorise le EventBridge planificateur à l'utiliser :

    
{
    "Sid": "Allow EventBridge Scheduler to use the key",
    "Effect": "Allow",
    "Principal": {
        "Service": "scheduler.amazonaws.com"
    },
    "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
    ],
    "Resource": "*"
}

  2. 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.

  3. Vérifiez la configuration du réseau 

    
{
    "RetryPolicy": {
        "MaximumRetryAttempts": 3,
        "MaximumEventAgeInSeconds": 3600
    }
}

  4. 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 planification.

    • Vérifiez que votre service cible est pris en charge et correctement configuré.

Problèmes liés aux autorisations relatives aux rôles d'exécution du calendrier

Les problèmes d'autorisation des rôles IAM sont une cause fréquente d'échec de l'exécution du planning. Voici comment résoudre ces problèmes et les résoudre :

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

  • TargetErrorCountMétrique accrue en CloudWatch

  • Les planifications ne s'exécutent pas sans problèmes apparents dans la configuration des planifications

Étapes de résolution des problèmes

  1. Surveillez CloudWatch les métriques

    • Vérifiez la TargetErrorCount métrique dans CloudWatch.

  2. Utiliser Dead-Letter la file d'attente (DLQ) pour confirmer les problèmes d'autorisation

    • Configurez un DLQ en fonction de votre emploi du temps.

    • S'il y a des problèmes d'autorisation avec votre cible et que le DLQ est correctement configuré, les appels échoués s'afficheront dans le DLQ avec des messages d'erreur liés aux autorisations.

    • Si le DLQ reste vide malgré les échecs d'exécution affichés dans CloudWatch les métriques, cela indique probablement un problème d'autorisations empêchant EventBridge Scheduler d'écrire dans le DLQ lui-même.

    Note

    Assurez-vous que le DLQ dispose lui-même des autorisations appropriées. S'il est chiffré, assurez-vous que EventBridge Scheduler est autorisé à utiliser la clé KMS.

  3. 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"
    }]
}

  4. Vérifier les autorisations du rôle d'exécution du planning

    • Le rôle d'exécution du calendrier nécessite des autorisations spécifiques pour invoquer différents types de cibles.

    • Exemples d'autorisations à inclure dans la politique de rôle 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"
    }]
}

  5. Vérifiez l'accès chiffré aux ressources

    • Si votre cible utilise des ressources chiffrées (par exemple, des files d'attente KMS-encrypted SQS), 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"
        }
    ]
}

  6. Vérifier la configuration de l'ARN des rôles

    • Assurez-vous que le rôle ARN dans la configuration de votre planning est correct.

    • 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 pour créer des plannings ou si vous constatez des appels limités, il est possible que vous atteigniez les limites de quota de service. EventBridge Scheduler dispose de quotas pour le nombre de programmes, de groupes de calendriers et de taux d'appel, qui peuvent varier selon les régions.

Identifier les problèmes de quotas

Pour déterminer si vous atteignez les limites de quota, procédez comme suit :

  1. Surveillez CloudWatch les métriques

    • Vérifiez la InvocationThrottleCount métrique. L'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.

  2. Surveillez les messages d'erreur spécifiques

    • Lorsque vous créez ou modifiez des programmes, a LimitExceededException indique que vous avez atteint le nombre maximum de programmes ou de groupes d'horaires.

    • Les appels d'API renvoyant des erreurs de limitation indiquent que vous dépassez le quota de demandes d'API.

Résoudre les problèmes de quotas

Si vous déterminez que vous atteignez les limites de quota :

  1. Passez en revue et optimisez vos horaires actuels. Envisagez de consolider des calendriers similaires ou de supprimer ceux qui ne sont pas utilisés.

  2. Pour limiter les API, implémentez la fonction Retry with Backoff dans vos appels d'API.

  3. 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é.

Schéma de planification et problèmes de synchronisation des déclencheurs

Les utilisateurs rencontrent parfois des problèmes lorsque les planifications ne se déclenchent pas aux heures prévues. Cela peut le plus souvent être dû à des malentendus concernant les 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 créneaux horaires flexibles.

  • Mauvaise compréhension des expressions tarifaires.

É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 simultanément les champs du jour du mois et du jour de la semaine dans une expression cron.

  2. Considérations relatives au fuseau horaire

    • Sélectionnez votre fuseau horaire préféré lors de la création du calendrier.

    • Comprenez comment l'heure d'été affecte votre emploi du temps, car cet ajustement est basé sur l'UTC.

    Exemple d'impact sur l'heure d'été : si vous configurez un programme pour qu'il s'exécute à 7 h 00 GMT :

    • En hiver : l'horaire commence à 7 h 00 GMT (comme GMT = UTC)

    • Pendant l'été : l'horaire fonctionne toujours à 7 h 00 UTC, soit 6 h 00 GMT/BST

    Si vous souhaitez que le programme fonctionne à la même heure locale tout au long de l'année, assurez-vous de sélectionner le fuseau horaire approprié lors de la création du programme et de déterminer comment l'heure d'été peut affecter ce fuseau horaire.

  3. Comprendre les fenêtres horaires flexibles

    • Les fenêtres horaires flexibles permettent à EventBridge Scheduler d'optimiser les appels.

    • Le calendrier peut ne pas se déclencher exactement au début de la fenêtre.

    • Surveillez les heures d'invocation réelles pour comprendre le comportement.

  4. Taux de révision et expressions cron

    • Assurez-vous que les expressions de taux sont correctement formatées (par exemplerate(5 minutes),rate(1 hour)).

    • Pour les expressions rate et cron, sachez que les appels de planning ne sont pas limités à la 0ème seconde de minute.

    • Les horaires peuvent se déclencher dans la minute spécifiée, mais pas nécessairement au début exact de la minute.

    Par exemple :

    • Un horaire rate(1 hour) qui pourrait se dérouler à 14 h 45, 15 h 00 32 h 32, 16 h 00 18 h 18, etc.

    • Un calendrier cron défini pour 0 * * * ? * (toutes les heures) peut s'exécuter à 14h00h15, 15h00h07, 16h00h52, etc.

  5. Surveillez CloudWatch les métriques

    • Utilisez cette InvocationAttemptCount métrique pour vérifier si votre planning est déclencheur.

    • Vérifiez TargetErrorCount si les appels échouent.

    • Si vous avez configuré une Dead-Letter file d'attente, 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 manière 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 qui peuvent ê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 respecte le format correct  :Minutes Hours Day-of-month Month Day-of-week Year.

    • N'oubliez pas que EventBridge Scheduler utilise la norme cron avec un champ Année supplémentaire.

  2. Comprenez les limites

  3. Utilisez la fonction de prévisualisation du calendrier

    • Lors de la création ou de la modification d'un calendrier, EventBridge Scheduler fournit un aperçu des 10 prochaines heures d'exécution.

    • 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, vérifiez et ajustez votre expression cron.

Ma cible est-elle en train d'être déclenchée ?

Pour vérifier si votre cible est en train d'être déclenchée :

  1. Vérifiez CloudWatch les statistiques :

    • InvocationAttemptCountaffiche le nombre de tentatives d'invocation

    • TargetErrorCountindique si l'une des invocations a échoué

    • TargetErrorThrottledCountindique si votre cible est limitée

    • InvocationDroppedCountindique si des invocations ont été supprimées

  2. Configurez une Dead-Letter file d'attente (DLQ) pour capturer et analyser toutes les invocations ayant échoué.

Cibles modélisées contre cibles universelles

Si vous recevez un message d'erreur du type « Demande fournie non valide : [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 cible modèle.

Pour résoudre ce problème :

  1. Vérifiez si le service que vous souhaitez est pris en charge en tant que cible Utilisation de cibles modélisées dans EventBridge le planificateur modélisée.

  2. Si elle n'est pas prise en charge, utilisez plutôt une cible universelle 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, EventBridge Scheduler 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 planifications dont les configurations d'entrée cible ne sont pas valides sont déclenchées 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 ouValidationException), mais pasAWS.Scheduler.InternalServerError.

  • Le ERROR_MESSAGE message DLQ fait référence à des échecs spécifiques de validation des paramètres d'entrée.

Exemples

Les exemples suivants montrent des configurations d'entrée non valides courantes pour une cible AWS Lambda universelle (arn:aws:scheduler:::aws-sdk:lambda:invoke).

Qualifications non concordantes

Un calendrier avec l'entrée suivante spécifie la version 2 dans le champ FunctionName et la version 1 dans le Qualifier champ :

{
    "FunctionName": "MyFunction:2",
    "Qualifier": "1"
}

Ce planning 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 l'entrée suivante spécifie une valeur contenant uniquement des espaces pour : FunctionName

{
    "FunctionName": "     "
}

Le message DLQ contient :

  • ERROR_CODE: ValidationException

  • ERROR_MESSAGE: 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 pour les planifications qui utilisent des cibles universelles. Les attributs du message DLQ (ERROR_CODEetERROR_MESSAGE) contiennent l'erreur spécifique renvoyée par le service cible, qui identifie le paramètre d'entrée non valide.

  2. Validez les paramètres d'entrée par rapport à l'API du service cible. Avant de créer un calendrier, 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 InvokeAPI pour confirmer la réussite de la demande.

  3. Testez avec un calendrier unique. Créez un calendrier ponctuel pour vérifier que l'appel cible est réussi avant de configurer un calendrier récurrent.

  4. Consultez la référence de l'API du service cible. Vérifiez la référence de l'API du service que vous ciblez pour confirmer les paramètres requis, les plages de valeurs valides et les contraintes. Pour AWS Lambda Invoke, consultez Invoke dans le Guide du AWS Lambda développeur.

Planifiez des mises à jour qui déclenchent 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, vous pouvez voir une invocation basée sur la configuration du calendrier d'origine.

Désactiver ou activer les planifications ponctuelles

Lors de la réactivation d'un programme ponctuel après l'expiration de l'heure initialement prévue, le calendrier peut immédiatement invoquer sa cible. Cela peut se produire même si le calendrier a été désactivé avant son heure d'exécution initiale.

Par exemple :

  • Heure actuelle : 13:15 UTC

  • One-time création du planning pour : 13:30 UTC

  • Horaire désactivé avant 13h30 UTC

  • Horaire réactivé à 14h00 UTC

  • Résultat : La cible peut être invoquée immédiatement après la réactivation