0

I want to make a centralized log for our infrastructure because of the ease of going to one place to find everything. We currently have about 15~20 different systems we would like to log and I was thinking in using nlog to a web-service.

So far so good, but then I read thread which exposes that:

Availability of the central repository is a little more complicated than just 'if you can't connect, don't log it' because usually the most interesting events occur when there are problems, not when things go smooth

So the author (Remus Rusanu) said that using MSMQ is a good way to go if I are in a Microsoft enviroment (which I am). I think this has some sense, so I wanted to see other opinions and I found this another article where the general idea is that MSMQ is too much for "just logging", just this time the reason about this decision was "Performance".

So, in your experience, should I worry about High Availability of the centralized logger or I just should log to local files when the service is not available.

Community
  • 1
  • 1
Gabriel Espinoza
  • 385
  • 1
  • 18
  • I would agree that MSMQ is overkill. I use a shared DLL to log both to the local disk and to SQL Server. A database won't get you the fastest write performance of course, but they are designed for high availability and it's very easy to setup. – Zer0 Sep 06 '14 at 09:15
  • Thank you for your answer Zer0, the thing is I have some systems outside my network, so I can't log directly into SQL Server because we don't expose the Database server to the WAN. In this scenario, I have to provide some sort of web-service to allow logging. Should I use standard web-service or I should really worry about High Availability of the central repository... – Gabriel Espinoza Sep 07 '14 at 15:15
  • 1
    I would log to both your web service and local disk then. Can't hurt to have a backup. – Zer0 Sep 08 '14 at 14:24
  • @Zer0, thank you :) I don't know why this did not come up to my mind xD – Gabriel Espinoza Sep 08 '14 at 19:12

0 Answers0