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 较为
评论0
最新资源