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