接口监控
- 心跳
- 第三方服务 阿里云 监控宝 easyApi。
- 开源工具 运维监控平台 zabbix、开源项目二次开发 HeartBeat(java)。
链路追踪
请求链路追踪,故障快速定位:可以通过调用链结合业务日志快速定位错误信息。 可视化: 各个阶段耗时,进行性能分析。 依赖优化:各个调用环节的可用性、梳理服务依赖关系以及优化。
-
功能模块
-
埋点请求和日志生成 客户端看要不要做什么上报处理,而且还要生成traceId。上报一条日志,日志要包含以下内容name、traceId、spanId、调用时间、信息、(parent_id)等。。异步log处理。也可以不异步。 需要一个独立的非项目内的独立log存放日志 ,定期清理日志,运维是跑不了了
-
收集和存储日志
肯定是logstash对日志进行分析,并且输出。es 也罢 , kafka 也罢 -
分析和统计调用链路数据 调用链跟踪分析:把同一TraceID的Span收集起来,按时间排序就是timeline。把ParentID串起来就是调用栈。 抛异常或者超时,在日志里打印TraceID。利用TraceID查询调用链情况,定位问题。 离线分析:按TraceID汇总,通过Span的ID和ParentID还原调用关系,分析链路形态
-
Google Dapper
Span
上图说明了span在一次大的跟踪过程中是什么样的。Dapper记录了span名称,以及每个span的ID和父ID,以重建在一次追踪过程中不同span之间的关系。如果一个span没有父ID被称为root span。所有span都挂在一个特定的跟踪上,也共用一个跟踪id。Span数据结构:
Span {
trace_id int // 用于标示一次完整的请求id
span_id int // 当前这次调用span_id
parent_id int // 上层服务的调用span_id 最上层服务parent_id为null
msg st ring // 信息
timestamp int // 用于标记的时间戳
name string // 名称
}
示例
- 请求调用示例
- 当用户发起一个请求时,首先到达前端A服务,然后分别对B服务和C服务进行RPC调用;
- B服务处理完给A做出响应,但是C服务还需要和后端的D服务和E服务交互之后再返还给A服务,最后由A服务来响应用户的请求;
- 请求调用示例
- 请求到来生成一个全局TraceID,通过TraceID可以串联起整个调用链,一个TraceID代表一次请求。
- 除了TraceID外,还需要SpanID用于记录调用父子关系。每个服务会记录下parent id和span id,通过他们可以组织一次完整调用链的父子关系。
- 一个没有parent id的span成为root span,可以看成调用链入口。
- 所有这些ID可用全局唯一的int表示;
- 整个调用过程中每个请求都要透传TraceID和SpanID。
- 每个服务将该次请求附带的TraceID和附带的SpanID作为parent id记录下,并且将自己生成的SpanID也记录下。
- 要查看某次完整的调用则 只要根据TraceID查出所有调用记录,然后通过parent id和span id组织起整个调用父子关系。
第三方服务 阿里云
开源
Skywalking 、Pinpoint、Zipkin