Хронологическое слияние больших файлов (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)
- Kibana используется для визуализации, поиска и управления вашими журналами.
Это не обязательно ответ, который вы, возможно, искали, но похоже, что у вас может быть законный вариант использования подобного решения. Вы также можете рассмотреть что-то вроде Splunk , но с учетом вашего объема данных это будет стоить вам.
Logstash также может использоваться на компьютерах Windows для чтения журнала событий, что может позволить вам достичь ваших целей вообще без использования системного журнала (если я правильно читаю между строк вашей настройки).
Это также может быть есть что-то, что вы можете сделать с тем, как пишутся журналы, чтобы избежать таких массивных файлов, но я бы склонен думать, что если вы регулярно имеете дело с 7 ГБ журналов, вам периодически нужно искать, решение, ориентированное на этот вариант использования может быть более практичным.
Обновлено Понятно. В этом случае невозможно, чтобы syslog-ng записывал все в один массивный ежедневный файл (а не 5), или чтобы syslog-ng записывал все в серию файлов до определенного размера (например, 10 файлов 700M , каждое из которых создается после последнего заполнения)?
Похоже, проблема в том, что ваши данные вышли из строя, и я подумал, что есть способы избежать этой проблемы, настроив системный журнал соответствующим образом. Поскольку кажется, что временные метки более важны, чем источники, я мог бы предположить, что одни только временные метки (или, возможно, временные метки и максимальный размер журнала) должны определять, как события хранятся в первую очередь.