红帽开发者：准备扔掉你的syslog吧！

多年以来，系统管理员们和运维们在怀疑服务器遭受攻击或出现问题的时候，确定是要先检查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