微服务监控：2018年预测

文化&方法

摘要： 多年来，微服务的监控与分布式追踪一直是一个挑战性的问题。近期，RisingStack的CTO Péter Márton撰写了一篇文章，文中通过一些建议和例子代码，介绍了包括OpenTracing在内的各种微服务监控方式，最后对微服务监控的未来发展提供了一两个建议。

作者： Mark Little

正文：

过去数年间，我们探讨了微服务实现和部署中所面临的多个挑战。一个贯穿始终的问题，是如何监控由微服务构建的分布式应用中的情况。随着复杂性的不断增加，以及协同（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