我有一个Web应用程序部署在10个Web服务器上。它们都是这样配置的（注意，下面的path是一个共享的网络路径。所以它们都指向同一个日志文件）：
"Serilog": {
"Using": [ "Serilog.Sinks.Console", "Serilog.Sinks.File" ],
"MinimumLevel": "Debug",
"WriteTo": [
{
"Name": "Console"
},
{
"Name": "File",
"Args": {
"shared": true,
"path": "logs/foo_.log",
"rollingInterval": "Day",
"retainedFileCountLimit": 7
}
}
],
"Enrich": [ "FromLogContext", "WithMachineName", "WithThreadId" ]
},但是，我注意到日志文件中有交错的消息：
2023-02-28 00：03：16.105 -06：00 [DBG]结果过滤器的执行计划（按以下顺序）：[“Microsoft. AspNetCore. Mvc. Infrastructure. C2023 -02-28 00：03：16.054 -06：00 [INF]要求2023 -02-28 00：03：16.130 -06：00 [DBG]结果筛选器的执行计划（按以下顺序）：
请注意同一条消息中的[DBG]和[INF]日志级别，这里特别提到：
基础设施C2023 -02-28 00：03：16.054 -06：00 [INF]要求2023 -02-28 00：03：16.13
我怎样才能防止这种情况发生呢？我以为shared: true是Serilog处理这种情况所需要的支持呢？
1条答案
按热度按时间agxfikkp1#
我知道这是一个令人沮丧的答案，但不幸的是，我不认为其他任何东西实际上最终会是好的建议。底线是，登录网络共享是一个简单的坏主意-它会受到网络干扰等。期望从多台机器的多个写入协调良好是使事情变得更加困难。这不是人们做的事情。
Serilog的成功将受到底层文件系统的锁定所能提供的限制。
您可以阅读接收器的源代码，以查看在.NET级别使用的文件共享模式。这将依次Map到Win32 API选项。
如果你能找到一个有用的共享模式配置，在你的环境中工作，它可以作为一个改变的接收器，但这样的变化必须满足一个非常高的酒吧-
File接收器是由字面上数以百万计的系统使用，实现是为了易于阅读和无聊优化。因此我的建议是要么a）转移到使用专用的日志服务器，例如Seq，或基于ELK的解决方案。这是人们所做的。还有很多其他的好处：
shared:true是否会在网络上实际执行事件工作，尽管面对多个进程）