I am considering the architecture for an enterprise logging service. Its job would be to receive and store log messages and then allow access to those log messages to users. Instead of building the logging functionality into our one existing Windows service that would use it for now, we need to separate it so that other services could use it in the near future. I like the fact that our various services could log their messages over net.tcp and then I could build a RESTful interface for delivering specific log messages to browsers or whatever.
Could anyone speak to the wisdom or lack of the following choices:
- Use WCF for the logging service
- Use net.tcp for the transport
- Host the service in a Windows Service project (using ServiceHost)
Also, how might I design it such that it takes advantage of some rather beefy servers that are going to be hosting it? Is it possible to open up multiple connections (or is that done automatically) or implement some automatic multi-threading?
The one service we currently have that would be utilizing this logging service is quite verbose and would be sending log messages very frequently (~40-100k/day). I have not yet built up a prototype and done any benchmarking and I know I’m not giving you enough details to make a definitive decision, but I’m just looking for some direction and considerations at this point. Thanks.
There are other alternatives to creating one more service just for logging. You could build the logging as an aspect and attach/detach this aspect (aka inject) as and when required by any
ServiceContractorOperationContract. This way you decouple logging but it avoids the overhead of calling one more service on every call. Once you create these aspects, compile them away in separate binary and use them as and when needed in all of your future services, enabling and disabling specific logging scenarios are more maintainable IMO compared to having a dedicated service for just logging.Have a look at following two posts and they provide simplistic approach of doing this, you’d have to fill in the flesh as you want for your project.
Important MSDN documentation you’d want to look at.
Edit – Sample Code
With below code you add
[OperationLogging]above any of your operation contract, and you can intercept calls to this operation contract inLoggingInspector.BeforeCall.Use
[ServiceLogging]on any service contract and all the operations defined in that service calls could be intercepted and logged.Set
your_app_config_keyto anything other thanTRUEthese additional behaviors are not added to your service pipeline. That is very cool as none of this code is executed based on this key in config.