速度關鍵系統的設計跟蹤/日誌

假設我們有速度關鍵的系統（例如統計/分析，套接字編程等），我們如何設計跟蹤和日誌。速度關鍵系統的設計跟蹤/日誌

更具體地說，日誌和跟蹤通常會降低性能（即使我們有關閉機制或冗長的擴展機制）。在這種情況下，是否有任何關於如何「放置」日誌/痕跡的參考指南，以便在問題發生時（特別是在生產現場），開發人員/後期製作團隊能夠指出實際問題。

PS：我來自哪裏這樣的應用在C/C開發的背景++（在Linux上運行）

2013-03-19 kumar_m_kiran

我猜如果你能承受失去一些條目異步日誌記錄;或者像lmax這樣的破壞者，如果你絕對需要一致的話 – driushkin 2013-03-19 12:15:24

如果你的意思是用另一個線程記錄，我意識到這個過程。然而，有時候，即使這些也會成爲一種阻力。想知道是否有任何其他「更好」的機制來處理記錄/追蹤。 – 2013-03-19 12:18:11

您是否正在尋找一種在無需登錄的情況下儘可能減少開銷的系統？或者你正在尋找一種方法來最大限度地減少實際寫入日誌的開銷？如果後者是這樣的，那麼這些消息是否傾向於聚集在一起，並且兩者之間存在長期差距，還是存在更嚴重的總吞吐量問題？ – 2013-03-19 12:24:51

可以積累您可以描述和使用Google Protocol Buffers實現緩衝區內的日誌。您可以定期使用不同的線程（每5分鐘）將該緩衝區清空到磁盤或通過UNIX domain socket（或其他Linux IPC mechanisms）將其發送到守護程序，該守護程序可偵聽並將它們寫入持久性數據庫或將其寫入磁盤。

如果您不想點擊生成日誌的計算機上的磁盤，則可以通過regular socket將它們發送到其他計算機，並將它們寫入該計算機上的磁盤。

如果您正在彙總來自多臺機器的日誌，請考慮使用0MQ或CrossRoads作爲消息隊列將您的日誌通過網絡傳遞到永久存儲它們的機器。你可以找到一些關於using 0MQ in conjuction with Google Protocol Buffers here的信息。

來源

2013-03-19 12:23:19 average

謝謝！讓我試試看！ – 2013-03-20 03:46:28

速度關鍵系統的設計跟蹤/日誌

回答

相關問題