登录到文本文件或数据库？

什么时候应该使用数据库记录日志，何时使用文本文件？
我看到默认情况下，Web服务器和Web框架（您的应用程序在内部使用）通常（总是？）将请求和错误记录到文本文件中。但是我看到围绕这些服务器和框架开发应用程序的人有时会登录数据库（甚至是应用程序的主数据库，而不是某些外部数据库）。
另外，调试日志和审核日志之间可能会有区别-我已经在此站点的某处阅读了此分类。

一般而言，登录到文本文件比登录数据库快得多。这是您需要考虑的日志记录的主要方面。

登录数据库的原因很可能是因为您要查询结果-在数据库中搜索特定的日志信息更加容易，尤其是当您记录可用于将日志条目分组在一起的上下文信息时。访问中央数据库通常比服务器上的日志文件更容易访问，因为日志文件可能是安全的并且无法访问。

理想的做法是本地登录到文件，然后再将此数据迁移到DB进行检查（如果需要）。

现在，审计完全是另一回事了。尽管在概念上与日志记录相似，但是通常需要将审计保留很​​长时间（与用于调试或跟踪的日志文件可能会一时删除）不同。审核可以显示重要信息。与正常的日志记录相比，您记录的审计信息少得多，而且记录的频率也少，因此性能不是问题。因此，可以看到将审核信息写入中央数据库的好处。

没有一种适合所有方法的规模，而为了实现弹性，您有时可能希望使用多种方法。以您的示例为例，您可能希望将调试日志存储在文件中，并将审核日志存储在数据库中。

应用程序屑

优点：易于实施，并且对用户立即可见

缺点：信息仅在应用程序启动时持续存在

文本文件

优点：易于实施

缺点：需要确保不会发生文件锁定。日志驱动器上的磁盘空间用完时该怎么办？

事件簿

优点：易于实施

缺点：如果未正确设置，事件日志可能已满，或者由于保留策略/清除而导致旧日志丢失。

数据库

优点：易于实施

缺点：更多的数据库流量。如何记录数据库丢失或其他数据库问题？

讯息（MQ）

优点：忘却

缺点：另一层出了问题。需要设置

审核日志必须确保出于审计目的可以在更长的时间内完全跟踪操作，目的是完全证明数据库的内容合理。

在某些情况下（例如财务申请），这些日志可能必须确保遵守法律要求，例如保留（在某些国家/地区为10年）或不可更改。由于这些日志必须在应用程序级别证明数据库内容的合理性，因此通常将它们存储在数据库中，在数据库中可以控制访问以避免未经授权的更改。

其他日志（例如监视日志或安全日志）经常必须应对性能和容量限制。通常将它们写入文件，因为写入速度更快（无事务管理开销），脱机归档更容易，并且更易于与外部监视SIEM工具集成。

应当指出的是，尽管这些日志可以用来证明审计日志的可靠性（例如，没有未经授权的访问），但是它们通常具有较短的保留限制（例如，出于电信日志的执法目的，在6个月至2年之间）如果有任何限制。

使用db进行调试日志记录的许多原因之一是当您无权访问应用程序或Web服务器来查看事件查看器或文本文件时

在Web应用程序的上下文中，审核日志与调试日志不同，因为在某些应用程序中，您可能需要将它们显示给最终用户，以便将它们放入数据库中以便于检索。

您也可以使用数据库工具进行过滤和轻松查看。