Designing a distributed (across many servers) error logging functionality, WCF or?
I am creating an error logging function, so our servers (each with different things) can have a central data store for logging errors.
Wouldn't it be nice if different applications were writing to the error log file using the WCF service, or is this a bad idea?
they can do it simply with ADO.NET on the database, which is an easier route in my opinion.
I would say just go into local datastore. Benefits:
- Speed - Dump the selected bug report into an existing data connection fairly quickly.
- Tracability - What happens if you have a bug in your service? You lose all opportunities to chase errors on all servers.
- Simplicity. If you change the endpoint for your error service, you must update any other application that uses the error service.
- Reporting - Do you really want to trawl bug reports from dozens / hundreds of applications to one place when you can easily find them in a data store local to the application?
Of course, any of these points could be seen from the other side, these are just my opinions.
source to share
We are considering a similar approach, with the exception of audit logging and error handling.
Looking at using WCF over netTcp, also looking at using event log, but this requires high trust settings and possibly performance issues.
Not sure about ZombieSheep's objections:
-
Very fast to unload the selected error report on an existing WCF connection. Jokes aside. Alternatively, you can do this async / queued. This is not a key factor for me.
-
You register with the central service and the local service. When the erroer service returns to the queue, you poll your computers for events since the last timestamp. The problem has been solved.
-
Use a dns alias and don't change the path - as you should be doing internal addressing anyway IMO.
-
What if you have multiple applications on the same machine? What if you want to see error times across multiple applications?