【51CTO精选译文】说到保护服务器，你首先会想到什么？
多年以来，系统管理员们和运维们在怀疑服务器遭受攻击或出现问题的时候，肯定是要先检查syslog的。不过在最近，红帽的两位开发人员提议采用一种新的基于二进制数的工具“The Journal”，这个工具可能将在Fedora 17中取代syslog。
两位开发人员名叫Lennart Poettering和Kay Sievers。他们的建议是：现在的syslog已经是30年的老古董，不仅效率低下，很容易被误读和被改动，甚至于连其最基本的功能——将系统事件日志存储在某一个Linux机器上都无法正常执行。
这在很大程度上归咎于系统日志不拘形式的性质：只要是Linux系统上的应用程序或守护程序发送的文本字符串，不管采用什么样的形式，系统日志基本上都照收不误。于是，某个守护程序可能会以某一种方式发送关于事件的信息，而另一个守护程序可能会以全然不同的方式来发送事件信息；这样一来，解析信息其含义的任务就扔给了阅读日志的人。自动化的日志分析工具在这方面有所帮助，但是Poettering和Sievers在关于The Journal的详细描述中写道：
“记入日志的数据其形式非常随便。自动化的日志分析工具需要解析人类语言字符串，以便：
1）识别消息类型，以及
2）从中解析相关参数。
这就导致了令人讨厌的正则表达式，而且经常需要跟在上游的开发人员屁股后面，因为这些开发人员可能会在新版本的软件中调整人类语言的日志字符串。实际上，从某种程度上来讲，只能这样。为了不破坏用户所用的正则表达式，所有日志消息变成了其相对应的服务的二进制文字版界面（ABI），而这通常不是开发人员的本意。”
这两位开发人员重点指出了当前的系统日志体系存在的14个问题，而上面这个只是其中之一。其他问题包括如下：
•syslog的数据没有经过验证。
•syslog仅仅是Linux上众多的日志系统之一。
•根本就没有针对syslog的访问控制机制。
•只是在固定的间隔时间对磁盘使用实行了限制，导致系统很容易受到分布式拒绝服务（DDoS）攻击。
等等。Poettering和Sievers重点指出了syslog体系存在的一个大家非常关注的问题：
“比如说，最近热议的kernel.org入侵事件涉及的就是黑客操纵日志文件；要发现这种攻击行为，完全靠运气。”
考虑到这些因素，Sievers和Poettering提议采用The Journal守护程序，该守护程序将来自系统日志的事件以二进制数、而不是文本的形式来存储数据，将数据作为包含散列以增强安全性的键－值对（key-value pair）列表来存储。
这并不是这两位开发人员头一回提议对Linux系统的基础架构作出如此全面的改变。Poettering不但是PulseAudio声音服务器的开发者，还开发了取代Linux上System V init守护程序的systemd守护程序。Sievers最近成了Fedora项目团队的一名成员，他提议：需要时，将所有可执行文件移入到/usr/bin目录，将它们的库移入到/usr/lib或/usr/lib64。（编辑注：当然，如果你的usr没了，那就悲催了）
实现了这种二进制数后，The Journal守护程序就能够为每个系统事件添加元数据，比如进程编号和发送者名称、用户和用户组编号以及其他关键的系统数据。
“受udev事件的启发，The Journal条目酷似环境块（environment block）。许多键/值字段由换行符分隔，使用大写字母的变量名。与udev设备事件和实际环境块相比较，有一大区别是：虽然关注的重心绝对放在ASCII格式化字符串上，但是作为值的二进制斑点（binary blob，这是指装入到开源操作系统内核里面的一种对象文件，但没有向公众开放的源代码）也得到支持——这种对象文件可以用来添加二进制元数据，比如ATA SMART健康状况数据、SCSI感知数据、核心转储数据或固件转储数据。生成The Journal条目的代码想为条目添加多少字段，就可以添加多少。字段可以是很有名的字段，也可以是针对特定服务/子系统/驱动程序的字符。”
如果说开发人员觉得这一切听起来有点耳熟，那么不妨直说吧：Poettering和Sievers在这方面的许多努力其灵感其实源自提供给使用Git版本控制系统的开发人员的键/值、散列和元数据这些概念。
实施The Journal不但会让Linux系统变得更安全（因为未经验证的日志条目或突如其来的数据字符项会立即被The Journal守护程序标出来），其发明者还希望通过统一Linux机器上的所有日志系统，为数据高效地重新建立结构，可以实际减少日志系统在Linux上占用的资源。
“其设计方式如下：日志数据只添加在末尾（目的是为了借助基于mmap()的访问，以确保健壮性和原子性），头里面的一些元数据变化可以引用新添加的日志数据。字段在日志文件中作为一个个对象来存储，然后可供有需要的所有条目来引用。这大大节省了磁盘空间，因为日志条目通常高度重复（想一想每个本地消息都会含有同样的_HOSTNAME=和_MACHINE_ID=字段）。数据字段经过了压缩，目的是为了节省磁盘空间。最终结果就是，虽然The Journal记入日志的元数据要比经典系统日志记入的多得多，但是占用的磁盘空间并没有立马体现这一点。”
然而，不是每个人都因这一提议而激动万分。Poettering和Sievers预料，许多开发人员和系统管理员不高兴The Journal使用通用唯一标识符（UUID）来识别消息，他们其实并不真正注意提议文档FAQ部分中的这个议题。
许多人在最先刊登这项提案的LWN上发表了反对意见，他们为简单的基于文本的系统将换成依赖The Journal这一种工具的二进制数据格式而悲痛，而这个工具将仅在systemd守护程序中存在。
有几个人在上面针对The Journal提议的FAQ留言道：
“日志文件格式会实现标准化吗？我在哪里能找到磁盘上数据结构的解释？”
“目前，我们不想对格式进行标准化。只要我们觉得合适，就想随意改变格式。我们可能最终会将磁盘上数据格式记入文档，但是眼下，我们不想使用其他任何软件来直接读取、写入或操纵我们的日志文件。我们需要一个共享库和命令行工具才能访问。（但是同样，这是自由软件，所以你总是能阅读源代码！）”
这引起了很大的争议，因为LWN上的许多读者反对为The Journal的数据使用非标准格式。向后兼容也是让人担心的一大问题。
其中一位读者C. McCabe留言道：“真遗憾，我们要失去明文syslog格式的简洁性。再说了，syslog通常使用gzip进行了压缩。所以实际上对我来说，这一切意味着，我将需要使用某个“神奇的工具”而不是gzcat作为我外壳命令的第一个部分。我发现的一大问题是，许多系统管理员会将这视作可以提高安全的魔法粉末，却没有认识到：为了获得任何安全方面的优点，他们需要定期将那些散列保存到远程而且安全的系统。”
McCabe补充说：“我还希望Lennart及其公司认识到磁盘上数据格式向后兼容的绝对必要性。要是升级到新版本后，旧日志变得无法读取，这确实会激怒许多系统管理员。不过，假如这方面得当了妥善处理，我觉得这倒也算是个好想法。”
这在更广泛的Linux社区会引起怎样的反响？我本人认为，Fedora（及它的红帽爸爸）现在成了一个对Linux的许多内部基础架构进行改造的项目，而Ubuntu等发行版则侧重于界面和用户方面。
显然，Linux在经历一些重大的革命性变化，剔除了UNIX的一些糟粕。在Linux不断前进的同时，这些变化会给它带来怎样的影响，让我们拭目以待吧。
原文：http://www.itworld.com/it-managementstrategy/227291/linux-syslog-may-be-way-out
【编辑推荐】
- Linux日志管理高级进阶:实例详解syslog
- 如何用rsyslog确保远程Linux日志安全？
- 专题：Windows服务器系统日志管理入门