Question

我已经设置了一个Cloudwatch规则事件，其中在完成上一个任务定义时启动了ECS任务定义。

我可以看到事件触发了任务定义，但它失败了。

此失败的唯一可见性在规则指标中，我看到指标失败的情况。

问题，是否有任何日志可以查看触发器失败的原因？

我可以通过管理控制台手动设置规则，一切正常。

当我通过云形态模板设置规则时发生错误。

我比较了两个规则，除了角色之外，两者都是相同的。但是，两个角色都具有相同的权限。

Answer 1

CloudTrail日志有所帮助。事件名称为RunTask。问题是： “ errorCode”：“ InvalidParameterException”， “ errorMessage”：“替代名为rds-task的容器不是TaskDefinition中的容器。”，

用于调试CloudWatch事件的AWS文档在这里：
https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/CWE_Troubleshooting.html

我打开了PR，以添加文档来调试CloudWatch Events中失败的ECS任务调用：
https://github.com/awsdocs/amazon-cloudwatch-events-user-guide/pull/12/files

Answer 2

这使我们困扰了很多年，主要的问题是Nathan B提到的角色问题，但令我们困扰的是预定容器在awsvpc模式下（以及扩展为Fargate）无法工作。这是一个示例CloudFormation模板：

---
AWSTemplateFormatVersion: 2010-09-09
Description: Fee Recon infrastructure

Parameters:

  ClusterArn:
    Type: String
    Description: The Arn of the ECS Cluster to run the scheduled container on

Resources:

  TaskRole:
    Type: AWS::IAM::Role
    Properties:
      Path: /
      AssumeRolePolicyDocument:
        Statement:
          - Action:
              - sts:AssumeRole
            Effect: Allow
            Principal:
              Service:
                - ecs-tasks.amazonaws.com
        Version: 2012-10-17
      Policies:
       - PolicyName: TaskPolicy
         PolicyDocument:
           Version: 2012-10-17
           Statement:
             - Effect: Allow
               Action:
                 - 'ses:SendEmail'
                 - 'ses:SendRawEmail'
               Resource: '*'

  TaskDefinition:
    Type: AWS::ECS::TaskDefinition
    Properties:
      TaskRoleArn: !Ref TaskRole
      ContainerDefinitions:
        - Name: !Sub my-container
          Essential: true
          Image: !Sub <aws-account-no>.dkr.ecr.eu-west-1.amazonaws.com/mycontainer
          Memory: 2048
          Cpu: 1024

  CloudWatchEventECSRole:
   Type: AWS::IAM::Role
   Properties:
     AssumeRolePolicyDocument:
       Version: 2012-10-17
       Statement:
         - Effect: Allow
           Principal:
             Service:
               - events.amazonaws.com
           Action:
             - sts:AssumeRole
     Path: /
     Policies:
       - PolicyName: CloudwatchEventsInvokeECSRunTask
         PolicyDocument:
           Version: 2012-10-17
           Statement:
             - Effect: Allow
               Action: 'ecs:RunTask'
               Resource: !Ref TaskDefinition

  TaskSchedule:
    Type: AWS::Events::Rule
    Properties:
      Description: Runs every 10 minutes
      Name: ScheduledTask
      ScheduleExpression: cron(0/10 * * * ? *)
      State: ENABLED
      Targets:
        - Id: ScheduledEcsTask
          RoleArn: !GetAtt CloudWatchEventECSRole.Arn
          EcsParameters:
            TaskDefinitionArn: !Ref TaskDefinition
            TaskCount: 1
          Arn: !Ref ClusterArn

注意：我已经将ClusterArn作为参数添加到脚本中，但是当然最好使用CloudFormation ImportValue语句来做到这一点。

您需要关心两个角色，第一个是任务本身的角色（TaskRole）：在此示例中，容器仅使用SES发送电子邮件，因此具有必要的权限。第二个角色（CloudWatchEventECSRole）使其全部正常工作，请注意，在其Policies数组中，原理是events.amazonaws.com，资源是模板中定义的ECS任务。 / p>

Answer 3

此问题是由于未将主要服务设置为包含events.amazonaws.com。任务无法承担这个角色。

Shame aws没有更好的记录失败的记录。

Answer 4

如果规则已成功触发，但对目标的调用失败，则应该在errorCode和errorMessage的AWS CloudTrail内部的事件历史记录中看到API调用的痕迹属性：

{
   [..]
   "errorCode": "InvalidInputException",
   "errorMessage": "Artifacts type is required",
   [..]
}

Answer 5

万一其他人来这里寻找必要的设置，以使其能够在Fargate中完成任务。除了Stefano的答案以外，还有一些其他配置。在Fargate中运行任务需要设置执行角色，因此您需要启用CloudWatchEventECSRole才能使用它。将此语句添加到该角色：

{
    "Effect": "Allow",
    "Action": "iam:PassRole",
    "Resource": [
        "arn:aws:iam::<account>:role/<executionRole>"
    ]
}

Answer 6

对于正在努力在Fargate上设置计划的任务并且正在使用Terraform设置其云的任何人，请查看此模块。 https://github.com/dxw/terraform-aws-ecs-scheduled-task

它有助于通过CloudEvents设置计划的任务，并设置正确的IAM角色。

Answer 7

我花了很长时间尝试解决此问题，当通过命令行创建ECS计划任务时，该任务已创建但从未启动。感谢您的发布，通过查看CloudTrail中的EventHistory，我发现ECS实例全部死亡，并且没有EC2实例在运行！

{
   [..]
 "errorCode": "InvalidParameterException",
 "errorMessage": "No Container Instances were found in your cluster.",
   [..]
}

Answer 8

我也没有看到我的lambda执行，但是我确实在CloudWatch Events中找到了FailedInvocations的证据（但只能通过事件规则指标链接，该链接将我带到https://console.aws.amazon.com/cloudwatch/home?region={your_aws_region}#metricsV2:graph=~();query=~'*7bAWS*2fEvents*2cRuleName*7d*2{Lambda_Physical_ID}）

我也没有在控制台中看到“触发器”，因此我退后了一步，决定使用Events属性集进行更“简单”的SAM部署，然后查看已处理的模板以确定在那种情况下是怎么做的。下面是我最终用来实现“ EventBridge”以使ScheduledEvent触发我的Lambda的东西（在我的情况下为别名，这就是我发现它的原因）。

用于计划调用的简单SAM方法

（将此属性添加到您的AWS :: Serverless :: Function）

Events:
  InvokeMyLambda:
    Type: Schedule
    Properties:
      Schedule: rate(1 minute)
      Description: Run SampleLambdaFunction once every minute.
      Enabled: True

通过查看CloudFormation中转换后的模板并将其与没有Events的版本进行比较，我能够识别出不在预期的AWS :: Events :: Rule上（这是我期望看到的lambad）），但我还看到了AWS :: Lambda :: Permission。

希望这是使所有人都能正常工作（并且不需要丢失的日志来了解原因）的必要条件：P

工作方法

MyLambdaScheduledEvent:
  Type: AWS::Events::Rule
  Properties:
    Name: MyLambdaScheduledEvent
    EventBusName: "default"
    State: ENABLED
    ScheduleExpression: rate(5 minutes) # same as cron(0/5 * * * ? *)
    Description: Run MyLambda once every 5 minutes.
    Targets:
    - Id: EventMyLambdaScheduled
      Arn: !Ref MyLambda
MyLambdaScheduledEventPermission:
  Type: AWS::Lambda::Permission
  Properties:
    Action: lambda:InvokeFunction
    Principal: events.amazonaws.com
    FunctionName: !Ref MyLambda
    SourceArn: !GetAtt MyLambdaScheduledEvent.Arn

Answer 9

对我来说 - 我的目标是一个 SQS FIFO 队列。很明显 - 在没有 FIFO 的情况下重新创建队列后，一切正常。

所以根本原因是没有启用内容重复数据删除。（当时启用队列 - 我不需要它。亚马逊 - 请帮助 EventBridge 跟踪这些失败的调用

同时 - 我向更新的文档提交了 PR https://github.com/awsdocs/amazon-cloudwatch-events-user-guide/pull/14

Cloudwatch failedinvocation错误没有可用日志

9 个答案:

用于计划调用的简单SAM方法

工作方法