全链路监控跟踪-资料整理和简单学习

本文最后更新于2019年5月19日,已超过 1 年没有更新,如果文章内容失效,还请反馈给我,谢谢!

=Start=

缘由:

业界大部分的应用分布式追踪的原理源自 Google 的一篇 Dapper系统的论文,比较出名的有:

  • Twitter贡献出来的Zipkin
  • 阿里的鹰眼
  • 腾讯的天机阁
  • 韩国人开源的Pinpoint
  • 国人开源的SkyWalking
  • 美团点评的CAT
  • 新浪的Watchman
  • 京东的Hydra [开源项目已于2013年6月停止维护]

正文:

参考解答:
微服务之熵:

为了支撑日益增长的庞大业务量,业界大量使用微服务架构。服务按照不同的维度进行拆分,互联网应用构建在不同的软件模块集上,这些软件模块可能是由不同的团队开发、可能使用不同的编程语言来实现、可能布在了几千台服务器,横跨多个不同的数据中心,分布式系统变得日趋复杂。一个请求的完整调用链可能如下图所示:

一个请求的调用链示例

基于微服务体系之下构建的业务系统存在的问题基本上分为四类:

第一个是故障定位难,今天我们淘宝下单的动作,用户在页面上点购买按钮,这么一个简单操作,其实它背后是由十几个甚至数十个的微服务去共同完成的,这十几个甚至几十个微服务也由不同的团队去负责,这是微服务的过度协同带来的结果,一旦出现问题,最坏情况下我们也许就要拉上十几个团队一起来看问题。

第二个问题是容量预估难,阿里每年要做若干次大促活动,在以前的巨石系统当中做容量预估是非常容易的,因为我们大促时候按照预估的流量与当前系统的单机压测容量做一个对比,把所有的系统按比例去扩容就可以了。而实际上在大促的场景下,每一个系统在核心链路当中的参与度、重要性都是不一样的,我们并不能对每一个系统做等比例的扩容,所以微服务架构下的容量预估也是一件难事。

第三个问题就是资源浪费多,资源浪费多首先是容量预估不准的一个后果,同时资源浪费多背后隐含的另一个问题就是性能优化难,为什么这么说呢?我们当打开一个页面发现它慢的时候,我根本不知道这个页面慢在哪里,瓶颈在哪里,怎么去优化,这些问题累积下来,资源的浪费也成为了一个巨大的问题。

第四个是链路梳理难,我们一个新人加入阿里的时候,老板让他负责一个系统,他在这个复杂的微服务体系中,就像人第一次在没有地图没有导航的情况下来到一个大城市一样,根本不知道自己身在何处。应用负责人不知道自己的系统被谁依赖了,也不知道自己的系统下游会影响其他哪些人。

整体来看,我们所说的微服务之熵主要就包含了上述这四个问题。

全链路监控系统希望达到的效果:
  1. 请求链路追踪,故障快速定位:可以通过调用链结合业务日志快速定位错误原因。
  2. 可视化: 记录各个阶段耗时,进行性能分析。
  3. 依赖优化:统计各个调用环节的可用性、梳理服务依赖关系以及优化。
  4. 数据分析,链路梳理和优化:分析用户的行为路径,梳理和优化整体调用链路。
全链路监控系统组件的一些目标要求:
  1. 探针的性能消耗——APM组件服务的影响应该做到足够小。服务调用埋点本身会带来性能损耗,这就需要调用跟踪的低损耗,实际中还会通过配置采样率的方式,选择一部分请求去分析请求路径。在一些高度优化过的服务,即使一点点损耗也会很容易察觉到,而且有可能迫使在线服务的部署团队不得不将跟踪系统关停。
  2. 代码的侵入性——作为业务组件,应当尽可能少入侵或者无入侵其他业务系统,对于使用方透明,减少开发人员的负担。对于应用的程序员来说,是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效,就必须需要依赖应用的开发者主动配合,那么这个跟踪系统也太脆弱了,往往由于跟踪系统在应用中植入代码的bug或疏忽导致应用出问题,这样才是无法满足对跟踪系统“无所不在的部署”这个需求。
  3. 可扩展性——一个优秀的调用跟踪系统必须支持分布式部署,具备良好的可扩展性。能够支持的组件越多当然越好。或者提供便捷的插件开发API,对于一些没有监控到的组件,应用开发者也可以根据需要自行扩展。
  4. 数据的分析——分析的速度要尽可能快 ,分析的维度要尽可能多。监控跟踪系统越能提供足够快、足够准的信息反馈,开发、运维就越能对生产环境下的异常状况做出快速反应。
常见的开源全链路监控系统简单对比:
基本原理对比:
类别ZipkinPinpointSKYWALKINGCAT
实现方式拦截请求,发送(HTTP,MQ)数据至Zipkin服务Java探针,字节码增强Java探针,字节码增强代码埋点(拦截器,注解,过滤器等)
接入方式对比:
类别ZipkinPinpointSkyWalkingCAT
实现方式基于Linkerd或者Sleuth方式,引入配置即可JavaAgent字节码JavaAgent字节码代码侵入
分析粒度对比:
类别ZipkinPinpointSkyWalkingCAT
颗粒度接口级方法级方法级代码级
全局调用统计×
traceid查询××
报警×
JVM监控××
其它对比项:
  • 管理端功能;
  • 数据存储方式;
  • 社区活跃度;
  • 插件化、定制化难易程度;

参考链接:

=END=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/4438.html

11 thoughts on “全链路监控跟踪-资料整理和简单学习”

  1. 应用性能管理の巅峰对决:Apache Skywalking P.K. Pinpoint
    https://mp.weixin.qq.com/s/uKqy5XX8wuMuOPZ9iNTqZg
    `
    社区比较
    支持语言比较
    协议比较
    存储比较(重要)
    UI比较
    扩展性比较
    告警比较
    JVM监控
    服务监控
    跟踪粒度比较
    过滤追踪
    性能损耗
    发布包比较
    支持组件比较
    总结
    参考链接

    说明:本次对比基于skywalking-6.0.0-GA和Pinpoint-1.8.2(截止2019-02-19最新版本)。另外,我们这次技术选型直接否定了Zipkin,其最大原因是它对代码有侵入性,CAT也是一样。这是我们所完全无法接受的。
    `

  2. 基于APM的智能运维体系在京东物流的落地和实践
    https://mp.weixin.qq.com/s/SgD1djsi1lgRaxl1M0WJ9A
    `
    本文整理自 2019 年 QCon 北京站上京东物流架构师付正全的演讲,主要介绍了京东物流大规模实时监控平台、AIOps 和 APM 的相关实践。

    为了支撑业务的高速发展,京东物流在智能运维体系的落地和构建方案上一直迭代优化、持续演进。从构建基于系统指标的实时大规模智能监控平台到融合多个部门多个监控平台的统一监控平台实践,再到基于 APM 的智能运维体系落地。通过实时告警、实时预警、故障智能处理以及全方位的应用维度数据分析,大大缩短了研发人员定位问题的效率,有力保障了大促期间各系统的平稳运行。

    我们在构建这套运维体系的时候大体上分为以下三个阶段:
    第一阶段是构建实时的大规模监控平台。这个阶段是一个从 0 到 1 的过程,从基础的 CMDB 系统建设到建设大规模实时监控平台。
    第二阶段在监控平台的基础上整合了京东现有的多个应用监控系统。结合应用维度的数据整合,进一步完善了监控数据维度的同时极大提高了研发人员进行故障定位的效率。
    第三阶段我们开始了 APM 和 AIOps 相关的一些尝试。

    下面我会从以下几个方面来介绍今天的内容:
    · 智能运维发展的现状和趋势
    · 智能运维体系建设方法论
    · 大规模实时监控平台的实践方案
    · 智能故障定位与处理实践
    · APM 在京东物流的落地实践
    · 智能运维落地规划
    `

  3. 开源分布式跟踪方案概览
    https://www.infoq.cn/article/f5bBD119Zv49aak_eByE
    https://developers.redhat.com/blog/2019/05/01/a-guide-to-the-open-source-distributed-tracing-landscape/
    `
    本文对最流行的工具进行了概述和分类,能够帮助你掌握分布式跟踪领域的概况。

    虽然跟踪和采样分析是密切相关的两个学科,但是分布式跟踪通常被理解将应用中不同工作单元的信息连接在一起,以便理解整个事件链的技术,这些工作单元会在不同的进程或主机中执行。在现代应用程序中,这意味着分布式跟踪可以用来描述 HTTP 请求在穿越大量微服务时的情况。

    这里所列的大多数工具可以大致分为 instrumentation 库、tracer、分析工具(analysis tool,后端 +UI),以及它们的任意组合。博文“各种跟踪方式的差异”很好地描述了分布式跟踪的这三个方面。

    对于本文来讲,我们将instrumentation定义为用来告诉记录哪些信息的库,将tracer定义为如何记录并提交数据的库,将分析工具定义为接收跟踪信息的后端。在现实中,这些分类是不断变化的,instrumentation 和 tracer 的区别并不会始终那么明显。类似的,分析工具这个术语可能会过于宽泛,因为有些工具会关注探索跟踪信息,而有些则是完整的可观察性平台。

    本指南只列出了开源的项目,不过还有一些其他的厂商和解决方案值得关注,比如 AWS X-Ray、Datadog、Google Stackdriver、Instana、LightStep 等。
    `

  4. 饿了么监控系统 EMonitor 与美团点评 CAT 的对比
    https://mp.weixin.qq.com/s/Dt-o1Cg6jcmn-Ez3n6CL5w
    `
    饿了么监控系统 EMonitor :是一款服务于饿了么所有技术部门的一站式监控系统,覆盖了系统监控、容器监控、网络监控、中间件监控、业务监控、接入层监控以及前端监控的数据存储与查询。每日处理总数据量近 PB ,每日写入指标数据量百T,每日指标查询量几千万,配置图表个数上万,看板个数上千。

    CAT:是基于 Java 开发的实时应用监控平台,为美团点评提供了全面的实时监控告警服务。

    本文通过对比分析下两者所做的事情为契机讨论监控系统或许该有的面貌,以及浅谈下监控系统发展的各个阶段。

    # 浅谈监控系统的发展趋势

    1、日志监控阶段

    本阶段实现方式:程序打日志,使用ELK来存储和查询程序的运行日志, ELK 也能简单显示指标曲线。
    排障过程:一旦有问题,则去 ELK 中搜索可能的异常日志来进行分析排障。

    2、链路监控阶段

    上一个阶段存在的问题: ELK 只是基于一行一行日志进行聚合或者搜索分析,日志之间没有上下文关联。很难知道一次请求耗时较长究竟耗时在哪个阶段。

    本阶段实现方式: CAT 横空出世,通过建模抽象出 Transaction、Metric 等监控模型,将链路分析和简单的报表带入了大家的视野。

    告警方式:针对报表可以进行阈值监控排障过程:一旦有告警,可以通过点击报表来详细定位到是哪个 type 或 name 有一定问题,顺便找到对应的链路,查看详细的信息。

    3、指标监控阶段

    上一阶段存在的问题: CAT 对自定义指标支持的比较弱,也无法实现或者展现更加多样的查询聚合需求。

    本阶段的实现方式:支持丰富的 Metric 指标,将链路上的一些报表数据也可以划分到指标中,交给专业的时序数据库来做指标的存储和查询,对接或者自研丰富的指标看板如 Grafana 。

    告警方式:针对指标进行更加丰富的告警策略排障过程:一旦有告警,可能需要到各个系统上查看指标看板,粗略定位根因,再结合链路总和分析。

    4、平台打通整合阶段

    上一阶段存在的问题:系统监控、中间件和业务监控、部分业务监控、链路监控与指标监控都各搞一套数据收集、预处理、存储、查询、展现、告警流程,各个系统处理数据格式、使用方式不统一。

    本阶段的实现方式:打通从系统层面、容器层面、中间件层面、业务层面等等的可能的链路和指标监控,统一数据的处理流程,同时整合发布、变更、告警与监控曲线结合,成为一站式监控平台。

    告警方式:可以统一的针对各个层面的监控数据做统一化的告警排障过程:只需要在一个监控系统中就可以查看到所有的监控曲线和链路信息。

    目前我们 EMonitor 已完成这个阶段,将公司之前存在已久的 3 套独立的监控系统统一整合成现如今的一套监控系统。

    5、深度分析阶段

    上一阶段存在的问题:
    * 用户虽然可以在一个系统中看到所有各个层面的监控数据了,但是每次排障时仍然要花很多的时间去查看各个层面是否有问题,一旦漏看一项可能就错过了问题所在的根因;
    * 没有整个业务的全局监控视角,都停留在各自应用的角度。


    总之:之前的阶段都是去做一个监控平台,用户查询什么指标就展示相应的数据,监控平台并不去关心用户所存储数据的内容。现在呢就需要转变思路,监控平台需要主动去帮用户分析里面所存储的数据内容。

    本阶段的实现方式:所要做的就是把帮用户分析的过程抽象出来,为用户构建应用大盘和业务大盘,以及为大盘做相关的根因分析。

    * 应用大盘:就是为当前应用构建上下游应用依赖的监控、当前应用所关联的机器监控、redis、MQ、database 等等监控,可以时刻为应用做体检,来主动暴露出问题,而不是等用户去一个个查指标而后发现问题;

    * 业务大盘:就是根据业务来梳理或者利用链路来自动生产大盘,该大盘可以快速告诉用户是哪些业务环节出的问题。

    根因分析:一个大盘有很多的环节,每个环节绑定有很多的指标,每次某个告警出来有可能需要详细的分析下每个环节的指标,比如消费 kafka 的延迟上升,有各种各样的原因都可能导致,每次告警排查都需要将分析流程再全部人为分析排查下,非常累,所以需要将定位根因的过程通过建模抽象下,来进行统一解决。

    趋势报表分析:主动帮用户发现一些逐渐恶化的问题点,比如用户发布之后,接口耗时增加,很可能用户没有发现,虽然当前没有问题,但是很有可能在明天的高峰期就会暴露问题,这些都是已经实实在在发生的事故。

    要想做主动分析,还深度依赖指标下钻分析,即某个指标调用量下降了,能主动分析出是哪些 tag 维度组合导致的下降,这是上述很多智能分析的基础,这一块也不简单。

    告警方式:可以统一的针对各个层面的监控数据做统一化的告警排障过程: NOC 根据业务指标或者业务大盘快速得知是哪些业务或者应用出先了问题,应用的 owner 通过应用大盘的体检得知相关的变动信息,比如是 redis 波动、database 波动、上下游应用的某个方法波动等等,来达到快速定位问题目的,或者通过对大盘执行根因分析来定位到根因。

    # 再谈 Logging、Tracing、Metrics
    三者的确都不可或缺,相辅相成,但是我想说以下几点:
    * 三者在监控排障中的所占比例却大不一样: Metrics 占据大头, Tracing 次之, Logging 最后;

    * Tracing 含有重要的应用之间的依赖信息, Metrics 有更多的可深度分析和挖掘的空间,所以未来必然是在 Metrics 上大做文章,再结合 Tracing 中的应用依赖来做更深度全局分析,即 Metrics 和 Tracing 两者结合发挥出更多的可能性。

    `

  5. 漫谈分布式链路追踪
    https://juejin.im/post/5e1afbcbe51d451ca73d877b
    `
    链路跟踪
    * 基于特定语言实现的方案
    * 基于组织内编码规范的实现
    * 基于mesh的方案
    模型和协议设计
    * 数据模型
    * span之间的关系
    * 透传实现原理
    * span日志数据构成、透传与搜集
    模块拆分和设计边界
    * 系统模块拆分
    * 客户端功能拆分和实现
    * 类与接口设计
    有趣的设计细节
    * Trace-id vs log-id
    * Java-agent与字节码增强
    典型的应用场景
    * 请求染色(环境路由)
    * 其他应用场景
    `

  6. 有赞全链路追踪实践
    https://mp.weixin.qq.com/s/TAiQjfkxJd_uDkDHNE_Sjg
    `
    全链路追踪系统就是为了解决微服务场景下的这些问题而诞生的。一般地,该系统由几大部分组成:
    * 客户端埋点SDK:集成在各业务应用系统中,完成链路追踪、数据采集、数据上报等功能;
    * 实时数据处理系统:对客户端采集上来的数据进行实时计算和相关处理,建立必要索引和存储等;
    * 用户交互系统:提供用户交互界面,供开发、测试、运维等用户最终使用链路追踪系统提供的各项功能;
    * 离线分析系统:对链路追踪数据进行离线分析,提供诸多强大的链路统计分析和问题发现功能;

    有赞目前的应用类型有很多种,已经支持追踪的语言有 Java、Node.js、PHP。那么,如何让跨不同语言的调用链路串到一起呢?有赞的链路追踪目前在使用的是Cat协议,业界也已经有比较成熟的开源协议:OpenTracing,OpenTracing是一个“供应商中立”的开源协议,使用它提供的各语言的API和标准数据模型,开发人员可以方便的进行链路追踪,并能轻松打通不同语言的链路。

    Cat协议与OpenTracing协议在追踪思路和API上是大同小异的。基本思路是Trace和Span:Trace标识链路信息、Span标识链路中具体节点信息。一般在链路的入口应用中生成traceId和spanId,在后续的各节点调用中,traceId保持不变并全链路透传,各节点只产生自己的新的spanId。这样,通过traceId唯一标识一条链路,spanId标识链路中的具体节点的方式串起整个链路。

    全链路追踪系统包含几大部分:链路采集SDK、数据处理服务、用户产品。SDK部分比较偏技术。数据处理更考验数据处理的吞吐能力和存储的容量,采用更高级的链路采样解决方案可以有效降低这部分的成本。用户产品主要考验的是设计者对用户需求的把握,全链路追踪可以做很多事情,产品上可以堆叠出很多功能,怎样能让用户快速上手,简洁而又易用是链路追踪产品设计的一大挑战。
    `

发表评论

电子邮件地址不会被公开。 必填项已用*标注