Ребята, есть ли решение * nix, которое заставит файл журнала работать как кольцевой буфер? Например, я бы хотел, чтобы в файлах журналов хранилось максимум 1 ГБ данных, а старые записи удалялись по достижении лимита.
Это вообще возможно? Я считаю, что для этого нужно превратить лог-файл в какое-то особое устройство ...
P.S. Я знаю о разных инструментах для ротации журналов, но это не то, что мне нужно. Логротация требует большого количества операций ввода-вывода, обычно происходит один раз в день, в то время как мне нужно решение «во время выполнения».
В Linux есть кольцевой буфер ядра. Ты можешь использовать dmesg к показать это.
Или Вот - это модуль ядра Linux, который делает то, что вы хотите.
Что такое emlog?
emlog - это модуль ядра Linux, который упрощает доступ к самым последним (и только самым последним) выводам процесса. Он работает так же, как "tail -f" для файла журнала, за исключением того, что требуемая память никогда не увеличивается. Это может быть полезно во встроенных системах, где недостаточно памяти или дискового пространства для хранения полных файлов журнала, но иногда требуются самые последние отладочные сообщения (например, после обнаружения ошибки).
Модуль ядра emlog реализует простой драйвер символьного устройства. Драйвер действует как именованный канал с ограниченным кольцевым буфером. Размер буфера легко настраивается. По мере того, как в буфер записывается больше данных, самые старые данные удаляются. Процесс, который читает с устройства emlog, сначала прочитает существующий буфер, а затем увидит новый текст по мере его написания, аналогично мониторингу файла журнала с помощью «tail -f». (Также поддерживаются неблокирующие чтения, если процессу необходимо получить текущее содержимое журнала без блокировки ожидания новых данных.)
Самое близкое, что я могу придумать, - это 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 ГБ.
Обратите внимание, что из-за автоматической ротации это один источник на экземпляр multilog. Но вы можете обойти это, написав простую оболочку с помощью netcat или вручную.
Вы можете создать канал FIFO, а затем прочитать его с помощью сценария, который вставляется в базу данных. Когда счетчик достигнет 1000, перезапустите номер идентификатора, вставляемый в базу данных. Конечно, не сработает для размера, но вы использовали это в качестве примера, поэтому я предполагаю, что это теоретический вопрос.
Интересный вопрос; вы обычно не воспринимаете это как дизайн. У меня есть программа, которая использует немного похожую технику записи истории, но использует двоичный формат. «Файл журнала» состоит из четырех частей, каждая из которых имеет машинно-нейтральный формат:
Когда выделяется новая запись, если в свободном списке есть место, она перезаписывает там запись (не обязательно используя все это - в этом случае фрагмент остается в свободном списке). Когда в свободном списке нет места, в конце выделяется новое место. При ротации старой записи ее пространство перемещается в свободный список и объединяется с любыми соседними свободными записями. Он предназначен для обработки операторов SQL, поэтому записи могут быть распределены по многим строкам. Этот код работает с указанным количеством записей. Он не ограничивает размер файла как такового (хотя это было бы несложно).
Основной код истории кода находится в двух файлах, history.c и history.h, доступных из источника для программы SQLCMD (моя версия, а не Microsoft; моя существовала за десять или более лет до Microsoft), которые можно загрузить с Международной группы пользователей Informix Архив программного обеспечения. Существует также программа дампа файла истории (histdump.c) и тестер истории (histtest.ec - он утверждает, что это ESQL / C, но сам по себе является кодом C; одна из вызываемых им функций поддержки использует некоторый Informix ESQL / C). библиотечные функции). Свяжитесь со мной, если вы хотите поэкспериментировать без использования Informix ESQL / C - см. Мой профиль. Необходимо внести несколько тривиальных изменений, чтобы он скомпилировал histtest вне среды разработки, плюс вам понадобится make-файл.
Я согласен с комментарием pehrs к вашему вопросу. Ротация бревен не так уж и сложна. Вы можете настроить logrotate или другой скрипт для периодической проверки файла журнала, даже если хотите, каждую минуту. Когда он обнаруживает, что размер вашего файла достигает 1 ГБ, он просто выполняет переименование, которое практически не требует ввода-вывода. Во время переименования процесс продолжает запись файла журнала. Затем ротатор журналов может отправить HUP вашему демону системного журнала (вашему демону является ведение журнала через системный журнал, верно? В противном случае он должен поддерживать сигнал HUP, если он хорошо написан ...), чтобы повторно открыть исходный путь к файлу. На этом этапе он начнет запись в новый файл по исходному пути, и вы сможете удалить повернутую версию.