我们目前正在使用 syslog-ng 将文件转储到网络存储位置。每天有 5 个由各种服务器写入的 .log 文件，每天结束时我需要按时间顺序合并这 5 个文件，然后压缩它们。在过去的 2 年里，我使用日志合并效果很好。确切的语法是：
/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 GB，日志合并过程无法对这么多行进行排序。现在我只是对它们进行 gzip 压缩，但由于日志没有按顺序排列，因此搜索变得更加困难。
有没有更好的方法来合并这些文件并将它们压缩起来？
答案1
听起来你可能想要研究某种形式的数据库来存储你的日志。
一种可能性可能是使用 ELK 堆栈：
- Elasticsearch作为数据库（它基于 Lucene，因此适用于搜索，但也提供许多聚合、map-reduce 和相关功能）
- Logstash作为日志提取和解析代理 - 除其他外，您还可以使用系统日志输入从你的节点接收日志（你可以直接发送它们，或者使用本地 syslog-ng 守护进程将副本提供给 logstash）
- 基巴纳用于可视化、搜索和操作您的日志。
这不一定是你一直在寻找的答案，但听起来你可能有一个合法的解决方案用例。你也可以考虑类似Splunk，但考虑到您的数据量，这将花费您一些钱。
Logstash 还可以在 Windows 机器上使用来读取 EventLog，因此可能允许您完全不使用 syslog 来实现您的目标（如果我正确地读懂了您的设置的字里行间的话）。
您可能还可以对日志的写入方式进行一些处理，以帮助避免产生如此庞大的文件，但我倾向于认为，如果您定期处理需要定期搜索的 7GB 日志，那么针对该用例的解决方案可能会更实用。
更新我明白了。在这种情况下，是否不可能让 syslog-ng 将所有内容写入一个巨大的每日文件（而不是 5 个），或者让 syslog-ng 将所有内容写入一系列不超过一定大小的文件（例如，10 个 700M 文件，每个文件在最后一次填充后创建）？
听起来问题确实是数据乱序了，我原本以为可以通过相应配置 syslog 来避免该问题。由于时间戳似乎比来源更重要，因此我认为时间戳本身（或者可能是时间戳和最大日志大小）应该首先决定事件的存储方式。