Превращение файла журнала в своего рода кольцевой буфер

Самой близкой вещью, о которой я могу думать, является RRDTools, но вероятно это не то, что Вы ищете. Другое решение состояло бы в том, чтобы контролировать, файл журнала (говорите каждую секунду или в Linux с inotify), например, Вы пишете сценарий как:

while :; do
  if [[ $(stat -c %s $FILE) -gt 10000 ]]; then
    # rotate the log
  fi
  sleep 1
done

с inotify:

while :; do
  if inotifywait [some options] $FILE; then
    # check size and rotate the file
  fi
done

Можно использовать мультижурнал от Daemontools djb. Вы передаете свой вывод журнала по каналу в него. Да это - вращение журнала, но вращения просто:

ln current $tai64nlocaltimestamp

Который, в примерно любой современной файловой системе Linux супер быстрая операция. Можно указать, сколько файлов журнала Вы хотите, как большой Вы хотите их. сделайте файлы 10 x 1024 МБ, и у Вас будет свой кольцевой буфер на 1 ГБ.

Обратите внимание на то, что из-за автоматического вращения, это - один источник на экземпляр мультижурнала. Но можно работать вокруг этого путем записи простой обертки с netcat или вручную.

Вы могли сделать канал FIFO и затем от того чтения это с помощью сценария, который вставляет в базу данных. Когда счетчик достигнет 1,000, перезапустите идентификационный номер, вставляемый в базу данных. Не работал бы на размер, конечно, но Вы использовали это в качестве примера, таким образом, я предполагаю, что это - теоретический вопрос.

Интересный вопрос; Вы обычно не рассматриваете что как дизайн. У меня действительно есть программа, которая использует слабо подобную технику для записи истории, но она использует двоичный формат. 'Файл журнала' имеет четыре части, все размеченные в машине нейтральном формате:

1. Заголовок, содержащий магическое число и (максимальное) количество записей в используемом списке и бесплатном списке, порядковом номере для следующей записи истории, фактического количества записей в используемом списке, фактического количества записей в бесплатном списке и длины файла (каждый из которых составляет 4 байта).
2. Используемый список, каждая запись, дающая смещение и длину (4 байта для каждой части каждой записи).
3. Бесплатный список, каждая запись, подобная используемой записи списка.
4. Основные данные, каждая запись истории, состоящая из непрерывного набора байтов, завершенных пустым байтом разделителя.

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

Основной код истории кода находится в двух файлах, history.c и history.h, доступном из источника для программы SQLCMD (моя версия, не Microsoft; мой был существующим десятилетие или больше перед Microsoft), который может быть загружен с Архива программного обеспечения Международной Группы пользователей Informix. Существует также программа дампа файла истории (histdump.c) и тестер истории (histtest.ec - она утверждает, что была ESQL/C, но является самостоятельно действительно C кодом; одна из функций поддержки это называет использование некоторыми библиотечными функциями ESQL/C Informix). Свяжитесь со мной, если Вы хотите экспериментировать, не используя Informix, ESQL/C - видит мой профиль. Существуют некоторые тривиальные изменения для создания, чтобы это скомпилировало histtest вне своей обстановки дизайна, плюс Вы нуждаются в make-файле.

Я соглашаюсь с комментарием pehr к Вашему вопросу. Вращение журнала не это трудно. Можно настроить logrotate или другой сценарий для периодической проверки файла журнала, как раз когда часто как каждую минуту если Вы, так пожелайте. То, когда это обнаруживает Ваш файл, достигает 1 ГБ в размере, это просто выполняет переименовывание, которое не берет рядом ни с каким вводом-выводом. Во время переименовывания процесса продолжает писать файл журнала. Вращающее устройство журнала может затем отправить ПОНУКАНИЕ Вашему демону системного журнала (Ваш демон регистрируется через системный журнал, правильно? В противном случае это должно поддерживать Сигнал HUP, если это правильно написано...) иметь его, вновь открыли исходный путь к файлу. В этой точке это начнет писать в новый файл в первоначальном тракте, и можно удалить повернутую версию.