views:

95

answers:

3

Hi,

I would like to know how people dealing with logging across multiple web servers. E.g. Assume there are 2 webservers and some events during the users session are serviced from one, some from the other. How would you go about logging events from the session coherently in one place (without e.g.creating single points of failure)? Assuming we are using: ASP.Net MVC, log4net.

Or am I looking at this the wrong way - should I log seperately and then merge later?

Thanks,

S

UPDATE

Please also assume that the load balancers will not guarantee that a session is stuck to one server.

A: 

Normally your load balancing would lock the user to one server after the session is started. Then you wouldn't have to deal with logs for a specific user being spread across multiple servers.

Ryan Kearney
Thanks, but in this case there would be no 'sticky sessions' provided by load balancing hardware.
UpTheCreek
A: 

One thing you could try is to have the log file in a location that is accessible by all web servers and have log4net configured to write to it. This may be problematic, however, with multiple processes trying to write to the same file. I have read about NLog which may work better in this scenario.

Also, the log4net FAQ has a question and possible solution to this exact problem

Loki Stormbringer
+1  A: 

You definitely want your web servers to log locally rather than over a network. You don't want potential network outages to prevent logging operations and you don't want the overhead of a network operation for logging. You should have log rotation set up and all your web servers clock's synced. When log rotation rolls your log files over to a new file, have the completed log files from each web server shipped to a common destination where they can be merged. I'm not a .net guy but you should be able to find software out there to merge IIS logs (or whatever web server you're using). Then you analyze the merged logs. This strategy is optimal except in the case that you need real-time log analysis. Do you? Probably not. It's fairly resilient to failures (assuming you have redundant disks) because if a server goes down, you can just reboot it and reprocess any log ship, log merge or log analysis operations that were interrupted.

Asaph
Hi Asaph, this sounds like the best solution for me - I had a feeling merging might be the most practical route. I don't need real time, so this would be fine.
UpTheCreek