紅帽開發者：準備扔掉你的syslog吧！
譯文【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
【編輯推薦】
