-
Notifications
You must be signed in to change notification settings - Fork 248
Guidelines
- Log using the correct
LogLevel- see below for descriptions - Log useful information:
- Reviewing the logs should lead to the cause of any errors that may have occurred
- The logs should be easy to navigate without having to filter through irrelevant information
- Redundant logging should be avoided
- Keep log messages short and concise without sacrificing quality of information
- Be mindful of where you are logging from within the pipeline of the application - no one wants to look at a single log that’s been nested inside 10 scopes.
- Although the loggers will not log if disabled, adding code guards before logging can reduce the overhead of an extra method call.
- Name your loggers with a distinct prefix so they can easily be filtered or disabled. Using the Create<T> extension when creating loggers will name your logger with the full name of the class. For example, loggers in MVC are prefixed with “Microsoft.Aspnet.Mvc”.
The most detailed log messages, may contain sensitive application data. These messages are disabled by default and should never be enabled in a production environment.
It is not recommended that you log sensitive information like passwords to any log level in your application, but frameworks such as Entity Framework will use this level when they are logging things like SQL Statements which could contain sensitive data depending on the queries.
example: inserting row in Users table: { "FirstName":"Luke", "LastName":"Waters" }
Logs that are used for interactive investigation during development should use the Debug level. These logs should primarily contain information useful for debugging and have no long-term value.
This is the default most verbose level of logging.
example: method x was called with parameter y
Track the general flow of the application using logs at the Information level. These logs should have value in the long term.
Common situations to log:
- startup configuration settings
- entry/exit points
- changes to data
examples: user JohnDoe created an account, an entry was added to the User database
Warnings should highlight an abnormal or unexpected event in the application flow. This event does not cause the application execution to stop, but can signify sub-optimal performance or a potential problem for the future. A common place to log a warning is from handled exceptions.
examples: invalid authentication, low disk space
An error should be logged when the current flow of execution is stopped due to a failure. These should indicate a failure in the current activity, not an application-wide failure. These will mainly be unhandled exceptions and recoverable failures.
example: failure to execute or process a task
A critical log should describe an unrecoverable application or system crash, or a catastrophic failure that requires immediate attention.
examples: data loss, stack overflow
A logging event may specify an integer event id. Event ids should uniquely identify a logging publication call site within a logging category (i.e. the name passed to ILoggerFactory.CreateLogger when creating the logger instance).