我所有的用户仅几步之遥，我的所有程序都在同一LAN上的工作站上运行。几年前，我让工作人员将所有程序的日志文件写入共享文件夹层次结构，在以该应用程序命名的子目录中，以机器名命名每个日志文件。

但是这种安排并不是很好，因为如果文件服务器崩溃，那么任何地方的程序都不会写日志。但是，将日志保存在每个工作站的本地位置将使我们在每次调试问题时都很难读懂日志。

我们尝试为日志文件服务器创建DNS别名，以便在必要时将其指向备份计算机，但是DNS别名不适用于Windows文件共享。

将路径放置到每个程序中的共享日志文件夹中并不是一件好事，即使它是可现场配置的，因为我们在数十台机器上有数十个程序。

我们还研究了使用Microsoft的分布式文件系统，但是价格太高了。

我想要一种将本地网络上许多程序的日志收集到一个地方的方法，这样我就可以进行尾部分析，而无需访问远程计算机。我们将.Net用于所有程序。

编辑：我想避免在每个用户的工作站上设置文件共享，或者避免每晚搜查日志的解决方案，因为我希望能够按需读取新日志，或者在报告问题后立即读取。

解决方案

在几年前我工作过的IT环境中，我们让每台计算机在本地写入其日志文件，并每五天擦除一次。服务器将每晚登录，以获取每台计算机上的最新日志。如果服务器出现故障，它将仅从每个人那里获取两天的日志。如果客户失败了，第二天也可以获取日志。

我们能否将日志文件写到人们的本地计算机上，然后有一个脚本将其作为夜间批处理作业拉到公用文件服务器上？

将应用程序的记录器作为订户服务(使用远程处理)怎么样？然后实现订阅该应用程序的LogServer。当应用程序需要记录某些内容时，它会将其发送给订阅者。如果存在问题，例如订户没有响应/死机，并且我们没有正在工作的订户，请在本地写入但会发出警报。例如。 TraceListener和Debug类的多计算机版本。

我们几乎可以肯定希望该应用程序将日志消息从另一个线程发送到应用程序的其余部分。

我们可以使用MSMQ。将日志写入MSMQ队列，然后提供一项服务，将这些日志收集起来并将它们放入数据库中，或者如果需要，将其放入中央位置的文件中。它不是瞬时的，但是我们可以告诉它要获取新的日志条目时就运行。另外，由于它使用MSMQ，因此它将是可靠的。

我们编写了一个承载其他应用程序的应用程序(插件体系结构)。发生异常时，必要的信息将被写入用户计算机上的XML文件(名为<USERNAME> .xml)。根据我们的请求或者当应用程序退出时，它将XML发送到Web服务，然后在Web服务中将文件写入到我们可以检查的位置。

如果Web服务关闭，则没什么大不了的，因为XML文件仍在用户的计算机上，并且在下次运行该应用程序时将被上载。

DFS包含在Windows Server中，我们可以进行注册以使用CNAME启用NetBIOS。

我也尝试过Splunk来提取和分析日志文件，但是这有点像CPU消耗的东西，我无法不花力气。但是，否则，它是一个非常不错的产品。

我们的商店在将日志存储到数据库表方面具有丰富的经验。我们可以随时将清理计划为数据库作业，以防止清理作业变得太大。

还写入数据库(例如CALM)，因此我们仅需在数据库关闭时拖曳日志文件

我们使用登录到本地共享的已知位置的方法。然后，很容易让第二个进程提取这些日志以供以后处理(转储到数据库，收集和存档等)。如果收集过程终止，那么实际上什么都没有受到影响。

确保我们没有故障的中心点。我看过这样的示例，该示例使用了所有应用程序都依赖的中央日志记录数据库，并且当它崩溃时，其他所有操作也都执行了。不聪明。

我同意克雷格的评论。在局域网环境中，应避免创建其他单点故障。

我的首选是让客户端在本地登录，然后将这些日志文件复制到中央位置。在这种情况下，如果日志服务器发生故障，则不会有任何严重的中断。此外，有时将日志文件写入网络可能会成为性能瓶颈。

中央日志服务器的另一个问题是，如果一个应用程序行为不当，则它可能会关闭所有应用程序。我见过无数的bug，遇到这些bug会使程序进入无限循环并喷出日志消息，直到设备装满为止。

如果确实需要，出于合规性原因或者其他原因，需要中央日志记录，那么我或者写入网络驱动器，或者以syslogd的方式写入套接字。由于syslogd是非常标准的，因此在服务器上进行设置没有任何麻烦，并且有很多示例代码和库可以写入该示例。甚至可以将硬件负载平衡配置为位于两个或者更多syslogd服务器的前面，从而提供更高的服务可用性。