Considering using WCF for a logging service ... Please advise

Question

I am looking at an architecture for an enterprise logging service. His task would be to receive and store log messages, and then allow access to these log messages to users. Instead of creating logging functionality in our existing Windows service, which will use it for now, we need to separate it so that other services can use it in the near future. I like the fact that our various services could record their messages through net.tcp, and then I could create a RESTful interface for delivering certain log messages to browsers or something else.

Can someone speak with wisdom or be absent of the following options:

• Use WCF for logging service
• Use net.tcp for transport
• Service node in a Windows service project (using ServiceHost)

Also, how can I create it so that it uses some pretty meaty servers that will host it? Is it possible to open multiple connections (or is this done automatically) or implement some automatic multithreading?

One service that we are currently using that will use this logging service is verbose and will send log messages very often (~ 40-100 fps). I have not created a prototype and have not done any benchmarking, and I know that I am not giving you enough details to make a final decision, but now I'm just looking for some direction and thoughts. Thanks.

Answer 1

There are other alternatives to creating another log-only service. You can create a log as an aspect and attach / detach this aspect (aka inject), when and when needed, any ServiceContract or OperationContract . Thus, you disable logging, but this avoids the overhead of calling another service for each call. After you create these aspects, compile them in a separate binary file and use them as needed in all of your future services, enabling and disabling certain logging scripts is more convenient for IMO than having a dedicated log-only service.

Take a look at the following two posts, and they provide a simplified approach to this, you need to fill the flesh as you want for your project.

• Creating a logging aspect
• WCF Extensibility: Parameter Inspectors

Important MSDN documentation you want to look at.

• IParameterInspector
• IOperationBehavior
• IServiceBehavior

Edit - Code Example

Using the code below, you add [OperationLogging] on any of your work contracts, and you can intercept calls to this operation contract in LoggingInspector.BeforeCall .

Use [ServiceLogging] for any service contract, and all operations defined in these service calls can be intercepted and logged.

Set your_app_config_key to anything other than TRUE ; these additional behaviors are not added to your service pipeline. This is very cool since none of this code is executed based on this key in config.

 public class LoggingInspector : IParameterInspector { private string service; public LoggingInspector(string serviceName){ service = serviceName;} public void AfterCall(string operationName, object[] outputs, object returnValue, object correlationState){} public object BeforeCall(string operationName, object[] inputs) { // your logging logic } } //Operation Logging attribute - applied to operationcontracts. [AttributeUsage(AttributeTargets.Method)] public class OperationLoggingAttribute : Attribute, IOperationBehavior { public void AddBindingParameters(OperationDescription operationDescription, BindingParameterCollection bindingParameters){} public void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation){} public void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation) { if (ConfigurationManager.AppSettings["your_app_config_key"] == "TRUE") dispatchOperation.ParameterInspectors.Add(new LoggingInspector(dispatchOperation.Parent.Type.Name)); } public void Validate(OperationDescription operationDescription){} } //Service Loggign attribute - applied to Service contract [AttributeUsage(AttributeTargets.Class)] public class ServiceLoggingAttribute : Attribute, IServiceBehavior { public void AddBindingParameters(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase, Collection<ServiceEndpoint> endpoints, BindingParameterCollection bindingParameters){} public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase) { if (ConfigurationManager.AppSettings["your_app_config_key"] == "TRUE") foreach (ServiceEndpoint endpoint in serviceDescription.Endpoints) foreach (OperationDescription operation in endpoint.Contract.Operations) operation.Behaviors.Add(new OperationLoggingAttribute()); } public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase){} } 

Answer 2

Basically, I think that one audit service makes sense if it falls into the limited context of your application (s). IDesign has an exemplary implementation of ES Logbook here (find the "Corporate Services Journal"). You can do some initial testing to see if it can handle the loads you expect. If you are worried about performance, I would consider message queuing over tcp (the sampling logging application also supports this). As for hosting, the service should always be running, so the Windows service makes sense. If you want to use IIS, I would suggest using the Windows Server AppFabric and turning on the AutoStart feature for the application.

NTN.

Answer 3

Reading the question, I have some thoughts to share. Registration itself is not terribly complicated, and using WCF to create an enterprise journal infrastructure will be fine. But logged-only data is useless. This data should then be consumed by some \ app process and therefore provide some added value. Therefore, a more important aspect of journaling is

• What data is logged.
• How is the data log written \ used

Thus, my advice will be to think more about what needs to be recorded and what value this data adds.