将服务器日志文件写入数据库是一个好的想法吗？

Question

阅读了O'Reilly关于该主题的文章后，我想询问Stack Overflow他们对此问题的看法。

- Thomas Owens

---

请查看此问题：https://dev59.com/J3VC5IYBdhLWcg3wsTfv - Joel Coehoorn

链接失效.... - T30

Answer 1

将数据先本地写入磁盘，然后定期批量插入到数据库（例如在日志轮换时间）。此操作应在一个单独的低优先级进程中执行，更高效且更可靠...

顺便提一下，确保你的数据库日志表包含“日志事件来自哪台机器”的列 - 这非常方便！

- Jon Skeet

---

那不意味着数据库中的日志信息总是过时的吗？因此，它主要作为存档而非诊断最近问题的工具。 - MusiGenesis

当然，你可以尝试变得更聪明——如果你记录了任何“重要”的内容，收集器/插入器可以更早地刷新到数据库 :) - Jon Skeet

似乎太复杂了。 - Piotr Perak

@Peri：这并不复杂。如果你有相当数量的日志记录，直接写入数据库的建议很可能会对性能产生非常显著的影响。你真的不想陷入这样一种情况：每个日志调用都需要涉及到数据库往返，因此无法添加更多的诊断信息。 - Jon Skeet

有时候，评论可以为主题提供很多深刻的见解！ - Swapnil

Answer 2

我会说不推荐这样做，因为相当大比例的服务器错误都涉及到与数据库通信出现问题。如果数据库在另一台机器上，网络连接也将成为无法记录的错误来源。

如果我要将服务器错误记录到数据库中，就需要关键性地准备备份日志程序，以便在数据库无法访问时本地写入（事件日志或文件等）。

- MusiGenesis

---

那是一个很好的观点。当然，在记录日志之前检查一切是否正常是可行的，但如果检查后发生了什么怎么办？或者在检查后如何处理要记录的数据？这篇文章中没有涉及到的两个问题，至少在我看来是这样的。 - Thomas Owens

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”。

- Piotr Perak

Answer 4

如果这个数据库是生产数据库，那么这是一个可怕的想法。你将会遇到备份、复制和恢复等问题。例如，需要更多的存储空间来存储数据库本身、副本（如果有的话）以及备份。设置和恢复复制需要更多时间，验证备份需要更多时间，从备份中恢复数据库需要更多时间。

- user933161

---

肯定有一种方法可以在备份时忽略某些表格吧？ - Corey Cole

Answer 5

如果您想将日志记录到数据库中，这可能不是一个坏主意，但是如果您有大量的日志文件条目，则建议不要按照文章的建议进行操作。 主要问题是，我发现文件系统在处理来自繁忙站点的日志时甚至无法跟上，更不用说数据库了。 如果您真的想这样做，我建议在日志文件首次写入磁盘后将其加载到数据库中。

- carson

Answer 6

想象一下一个正确设置的数据库，利用RAM进行读写？这比写入磁盘快得多，并且不会出现磁盘IO瓶颈，当服务大量客户端时，线程开始锁定，因为操作系统告诉它们等待当前正在使用所有可用IO句柄的线程。

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

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

未来我希望开发基准来证明我的观点。

祝好运！

- Andrew Carr