BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

华为吴晟:分布式监控系统的设计与实现

| 作者 郭蕾 关注 9 他的粉丝 发布于 2017年8月15日. 估计阅读时间: 10 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

微服务架构其实就是将单一的应用程序划分成为一组小的服务,其中每个服务都是独立的业务单元,同时又能够被独立开发、运行、测试以及部署。简单来说,它的本质其实就是拆分和独立,这也决定了微服务的部署应该是分布式的。微服务架构虽然解决了目前诸多的架构层面的问题,但在分布式部署的环境中,如何才能够有效监控每一个服务,并及时发现系统中的问题又成为了新的挑战。

Google公司早已就在其生产系统中实践了分布式理念,为了解决监控问题,他们研发了Dapper分布式跟踪系统,并对外公开了相关论文。与此同时,Twitter基于Google的论文开发了Dapper系统的开源实现Zipkin。国内类似的有过曝光的系统还有淘宝鹰眼系统EagleEye以及开源软件Skywalking。InfoQ记者就分布式监控相关的问题采访了Skywalking作者吴晟,请他从整体层面为读者分享解读分布式监控相关的技术难点。另外,吴晟也将会在9月10日举行的CNUTCon全球运维技术大会上分享相关话题,欢迎关注。

InfoQ:对于分布式系统的监控,你认为难点是什么?目前有哪些可行的落地思路?

吴晟:分布式监控系统从使用的角度上,无论是手动探针还是自动探针,上手难度都不大。多数的技术型软件,从数据库、大数据处理到流式计算,在入门时都需要经历复杂的安装和参数设置过程。但是对于分布式监控系统,无论是Zipkin、Skywalking这些国内外的开源监控产品,还是各种商业APM产品,安装和入门难度都不大。

但对于开发一款分布式监控系统来说,情境则完全不同,无论是探针还是后台处理都有很多的挑战。比如:

  • Java自动探针的实现,对于Java字节码、程序运行情况、GC、程序优化都要有相当细致的要求。

  • 后端分析服务,如果不了解探针,给出的分析方案难度大,效率低,机器需求量大。

  • 探针网络传输的需求,序列化效率。

在APM领域,程序的细节决定产品的性能。目前按照探针的实现,可行的思路主要有四种:

  1. 基于日志系统,探针只负责对日志加上编号,又类似ELK的系统进行收集、处理、展示。这方面没有很成熟的产品,一般都属于公司内部封装的框架。

  2. 自动探针,适用语言:Java、C#、PHP、Node.js等等存在VM的语言。绝对大多数的商业产品和热门的开源产品都属于这个系列。

  3. 全手动探针,优势是适用范围广,最有名的就是Zipkin的整个生态系统,分布式追踪几乎无处不在。也是现在全球运用最广泛的分布式监控系统。

  4. 同时支持自动和手动模式的探针,适用语言同样是Java、C#、PHP、Node.js等等存在VM的语言,由于技术复杂性提高,运用的较少。优点是入门方便,同时使用灵活。商业上主要是Instana,开源主要是sky-walking提供了技术解决方案。

InfoQ:分布式监控领域常用的理论都有哪些?

吴晟:所有的分布式理论几乎都来自2010年的Google论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》,这里面详尽的描述了分布式系统的解决思路。

Dapper作为分布式监控的核心,主要给大家介绍了Trace、Span、spanId、log、采样等几个重要概念。其中Trace就是一个可能跨越多个节点的分布式。Span是调用过程中一个时间区间(时间跨度),这也是这个英文名字的由来。一般对应一个方法或者代码块的执行。SpanId按照书的索引方式(例如1, 1.0, 1.1, 1.1.1)来表达层级关系,让更多的读者很好的理解了调用链追踪。不过这里要强调的是,绝大多数的追踪系统,包括开源和商业,在工程实践上,因为消耗问题都放弃了这种方法。

log是Span跨度内发生的事件,比如异常。在实际的产品中,会使用Tag、Annotation、Log、Event等多种概念来提升效率。采样是Dapper是大篇幅强调的问题,也就是说,超高并发系统中采样是必然,如何采样也是各产品策略不同,比如按照Span采样,按照Trace采样。

但是几乎所有的现在开源和商业分布式监控系统,都在论文的基础上做了大量改进,模型并不相同。目前阶段,CNCF基金会的OpenTracing标准,是一个很好的理论参考。

还有就是Zipkin的庞大生态和大量公司的参与。我和Zipkin的负责人,Pivotal资深工程师Adrian Cole有过很多的沟通,在跨语言,跨平台的监控上,Zipkin有着强大的用户基础和案例。

InfoQ:从你的角度来看,分布式监控系统应该包含哪些模块?

吴晟:监控系统一般分为三大模块:

探针或SDK,负责数据采集和发送。探针或SDK是应用程序的收集端。一般使用插件的模式,自动探针一般是不需要修改程序,而SDK则是需要修改部分配置或者代码。skywalking就是自动探针为主,zipkin-brave就是Zipkin的Java手动探针。

Collector模块,负责数据收集、分析、汇总、告警和存储。Collector模块,这个根据不同的APM实现,可能由一个或者多个子系统构成。Collector负责对探针和SDK提供网络接口(TCP、UDP、HTTP不同形式接口)。

功能上,主要包含数据收集、分析、汇总、告警和存储。这些模块在复杂的开源APM和商业产品上都保持一致。大家选择时,值得注意的是,现在包括Zipkin在内的不少国外的追踪系统,是只负责追踪,不负责分析汇总,他们认为分析可以由使用者自己负责。

作为分析方式,分为流式分析和异步批量两种,而流式分析会对数据统计和告警的实时性更有帮助。

UI,负责高实时性的展现。包括但不限于Trace的查询,统计数据展现,拓扑图展现,VM或进程相关信息等,监控关键数据的展现。

InfoQ:对于访问量较大的应用,如何解决埋点监控的性能问题?

吴晟:这是我在本次分享里面很多内容的根本,性能问题。这个其实没有标准答案,根据系统的不同,流量不同,容忍度不同,标准会完全不同。我们举个简单的例子,在Google,千分之一,万分之一的采样,依然是大数据分析,依然足以定位问题;在多数非BAT核心产品上,50%或者100%采样都不会有性能问题。一定要选择适合自己的,不要过分担忧。

一般说来,一款合格的产品,在单点500TPS之下的应用,采样率都可以保持的很高。

InfoQ:现在你们的监控系统有没有结合大数据分析,智能的进行故障预警以及处理?

吴晟:目前sky-walking没有去做这方面的工作,因为这样会大大增加部署和运维的难度。有需求,有运维的能力的公司,很容易在产品的基础上进行相关的分析。

在商业产品中,指标方差数,趋势分析,偏移量,热度分析,用户促销活动等等都是在处理范围中。

InfoQ:你的演讲里有一个有趣的观点,面向研发的监控和面向运维的监控,如何理解这句话?

吴晟:虽然现在DevOps很热,但是无论一体化进行到哪个阶段,线上问题和开发迭代,永远都有时间差。所以“线上问题的发现、规避和应急响应”和“研发过程对于产品的改进和修复”是两个有联系又实际并不相同的理念。

目前的DevOps,强调快速的迭代和响应,微更新,快速发布。相关的容器化技术也是倍受追捧。而这些对于分布式监控的要求也是越来越高。主要原因是分布式的节点,从几十个上升到几百个上千个都是很常见的。

但是,DevOps的发展,并不会完全消除“线上问题响应”和”线下修复问题“中间的时间差。

比如在生产环境中,某个数据库因为冷门业务的某条大SQL语句缓慢,拖慢服务器IO性能,造成应用其他主要接口响应受到影响。

  1. 对于运维人员,监控系统的职责是需要发现这条慢SQL,识别数据对应的session信息,辅助运维人员杀掉这条SQL的执行。

  2. 对于开发人员,则需要反馈调用链路,找到发生这条SQL调用的原因,是特定参数引起的,还是特定的条件分支,或者是特定的用户。并通过本周期迭代,避免或降低再次发生这个问题的风险。

这个案例中,你会看到,其实,APM系统需要提供的信息是不太相同的。这就是所谓的“面向研发的监控”和“面向运维的监控”之间的差别。而很多人都忽略了这个差别,而这对于APM系统的运用和演进都是很重要的。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT