亚马逊AWS官方博客

利用新推出的 Amazon EventBridge 日志记录功能来监控和调试事件驱动型应用程序

从现在起，您可以在 Amazon EventBridge 中使用增强的日志记录功能，以便通过全面的日志来监控您的事件驱动型应用程序并对其进行调试。新推出的这些增强功能有助于改善您监控事件流和排查事件流问题的方式。

您可以通过如下方式在 Amazon EventBridge 控制台上找到这项新功能：

新推出的可观测性功能可提供全面的事件生命周期跟踪，以便应对微服务和事件驱动型架构监控方面的挑战。现在，每当发布不符合规则的匹配事件、向订阅者进行交付或者遇到失败并重试时，EventBridge 都会生成详细的日志条目。

借助有关成功、失败和状态代码的详细信息，您可以了解整个事件历程，从而直截了当地识别和诊断问题。使用详细的事件生命周期跟踪功能和内置的查询工具，现在只需几分钟即可完成以往需要花费数小时时间的试错调试。

使用增强的 Amazon EventBridge 可观测性

我来向您展示一下 Amazon EventBridge 中的日志记录功能。

我可以在现有的事件总线中或创建新的自定义事件总线时启用日志记录功能。首先，我要导航到 EventBridge 控制台，然后在左侧导航窗格中选择事件总线。在自定义事件总线中，我要选择创建事件总线。

我可以在日志部分中看到这项新功能。我可以使用三个选项来配置日志目的地：Amazon CloudWatch Logs、Amazon Data Firehose 和 Amazon Simple Storage Service（Amazon S3）。如果打算将日志流式传输到数据湖，我可以选择 Amazon Kinesis Data Firehose Stream。如果为事件总线提供了客户托管的密钥（CMK），系统将使用 TLS 对日志进行传输中加密。CloudWatch Logs 支持客户托管的密钥，而 Data Firehose 为下游目的地提供了服务器端加密。

对于此演示，我要选择 CloudWatch 日志和 S3 日志。

我还可以从“错误”、“信息”或“跟踪”中选择日志级别。我要选择跟踪，然后选择包括执行数据，因为我需要查看有效负载。您需要注意，因为记录的有效载荷数据可能包含敏感信息，此设置将应用于您选择的所有日志目的地。接下来，我要配置两个目的地，一个用于 CloudWatch 日志组，另一个用于 S3 日志。随后，我要选择创建。

启用日志记录功能之后，我可以开始发布测试事件，以便观察日志记录功能的行为。

在第一个场景中，我构建了一个 AWS Lambda 函数，然后将这个 Lambda 函数配置为目标。

通过选择发送事件，我要导航到我的事件总线，以便发送一个示例事件。

下面是我使用的有效载荷：

{
  "Source": "ecommerce.orders",
  "DetailType": "Order Placed",
  "Detail": {
    "orderId": "12345",
    "customerId": "cust-789",
    "amount": 99.99,
    "items": [
      {
        "productId": "prod-456",
        "quantity": 2,
        "price": 49.99
      }
    ]
  }
}

发送这个示例事件之后，我可以看到我的 S3 存储桶中提供了日志。

我还可以查看 Amazon CloudWatch 日志中显示的日志条目。日志会显示从 EVENT_RECEIPT 到 SUCCESS 的事件生命周期。要了解有关完整事件生命周期的更多信息，请访问 TBD:DOC_PAGE。

现在，我们要评估这些日志。为简洁起见，我只包含了几条日志，为了便于阅读，我对它们进行了编辑。下面是我触发此事件时的日志：

{
    "resource_arn": "arn:aws:events:us-east-1:123:event-bus/demo-logging",
    "message_timestamp_ms": 1751608776896,
    "event_bus_name": "demo-logging",
// 为简洁起见，已编辑 //
    "message_type": "EVENT_RECEIPT",
    "log_level": "TRACE",
    "details": {
        "caller_account_id": "123",
        "source_time_ms": 1751608775000,
        "source": "ecommerce.orders",
        "detail_type": "Order Placed",
        "resources": [],
        "event_detail": "为简洁起见，已编辑"
    }
}

下面是成功调用此事件时的日志：

{
    "resource_arn": "arn:aws:events:us-east-1:123:event-bus/demo-logging",
    "message_timestamp_ms": 1751608777091,
    "event_bus_name": "demo-logging",
// 为简洁起见，已编辑 //
    "message_type": "INVOCATION_SUCCESS",
    "log_level": "INFO",
    "details": {
// 为简洁起见，已编辑 //
        "total_attempts": 1,
        "final_invocation_status": "SUCCESS",
        "ingestion_to_start_latency_ms": 105,
        "ingestion_to_complete_latency_ms": 183,
        "ingestion_to_success_latency_ms": 183,
        "target_duration_ms": 53,
        "target_response_body": "<为简洁起见，已编辑>",
        "http_status_code": 202
    }
}

其他日志条目包含丰富的元数据，有助于直截了当地排查问题。例如，在一个成功的事件中，我可以查看从事件开始到结束的延迟时间、目标完成处理的持续时间以及 HTTP 状态代码。

通过完整的事件生命周期跟踪功能对失败进行调试

当出现问题时，EventBridge 日志记录功能的优势会体现得淋漓尽致。为了测试失败场景，我要故意错误地配置 Lambda 函数的权限，并更改规则以使其指向另一个没有适当权限的 Lambda 函数。

由于缺少权限，尝试失败并产生了一个永久性错误。日志表明这是一个 FIRST 尝试，并导致了 NO_PERMISSIONS 状态。

{
    "message_type": "INVOCATION_ATTEMPT_PERMANENT_FAILURE",
    "log_level": "ERROR",
    "details": {
        "rule_arn": "arn:aws:events:us-east-1:123:rule/demo-logging/demo-order-placed",
        "role_arn": "arn:aws:iam::123:role/service-role/Amazon_EventBridge_Invoke_Lambda_123",
        "target_arn": "arn:aws:lambda:us-east-1:123:function:demo-evb-fail",
        "attempt_type": "FIRST",
        "attempt_count": 1,
        "invocation_status": "NO_PERMISSIONS",
        "target_duration_ms": 25,
        "target_response_body"："{\"requestId\":\"a4bdfdc9-4806-4f3e-9961-31559cb2db62\",\"errorCode\":\"AccessDeniedException\",\"errorType\":\"Client\",\"errorMessage\":\"用户 arn:aws:sts::123:assumed-role/Amazon_EventBridge_Invoke_Lambda_123/db4bff0a7e8539c4b12579ae111a3b0b 无权对资源 arn:aws:lambda:us-east-1:123:function:demo-evb-fail 执行 lambda:InvokeFunction，因为没有任何基于身份的策略允许执行 lambda:InvokeFunction 操作\",\"statusCode\":403}",
        "http_status_code": 403
    }
}

最后一个日志条目利用计时指标和确切的错误消息对整个失败进行了总结。

{
    "message_type": "INVOCATION_FAILURE",
    "log_level": "ERROR",
    "details": {
        "rule_arn": "arn:aws:events:us-east-1:123:rule/demo-logging/demo-order-placed",
        "role_arn": "arn:aws:iam::123:role/service-role/Amazon_EventBridge_Invoke_Lambda_123",
        "target_arn": "arn:aws:lambda:us-east-1:123:function:demo-evb-fail",
        "total_attempts": 1,
        "final_invocation_status": "NO_PERMISSIONS",
        "ingestion_to_start_latency_ms": 62,
        "ingestion_to_complete_latency_ms": 114,
        "target_duration_ms": 25,
        "http_status_code": 403
    },
    "error": {
        "http_status_code": 403,
        "error_message"："用户 arn:aws:sts::123:assumed-role/Amazon_EventBridge_Invoke_Lambda_123/db4bff0a7e8539c4b12579ae111a3b0b 无权对资源 arn:aws:lambda:us-east-1:123:function:demo-evb-fail 执行 lambda:InvokeFunction，因为没有任何基于身份的策略允许执行 lambda:InvokeFunction 操作",
        "aws_service": "AWSLambda",
        "request_id": "a4bdfdc9-4806-4f3e-9961-31559cb2db62"
    }
}

这些日志提供了详细的性能指标，可以帮助识别瓶颈。ingestion_to_start_latency_ms: 62 显示了从事件摄取到开始调用的时间，而 ingestion_to_complete_latency_ms: 114 表示从摄取到完成的总计时间。此外，target_duration_ms: 25 表示目标服务做出响应时花费的时间，可以帮助区分 EventBridge 处理时间与目标服务性能。

错误消息清晰地说明了失败的内容、lambda:InvokeFunction 操作、失败的原因（没有任何基于身份的策略允许执行此操作）、涉及的角色（Amazon_EventBridge_Invoke_Lambda_1428392416）以及受到影响的特定资源，Lambda 函数 Amazon 资源名称（ARN）指出了这一点。

使用 EventBridge 日志记录功能调试 API 目的地

我认为能够让 EventBridge 日志记录功能大显身手的一个特殊使用案例是调试 API 目的地的问题。EventBridge API 目的地是一些 HTTPS 端点，您可以将它们作为事件总线规则或管道的目标进行调用。HTTPS 端点可以帮助您利用 HTTPS 调用将事件从事件总线路由到外部系统、软件即服务（SaaS）应用程序或第三方 API。它们使用连接来处理身份验证和凭证，这样就可以轻松将您的事件驱动型架构与任何基于 HTTPS 的服务集成。

API 目的地通常用于向外部 HTTPS 端点发送事件，因此从外部端点对失败进行调试可能是一项挑战。这些问题通常起源于端点身份验证要求发生变化或者凭证被修改。

为了演示这项调试功能，我故意在连接资源中使用不正确的凭证配置了 API 目的地。

当我向这个配置错误的端点发送事件时，增强的日志记录功能会显示此次失败的根本原因。

{
    "resource_arn": "arn:aws:events:us-east-1:123:event-bus/demo-logging",
    "message_timestamp_ms": 1750344097251,
    "event_bus_name": "demo-logging",
    //为简洁起见，已编辑//,
    "message_type": "INVOCATION_FAILURE",
    "log_level": "ERROR",
    "details": {
        //为简洁起见，已编辑//,
        "total_attempts": 1,
        "final_invocation_status": "SDK_CLIENT_ERROR",
        "ingestion_to_start_latency_ms": 135,
        "ingestion_to_complete_latency_ms": 549,
        "target_duration_ms": 327,
        "target_response_body": "",
        "http_status_code": 400
    },
    "error": {
        "http_status_code": 400,
        "error_message": "Unable to invoke ApiDestination endpoint: The request failed because the credentials included for the connection are not authorized for the API destination."
    }
}

日志立即清晰地说明了此次失败。target_arn 表明这涉及一个 API 目的地，final_invocation_status 表明发生了 SDK_CLIENT_ERROR，http_status_code 为 400，表示发生了客户端问题。最重要的是，error_message 明确指出：无法调用 ApiDestination 端点：请求失败，因为连接中包含的凭证未经授权，无法用于 API 目的地。

这个完整的日志序列提供了有用的调试见解，因为我可以确切地了解事件是如何经过 EventBridge 的 – 从事件接收到摄取，再到规则匹配，再到尝试调用。这样的详细程度消除了猜测，并且直接指明了问题的根本原因。

需要了解的其他事项

请注意以下几点：

  • 架构支持 – 日志记录功能适用于所有 EventBridge 功能，包括自定义事件总线、合作伙伴事件来源以及 HTTPS 端点的 API 目的地。
  • 对性能的影响 – 日志记录功能以异步方式运行，不会对事件处理延迟或吞吐量产生显著的影响。
  • 定价 – 对于日志存储和交付，您需要支付标准的 Amazon S3、Amazon CloudWatch Logs 或 Amazon Data Firehose 费用。EventBridge 日志记录功能本身不会产生额外费用。有关详情，请访问 Amazon EventBridge 定价页面。
  • 发布情况 – Amazon EventBridge 日志记录功能已在支持 EventBridge 的所有 AWS 区域推出。
  • 文档 – 有关更多详情，请参阅 Amazon EventBridge 监控和调试文档。

访问 EventBridge 控制台并为事件总线启用日志记录功能，以便开始使用 Amazon EventBridge 日志记录功能。

祝您构建顺利！
– Donnie

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您了解行业前沿技术和发展海外业务选择推介该服务。