内部IT环境中日志文件的最佳位置

Question

我的所有用户都在大厅里走了一小段路，我的所有程序都在同一局域网上的工作站上运行。几年前，我让员工将所有程序的日志文件写入共享文件夹层次结构，将每个日志文件命名为以app命名的子目录中的机器名称。

但是这种安排并不是那么好，因为如果文件服务器出现故障，那么任何地方的程序都无法写入日志。然而，每当我们必须调试问题时，将日志保存在每个工作站的本地会使得阅读它们变得很麻烦。

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

将路径放在每个程序的共享日志文件夹中并不好 - 即使它是可配置的字段 - 因为我们在几十台机器上有许多程序。

我们也研究过使用微软的分布式文件系统，但价格太荒谬了。

我想要一种方法将本地网络上的许多程序的日志记录收集到一个地方，这样我就可以在不访问远程计算机的情况下进行尾随和分析。我们为所有程序使用.Net。

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

Answer 1

在几年前我工作过的IT环境中，我们让每台机器在本地编写日志文件并每隔五天擦除一次。服务器每晚都会登录以从每台机器获取最新的日志。如果服务器出现故障，它只会从每个人那里获取两天的日志。如果客户端发生故障，那么第二天也可以抓住它的日志。

Answer 2

您可以使用MSMQ。将您的日志写入MSMQ队列，然后拥有一个服务，该服务可以选择这些日志并将其放入数据库中，或者根据需要将其放入中心位置的文件中。它不是即时的，但是只要你想获得新的日志条目，你就可以告诉它运行。此外，它使用MSMQ是可靠的。

Answer 3

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

Answer 4

我们使用在本地登录到共享的已知位置的方法。然后很容易让第二个进程拉出这些日志以便以后处理（转储到数据库，收集和存档等）。如果收集过程死亡，那么什么都不会受到影响。

确保没有中心点。我已经看到过这样的例子，它使用了一个所有应用程序所依赖的中央日志记录数据库以及它何时停止其他所有内容。不聪明。

Answer 5

您是否可以将日志文件写入人员本地计算机，然后使用脚本将它们作为夜间批处理作业提取到公共文件服务器？

Answer 6

如何将应用程序的记录器作为订户服务（使用远程处理）。然后实现订阅该应用程序的LogServers。当应用程序有记录内容时，会将其发送给订阅者。如果存在问题，例如订户没有响应/死，并且您没有正在工作的订户，则在本地写入但发出警报。例如。 TraceListener和Debug类的多机器版本。

您几乎肯定希望应用程序将来自不同线程的日志消息发送到您应用程序的其余部分。

Answer 7

我们编写了一个托管其他应用程序的单个应用程序（插件架构）。发生异常时，必要的信息将写入用户计算机上的XML文件（名为＆lt; USERNAME＆gt; .xml）。根据我们的请求或应用程序退出时，它会将XML发送到Web服务，然后将文件写入我们可以去的位置并检查它们。

如果Web服务已关闭，那么由于XML文件仍在用户的计算机上，并且下次运行应用程序时会上传，因此没什么大不了的。

Answer 8

DFS包含在Windows Server中，您可以regedit启用带有CNAME的NetBIOS。

我也试过Splunk来提取和分析日志文件，但它有点像CPU，我无法放弃马力。否则，它是一个非常好的产品。

Answer 9

也写入数据库（如CALM），因此您只需在数据库关闭时拖动日志文件

Answer 10

我同意craigb的评论。在LAN环境中应避免创建其他单点故障。

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

中央日志服务器的另一个问题是，如果一个应用程序行为不当，它可能会删除所有应用程序。我遇到过无数的错误，当遇到这些错误导致程序进入无限循环并且会在设备填满之前显示消息。

如果您真的想要中央日志记录，出于合规性原因或其他原因，我会写入网络驱动器，或以syslogd的方式写入套接字。由于syslogd非常标准，所以在服务器上设置一个是不容易的，并且有很多示例代码和库可以写入它。甚至可以将硬件负载平衡配置为位于两个或更多syslogd服务器之前，从而提供更高的服务可用性。