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

Question

阅读有关O'主题的文章后Reilly ，我想问Stack Overflow对此事的看法。

Answer 1

本地写入磁盘，然后定期批量插入数据库（例如，在日志翻转时）。在单独的低优先级流程中执行此操作。效率更高，更健壮......

（确保您的数据库日志表包含<！>的列;顺便说一下，该日志事件来自哪个机器<！>;顺便说一句，非常方便！）

Answer 2

我会说不，因为相当大比例的服务器错误涉及与数据库通信的问题。如果数据库位于另一台计算机上，则网络连接将成为无法记录的另一个错误源。

如果我要将服务器错误记录到数据库，那么在数据库无法访问的情况下，使用本地写入的备份记录器（到事件日志或文件或其他内容）至关重要。

Answer 3

如果可以，请记录到数据库并且不会减慢数据库速度：）

这样可以更快地在日志文件中找到DB中的任何内容。特别是如果你提前考虑你需要什么。登录db让你查询日志表如下：

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

然后在找到错误后，您可以看到导致此错误的整个路径

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

如果您将其记录在文本文件中，您将如何获得此信息？

修改 正如JonSkeet所说，如果我说应该考虑将数据库记录到db异步，那么这个答案会更好。所以我说出来:)我只是不需要它。例如，如何操作，你可以检查<！>“Ultra Fast ASP.NET <！>”;作者：Richard Kiessig。

Answer 4

如果数据库是生产数据库，这是一个可怕的想法。 您将在备份，复制和恢复方面遇到问题。就像DB本身，副本（如果有）和备份的更多存储一样。有更多时间来设置和恢复复制，有更多时间来验证备份，有更多时间从备份中恢复数据库。

Answer 5

如果你想在数据库中记录日志可能并不是一个坏主意，但如果你有很多日志文件条目，我会说不遵循文章的建议。主要问题是我看到文件系统存在问题，无法跟上来自繁忙站点的日志，更不用说数据库了。如果您真的想这样做，我会考虑在将日志文件首次写入磁盘后将其加载到数据库中。

Answer 6

考虑使用RAM进行读写的正确设置数据库？这比写入磁盘要快得多，并且在由于操作系统告诉他们等待正在使用所有可用IO的当前正在执行的线程而导致线程开始锁定时发生的大量客户端时，会出现磁盘IO瓶颈。处理

我没有任何基准来证明这些数据，尽管我的最新应用程序正在滚动数据库日志记录。这将具有其中一个响应中提到的故障保护。如果无法创建数据库连接，请创建本地数据库（可能是h2？）并写入该数据库。然后我们可以定期检查数据库连接，重新建立连接，转储本地数据库，并将其推送到远程数据库。

如果您没有H-A网站，可以在非工作时间完成。

未来的某个时候，我希望制定基准以证明我的观点。

祝你好运！