一個好的日志系統(tǒng)，除了可以記錄盡可能多的必要信息，方便trace bugs、提供data analysis source這些基本功能之外，其他的貌似不必太在意。但真正當bugs冒出來的時候，要命的是既沒有dump，也沒有有價值的日志，更要命的是日志居然已經記錄了那么多，居然讓你查了半天，居然都是沒有價值的！

悲劇啊！

日志需要記錄的信息大概分為兩類：

1) 系統(tǒng)運行情況：啟動、加載、讀寫、關閉、異常；

2) 用戶使用情況：進入、操作、離開、異常。

我可以想到的關于日志系統(tǒng)的要求大致以下幾點：

1) 日志系統(tǒng)使用目錄樹結構：系統(tǒng)日志和用戶日志分別記錄，正常日志和異常日志分別記錄，不置于同一文件夾下，日志文件命名做到令觀者一目了然；

2) 記錄詳盡但不冗余：正確記錄日志時間、位置、事件、因果，有可能的話，記錄上下文（這要求有點高了）；

3) 格式統(tǒng)一但嚴禁千篇一律：格式統(tǒng)一是指記錄內容遵循一定格式，方便查看，嚴禁千篇一律是指記錄要有層次、輕重，不同事件導致的“同一”異常日志不應不加區(qū)別，同樣是為了方便查看；

4) 與異常處理相輔相成：有dump時，以日志輔助快速定位，沒有dump時，日志應盡可能提供有效信息，離系統(tǒng)崩潰的地方越近越好（這一點似乎也有難度）。

________________________________________________

突然想到的，也還沒有動手去做，先記下了，歡迎補充。

_____Added on Jul.25th, 2008_______________________

還看到一位兄弟在為我說話，謝謝！

今天在考慮實現(xiàn)時，想到一個很現(xiàn)實的問題，日志幾乎是無處不在的，隨時隨地會有日志記錄。不知道有誰對I/O（當然主要是Output）消耗和對系統(tǒng)的影響做過專門測試，猜測就算了:-)，我很想知道有沒有必要放到專門的線程中，如果放到獨立線程中的話，問題就出來了，多長時間寫一次？畢竟，記錄日志的主要目的就是為了全面記錄系統(tǒng)運行和用戶使用情況，如果在服務器crash的時候，還有日志（尤其是crash上下文日志）沒有被順利寫入，日志的意義也就大打折扣。

誰給點建議？