Just to share our experience on this, we have a distributed system across several hosts, but with centralised logging. We've just about completed a move from a home grown horrific logging setup to a log4net approach. We use an adapted MSMQAppender on each host to send the log message to a local queue. A service on each host then processes these messages (using log4net again) and logs them to a central database using AdoAppender. This works very well for us, and means that the applications aren't waiting for the database, but also minimises network traffic to just the database call. The timestamp is placed within the message placed on the queue, which does mean time syncing, but also means you get the time of the event, rather than the time it was logged, which can be very different in this setup.
It involves a little bit of time to create a service to log, but it was only a day or so. Our tests show that writing to the MSMQ queue is about 6 times quicker than writing to the database, but that would depend on what you're logging (i.e. the width of your log entry), which is quite a bit for us. Good luck, Dave. > > A previous generation application suite simply uses OutputDebugString( ) > to achieve centralized logging for a multi-app suite running on a single > host. The next generation replacement is in the design stage, and will > be distributed. It is desired to maintain an efficient and reliable > means of centralized logging. > > One idea is some sort of publish-subscribe model, whereby each app > writes to a publisher, with the publisher responsible for delivering the > messages to each subscriber. > > Another idea is to have each app use a RollingFileAppender, and have a > background process examine the time tags to assemble a centralized log > from the individual files. Obviously time-syncing will be necessary > between hosts, and a means to determine any offsets. > > Both of these approaches may involve more work than we would like to > budget for, and may have inherent time-order ambiguity for messages that > are close together due to OS context switching. > > Any comments on these approaches? Any other ideas on how better to do > this? > > Thanks, > -Mike > >
