我们正在使用syslog-ng将文件转储到networking存储位置。 每天有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 GB，logmerge进程在sorting这么多行时失败了。 现在我只是把它们拼凑起来，但是由于日志不正确，search变得更加困难。
有没有更好的方法来合并这些文件并将其压缩？
这听起来像你可能想要查看某种forms的数据库来存储你的日志。
一种可能是使用ELK栈：
这不一定是你可能一直在寻找的答案，但听起来像你可能有一个像它这样的解决scheme的合法用例。 你也可以考虑像Splunk这样的东西，但考虑到你的数据量，这将花费你。
Logstash也可以在Windows机器上用来读取EventLog，所以可以让你实现你的目标而不使用系统日志（如果我正在阅读你的设置正确的行之间）。
也许你可以做一些关于如何写日志来帮助避免如此庞大的文件，但是我倾向于认为，如果你经常处理7GB的日志，你需要定期search，解决scheme齿轮对于这个用例可能更实际一些。
更新我看。 在这种情况下，是不是可以将syslog-ng写入一个大型的日常文件（而不是5个），或者让syslog-ng将所有内容写入一系列特定大小的文件（例如，10 700M文件，每个创build后最后填充）？
这听起来好像是你的数据出了问题，而且我会认为有办法通过相应的configurationsyslog来避免这个问题。 由于听起来像时间戳比来源更重要，所以我会想象单独的时间戳（或者可能是时间戳和最大日志大小）应该确定事件如何存储在第一位。