紅帽開發者：準備扔掉你的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