从远程计算机收集日志文件的最佳方法?

我想这取决于你怎么处理他们。。。如果要将它们解析为度量数据到数据库中,那么在每台计算机上安装解析实用程序以便同时解析并加载到中央数据库中会更快。

即使您所做的只是压缩和复制到一个中心位置,也可以在一个.cmd文件中设置这些命令,并安排它自动在每个服务器上运行。然后,您将在所有这些服务器之间分发工作,而不是强迫您的一个本地系统来完成所有工作。:-)

首先想到的改进是 装运整个日志文件,但只发送上次装运后的记录。当然,这是假设这些文件是随着时间的推移而积累起来的,而不是每次都是全新的。

不管怎样,目标都是只发货 内容。在我们自己的系统中,日志是通过一个服务发送的,该服务在日志写入时复制日志。这需要一个小型的服务来处理要写入的日志文件,但是减少了捕获日志的延迟,并大大减少了带宽的使用。

每台服务器可能应该:

• 管理自己的日志文件(上传前启动新日志,上传后删除发送日志)
• 为文件命名(或预先准备元数据),以便服务器知道是哪个客户机发送的文件以及它们所覆盖的时间段
• 在发布之前压缩日志文件(compress+FTP+uncompress通常比单独使用FTP更快)
• 将日志文件推送到中心位置(FTP比SMB快,可以使用“-s:scriptfile”自动执行windows FTP命令)
• 当它由于任何原因无法推送其日志时通知您
• • 也许使用服务器的最后一个IP八位字节乘以一个常量,以分钟为单位从午夜开始偏移?

中央服务器可能应该:

• 接受发送的日志文件并对其进行队列处理
• 优雅地处理接收同一日志文件两次(应该忽略还是重新处理?)
• 根据需要解压缩并处理日志文件
• 根据保留策略删除/存档已处理的日志文件
• 当服务器最近没有推送其日志时通知您

我们这里有一个小规模的类似产品。我们的解决方案是让生成日志文件的机器每天以随机交错的模式将它们推送到NAT。这解决了基于拉的方法的许多问题,包括使服务器忙了好几天的读写时间。

听起来存储服务器的带宽不会饱和,所以您可以并行地从多个不同位置的客户机中提取数据。主要的问题是,什么是阻碍整个进程的瓶颈?

我会做以下事情:

监视服务器上的日志
按特定的计划压缩它们

编写另一个位于核心srver上的程序,该程序执行以下操作:
当网络/cpu不太忙时,拉取压缩文件。
(这可以是多线程的。)
它使用从终端计算机传递给它的信息来确定下一个要获取的日志。
解压并持续上传到你的数据库。

缺点是相对一致的网络/计算机使用,但这通常是一件好事。

它还可以方便地管理系统,检测任何需要解决的问题或问题。

NetBIOS拷贝不如FTP快。问题是你不希望在每台服务器上都有一个FTP服务器。如果无法在每台服务器上本地处理日志文件,另一种解决方案是让所有服务器通过FTP将日志文件上载到一个中心位置,您可以从该中心位置进行处理。例如:

KB 814596: How to use schtasks.exe to Schedule Tasks in Windows Server 2003

您可能需要错开上传到FTP服务器。