接口监控和链路追踪

1,562 阅读3分钟

接口监控

  • 心跳
  • 第三方服务 阿里云 监控宝 easyApi。
  • 开源工具 运维监控平台 zabbix、开源项目二次开发 HeartBeat(java)。

链路追踪

请求链路追踪,故障快速定位:可以通过调用链结合业务日志快速定位错误信息。 可视化: 各个阶段耗时,进行性能分析。 依赖优化:各个调用环节的可用性、梳理服务依赖关系以及优化。

  • 功能模块

    1. 埋点请求和日志生成 客户端看要不要做什么上报处理,而且还要生成traceId。上报一条日志,日志要包含以下内容name、traceId、spanId、调用时间、信息、(parent_id)等。。异步log处理。也可以不异步。 需要一个独立的非项目内的独立log存放日志 ,定期清理日志,运维是跑不了了

    2. 收集和存储日志
      肯定是logstash对日志进行分析,并且输出。es 也罢 , kafka 也罢

    3. 分析和统计调用链路数据 调用链跟踪分析:把同一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 // 名称
}

示例

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

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

第三方服务 阿里云

开源
Skywalking 、Pinpoint、Zipkin