我有超過500臺機器分佈在覆蓋三大洲的廣域網上。定期地，我需要收集每個刀片上本地硬盤上的文本文件。每臺服務器都運行Windows Server 2003，並將這些文件安裝在共享位置，可以通過\ server \ Logs遠程訪問。每臺機器都擁有多個文件，每個文件可以是幾個Mb，並且可以通過壓縮縮小大小。從遠程機器收集日誌文件的最佳方法？
到目前爲止，我已經嘗試使用Powershell腳本和一個簡單的Java應用程序來進行復制。這兩種方法都需要幾天才能收集500Gb左右的文件。有更好的解決方案可以更快更高效嗎？
想到的第一個改進是而不是發送整個日誌文件，但只有最後一次發貨後的記錄。這當然是假設文件正在累積，並且每次都不是全新的。
您可以通過多種方式實現它：如果文件具有可以依賴的日期/時間戳記，可以通過過濾器運行它們，從考慮中刪除舊記錄並轉儲餘下的就足夠了。如果沒有可用的鑑別器，我會跟蹤發送的最後一個字節/行，並在發貨前前往該位置。
無論哪種方式，目標是隻發貨新的內容。在我們自己的系統中，日誌通過一個服務發貨，該服務在寫入日誌時複製日誌。這需要一個處理日誌文件的小型服務，但是捕獲日誌和減少帶寬使用的延遲非常大。
我想這取決於你對他們做什麼......如果你要解析他們的指標數據到數據庫中，那麼在每個這些機器上安裝解析實用程序來解析並加載到您的中央數據庫在同一時間。
即使您正在進行的操作是壓縮並複製到中央位置，也需要在.cmd文件中設置這些命令並將其安排在每臺服務器上自動運行。然後，您將在所有這些服務器之間分配工作，而不是強迫您的一個本地系統完成所有工作。 :-)
我們在這裏有一個小規模的類似產品。我們的解決方案是讓生成日誌文件的計算機每天以隨機交錯的模式將它們推送到NAT。這解決了更多基於拉的方法的問題，包括使服務器繁忙數日的分組讀取寫入時間。
這聽起來不像存儲服務器的帶寬會飽和，所以你可以從幾個並行的不同位置的客戶端拉。主要問題是，減緩整個過程的瓶頸是什麼？
我會做到以下幾點：
寫一個程序，每臺服務器上運行，這將做到以下幾點：
監控服務器上的日誌
在特定定義的計劃
傳遞信息壓縮他們的分析服務器。
編寫另一個程序，它位於核心srver上，它執行以下操作：
當網絡/ CPU不太忙時，取出壓縮文件。
（這可以是多線程的。）
這將使用從最終計算機傳遞給它的信息來確定下一個要獲取的日誌。
不斷壓縮並上傳到您的數據庫。
這應該爲您提供一個解決方案，它提供了最新的信息和最少的停機時間。
不利的一面是網絡/計算機的使用比較一致，但tbh通常是件好事。
它還可以輕鬆管理系統，檢測任何需要解決的問題或問題。
NetBIOS副本並不像FTP那麼快。問題是你不想在每臺服務器上安裝FTP服務器。如果您無法在每臺服務器上本地處理日誌文件，則另一種解決方案是讓所有服務器通過FTP將日誌文件上載到中央位置，您可以從中央位置進行處理。例如：
將FTP服務器設置爲中央收集點。在每臺服務器上安排任務以壓縮日誌文件並將檔案傳輸到您的中央FTP服務器。你可以寫一個程序，它能夠自動的遠程使用的工具像SchTasks.exe會的任務調度：
KB 814596: How to use schtasks.exe to Schedule Tasks in Windows Server 2003
你可能會希望錯開上傳回FTP服務器。
每個服務器也許應該：
中央服務器或許應該：
文件傳輸是否需要幾天或壓縮過程？ – 2009-01-26 22:40:58