从简单日志到全链路日志 我们应该怎么打日志

自从团队自研全链路日志系统上线后,一直想分享一下本人对日志系统的一些感受与记得,今天正好是周未,仔细回想了一下有关日志的点滴,因为涉及到全链路日志的概念,由于我打算从非全链路日志(普通)到全链路的演化路线做一次分析,就打日志关系的一次业务问题做一些简单的案例剖析。请搬个小凳子,开场了。

非链路日志(普通日志)

如果没有链路的概念,那恭喜,您正在使用普通的日志。普通的日志没有链路标识,不同请求的日志可能穿插在一起,查看的时候不太好串起来,分析日志有点点眼花缭乱。尤其是出现线上问题的时候,面对一团无序的日志,心急如焚。如果站点业务机有10台,定位日志的范围,也成为一个不太愉快的时候。若是多线程的服务日志,日志穿插得眼花缭乱。非链路日志(普通日志)在实时排查问题的过程中,存在的最大问题就是定位分析问题,简单的示例如下图,日志穿插在一起,不易分析同一个请求的情况。

我收到一个请求,参数是
我收到一个请求,参数是
我收到一个请求,参数是
我收到一个请求,参数是
我收到一个请求,参数是
用户账号BBB未认证

单链路日志

当我看到有同事使用GUID将日志请求串在一起的时候,我就这应该算是单链路日志了。站点的单次请求或服务的业务操作日志能够很好的被标识出来,在分析日志的时候,需要搜索同GUID的日志,请能定位到一个请求或作业的日志,不用提心其他日志的干扰。单链路日志对于分析单个站点或单个服务的日志情况,还是很有帮忙。我们已经能从日志中挑出日志,专注于重点日志。

请求3fba452e-d9c9-45ee-96cb-19280fa59673 我收到一个请求,参数是
请求b3a45dec-7667-4822-b7b9-7db1eec11a8b 我收到一个请求,参数是
请求3e2f3851-9491-4f97-a47c-53d1001278ba 我收到一个请求,参数是
请求6180a2f7-d9bf-4612-9d23-c5e6d46a079d 我收到一个请求,参数是
请求26a9d771-f2f3-47fa-b810-d3071a1d98ca 我收到一个请求,参数是
请求3fba452e-d9c9-45ee-96cb-19280fa59673 用户账号BBB未认证

全链路日志

全链路日志在单链路日志的基础上进行跨站点,跨服务逻辑的日志追踪。分我们排查问题的时候,往往是一个完整业务排查,不单是涉及一个站点的,可能需要顺藤摸瓜,一点一点回溯。单链路日志 对此就无能为力了。所以引身出了全链路日志,我们需要为每个完整的请求分配一个追踪id,称之为TraceId,这个追踪id将在业务站点间流转,将业务日志串起来。当我们查看日志的时候,可以完整得看到业务日志的流转明细。同样的道理,服务日志在入口处,也将分配一个完整的TraceId,标识出完整的日志。

站点A
TaceId 2ad28f58-858c-47c0-8875-e2e9db4ff24b 请求3fba452e-d9c9-45ee-96cb-19280fa59673 我收到一个请求,参数是
TaceId 2ad28f58-858c-47c0-8875-e2e9db4ff24b 请求3fba452e-d9c9-45ee-96cb-19280fa59673 用户账号BBB未认证

站点B
TaceId 2ad28f58-858c-47c0-8875-e2e9db4ff24b 请求3fba452e-d9c9-45ee-96cb-19280fa59673 用户账号检查

针对于全链路日志,我们应该采用TraceId将跨站点的日志打上标记,对服务内部的日志转流也同样的道理。通过GUID标记好的日志,可以通过日志收集系统,FileBeat抓取到Kafka,LogStash从Kafka消费送到ES,我们DIY一个全链路日志查询系统,在出一线上问题的时候,快速的定位出完整的业务日志,高效的排查问题。今天本想分享如果打业务日志,写着写着就变主题了,下次再找机会分析打业务日志的经验。关于日志收集系统的搭建,也是另外分享。

此条目发表在未分类分类目录。将固定链接加入收藏夹。

发表评论

电子邮件地址不会被公开。 必填项已用*标注