Résolution des problèmes liés à Amazon EventBridge Scheduler - EventBridge Planificateur
Erreurs ciblesAutorisations du rôleQuotas de serviceSchéma et chronométrage du déclenchementCréation de motifsMa cible est-elle déclenchée ?Objectifs modélisés ou objectifs universelsEntrée cible universelle non validePlanifier des mises à jour déclenchant des appels inattendusDésactiver ou activer les plannings ponctuels

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 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, 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": "*"
}

  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

    • Si les appels échouent en raison de problèmes réseau transitoires, implémentez une logique de nouvelle tentative.

    • Exemple de politique de nouvelle tentative :

    
{
    "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 calendrier.

    • Vérifiez que votre service cible est pris en charge 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

  • TargetErrorCountMé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.

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

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

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

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

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

  2. Pour la régulation des API, implémentez une nouvelle tentative avec interruption 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é.

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.

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

  3. Comprendre les fenêtres horaires flexibles

    • Les fenêtres temporelles flexibles 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.

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

  5. 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 :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.

  2. Comprendre les limites

    • Vous ne pouvez pas spécifier à la fois day-of-week les champs day-of-month et comme indiqué ici.

    • Les expressions cron qui entraînent des fréquences d'une rapidité supérieure à 1 minute ne sont pas prises en charge.

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

    • InvocationAttemptCountindique le nombre de tentatives d'invocation

    • TargetErrorCountindique si des invocations ont échoué

    • TargetErrorThrottledCountindique si votre cible est limitée

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

  2. Configurez une file d'attente de lettres mortes (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.

  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, 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 ouValidationException), mais nonAWS.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 pour les plannings utilisant 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 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 InvokeAPI pour confirmer le succès de la demande.

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

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