可观测性之两大误区

（把可观测性进行到底！）



有一天，我和一位读者刚开始对可观测性中日记数据的价值看法差别，但通过一阵子辩说（或者说来回争论）之后，我们最终告竣了共识，得到3个观点或结论：

• 在可观测性策略中忽略日记数据是一个巨大的错误步骤
  
• 有很多高级用户只使用日记和度量来观测
  
• 可观测性是一系列的实践，虽然我们不可能立刻就能做到完善。
  

我的可观测性之旅始于2021年，当时我发现本身正在管理一个可观测性实践团队，并试图为所在的公司设计一个可观测性策略。这意味着，随着我对这个问题域不绝地深入学习和发掘，我的理解也在不绝地发展。比方，今天看待可观测性相干的事情，其实会面临一个巨大的范式变化。和全部的范式变化一样，要改变我们看待问题的方式并不容易。


在讨论具体内容之前，先解释一下几个关键的术语：

• 日记告诉我们某一特定时间点的情况。它们没有一个标准化的格式，因此很难查询。
  
• 跨度（Span）代表一个工作或操作单位。它通过相干的布局化日记信息（跨度事件）和属性（如客户端ID、API端点、IP地址）等上下文信息，描绘了在执行该操作期间所发生的情况。比方，一个跨度捕获了当客户向购物车添加一个商品时发生的全部事情。
  
• 跟踪（trace）将全部相干的跨度（如树状）连接起来，向我们展示大局。
  
• 度量指标（Metrics）是一段时间内有关基础设施或应用程序的数据汇总。比方：系统错误率、CPU使用率、特定服务的请求率。
  
• 遥测（Telemetry） 从一个系统发出的关于其举动的信号。这些信号可以跟踪、度量和日记的形式出现。
  
• SLI，即服务水平指标，是一个正在度量的东西。尽管SLI是根据一个指标创建的，但该指标是由跟踪数据的汇总而来。一个SLI的例子：成功的HTTP请求数/HTTP请求总数（成功率）。
  
  
• SLO，即服务水平目标，是我们如何通过将SLI与业务价值联系起来，向组织或团队的其他人传达可靠性。
  

误区一：日记已经充足好了
日记重要吗？是的。如果没有日记，你就无法得到数据来调试基础设施的问题或应用服务器的问题。但是，它们是一堵文本墙，我们必须对其进行分析，以便有一丝机遇我们能拼凑出代码中的问题。这样做，很难受。所以我想说的是" 如果我们把日记放在一个跨度（Span）里，日记会更有用。"因为跨度能提供事件的配景（上下文），而上下文很重要，从而通过Trace，犹如胶水，可以将Span缝合在一起报告完整的故事。在微服务领域，你不是在处理一个大的服务（即一个单体），而是在处理大量的微型服务，这些服务之间相互作用，举动怪异，甚至有时是不可预知的。日记如何帮助解决这个问题？想象一下，像下面这样的日记，你能搞清楚它们的含义吗？

即使我们有布局化的日记，并且使用了专门对日记信息进行切片和切块的工具（如ElasticSearch），我们仍然会错过大局（整体情况）：

• 涉及哪些服务？
  
• 它们以什么顺序被调用？
  
• 哪些事件联系在一起？
  

如果没有这些信息在手，就很难进行故障排除。在以前的一家公司，开发团队试图调试（debug）产品线上故障时，遇到的困难最大。为什么？因为在很大程度上他们依赖日记进行调试。有那么多的日记、有那么多的数据，但他们甚至不知道从哪里开始找。当然，我们能寻找到日记级别的ERROR，但是：

• 在什么情况下出错的？
  
• 它是哪个事件的一部分？
  
• 什么服务调用了抛出错误信息的服务？
  

现在，如果我们用Traces来代替呢？思量一下这个非常精简的Trace样本。

我们立刻就有了这么多信息。下面就是可以网络到的一些信息：

• 我们的跟踪（也是根跨度）叫做Hello
  
• 它有两个子节点：Hello-Greetings和Hello-Salutations。我们知道这一点是因为它们有相同的parent_id，对应于Hello Span的span_id；
  
• 它们都是同一个跟踪的一部分。我们知道这一点，是因为它们有相同的trace_id。
  
• 我们得到了一些关于Span的有用信息，这些信息被存储为attributes。
  
• 我们甚至还有一些日记信息，以events的形式存储，为我们提供一些额外的信息。
  

把这些信息发送到可观测性（Observability）的后端，我们就可以认认真真、快速地完成故障排除了!



误区二：度量指标总是有用的
度量指标是有用的，是可以给我们提供关于CPU水平和完成一个事件所需时间的信息。但是，正如我们在日记中看到的，没有上下文的度量指标不会给我们带来可观测性。甚至有人写道："在可观察性的世界里，我们正在处理未知的未知数，因此我们不知道会度量什么指标。这意味着......再见, 度量！"那怎样可以带来可观测性？将度量指标与跟踪联系起来。在某些情况下，我们可以从跟踪 中推导出度量指标，如可以从跟踪中得出一个服务的响应时间指标。但有时不能这样做，如不能从跟踪中得出虚拟机（VM）的相干指标——CPU和内存使用率。但是，我们可以通过一个链接属性将它们（度量指标）与跟踪关联起来。比方，如果我们把IP地址作为一个跨度属性来捕获，那么具有给定IP地址的虚拟机就可以与跟踪相干联。说到度量指标，要警惕度量指标仪表板（dashboard）的毛病。众所周知，许多公司喜欢在办公室的巨大显示屏上骄傲地展示仪表板，作为很花哨的指挥中心的一部分。有些IT公司喜欢用仪表盘来观察CPU使用率、磁盘使用率、内存使用率、每小时事件数量等。这很好，但谁愿意整天盯着仪表盘、等待故障的发生？这些是可操作的吗？这个仪表盘上到底有什么？上面那些指标项相干吗？当初设计和创建这个仪表盘的人现在还在公司吗？他可能离开公司了，那就更糟糕。一个比度量指标仪表板更好的选择是使用SLOs（见文章开头术语），因为SLOs是可操作的。比方，假设有一个SLO，其中规定服务X的响应时间必须低于某个阈值的95%。如果服务没有达到SLO，就会触发警报，通过企业微信、电话、短信或其他方式通知，告诉值班工程师：系统没有在预期的参数内表现出来，你必须仔细检查一下情况。这就需要他去看这些指标，当然，这些指标与问题的追踪是相干联的。
日记和度量指标是否充足？如上述讨论，日记本身并不充足好，因为它们缺乏配景/上下文。我们还了解到，度量指标本身也不充足好，因为它们也缺乏上下文。向APM工具发送日记和度量指标并不能神奇地给我们提供上下文。因此：日记 + 指标  ！=  可观测性
但是，如果日记是与跟踪（traces）联系在一起的（比方，作为跨度事件），而且度量指标与跟踪相连（比方，从跟踪中推导出度量指标，或者通过链接属性将它们关联起来）。这样，我们就能看到系统的全貌。
在这种情况下，我们可以说跟踪（traces）是创建可观测性的基础，所以：痕迹（日记 + 度量）== 可观测性
总之，traces应该是遥测（telemetry）数据的基础。


参考：

• ACTS：如何让缺陷无处藏身？（可测试性=可控性+可观测性）
  
  
• 十年磨一剑：蚂蚁集团可观测性平台 AntMonitor 揭秘
  
  
• 一文读懂：近来流行的可观察性
  
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

继续阅读请点击广告