我正在参加「掘金·启航计划」
一、案例
某系统刚从传统部署方式转换到微服务，迁移后发现原本将日志打印在到文件中，然后使用ELK进行日志收集和分析的方式无法在微服务中使用。这种方式相对来说比较随意，没有统一的规范，因此在线上系统出现异常时，要排查出具体问题的话是一个很困难的事情。基于这个问题，我们需要把日志规范化，要实现规范化就要从如下五个需求入手：
- 记录什么时候调用了中间件，耗时多久；
- 记录什么时候调用了数据库，执行的SQL是什么，耗时多久；
- 记录什么时候调用了其他服务，是哪个服务，调用的方法是哪个，耗时多久；
- 将同一个服务的以上三种记录全部进行串联，形成一个树形记录；
- 设计查询记录的功能。
二、使用何种技术
进行记录选型时我们要遵循如下5个原则：
- 日志数据结构支持 OpenTracing；
- 支持ES作为存储系统；
- 日志收集对性能几乎无影响；
- 有丰富的查询统计功能；
- 有多少项目在使用
下面分别讲解以下这五个原则。
2.1 日志数据结构支持 OpenTracing
日志一般我们都是独立记录的，然后通过线程ID将这些日志关联起来，因此我们需要一个可以将同一个请求的所有日志都连接在一起的数据结构，目前较为常用的是OpenTracing。它提供一个和平台/厂商无关的API，开发人员可以很方便的将追踪系统添加进来，后期如果要更换别的追踪系统的话也是很方便的。具体OpenTracing的使用可以参考官方文档，在这里不再讲解。
Tip：在技术选型时要保证系统的可替代性，尽量不要束缚于某个技术上。
2.2 支持ES作为存储系统
由于流量很大，因此会出现日志数据量也很大，那么这就要求存储日志的系统必须支持海量数据的存储和保证查询的效率，目前较为常用的就是Elasticsearch，技术方案较为成熟的也是Elasticsearch，因此存储系统要支持ES。
2.3 日志收集对性能几乎无影响
在服务记录日志时，要保证日志的记录和手机对服务器的性能几乎不会产生影响。
2.4有丰富的查询统计功能
查询功能不仅仅是越多越好，还要有这几个基本要求必须满足 ：
- 支持每个请求树形结构的全链路日志；
- 具备监控报警功能；
- 具备指标统计功能；
- 对业务代码的侵入性小；
- 二次开发成本小。
2.5 有多少项目在使用
技术选型时要了解有多少知名公司在使用该技术，这是因为大公司的业务场景都很复杂，相关技术的问题会被很快的暴露出来，并且也能够被很快的修复。
三、总结
这篇文章比较简单，主要说明了全链路日志系统的技术选型方法，一般来说常用的全链路日志系统是SkyWalking，关于这个系统的讲解，我将会专门写一篇文章来讲解。
