Logging
In its most basic form, logging for web services needs to have a few important pieces of information: some way to identify which request a log message was generated from, a time stamp stored in UTC, the severity of the log message (i.e., if it is a fatal error, error, warning, informational, or diagnostic), and finally the message text itself. It should be possible to quickly scan through any file-based log to collect all the messages that were relevant to a given user request. Logging must be thread safe and cannot impose a performance penalty in highly threaded environments.
The goal in implementing logging within Harmony Core has been to ensure that logging calls are as cheap as possible when the relevant logging level is disabled. This means that, as an overall philosophy, users of the library and the library itself should not be making expensive calls as part of the parameters to a logging call. Expensive calls can be hidden within Object.ToString(), where the cost is deferred until it has been decided to perform the logging operation.
- File - This is a streaming JSON file, which is human readable and machine readable. Since we include the session ID in the JSON object, it is very easy to choose a session ID and get all of the relevant messages for it.
- Console - This very simple mechanism for logging makes development easier. The debugger doesn't need to be attached, it is fast, and you don't need to reload the log file constantly.
- Event Log - This log type should only be used for very important errors. Not only is this the most expensive log entry type, it can quickly overwhelm an IT admin with Event Viewer entries.
- Debug View - These log messages are only visible when a debugger or Debug Viewer is attached to the process.