当前位置:云计算行业动态 → 正文

微服务监控:2018年预测

责任编辑:editor004 作者:Mark Little |来源:企业网D1Net  2017-12-04 11:18:56 本文摘自:INFOQ

在构建整个系统之前,先构建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软件厂商、服务提供商和开源软件维护者。

关键字:ter软件厂商仪表显示

本文摘自:INFOQ

x 微服务监控:2018年预测 扫一扫
分享本文到朋友圈
当前位置:云计算行业动态 → 正文

微服务监控:2018年预测

责任编辑:editor004 作者:Mark Little |来源:企业网D1Net  2017-12-04 11:18:56 本文摘自:INFOQ

在构建整个系统之前,先构建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软件厂商、服务提供商和开源软件维护者。

关键字:ter软件厂商仪表显示

本文摘自:INFOQ

电子周刊
回到顶部

关于我们联系我们版权声明隐私条款广告服务友情链接投稿中心招贤纳士

企业网版权所有 ©2010-2024 京ICP备09108050号-6 京公网安备 11010502049343号

^