皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

微服务监控:2018 年预测

作者  Mark Little ,译者 盖磊  

多年来,我们已经探讨了 微服务在实现和部署中所面临的不少挑战 。如何 监控 微服务构建的分布式应用中发生的事情,这是一个贯穿始终的问题。随着复杂性的增加,以及 协同(choreographies) 理念的日益重要,微服务监控尤为紧迫。例如,早在 2017 年初我们举办的一次“ 微服务实践的虚拟研讨会 ”中,在被问及列出关于微服务前五位要做的和前五位不要做的事项时,研讨会参与嘉宾之一的 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)解决方案,例如 NewRelic 和 Dynatrace,严重依赖于不同层级上的仪表展示(Instrumentation),这就是为什么这些产品必须要安装软件厂商特定的代理才能采集度量。代理可以采集应用的各种度量,包括垃圾回收行为等底层语言特定的度量,以及 RPC 和数据库延迟等软件库特定的度量。

Péter 进而指出,应注意不要过于快速推进乃至深入 APM 路线。他给出了如下的预测:

使用软件厂商特定的代理会导致一个问题,当开发人员开始将多种监控解决方案和代理一并使用时,会丢失当前 APM 解决方案的一些特性。多代理通常意味着对同一构件代码(code picec)给出多种仪表显示方式,这可能会导致不必要的性能开销、虚假的度量,甚至是软件缺陷。我认为在未来使用软件厂商特定代理的趋势将发生变化,APM 软件提供商将通过共同努力提出仪表显示的开放标准。未来将是独立于软件厂商的时代,所有价值来自于不同的后端和 UI 特性。

之后,Péter 跳转到分布式追踪(distributed tracing)相关问题上。在他看来,为了监控并调试所涌现的容器和微服务,驱使开发人员提高实现可观测性方法。过去我们也曾探讨过分布式追踪技术,例如 Zipkin,以及近期 Cindy Sridharan 对可观测性的介绍

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

Péter 也同意上述观点。在文章中探讨 OpenTracing 技术及其重要性之前,他给出了一些例子,说明了想要提供的内容:

(……)标准,以及用于分布式追踪仪表显示的接口,这些接口是独立于软件厂商的。Opentracing 提供了一套标准的 API,对代码情况做仪表显示,并连接到各种追踪后端。它也可以在任何时候对代码做仪表显示。不存在任何问题,并更改追踪后端。

他给出了一些在原始技术中使用 OpenTracing 的例子,特别是从 Node.js 开发的角度。在文章结尾处,他作出了一个强调声明,也可以说是一个请求:“ 我希望将来会有越来越多的标准化仪表显示解决方案,也希望有一天,所有的 APM 软件厂商能共同努力,提供最好的软件厂商独立的代理

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

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

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

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

在文章最后,Péter 总结并给出了如下预测:

要使微服务的监控和观测性更上一层楼,并步入下一代 APM 工具的时代,需要给出一种开放的、独立于软件厂商的仪表显示标准,正如 OpenTracing 那样。该新标准需应用于 APM 软件厂商、服务提供商和开源软件维护者。

查看英文原文: Monitoring Microservices – A Prediction for 2018

转自 http://www.infoq.com/cn/news/2017/12/monitoring-microservices

分享到:更多 ()