2

我有一个关于 AWS CloudWatch Logs 的有趣场景。我目前使用 log4net 并使用 CloudWatch Logs 代理将所有日志泵入 CloudWatch Logs。我在 CloudWatch 中有一个指标，它基本上会扫描 [ERROR] 条目，并且警报会在它们发生时将它们传递给另一个服务以获取开发通知（阈值 >= 1，周期 - 1 分钟）。所有这一切都很好。

现在我想以不同的方式处理某些错误。例如，基于异常类型，我只想在 N 分钟内发生 X 次事件时触发警报。所以在这种情况下，我会为此条件创建一个指标，然后将其分配给警报。问题是一般错误度量，在本问题的第一部分中解释，仍在跟踪每个单独的错误发生。所以现在我收到了多个通知。每个错误一个，出现 X 次后一个。

我可以禁用一般错误指标，但我会失去跟踪未处理异常的能力。对于每一个可能的异常，我都必须有一个指标。我错过了什么吗？处理这个问题的最佳方法是什么？

4

1 回答 1

2

您通常可以通过创建一个函数来处理这个问题，以便在您收到通知之前进行一些额外的处理。执行此操作的最简单方法是将 AWS Lambda 函数订阅到您的未处理错误警报的 SNS 主题。取消订阅主题，只有在您定义的任何条件都通过后，才让 lambda 函数通知您而不是 SNS。

对于这种情况，当您的聚合指标处于警报状态时，您可能希望抑制来自您的单个指标的通知，以发现与您的聚合指标匹配的未处理错误。

伪代码：

  • 使用DescribeAlarms API 获取聚合未处理异常警报的状态。如果聚合警报处于“警报”状态，请继续。
  • 使用FilterLogEvents API 获取日志事件匹配：
    • 您的日志组
    • 您的日志流
    • FilterPattern：您的个人未处理异常警报的指标过滤器
    • StartTime：报警时间戳 - 周期
    • EndTime：报警时间戳
  • 使用GetLogEvents API 获取所有匹配的日志事件：
    • 您的日志组
    • 您的日志流
    • StartTime：报警时间戳 - 周期
    • EndTime：报警时间戳
  • 如果“所有事件”计数和“过滤事件”计数匹配，并且聚合警报处于警报状态，则不要发送通知。否则，使用 SES 或 SNS API 向自己发送通知。

如果您想继续通过 SNS 收到通知，请不要重复使用警报用于触发 lambda 的同一主题——为您的移动/短信通知创建一个单独的主题。

我不确定这是否比 log4net 更容易，但如果您打算对日志进行这种后处理，最好直接将未处理的异常发送到 SNS，先在 lambda 中进行后处理，然后然后从您的 lambda 函数写入 cloudwatch 日志。此更改将允许您通过 SNS 消息有效负载检查未处理的异常，并让您对如何抑制重叠关注点进行一些额外的控制。

于 2016-12-06T19:33:14.550 回答