我有一个多用户应用程序，它为活动保留一个集中的日志文件。目前，该日志记录正在以大约 10MB-50MB / 天的速度进入文本文件。文本文件由记录器每天轮换，我们保留过去 4 或 5 天的价值。我们不感兴趣。
它们很少被阅读：无论是在为错误消息、诊断消息开发应用程序时，还是在应用程序在生产中对用户报告的问题或错误进行分类时。
（这严格来说是一个应用程序日志。安全日志保存在其他地方。）
但是当他们被阅读时，他们是一个痛苦的屁股。即使使用 Perl 也不是什么有趣的 10MB 文本文件：文件中的字段（事务 ID、用户 ID 等）很有用，但只是文本。消息是按顺序写入的，一次一个，因此在尝试跟踪特定事务或用户时，交错的活动都会混淆。
我正在寻找有关该主题的想法。有人使用 SQL 数据库完成应用程序级日志记录并喜欢它吗？讨厌它？
我认为直接记录到数据库通常是一个坏主意，我会避免它。
主要原因是：一个好的日志在您可以使用它来调试您的应用程序事后检查时最有用，一旦错误已经发生并且您无法重现它。为此，您需要确保日志记录本身是可靠的。为了使任何系统可靠，一个好的开始就是保持简单。
因此，只需几行代码（打开文件、追加行、关闭文件或保持打开状态、重复...），当您真正需要时，拥有一个简单的基于文件的日志通常会更加可靠和有用去工作。
另一方面，成功地记录到 SQL 服务器将需要更多的组件正常工作，并且将有更多可能的错误情况，您将无法记录所需的信息，这仅仅是因为日志基础架构本身不会工作。最糟糕的是：日志过程中的故障（如数据库损坏或死锁）可能会影响应用程序的性能，然后您将遇到次要组件阻止应用程序执行其主要功能的情况。
如果您需要对日志进行大量分析，并且您不习惯使用 grep 等基于文本的工具，则将日志保存在文本文件中，并定期将它们导入 SQL 数据库。如果 SQL 失败，您不会丢失任何日志信息，甚至不会影响应用程序的运行能力。然后您可以在数据库中进行所有数据分析。
我认为这些是我不记录到数据库的主要原因，尽管我过去做过。希望能帮助到你。
我们在上一份工作中使用了一个日志数据库，它很棒。
我们有存储过程，可以为我可以从网页加载的不同指标提供一般系统健康状况的概述。我们还可以在给定的时间段内快速为给定的应用程序吐出跟踪，如果我想要它很容易得到一个文本文件，如果你真的只是喜欢 grep-ing 文件。
为了确保日志系统本身不会成为问题，当然我们在不同的应用程序中使用了一个通用的代码框架来处理日志表的写入。该框架的一部分还包括记录到文件，以防问题出在数据库本身，其中一部分涉及循环日志。至于空间问题，日志数据库的备份计划不同，这真的不是问题。空间（未备份）很便宜。
我认为这解决了其他地方表达的大部分担忧。这都是执行的问题。但是，如果我在这里停下来，那仍然是“不会更糟”的情况，这是麻烦设置数据库日志记录的一个不好的理由。我喜欢它的地方在于它允许我们做一些对平面文件来说更难做的新事情。
文件有四个主要改进。首先是我已经提到的系统概述。第二个，也是最重要的，是检查是否有任何应用程序丢失了我们通常期望找到的消息。这种事情在传统的文件记录中几乎是不可能发现的，除非你每天花费大量时间查看那些在 99% 的情况下告诉你一切正常的应用程序的令人麻木的日志。令人惊奇的是如何释放视图以显示丢失的日志条目。大多数时候，我们根本不需要查看大多数日志文件……如果没有数据库，这将是危险和不负责任的。
这带来了第三个改进。我们生成了一封每日状态电子邮件，这是我们在一切正常运行的日子里唯一需要查看的内容。包含的电子邮件显示错误和警告。发送电子邮件的同一个数据库作业将丢失的日志重新记录为警告，并且丢失电子邮件是一件大事。我们可以在每日电子邮件中一键将特定日志消息转发到我们的错误跟踪器（它是 html 格式的，从网络应用程序中提取数据）。
最后的改进是，如果我们确实想更密切地关注特定应用程序，比如在进行更改后，我们可以订阅该特定应用程序的 RSS 提要，直到我们满意为止。从文本文件中更难做到这一点。
我现在所处的位置，我们更多地依赖第三方工具及其日志记录能力，这意味着要回到更多的人工审查。我真的很想念数据库，我正在考虑编写一个工具来读取这些日志并将它们重新记录到数据库中以恢复这些能力。
同样，我们使用文本文件作为后备来执行此操作，而真正使数据库有价值的是新功能。如果您要做的只是写入数据库并尝试以与旧文本文件相同的方式使用它，它会增加不必要的复杂性，您不妨只使用旧文本文件。为新功能构建系统的能力使其值得。
是的，我们在这里做，我受不了。我们在这里遇到的一个问题是，如果数据库出现问题（连接、损坏等），所有日志记录都会停止。我的另一个大问题是很难通过追踪问题。我们也遇到了表日志占用太多空间的问题，并且在移动数据库时不得不担心截断它们，因为我们的日志太大了。
与日志文件相比，我认为它很笨重。我发现很难看到存储在数据库中的“大图”。我承认我是一个日志文件的人，我喜欢能够打开一个文本文件并通过（正则表达式）它而不是使用 sql 来尝试搜索一些东西。
我工作的最后一个地方有超过 100 兆的日志文件。它们有点难以打开，但如果你有正确的工具，它还不错。我们也有一个记录消息的系统。您可以快速查看文件并确定哪组日志条目属于哪个进程。
我们之前使用过 SQL Server 集中式日志记录，如前文所述，最大的问题是与数据库的连接中断意味着日志记录中断。实际上，我最终在日志记录中添加了一个排队例程，该例程将首先尝试 DB，如果失败则写入物理文件。您只需将代码添加到该例程中，在成功登录到数据库时，将检查是否有任何其他条目在本地排队，然后也写入。
我喜欢将所有东西都放在数据库中，而不是物理日志文件，但这只是因为我喜欢用我写的报告来解析它。
我认为日志记录问题可以通过将日志记录到 SQL 来解决，前提是您能够将感兴趣的字段拆分为不同的列。您不能将 SQL 数据库视为文本字段并期望它会更好，但事实并非如此。
一旦您将所有您感兴趣的内容都记录到您想要的列中，通过能够按列隔离某事物，跟踪某事物的顺序操作就容易得多。就像您有一个“进入”流程一样，您通常会记录所有内容，并将文本“进入流程”放入“logtype”列或“process”列。然后，当您遇到“进入流程”问题时，该列上的 WHERE 语句将隔离所有进入流程。
我们在我们的组织中使用 SQL Server 大量执行此操作。由于搜索和过滤功能，在我的开放中写入数据库更好。性能方面 10 到 50 MB 的数据并仅保留 5 天，不会影响您的应用程序。与从文本文件中跟踪交易相比，跟踪交易和用户将非常容易，因为您可以按交易或用户进行过滤。
您提到文件很少读取。那么，决定是否值得花时间开发日志框架？计算一年中从日志文件中搜索日志所花费的时间与编码和测试所需的时间。如果每天花费 1 小时或更多时间来搜索日志，最好将日志转储到数据库中。这可以大大减少解决问题的时间。
如果您花费不到一个小时，那么您可以使用一些文本搜索工具，例如“SRSearch”，这是我使用的一个很棒的工具，从文件夹中的多个文件中搜索并以小片段的形式为您提供结果（“如谷歌搜索结果")，您可以在此处单击以打开感兴趣的结果的文件。还有其他可用的文本搜索工具。如果环境是 windows，那么你有 Microsoft LogParser 也是一个很好的免费工具，如果文件是以特定格式编写的，你可以像数据库一样查询文件。
以下是一些额外的优点和缺点，以及我更喜欢日志文件而不是数据库的原因：
使用 VPS 时，空间并不便宜。在实时数据库系统上恢复空间通常很麻烦，您可能必须在恢复空间时关闭服务。如果您的日志非常重要，以至于您必须将它们保存多年（就像我们一样），那么这是一个真正的问题。请记住，当您删除数据时，大多数数据库不会恢复空间，因为它只是重新使用空间 - 如果您实际上空间不足，则没有多大帮助。
如果您经常访问日志，并且您必须从具有一个巨大日志表和数百万条记录的数据库中提取每日报告，那么您将在从数据库中查询数据时影响数据库服务的性能。
可以每天创建日志文件并归档旧日志。根据日志的类型，可以通过归档日志来回收大量空间。当我们压缩日志时，我们节省了大约 6 倍的空间，在大多数情况下，您可能会节省更多。
可以轻松压缩和传输单个较小的日志文件，而不会影响服务器。以前，我们在数据库中拥有 100 多 GB 数据的日志。在服务器之间移动如此大的数据库变得很麻烦，尤其是因为这样做时您必须关闭数据库服务器。我要说的是，在您必须开始移动大型数据库的那一天，维护变得非常痛苦。
写入日志文件通常比写入数据库快得多。不要小看你的操作系统文件 IO 的速度。
如果您没有正确构建日志，日志文件只会很糟糕。您可能必须使用其他工具，甚至可能需要开发自己的工具来帮助处理它们，但最终这将是值得的。
您可以将日志记录为逗号或制表符分隔的文本格式，或者将您的日志导出为 CSV 格式。当您需要从日志中读取 CSV 文件导出到 SQL 服务器上的表时，您可以使用标准 SQL 语句进行查询。要自动化该过程，您可以使用 SQL 集成服务。
我一直在阅读所有答案，它们很棒。但是在我工作的一家公司中，由于一些限制和审核，必须登录数据库。无论如何，我们有几种记录方式，解决方案是安装一个管道，我们的程序员可以连接到管道并登录到数据库、文件、控制台，甚至将日志转发到端口以供其他应用程序使用。此管道不会中断正常进程，并在您登录数据库的同时保留一个日志文件，确保您很少丢失一行。我建议您进一步调查 log4net，它对此非常有用。
我可以看到它运行良好，前提是您能够过滤需要记录的内容以及需要记录的时间。如果您找不到您要查找的内容或包含不必要的信息，则日志文件（或表，例如它）是无用的。
由于您的日志很少被读取，因此我会将它们写入文件（更好的性能和可靠性）。
然后，当且仅当您需要阅读它们时，我会将日志文件导入数据库（更好的分析）。
这样做，您将获得这两种方法的优势。