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

Question

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

Answer 1

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

（顺便说一句，请确保您的数据库日志表包含“日志事件来自哪台机器”的列 - 非常方便！）

Answer 2

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

如果我要将服务器错误记录到数据库中，那么拥有一个在本地写入（写入事件日志或文件或其他内容）的备份记录器至关重要，以防数据库无法访问。

Answer 3

如果可以的话，记录到数据库，它不会减慢您的数据库:)

在数据库中查找任何内容比在日志文件中查找任何内容要快得多。 特别是如果您提前考虑您需要什么。 登录数据库让您像这样查询日志表：

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 所建议的，如果我指出应该考虑将日志记录到数据库异步，那么这个答案会更好。 所以我声明了:)我只是不需要它。 例如，如何做到这一点，您可以查看 Richard Kiessig 的“Ultra Fast ASP.NET”。

Answer 4

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

Answer 5

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

Answer 6

考虑一下正确设置的数据库，利用 RAM 进行读取和写入吗？ 这比写入磁盘要快得多，并且不会出现在为大量客户端提供服务时出现的磁盘 IO 瓶颈，这种瓶颈是在线程开始锁定时发生的，因为操作系统告诉它们等待正在使用所有可用 IO 的当前正在执行的线程手柄。

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

如果您没有 HA 站点，则可以在下班时间完成此操作。

将来的某个时候，我希望开发基准来证明我的观点。

祝你好运！