使用SQL Server进行应用程序日志记录.优点缺点? [英] Using a SQL Server for application logging. Pros/Cons?
问题描述
我有一个多用户应用程序，该应用程序保留用于活动的集中式日志文件.现在，该日志记录正在进入文本文件，大约每天10MB-50MB.记录器每天轮换一次文本文件，我们保留过去4或5天的价值.比这更旧对我们来说没什么意义.
很少阅读它们:在开发用于错误消息，诊断消息的应用程序时，或者在应用程序正在生产中以对用户报告的问题或错误进行分类的情况下.
(严格来说，这是应用程序日志.安全日志记录保存在其他位置.)
但是，当他们被阅读时，他们的确很痛苦.即使使用Perl，也无法容纳10MB的文本文件:文件中的字段(事务ID，用户ID等)很有用，而仅仅是文本.消息是顺序写的，一次写一次，因此，在尝试跟踪特定事务或用户时，交错的活动会混合在一起.
我正在寻找有关该主题的想法.有人用SQL数据库完成了应用程序级日志记录并喜欢吗?讨厌吗?
我认为直接登录数据库通常不是一个好主意，我会避免使用它.
主要原因是:一旦错误已经发生并且您无法重现，那么当您可以使用它来调试应用程序的验尸时，一个好的日志将是最有用的.为此，您需要确保日志记录本身是可靠的.为了使任何系统都可靠，一个好的开始就是保持简单.
因此，当您将来使用一个简单的基于文件的日志且只有几行代码(打开文件，追加行，关闭文件或保持打开状态，重复...)时，通常会更可靠，更有用.确实需要它来工作.
另一方面，要成功登录到SQL Server，将需要更多组件才能正常工作，并且在许多错误情况下，您将无法记录所需信息，这仅仅是因为日志基础架构本身将无法正常工作.更糟糕的是:日志过程中的故障(例如数据库损坏或死锁)可能会影响应用程序的性能，然后您将遇到辅助组件阻止应用程序执行其主要功能的情况. /p>
如果您需要对日志进行大量分析，并且不习惯使用基于文本的工具(例如grep)，则将日志保存在文本文件中，并定期将其导入到SQL数据库中.如果SQL失败，您将不会丢失任何日志信息，甚至不会影响应用程序的功能.然后，您可以在数据库中进行所有数据分析.
我认为这些是我不记录数据库的主要原因，尽管我过去已经这样做过.希望对您有所帮助.
I have a multi-user application that keeps a centralized logfile for activity. Right now, that logging is going into text files to the tune of about 10MB-50MB / day. The text files are rotated daily by the logger, and we keep the past 4 or 5 days worth. Older than that is of no interest to us.
They're read rarely: either when developing the application for error messages, diagnostic messages, or when the application is in production to do triage on a user-reported problem or a bug.
(This is strictly an application log. Security logging is kept elsewhere.)
But when they are read, they're a pain in the ass. Grepping 10MB text files is no fun even with Perl: the fields (transaction ID, user ID, etc..) in the file are useful, but just text. Messages are written sequentially, one like at a time, so interleaved activity is all mixed up when trying to follow a particular transaction or user.
I'm looking for thoughts on the topic. Anyone done application-level logging with an SQL database and liked it? Hated it?
I think that logging directly to a database is usually a bad idea, and I would avoid it.
The main reason is this: a good log will be most useful when you can use it to debug your application post-mortem, once the error has already occurred and you can't reproduce it. To be able to do that, you need to make sure that the logging itself is reliable. And to make any system reliable, a good start is to keep it simple.
So having a simple file-based log with just a few lines of code (open file, append line, close file or keep it opened, repeat...) will usually be more reliable and useful in the future, when you really need it to work.
On the other hand, logging successfully to an SQL server will require that a lot more components work correctly, and there will be a lot more possible error situations where you won't be able to log the information you need, simply because the log infrastructure itself won't be working. And something worst: a failure in the log procedure (like a database corruption or a deadlock) will probably affect the performance of the application, and then you'll have a situation where a secondary component prevents the application of performing it's primary function.
If you need to do a lot of analysis of the logs and you are not comfortable using text-based tools like grep, then keep the logs in text files, and periodically import them to an SQL database. If the SQL fails you won't loose any log information, and it won't even affect the application's ability to function. Then you can do all the data analysis in the DB.
I think those are the main reasons why I don't do logging to a database, although I have done it in the past. Hope it helps.
这篇关于使用SQL Server进行应用程序日志记录.优点缺点?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
