应用的日志分析、对比以及实践

前言

随着业务量的增长,服务器的增长,同时应用日志的数量也是呈现几何的速度增长。大部分人的认为日志数据对业务来说只是开发人员排除故障的依据,除此以外对业务而言是没有任何的意义的。我相信,对很多人的认知来说日志也就那么点的作用。不可或缺,但是也是很鸡肋。需要它的时候,迫不及待,不需要它的时候弃之如敝履。

作用

  • 常见作用: 排问题,查日志(
  • 日志记录代码的执行记录,记录异常信息,排查代码的隐藏bug
  • 记录业务逻辑,查询业务上的问题或者追踪相关信息
  • 非常见作用: 数据分析(
  • 根据错误日志的错误处,统计错误率,针对性的对代码进行优化
  • 根据时间轨迹,可以统计出业务的集中时间和接口调用次数等统计
  • 统计用户业务轨迹
  • .......更多的数据价值待挖掘,比如从日志中统计用户类型、用户访问习惯、用户停留时间、用户的等待时间等等各个方面,针对性的优化应用,提升用户的访问体验。

变化

到目前为止,参照我们系统( 某上市互联网保险中介 )应用,就日志而言,我们经历了以下几个时间段的变化,也经历很多方面的尝试。就目前我们的应用日志系统经历了以下的变化:

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
  • 原生时代

    描述: 早期的终端原生时代,由于业务和服务器的规模不是很大,针对应用的日志并没有做相应的的处理和优化。都只是应用容器本身的日志处理,开发需要看日志就去对应的服务器上看相应的日志。比如tomcat下自由log4j下的catalina.out等等。

    特点: 方便,对开发相对友好,因为在自己的PC开发环境中,开发更加习惯在文本或者终端查看日志。但是在linux平台下查看应用日志,需要具体的一定的Linux日志命令的相关基础知识,如tail、awk等

  • nfs共享

    描述: 随着业务规模的增加,服务器的数量增长,应用日志的数量也在增加。通常一个业务还有7到8个集群节点的日志,这时候如果还是采用的原生时代的日志查看方式会显得的很费力。查一个日志可能要登陆10多个终端在日志当中去排除问题。所以在这时候的我们考虑将日志归集到一起,这样就避免了开多个服务器去看日志的问题。

    特点: 相对于原生时代来说,其实没有发生了什么变化。只是不需要登陆多个服务器,只登陆一台服务器就能看到所有服务器的日志。

  • splunk

    描述: 这是一款商业的日志系统,集合日志收集、处理、分析等一体的日志解决方案。当日志文件超过500M就要收费的。但就它的功能而言,各方面的表现都非常不错的。web可视化,日志异常,资源占用率等很不错。唯一的是,基于当时的业务情况并不适合在日志收集去投入额外的资产支出,所以后续就放弃了。

    特点: 采用CS结构,各方面的都比较优秀。

  • log.io日志系统

    描述: 这是一款开源的实时日志系统,它只实时显示日志,并不对日志做存储。也是C/S结构,采用node的语言编写而成。

    特点: 采用CS结构,小巧易于使用。

  • elk

    描述: 这是一款开源的集中式日志系统,也是目前很多互联网公司主推的开源日志系统。ELK 其实并不是一款软件,而是一整套解决方案,是三个软件产品的首字母缩写,Elasticsearch,Logstash 和 Kibana。从日志收集、聚合、全文搜索、展现等拥有一套完整的解决方案。社区和文档也比较完善,可以进行自定义二次开发。

    特点: 采用CS结构,功能强大。

  • flume+其他

    描述: 这是一款开源的日志收集的解决方案,并不对日志进行分析,flume是一个高可用的,高可靠的,分布式的海量日志采集、聚合和传输的系统。通过与kafka等结合做日志解决方案。 特点: 采用CS结构,可扩展性强,存储丰富比如HDFS.

  • 自研平台

    描述: 综合业务等个方面的特点自定义的开发日志系统。 特点: 自主性强、适合业务的可持续性扩展。

使用对比

调研

前置环境:

服务器数量: 40 + 应用容器类型: tomcat/resin/php等 日志大小: 500M > size < 5G 环境: 集群环境

需求调研

  1. 方便开发人员查询日志,排除故障
  2. 不占用系统资源,一般日志系统采用C/S结构,客户端的资源占用率必须保障在3%以下
  3. 扩展性强,易于进行二次开发

总结

目前在行业内日志处理方案,有开源的,也有商业级别,也可以自行开发。至于你要选择什么解决方案,完全要依赖于你的业务需求和环境,如果你有更加高的要求的日志要求,且对费用没什么担心,商业版本的日志解决方案无疑是最佳的解决方案。如果你的资产投入有限,或者想自定义日志的系统,开源或者自研也是可以的。选择最合适业务,然后去调研、测试,来最贴近你的业务需求。

results matching ""

    No results matching ""