我所有的用户都在大厅里走一小段路，我的所有程序都在同一个 LAN 上的工作站上运行。几年前，我让员工将他们所有程序的日志文件写入共享文件夹层次结构，在以应用程序命名的子目录中以机器名称命名每个日志文件。
但这种安排并不是那么好，因为如果文件服务器出现故障，那么任何地方的程序都无法写入日志。然而，将日志保存在每个工作站本地会使我们在必须调试问题时阅读它们变得很痛苦。
我们尝试为日志文件服务器创建 DNS 别名，以便在必要时将其指向备份计算机，但 DNS 别名不适用于 Windows 文件共享。
将共享日志文件夹的路径放在每个程序中并不是很好——即使它是现场可配置的——因为我们在几十台机器上有几十个程序。
我们也研究过使用微软的分布式文件系统，但价格太离谱了。
我想要一种将本地网络上许多程序的日志收集到一个地方的方法，这样我就可以在不访问远程机器的情况下跟踪和分析它们。我们的所有程序都使用 .Net。
编辑：我想避免在每个用户的工作站上设置文件共享，或者每晚拖网日志的解决方案，因为我希望能够按需读取新日志，或者在报告问题后的片刻。
在我几年前工作的 IT 环境中，我们让每台机器在本地写入日志文件，并每五天擦除一次。服务器每天晚上都会登录以从每台机器上获取最新的日志。如果服务器出现故障，它只会从每个人那里获取两天的日志。如果客户端出现故障，它的日志也可以在第二天被抓取。
您可以使用MSMQ。将您的日志写入 MSMQ 队列，然后有一个服务来挑选这些日志并将它们放入数据库中，或者如果您愿意，可以将它们放入中央位置的文件中。它不会是即时的，但您可以告诉它在您想要获取新的日志条目时运行。另外，由于它使用 MSMQ，因此它是可靠的。
我们的商店在将日志存储在数据库表中方面有很好的经验。您可以随时将清理安排为数据库作业，以防止它变得太大。
我们使用登录到本地共享的已知位置的方法。然后很容易让第二个进程提取这些日志以供以后处理（转储到数据库、收集和存档等）。如果收集过程终止，则不会真正受到影响。
确保您没有中心故障点。我见过这样的例子，它使用了一个所有应用程序都依赖的中央日志数据库，当它出现故障时，其他所有东西也都这样做了。不聪明。
您能否将日志文件写入人们的本地计算机，然后有一个脚本将它们作为夜间批处理作业拉到公共文件服务器？
将您的应用程序的记录器作为订阅者服务（使用远程处理）怎么样。然后实现订阅应用程序的 LogServer。当应用程序有要记录的内容时，它会将其发送给订阅者。如果出现问题，例如订阅者没有响应/死亡并且您没有工作订阅者，请在本地写入但发出警报。例如 TraceListener 和 Debug 类的多机版本。
您几乎肯定希望应用程序将日志消息从不同的线程发送到应用程序的其余部分。
我们编写了一个托管其他应用程序的应用程序（插件架构）。发生异常时，必要的信息将写入用户机器上的 XML 文件（名为 <USERNAME>.xml）。无论是根据我们的请求还是应用程序退出时，它都会将 XML 发送到 Web 服务，在那里它将文件写入我们可以去检查它们的位置。
如果 Web 服务关闭，这没什么大不了的，因为 XML 文件仍在用户的机器上，并且会在他们下次运行应用程序时被上传。
也写入数据库（如CALM），因此您只需在数据库关闭时查看日志文件
我同意craigb的评论。在 LAN 环境中应避免产生额外的单点故障。
My preference is to have the clients log locally, and then copy these log files to a central location. In this case if your log server falls over then there won't be any serious outage. Additionally, sometimes writing a log file to a network can be performance bottleneck.
Another issue with the central log server is if one application misbehaves, it can take down all the apps. I've seen countless bugs, which when encountered cause the program to enter an infinite loop and spew logs messages until the device fills up.
如果您真的需要中央日志记录，出于合规性原因或其他原因，我会写入网络驱动器，或者以syslogd的方式写入套接字。由于 syslogd 非常标准，因此在服务器上设置它应该没有任何问题，并且有大量示例代码和库可以写入它。甚至可以将硬件负载平衡配置为位于两个或更多 syslogd 服务器的前面，从而提供更高的服务可用性。