除了传统的应用程序日志记录（例如 Elasticsearch）之外，组织可能还拥有警报系统”哨兵“它接收应用程序通过 HTTP 发送的日志消息/异常事件，并通知开发人员潜在的问题。
假设 Sentry 现在不仅包含“可操作”事件（例如，连接到数据库时出错。Devops 应该进行调查），而且还被大量“不可操作”事件所污染（例如，无法处理用户输入 - 期望用户再次尝试，而 DevOps 无需执行任何操作）。
有哪些选项可以把一个充满好坏事件数据的系统转变为一个只有好数据的干净系统，从而使警报再次变得有意义并且不会被忽略？
示例：1）逐步处理每个事件，从最容易实现的/最常见的事件开始，决定它是否可行。2）创建一个新系统并逐步将可操作的事件转移到其中。
答案1
每条警报都必须要求采取明智的行动。无需采取行动的警报必然会导致警报疲劳，并最终导致错过真正的问题。真正的问题会导致有关服务降级的状态报告，或软件开发人员的未决问题。
从嘈杂的系统创建合理的更改是一项艰巨的工作。积压的工作很可能无法快速完成。
考虑宣布警报破产并删除所有警报。重新添加最基本的必需品，例如 API 服务器上的错误率和用户响应时间的中位数。请参阅Google SRE 书中的四个黄金信号。
接下来，对意外事件和未遂事件进行根本原因分析。如果您有预测问题的数据，请添加警报。当根本原因得到解决并且警报长时间未触发时，安排警报被移除。
答案2
如果您的事件数据有分类级别，则可以从高严重性到低严重性进行分类。通常，最高严重性的输出应该少得多（例如致命的），但希望更重要。
然后，您可以开始逐步降低严重程度，并在达到收益减少时停止。
如果事件组数量巨大，则另一种选择是根据从日志中获取的时间序列指标发出警报。