我已经设置了一个 Cloudwatch 规则事件，其中一个 ECS 任务定义在之前的任务定义完成时启动。
我可以看到该事件触发了任务定义，但是它失败了。
此失败的唯一可见性是在规则指标中，我在其中看到了指标 failedinnvocations。
问题，是否有任何日志可以查看触发器失败的原因？
我可以通过管理控制台手动设置规则，一切正常。
当我通过 cloudformation 模板设置规则时出现错误。
我比较了这两个规则，除了角色之外，两者都是相同的。但是，这两个角色具有相同的权限。
【问题讨论】：
标签： amazon-web-services amazon-ec2 amazon-cloudformation amazon-cloudwatch amazon-ecs
如果规则已成功触发，但对目标的调用失败，您应该在 AWS CloudTrail 内的事件历史记录中看到 API 调用的跟踪，查看 errorCode 和 errorMessage 属性：
{
[..]
"errorCode": "InvalidInputException",
"errorMessage": "Artifacts type is required",
[..]
}
【讨论】：
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
【讨论】：
这困扰了我们很久，主要问题是 Nathan B 提到的角色问题 但让我们感到困惑的其他事情是计划容器在 awsvpc 模式下无法工作（以及扩展 Fargate） s>。这是一个示例 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
SecurityGroup:
Type: String
Description: The security group the task will use
Subnet0:
Type: String
Description: A subnet that the task will run in
Subnet1:
Type: String
Description: A subnet that the task will run in
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
NetworkConfiguration:
AwsVpcConfiguration:
SecurityGroups:
- !Ref SecurityGroup
Subnets:
- !Ref PrivateSubnet0
- !Ref PrivateSubnet1
Arn: !Ref ClusterArn
注意：我已将 ClusterArn 作为参数添加到脚本以及您希望任务在其中运行的安全组和子网中。
您需要关心两个角色，第一个是任务本身的角色 (TaskRole)：在此示例中，容器仅使用 SES 发送电子邮件，因此它具有必要的权限。第二个角色 (CloudWatchEventECSRole) 是让一切正常工作的角色，注意在其 Policies 数组中，原则是 events.amazonaws.com，资源是模板中定义的 ECS 任务。
【讨论】：
awsvpc模式，但您需要明确指定网络策略（mismo.team/…）
此问题是由于未将主要服务设置为包括 events.amazonaws.com。该任务无法承担该角色。
Shame aws 没有更好的失败调用日志记录。
【讨论】：
以防其他人来这里寻找必要的设置以使这项工作在 Fargate 中完成任务。除了 Stefano 的回答之外，还有一些额外的配置。 在 Fargate 中运行任务需要设置执行角色，因此您需要启用 CloudWatchEventECSRole 才能使用它。将此语句添加到该角色：
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": [
"arn:aws:iam::<account>:role/<executionRole>"
]
}
【讨论】：
iam:PassRole。它使用"StringLike": { "iam:PassedToService": "ecs-tasks.amazonaws.com" } 而不是命名资源。
我也没有看到我的 lambda 正在执行，但我确实在 CloudWatch Events 中找到了 FailedInvocations 的证据（但只能通过 Event Rule Metrics 链接，该链接将我带到 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（在我的例子中是别名，这就是我发现这个的原因）。
（将此属性添加到您的 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
【讨论】：
对于在 Fargate 上设置计划任务并使用 Terraform 设置云的人来说，请查看此模块。 https://github.com/dxw/terraform-aws-ecs-scheduled-task
它有助于通过 CloudEvents 设置计划任务并设置正确的 IAM 角色。
【讨论】：
我花了很长时间尝试解决此问题，当通过命令行创建 ECS 计划任务时，该任务已创建但从未启动。 感谢这篇文章，我通过查看 CloudTrail 中的 EventHistory 发现 ECS 实例已全部死亡，并且没有 EC2 实例在运行！
{
[..]
"errorCode": "InvalidParameterException",
"errorMessage": "No Container Instances were found in your cluster.",
[..]
}
【讨论】：
对我来说——我的目标是一个 SQS FIFO 队列。它变得很明显 - 在没有 FIFO 的情况下重新创建队列之后一切正常。
所以根本原因是没有启用内容重复数据删除。 （在启用队列时 - 我不需要它。亚马逊 - 请帮助 EventBridge 跟踪这些失败的调用
同时 - 我向更新的文档提交了 PR https://github.com/awsdocs/amazon-cloudwatch-events-user-guide/pull/14
【讨论】：