Назад | Перейти на главную страницу

Хронологическое слияние больших файлов (UNIX)

В настоящее время мы используем syslog-ng для дампа файлов в сетевое хранилище. Каждый день существует 5 файлов .log, которые записываются различными серверами, и в конце дня мне нужно объединить 5 файлов в хронологическом порядке, а затем сжать их. Последние 2 года я использовал logmerge и это сработало отлично. Точный синтаксис:

/local/bin/logmerge -f /mnt/logs/Windows/`date -d yesterday +\%Y-\%m-\%d`-sys*.log | gzip -9 -c > /mnt/logs/Windows/`date -d yesterday +\%Y-\%m-\%d`.log.gz && rm -f /mnt/logs/Windows/`date -d yesterday +\%Y-\%m-\%d`-sys*.log

За последние несколько недель этот процесс нарушился из-за большого размера файлов .log. Каждый из них теперь превышает 7 ГБ, и процесс слияния журналов не работает при сортировке такого количества строк. Прямо сейчас я просто сжимаю их, но это усложняет поиск, потому что журналы не в порядке.

Есть ли лучший способ объединить эти файлы и заархивировать их?

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

Одна из возможностей - использовать стек ELK:

  • Elasticsearch в качестве базы данных (она основана на Lucene, поэтому ориентирована на поиск, но также предоставляет ряд функций агрегации, уменьшения карты и связанных функций)
  • Logstash в качестве агента приема журналов и парсера - вы можете, среди прочего, использовать ввод системного журнала для получения журналов с ваших узлов (вы можете отправить их напрямую или использовать свой локальный демон syslog-ng для подачи копии в logstash)
  • Кибана используется для визуализации, поиска и управления вашими журналами.

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

Logstash также может использоваться на машинах Windows для чтения журнала событий, что может позволить вам достичь ваших целей вообще без использования системного журнала (если я правильно читаю между строк вашей настройки).

Также может быть что-то, что вы можете сделать с тем, как пишутся журналы, чтобы избежать таких массивных файлов, но я бы склонен думать, что если вы регулярно имеете дело с 7 ГБ журналов, вам периодически нужно искать, решение, ориентированное на к этому варианту использования может быть более практичным.

Обновлено Понимаю. В этом случае невозможно, чтобы syslog-ng записывал все в один массивный ежедневный файл (а не 5), или чтобы syslog-ng записывал все в серию файлов до определенного размера (например, 10 файлов 700M , каждая создана после последней заливки)?

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