在实际工作中会发现身边的同事或者一些公司,搭建和构建日志系统的时候走了很多的弯路,有用 Logback 的有用 Log4j 的,有自定义 Aappender 改变日志格式的,有异步推送到日志系统的,有用 ELK 的,有用国内开源 Cat 的。开源的 Cloud 框架有用 Sleuth 的,有用 Zipkin 的,而也有直接用 OpenTracking 的。可能五花八门什么样的都有,作者通过这篇文章,来看一下我们生产环境的日志是如何收集的。
通过此篇 Chat 我们可以了解到如下内容:
- OpenTracing 是什么?
- Spring Cloud Sleuth 我们如何使用?
- Zipkin 扮演什么角色?
- Spring Logging 为我们做了哪些工作?
- ELK 应该怎么样来收集我们的日志?
- 如何利用 Sentry 独立收集异常和警告日志?
- 一个日志系统的正确架构思想是什么?
- 我们的生产 Framework-Logging 做了哪些工作?
我们这篇 Chat 的中心是谈谈怎么从全局来看这件事,把实战经验给大家分享一下。由于篇幅有限可能不能谈里面的实现原理,主要是实际操作,完成整体认识。
实录内容提要:
- 目前微服务盛行,这个业务可能夸多个系统,怎样设计日志系统,在出现问题时怎样,才能快速定位不同系统间的请求是同一笔请求,例如系统间日志能否有一个统一的 ID?
- OpenTracing 与 Zipkin 如何做选择?
- Server ZipkinUI 和 Jaeger 如何做选择?
- Sleuth 依赖 Filter 并配置一定的 Percentage 这样性能会成线性下降,你如何看这样的问题?在生产环境下查问题的时候才打开吗?
- JMS 日志跟踪是如何实现的?
- DBtracing 如何实现的?
- 有没有代码地址可以参考?
- 集成的时候坑有哪些?
- 日志系统架构的本质是什么?
- 日志级别该如何划分?
- 架构师最重要的素质是什么?
- 阿里有对 Java 日志部分做约束吗?
阅读全文: http://gitbook.cn/gitchat/activity/5aeb13c1bba5bc30cda8303f
您还可以下载 CSDN 旗下精品原创内容社区 GitChat App ,阅读更多 GitChat 专享技术内容哦。