This project is read-only.

Best starting point for a new sink

Topics: Contributing, General
Mar 23, 2014 at 12:59 AM
Hi all!

I'm working on a log server built specifically for structured log events ( and think support for SLAB is long overdue...

I've seen the recently-contributed ElasticSearch sink - is that the best place to start when writing a new implementation? The sink will send batches of events via HTTP - it is a very simple protocol - but if there's any existing work that would allow events to be (optionally) buffered via disk that would be ideal.

Tips, pointers and advice gratefully accepted :)


(Why another log server, you might ask? Well, Seq is very quick and easy to set up, has minimal infrastructure requirements, and "just works" with .NET tools. It also assumes structure data as the starting point, rather than grafting it on as other log solutions tend to do. And, I freely admit, it is a lot of fun to build :))
Mar 26, 2014 at 1:19 PM
The Developer's Guide to Microsoft Enterprise Library contains examples of creating custom sinks.

In terms of creating a buffered asynchronous sink then the new ElasticSearch sink is a good place to start. The BufferedEventPublisher class was made public so that it can be more easily used by custom sinks (it was previously internal).

Randy Levy
Enterprise Library support engineer
Support How-to
Mar 26, 2014 at 11:11 PM
Thanks Randy! I've got some time blocked out to do it shortly, I'll let you know how it goes :)

Mar 27, 2014 at 10:01 PM
I started on this in a separate repo but quickly found out the current ( NUPKG doesn't include the BufferedEventPublisher changes you mention. Is there any ETA on when the new version will be released?
Mar 27, 2014 at 10:03 PM
Mar 27, 2014 at 10:05 PM
Thanks, perfect timing :)
Mar 29, 2014 at 4:51 AM
OK - this was painless enough!

Some details here: if anyone's interested, and code here:

Planning to iterate pretty quickly on this, the current version is very basic.

(We use the prefix "Etw" for the built-in properties from SLAB, so that their names don't conflict so readily with properties from the payload, but it is a bit unsightly - think this will be likely to change.)

All the best,