Реализовать файл Semi-Round-Robin, который можно расширять и сохранять по требованию - PullRequest
3 голосов
/ 07 февраля 2011

Хорошо, этот заголовок будет немного запутанным. Позвольте мне попытаться объяснить это немного лучше. Я строю программу регистрации. Программа будет иметь 3 основных состояния:

  1. Запись в буферный файл циклического перебора, сохраняя данные только за последние 10 минут.

  2. Запись в буферный файл без учета времени (запись всех данных).

  3. Переименуйте весь буферный файл и запустите новый с данными за последние 10 минут (и измените состояние на 1).

Вот пример использования: Время от времени я испытывал некоторые узкие места в сети. Поэтому я хочу создать систему для записи трафика TCP, когда он обнаруживает узкое место (обнаружение через Nagios). Однако к тому времени, когда он обнаруживает узкое место, большинство полезных данных уже было передано.

Итак, мне бы хотелось, чтобы у демона все время было что-то вроде dumpcap. В обычном режиме он будет хранить данные только за последние 10 минут (поскольку бессмысленно сохранять данные на лодке, если они не нужны). Но когда Nagios предупредит, я пошлю сигнал в демон, чтобы сохранить все. Затем, когда Naigos восстановится, он отправит другой сигнал, чтобы прекратить сохранение и сбросить буфер в файл сохранения.

Теперь проблема в том, что я не вижу, как правильно хранить вращающиеся 10 минут данных. Я мог бы хранить новый файл каждые 10 минут и удалять старые, если в режиме 1. Но это кажется мне немного грязным (особенно когда дело доходит до выяснения, когда в файле произошло предупреждение).

В идеале, сохраненный файл должен быть таким, чтобы предупреждение всегда находилось в отметке 10:00 в файле. Хотя это возможно для новых файлов каждые 10 минут, «исправлять» файлы к этому моменту кажется немного грязным.

Есть идеи? Должен ли я просто сделать вращающуюся файловую систему и объединить их в 1 в конце (делая довольно много постобработки)? Есть ли способ аккуратно реализовать файл с полукруглым циклом, чтобы не было необходимости в какой-либо последующей обработке?

Спасибо

Да, и на данном этапе язык не так важен (я склоняюсь к Python, но не возражаю против любого другого языка. Это менее важно, чем общий дизайн) ...

Ответы [ 3 ]

3 голосов
/ 07 февраля 2011

Первая идея, которая приходит на ум, - хранить MINUTES+1 (в данном случае 11) файлы за одну минуту.Выбрасывать старые.

По запросу вы можете скопировать / объединить 10 файлов, которые в настоящее время не записываются, в один «большой файл журнала» и добавить содержимое всех остальных файлов, которые заканчиваются.

Затем снова этовыглядит как задача «должен быть инструмент для чего-то подобного», и, возможно, кто-то придумает инструмент для этого:)

Одна проблема, которую не удается решить, это наличие точно последние X минут для данных.Он всегда начинается с 0 секунд.

1 голос
/ 12 февраля 2011

Это не совсем то, что вы ищете, но я думаю MongoDB Capped Collections - это то, на что вы, возможно, захотите взглянуть.

Закрытые коллекции - это коллекции фиксированного размера, обладающие очень высокой эффективностью автоматического истечения срока действия FIFO (срок действия зависит от порядка вставки). Они немного похожи на концепцию «RRD», если вы знакомы с этим. Кроме того, закрытые коллекции автоматически и с высокой производительностью поддерживают порядок вставки объектов в коллекции; это очень эффективно для определенных случаев использования, таких как ведение журнала.

Так что записывайте все свои вещи в ограниченную коллекцию, размер которой вы зафиксировали, чтобы хранить данные примерно за 10 минут. Когда Nagios отправляет сигнал, переключитесь на хранение в коллекцию без крышки, пока не пройдет узкое место, затем переключитесь обратно. MongoDB будет автоматически обрабатывать устаревание старых данных для каждой строки, а не извлекать целые 10-минутные файлы за раз.

0 голосов
/ 11 февраля 2011

В чём выгода, если вы берете только последние 10 минут журналов? Для этого вам необходимо постоянно проверять старые журналы и удалять их из файла, а затем перезаписывать файл. такая функциональность может быть легче достигнута некоторыми БД, например, SQLite.

временные метки журнала дают вам то же самое и больше. Просто сохраните два файла журнала, как вы описали, если в файле журнала уже есть 10 минут журналов - переименуйте его (перезаписав старый) и начните запись в новый файл.

...