Semantic logging- can logging be controlled by keyword?

Topics: Pre-release discussions, Semantic Logging Application Block
Mar 8, 2013 at 6:13 PM
Examining the xsd / xml schema for the semantic logging service, I see where the service can be configured to capture logs via the level.

Is it possible to log on a more granular level? I see Keywords.All in the example for in process calls, but don't see where keyword may be specified in the xml configuration of the service.

What I'm thinking is when I use tool like LogMan or Perview, if I recall correctly, it's possible to specify the keywords all, or specific keywords as well as the level.
Mar 10, 2013 at 5:46 AM
I don't see the option to configure Keywords in the OOP service. Currently the value for Keywords is hard coded to ulong.MaxValue which would enable all keywords.

It looks possible but I'm not sure if there is a plan to implement that feature or if there is a reason not to.

Randy Levy
Enterprise Library support engineer
Support How-to
Mar 11, 2013 at 12:35 AM
That's the conclusion I was coming too also. Thanks for the confirmation Randy!

So, as the team is asking for feedback to the CTP, what is the way to add to a wish list to include the implement the feature to filter by keyword?

re: I'm not sure if there is a plan to implement that feature or if there is a reason not to.

Here is a scenario I'm thinking of. (and I'm quite open to different paths to the same end)

Consider a layered Sales Order application. The layers are the traditional UI, Service, Business and Data Layers.

I would like to log within a 'context' of the application. Consider the application contains the following contexts: "CustomerService" "Shipping" "Billing" and "Sales".

I could derive from EventSource a CustomerServiceLogContext, a ShippingLogContext, a BillingLogContext, and a SalesLogContext

Each logging context would be responsible for logging 'vertically' across the multiple layers-- UI, Service, Business, And Data Layers.

But I also want to filter within a layer (horizontal). Perhaps I want to log only the UI layer, the Service Layer, or just both. (As the UI and Service layer may offer good boundaries in the system in terms of the action starts at the UI, crosses a WCF (service) boundary, before accessing the business and data layers.

To filter horizontally, I was thinking I could use the keywords within each derived class: for example: Log CustomerServiceLogContext: keywords UI and Service

One could have a CustomerServiceUILogContext, a CustomerServiceServiceLogContext, a CustomerServiceBusinessLogContext and a CustomerServiceDataLogContext.
But doing that seems like a proliferation of classes to accomplish what could be done via usage of keywords internal to a CustomerServiceLogContext.

I believe Logman and Perfview allow keyword specificiers, so I could accomplish the vertical / horizontal logging concerns with those tools.

Might there a different way of solving the problem wiht the Semantic Logging block?

Mar 11, 2013 at 9:34 PM
Dan - I'm in a similar boat as you. I want to create a set of classes and listeners that can be reused by many developers creating new apps, and thus be easily queried and reported on since they all have similar meaning.

For example:

-LogPageError (string appName, string errorMessage, string stackTrace)
-LogYellowScreenError(string appNameSpace, string errorMessage, string stackTrace)

-LogGeneralError(string appName, string errorMessage, string stackTrace)
-LogDBQueryError(string appName, string errorMessage, string stackTrace)
Mar 12, 2013 at 3:19 AM

Yes, it appears we have similar needs. For your case it appears you want to have different classes to report errors in different parts of your application, or perhaps in different applications.

In my case, I am interested in using derived EventSource classes to instrument my application. What I find compelling about ETW logging is its low overhead and ability to combine events from other providers such as garbage collection and CPU utilization. I am currently exploring how to accomplish getting event traces into my application using Aspect Oriented Programming (AOP) techniques via the Unity container, or through tooling like PostSharp. And also examining how to add logging into the WCF stack using custom behaviors.

One objective is having the logging points / instrumentation available so I can turn them on during development while adding new features, refactoring, or doing load testing. And have the instrumentation available to turn on during production, to obtain performance information.

When I read about about SLAB a couple weeks ago, and have been doing some prototypes with it, I'm optimistic it will be a really useful tool for my purposes.

But, as I stated in my first question, I'd like to see SLAB provide a finer filtering than it currently has.

Think of a Venn diagram of a narrow vertical circle which is the logging concerns of a context within an application from the Presentation to the Data layer. I want to events from each layer via the derived class, via all keywords are set, or narrow the focus onone or more specific layers by using keywords.
Mar 12, 2013 at 6:38 PM
@DanMoyer, @jonnycoder

Thank you for your elaborate feedback.

In the Out-of-proc service we now have support for numeric keywords. It wasn't included in the CTP.
It's not easy to implement support for custom literal kewords because it's impossible to know what the keyword is till the manifest is obtained.

Do you feel the support for numeric keywords would be sufficient for your scenarios?

Mar 13, 2013 at 3:53 AM

Thanks for your response!

Numeric keywords fit very well for my problem. In reviewing the CTP, I had concerns in not seeing support for keywords in the docs or code. Great that they will be supported post CTP.

I was re-reading some of Vance Morrison's blogs this morning, and he wrote on Aug 29, 2012, in a response, a point which I want to avoid: (i.e. don't use a large number of classes to acheive filtering / granularity)

"...C# class, making a provider for each is definately NOT how the system was deigned to be used (the system does not expect that many). If it is something else (a logical component) and there are < 100 of them than that can be OK. Fundamentally, you want providers to be things that users consuming the events 'understand' as 'big' things that make sense to be logically separate..."

Numeric keywords work fine for me. Their usage will allow the a handful of classes for instrumenting an application, while allowing a finer grain filtering when desired.

And I think that in using numeric keywords SLAB will be consistent with other tools like PerfView, XPerf, and LogMan, where, corect me if I'm wrong, keywords are specified numerically.