代码之家 › 专栏 › 技术社区 › John M Gant aman_novice

单独的生产数据库用于日志记录

logging database

John M Gant aman_novice · 技术社区 · 15 年前

我有一个正在测试的应用程序,它将部门Windows窗体应用程序的事件记录到SQL Server数据库中。应用程序几乎可以投入生产。日志数据库与应用程序数据库完全分离。

我的问题是,我真的需要创建日志数据库的生产版本吗,或者我可以只将生产和测试事件记录到同一个数据库中吗?显而易见的答案是肯定的,当然我需要一个单独的数据库。您永远不希望测试和生产环境混合在一起。但在这种情况下,写入数据库的数据实际上不是生产确切地说,数据只是记录我们用来解决问题的详细信息。它没有业务价值,如果无意中删除数据或数据库暂时不可用,也不会丢失任何重要信息。把它们都放在测试环境中会让我管理起来更简单。

因此,基于优缺点,为所有环境使用一个日志数据库似乎是一个更好的解决方案。但感觉不太对劲。有人能告诉我为什么这是个坏主意吗?

4 回复 | 直到 15 年前

HLGEM 15 年前

如果您的dev服务器关闭,您的日志记录可能不起作用,但prod不起作用。可以保证,当您需要登录prod的某些关键事件发生时,日志记录将起作用。在我们的例子中,prod和dev不在同一物理位置,这意味着在我们的网络上发送日志数据,并导致管道瓶颈和网络怪人。

另外,如果您决定更改日志记录过程呢?当您进行新的开发时,整个生产过程可能会中断。

有时会有人读日志,对某些错误感到恐慌,忘记它发生在dev上,或者更糟的是,有人可能会看到一个他们认为发生在dev上的错误,而这个错误确实发生在prod上。

John Gietzen 15 年前

我会说:

使用标准方法来记录(单个DLL或类似的方法),并在生产中实际存储日志数据库。

这样,您的日志数据库就可以被视为“日志服务器”,所有应用程序(dev、staging、test和prod)都可以登录到它,因为您使用的是经过审查的库。

当然,你还是要注意不要让服务器泛滥…

Aaron Alton 15 年前

我觉得把它放在开发人员的盒子里没什么问题, 除非如果您的应用程序无法正确登录,或者除非正在记录的信息比您所指示的更有价值,否则它将失败。

好处是,将日志数据库保存在dev服务器上将有助于减轻从生产服务器处理这些数据的负担——这在性能方面是一个明确的优势。

Artel 15 年前

将日志保存在数据库上首先是一个坏主意。当您由于某种原因无法连接到数据库时会发生什么?我建议您使用log4net并实现RollingFileAppenders。它们将日志条目写入一个文件,当该文件达到某个限制时,log4net开始写入一个新文件。如果您对设置有疑问,请随时询问。我很乐意帮忙!