日志系统设计

2009-12-11 00:46:58| 分类：技术 | 标签： |字号大中小订阅

一、重要性
日志系统在整个系统架构中的重要性可以称得上基础的基础，但是这一点，都容易被大多数人所忽视。因为日志在很多人看来只是printf。在系统运行期间，是很难step by step的，所以只能根据系统的运行轨迹来推断错误出现的位置，这往往也是唯一的资料，特别是在高可靠性的情况下。
从更大方面的范围来说，日志系统是运营维护的范畴。但小的方面来说，这是必须的调试的手段。在多年的开发经验来看，日志系统必须被我们重视的。

二、解决问题
日志系统的主要解决的问题是记录系统的运行轨迹，在这个基础上，进行跟踪分析错误，审计系统运行流程。在高可靠的系统中，是不允许系统运行终止的。日志系统的内容可以分为2类，一类可是业务级别的日志，主要供终端用户来分析他们业务过程；另一类是系统级别的日志，供开发者维护系统的稳定。
由于日志系统的数据输出量比较大，所以不能不考虑对整个系统性能的影响。从另外一方面来看，海量的日志内容有时候并不件好事，因为，很容易覆盖真实问题的蛛丝马迹。也增加日志阅读者信息检索的困难。
日志系统的设计，必须解决几个问题：
1、使用方便，包括开发和信息检索。
2、组织合理，日志内容被有效的组织起来。有助于基于日志内容的分析。
3、过程重现，这个目标其实对开发者来说是最重要的。基于日志的分析，最重要的是重现当时运行的过程。
4、可控制性，允许用户进行干预，特别是运行期的干预。比如关闭某些内容，或者重定向内容的输入目标点。

三、系统构成
一个日志系统根据他的过程，可以分为日志来源，系统控制，日志输出，【日志存储】。根据这个过程，我们可以将整个系统分为4个模块，并加以抽象。

1、日志来源
日志内容可以来源于任何其他系统，但对日志系统来说，这是个格式化的缓冲区。对于日志系统来说，任何内容都是合法的。最重要的是，日志系统必须提供一个简单的规则，为后续的管理和检索提供方便性和灵活性。在传统的printf格式中，是很难维护一个格式化的日志输出。文本方式对人来说阅读方便，但不容易检索，特别是在大量日志的情况下，更不好维护了。
2、日志控制
系统控制的重点在于控制日志内容在日志系统中的流转过程。比如日志输出目的地，比如日志的输出级别。我们在apache的Logging项目中曾经看到，他们提供了一个和平时不太一样的输出目的地，telnet。这和传统的stdout、stderr、syslog有很大的区别，便于远程管理，更大的潜力在于，可以在运行期，通过登录telnet来动态调整系统环境配置。
3、日志输出
日志在控制台输出是比较常见的，但如何考虑为系统的可靠性提供支持，以及大量日志内容的情况下，这个一般不予考虑的。在控制台输出的，只会是非常核心的内容或者是致命的错误，况且，在有些情况下，不一样会有控制台。我们一般在这种情况下，都倾向于将日志输出到文件。但对一个完善的日志系统，日志输出和日志存储又是有区别的。日志存储是日志输出到文件的一种方式。日志输出也是日志控制的一个内容。
4、日志存储
日志存储在很多小型系统往往并不需要关注，一个可靠性要求很高的系统中，对日志存储却是极为苛刻。就是在现在的数据库系统中，也必须依赖日志的存在，来还原操作。

四、日志内容
1、内容分级
在LINUX的SYSLOG中，对日志内容进行分级，将分为8个级别，如下：

#define LOG_EMERG 0 /* system is unusable */
#define LOG_ALERT 1 /* action must be taken immediately */
#define LOG_CRIT 2 /* critical conditions */
#define LOG_ERR 3 /* error conditions */
#define LOG_WARNING 4 /* warning conditions */
#define LOG_NOTICE 5 /* normal but significant condition */
#define LOG_INFO 6 /* informational */
#define LOG_DEBUG 7 /* debug-level messages */

这样，我们只需要设置一个全局变量，监控日志内容输出级别。当产生日志内容的级别比输出级别更优先时，将被记录下来，否则被简单的忽略。这种方式，很容易控制日志的输出内容。在WIN32平台下，有分类的功能，但是没有分级。但实际上也有个问题，就是只能控制一个输出范围，如果想只输出特定类的日志内容，在策略上，还是比较麻烦的。
2、内容分类
在LINUX的SYSLOG中，不但对日志内容有分级，同样也有分类，主要是根据日志内容的来源，如下：

#define LOG_KERN (0<<3) /* kernel messages */
#define LOG_USER (1<<3) /* random user-level messages */
#define LOG_MAIL (2<<3) /* mail system */
#define LOG_DAEMON (3<<3) /* system daemons */
#define LOG_AUTH (4<<3) /* security/authorization messages */
#define LOG_SYSLOG (5<<3) /* messages generated internally by syslogd */
#define LOG_LPR (6<<3) /* line printer subsystem */
#define LOG_NEWS (7<<3) /* network news subsystem */
#define LOG_UUCP (8<<3) /* UUCP subsystem */
#define LOG_CRON (9<<3) /* clock daemon */
#define LOG_AUTHPRIV (10<<3) /* security/authorization messages (private) */
#define LOG_FTP (11<<3) /* ftp daemon */

在WIN32平台下的事件管理器也是有相应的功能，只是有部分区别。WIN32的系统日志被分为安全性、应用程序、系统等几类。每类都有几个固定的字段，日志内容是以文本方式被保存的。分类的主要依据也是日志内容的来源。

3、内容格式
虽然内容的分级和分类在很大的程度上，对日志内容进行归类，但这远远不够。这个规则的粒度相当粗糙。也就是说，针对特定级别特定类的日志内容也会是相当地庞大。因此有必要针对日志内容在更小粒度的划分，就是内容格式的设计。内容格式的设计上，有个很致命的问题，就是内容的多样性，很难用一个统一的格式来限定内容输出。对于动态内容的格式话，其实我们也有几个现成方案值得借鉴。
首先、XML在格式化多样性内容方面具有相当大的灵活性，不过他也有个致命的弱点，就是解析内容时，具有相当大的时间复杂度。
其实、TDS协议是SYBASE数据库在输出DBMS结果给客户端时，数据流的格式。他允许在一个流中存在不同类表的数据，比如多个不同结果字段的游标。在灵活性方面不如XML，但速度要快于XML。
最后、每个内容块都遵循同样的格式，这种方式，灵活性最差，但要简单多了。整个日志内容相当于一个固定结构的表。
从笔者的角度出发，倾向于以TDS的格式为基础，引进XML的某些特性，来设计出一个内容格式。

4、内容边界

日志系统可能需要将各种各种格式的日志内容统一存储在一起，这些内容同样可能是不同的大小，因此我们需要确认每个内容边界，否则极有可能混淆每个内容的确切内容。内容边界是日志系统设计的一个最基本细节，否则这个日志系统将是不可能。没法确切区分每个日志内容，后续的分析就没法是实现了。内容边界的设计，在日志存储系统之前就必须是明确的。

五、日志控制
1、控制目标
日志系统要控制的目标包含整个日志内容流转的过程。对日志来源的控制，一般着重于对日志内容的过滤。上面对内容进行分级、分类、制定格式，一个最重要的原因就是对日志内容的过滤。对日志输出控制，主要着重于输出目的，比如是文件还是SYSLOG，以及诸如此类。
日志控制是日志内容流转过程中的一个强化功能。一般来说，越多的日志内容，对系统跟踪分析更有利，但更多的内容，就越增加分析的难度。所以我们需要通过日志控制这个功能来进行平衡。

2、来源控制
一个最明显的例子，为了方便调试，可能需要在系统中增加调试信息，在正在发布中，这些是不需要。所以在很多系统发布版本中，都要区分发布版和调试版。如果增加了来源控制系统，那么这些事情就简单多了。我们只要将这些信息简单地分级分类。通过一个逻辑控制，将不需要的给过滤掉。前面的分级分类的工作，在这个时候就会发挥很大的作用。
在wireshark，原来的ethereal，允许自己编辑过滤条件。POSIX的正则表达式也是个很好的设置过滤条件工具。过滤是来源控制功能的一个很重要的工作。实际上，内容在来源上已经产生，只是没有到达或者说没有必要到达到输出目的地。

3、输出控制
输出控制是日志控制的一个重要工作，但是这个工作和日志输出会有个概念重合的地方。控制只是负责按规则解释这个内容究竟是否需要输出，至于输出的具体内容，其实和他已经没有什么关系了。

六、日志输出
日志输出有两个重点功能，就是输出什么样以及往哪里输出。
1、输出格式
输出格式，是解释内容是什么样的工作，printf的格式串是很明显的例子。但是一个强大的日志系统可能更为复杂，比如DBMS的日志系统。格式问题往往在日志检索中，或者日志分析中，体现出巨大的作用。在通常的使用中，还是要依赖于分级和分类。不过格式的使用，针对日志内容级别的检索和分析将更为有用。

2、输出目标
输出目标通常为文件，控制台，syslog，在apache logging项目中还有个telnet。在文件和syslog作为输出目标时，其实和存储已经很相似了。往哪个目标输出是输出控制的功能，不过，每个目标输出内容应该如何输出，就是日志输出的工作了。

3、telnet
telnet作为输出目标是很少见，因为他比较复杂，不过，因为他功能强大，所以，在大型服务器中，是非常需要的。在这里必须着重提醒一下。apache logging项目，专门有个功能。telnet配合日志控制，允许在运行期得到更为详细的功能供调试。这是个很重要的特性，他提供了在运行期和系统进行交互的一个手段。

七、日志存储
日志存储其实是日志输出的一部分，不过是日志输出中一个很特别的部分。日志输出可能没有IO操作，只在内存中完成操作，但是日志存储是必须存储到物理磁盘中。这个特性就会涉及到一个效率问题。我们知道IO操作和内存操作的性能级别不是一个数量级的。当日志系统涉及到存储时，就必须考虑到性能问题。当大量的数据频繁地被写入到磁盘中，性能问题就更为严重。必须采取更有效的措施来避免写盘操作对其他系统的影响。