微服务监控：2018 年预测

过去数年间，我们探讨了微服务实现和部署中所面临的多个挑战。一个贯穿始终的问题，是如何监控由微服务构建的分布式应用中的情况。随着复杂性的不断增加，以及协同（choreographies）理念日益重要，微服务监控变得尤为紧迫。例如，在 2017 年初 InfoQ 举办的一次“微服务实践的虚拟研讨会”中，在被问及分别列出微服务上前五位应做的和不应做的事项时，研讨会参与嘉宾之一的 Martin Verburg 说：

在构建整个系统之前，先构建 3 个互相交互的服务原型，找出实现非功能需求的解决方案，比如安全问题、服务发现、健康监控、回压、失效备援，等等。

在被问及是否可推荐一些专用于微服务开发的语言或技术时，研讨会参与嘉宾之一的 Adam Bien 说：

Java 已经诞生 20 多年了，它是一门成熟的开发语言，具有强大的工具和监控能力。Java 在一开始就融入了微服务概念，比如 Jini/JXTA 框架，它们与 No-SQL 数据库（比如 JavaSpaces）混在一起。可以说，Java 超前了 15 年，那个时候市场还没有做好使用这些技术的准备。不过，从 1999 年以来的那些技术在今天仍然适用。我们并没有重新造轮子。

在过去的一年甚至更长的时间中，我们总是习惯于将 Linux 容器和微服务等同看待，这影响到了对监控的考量。最近， RisingStack 的 CTO Péter Márton 撰文对明年的发展情况给出了一些意见。文中首先阐明了一些基本理念：

目前市面上的 APM（应用性能监控，Application Performance Monitoring）解决方案严重地依赖于不同层级的观测（Instrumentation），例如 NewRelic 和 Dynatrace 等。这些产品必须安装软件厂商特定的代理才能采集度量。代理采集应用的各种度量，其中包括一些底层语言特定的度量（例如垃圾回收行为等），以及一些软件库特定的度量（例如 RPC、数据库延迟等）。

Péter 进而指出，应注意不要过于快速地推进 APM 路线，甚至是深陷其中。文中给出了如下预测：

使用厂商特定的代理会导致一个问题，即一旦开发人员同时使用多种监控解决方案和代理，就会丢失当前 APM 解决方案的部分特性。多代理通常意味着对同一构件代码（code picec）做出多种观测，进而导致不必要的性能开销、虚假的度量乃至软件缺陷。我认为，使用厂商特定代理的趋势在未来将会发生改变，APM 软件提供商将会共同努力提出一种开放的观测标准。未来将会是一个独立于厂商的时代，所有价值将来自于不同的后端和 UI 特性。

随后 Péter 笔锋一转，开始探讨分布式追踪（distributed tracing）的相关问题。在他看来，容器和微服务技术的涌现，驱使开发人员为实现监控和调试而提升可观测性（Observability）方法。InfoQ 曾探讨过分布式追踪技术，例如对Zipkin 的介绍，以及近期 Cindy Sridharan 对可观测性的介绍：

日志、指标和请求跟踪是可观测性的基础。日志为数据（如指标）提供额外的上下文。不过，日志对性能的影响也很大。相比之下，指标的开销是不变的，而且有利于预警。总而言之，日志和指标可以为观察单独的系统提供方便，但是对于穿过多个系统的请求，很难提供其生命周期的信息。跟踪提供了跟踪在各个系统之间传递的请求的能力。

Péter 同意上述的观点。在探讨 OpenTracing 技术及其重要性之前，文中给出了一些例子，说明了 OpenTracing 意在提供：

(……）标准的、独立于厂商的分布式追踪观测接口。Opentracing 提供标准的 API，用于收集代码观测指标，并传递给各种追踪后端。它可以做到，只需收集一次代码观测指标，完全没有问题地用于各种追踪后端。

他给出了一些将 OpenTracing 用于原生技术的例子，特别是从 Node.js 开发的角度。他强调指出，也可以说是发出了一个请求：“我希望将来会有越来越多的标准化观测解决方案。也希望有一天，所有的 APM 软件厂商能共同努力，给出最好的独立于厂商的代理”

文章的更多内容是关于 OpenTracing 的。文中介绍了 OpenTracing 是如何与 ElasticSearch 和 Prometheus 一起工作的，并给出一些例子和展示图。正如 Péter 所指出的，这些例子显示了 OpenTracing 在架构拓扑可视化上的强大功能，有助于了解问题发生问题时的相关情况。文中进一步引用了 RisingStack 的一个 Node.js 上的度量追踪项目。据 Péter 介绍，该项目可用于：

（……）基于这些度量信息，对整体拓扑结果做逆向工程，并可视化各服务间的依赖关系。我们可以从这些度量中获得微服务架构中应用和数据库间通量和延迟的情况。

在 2016 年早期，我们曾就“对大规模容器进行监控所面临的挑战”访谈了部分人士。对于如何理解和使用追踪所采集数据方面的问题，Dynatrace 的首席技术战略师 Alois Reitbauer 给出了以下观点：

（……）每个人都必须了解这些监控数据。这也是为什么我们花费了大量时间创建自解释的信息图表，让每个人都能够其中的意义。另一个关键需求是对异常情况的检测。由于系统的巨大规模，没有任何人能够做到手动查看所有数字。因此，监控系统必须了解什么是正常的行为，并当系统的行为出现异常时进行提示。最后一个方面在于具备上下文的语义信息。举例来说，监控系统需要“理解”指标所代表的意义，以及它与其他指标的关联。我们需要了解整个应用中的所有依赖，将这此信息用于问题的分析。

在文章最后，Péter 做了总结，并给出如下预测：

要使微服务的监控和可观测性更上一层楼，并步入下一代 APM 工具时代，需要给出 OpenTracing 那样的独立于厂商的开放观测标准。这一新标准应得到 APM 软件厂商、服务提供商和开源软件维护者的采用。

查看英文原文： Monitoring Microservices - A Prediction for 2018