创建记录器
这并不是真正的编码问题，但我在开发新的记录器实现时，正在寻求社区关于我遇到的一些问题的一些反馈。
背景
我们的 ASP.NET 应用程序最初使用 log4net。虽然 log4net 是一个很棒的日志记录工具，但它不能满足我们的需求，在某些情况下，它甚至会在日志记录的完成方式上给我们的应用程序带来问题。我们目前正在实现我们自己的日志系统，该系统模仿 log4net 的某些行为，但也根据我们的需求进行了定制。我不是在这里讨论 log4net 的使用或如何配置它。
系统
目前我们正在开发一个系统。系统有一个记录器类，它是一个单例（设计缺陷，我知道...），并且该类具有IReporter对象的集合。
每次应用程序调用Logger.Instance.Log(message)时，记录器都会将这些消息定向到队列中的每个IReporter，并且报告者有责任将消息记录在他们的目的地/存储/任何东西。
目前，我们选择每个IReporter都有一个后台线程和一个消息队列，以按照自己的速度处理消息。这里的危险在于，当应用程序突然终止时，我们可能会丢失一些消息。
我们想到的另一种方法是在记录器上有一个线程池，让这些线程在队列上运行，然后将消息委托给报告者。
我关心的是性能。我们首先使用记录器中的事件来实现这一点，但是在访问文件时生成的线程很快就会失控。因此，现在通过这种方法，我们希望限制对资源的访问。
我正在寻找具有类似情况的人以及他们如何处理此问题。
It's not really a coding problem, but i'm after some feedback from the community regarding some issues that I'm having, while developing a new Logger implementation.
Background
our ASP.NET Application originally worked with log4net. While log4net is a great logging tool, it does not suit our needs and in some cases it even causes problems for our application by the way the logging is done. We currently are implementing our own logging system that is mimicing some behavior of log4net, but also tailored to suit our needs. I'm not here to discuss about the usage of log4net or how to config it.
System
Currently we have a system that's beeing developed. The system has a logger class, which is a Singleton (design flaw, I know...) and this class has a collection of IReporter objects.
Everytime the application calls Logger.Instance.Log(message) the logger will direct these messages to every IReporter inside the queue, and the reporters have the responsibility of logging the message in their destination/storage/whatever.
Currently we've chosen that each IReporter has a backgroundthread and a message queue to process the messages at their own speed. The danger here is that when the app dies suddenly we could lose some of the messages.
Another approach we had in mind was to have a thread pool on the logger and let these threads run over the queue and then delegate the messages to the reporters.
What I'm concerned about is the performance. We first implemented this using events in the logger, but the threads spawned went haywire fast when accessing the file. So now with this approach we hope to limit the access to the resources
What I'm lookign for is people who had similar situations and how they approached this issue.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我是否理解正确，所有这些进程都访问同一组文件？在 Windows 上？
您不应该这样做，因为操作系统将执行一些复杂的锁定，这需要时间，或更糟糕的是，根据您访问文件的方式，您可能会遇到死锁。最好在一个线程上完成所有日志记录，并按顺序运行 IReporters。
如果您担心您的软件可能会在日志操作过程中死机，请将记录器放在另一个进程中，通过IPC进行通信。但您确定要重新发明 syslogd 吗？
Did I understand it correctly, and all those processes access the same set of files? On Windows?
You shouldn't do that, as the OS will do some complex locking that will take time, or worse, depending on how you access the files, you can get a deadlock. It would be better to do all the logging on one single thread, and running the IReporters sequentialy.
If you are concerned that your software may die during a log operation, put the logger in another process, communicate by IPC. But are you sure you want to reinvent syslogd?
您的设计听起来非常像带有一堆
FileAppender的 Log4Net。你真的应该重新考虑你的决定，除非有你没有分享的要求。 Log4Net 在该领域的用途比您的记录器要多得多，而且它已经解决了许多错误和性能问题。Your design sounds an awful lot like Log4Net with a bunch of
FileAppenders. You should really reconsider your decision, unless there are requirements on you that you haven't shared. Log4Net has a lot more use in the field than your logger ever will, and it's had lots of bugs and performance issues already shaken out of it.