日志分析与我之缘

日志分析与我之缘

——日志分析(new-access-log)项目开发的总结

日志分析是我接触比较深的，从开始项目经理提出需求，评审，相关主管构思其可行性，并对实现其功能所需的技术进行布线，我都有所参与。

那时才参加工作不久，项目经验严重不足，对于主管开发任务的描述，我理解的似是而非，总是在开发中摸索，在摸索中前行。当时一心完成主管安排的任务就行，没有什么执行效率、性能优化等概念，对于开发中会出现的问题也没有一个清晰的认识，在领导的推动中，我浑浑噩噩的完成了这项开发任务。

总得来说，我的任务是完成模块访问统计和用户模块访问统计，遇到了几个承需解决的问题：

1.访问URL的子父级关系的递归叠加；

2.访问URL对带参数的URL的同一URL和子父级关系之间的界定定义；

3.大规模操纵数据库，对数据库的影响，以及如何合理的使用CPU资源。

这几个问题在磕磕绊绊中解决了，其中大规模操纵数据库，任务线程池的使用，使系统CPU资源得到大规模提高，但是在更多时候，压力集中于数据库，数据库并发激增，仍然存在。

随后我担任日志分析的运维，进行CMP和商用车亲情服务的日志分析，给其季度报告提供一定的数据支持。在此过程中，又陆陆续续发现一些问题:

1.在整个分析过程中，主要压力集中于数据库，在高峰期，数据库的CPU使用率达到700%(8核CPU);

2.在应用流量统计中，需要读取并运行awstats的配置文件，由于多线程运行，该文件被第一个进行的线程占用，导致其他线程访问该文件，会报出此文件不存在的异常；

3.在CMP日志分析中，由于模块映射表中定义的URL是一些URL的父级URL，而这些父级URL本身又不是页面，所以其页面停留时间统计的没有任何数据，一度以为是生成环境的日志分析项目出现问题，经过梳理才发现其问题根源；

4.通过awstats分析日志，该软件对日志的分析能力有一定的限制，即只能分析一个节点固定一天的日志，而CMP有八个节点，会产生八份日志，所以其统计的数据仅仅只是真实数据的1/8。

随着业务的调整，一次性上传大量的日志文件，需要耗费大量的时间，从节约人力成本的角度出发，对日志分析进行一定程度的升级更新，最大程度的节约运维的人力成本。其相关功能最大的改变就是由人力上传日志文件然后分析，变成现在的定时从挂载的日志文件机器上读取文件，然后分析，考虑到会出现一些异常，增加一段时期内的日志分析和日志分析出现异常后的强制分析。

在主管提出相应需求之后，我和同事编写了<《日志分析升级更新》概要设计说明书>,在主管确认之后，我将概要设计说明书以及以前日志分析的完整项目发给业务方，让其进行开发，我负责联系跟进，在一定程度上扮演着项目经理的角色，虽然这是一个很小的项目。

在负责跟进此项目时，由于经验严重欠缺，对于项目开发遇到问题的复杂性没有一个清晰的认识，导致出现了很多错误，对项目开发的进度、项目的部署都产生了很大程度上的消极影响。

遇到的问题主要有：

1.在沟通过程中，针对某一问题，临时安排业务方按照要求去做，没有形成文档或者保留文字性资料，导致其忘记，造成其业务过错的推诿；

2.在开发过程中，针对某一里程碑事件，没有较为清晰的定义，没有进行合理的规划，放羊式的项目管理导致开发进度拖沓；

3.在项目的审查上，没有进行严格的阶段性的项目验收，在没有看到其开发成果的前提下，只听其描述就认为其完成了相应的开发任务，结果在项目最终的测试中，开发过程中的问题井喷式爆发，在很短时间内，出现超过20个较为严重的bug；

4.对于项目验收没有进行比较清晰的定义，只是依着感觉，可以接受就让其合格，没有一个可行性文字描述性的标准。

在部署运行之后，仍然出了一定的问题，由于需要记录每批次日志分析的结果，需要将之前的多线程运行应用改为单线程应用线程，而单线程对于数据库持续操作，分析三天(3*8)的日志24小时之内都不能完成。随后考虑引入缓存机制，尽量减少数据库压力，同一批次的分析结果，暂时存入缓存，在分析结束后，一次性存入数据库中。

目前，正在调试其各项性能，有几个变量，本地缓存、远程缓存、入库的时机选择、定时调度的执行频率等几个事件的组合。目前在使用的是只使用本地缓存+每天的日志分析结束后入库(8个日志)+定时调度日志分析频率为没两天一次。

这个选择充分考虑了性能优化，适用节约的特征，由于分析本地的日志没有远程的调用，只使用本地缓存就可以满足要求，缓存中数据量越大，缓存的读取耗时越长，考虑到这一因素，将之前的同一批次的一次性入库改为一天的日志一次性入库，这样可以加快缓存中读写的速率，CMP7天归档一次，考虑其日志规模，大致在两天的时间可能分析完毕。

目前，该项目处于部署调试阶段，估计还是陆续出现问题，勤记录，多思考，善于总结分析，善于在复杂的环境中找到解决问题的关键，争取较大的发展。