1

I'm looking for good a centralized log solution (for Windows server) for my ASP.NET MVC application.

My application is scalable and I want my log to be scalable too (so log server won't be a single point of failure / bottleneck).

I used LogFaces before, but this solution is not scalable. It uses a single log server.

I use log4net as a logger, and looking for solution that I could write (or use) an appender to push logs to.

Any suggestions?

Thanks! Roei

Roei
  • 319
  • 4
  • 15
  • Maybe the Windows event log? Keep in mind that writing to the logs is only half of the equation. Managing them and reporting on information in them is the other half. If you're the developer writing code to write to the logs, you'll want to consult the administrator who has to manage them when they're live in production. He may have some insights/preferences as well (such as the event log, or a database, or something else). – David Dec 20 '11 at 15:49

3 Answers3

1

Look into ELMAH, works great can run per app, or one instance to cover all apps on server

curtisk
  • 19,950
  • 4
  • 55
  • 71
1

Spread would fit the bill. It's not a logging service but a number of projects use it for distributed logging (such as the Apache web server's mod_log_spread module). It has a client for C# available here.

Its value lies within a simple principle: applications that produce logs shouldn't be constrained or interrupted by the very act of logging. Logging is typically a secondary concern of an application, and having your log file destination disk fill up (or your log service crash) is a really bad reason for your application to fail.

To reach this level of separation, you must build your application in such a way that it can log completely asynchronously and independently of the logging "service". Spread achieves this using a well-understood and established technology: UDP/multicast.

Logging with Spread would mean that your applications would log in a "fire and forget" mode over UDP. If no Spread daemon has been set up to consume those multicast messages, the log messages will disappear forever. However, the decoupling between log producer and consumer means that your applications will never need to worry about logs filling up disks, nor will they have to worry about spending time finding and connecting to a central log server using TCP.

Spread's not for every application, though. Your environment might not support multicast (so EC2 is out, for starters) or your network admin might prevent multicast packets within your production environment.

Brian Kelly
  • 19,067
  • 4
  • 53
  • 55
  • Thanks for your reply! I run my environment over EC2, so as you said - that's a problem is this case... – Roei Dec 21 '11 at 09:36
0

i have an appender that sends messages to a msmq message queue on a remote machine via wcf's net.tcp binding. there is a service on the other end that logs those messages to a database.

elmah is probably pretty good if you are only talking about asp.net - my understanding is that it only plugs into that and doesn't address more general things like windows services and such. not sure about wcf applications or if you even care about anything beyond your asp.net application. i'd guess there's probably more in your system and that you'd like to standardize. also, because you are concerned about scale, you might be concerned about having to access the database directly from asp.net for logging. my understanding is that this is what elmah does. haven't looked into it, but it could probably be extended to do what i suggest with msmq. if you really care about scale, i think you want to incorporate messaging queuing in one way or another, and wcf is a good option for doing that.

Dave Rael
  • 1,759
  • 2
  • 16
  • 21