可观测性之两大误区

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



有一天，我和一位读者刚开始对可观测性中日志数据的价值看法不同，但通过一阵子辩论（或者说来回争论）之后，我们最终达成了共识，得到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 揭秘
  
  
• 一文读懂：最近流行的可观察性
  
  

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