我有兴趣将所有Rails应用程序日志记录发送到数据库(MySQL或MongoDB),作为日志文件的补充或替代.有几个原因,其中大多数都关注日志文件分析.我们已经使用了Google Analytics(分析),但我们想要做的各种事情在Google Analytics中并不可行.
此外,我想通过查看日志来对问题进行"实时"调查.筛选日志文件是一种繁琐的方法,我希望能够比日志文件(轻松)更好地进行搜索和过滤.
最后,我经常想要检查更接近网站访问者行为的内容:例如,跟踪网站中的路径,以便我可以看到在发生错误之前用户正在查看的最后一页是什么.鉴于我们有多个应用服务器,单独的日志文件使这真的很痛苦.如果所有数据都在数据库中,那么我可以很容易地看到给定访问者的正确页面序列.我知道Syslog是解决这个特定事物的一种方式(单个日志文件/存储库),但我希望将它与我与数据库搜索相关联的更好的搜索能力结合起来.
我想知道人们建议解决这个问题.您是直接登录到数据库,还是将日志文件转储到数据库中(但是您的方法是什么,以便它基本上是实时/最新的日志文件本身)?
我目前正在确定我喜欢这种日志记录的级别,因为我看到的另一件事是编写一个可以记录所有请求的小型Rack过滤器.这将错过正常Rails日志记录转储出来的所有额外输出(缓存命中和未命中的所有SQL和输出等),但它会实现我的目标的很大一部分,并且似乎具有不打扰的优势系统中的任何其他内容.
无论如何,我不是在寻找一个正确的答案,更多的是关于其他人可能在同样的事情中做什么的讨论和信息.
我的公司已经将一些结构化的流量信息直接记录到MySQL日志数据库中.此数据库将下游复制到另一个数据库.所有分析都运行在最终的数据库复制中.我们的网站维持了相当多的流量.到目前为止,它似乎没有任何重大问题.但是,我们的IT部门对当前设置的可扩展性有一些日益增长的担忧,并建议我们将日志信息卸载到"正确"的日志文件中.然后将日志文件重新插入到相同的下游数据库表中.这让我想到了这个问题.:)
以下是我看到的关于日志文件与log-db(关系)主题的一些优缺点:
日志文件快速,可靠,可扩展(至少我听说过Yahoo!大量使用日志文件进行点击跟踪分析).
日志文件很容易由sys-admin维护.
日志文件可以非常灵活,因为您几乎可以编写任何内容.
日志文件需要大量解析,并且可能需要地图缩减类型的数据提取设置.
log-db结构与您的应用程序更加接近,使得某些功能的周转时间缩短了很多.这可能是一种祝福或诅咒.从长远来看可能是一个诅咒,因为你很可能最终得到一个高度耦合的应用程序和分析代码库.
log-db可以减少日志噪声和冗余,因为日志文件只是插入,因为log-db使您能够进行更新和关联插入(如果你敢于标准化).
如果使用数据库分区和/或多日志数据库(通过下游复制重新加入数据),log-db也可以快速且可扩展
我认为在我的情况下需要对日志数据库进行一些压力测试.这样至少我知道我有多少空间.
最近,我一直在研究一些基于键值/文档的数据库,如Redis,Tokyo Cabinet和MongoDB.这些快速插入数据库可能是最佳选择,因为它们提供持久性,高(写入)吞吐量和不同程度的查询功能.它们可以使数据提取过程比通过日志文件的数据解析和映射减少简单得多.
从长远来看,我认为拥有一个强大的分析数据仓库至关重要.从分析数据中释放应用程序数据(反之亦然)可能是一个很大的胜利.
最后,我想指出StackOverflow上有许多类似/密切相关的问题,以防你想扩大讨论范围.
存储许多日志文件
将服务器日志文件写入数据库是一个好主意吗?
使用SQL Server进行应用程序日志记录.优点缺点?
在日志中快速搜索
用于记录的独立生产数据库
您登录到您的数据库,当您的数据库关闭时,您在哪里记录?
编辑:
rsyslog看起来很有趣.它使您能够直接写入MySQL.如果您使用的是Ruby,那么您应该查看日志记录gem.它提供多目标日志记录功能.这太好了.
如果要更改默认日志记录行为,只需创建一个响应所有Rails记录器方法的自定义记录器对象:
加
调试,警告,错误,信息,致命,未知
http://github.com/rails/rails/blob/9d7aae710384fb5f04129c35b86c5ea5fb9d83a9/activesupport/lib/active_support/buffered_logger.rb
因为它是您的记录器,您可以决定实施您的个人逻辑.您可以随时写入数据库,标准输出.
然后,替换要自定义的每个基类的默认记录器.
ActiveRecord::Base.logger = YouLogger.new
您可以轻松创建名为logger.rb的初始化文件,并在其中写入所有自定义配置.这样,Rails启动时会立即替换记录器.