Components and Contexts

Working with Components and Contexts, Filter dialog

When a log message is created it falls under the umbrella of a component and a context. Practically speaking, a component or context per se is not much more than a text string that ultimately winds up being a field in the log message. These two fields are broken out into their own structures and treated as separate entities because there are some very powerful interpretations and operations that justify a little more sophistication than simply passing them in on the logging call as two more strings.

Generally speaking, components and contexts are used to group log messages together into logical sets so that they can be filtered out or disabled in code programatically and so that they can later be filtered or sorted in the viewer prefiltering vs. postfiltering. The component field of the log message is typically used to group messages into high level abstract categories such as 'The Database Server' where the database server may in fact consist of a couple exes and a handful of dlls and may even span machines. Alternatively, a context is typically a grouping by specific operation rather than functionality. Using the database server example, a context would be a unique text string that groups log messages by transaction. A context is typically not a lower level or higher level grouping in a hierarchical sense but rather an orthogonal grouping. In the database server example, the transaction may have started on a front end running on a machine in a different country with replication functionality triggering on various machines. This would involve many components such as the database server itself, the front end, connectivity servers, and etc. with the context being constant across all of them. In short, the component is typically used to group log messages by functionality (usually meaning 'a set of modules'), where the context groups messages by current operation (usually a transaction id, session id, user id, or similar).