将服务器日志文件写入数据库是一个好主意?

在阅读了O'Reilly撰写的关于这个主题的文章之后,我想问Stack Overflow对这个问题的看法。

本地写入磁盘,然后批量插入数据库定期(例如在日志翻转时间)。 在一个单独的,低优先级的过程中做到这一点。 更高效,更强大…

(确保你的数据库日志表中包含一个“从哪一台机器发出日志事件”的列 – 非常方便!)

我会说不,考虑到相当大比例的服务器错误涉及与数据库通信的问题。 如果数据库位于另一台计算机上,networking连接将成为另一个无法logging的错误来源。

如果我将服务器错误logging到数据库,那么在数据库无法访问的情况下,有一个本地写入(对事件日志或文件或其他东西)的备份logging器是非常重要的。

logging到数据库,如果可以,它不会减慢你的数据库:)

在数据库中find任何东西,然后在日志文件中快速find方法。 特别是如果你提前想到你将需要什么。 login数据库让你像这样查询日志表:

select * from logs where log_name = 'wcf' and log_level = 'error' 

那么当你发现错误后,你可以看到导致这个错误的整个path

 select * from logs where contextId = 'what you get from previous select' order by timestamp 

如果你把它logging在文本文件中,你将如何得到这个信息?

编辑:如JonSkeetbuild议这个答案会更好,如果我说,应该考虑做logging到dbasynchronous。 所以我说:)我只是不需要它。 例如,如何做到这一点,你可以查看Richard Kiessig的“Ultra Fast ASP.NET”。

如果你想在数据库中logging日志,这可能不是一个坏主意,但是如果你有很多的日志文件条目,我会说不遵循这篇文章的build议。 主要的问题是,我看到文件系统遇到来自繁忙网站的日志,更不用说数据库了。 如果你真的想这样做,我会看他们第一次写入磁盘后,将日志文件加载到数据库中。

考虑一个正确设置的数据库,利用RAM读取和写入? 这比写入磁盘要快得多,并且不会出现在服务大量客户端时出现的磁盘IO瓶颈,这些瓶颈在线程开始locking时发生,因为操作系统告诉他们等待当前正在执行的使用所有可用IO的线程处理。

我没有任何基准来certificate这些数据,尽pipe我最近的应用程序正在使用数据库日志logging。 这将有一个这样的答复中提到的失败安全。 如果数据库连接不能创build,创build本地数据库(h2也许?)并写入。 然后,我们可以定期检查数据库连接,重新build立连接,转储本地数据库,并将其推送到远程数据库。

如果您没有医pipe局网站,可以在下class时间进行。

在未来的某个时候,我希望制定基准来certificate我的观点。

祝你好运!

如果数据库是生产数据库,这是一个可怕的想法。 您在备份,复制和恢复方面遇到问题。 像更多的存储本身,副本,如果有的话,和备份。 有更多的时间来设置和恢复复制,更多的时间来validation备份,更多的时间从备份恢复数据库。