充分利用事件遥测，掌握状态变化，助你定位及解决问题。
译自 Why Events Are the Critical Telemetry Type You’re Missing，作者 Rachel Dines。
去年，云原生公司的一群高级可观测性领导人开会时，我要求每个人告诉我他们最不喜欢的遥测类型：指标、事件、日志、跟踪或其他。我非常确信主要的答案会是日志。没什么反对日志，但我最近听到这个组表达的热门观点是“事件期间，如果查看了日志，就已经失败了”。
令我惊讶的是，他们几乎一致地回答：事件。事件是最不受欢迎的遥测类型。我后续询问，你为什么这么不喜欢事件？答案再次几乎一致:对事件的定义不足，不清楚如何使用。
在研究事件时，我发现有四五个不同的定义，而且似乎没有人确定将事件用于故障排除工作流的最佳方式。
自那次会议以来，我们团队花了很多时间思考事件，研究如何使事件成为一流的遥测类型。团队进行了广泛研究，着手构建跟踪变更事件的功能。就在最近，我们宣布了在可观测性平台中接收事件的能力。
我想退后一步，探讨为什么事件如此重要，以及事件如何提供帮助。
变更是错误的主要原因。在稳定状态下，系统应当能够在不确定的时间段内持续、一致地运行。然而，在现代 DevOps 环境中，我们的系统每天要进行几十次变更。我们部署新代码，打开和关闭功能标志，部署新基础设施，横向扩展和缩减规模，我们甚至变更可观测性解决方案。业务也不会静止；它会根据时间、周几、季节、世界事件、竞争等成百上千个我们无法跟踪的因素而不断变化。
跟上变更的唯一方法是上下文关联系统，当收到警报时，可以快速查看同一时间范围内可能引入中断性变更的相关事件。这就是我们所说的事件。
事件是对系统、工作负载或可观测性平台的一次离散变更。下面是一些事件示例以及事件如何帮助排查问题:
- 系统变更：这些是大多数人在谈到事件时想到的变更类型。示例可能是自动扩缩操作、配置变更或功能标志。这些变更可以通过深入相关的CI/CD、功能标志或基础设施管理工具来找到，但这需要宝贵的时间。
- 工作负载变更：这是组织最常见的盲区。示例可能是接入新客户或商业促销事件。使用这些事件为其他遥测数据建立上下文，可以减少不必要的调查和交流(时间)，当团队试图确定遥测数据为何会突然变化时。
- 可观测性平台变更：这些事件可能是警报触发或被静音。它也可能是一个新的数据汇总规则生效，导致数据形状发生变更。
与可观测性信号一样，事件不能单独存在。事件在故障排除工作流中与指标、跟踪和日志发挥重要作用。指标可以告知问题的症状，是平均故障检测时间的关键；而事件可以快速告知变更的内容。在跟踪的帮助下可以找到问题的位置，事件可以帮助修复并停止客户痛点。之后，可以通过日志开始了解问题的原因，以便找到根本原因并解决基本问题。
我们将这个工作流称为可观测性的三个阶段：知晓问题，分类并理解问题，同时尽快实施修复。
我最初把这篇文章称为“为事件辩护”，希望现在您了解为什么，并愿意给事件一个机会。事件互补并增强其他遥测类型，能够更快地将关键上下文纳入警报。