log需求主要分2种:

一个是平时给开发人员和测试人员开放实时查看的。

另外一种是用来进行存储起来进行后面的统计分析。

 

由于给开发和测试,他们一般都没有服务器的权限,但是又需要实时查看,毕竟有时候问题的时间日志比较好在当场表现出来,后面再去log库里查就比较麻烦了,为了解决这个问题,那就需要一个单独的日志服务器去实时收集。

同时最好是web页面去展示出来,然后可以自己定义filter。

这个需求找了一圈发现了一个叫log.io的工具,但是需要装client,而且是nodejs写的,所以还得部署一套nodejs。这个对于我们的需求是不是太重了。

我们现在所有的机器上其实都已经有fluentd了,如何利用好现在的设施是需要考虑的,我不倾向于为了实现特地目的去引入特地的工具,这样对于运维人员会更好一点,毕竟后期维护成本是必须考虑,引入一个新的工具,后面监控维护是需要一长串事情要做的。

于是最终是2个方案集合成一个方案来进行。

  1. fluentd-client -> fluentd-aggregation -> elastichsearch -> kinbana
  2. 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倍左右了,得取一个相对经济的方法来进行。

Share Your Thought