日志系統設計??

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操作和內存操作的性能級別不是一個數量級的。當日志系統涉及到存儲時，就必須考慮到性能問題。當大量的數據頻繁地被寫入到磁盤中，性能問題就更為嚴重。必須采取更有效的措施來避免寫盤操作對其他系統的影響。

原文轉自：http://blog.csdn.net/romandion/archive/2007/11/10/1877189.aspx

總結

以上是生活随笔為你收集整理的日志系统设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。