我想这取决于你用它们做什么......如果你要将它们解析为度量数据到数据库中，那么在每台机器上安装该解析实用程序以解析并加载到你的中央数据库中会更快同时。
即使您所做的只是压缩并复制到一个中央位置，在 .cmd 文件中设置这些命令并安排它在每个服务器上自动运行。然后，您将在所有这些服务器之间分配工作，而不是强迫您的一个本地系统完成所有工作。:-)
想到的第一个改进是不发送整个日志文件，而只发送上次发送后的记录。这当然是假设文件是随着时间的推移而积累的，并且每次都不是全新的。
您可以通过多种方式实现这一点：如果文件具有您可以依赖的日期/时间戳，则通过过滤器运行它们，从考虑中删除较旧的记录并转储剩余部分就足够了。如果没有这样的鉴别器可用，我会跟踪发送的最后一个字节/行，并在发货前提前到那个位置。
无论哪种方式，目标都是只发布新内容。在我们自己的系统中，日志是通过一个服务传送的，该服务会在日志写入时复制它们。这需要一个小型服务来处理要写入的日志文件，但减少了捕获日志的延迟并极大地减少了带宽使用。
每个服务器可能应该：
中央服务器可能应该：
我会执行以下操作：
编写一个在每台服务器上运行的程序，该程序将执行以下操作：
监控服务器上的日志
按照特定定义的计划压缩它们 将
信息传递给分析服务器。
编写另一个位于核心服务器上的程序，它执行以下操作：
当网络/cpu 不太忙时提取压缩文件。
（这可以是多线程的。）
这使用从终端计算机传递给它的信息来确定接下来要获取哪个日志。
不断解压缩并上传到您的数据库。
这应该为您提供一个解决方案，该解决方案可提供最新信息，并且停机时间最短。
缺点是相对一致的网络/计算机使用，但这通常是一件好事。
它还将允许轻松管理系统，以检测任何需要解决的问题或问题。
NetBIOS 副本不如 FTP 快。问题是您不希望每台服务器上都有一个 FTP 服务器。如果您无法在每台服务器上本地处理日志文件，另一种解决方案是让所有服务器通过 FTP 将日志文件上传到您可以处理的中央位置。例如：
将 FTP 服务器设置为中央收集点。在每台服务器上安排任务以压缩日志文件并将存档通过 FTP 传输到中央 FTP 服务器。您可以编写一个程序，使用 schtasks.exe 之类的工具远程自动安排任务：
KB 814596：如何使用 schtasks.exe 在 Windows Server 2003 中安排任务
您可能希望错开上传回 FTP 服务器。
我们这里有一个规模较小的类似产品。我们的解决方案是让生成日志文件的机器每天以随机交错的模式将它们推送到 NAT。这解决了更多基于拉的方法的许多问题，包括使服务器忙碌数天的堆积读写时间。
听起来存储服务器的带宽不会饱和，因此您可以同时从不同位置的多个客户端拉取。主要问题是，减缓整个过程的瓶颈是什么？