Logging
In its most basic form, logging for web services needs to have a few important pieces of info included. Some way to identify what request a log message was generated from. A time stamp stored in UTC. The severity of the log message, meaning if its a fatal error, error, warning, info, or diagnostic. Finally you have to log the message text itself. It should be possible to quickly scan through any file based log to collect all of the messages that were relevant to a given user request. Logging must be threadsafe and cannot impose a performance penalty in highly threaded environments.
The goal in implementing logging within Harmony Core has been to ensure logging calls are as cheap as possible when the relevant logging level is disabled. This means 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 after its been decided to actually perform the logging operation or not.
- File - This is a streaming JSON file, its still very human readable but it has the added benefit of being machine readable. Since we include the session id in the JSON object its 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, its plenty fast and you dont need to reload a log file constantly.
- Event Log - This Log type should only be used for very important errors. Not only is it 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.