我有兴趣将所有Rails应用程序日志记录发送到数据库(MySQL或MongoDB),作为日志文件的补充或替代.有几个原因,其中大多数都关注日志文件分析.我们已经使用了Google Analytics(分析),但我们想要做的各种事情在Google Analytics中并不可行.
此外,我想通过查看日志来对问题进行"实时"调查.筛选日志文件是一种繁琐的方法,我希望能够比日志文件(轻松)更好地进行搜索和过滤.
最后,我经常想要检查更接近网站访问者行为的内容:例如,跟踪网站中的路径,以便我可以看到在发生错误之前用户正在查看的最后一页是什么.鉴于我们有多个应用服务器,单独的日志文件使这真的很痛苦.如果所有数据都在数据库中,那么我可以很容易地看到给定访问者的正确页面序列.我知道Syslog是解决这个特定事物的一种方式(单个日志文件/存储库),但我希望将它与我与数据库搜索相关联的更好的搜索能力结合起来.
我想知道人们建议解决这个问题.您是直接登录到数据库,还是将日志文件转储到数据库中(但是您的方法是什么,以便它基本上是实时/最新的日志文件本身)？
我目前正在确定我喜欢这种日志记录的级别,因为我看到的另一件事是编写一个可以记录所有请求的小型Rack过滤器.这将错过正常Rails日志记录转储出来的所有额外输出(缓存命中和未命中的所有SQL和输出等),但它会实现我的目标的很大一部分,并且似乎具有不打扰的优势系统中的任何其他内容.
无论如何,我不是在寻找一个正确的答案,更多的是关于其他人可能在同样的事情中做什么的讨论和信息.
对日志文件进行故障排除,分析和过滤是迄今为止最费力的日常工作之一.我的问题是搜索日志文件,其大小可能超过4个演出.只需加载文件最多需要15分钟.我正在运行一个相当快的处理器,有8个内存.文件加载后,我实际上只有grep和/或control + F的奢侈品来扫描文件.当我试图从多个系统中查看文件时,这会变得更糟.尝试根据时间戳分隔文件,使它们变小,但真的没有快乐.
是否有一个工具甚至一个过程可以用来减少故障排除(除了通常的"只是先修复bug")？
您的意见表示赞赏.