日志系统引起的争论

 

年前了事情还是有一大堆。最近我一直在思考“写代码”这事，如何摆脱小作坊、小玩具式的开发。如何能少走弯路、避免做无用功。

老板给提的建议是做事情要注重以下几点：

预见性：提前对项目作出预估、提前预见困难和陷阱。

计划性：计划和安排好达到目标的每一步。

执行力：任何事情都要有deadline，在规定的时间里完成规定的任务，并能对结果进行验证。

 

日志系统小到System.out.println，大到要使用hadoop等分布式文件系统存储都是项目中必不可少的一个模块。一个项目的日志系统要做到什么样的程度与项目本身的需求密切相关。如果是只想在编码期间看下程序运行是否正常，逻辑是否OK，直接用printl就能解决；稍微大些使用log4j，可以分级别记录日志。

现在做的一个项目中需要收集客户端的一些操作日志并进行分析展示，所有的日志都通过http的方式上传到服务器。在如何处理和存储上不同的人有了不同的看法。

一些人建议按用户、日期生成文本文件存在指定目录，另一些人建议在数据库中使用大字段存储。这两种方法都是处理日志的可行方法，但各有优缺点：

按用户、日期生成文本文件一方面不利于查看、不利于统计、另一方面也难以管理。

直接存到统计数据库则效率低下、浪费过多的表空间、在不进行优化处理的情况下数据查询也比较困难（尤其针对大字段内容的检索）、在用户量大的情况下严重影响数据库性能。

 

进一步考虑，系统规模增大的情况下日志的处理会面临以下问题：

1．初始的日志存储位置分散：多台应用服务器产生的日志位置分散

2．需要记录的日志格式不一致：针对应用功能的不同，日志信息的侧重点不同格式多样

3．需要统计的信息点不同：同一批日志数据，统计时的关注点也可以不同

4．存储量大

5．写频繁对服务器压力大

6．日志合并面临的排序、去重

7．日志备份

针对以上几点，最好的处理方法就是建立独立的日志系统。

以淘宝的日志系统为例：

淘宝后台系统有大量的应用服务器，每天处理海量的应用，同样会产生海量的日志信息。所以其内部开发了专门的队列服务器TT，并在所有的应用服务器上布署client端负责收集日志发送到TT中。后台日志的存储备份则使用hadoop集群实现，数据的统计则使用hive进行。

所以整体的架构应该是这样：