SLAB logging to Windows EventLog

Topics: Semantic Logging Application Block
Apr 10, 2013 at 11:38 PM
Hi there,

After reviewing the design doc, I found SLAB will provide logging to Windows EventLog support, while in the current CTP, seems there is no EventlogEventListener yet. We are testing the WindowsAzureEventListener, it's working great. Just wonder will EventLogEventListener be released in next CTP? And When will be the next CTP? Thanks a lot.

ZF
Editor
Apr 15, 2013 at 4:13 AM
I haven't heard an update on the timeline for EventLog support. I know the team is busy but I'll try and find out.

Thanks for taking the Semantic Logging Application Block for a test drive!

~~
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to
Coordinator
May 7, 2013 at 4:37 AM
@Wuzhenfei

The EventLog listener is not included in the final release of SLAB. This is due to a limitation of the EventSource class – no Channels support. Once Channels are added, the EventSource will support the EventLog natively.

Grigori
May 9, 2013 at 7:50 AM
Is sounds like adding channels is on the cards. Did they give you any idea of timescales?
May 9, 2013 at 6:53 PM
No, got no idea.

Regards,
Eddie


Editor
Sep 16, 2013 at 6:43 AM
See Announcing the EventSource NuGet Package – Write to the Windows Event Log for a walkthrough on logging to the Event Log using EventSource.

~~
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to
Sep 16, 2013 at 3:59 PM
Randy,

Any timeline on when a version of SLAB supporting EventSource 4.5.1 will be out (the NuGet Microsoft.Diagnostics.Tracing version)?

Can we switch to it on our own?

Kathleen Dollard
Editor
Sep 17, 2013 at 4:27 AM
Not sure what the plans are for the new Microsoft.Diagnostics.Tracing release on NuGet (that is prerelease right now) for SLAB.

You can't use Microsoft.Diagnostics.Tracing along with SLAB since SLAB uses System.Diagnostics.Tracing.

~~
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to
Sep 17, 2013 at 12:02 PM
Randy,

Right. But with major features people have been asking for (an Event Viewer sink) only available in EventSource 4.5.1 (NuGet, Microsoft.Diagnostics.Tracing) it would be really nice to see a version of SLAB that supports it.

Do you know if it Is more than a namespace change and a recompile using a different EventSource namespace (as in a compiler #if would do the trick)?

And there's the second question of whether the SLAB custom out of proc listener support will be updated to use the NuGet TraceEvent release from the clr team so everyone writing custom tools is using the same core.

Kathleen
Coordinator
Sep 23, 2013 at 7:14 PM
Just to reiterate, EventSource 4.5.1 and Microsoft.Diagnostics.Tracing.EventSource are different things.

4.5.1 ships with the .NET framework and supports activity tracing but not channels (i.e. no event log). That should work without modifications in SLAB, but the new ActivityId property cannot be used until we rev it up. I cannot provide the timeline for that work yet, but it is on our backlog.

The pre-release NuGet package which does support channels will not work with SLAB as is. You'll need to get the SLAB source, add references to the nuget package, change namespaces to point to the package's classes and rebuild.

Grigori
Mar 7 at 7:10 AM
I just pushed an update that flips the references over to Microsoft.Diagnostics.Tracing.EventSource:
Changes to the code are available on GitHub. No guarantees on the code quality, but you can see by the diff there are some changes in how EventSource handles conflicts in the manifest that have caused EventAnalyzer to behave differently. I did not fix that as it would become a different implementation from where the SLAB team is going at some point I hope. :)
Coordinator
Mar 7 at 7:08 PM
Colin, since there are effectively two stacks of EventSource in existence today (one - in the .NET framework, and another one - in the NuGet package), we have made a decision to avoid the confusion of releasing and maintaining two versions of SLAB by just shipping the official SLAB using the EventSource from the .NET framework. If someone wants to use the additional features of the EventSource NuGet package before they make into the next version of .NET, the conversion process of getting SLAB to work against the EventSource NuGet package is pretty straightforward and doesn't require a major effort: you just do a global search and replace and add the references to the EventSource NuGet package - as you have already experienced.

It's up to the user whether they want to do the conversion themselves or use your unofficial package.

One additional action that we feel still needs to be taken to better support the EventSource NuGet package is to update the test suite, which we will do in the upcoming release of SLAB1.1.

On a separate note, the decision we've made was based on our feeling that the confusion caused by two stacks of SLAB is less desirable than the very simple conversion. If you feel strongly that this decision should be revisited, I suggest you submit a workitem and based on the votes from the user community, we'll review this again.

Thanks,
Grigori
Thu at 7:00 PM
Edited Thu at 7:00 PM
On this page: http://msdn.microsoft.com/en-us/library/dn440729(v=pandp.60).aspx

It mentions: "The Semantic Logging Application Block includes a number of sinks for receiving and processing log messages such as the ConsoleSink, the EventLogSink, and the RollingFlatFileSink."

I've looked for it, and cannot find it... can someone please direct me to where this is?

Thank you,
Michael
Editor
Thu at 7:55 PM
Looks like the documentation didn't get updated when the EventLogSink was "pulled" from the release. gmelnik's response is still correct:
The EventLog listener is not included in the final release of SLAB. This is due to a limitation of the EventSource class – no Channels support. Once Channels are added, the EventSource will support the EventLog natively.
See: The EventSource NuGet package and support for the Windows Event Log (Channel Support).

~~
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to
Thu at 8:10 PM
Geeze. :P More than a year later and we're all still scratching our collective balls over this. Inaccurate documentation certainly doesn't help. :P

Seems like it's just a matter of creating another official package that supports the Microsoft. namespaces. This is what ESP is doing:
https://github.com/jonwagner/EventSourceProxy/tree/master/EventSourceProxy.Tests.NuGet

For reference, these issues don't exactly mention the core issue, but they are demonstrative of it. Providing Microsoft
versions of SLAB will fix them. They also have the most votes and have the momentum, so maybe voting them up will actually get the team to deal with it:
https://slab.codeplex.com/workitem/25
https://slab.codeplex.com/workitem/61

Assuming there's still a team that works on any of this. :P
Thu at 10:10 PM
Are you looking for EventViewer support?
Thu at 10:21 PM
Yes, EventLog support, preferably via SLAB support for Microsoft.Diagnostics.Tracing.

Adding to the confusion is this page:
https://slab.codeplex.com/wikipage?title=SLAB2.0ReleaseNotes

Where it mentions:
"Changed System.Diagnostics.Tracing to Microsoft.Diagnostics.Tracing in all source files"

A quick look in the source files in the SLAB repository shows that this is not the case... or maybe someone can explain...
Thu at 11:34 PM
Yes, and you would think this would be easy.

EventViewer uses static manifests. We only got good static manifest support recently (4.5.2?) and even then, deploying is hardly simple. While the problems go deeper, the fact that SLAB was created for 4.5 is one part of the history.

The idea of an in-line manifest, while brilliant and a massive simplification of the logging pipeline, is not yet supported by EventViewer.

There might be a mechanism for SLAB to eventually support static manifests, but my head isn't around how it could ever do it and with changes on the team, this might be left to the community.

So, depending on what you are trying to do, either SLAB is not the best route, or EventViewer is not the best route. This isn't SLAB's fault, it's not .NET's fault, it's not EventViewer;s fault. It's just the way history brought the underlying technology to the table.

Some people fail to understand that SLAB is doing almost nothing for you out of proc except giving you an on-ramp and great documentation. If you are going to EventViewer, you are using ETW. While out of proc SLAB uses ETW, mostly it reroutes ETW to it's listener to send to other sources. You don't want to go to those other sources. You want to go to ETW (with the correct static manifest installed on the machine where the analysis is done) . If you're going to ETW/EventViewer, routing through the SLAB listener would cause a massive slow-down (compared to raw ETW).

So, while I understand the frustration, especially going from the very friendly SLAB documentation to Vance's blog as a pretty enormous jump, my guess is that you have graduated SLAB and it's time to just use ETW.

There is no reason to tell me about the pain in PerfView (the innards are available if you want to write a OSS UI), or how sad it is that WPR/WPA can't quite make the grade yet, and please, please make a UserVoice request for non-completely-sucky ETW support in Visual Studio (although, really, is that where we want it?).

I'm saying this badly. If you're going to EventViewer, you've graduated SLAB and the problem is the hard cold world of SLAB-free ETW. Sorry.

Parts of my course might help: http://www.pluralsight.com/courses/event-tracing-windows-etw-dotnet
Thu at 11:56 PM
Whoa whoa whoa... :P

Let's back up here for a second... when you say "EventViewer" ... do you mean EventLog? That is what I am talking about here, and it sounds like this has support in the Microsoft.* NuGet library. It sounds like it's just a simple recompile with the new namespace (which again from my last post, sounds like it is already in the code, but is not), and we're good to go. End of story. Let me know if I have something terribly and fundamentally wrong.

"... this might be left to the community"

Great. Bring it on. Except that, EntLib isn't in GitHub so it's not possible to send pull requests, or make use of pull requests that have been provided by others. In fact, it seems like every project in MSFT is in GitHub now, with the exception of EntLib. This is, of course, choking on irony as it is supposed to be run by the group that is giving us guidance and best practices. :P
Editor
Fri at 1:47 AM
MichaelDBang wrote:
Yes, EventLog support, preferably via SLAB support for Microsoft.Diagnostics.Tracing.

Adding to the confusion is this page:
https://slab.codeplex.com/wikipage?title=SLAB2.0ReleaseNotes

Where it mentions:
"Changed System.Diagnostics.Tracing to Microsoft.Diagnostics.Tracing in all source files"

A quick look in the source files in the SLAB repository shows that this is not the case... or maybe someone can explain...
It might not be obvious (past tense not helping here), but the context of that statement is noting the specific steps required to support EventSource nuget package. The actual change to SLAB is the top level item "Improved compatibility with the EventSource nuget package" with the child item indicating that a rebuild is required and the 3 sub-items detailing the specific steps.

~~
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to
Editor
Fri at 2:06 AM
Edited Fri at 2:10 AM
MichaelDBang wrote:
Let's back up here for a second... when you say "EventViewer" ... do you mean EventLog? That is what I am talking about here, and it sounds like this has support in the Microsoft.* NuGet library. It sounds like it's just a simple recompile with the new namespace (which again from my last post, sounds like it is already in the code, but is not), and we're good to go. End of story. Let me know if I have something terribly and fundamentally wrong.

If you want to log to the EventLog you don't need to use SLAB. You can just use the EventSource NuGet package and with some configuration (detailed in Announcing the EventSource NuGet Package – Write to the Windows Event Log) ETW events will be directed to the EventLog.

EntLib isn't in GitHub so it's not possible to send pull requests, or make use of pull requests that have been provided by others.

I just want to point out that the source code is open source on CodePlex and uses git and supports forks, pull requests, etc.

~~
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to
Editor
Fri at 2:12 AM
Thanks, @KathleenDollard, for joining in -- your thoughts are appreciated. I think you're right about some confusion around SLAB vs. ETW.
Fri at 9:36 AM
Edited Fri at 9:37 AM
randylevy wrote:
Thanks, @KathleenDollard, for joining in -- your thoughts are appreciated. I think you're right about some confusion around SLAB vs. ETW.
Yes, I, too, appreciate the discussion. :D FWIW, I've been spending the entire week refreshing my knowledge about logging/SLAB and learning more about ETW. It has been very involved... and I can see why developers choose Log4Net over this.
It might not be obvious (past tense not helping here), but the context of that statement is noting the specific steps required to support EventSource nuget package...
Is it possible to make it more obvious? :P
If you want to log to the EventLog you don't need to use SLAB. You can just use the EventSource NuGet package and with some configuration
Yes, I am very aware that this is supported. However, if I bring in the Microsoft* version, then I have essentially two versions of the Diagnostics assembly in my solution. The whole idea here is to have ONE assembly in my solution.

Crazy question here: has anyone considered going to the Diagnostics team and see if they can simply rename their assembly from Microsoft* to System.*, but version their assembly differently, instead? That's how you're "supposed" to do it, anyways. That way. all the namespaces are in alignment, with no need to recompile dependencies. In order to make it work with SLAB, a developer would simply add an assembly redirect binding in their app.config. Simple. Right? :P
Fri at 12:23 PM
Never mind about pinging the Diagnostics team... System.Diagnostics.Tracing is in the System.dll assembly, so that wouldn't work. What a mess. :P
Fri at 3:10 PM
I apologize for taking the discussion in a slightly different direction (EventViewer) than intended.

I am so happy to have the conversation. We need to kill in-proc logging, put a silver stake in it's heart and let the sun beam down on nearly-free (from a performance perspective) logging. I don't mean SLAB in-proc so much, because it is at least a path out of the dungeon of in-proc logging.

It's great Randy has the SLAB perspective. Coming from raw EventSource, it took me a while to warm up to it, but it seems an awesome on-ramp to EventSource.

The System/Microsoft namespace issue is partially a matter of historic timing. System because it was desired on every box, and that's where "real" CLR stuff went. Then it was the first piece of the CLR for out-of-band releases - particularly around manifests.

This is important:

"Yes, I, too, appreciate the discussion. :D FWIW, I've been spending the entire week refreshing my knowledge about logging/SLAB and learning more about ETW. It has been very involved... and I can see why developers choose Log4Net over this."

What could have made it easier? Where were the pain points? Log4Net can block, badly block, scalability (or be forever turned off :( ). Is the problem more on the app side, the creation of all those semantic methods, or consuming the trace? Something else?
Fri at 3:46 PM
Edited Fri at 3:50 PM
KathleenDollard wrote:
I apologize for taking the discussion in a slightly different direction (EventViewer) than intended.
No worries! We've all been there. :)
What could have made it easier? Where were the pain points? Log4Net can block, badly block, scalability (or be forever turned off :( ). Is the problem more on the app side, the creation of all those semantic methods, or consuming the trace? Something else?
Personally, I've had my nose in EntLib since about v3 or v4... so about 5-6 years now? So all my training/knowledge is around the Logging Application Block. So it has taken some time to see how SLAB works. That actually didn't take too long, as I did a lot of that last year when it first came out. Although, it does appear I got it completely wrong and am now taking a more comprehensive approach.

I think where most of the friction is coming from is what you mention earlier with history. There is a LOT of history with ETW, and it just now reaching managed code, and apparently not very well. So there's that, learning about the history of ETW, and more importantly how to utilize it in a end-to-end scenario. There's just a lot to absorb with all the blog posts and documentation to learn what is what, which is to be expected for enterprise-based scenarios (and what scares a lot of the developers away).

So there's the history, but also the components to consume/analyze the data. PerfMonitor (not to be confused with PerfMon, sigh), and PerfView. Plus EventRegister and MDT's (Microsoft.Diagnostics.Tracing) implementation of it. Then there's little things like the "mf" and "rf" parameters in wevtutil that aren't even documented anywhere (if you know what these are that would be very helpful). Also, learning the difference between SDT and MDT has been very time-consuming, as well.

Additionally, I have also spent a good deal of time with EventSourceProxy (ESP), which is an outstanding project and really the way ETW should be implemented. There really isn't an EventSource; it's just interfaces. Interfaces are be the schema definitions, and you can use metadata/fluentapi/configuration to define them. This gets rid of the Event Source Analyzer altogether and really simplifies implementation.

All of that said, I am on-board with ETW and see the value of it. Although, with the recent push for cross-platform awesomeness, that adds another layer of investigation. Personally, I am building a Xamarin.Forms framework, so I need a logging/instrumentation solution that caters to both native and cross-platform code. That currently has me angling a solution that uses ETW for service-side applications, and Xamarin.Insights for client-side applications (and maybe falling back on ETW for clients that are running on native platforms such as WPF).

Hope this helps!
Sat at 6:22 PM
Edited Sat at 6:23 PM
OK, I have created (yet another) unofficial package for SLAB, compiled against the MDT (Microsoft.Diagnostics.Tracing) assembly. I've called this version EnterpriseLibrary.SemanticLogging.Futures and have deployed it here:

https://www.nuget.org/packages/EnterpriseLibrary.SemanticLogging.Futures/2.0.1406.1

A couple notes around this:
  1. Compiling around the latest code in SLAB and the last stable release of MDT caused one more test to fail. I have placed this test (when_inspecting_event_with_less_writeEvent_arguments) in the EVENT_SOURCE_PACKAGE ifdef condition.
  2. I tried peeking ahead with the latest beta of MDT, and I am very sorry I did. The last release was on Halloween, and it is appropriate due to how spooky it is. :P Essentially, EventSource.CurrentThreadActivityId has been deprecated (with a thrown exception) and is failing a bunch of tests in SLAB when paired with that release now. This will take some careful coordination to get this resolved.
  3. I have also made Microsoft and patterns-and-practices owners so they can upload to this location with an official version at a later date, if they so feel inclined.
  4. I have also made a Pull Request with my additions to make this all work. You can find that here: https://slab.codeplex.com/SourceControl/network/forks/MichaelDBang/SLAB/contribution/7751 -- It looks like I need to sign a CLA to be considered for this. I doubt the EntLib team would be interested in this PR, but if so, I will go down the road of getting a signed CLA for you. :)
Anyways, hope this helps someone, and/or provides some ideas/direction for fixing this very ugly problem/mess. :P