Лучший подход к сбору файлов журналов с удаленных машин?

Question

У меня более 500 машин, распределенных по глобальной сети, охватывающей три континента. Периодически мне нужно собирать текстовые файлы, которые находятся на локальном жестком диске на каждом блейде. Каждый сервер работает под управлением Windows Server 2003, и файлы монтируются на общем ресурсе, к которому можно получить удаленный доступ как \ server \ Logs. На каждой машине хранится много файлов, каждый из которых может занимать несколько мегабайт, а размер может быть уменьшен путем архивирования.

До сих пор я пытался использовать скрипты Powershell и простое Java-приложение для копирования. Оба подхода занимают несколько дней, чтобы собрать 500Gb или около того файлов. Есть ли лучшее решение, которое было бы быстрее и эффективнее?

Answer 1

Полагаю, это зависит от того, что вы с ними делаете ... если вы собираетесь анализировать их для данных метрик в базе данных, было бы быстрее установить утилиту синтаксического анализа на каждой из этих машин для анализа и загрузки в центральная база данных одновременно.

Даже если все, что вы делаете - это сжимаете и копируете в центральное место, настройте эти команды в файле .cmd и запланируйте их автоматический запуск на каждом из серверов. Тогда вы будете распределять работу между всеми этими серверами, вместо того чтобы заставлять вашу локальную систему выполнять всю работу. : -)

Answer 2

Первое, что приходит на ум, это не отгружает целые файлы журналов, а только записи после последней отправки. Это, конечно, предполагает, что файлы накапливаются с течением времени и каждый раз не являются полностью новыми.

Вы можете реализовать это по-разному: если файлы имеют метки даты / времени, на которые вы можете положиться, их можно пропустить через фильтр, который удаляет старые записи из рассмотрения и сбрасывает оставшуюся часть. Если такого доступного дискриминатора нет, я бы проследил за последним отправленным байтом / линией и перешел бы к этому месту перед отправкой.

В любом случае, цель состоит в том, чтобы только отправить новый контент. В нашей собственной системе журналы доставляются через службу, которая копирует журналы по мере их записи. Это потребовало небольшого сервиса, который обрабатывал файлы журналов для записи, но уменьшил задержку при захвате журналов и значительно сократил использование полосы пропускания.

Answer 3

Каждый сервер, вероятно, должен:

• управлять своими файлами журналов (запускать новые журналы перед загрузкой и удалять отправленные журналы после загрузки)
• Назовите файлы (или добавьте метаданные), чтобы сервер знал, какой клиент отправил их и какой период они охватывают
• сжатие файлов журнала перед отправкой (сжатие + FTP + распаковка часто выполняется быстрее, чем только FTP)
• отправка файлов журнала в центральное место (FTP быстрее, чем SMB, команда windows FTP может быть автоматизирована с помощью "-s: scriptfile")
• уведомляет вас, когда по какой-либо причине не может отправить свой журнал
• делать все вышеперечисленное в шахматном порядке (чтобы избежать перегрузки центрального сервера)
  • Возможно, использовать последний IP-октет сервера, умноженный на константу, для смещения в минутах от полуночи?

Центральный сервер, вероятно, должен:

• принимать отправленные файлы журналов и ставить их в очередь на обработку
• изящно обрабатывает получение одного и того же файла журнала дважды (его следует игнорировать или повторно обрабатывать?)
• распаковываете и обрабатываете файлы журналов при необходимости
• удаление / архивирование обработанных файлов журнала в соответствии с политикой хранения
• уведомляет вас, когда сервер в последнее время не загружал свои журналы

Answer 4

NetBIOS-копии не такие быстрые, как, скажем, FTP. Проблема в том, что вам не нужен FTP-сервер на каждом сервере. Если вы не можете обработать файлы журналов локально на каждом сервере, другое решение состоит в том, чтобы все серверы загружали файлы журналов через FTP в центральное место, которое вы можете обрабатывать. Например:

Установите FTP-сервер в качестве центрального пункта сбора. Запланируйте задачи на каждом сервере для архивирования файлов журналов и передачи архивов на ваш центральный FTP-сервер. Вы можете написать программу, которая автоматизирует планирование задач удаленно, используя такой инструмент, как schtasks.exe:

КБ 814596: Как использовать schtasks.exe для планирования задач в Windows Server 2003

Скорее всего, вы захотите откатить загрузку обратно на FTP-сервер.

Answer 5

Я бы сделал следующее:
Напишите программу для запуска на каждом сервере, которая будет выполнять следующие действия:
Мониторинг логов на сервере
Сжать их по определенному расписанию
Передайте информацию на сервер анализа.

Напишите другую программу, которая работает на ядре srver и выполняет следующие действия:
Извлекает сжатые файлы, когда сеть / процессор не слишком заняты.
(Это может быть многопоточным.)
При этом используется информация, переданная ему с конечных компьютеров, чтобы определить, какой журнал следует получить.
Распаковывайте и загружайте в свою базу данных постоянно.

Это должно дать вам решение, которое предоставляет актуальную информацию с минимальным временем простоя.
Недостатком будет относительно последовательное использование сети / компьютера, но это часто хорошо.

Это также позволит легко управлять системой, обнаруживать любые проблемы или проблемы, которые необходимо решить.

Answer 6

Не похоже, что пропускная способность серверов хранения была бы насыщенной, так что вы можете получать данные от нескольких клиентов в разных местах параллельно. Главный вопрос: что является узким местом, которое замедляет весь процесс?

Answer 7

У нас есть аналогичный продукт в меньшем масштабе здесь. Наше решение состоит в том, чтобы машины, генерирующие файлы журналов, ежедневно передавали их в NAT в случайном порядке. Это решило множество проблем более основанного на извлечении метода, включая сжатые времена чтения-записи, которые поддерживали сервер в течение нескольких дней.