前言:
现在用的是日志易的产品,通过traceId能够查出所有链路上的日志,用是会用了,但确实对这是怎么实现的,没有了解过。今天也算是补下这块的内容,避免一问三不知的情况
日志
通过日志,可以查询到一笔交易涉及到的所有关联系统,它们各自的交易耗时,又可以通过traceId【全局唯一ID】+parentId【父系统ID】or SPANID【各系统自ID】 查出相应日志,基于这种能做消息的收集、分析,日志告警等。
全链路日志
全链路的相关原理大都基于论文《Google Dapper》的描述,有兴趣的可以翻阅下
组成模块
以下模块按实际需求选择相应的模块替代即可
模块名 | 含义 |
---|---|
全局traceId | 既然要做到查询每一笔交易的完整链路,那么它们的traceId就不肯定不能共用的,这一块就涉及到了如何高效生成全局ID的问题,这块可以参考雪花算法等实现方式 |
SpanId | 作为基本工作单元,交易链路上的每个子环节,都生成自己的SpanId作为唯一标志 |
parentId | 记录父节点,相当于链表的prev节点了 |
存储以及检索 | 日志的存储,以及快速检索方式(ES集群存储traceId节点,Hbase存储基础数据与traceID的关系) |
日志的收集以及清洗 | logstash插件等 |
消息队列的选用 | kafka |
调用链路
埋点
从服务端划分
- 服务端
- 客户端
- 服务端和客户端双向
从服务上
- rpc
- HTTP
实现上,在收到请求报文时,先通过拦截请求,在前置统一切面上做traceId的透传、spanId生成等内容,照常打印日志即可。
收集日志
- collector
- 按服务、应用级别分级收集日志
- 集群收集,经logstash处理后发往kafka处理
分析日志上
- traceId全局唯一,用traceId可查到一笔交易所有日志信息,通过parentId可以查到各系统具体的请求指标,可以做各系统交易链路耗时的分析,实现告警,服务降级、熔断等操作。收集出来的日志,按span排序后即为交易的timeline,便于排查问题