日志采集
日志是线上服务的刚需，用于排查问题分析数据，特点是写入量大、允许一定丢失、断网也要可以写入（比如写入一些网络异常日志）
所以日志一般是写到本地磁盘中，写入时为了减少IO，一般都是先缓存一个内存桶中，比如每积累100k写入一次磁盘
如果是在单机上，一般的日志框架已经足够使用，用于常用的linux命令查找日志问题足以
但是分布式服务环境下，因为机器较多，不可能登录到每台机器上去查找问题，尤其是那种同一个用户操作，要根据uid查找行为链路的时候
可能有人会想配置同一个用户操作路由规则总是落到一台机器上是不是可以解决
但是这带来了3个问题：单机故障后这个用户所有操作都挂了、横向扩展后用户的日志就可能又路由到另一台机器了、不是所有的方法都有uid参数，路由维度可能有多个：设备id、ip、uid等
所以这只会把问题搞复杂。
更简单的方式是还是保持原有负载均衡路由与本地日志的策略，通过一个日志采集程序到统一日志管理平台
然后通过统一的日志查询平台查询所有机器日志，这样还附带了很多好处，比如日志归档，本地日志可以保留更短时间
隔离程序员登录大命令的时间，直接可视化操作，筛选统计更方便，同时还能有权限控制，图表等功能扩展
所以这就是日志采集一整套东西，现在互联网流行的一套叫做ELK
ELK
ELK(Kibana)
Kibana不好的地方在于日志查询不能像grep那样查看上下多行信息，也就是上下文信息，不过最新的版本好像有这个功能了
