集中式日志解决方案
我正在为我的 ASP.NET MVC 应用程序寻找良好的集中式日志解决方案（适用于 Windows 服务器）。
我的应用程序是可扩展的，我希望我的日志也可扩展（因此日志服务器不会成为单点故障/瓶颈）。
我之前使用过LogFaces，但这个解决方案不可扩展。它使用单个日志服务器。
我使用 log4net 作为记录器，并寻找可以编写（或使用）附加程序来推送日志的解决方案。
有什么建议吗？
谢谢！ 罗伊
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
查看 ELMAH，效果很好，可以针对每个应用运行，也可以在一个实例上运行以覆盖服务器上的所有应用
Look into ELMAH, works great can run per app, or one instance to cover all apps on server
Spread 就符合要求。它不是日志服务，但许多项目将其用于分布式日志记录（例如 Apache Web 服务器的 mod_log_spread 模块）。它有一个 C# 客户端在此处提供。
它的价值在于一个简单的原则：生成日志的应用程序不应受到日志记录行为的限制或中断。日志记录通常是应用程序的次要问题，日志文件目标磁盘已满（或日志服务崩溃）是应用程序失败的一个非常糟糕的原因。
为了达到这种分离级别，您必须以这样的方式构建应用程序：它可以完全异步且独立于日志记录“服务”进行日志记录。 Spread 使用一种易于理解且成熟的技术来实现这一点：UDP/组播。
使用 Spread 进行日志记录意味着您的应用程序将通过 UDP 以“即发即忘”模式进行日志记录。如果没有设置 Spread 守护进程来使用这些多播消息，则日志消息将永远消失。然而，日志生产者和消费者之间的解耦意味着您的应用程序永远不需要担心日志填满磁盘，也不必担心花费时间使用 TCP 查找并连接到中央日志服务器。
不过，Spread 并不适合所有应用程序。您的环境可能不支持多播（因此对于初学者来说，EC2 已不再适用），或者您的网络管理员可能会在您的生产环境中阻止多播数据包。
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.
我有一个附加程序，它通过 wcf 的 net.tcp 绑定将消息发送到远程计算机上的 msmq 消息队列。另一端有一个服务将这些消息记录到数据库中。
如果您只谈论 asp.net，elmah 可能相当不错 - 我的理解是它仅插入其中，并且不解决更一般的问题，例如 Windows 服务等。不确定 WCF 应用程序，或者您是否关心 ASP.NET 应用程序之外的任何内容。我猜想您的系统中可能还有更多内容并且您想要标准化。另外，由于您担心规模，您可能会担心必须直接从 ASP.NET 访问数据库进行日志记录。我的理解是，这就是 elmah 所做的。还没有研究过它，但它可能可以扩展以执行我对 msmq 的建议。如果您真的关心规模，我认为您希望以某种方式合并消息队列，而 WCF 是实现这一目标的一个不错的选择。
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.