随着业务量的增长,服务器的增长,同时应用日志的数量也是呈现几何的速度增长。大部分人的认为日志数据对业务来说只是开发人员排除故障的依据,除此以外对业务而言是没有任何的意义的。我相信,对很多人的认知来说日志也就那么点的作用。不可或缺,但是也是很鸡肋。需要它的时候,迫不及待,不需要它的时候弃之如敝履。
点
) 面
) 到目前为止,参照我们系统( 某上市互联网保险中介 )应用,就日志而言,我们经历了以下几个时间段的变化,也经历很多方面的尝试。就目前我们的应用日志系统经历了以下的变化:
st=>start: 原生时代
e=>end: 自研平台
op=>operation: syslog-ng
op1=>operation: nfs共享
op2=>operation: splunk
op3=>operation: log.io日志系统
op4=>operation: elk
op5=>operation: flume
st->op->op1->op2->op3->op4->op5->e
使用对比
前置环境:
服务器数量: 40 + 应用容器类型: tomcat/resin/php等 日志大小: 500M > size < 5G 环境: 集群环境
需求调研
目前在行业内日志处理方案,有开源的,也有商业级别,也可以自行开发。至于你要选择什么解决方案,完全要依赖于你的业务需求和环境,如果你有更加高的要求的日志要求,且对费用没什么担心,商业版本的日志解决方案无疑是最佳的解决方案。如果你的资产投入有限,或者想自定义日志的系统,开源或者自研也是可以的。选择最合适业务,然后去调研、测试,来最贴近你的业务需求。