从架构角度来看 Java 分布式日志如何收集（Sleuth/Zipkin）

在实际工作中会发现身边的同事或者一些公司，搭建和构建日志系统的时候走了很多的弯路，有用 Logback 的有用 Log4j 的，有自定义 Aappender 改变日志格式的，有异步推送到日志系统的，有用 ELK 的，有用国内开源 Cat 的。开源的 Cloud 框架有用 Sleuth 的，有用 Zipkin 的，而也有直接用 OpenTracking 的。可能五花八门什么样的都有，作者通过这篇文章，来看一下我们生产环境的日志是如何收集的。

通过此篇 Chat 我们可以了解到如下内容：

1. OpenTracing 是什么？
2. Spring Cloud Sleuth 我们如何使用？
3. Zipkin 扮演什么角色？
4. Spring Logging 为我们做了哪些工作？
5. ELK 应该怎么样来收集我们的日志？
6. 如何利用 Sentry 独立收集异常和警告日志？
7. 一个日志系统的正确架构思想是什么？
8. 我们的生产 Framework-Logging 做了哪些工作？

我们这篇 Chat 的中心是谈谈怎么从全局来看这件事，把实战经验给大家分享一下。由于篇幅有限可能不能谈里面的实现原理，主要是实际操作，完成整体认识。

实录内容提要：

1. 目前微服务盛行，这个业务可能夸多个系统，怎样设计日志系统，在出现问题时怎样，才能快速定位不同系统间的请求是同一笔请求，例如系统间日志能否有一个统一的 ID？
2. OpenTracing 与 Zipkin 如何做选择？
3. Server ZipkinUI 和 Jaeger 如何做选择？
4. Sleuth 依赖 Filter 并配置一定的 Percentage 这样性能会成线性下降，你如何看这样的问题？在生产环境下查问题的时候才打开吗？
5. JMS 日志跟踪是如何实现的？
6. DBtracing 如何实现的？
7. 有没有代码地址可以参考？
8. 集成的时候坑有哪些？
9. 日志系统架构的本质是什么？
10. 日志级别该如何划分？
11. 架构师最重要的素质是什么？
12. 阿里有对 Java 日志部分做约束吗？

阅读全文: http://gitbook.cn/gitchat/activity/5aeb13c1bba5bc30cda8303f

您还可以下载 CSDN 旗下精品原创内容社区 GitChat App ，阅读更多 GitChat 专享技术内容哦。