可观测性工程_【美】夏丽蒂·梅杰斯;莉兹·方-琼斯;乔治·米兰达_AZW3_MOBI_EPUB_PDF_电子书(无页码)_【美】夏丽蒂·梅杰斯;莉兹·方-琼斯;乔治·米兰达

内容节选

第8章通过事件分析实现可观测性 在本部分的前两章中,我们了解了遥测的基础知识。这些基础知识是创建可以使用可观测性工具正确调试的数据集所必需的。虽然拥有正确的数据是一个基本要求,但可观测性却是通过从该数据中了解系统的状态来衡量的。本章将探讨应用于可观测性数据的调试技术,以及它们与传统监控技术的区别。 首先,我们将仔细研究使用传统监控和应用程序性能监控工具调试问题的常见技术。如前几章所强调的,传统方法是假定工程师对先前已知的故障模式相当熟悉。在本章中,该方法将进一步展开,以便将其与无须对故障系统十分了解的可观测性调试方法相对比。 然后,我们将研究基于可观测性的调试技术如何实现自动化,并考虑人类和计算机在创建有效的调试工作流中所扮演的角色。结合这些因素,你将了解可观测性工具如何帮助你分析遥测数据以识别传统工具无法检测到的问题。 这种由假设驱动的调试方式——形成假设,然后探索数据以确认或否认之前的假设——不仅比依赖直觉和模式匹配更科学,而且它也使调试行为大众化。与传统的调试技术相反(传统的调试技术利于那些对系统最熟悉和有经验的人快速找到答案),可观测性调试有利于那些对生产代码检查充满好奇或最勤奋的人。有了可观测性,即使对系统知之甚少的人也应该能够介入并调试问题。 8.1 从已有条件调试 在可观测性出现之前,系统和应用程序调试主要是基于你对系统的了解进行的。当查看技术团队中最高级成员进行故障排查的方式时,可以观察到这一点。当他们知道哪些问题是该问的并且本能地知道分析的正确位置时,这似乎非常神奇。这种魔力源于他们对应用程序和系统的熟悉。 为了捕捉这种魔力,经理敦促他们的高级工程师编写详细的操作手册,以试图找出并解决他们日常可能遇到的每一个可能的“根本原因”。在第2章,我们介绍了不断升级的创建仪表盘“军备竞赛”,该竞赛旨在创建正确的视图来识别新遇到的问题。但是花在创建运行手册(runbook,也叫操作手册)和仪表盘上的时间很大程度上被浪费了,因为现代系统很少会以完全相同的方式失败两次。所以,配置一个可以自动纠正故障的补救措施变得越来越迫切。 任何曾经编写或使用过运行手册的人都可以告诉你一个故事,说明它们是多么不足。也许它们的工作是为了暂时解决技术债务:有一个反复出现的问题,运行手册告诉其他工程师如何缓解该问题,直到即将到来的冲刺(sprint),问题最终得以解决。但更常见的是,尤其在分布式系统中,几乎从未发生过的一长串问题会导致生产中的级联故障。或者,五个看似不可能的条件将恰到好处地结合在一起,以可能每隔几年发生一次的方式造成大规模的服务故障。 关于运行手册 创建运行手册所花费的时间在很大程度上被浪费的断言一开始似乎有点苛刻。需要澄清的是,建立文档中心,旨在快速引导你的团队了解特定服务的需求及其初始信息。例如,每个服务都应该有包含基本信息的文档,包括哪个团队拥有和维护服务、如何联系值班工程师、升级点、此服务依赖的其他服务(反之亦然),以及指向良好查询界面或仪表盘的链接,以了解此服务的性能表现。 然而,试图维护一个包含所有可能的系统错误和解决方案的实时文档中心是徒劳而危险的。这种类型的文档很快就会过时,而错误的文档也许比没有文档更危险。在快速变化的系统中,仪表显示往往是最好的文档,因为它结合了意图(工程师命名并决定收集的维度是什么?)以及生产环境中最新的实时状态信息。 然而,工程师通常将创建运行手册视为完成故障排查的方式——因为这就是调试行为几十年来的工作方式。首先,你必须深入了解系统的所有部分——无论是通过直接接触和体验,还是通过文档,或是运行手册。然后观察你的仪表盘,最后依靠……你的直觉给出答案?或者,也许你猜测大概原因,然后开始查看仪表盘以寻找证据来确认你的猜测。 即使在探测你的应用程序以发出可观测性数据之后,你可能仍在从已知条件进行调试。例如,你可以获取任意宽度的事件流,将其通过pipeline传输到tail-f并用grep查找已知字符串,就像今天使用非结构化日志进行故障排查一样。或者,你可以获取查询结果,将它们以流式传输到一系列仪表盘进行展示,并使用指标完成故障排查。你在一个仪表盘上看到一个尖峰,然后你开始翻阅几十个其他仪表盘,在视觉上与其他类似形状匹配。 这不仅是因为你现在正在收集的事件数据使你能够调试未知条件。这是你处理探测和调试行为的方式。 在Honeycomb,我们花了很长时间才弄清楚这一点,即使我们已经构建了自己的可观测性工具。作为工程师,自然倾向于凭借对系统了解的直觉与经验去处理问题。在Honeycomb早期阶段,在我们学会如何摆脱从已知条件调试之前,可观测性帮助我们做的只是跳到要问的正确的高基数问题上。 如果我们刚发布了一个新的前端功能并且担心性能,我们会问:“它对我们的CSS和JS资产大小有多大影响?”刚刚自己编写了......

  1. 信息
  2. O'Reilly Media, Inc. 介绍
  3. 本书赞誉
  4. 推荐序一 可观测性创造繁荣技术和软件生态
  5. 推荐序二 为什么我们要了解可观测性工程
  6. 推荐序三 窥见更远:望远镜和软件可观测性
  7. 译者序
  8. 前言
  9. 第一部分 可观测性的路径
  10. 第1章 什么是可观测性
  11. 第2章 可观测性和监控之间的调试实践有何不同
  12. 第3章 不通过可观测性扩展系统的经验教训
  13. 第4章 可观测性与DevOps、SRE和云原生的关联
  14. 第二部分 可观测性基础
  15. 第5章 结构化事件
  16. 第6章 将事件拼接成链路
  17. 第7章 遵照OpenTelemetry的探针
  18. 第8章 通过事件分析实现可观测性
  19. 第9章 可观测性和监控的融合
  20. 第三部分 团队的可观测性
  21. 第10章 在团队中应用可观测性实践
  22. 第11章 可观测性驱动开发
  23. 第12章 使用SLO来提高可靠性
  24. 第13章 处理和调试基于SLO的告警
  25. 第14章 可观测性与软件供应链
  26. 第四部分 大规模可观测性
  27. 第15章 自建与购买以及投资回报率
  28. 第16章 高效的数据存储
  29. 第17章 如何使采样精准且便宜
  30. 第18章 使用流水线进行遥测管理
  31. 第五部分 传播可观测性文化
  32. 第19章 可观测性的商业案例
  33. 第20章 可观测性利益相关方和联盟
  34. 第21章 可观测性成熟度模型
  35. 第22章 未来发展趋势
  36. 关于作者
  37. 关于封面