构建可观测的分布式系统

如今的系统正在变得越来越复杂；微服务在网络上是分布式存在的，并且能够动态扩展，这样会导致各种形式的故障，出现故障的方式是我们无法预料的。如果盲目相信我们能够构建完美的系统将会形成错误的安全感，所以我们需要预先为此做好充分地准备。在可观测方面进行投资能够让我们掌握系统的运行状况，这些事情是我们以前所想象不到的。在这方面有一些可用的工具，包括指标、跟踪、结构化和关联日志。

Pierre Vincent 是 Poppulo 的站点可靠性工程（site reliability engineering，SRE）主管，在 QCon 伦敦 2018 上做了关于构建可观测的分布式系统的演讲。InfoQ 以访谈、演讲、总结和文章的形式报道了此次会议。

InfoQ 采访了 Vincent，讨论了将可观测性应用于分布式系统的话题。

InfoQ：在演讲中，您提到到达生产环境仅仅是个开始。您能详细介绍一下吗？

Pierre Vincent：在部署到生产环境之前，我们对其中的每件事都很擅长，但是我们很少会在部署到生产环境之后再进行改善。我看到的越多就越发现将所有的时间花费在生产环境之前不仅会带来收益的递减，还会适得其反。我们可能会相信能够构建出完美的东西，但是最终系统可能会出现故障，变得难以处理，当我们开始分布式系统时，这一点将会尤为明显。

作为开发人员，我长期有这种错误的看法：生产环境上线就万事大吉了，生产环境部署之后，我们的任务就完成了，它就变成了别人的问题，我们就可以转向下一个用户故事或特性了。我们自以为心安理得，认为在生产环境部署之前，我们所做的重要的事情已经足够多了：TDD、集成测试、阶段部署、端到端等等。

如今，我们正在处理更复杂的系统，它们具备跨网络分布、动态扩展等特点。这样会带来各种形式的故障，出现故障的方式是我们无法预料的。如果盲目相信我们能够构建完美的系统将会形成错误的安全感：当出现故障时，我们根本就没有准备好。而另外一个坏消息就是，故障会更加难以处理，因为我们没有任何东西去探测或调查问题的原因。

InfoQ：可观测性能够如何帮助我们应对生产环境中出现的问题呢？

Vincent：在可观测性方面进行投资意味着我们要花费时间对系统进行 instrument 操作，让我们在应对生产环境中未知的问题时有可用的工具。

在生产环境中，我们有不同的方式来获取信息。起始的时候，这可能会非常简单，比如基本的健康状态检查。借助时间序列指标，我们可以使用很多工具来完成一些很强大的功能。指标、跟踪、日志、关联和结构化日志、事件。没有哪种方案能够适用于所有的场景，但是将它们组合起来能够形成强大的解决方案。我们必须承认，事情总有可能会出错，但是当出错的时候，我们借助这些工具能够辅助探查，帮助我们快速应对和恢复。

InfoQ：你推荐哪些可观测性技术和实践呢？

Vincent：很多人会满足于指标或监控，但是还有其他的事情值得关注。

在低粒度维度聚合数据方面，指标是非常有效的，这也使得它成为服务级别监控的一个不错选择。但是，指标在基数较大时，扩展性并不好，而这是调试和探查所需的。我们曾经将 Prometheus 用到高基数的时间序列上，这并没有达到预期的效果！

好的日志，尤其是结构化的日志，在帮我们理解应用的行为时扮演了重要的角色。通过良好的日志，我指的是能够易于搜索并且能够提供足够的上下文信息帮助我们理解事件是如何发生的。日志的关联也是首先要关注的事情之一，可以使用像 Request Id 这样的方式在整个系统中跟踪请求。但是，日志的代价可能会非常高昂，日志库通常会有一定的开销，管理大量的日志可能需要一定的技巧，在日志级别上进行采样也并不简单。

在我们的技术栈中，使用 Zipkin（Open Tracing）方面，我们有一些好的经验：我们实际上使用 Trace Id 作为日志关联 Id，这样的话，更容易从 log 跳转到 trace。在观测 trace 的最初几个小时中，我们发现了一些我们之前未曾关注到的事情。遗憾的是，分布式跟踪对现有的系统有较高的 instrumentation 成本。我们花了一年多的时间，还没有全部完成。我的建议就是：如果你刚刚开始构建系统的话，将跟踪添加进去，预先做这件事会带来巨大的成本节省。

我们目前正在研究的是异常传输，尤其是客户端浏览器的错误。长期以来，这是我们的一个盲点，我们正在尝试像 Sentry 这样的工具能否增加可见性，尤其是那些对客户产生影响的错误。

整体而言，你必须要花费一定的时间使用这些工具，掌握它们擅长什么。单个工具肯定是不行的，关键在于找到合适的平衡点，让它们各自发挥出最大的作用。

InfoQ：可观测性能够带来什么好处呢？

Vincent：对我们来说，立竿见影的好处就是可见性。当几年前引入 Prometheus 时，我们的反应是非常明确的：如何在不了解上述这些功能的情况下，把事情做好？从那时起，就进入了一个良性的循环：提出更多的问题，如果我们无法回答的话，就对系统执行更多的 instrument 操作。

正如我在前文所述，这个过程中并非没有问题：当指标不适合解决方案时，我们必须审视我们的策略。其中有个样例就是，针对客户级别粒度（这是一个基数很高的粒度），我们依赖于结构化的日志，这使得我们能够基于每个客户进行调试。

InfoQ：可观测性的未来将会如何发展呢？

Vincent：我们确实应当将用户和开发人员的易用性提上日程。如果系统难以进行 instrument 操作并且输出难以解释的话，那么这就是一场失败的战斗。

如果还有什么事情值得一提的话，我认为日志将会得到更多的关注。目前它有一定的局限性，但是在结构化日志方面还有很大的潜力：提供更详细的上下文信息并支持更好的调试功能。

查看英文原文： Building Observable Distributed Systems