干货 | 一文搞懂全链路监控:方案概述与比较(上)

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 干货 | 一文搞懂全链路监控:方案概述与比较

问题背景

随着微服务架构的流行,服务按照不同的维度进行拆分,一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器,横跨多个不同的数据中心。因此,就需要一些可以帮助理解系统行为、用于分析性能问题的工具,以便发生故障的时候,能够快速定位和解决问题。


全链路监控组件就在这样的问题背景下产生了。最出名的是谷歌公开的论文提到的 Google Dapper。想要在这个上下文中理解分布式系统的行为,就需要监控那些横跨了不同的应用、不同的服务器之间的关联动作


所以,在复杂的微服务架构系统中,几乎每一个前端请求都会形成一个复杂的分布式服务调用链路。一个请求完整调用链可能如下图所示:

image.png

那么在业务规模不断增大、服务不断增多以及频繁变更的情况下,面对复杂的调用链路就带来一系列问题:

  1. 如何快速发现问题?
  2. 如何判断故障影响范围?
  3. 如何梳理服务依赖以及依赖的合理性?
  4. 如何分析链路性能问题以及实时容量规划?

同时我们会关注在请求处理期间各个调用的各项性能指标,比如:吞吐量(TPS)、响应时间及错误记录等。

  1. 吞吐量,根据拓扑可计算相应组件、平台、物理设备的实时吞吐量。
  2. 响应时间,包括整体调用的响应时间和各个服务的响应时间等。
  3. 错误记录,根据服务返回统计单位时间异常次数。

全链路性能监控 从整体维度到局部维度展示各项指标,将跨应用的所有调用链性能信息集中展现,可方便度量整体和局部性能,并且方便找到故障产生的源头,生产上可极大缩短故障排除时间。


有了全链路监控工具,我们能够达到:

  1. 请求链路追踪,故障快速定位:可以通过调用链结合业务日志快速定位错误信息。
  2. 可视化:各个阶段耗时,进行性能分析。
  3. 依赖优化:各个调用环节的可用性、梳理服务依赖关系以及优化。
  4. 数据分析,优化链路:可以得到用户的行为路径,汇总分析应用在很多业务场景。


1
 

目标要求


如上所述,那么我们选择全链路监控组件有哪些目标要求呢?Google Dapper中也提到了,总结如下:


1. 探针的性能消耗

APM组件服务的影响应该做到足够小。服务调用埋点本身会带来性能损耗,这就需要调用跟踪的低损耗,实际中还会通过配置采样率的方式,选择一部分请求去分析请求路径。在一些高度优化过的服务,即使一点点损耗也会很容易察觉到,而且有可能迫使在线服务的部署团队不得不将跟踪系统关停。


2. 代码的侵入性

即也作为业务组件,应当尽可能少入侵或者无入侵其他业务系统,对于使用方透明,减少开发人员的负担。


对于应用的程序员来说,是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效,就必须需要依赖应用的开发者主动配合,那么这个跟踪系统也太脆弱了,往往由于跟踪系统在应用中植入代码的bug或疏忽导致应用出问题,这样才是无法满足对跟踪系统“无所不在的部署”这个需求。


3. 可扩展性

一个优秀的调用跟踪系统必须支持分布式部署,具备良好的可扩展性。能够支持的组件越多当然越好。或者提供便捷的插件开发API,对于一些没有监控到的组件,应用开发者也可以自行扩展。


4. 数据的分析

数据的分析要快 ,分析的维度尽可能多。跟踪系统能提供足够快的信息反馈,就可以对生产环境下的异常状况做出快速反应。分析的全面,能够避免二次开发。

2 

功能模块

一般的全链路监控系统,大致可分为四大功能模块:


1.埋点与生成日志

埋点即系统在当前节点的上下文信息,可以分为 客户端埋点、服务端埋点,以及客户端和服务端双向型埋点。埋点日志通常要包含以下内容traceId、spanId、调用的开始时间,协议类型、调用方ip和端口,请求的服务名、调用耗时,调用结果,异常信息等,同时预留可扩展字段,为下一步扩展做准备;

  • 不能造成性能负担:一个价值未被验证,却会影响性能的东西,是很难在公司推广的!
  • 因为要写log,业务QPS越高,性能影响越重。通过采样和异步log解决。

2.收集和存储日志

主要支持分布式日志采集的方案,同时增加MQ作为缓冲;

  • 每个机器上有一个 deamon 做日志收集,业务进程把自己的Trace发到daemon,daemon把收集Trace往上一级发送;
  • 多级的collector,类似pub/sub架构,可以负载均衡;
  • 对聚合的数据进行 实时分析和离线存储;
  • 离线分析 需要将同一条调用链的日志汇总在一起;

3.分析和统计调用链路数据,以及时效性

调用链跟踪分析:把同一TraceID的Span收集起来,按时间排序就是timeline。把ParentID串起来就是调用栈。

抛异常或者超时,在日志里打印TraceID。利用TraceID查询调用链情况,定位问题。

依赖度量:

  • 强依赖:调用失败会直接中断主流程
  • 高度依赖:一次链路中调用某个依赖的几率高
  • 频繁依赖:一次链路调用同一个依赖的次数多

离线分析:按TraceID汇总,通过Span的ID和ParentID还原调用关系,分析链路形态。

实时分析:对单条日志直接分析,不做汇总,重组。得到当前QPS,延迟。

4.展现以及决策支持

3 

Google Dapper


3.1 Span

基本工作单元,一次链路调用(可以是 RPC,DB 等没有特定的限制)创建一个 span,通过一个64位 ID 标识它,uuid 较为方便,span 中还有其他的数据,例如描述信息,时间戳,key-value对的(Annotation)tag信息,parent_id 等,其中 parent-id 可以表示 span 调用链路来源。

image.png

上图说明了span在一次大的跟踪过程中是什么样的。Dapper记录了span名称,以及每个span的ID和父ID,以重建在一次追踪过程中不同span之间的关系。如果一个span没有父ID被称为root span。所有span都挂在一个特定的跟踪上,也共用一个跟踪id


Span数据结构

type Span struct {
    TraceID    int64 // 用于标示一次完整的请求id
    Name       string
    ID         int64 // 当前这次调用span_id
    ParentID   int64 // 上层服务的调用span_id  最上层服务parent_id为null
    Annotation []Annotation // 用于标记的时间戳
    Debug      bool
}

3.2 Trace


类似于 树结构的Span集合,表示一次完整的跟踪,从请求到服务器开始,服务器返回response结束,跟踪每次 rpc 调用的耗时,存在唯一标识trace_id。比如:你运行的分布式大数据存储一次 Trace 就由你的一次请求组成。
image.png

每种颜色的note标注了一个span,一条链路通过TraceId唯一标识,Span标识发起的请求信息。树节点是整个架构的基本单元,而每一个节点又是对span的引用。节点之间的连线表示的span和它的父span直接的关系。虽然span在日志文件中只是简单的代表span的开始和结束时间,他们在整个树形结构中却是相对独立的。


3.3 Annotation


注解,用来记录请求特定事件相关信息(例如时间),一个span中会有多个annotation注解描述。通常包含四个注解信息:

(1) cs:Client Start,表示客户端发起请求

(2) sr:Server Receive,表示服务端收到请求

(3) ss:Server Send,表示服务端完成处理,并将结果发送给客户端

(4) cr:Client Received,表示客户端获取到服务端返回信息

Annotation数据结构

type Annotation struct {
    Timestamp int64
    Value     string
    Host      Endpoint
    Duration  int32
}

3.4 调用示例


1. 请求调用示例

  1. 当用户发起一个请求时,首先到达前端A服务,然后分别对B服务和C服务进行RPC调用;
  2. B服务处理完给A做出响应,但是C服务还需要和后端的D服务和E服务交互之后再返还给A服务,最后由A服务来响应用户的请求;

    image.png

2. 调用过程追踪

整个调用过程追踪:

  1. 请求到来生成一个全局TraceID,通过TraceID可以串联起整个调用链,一个TraceID代表一次请求。
  2. 除了TraceID外,还需要SpanID用于记录调用父子关系。每个服务会记录下parent id和span id,通过他们可以组织一次完整调用链的父子关系。
  3. 一个没有parent id的span成为root span,可以看成调用链入口。
  4. 所有这些ID可用全局唯一的64位整数表示;
  5. 整个调用过程中每个请求都要透传TraceID和SpanID。
  6. 每个服务将该次请求附带的TraceID和附带的SpanID作为parent id记录下,并且将自己生成的SpanID也记录下。
  7. 要查看某次完整的调用则 只要根据TraceID查出所有调用记录,然后通过parent id和span id组织起整个调用父子关系。

image.png

3. 调用链核心工作

  1. 调用链数据生成,对整个调用过程的所有应用进行埋点并输出日志。
  2. 调用链数据采集,对各个应用中的日志数据进行采集。
  3. 调用链数据存储及查询,对采集到的数据进行存储,由于日志数据量一般都很大,不仅要能对其存储,还需要能提供快速查询。
  4. 指标运算、存储及查询,对采集到的日志数据进行各种指标运算,将运算结果保存起来。
  5. 告警功能,提供各种阀值警告功能。


4. 整体部署架构

image.png

  1. 整体部署架构
  2. 通过AGENT生成调用链日志。
  3. 通过logstash采集日志到kafka。
  4. kafka负责提供数据给下游消费。
  5. storm计算汇聚指标结果并落到es。
  6. storm抽取trace数据并落到es,这是为了提供比较复杂的查询。比如通过时间维度查询调用链,可以很快查询出所有符合的traceID,根据这些traceID再去 Hbase 查数据就快了
  7. logstash将kafka原始数据拉取到hbase中。hbase的rowkey为traceID,根据traceID查询是很快的
相关实践学习
日志服务之数据清洗与入湖
本教程介绍如何使用日志服务接入NGINX模拟数据,通过数据加工对数据进行清洗并归档至OSS中进行存储。
目录
相关文章
|
存储 数据采集 Prometheus
【云原生监控系列第一篇】一文详解Prometheus普罗米修斯监控系统(山前前后各有风景,有风无风都很自由)(一)
【云原生监控系列第一篇】一文详解Prometheus普罗米修斯监控系统(山前前后各有风景,有风无风都很自由)(一)
1417 0
【云原生监控系列第一篇】一文详解Prometheus普罗米修斯监控系统(山前前后各有风景,有风无风都很自由)(一)
|
传感器 监控 安全
闭环反馈系统原理概述
有时,为了获得系统的一致性和稳定性并产生控制系统的期望输出,我们使用反馈回路。反馈只不过是输出信号的一部分。这个概念在控制系统中最常见和最重要,以实现输出的稳定性。根据反馈连接,控制系统分为两种类型。它们是开环控制系统和闭环控制系统。下面简单介绍下闭环反馈系统。
2888 0
闭环反馈系统原理概述
|
存储 数据采集 人工智能
如何设计一个监控平台(上篇)
在大型分布式微服务场景下,各个服务版本快速迭代,各类业务规模不断膨胀,同时监控的场景也在不断的发生变化,线上故障随时可能发生,各个平台错综复杂,如何保证线上服务稳定运行,同时提升运维效率,降低运维成本成了监控平台的挑战。
如何设计一个监控平台(上篇)
|
设计模式 安全 架构师
|
2月前
|
存储 监控 前端开发
【专栏】阿里云ARMS前端监控的引入方法,以提升应用质量和稳定性
【4月更文挑战第29天】本文介绍了阿里云ARMS前端监控的引入方法,以提升应用质量和稳定性。该工具通过实时收集和分析用户行为、性能数据,提供错误监测和实时告警。步骤包括注册阿里云账号,创建前端监控项目,获取并嵌入监控代码到页面中,部署并运行,最后查看监控数据。案例和经验分享强调了合理设置监控指标、与其他工具结合以及定期分析数据的重要性。注意保护用户隐私,正确管理监控代码,并解决可能出现的数据不准确和大量错误告警问题。
|
2月前
|
负载均衡 NoSQL 关系型数据库
性能基础之全链路压测知识整理
【2月更文挑战第16天】性能基础之全链路压测知识整理
219 11
|
XML 缓存 前端开发
【解决方案 十一】问题排查方法的思考
【解决方案 十一】问题排查方法的思考
88 0
|
Prometheus 监控 Cloud Native
【分布式技术专题】「架构实践于案例分析」盘点一下分布式模式下的服务治理和监控优化方案
【分布式技术专题】「架构实践于案例分析」盘点一下分布式模式下的服务治理和监控优化方案
205 0
【分布式技术专题】「架构实践于案例分析」盘点一下分布式模式下的服务治理和监控优化方案
|
Prometheus 运维 监控
无监控,不运维!深入浅出介绍ChengYing监控设计和使用
监控系统俗称「第三只眼」,几乎是我们每天都会打交道的系统,它也一直是IT系统中的核心组成部分,负责问题的发现以及辅助性的定位。 ChengYing作为一站式全自动化全生命周期大数据平台运维管家,自然也提供大数据产品的监控服务。这篇文章,将为大家系统性地介绍ChengYing监控的设计和使用,带大家进一步了解ChengYing。
269 0
无监控,不运维!深入浅出介绍ChengYing监控设计和使用
|
Prometheus 监控 Cloud Native
【云原生监控系列第一篇】一文详解Prometheus普罗米修斯监控系统(山前前后各有风景,有风无风都很自由)(二)
【云原生监控系列第一篇】一文详解Prometheus普罗米修斯监控系统(山前前后各有风景,有风无风都很自由)(二)
431 0
【云原生监控系列第一篇】一文详解Prometheus普罗米修斯监控系统(山前前后各有风景,有风无风都很自由)(二)