为什么 log4net 条目可能会“丢失”?在一些听众看来

发布于 2024-08-19 00:34:53 字数 662 浏览 7 评论 0原文

这真的让我摸不着头脑......

我已经在应用程序中使用 log4net (当前版本 1.2.10)一段时间了。在向应用程序添加新选项时,我注意到即使 log4net 调试、错误等方法从该日志源调用项目,控制台附加程序也看不到。

检查完明显的事情(比如确保不涉及过滤)后,我注意到其他一些奇怪的事情。如果我有多个附加程序(例如日志文件附加程序和 UDP 附加程序),那么附加程序有时会看到日志消息的不同子集。他们看到的子集似乎是随机的,但通常当问题发生时,他们将无法看到来自给定日志源的所有消息。

为什么会发生这种情况?由于丢失的消息意味着无法信任日志文件来显示远程故障的准确图片,我该怎么办?

[下面添加的其他信息于 2010 年 1 月 19 日添加]

我终于仔细研究了响应调用而传回的 ILog 对象。

LogManager.GetLogger(typeof (MyTypeHere));

在某些情况下,我得到一个包含 Debug、Info、警告、错误等设置为 false。在其他情况下,ILog 对象将它们正确设置为 true。由于我的代码不执行任何操作这些标志的操作,因此当我的代码传递时,来自我的代码的“禁用”ILog 对象消息(可以理解)根本不会传播。

我仍然无法解释两个附加程序之间的明显差异。

This one really has me scratching my head....

I have been using log4net (currently version 1.2.10) in an application for some time. While adding a new option to the application, I noticed that even though the log4net Debug, Error, etc. methods were getting called items from that log source were not being seen by the console appender.

Having checked the obvious (like making sure there was no filtering involved), I noticed something else that was strange. If I have more than one appender (e.g. a log file appender and a UDP appender) then the appenders will sometimes see different subsets of the log messages. Which subset they see appears to be random, but typically when the problem occurs they will fail to see all messages from a given log source.

Why might this be happening, and what can I do about it since lost messages mean the log file cannot be trusted to show an accurate picture of remote failures?

[Additional information below added Jan 19th, 2010]

I finally took a good look at the ILog object getting passed back in response to the call

LogManager.GetLogger(typeof (MyTypeHere));

On some occasions, I am getting an ILog object with Debug, Info, Warning, Error etc set to false. On other occasions the ILog object has them correctly set to true. Since my code does nothing to manipulate those flags, on the occasions when my code is passed the "disabled" ILog object messages from my code (understandably) do not get propagated at all.

I still cannot explain the apparent discrepancy between the two appenders.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

居里长安 2024-08-26 00:34:54

我知道这已经很旧了,但我最近在 ASP.NET MVC 应用程序中遇到过这种情况,追踪起来真的很令人沮丧。它似乎发生在使用 ValidateInput(false) 属性的方法上。

我的猜测是,使用此属性会跳过初始化 log4net 在记录时尝试访问的一些数据。我发现将以下内容添加到我的 web.config 解决了问题:

<httpRuntime requestValidationMode="2.0" />

当然它还有其他副作用(与日志记录无关)。

I know this is old, but I've had this happen in asp.net mvc apps recently and it was really frustrating to track down. It seems to happen on methods that use the ValidateInput(false) attribute.

My guess is that using this attribute skips initializing some data that log4net tries to access while logging. I found that adding the following to my web.config fixed the problem:

<httpRuntime requestValidationMode="2.0" />

Of course it has other side affects (not related to logging).

不奢求什么 2024-08-26 00:34:53

我们经常一起使用日志文件、控制台和 smtp 附加程序,但似乎没有这些问题。在某些情况下,某些附加程序可能会因其固有的性质而丢失消息。例如,由于传输机制的原因,UDP 附加程序不能保证传输所有消息。 SMTP 附加程序也会发生同样的情况。如果您使用通用日志文件但从多个进程进行日志记录,有时该文件会被另一个进程锁定(这通常会引发异常,但它可能会在代码中的某个位置被捕获),因此请务必设置“最小锁定”属性在它上面。此外,appender 可以被缓冲,因此如果进程崩溃,log4net 可能没有机会刷新缓冲的数据。

最后,最可靠的附加程序是那些本地日志附加程序,例如文件和事件日志附加程序,但随后您必须收集所有日志。如果您想集中记录日志,您可能需要考虑记录到数据库或消息队列。

We regularly use the logfile, console and smtp appenders together and we don't seem to have these issues. Under certain conditions, some appenders can lose messages because of their inherent nature. For example, the UDP appender, because of the transport mechanism, isn't guaranteed to transmit all messages. Same thing happens with the SMTP appender. If you are using a common log file but logging from several processes, sometimes the file is locked by another process (this usually throws an exception, but it might be getting caught somewhere in your code), so be sure to set the Minimal Lock property on it. Also, the appenders can be buffered, so if there is a process crash, log4net might not have a chance to flush out the buffered data.

In the end the most reliable appenders are those that log locally, such as the file and the event log appenders, but then you have to harvest all the logs. If you want to log centrally, you might want to consider logging to a database or a message queue.

傲世九天 2024-08-26 00:34:53

我是否正确理解某些通常成功记录的消息在某个时刻突然停止出现(正在记录)?如果是这种情况,那么我建议打开 log4net 的内部日志记录。或者使用 log4net 代码调试问题(对于您的问题,我建议在 Logger 类中的 CallAppenders 方法周围的某个地方进行破坏。它会告诉您日志记录事件实际上会调用哪些附加程序)。

如果某些消息始终没有被记录,那么我会查看 log4net 配置。检查是否设置了任何级别/阈值,更重要的是,如果您使用记录器,请检查它们的名称,并确保您放入 LogManager.GetLogger(...) 调用中的任何内容的前缀与配置中的名称记录器相匹配。

我将 jvilalta 所说的话加倍。我多年来一直使用 log4net 和多种类型的附加程序,并且我还没有见过仅某些附加程序而不是全部附加程序丢失消息的情况。

Do I understand correctly that some messages which are normally logged successfully suddennly stop appearing (being logged) at some point? If that is the case, then I would suggest turning on the internal logging of log4net. Alternativly debug the issue with log4net code (with your problem I'd suggest breaking somewhere around CallAppenders method in Logger class. It will tell you which appenders will actually be called for a logging event).

If some messages are consistently are not being logged then I would look at the log4net configuration. Check for any levels/thresholds being set and more importantly, if you are using loggers check that their names and make sure that the prefix of whatever you put into LogManager.GetLogger(...) call matches the name loggers in your config.

I double what jvilalta said. I have been using log4net for years now with many types of appenders and I have not seen a situation where a message would be missing from only some of appenders but not all.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文