【发布时间】:2010-04-06 16:18:19
【问题描述】:
是否可以让 2 个应用程序使用 log4net 写入同一个日志文件?
【问题讨论】:
标签: log4net
是否可以让 2 个应用程序使用 log4net 写入同一个日志文件?
【问题讨论】:
标签: log4net
MinimalLock 部分解决了这个问题(正如@Mark 提到的),但如果你使用的是 RollingFileAppender,你会遇到其他问题。当文件滚动时,您可能会发现自己处于竞争状态,一个进程会覆盖另一个进程新创建的日志文件。
其他选项包括 RemoteLogger,您可以在其中设置一个简单的服务器来接收和记录其他进程发送的日志记录事件。同样,您可以登录到 SQL 数据库。我写了一个简单的附加日志到 Redis;您需要一个简单的应用程序来从 Redis 读取并记录到文件中。这些方法的问题在于它们都引入了故障点。当某些事情无法正常工作时,通常是您最需要日志的时候,然后它们可能不可用。
所以我的解决方案是通过将每个进程记录到自己的文件中来完全避免这个问题。这很容易通过更改配置来完成。在您的 (Rolling)FileAppender 配置中,使用:
<file type="log4net.Util.PatternString" value="c:\mylog-[%processid].txt" />
进程 ID 成为文件名的一部分。是的,这意味着您现在需要梳理多个日志文件,但是像 Graylog、Splunk 或 Logscape 这样的日志文件聚合器可以提供帮助。
【讨论】:
%processid 是否能够处理以确保写入日志失败?如果由于某种原因失败,它是停止执行其余代码还是继续执行 API 调用中的其余代码?
%processid 对于同一进程中的多个线程可能是相同的,但我相信 log4net 可以处理。我想你会没事的;通过验证信任。
他们可以,但是如果一个应用程序正在写入文件,另一个应用程序很可能会在需要写入日志时遇到错误,因为第一个应用程序将保持文件打开以进行写入。最好为您的应用程序提供专用的日志记录源 - 如果您需要共享日志,请使用旨在处理并发写入的数据库。
这是在您进行开发时在您的机器上运行良好的事情之一,因为您不太可能对日志文件创建足够的并发写入来发现任何问题。一旦您的应用程序开始承受更多负载,问题就会开始显现,并且可能会以奇怪的方式表现出来。我肯定会尝试其他解决方案。
【讨论】:
这取决于FileAppender 的LockingModel。如果是ExclusiveLock,则另一个进程无法打开文件进行写入。替代方案是MinimalLock,但并非为此目的。它旨在允许另一个进程移动或删除文件。
【讨论】:
是的,有可能,如上所述,但我现在已经对这种情况进行了一些压力测试。
设置非常简单:
当同时点击两个按钮时,日志条目会散布在整个日志中。 但是,这是一个大问题,从随附的请求计数器判断,很明显存在竞争条件。 几乎每次一个 web 项目成功记录其条目时,另一个失败(条目被跳过)。
因此,如果针对此公共日志的流量不错,您基本上无法保证哪些日志语句实际上最终会出现在日志中。 结论是总是有项目特定的日志文件,似乎。
测试是使用默认的“MinimalLock”完成的。 我也用“ExclusiveLock”重新进行了测试,结果发现第一个配置记录器的 Web 项目“赢了”,基本上锁定了所有其他记录请求。 所以很明显,这也是不行的。
【讨论】:
或者您可以使用 Mutex 锁定公共资源,从而同步不同进程对公共日志文件的访问。
【讨论】: