登錄到數據庫而不是日誌文件

Question

我有意將所有Rails應用程序日誌記錄發送到數據庫（MySQL或MongoDB），作爲日誌文件的補充或替代。有幾個原因，其中大部分都是關於日誌文件分析的。我們已經使用Google Analytics（分析），但是我們想要做的事情有很多，但在Google Analytics中不可行。

此外，我想通過看日誌做的問題「實時」的調查。篩選日誌文件是一種乏味的方式，我想要比日誌文件（容易）更好地進行搜索和篩選。

最後，我經常想要檢查一些更接近站點訪問者行爲的事情：例如通過站點追蹤路徑，以便我可以查看錯誤發生前用戶正在查看的最後一頁。鑑於我們有多個應用程序服務器，單獨的日誌文件使這成爲一個真正的痛苦。如果所有數據都在數據庫中，那麼我可以很容易地看到給定訪問者正確的頁面順序。我知道Syslog是解決這個問題的唯一方法（單個日誌文件/存儲庫），但我想將它與我與數據庫搜索相關的更好的搜索能力結合起來。

我想知道什麼樣的人推薦解決這個問題。您是直接登錄到數據庫還是將日誌文件轉儲到數據庫中（但是您的方法是什麼，以便它本質上是實時/最新的日誌文件本身）？

我目前正在確定什麼級別，我想這個日誌記錄，因爲我看的另一件事是寫一個小的機架過濾器，將記錄所有請求。這會錯過正常的Rails日誌輸出的所有額外輸出（所有SQL和輸出緩存命中和未命中等），但它會實現我目標的很大一部分，並且似乎具有不會干擾的優點系統中的其他任何東西。

無論如何，我不是在尋找一個正確的答案，更多的是關於其他人可能在這個相同的光線下做什麼的討論和信息。

Answer 1

如果要更改默認的日誌記錄行爲，簡單地創建一個所有Rails的記錄方法應對自定義日誌對象：

• 添加
• 調試，警告，錯誤，信息，致命的，未知

http://github.com/rails/rails/blob/9d7aae710384fb5f04129c35b86c5ea5fb9d83a9/activesupport/lib/active_support/buffered_logger.rb

因爲這是你的記錄，您可以決定實施你的個人邏輯。 您可以隨時向數據庫寫入標準輸出。

然後，替換您想要自定義的每個基類的默認記錄器。

ActiveRecord::Base.logger = YouLogger.new 

您可以輕鬆創建一個名爲logger.rb的初始化文件，並在其中寫入所有自定義配置。這樣，記錄器將在Rails啓動時立即被替換。

Answer 2

我使用導軌"exception logger"將所有問題記錄到我的數據庫，同時我的網站處於生產模式。它會給你一個很好的界面，你可以檢查問題。如果你想看看你的訪問者在實時做，然後看看

Answer 3

克里斯，

我認爲迪馬的評論是非常重要的在這裏。你對（1）在數據庫中實時訪問日誌感到滿意嗎？（2）你對Rails /特定於應用程序的日誌更感興趣嗎？

對於（1），使用Apache（至少），您可以使用管道日誌記錄登錄到數據庫。

http://httpd.apache.org/docs/1.3/logs.html#piped

我寫道，在後臺運行，等待輸入，它分析和日誌一個Postgres數據庫的程序。我的httpd.conf文件用CustomLog指令管道到這個程序。

這是相對簡單的設置，並給你所有的能夠分析你的日誌在數據庫中的明顯優勢。它對我來說非常好，特別是在錯誤發生之前追蹤用戶的行爲。但是，您必須防止日誌程序中的sql注入，緩衝區溢出和其他安全問題。對於（2），我不是Rails開發人員，所以我只能談論一般方法。如果您想記錄環境變量，應用程序數據或非常有選擇性的信息，您可以考慮編寫一個Web服務器模塊。根據您的具體需要，您還可以通過組合條件日誌記錄指令和日誌記錄程序中的過濾來獲得。

這實際上取決於您是否需要Rails特定的解決方案或更通用的Web服務器範圍的解決方案。

Answer 4

我的公司一直在將一些結構性流量信息直接記錄到MySQL日誌數據庫中。該數據庫被下游複製到另一個數據庫。所有分析運行最終的數據庫複製。我們的網站保持相當的流量。到目前爲止，它似乎沒有任何重大問題。但是，我們的IT部門對當前設置的可擴展性有着越來越多的擔憂，並建議我們將日誌信息卸載到「正確」的日誌文件中。日誌文件將被重新插入到相同的下游數據庫表中。這使我想到了這個問題。 :)

這裏有一些優點和我看到的關於到日誌文件VS登錄分貝（關係）的主題利弊：

• 日誌文件是快速，可靠和可擴展的（在至少我聽說雅虎使用日誌文件進行點擊跟蹤分析）。
• sys-admin很容易保存日誌文件。
• 日誌文件可以非常靈活，因爲你幾乎可以寫任何東西。
• 日誌文件需要大量解析，並且可能需要map-reduced類型的數據提取設置。
• log-db結構與應用程序距離更近，使某些功能的轉換時間縮短了很多。這可能是一種祝福或詛咒。從長遠來看，這可能是一個詛咒，因爲你很可能最終會得到高度耦合的應用程序和分析代碼庫。
• log-db可以減少日誌記錄的噪音和冗餘，因爲日誌文件只能插入到log-db中，使您可以執行更新和關聯插入（如果您敢於進行標準化）。
• 日誌-DB可以快速和可擴展的太多，如果你與數據庫分區和/或多日誌數據庫去（通過下游重複歸隊數據）

我覺得都需要在日誌數據庫上的一些壓力測試我的情況。至少我知道我有多少空間。

最近，我一直在研究Redis，Tokyo Cabinet和MongoDB等一些基於鍵值/基於文檔的數據庫。這些快速插入數據庫可能是最佳選擇，因爲它們提供了持久性，高（寫）吞吐量以及不同程度的查詢功能。它們可以使數據提取過程比通過演出日誌文件進行解析和縮小圖更簡單。

從長遠來看，我認爲擁有強大的分析數據倉庫至關重要。從分析數據中釋放應用程序數據，反之亦然可以是一個很大的勝利。

---

最後，我只想指出有StackOverflow上這裏有許多類似/密切相關的問題，在你想擴大你的討論情況。

• Storage of many log files
• Is writing server log files to a database a good idea?
• Using a SQL Server for application logging. Pros/Cons?
• Fast Search in Logs
• Separate production database for logging
• You Log to Your DB, Where Do You Log When Your DB is Down?

---

編輯：

rsyslog看起來很有趣。它使您能夠直接寫入MySQL。如果您使用的是Ruby，那麼您應該查看日誌記錄寶石。它提供了多目標記錄功能。這太好了。

Answer 5

，因爲沒有答案被接納到現在爲止，我會給我的貢獻

我做開發一個插件rsylog保存日誌未在文件中，但在MongoDB的

整個源代碼，從rsyslog現在+插件在這裏https://github.com/vpereira/rsyslogd-mongo

要編譯它，你應該運行./configure --help並查看可用的選項。

Answer 6

在作出記錄到數據庫最近我的錯，我覺得我可以提供一個非常好的理由，爲什麼你不應該這樣做：交易。比方說，你開始一個交易，在交易過程中記錄一堆東西，最終你會得到一個錯誤條件。你記錄錯誤情況，嘿嘿。 ROLLBACK。突然之間，你所記錄的一切都消失了，你不知道發生了什麼或者爲什麼。

特別是在Rails的上下文中，像AASM這樣真正有用的庫將一大堆東西包裝在一個事務中，最終可能會導致事務處理在你認爲不可能的地方，這也會導致問題很難調試。

就我而言，我將事情記錄到數據庫的原因是我需要上下文敏感的日誌。基本上我需要能夠查找與特定數據庫模型相關的所有日誌條目。但是，正確的答案是將這些日誌放在一個更適合日誌數據的獨立位置（在我的情況下，它恰好是可查詢的）。