您需要区分日志记录和跟踪。虽然线条有点模糊,但我倾向于将日志记录视为“非开发人员的东西”。诸如未处理的异常、损坏的文件等。这些绝对是不正常的,应该是一个非常罕见的问题。
跟踪是开发人员感兴趣的。堆栈跟踪、方法参数、Web 服务器返回的 HTTP 状态为 401.3 等。这些确实很嘈杂,并且可以在短时间内产生大量数据。通常我们有不同级别的跟踪,以减少噪音。
对于登录客户端应用程序,我认为事件日志是要走的路(我必须仔细检查,但我认为 ASP.NET 健康监控也可以写入事件日志)。普通用户有权写入事件日志,只要您有安装程序(无论如何都由管理员安装)创建事件源。
Sql 日志记录的大部分优势虽然是真的,但不适用于事件日志记录:
- 可以处理大量数据:
您是否真的有大量未处理的异常或其他高级故障?
- 可以处理快速大量插入的异常:一个未处理的异常应该会让你的应用程序崩溃——它本质上是速率受限的。其他对非开发人员感兴趣的事件也应该类似地汇总。
- 非常可定制:事件日志中的消息几乎是自由文本。如果您需要更多信息,只需指向文本或结构化 XML 或二进制文件日志
- 从 SQL 存储中构建报告/通知更容易一些:报告内置于事件日志查看器中,并且通知系统是固有的 - 由于应用程序崩溃 - 或与其他非常重要的通知混合 - 没有什么借口缺少事件日志消息。对于企业或其他联网应用程序,已经从事件日志中剔除一千零一个不同的应用程序以查找错误......您的系统管理员可能已经在使用一个。
对于跟踪,其中包含异常或错误的具体细节,我喜欢平面文件 - 它们易于维护,易于 grep,如果我愿意,可以导入 Sql 进行分析。
90% 的情况下,您不需要它们,它们被设置为 WARN 或 ERROR。但是,当您将它们设置为 INFO 或 DEBUG 时,您将生成大量数据。RDBMS 有很多开销——性能(ACID、并发等)、存储(事务日志、SCSI RAID-5 驱动器等)和管理(备份、服务器维护等)——所有这些都是跟踪日志是不必要的。