-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Although the concepts behind Semantic Logging are universal, this project builds a C# code example. It specifically brings in Microsoft provided packages in support of creating a solution with semantic logging as a component.
Semantic Logging (SL) is a framework for logging that is straightforward to adopt and use, but is a bit daunting in its documentation. Here is the quick definition given by Microsoft, "The term semantic logging refers specifically to the use of strongly typed events and the consistent structure of the log messages in the Semantic Logging Application Block."
The trouble is that it is desperately easy to think about logging as an and late in development of a project. SL is possible to refactor into place for an existing project, but benefits from an overall approach and plan.
While there are many reasons for adopting the approach, I'll bring forward those that I've not read or heard elsewhere.
In times past, it might have been true that a developer could work on code, and that things like logging were put in place either to supplement testing or to help a separate support organization. Neither of these things is likely in our DevOps and Continuous Integration organizations. Many (many!) developers are responsible for direct support of their work in production. DevOps has certainly benefitted from recognizing the virtuous cycle of bug reduction brought about by more careful development. Plus, Continuous Integration and the automated unit and integration testing implied, no longer have room for the lone developer manually "testing" by threading their way through a trace each time the project is built. Traces can be used for manual debugging, but manual testing is a thing of the past (good riddance!).
SL is an opportunity to develop "intention." Programming by intention drives separation of intent from implementation in code, making it more modular. Semantic Logging, when done properly, adds communication to the intent of the application code -- it communicates the "what" without getting bogged down in the "how." SL drives understanding because it affords another opportunity to consider what an application means to communicate about its events and actions.
Depending on what type of IT organization or company you work with, SL supports your wider organization by making log information structured (i.e. strongly typed) and therefore more available. Most organizations now require some level of centralized logging using Loggly, Splunk, or something else. But attempting to divine meaning from disorganized strings of text is a nightmare. Strongly typed log messages drive clarity. This is especially important if your organization's log-centralizer is also used for some types of monitoring or alerting.
I want to especially say that not all the work on this project is my own. Alan Muller originated several of the key ideas in the demonstration, including making the Logger class internal and sealed. He also made the "lazy load" part of the Logger's instantiation. Thanks Alan for clever ideas and feedback!
I sincerely hope that this content helps you understand, implement, and succeed with semantic logging.
Succeed: incrementally, based on user engagement, and driven by data.