設計Azure的雲的日誌框架

Question

我有麻煩找上設計和實施生活在Azure雲應用的彈性日誌框架標準做法的信息。這個想法是，應用程序不需要知道或處理自己的日誌記錄和信息\錯誤信息的記錄可以照顧「在後臺」

我正在考慮的設計基本上是「隊列 - 基於負載均衡模式「（https://msdn.microsoft.com/en-us/library/dn589783.aspx）通過鏈接自動轉發的服務總線實體進行增強。

的想法是，每個應用程序都有它自己的隊列地方在它的地方丟棄的日誌信息資源組。此本地隊列然後將日誌消息轉發到中央日誌隊列。當日志消息落在中央隊列中時，它觸發一個工作服務（或類似的）來適當地處理消息（格式並將其發送到適當的數據存儲區）

這種方法的思想是如果中央消息隊列日誌消息將保留在應用程序的本地隊列中，從而提供額外的彈性層。如果本地隊列失敗，該應用程序可以作爲備份\冗餘登錄到其他數據存儲。

所以我只是想知道是否有任何缺點或理由上面不會是一個好方法，或者如果任何人都可以推薦一個更好的方法來設計/實施Azure中的共享日誌框架？

Answer 1

這將是很容易實現日誌客戶端，例如把日誌消息到服務總線隊列。你會有一個很好的保護消息隊列與自動毒信件檢測等。當然大問題是：你會需要它，或者它會足夠像存儲隊列一樣簡單，甚至直接登錄到存儲？

任何類型的日誌記錄都可以使用任務內部的pub/sub模式（例如Event Aggregator）作爲後臺任務完成。

現有的日誌框架

還有一些日誌已經實施很多你描述，較受歡迎的一個，名叫Log4Net框架，採用了附加器的概念作爲描述實際記錄的引擎的方式。這真的可以是任何事情;存儲，隊列，數據庫，並且只需很少的努力，您也可以編寫自己的appender以滿足您的需求。

成本

更多的往往不是的問題，這可以歸結爲成本比彈性更大。而彈性是一個風險計算的問題。你的系統可能會崩潰的可能性很大，在這種情況下，你很可能沒有看到日誌文件。最後，您需要記錄哪些尚未由應用程序運行時發生的現有日誌處理的內容？最後，沒有這些信息會花費多少錢？ 這些問題的答案會給你一個數字，然後你可以轉化爲適當的日誌框架的投資。

我知道，作爲開發商，我們一直在尋找完美的解決方案，但是這並不總是符合邏輯的選擇。