LINUX.ORG.RU

Circular logs


0

1

Привет.
Покритикуйте механизм.
Логи пишутся в файлы вида:
- dump_log_00001.txt
- dump_log_00002.txt
...

Хочу ввести механизм круговых логов, чтобы избежать заполнения всего места на диске. Допустим пишется 10000 файлов, затем счётчик сбрасывается в 1 и пишет дальше. По завершении приложения выводить StartMarker.txt с номером «первого» файла.
Нормальная практика?

★★★★★

Ответ на: комментарий от former_anonymous

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

UVV ★★★★★
() автор топика
Ответ на: комментарий от vertexua

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

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

UVV ★★★★★
() автор топика

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

Dark_SavanT ★★★★★
()
Ответ на: комментарий от UVV

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

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

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

MKuznetsov ★★★★★
()

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

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

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

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от vertexua

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

UVV ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

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

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

UVV ★★★★★
() автор топика

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

Anon
()
Ответ на: комментарий от UVV

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от UVV

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

Вот идея

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
vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от Anon

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

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

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

UVV ★★★★★
() автор топика
Ответ на: комментарий от Anon

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

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

UVV ★★★★★
() автор топика
Ответ на: комментарий от vertexua

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

UVV ★★★★★
() автор топика
Ответ на: комментарий от UVV

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

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

Anon
()
Ответ на: комментарий от UVV

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

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

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

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

UVV ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

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

vromanov ★★
()

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

sdio ★★★★★
()
Ответ на: комментарий от sdio

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от vertexua

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

UVV ★★★★★
() автор топика
Ответ на: комментарий от UVV

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

vertexua ★★★★★
()
Ответ на: комментарий от UVV

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

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

vromanov ★★
()
Ответ на: комментарий от sdio

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

vromanov ★★
()
Ответ на: комментарий от vromanov

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

В данную минуту 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

sdio ★★★★★
()
Последнее исправление: sdio (всего исправлений: 1)
Ответ на: комментарий от sdio

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

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

UVV ★★★★★
() автор топика
Ответ на: комментарий от UVV

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

vromanov ★★
()
Ответ на: комментарий от vromanov

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

anonymous
()
Ответ на: комментарий от vromanov

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

anonymous
()
Ответ на: комментарий от sdio

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

Anon
()
Ответ на: комментарий от sdio

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

vromanov ★★
()
Ответ на: комментарий от anonymous

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

vromanov ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.