2013-03-16 83 views
0

我花了大部分時間用C編寫軟件。最近,我一直在研究將被歸類爲中間件的庫。他們只需要存在兩個軟件進行通信。從庫中暴露日誌接口

在開發過程中,我發現分析日誌可以更快更輕鬆地追蹤和隔離錯誤。很顯然,我希望庫的任何生產使用都不需要頻繁檢查日誌輸出。

但實際情況是一些錯誤只出現在生產環境中。造成這種情況的一個常見原因可能是圖書館另一面的實施方式正在做一些標準方面的灰色區域。因此,需要能夠分析生產環境中的日誌。

那麼從中間件類型API公開日誌的最佳做法是什麼?有沒有關於這個話題的文獻?

我心目中目前兩個想法:

首先是使用#define來控制我的源代碼記錄語句的存在。在生產環境中,庫可以編譯兩次。一個共享對象將啓用日誌語句。另一個將在沒有日誌記錄的情況下進行優化。通過在運行時更改動態鏈接的庫,可以啓用和禁用日誌記錄。

#define方法可行,但可能不靈活。另外,我對性能不是很在意。我先採取工具的做法,優化第二。

我的第二種方法是堅持使用UNIX風格的哲學,並在庫上通過傳遞文件描述符來啓用日誌功能。這可以使日誌在運行時啓用或禁用。如果設置了文件描述符,則啓用日誌記錄。如果沒有設置,則不記錄。顯然,這有其自身的缺點。但這是一個簡單的方法。

回答

2

這裏是我的考慮:

  • 記錄當客戶碰到一個問題,必須始終有

通常情況下,你想的第一件事就是日誌。

  • 記錄消息應該由
  • 水平

你應該在你的代碼添加儘可能多的日誌報表不同,因爲你會發現有用的(超前思考)。然而並非所有的陳述都是有用的。應該有區分的問題,水平或命名空間信息的方式,因此您可以快速選擇你需要

  • 記錄應該是可配置

如果你有一個高容量的服務器系統,記錄一切什麼可以每秒生成數兆字節的數據。你應該擁有如何控制記錄和不記錄的功能。

作爲一個例子,你可以看看C(cutils組件)的Android日誌API。它是函數+宏的組合,使您可以將日誌記錄語句添加到代碼中。

您選擇哪種機制將日誌存儲在磁盤上是您的選擇,但是對於您的平臺使用最常見的方法(Linux的/ var/logs,Android的logcat等)是有益的