使用SQL Server进行应用程序日志记录 优点缺点?

前端之家收集整理的这篇文章主要介绍了使用SQL Server进行应用程序日志记录 优点缺点?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我有一个多用户应用程序,保持一个集中的日志文件的活动。现在,日志记录将进入大约10MB-50MB /天的文本文件。文本文件每天由记录器旋转,我们保留过去4或5天的价值。比这更老,对我们没有兴趣。

他们很少阅读:在开发应用程序的错误消息,诊断消息或应用程序正在生产中对用户报告的问题或错误进行分类时。

(这是一个严格的应用程序日志,安全记录保存在其他地方。)

但是当他们被阅读时,他们是屁股的痛苦。即使使用Perl,即使使用Perl也可以使用10MB的文本文件文件中的字段(事务ID,用户ID等)很有用,但只是文本。消息按顺序写入,一次像一次一样,因此当尝试跟踪特定事务或用户时,交错的活动都被混合在一起。

我正在寻找关于这个话题的想法。任何人使用sql数据库完成应用程序级日志记录并且喜欢它?讨厌吗

解决方法

我认为直接记录到数据库通常是一个坏主意,我会避免它。

主要原因是这样的:一旦出现错误,您就可以使用它来调试您的应用程序验证后,一个好的日志将是最有用的。为了能够做到这一点,你需要确保记录本身是可靠的。为了使任何系统可靠,一个好的开始是保持简单。

所以有一个简单的基于文件的日志只需几行代码(打开的文件,附加行,关闭文件或保持打开,重复…)通常会更加可靠和有用的将来,当你真的需要它上班。

另一方面,成功记录到sql服务器将要求更多组件正常工作,并且将会有更多可能的错误情况,您将无法记录所需的信息,只是因为日志基础设施本身不会工作。最糟糕的是:日志过程中的故障(如数据库损坏或死锁)可能会影响应用程序的性能,然后您将遇到一个次要组件阻止应用程序执行其主要功能的情况。

如果您需要对日志进行大量分析,并且您不舒服使用基于文本的工具(如grep),请将日志保存在文本文件中,并定期将其导入sql数据库。如果sql失败,则不会丢失任何日志信息,甚至不会影响应用程序的功能。那么可以在数据库中进行所有的数据分析。

我认为这些是为什么我不记录到数据库的主要原因,尽管我以前做过这一切。希望它有帮助。

猜你在找的MsSQL相关文章