log处理
log需求主要分2种： 一个是平时给开发人员和测试人员开放实时查看的。 另外一种是用来进行存储起来进行后面的统计分析。 由于给开发和测试，他们一般都没有服务器的权限，但是又需要实时查看，毕竟有时候问题的时间日志比较好在当场表现出来，后面再去log库里查就比较麻烦了，为了解决这个问题，那就需要一个单独的日志服务器去实时收集。 同时最好是web页面去展示出来，然后可以自己定义filter。 这个需求找了一圈发现了一个叫log.io的工具，但是需要装client，而且是nodejs写的，所以还得部署一套nodejs。这个对于我们的需求是不是太重了。 我们现在所有的机器上其实都已经有fluentd了，如何利用好现在的设施是需要考虑的，我不倾向于为了实现特地目的去引入特地的工具，这样对于运维人员会更好一点，毕竟后期维护成本是必须考虑，引入一个新的工具，后面监控维护是需要一长串事情要做的。 于是最终是2个方案集合成一个方案来进行。
- fluentd-client -> fluentd-aggregation -> elastichsearch -> kinbana
- fluentd-client -> fluentd-aggregation -> file
第一种方案kibana没有很好的认证，但是我们自己写了一个基于内部认证系统的接口挂在kinbana外面，使用nginx的subrequest来进行实现。 为了保证实时性，写入es的数据都设置为缓存10秒就进行写入，后期碰到瓶颈后再调整。 同时需要修改程序的logback，所有的log都写入到同一文件中，但是日志格式需要定义好：time，application-name， log-level, msg 这样的格式去定义好，然后在es中前3个字段都进行索引，msg内容就不索引了。 每天建立一个index，为了减少数据量index就只保留最近一周的，超过一周以上的还得从文件系统内进行查。但是开发人员一般很少查一周以上的数据。 统计分析的需求。纯文本对于各种分析工具都是最友好的，而且统计分析都是实时行要求很低的，但是又要经常看整个历史趋势的。所以对于一些长期的数据是必须要有机制来进行合并汇总的。 但是单纯文本可能占用的空间比较大，我个人是倾向用gz格式进行压缩的，而不是使用bz2格式，bz2虽然压缩比更高，但是耗费cpu time可是要高3，4倍左右了，得取一个相对经济的方法来进行。