你的伐木理念是什么？

正如杰夫·阿特伍德问:"什么是你的日志哲学应该所有代码被散落？.logthis()和.logthat()来电或你在事后注入记录不知何故？"

我的记录理念很容易归纳为四个部分:

审计或业务逻辑日志记录

记录需要记录的内容.这来自应用程序要求,可能包括记录对任何数据库(如许多财务应用程序)所做的每个更改或记录对数据的访问(可能需要在健康行业中满足行业法规)

由于这是程序要求的一部分,许多人不会将其包含在日志记录的一般性讨论中,但是这些领域存在重叠,对于某些应用程序,将所有日志记录活动一起考虑是有用的.

程序记录

有助于开发人员测试和调试应用程序的消息,更容易遵循数据流和程序逻辑,以了解可能存在的实现,集成和其他错误.

通常,根据调试会话的需要打开和关闭此日志记录.

性能记录

根据需要添加以后的日志记录,以查找和解决性能瓶颈和其他程序问题,这些问题不会导致程序失败,但会导致更好的操作.在内存泄漏和一些非严重错误的情况下,使用程序记录重叠.

安全日志

记录用户操作以及与安全性有关的外部系统的交互.用于确定攻击者在攻击后如何破坏系统,但也可能与入侵检测系统绑定以检测新的或持续的攻击.

我使用安全关键的实时系统和记录通常是捕获罕见错误的唯一方法,如果你抓住我的漂移,它只会在满月时每隔53周出现一次.这种让你对这个主题的迷恋,所以如果我开始在嘴里泡沫,我现在会道歉.

我设计的系统几乎可以记录所有内容,但我没有默认打开所有内容.调试信息被发送到隐藏的调试对话框,该对话框将其加时间戳并将其输出到列表框(删除前限制为大约500行),对话框允许我将其停止,自动将其保存到日志文件或转移到附加的调试器,如DBWin32.这种转移使我能够看到来自多个应用程序的调试输出都整齐地序列化,有时可以节省生命.每N天自动清除日志文件.我用用数字日志记录级别(您设置的级别越高,你越捕捉):

离

只有错误

基本

详细

一切

但这太不灵活了 - 当你朝着一个错误的方向前进时,能够更加高效地集中登录你需要的东西,而不必跋涉大量的碎屑,它可能是一种特殊的交易或操作这会导致错误.如果这需要你打开一切,你只是让自己的工作变得更难.你需要更精细的东西.

所以现在我正在切换到基于标志系统的日志记录.记录的所有内容都有一个标志,详细说明它是什么类型的操作,并且有一组复选框允许我定义记录的内容.通常,该列表如下所示:

#define DEBUG_ERROR          1
#define DEBUG_BASIC          2
#define DEBUG_DETAIL         4
#define DEBUG_MSG_BASIC      8
#define DEBUG_MSG_POLL       16
#define DEBUG_MSG_STATUS     32
#define DEBUG_METRICS        64
#define DEBUG_EXCEPTION      128
#define DEBUG_STATE_CHANGE   256
#define DEBUG_DB_READ        512
#define DEBUG_DB_WRITE       1024
#define DEBUG_SQL_TEXT       2048
#define DEBUG_MSG_CONTENTS   4096

此日志记录系统随附发布版本,默认情况下已打开并保存到文件.现在发现你应该在发生错误之后进行日志记录已经太晚了,如果这个错误平均每六个月发生一次并且你无法复制它.

该软件通常附带ERROR,BASIC,STATE_CHANGE和EXCEPTION,但可以通过调试对话框(或者注册表/ ini/cfg设置,这些内容得到保存)在现场更改.

哦,还有一件事 - 我的调试系统每天生成一个文件.您的要求可能有所不同.但请确保您的调试代码启动每个文件,其中包含您正在运行的代码的日期,版本,以及可能的客户ID,系统位置或其他任何标记.你可以从现场获得一些混合的日志文件,你需要记录一下来自哪里以及它们运行的​​系统版本实际上是在数据本身中的什么,你不能相信客户/现场工程师告诉你他们有什么版本 - 他们可能只是告诉你他们认为他们有什么版本.更糟糕的是,他们可能会报告磁盘上的exe版本,但旧版本仍在运行,因为他们在更换后忘记重新启动.让你的代码告诉你自己.

那是我的大脑倾倒......