Circular logs

Старые логи при этом архивируются, но только один раз. Называется logrotate, есть такой демон.

Зачем если можно просто ставить timestamp и никаких сбрасываний?

Да, наверное, сбросив счётчик, старые логи можно просто заархивировать, так должно быть проще и можно обойтись без StartMarker.

Зачем если можно просто ставить timestamp и никаких сбрасываний?

Лишние 4 байта(?) на одну запись, не?

А может и правда logrotate? всё написали до тебя.

Лишние 4 байта(?) на одну запись, не?

один файл :: одна запись ~сотня байт (раз уж 4 жалка) ?? и городятся они судя по всему часто

ох и нихрена себе..

Просто юзай systemd-journald :]

На имя файла

Покритикуйте механизм.

Велосипед^WМеханизм не нужен, есть logrotate.

И предложенная схема именования - говно, да.

Ну ок, можно использовать timestamp файловой системы. А почему не сбрасывать счётчик тогда?

Велосипед^WМеханизм не нужен, есть logrotate.

Как я понял из man'a, он хорош для демонов, и для него нужно ещё конфигурационный файл настраивать (т.е. на каждой запускаемой машине получается).

Тогда уж лучше пиши дату в формате, скажем, %Y%m%d_%T, а при формировании очередного файла считай, сколько их там, да удаляй самые старые.

Дельно, спасибо.

Как я понял из man'a, он хорош для демонов

Ему безразлично.

и для него нужно ещё конфигурационный файл настраивать (т.е. на каждой запускаемой машине получается)

Приличные люди включают этот файл в инсталляционный пакет.

Не понимаю в чем твой вопрос. Просто делаешь имена с таймстемпом и этого достаточно, лишние можно удалять.

Вот идея

vertexua@vxcomp$ touch dump_log_`date +%s`.txt
vertexua@vxcomp$ touch dump_log_`date +%s`.txt
vertexua@vxcomp$ touch dump_log_`date +%s`.txt
vertexua@vxcomp$ touch dump_log_`date +%s`.txt
vertexua@vxcomp$ touch dump_log_`date +%s`.txt
vertexua@vxcomp$ touch dump_log_`date +%s`.txt
$ ls
dump_log_1381140052.txt  dump_log_1381140053.txt  dump_log_1381140054.txt  dump_log_1381140057.txt  dump_log_1381140080.txt  dump_log_1381140081.txt
vertexua@vxcomp$ ls * | sed -n 's/\(^dump_log_\([0-9][0-9]*\).txt\)/\1 \2/p' | sort -rn -k2 | tail -n +4 | awk '{print $1}' | xargs rm -v
удалено «dump_log_1381140054.txt»
удалено «dump_log_1381140053.txt»
удалено «dump_log_1381140052.txt»
vertexua@vxcomp$ ls
dump_log_1381140057.txt  dump_log_1381140080.txt  dump_log_1381140081.txt

sed там на кой черт? Просто по ctime сортируй: ls --time=ctime -r, а потом удаляй N первых.

Да пофиг по чему, я просто хотел показать что вот есть таймстемпы в имени, которые в том числе добавляют уникальности ну и еще по ним можно сортировать. Но ctime вполне подойдет

Да, я уже понял идею, спасибо.

а при формировании очередного файла считай, сколько их там...

Нашёл недостаток в этом подходе, подумываю опять вернуться к идее с маркером. Допустим я поставил ограничение 100к файлов, на файле 100001 мне нужно будет найти один старый и удалить, что займёт дофига времени.
Как вариант, конечно, можно просматривать файлы скажем не каждый раз, а 100к + 10%, к примеру, чтобы избежать слишком частых операций чтения/записи...

Либо создать ещё один поток, который просто следит за количеством файлов, проверяя их количество раз в минуту, допустим )

Можно и без сортировки: имена файлов заносишь в отдельный файл. Количество файлов == количеству "\n", mmap'ом его подключай, чтобы не париться. Считаешь, сколько там файлов, вычисляешь количество лишних, удаляешь эти файлы с диска и список, начиная с номера самого старого файла, пересохраняешь. Времени на сортировку тратить не надо.

А если в начало файлика со списком логов сохранять и общее количество файлов, то совсем халява будет. Правда, это уже эдакая файло-ориентированная БД получится.

100000 файлов обработаются моментально. Логи все равно все раз в день чистят. Даже если раз в час, то посчитай сколько времени понадобится тебе для достижения 100000

• Писать сразу в запакованном виде.
• logrotate - говно, не надо им пользоваться
• на последний файл при его открытии просто делается ссылка, при закрытии файл переменуется. Т.е. текущий имеет имя в вида hhh_[date].log.gz.tmp после закрытия становится hhh_[date].log.gz
• cтарые логи удаляются в кроне

logrotate - говно, не надо им пользоваться

Обоснуй.

man logrotate

Даже если раз в час, то посчитай сколько времени понадобится тебе для достижения 100000

Минут 10-15, я это гарантирую.

В момент упаковки логов создает неравномерную нагрузку на систему. Кривая схема перемиенования фалов для циркулярного логирования. Бедные возможности по заданию условий какие файлы упаковать.

логи пиши через syslog, дальше забота админа как и куда они будут складываться, архивироваться, удалятся. А то понастроят своих велосипедов, потом иди поддерживай этот зоопарк.

понастроят своих велосипедов, потом иди поддерживай этот зоопарк.

+1 (хотя я ни разу не админ).

Один файл будет создаваться каждые 9 мс? You are doing it wrong

Значит немного преувеличил, 4к за 2 минуты выходит примерно.

4к за 2 минуты выходит примерно.

Кажды 30мс новый файл? Странные логи.

tags: [рукожопие]

☺

Ну серьезно, скажи нам зачем так уж много файлов

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

А, пф. Так они же в разных папках должны лежать

Какая-то жесть...

У нас сейчас в продакшене пишется в среднем где-то 4500 строк лога в секунду. syslog просто сдохнет скорее всего на таком объеме. У нас это нормальный режим эксплуатации, можно уровень логирования еще и поднять.

Вы тестировали сколько сообщений в секунду может переварить syslog и как это сказывается на производительности системы?

Какая-то жесть...

В чём заключаеться жесть, если у тебя практически то же самое?

Наверное, у него файлы не каждые 30мс создаются.

lttng?

Да. Вас какой порядок чисел интересует?

В данную минуту squid пишет свой лог и параллельно в сислог: 600 строк (сообщений) в секунду.

 load average: 0.12, 0.16, 0.11
Tasks: 403 total,   1 running, 402 sleeping,   0 stopped,   0 zombie
Cpu0  :  1.3%us,  1.0%sy,  0.0%ni, 96.0%id,  0.0%wa,  0.0%hi,  1.7%si,  0.0%st
<SKIP>
Cpu7  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8175136k total,  8124952k used,    50184k free,    47412k buffers
Swap: 10223608k total,   237824k used,  9985784k free,  6869984k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
24433 squid     15   0  648m 595m 2476 S  3.3  7.5   1212:17 squid

/proc/cpuinfo: model name      : Intel(R) Xeon(R) CPU           E5430  @ 2.66GHz



Лог однодневный (с 00:00 -- сейчас ~19:00)

$ ls -lh /var/log/squid/access.log
-rw-r----- 1 squid squid 4.4G Oct  7 19:00 /var/log/squid/access.log

$ wc -l /var/log/squid/access.log
30985669 /var/log/squid/access.log

В данную минуту squid пишет свой лог и параллельно в сислог: 600 строк (сообщений) в секунду.

Маловато будет... Раз бы в 20 побольше.

У нас лог из разных процессов сначала пишется в циркулярный буффер в разделяемой памяти. Есть отдельная утилита (ncurses), которая позволяет просматривать содержимое этого буффера с фильтрацией по уровню, источнику, с поиском, раскраской цветами итд. Есть аналог tail -f также с фильтрацией, который можно напустить на этот буфер. Есть сервис, который пишет содержимое буфера на диск, сразу его запаковывая и ротируя. Жрет он при этом меньше процента CPU. В общем этот сервис можно остановить на некоторе время и запустить снова. Если буффер не переполнился, то ничего не теряется.

А что имеется в виду под ратацией? Я так понимаю, что она осуществляется все время (равномерно), раз к logrotate была претензия, что он не равномерно нагружает сервер.

А что будет с логами, если сервис пишущий содержимое буфера на диск по какой-нибудь пречине упадет в процессе упаковки?

А зачем при такой нагрузке access.log заполнять? Сделай его FIFO, да читай на лету программкой, которая трафик считает, сохраняя более сжатые данные (только то, что нужно, а не полную историю).

А у нас за теже 19 часов 3.8 гига ЗАПАКОВАННЫХ логов. Или 34 гига распакованных. Плюс у нас по логам в онлайне рисуются графики количества разных сообщений по уровням.

так сервер и не нагружен вовсе. я же не зря его загрузку показал

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