Viewing a log filtered to show only warnings and errors may give quick insight into early hints at the root cause of a subsequent error. For example, expected transient environmental conditions such as short loss of network or database connectivity should be logged as Warnings, not Errors. Warning: This MIGHT be problem, or might not. For example, this metric might help inform decisions about whether or not another beta testing cycle is needed before a release. Tracking error rates as versus application usage can yield useful quality metrics such as MTBF which can be used to assess overall quality.
By filtering a log to look at errors and above you get an overview of error frequency and can quickly identify the initiating failure that might have resulted in a cascade of additional errors. SysAdmin should be notified automatically, but doesn't need to be dragged out of bed. Typically, a Fatal error only occurs once in the process lifetime, so if the log file is tied to the process, this is typically the last message in the log.Įrror: Definitely a problem that should be investigated. If it's happening daily and that's not a BFD, it's lost it's meaning. Since we prefer our SysAdmins alert and well-rested, this severity should be used very infrequently. I find it more helpful to think about severities from the perspective of viewing the log file.įatal/Critical: Overall application or system failure that should be investigated immediately. I reserve these only for the most heinous errors and situations where there is guaranteed to have been data corruption or loss. Fatal - Any error that is forcing a shutdown of the service or application to prevent data loss (or further data loss).These are usually reserved (in my apps) for incorrect connection strings, missing services, etc. These errors will force user (administrator, or direct user) intervention. Error - Any error which is fatal to the operation, but not the service or application (can't open a required file, missing data, etc.).(Such as switching from a primary to backup server, retrying an operation, missing secondary data, etc.) Warn - Anything that can potentially cause application oddities, but for which I am automatically recovering.Info I want to always have available but usually don't care about under normal circumstances. Info - Generally useful information to log (service start/stop, configuration assumptions, etc).Debug - Information that is diagnostically helpful to people more than just developers (IT, sysadmins, etc.).Trace - Only when I would be "tracing" the code and trying to find one part of a function specifically.
I generally subscribe to the following convention:
0 kommentar(er)
