高并发系统实战课
徐长龙
前微博架构师、极客时间架构师
11663 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 30 讲
结束语&结课测试 (2讲)
高并发系统实战课
15
15
1.0x
00:00/00:00
登录|注册

11|链路追踪:如何定制一个分布式链路跟踪系统 ?

可以通过前缀有几个分隔符判断日志所在层级
记录请求方日志
优点
层级计数器实现
通过整理span之间的依赖关系组合成调用链路树
记录上游依赖服务的SpanID
个性定制表格查询(Kibana)
实时分析(Kibana)
检索计算(Elasticsearch + Kibana)
日志存储(Elasticsearch)
日志传输(Kafka+Logstash)
日志收集(Filebeat)
标准(集成了OpenCensus、OpenTracing标准)
Metrics+Tracing+Logging集成
Logging
Tracing
Metrics
思考题
ELK的流行
系统监控的重要性
改造分级日志
SDK的重要性
日志缓存技巧
长内容写入日志的注意事项
提高写线程的个数
样例
JSON格式
分级日志类型
Metric日志类型
日志类型
传递TraceID和RPCID(或SpanID)的方式
RPCID方式
span实现
日志足够详细的重要性
生成并传递TraceID
ELK提供的功能
系统警告
个性化定制指标盘
分布式实时分析
分布式检索计算
分布式日志存储
分布式日志传输
日志收集
埋点SDK
监控日志标准
三位一体的标准
常见监控系统类型
监控行业的大革新
总结
"侵入式埋点SDK"VS"AOP方式埋点"
日志写吞吐能力提高技巧
日志格式样例
日志类型定义
"RPCID" VS "SpanID 链路标识"
TraceID单次请求标识
使用ELK实现分布式链路跟踪
分布式链路跟踪系统提供的支撑服务
监控行业发展现状
作者: 徐长龙
链路追踪:如何定制一个分布式链路跟踪系统

该思维导图由 AI 生成,仅供参考

你好,我是徐长龙,这节课我们讲一讲如何实现分布式链路跟踪。
分布式链路跟踪服务属于写多读少的服务,是我们线上排查问题的重要支撑。我经历过的一个系统,同时支持着多条业务线,实际用上的服务器有两百台左右,这种量级的系统想排查故障,难度可想而知。
因此,我结合 ELK 特性设计了一套十分简单的全量日志分布式链路跟踪,把日志串了起来,大大降低了系统排查难度。
目前市面上开源提供的分布式链路跟踪都很抽象,当业务复杂到一定程度的时候,为核心系统定制一个符合自己业务需要的链路跟踪,还是很有必要的。
事实上,实现一个分布式链路跟踪并不难,而是难在埋点、数据传输、存储、分析上,如果你的团队拥有这些能力,也可以很快制作出一个链路跟踪系统。所以下面我们一起看看,如何实现一个简单的定制化分布式链路跟踪。

监控行业发展现状

在学习如何制作一个简单的分布式链路跟踪之前,为了更好了解这个链路跟踪的设计特点,我们先简单了解一下监控行业的现状。
最近监控行业有一次大革新,现代的链路跟踪标准已经不拘泥于请求的链路跟踪,目前已经开始进行融合,新的标准和我们定制化的分布式链路跟踪的设计思路很相似,即 Trace、Metrics、日志合并成一套系统进行建设。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了如何设计一个简单的分布式链路跟踪系统,通过结合ELK特性,实现全量日志的分布式链路跟踪,以降低系统排查难度。作者指出了Metrics、Tracing和Logging三种监控系统的优缺点,并提出了集成这三种系统的标准。建议使用ELK提供的功能来实现分布式链路跟踪系统,并详细介绍了TraceID单次请求标识的生成和传递原理。通过对具有相同TraceID的日志进行收集和分析,可以监控系统的工作状态,分析项目之间的调用关系,快速查找问题等。此外,文章还介绍了RPCID和SpanID两种链路标识的区别,以及日志类型定义和格式样例。文章还提供了一些技巧,如提高日志写吞吐能力的注意事项和技巧。总的来说,本文为读者提供了实现分布式链路跟踪系统的思路和方法,以及相关技术特点和实际应用场景。文章内容丰富,对于需要了解分布式链路跟踪系统的读者具有很高的参考价值。文章还探讨了ELK实现Trace的简易性,以及当年实现难度的原因,为读者提供了深入思考的空间。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《高并发系统实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(2)

  • 最新
  • 精选
  • 👽
    请教一下,TraceID 是什么时候生成的呢?单体服务的时候,我们是filter层生成。微服务的话,因为起始服务是不确定的,应该在哪一步生成呢?我的初步构思实在网关层,比如spring cloud gateway这一层注入一个,然后每个组件依次传递。 不过也有别的问题,就是比如定时任务之类的系统自发的请求链路应该如何生成呢?

    作者回复: 发起请求方生成,这个不用集中服务生成,因为很多客户端是离线的,然后如果收到的请求没有 traceid 那么收到请求的网关生成,最后脚本 traceid ,如果是数据处理,一次大循环一个,如果小任务就用一个 traceid

    2023-04-07归属地:广东
    1
  • John
    老师,我有个疑问想请教下,未来的趋势是使用open telemetry 规范来使用Metric / Tracing /Logging? 那么ELK 遵循了open telemetry 规范?两者之间是什么关系呢

    作者回复: 你好,John,很高兴收到你的提问,open telemetry目前是个新标准计划对三者进行统一,目前各个开源正在积极的在往这个标准靠拢合并,目前还在建设阶段。ELK是个支撑服务包含了数据存储、传输、计算、统计的功能,不过他需要我们人工做一些统计工作来实现数据分析,可以说他是一个日志平台,我们可以根据需要对存储的数据进行加工整理,目前ot的标准和他关系不大

    2022-11-20归属地:北京
收起评论
显示
设置
留言
2
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部