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

非链路日志（普通日志）

如果没有链路的概念，那恭喜，您正在使用普通的日志。普通的日志没有链路标识，不同请求的日志可能穿插在一起，查看的时候不太好串起来，分析日志有点点眼花缭乱。尤其是出现线上问题的时候，面对一团无序的日志，心急如焚。如果站点业务机有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一个全链路日志查询系统，在出一线上问题的时候，快速的定位出完整的业务日志，高效的排查问题。今天本想分享如果打业务日志，写着写着就变主题了，下次再找机会分析打业务日志的经验。关于日志收集系统的搭建，也是另外分享。