好的，这个标题会有点令人困惑。让我试着更好地解释一下。我正在建立一个记录程序。该计划将有3个主要状态：
写入循环缓冲区文件，仅保留最后10分钟的数据。
写入缓冲区文件，忽略时间（记录所有数据）。
重命名整个缓冲区文件，并使用过去10分钟的数据启动一个新文件（并将状态更改为1）。
现在，用例就是这样。我的网络中不时遇到一些网络瓶颈。所以我想构建一个系统来检测TCP流量时检测到瓶颈（通过Nagios检测）。但是，当它检测到瓶颈时，大部分有用数据已经被传输。
所以，我想要的是一个像dumpcap一样运行的守护者。在正常模式下，它只会保留过去10分钟的数据（因为如果不需要，就没有必要保持数据的载荷）。但是当Nagios发出警报时，我会在守护神中发出信号来存储所有信息。然后，当Naigos恢复时，它将发送另一个信号以停止存储并将缓冲区刷新到保存文件。
现在，问题在于我无法看到如何干净地存储旋转10分钟的数据。我可以每隔10分钟存储一个新文件，如果处于模式1，则删除旧文件。但这对我来说似乎有点脏（特别是当弄清楚文件中发生警报的时候）。
理想情况下，保存的文件应使警报始终位于文件中的10:00标记处。虽然每10分钟就可以使用新文件，但到目前为止“修复”文件似乎有点脏。
有什么想法吗？我应该只是做一个旋转文件系统并在最后将它们组合成1（进行相当多的后处理）？有没有办法干净地实现半循环文件，以便不需要任何后期处理？
由于
哦，语言在这个阶段并不重要（我倾向于Python，但不反对任何其他语言。这不是一个问题而不是整体设计）......
答案 0 :(得分：3)
首先想到的是将MINUTES+1（在本例中为11）存储一分钟的文件。扔掉旧的。
根据要求，您可以将当前未写入的10个文件复制/合并到一个“大日志文件”中，并附加完成的每个其他文件的内容。
然后，这看起来像是“必须有类似的东西的工具”任务，也许有人会想出一个工具：）
这个问题无法解决的问题是完全数据的最后X分钟。它总是从0秒开始。
答案 1 :(得分：1)
这不完全是你想要的，但我认为MongoDB Capped Collections是你可能想要看的东西。
加盖集合是固定大小的集合，具有非常高性能的自动FIFO超时功能（超时基于插入顺序）。如果您熟悉它们，它们有点像“RRD”概念。此外，自动封顶集合具有高性能，可维护集合中对象的插入顺序;对于某些用例，例如日志记录，这是非常强大的。
所以将所有内容记录到一个上限集合中，您已修复其大小以存储大约10分钟的数据。当Nagios发送信号时，切换到存储到无上限的集合，直到瓶颈通过，然后切换回来。 MongoDB将自动处理每行基于旧数据的老化，而不是一次移出整个10分钟的文件。
答案 2 :(得分：0)
仅使用最后10分钟的原木有什么好处？要实现这一点，您需要不断检查旧日志并将其从文件中删除，然后覆盖该文件。某些DB可以更容易地实现这种功能，例如， SQLite的。
日志时间戳为您提供相同或更多。如上所述，只保留两个日志文件，如果日志文件已经有10分钟的日志 - 重命名它（覆盖旧日志）并开始记录到新文件。