如何解决日志管理？

一个稍大一点的系统，通常就需要考虑内嵌一个日志系统，无论这个系统是多么精简，至少能给开发人员定位问题。而常用的方法无过于使用控制台的printf和文件记录fwrite函数。
 
 
在一个大型系统中，日志该如何管理，当系统运行n天后，发现了一个BUG，难道要去控制台截取printf打印？生成一个巨大的日志文件吗？是这么做的吗？可行吗？这个问题的答案是非常明显的，我们不能用printf来做大型系统的日志管理，它只能在开发阶段用于简单的问题定位而已。
 
日志管理需要从系统架构上解决，而这个架构最终还是要取决于日志的用途和目的。先来看看日志管理究竟是干什么的？
 
日志管理主要为了提供一个方法来管理计算机产生的大量日志信息，其主要过程涉及信息的收集，存储和分析，主要目的是安全检查，审计检查，问题定位。
 
 
 
通常开发人员会自己构建日志系统和分析工具，来支撑模块开发，但实际情况是常常没有固定的格式和规范可循。因此系统级的日志管理将是一个复杂的过程，若在开发中不做适当的管控，经常容易产生混淆，降低系统级开发定位的效率。因此有效的系统级日志分析涉及很多挑战：大量日志，日志类型，日志格式等。
 
为了解决系统级日志分析【1】，当前有诸多方案：
 
 
 
模式识别（Pattern recognition）
归一化（Normalization）
分类和标示（Classification and tagging）
相关性分析（Correlation analysis）
人工过滤（Artificial Ignorance）
 
 
但是我们回过头来看下日志管理的目的和流程：来源于应用程序，操作系统，硬件设备的日志信息以消息流的方式组织成日志，经由日志管理系统的收集和存储环节，进入日志分析阶段。可以说，日志收集和存储的主要目的是为了分析，而分析是为了解决日志管理的目的：安全检查，审计检查，问题定位。
 
 
 
日志管理在大型系统中是一个系统架构问题。既然如此，日志管理就应该从系统架构上考虑。下面介绍下日志管理架构开发涉及的主要几个环节和步骤。
 
日志管理架构开发主要环节和步骤：
 
 
 
定义需求和目标：如安全日志分析，应用问题分析，控制管理报告等；
定义日志框架，类型，格式，规范；
确定日志管理目的：收集，分析，报告，远程监控？如果收集日志，多长时间需要归档一次？是否需要压缩？
日志中需要包含哪些信息：模块类型？日志级别？错误信息？
评估当前技术，参考开源项目，选择或者构建最合适的日志管理方案。
 
 
从源头上规范了日志管理，做好了日志管理的架构设计，对于后续模块，系统开发，定位将会带来深远的影响。
 
 
 
如果有朋友涉及了这些问题，可以讨论下，当前正在做一个系统级的日志管理方案。
 
 
 


参考文档：

【1】Log Analysis

摘自 lida2003的专栏