ruby-on-rails - 记录到数据库而不是日志文件

Question

我有兴趣将所有 Rails 应用程序日志记录发送到数据库(MySQL 或 MongoDB)，以补充或代替日志文件。有几个原因，其中大部分与日志文件分析有关。我们已经在使用 Google Analytics，但有很多我们想做的事情在 Analytics 中并不可行。

此外，我想通过查看日志对问题进行“实时”调查。筛选日志文件是一种繁琐的方法，我想做比日志文件(容易)允许的更好的搜索和过滤。

最后，我经常想检查一些更接近站点访问者行为的东西:例如跟踪站点的路径，这样我就可以看到用户在错误发生之前查看的最后一页是什么。鉴于我们有多个应用程序服务器，单独的日志文件使这成为一个真正的痛苦。如果所有数据都在数据库中，我就可以很容易地看到特定访问者的正确页面顺序。我知道 Syslog 是解决这个特定问题(单个日志文件/存储库)的一种方法，但我想将其与我与数据库搜索相关联的更好的搜索能力结合起来。

我想知道人们推荐什么来解决这个问题。您是直接登录到数据库，还是将日志文件转储到数据库中(但是您的方法是什么，以便它基本上是实时的/与日志文件本身一样最新)？

我目前正在确定我希望在什么级别进行日志记录，因为我看到的另一件事是编写一个小型 Rack 过滤器来记录所有请求。这会错过正常 Rails 日志转储的所有额外输出(所有 SQL 和缓存命中和未命中的输出等)，但它会实现我的目标的很大一部分，并且似乎具有不打扰的优势系统中的任何其他内容。

无论如何，我不是在寻找一个正确的答案，更多的是关于其他人在同样的情况下可能正在做的事情的讨论和信息。

Answer 1

我的公司一直在将一些结构化的交通信息直接记录到 MySQL 日志数据库中。该数据库被复制到下游到另一个数据库。所有分析都基于最终的数据库复制。我们的网站维持相当多的流量。到目前为止，它似乎没有任何大问题。但是，我们的 IT 部门越来越担心当前设置的可扩展性，并建议我们将日志信息卸载到“适当的”日志文件中。然后日志文件将被重新插入到相同的下游数据库表中。这让我想到了这个问题。 :)

以下是我看到的关于日志文件与日志数据库(关系)主题的一些优缺点:

• 日志文件快速、可靠且可扩展(至少我听说 Yahoo! 大量使用日志文件来进行点击跟踪分析)。
• 日志文件便于系统管理员维护。
• 日志文件可以非常灵活，因为您几乎可以向其中写入任何内容。
• 日志文件需要大量解析，并且可能需要使用 map 简化类型的数据提取设置。
• log-db 结构更接近您的应用程序，使某些功能的周转时间更短。这可能是一种祝福，也可能是一种诅咒。从长远来看，这可能是一个诅咒，因为您很可能最终会得到一个高度耦合的应用程序和分析代码库。
• log-db 可以减少日志记录噪音和冗余，因为日志文件仅在 log-db 使您能够执行更新和关联插入(如果您敢于标准化)的地方插入。
• 如果您使用数据库分区和/或多日志数据库(通过下游复制重新加入数据)，log-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，则应该查看日志记录 gem。它提供多目标日志记录功能。这太好了。