3

好吧，这个标题会有点混乱。让我试着更好地解释一下。我正在构建一个日志记录程序。该程序将有 3 个主要状态：

  1. 写入循环缓冲区文件，仅保留最后 10 分钟的数据。

  2. 写入缓冲区文件，忽略时间（记录所有数据）。

  3. 重命名整个缓冲区文件，并使用过去 10 分钟的数据开始一个新文件（并将状态更改为 1）。

现在，用例是这样的。我在我们的网络中不时遇到一些网络瓶颈。所以我想建立一个系统来记录 TCP 流量，当它检测到瓶颈时（通过 Nagios 检测）。然而，当它检测到瓶颈时，大部分有用的数据已经被传输了。

所以，我想要的是有一个一直在运行的守护进程dumpcap。在正常模式下，它只会保留过去 10 分钟的数据（因为如果不需要，保留大量数据是没有意义的）。但是当 Nagios 发出警报时，我会在守护进程中发送一个信号来存储所有内容。然后，当 Naigos 恢复时，它将发送另一个信号以停止存储并将缓冲区刷新到保存文件。

现在，问题是我看不到如何干净地存储旋转 10 分钟的数据。如果处于模式 1，我可以每 10 分钟存储一个新文件并删除旧文件。但这对我来说似乎有点脏（尤其是在确定文件中何时发生警报时）。

理想情况下，已保存的文件应使警报始终位于文件中的 10:00 标记处。虽然每 10 分钟就有一次新文件可以做到这一点，但将文件“修复”到那时似乎有点脏。

有任何想法吗？我是否应该只做一个旋转文件系统并在最后将它们组合成 1 （做相当多的后处理）？有没有办法干净地实现半循环文件，从而不需要任何后处理？

谢谢

哦，在这个阶段语言并不重要（我倾向于 Python，但不反对任何其他语言。这比整体设计问题更小）......

4

3 回答 3

4

想到的第一个想法是存储MINUTES+1（在本例中为 11 个）一分钟的文件。扔掉旧的。

根据要求，您可以将当前未写入的 10 个文件复制/合并到一个“大日志文件”中，并附加完成的每个其他文件的内容。

再一次，这看起来像是“必须有类似的工具”的任务，也许有人会为此想出一个工具:)

这没有解决的一个问题是恰好有最后 X 分钟的数据。它总是从 0 秒开始。

于 2011-02-07T16:15:08.697 回答
1

这并不完全是您要寻找的东西，但我认为MongoDB Capped Collections是您可能想要查看的东西。

Capped collections 是固定大小的集合，具有非常高性能的自动 FIFO 老化功能（老化基于插入顺序）。如果您熟悉的话，它们有点像“RRD”概念。此外，自动封顶集合，高性能，维护集合中对象的插入顺序；这对于某些用例（例如日志记录）非常强大。

因此，将所有内容记录到一个有上限的集合中，该集合的大小已固定，可存储大约 10 分钟的数据。当 Nagios 发送信号时，切换到存储到无上限的集合中，直到瓶颈过去，然后切换回来。MongoDB 将自动逐行处理旧数据的老化，而不是一次移出整个 10 分钟的文件。

于 2011-02-11T23:22:58.893 回答
0

只记录最后 10 分钟的日志有什么好处？要实现这一点，您需要不断检查旧日志并将它们从文件中删除，然后覆盖文件。某些数据库（例如 SQLite）可以更轻松地实现此类功能。

日志时间戳为您提供相同的功能和更多功能。只需按照您的描述保留两个日志文件，如果日志文件已经有 10 分钟的日志 - 重命名它（覆盖旧的）并开始记录到一个新文件。

于 2011-02-11T12:22:43.823 回答