【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

微服务监控:2018 年预测

  • 2017-12-03
  • 本文字数:2216 字

    阅读完需:约 7 分钟

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

2017-12-03 18:003642
用户头像

发布了 391 篇内容, 共 126.0 次阅读, 收获喜欢 255 次。

关注

评论

发布
暂无评论
发现更多内容

喜报 | 思码逸 DevInsight 通过DaoCloud兼容性互认证

思码逸研发效能

亲测可用!Acrobat Pro DC 2023中文破解版 Mac/win

Rose

Dapp开发技术指南,快速入门,掌握实战技能

区块链软件开发推广运营

dapp开发 区块链开发 链游开发 NFT开发 公链开发

运用 Argo Workflows 协调 CI/CD 流水线

SEAL安全

开源 Kubernetes CI/CD

几个有趣的C/C++语言『冷知识』

伤感汤姆布利柏

C语言 编程语言、 c++语言

中国首档数字人真人秀怎样实现?

青否数字人

数字人

Character Animator 2024 (Ch2024角色动画设计软件) Mac/win

Rose

熬了一晚上,开放签电子签章移动端上线了~

开放签开源电子签章

电子合同 电子签章

NFTScan | 02.19~02.25 NFT 市场热点汇总

NFT Research

NFT NFT\ NFTScan

水杉Metasequoia 4:开启全新的三维建模时代

Rose

FxFactory 8 Pro视觉效果插件:从粒子系统到3D动画

Rose

Pydantic:强大的Python 数据验证库

霍格沃兹测试开发学社

2023 re:Invent 用 Amazon Q 打造你的知识库

亚马逊云科技 (Amazon Web Services)

人工智能

BRC20铭文智能合约系统开发规则指南

区块链软件开发推广运营

dapp开发 区块链开发 链游开发 NFT开发 公链开发

是什么增加了系统的复杂度

Bruce Talk

敏捷开发 Agile Product Owner

免费好用的菜单栏Cpu可视化监测工具:跑猫RunCat for mac

Rose

直播回顾 | 张乐、何勉、余伟、任晶磊共议研发效能的破局之道

思码逸研发效能

Solidity案例详解(三)飞机管理合约

BSN研习社

区块链 Solidity

青团社:亿级灵活用工平台的云原生架构实践

阿里巴巴云原生

阿里云 云原生 可观测

AI 编程如何颠覆生产力 | 参与体验免费领取 ArchSummit 架构师峰会专属门票

阿里巴巴云原生

阿里云 云原生

如何避免被公司裁掉?

小齐写代码

微服务监控:2018年预测_DevOps & 平台工程_Mark Little_InfoQ精选文章