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