Какой либой лучше паковать логи?

Раз уж всё равно собрался паковать, пиши в двоичном виде сразу.

Ну или в БД.

snappy, lzo, lz4. Тут есть небольшое сравнение по скорости

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

Админы не поймут бинарных логов. Им по ним надо грепать

Сделать десериализатор не проблема, можно даже из него кормить вывод грепу для простоты пользования админами.

А зачем их вообще паковать?

Админы не поймут бинарных логов.

Дык распаковщик сделать.

200 тысяч инсертов в секнуду это какая должна быть база? И сколько она будет занимать?

Меньше, чем логи. По сути она бинарно упакует твои записи. Время - 4байта, числа 2/4 байта, IP - 4 байта ну и т.д.

Соответственно структурку подходящую — и 200к не проблема.

Меньше, чем логи. По сути она бинарно упакует твои записи.

И насоздаёт кучу «паразитических» структур вроде индексов. Для лога ничего лучше лога по объёму быть не может, в GP СУБД он будет занимать ошутимо больше.

Диски на серверах не резиновые. Разгружается дисковая подсистема

Время не 4 байта, т.к. оно с точностью до ms. Также записи бывают совсем разные. То что в примерее они похожи, это случайность. Т.е. структура таблицы будет типа

time timestamp;
process_name varchar(64);
pid shortint;
log_level char;
message varchar(100000);

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

И насоздаёт кучу «паразитических» структур вроде индексов.

Барабашка насоздаёт?

Но они все равно эффективно пакуются, т.к. повторяются в каждой строке

Ровно это же самое можно сделать и своими руками если выносить общую дату до секунды - десятка секунд в общий блок, а в самих записях оставлять ms оффсет.

Барабашка насоздаёт?

Зачем тупишь?

Имя процесса можно вынести в отдельную табличку, партицировать по дате (как раз хорошо для логов) и хранить только время. Всякие EVENT_USAGE_REPORT сделать enum и хранить в отдельных полях. Ну и с 100000 ты загнул. Значит эти твои админы легко читают записи логов такой длины? 4 экрана.

Тупишь пока ты

Им по ним надо грепать.

200k строк в секунду

OMFG. Сколько же времени займет grep? Уж лучше писать логи в какой-то NOSQL, или пересмотреть логику логгирования.

Еще раз - записи бывают СОВСЕМ разного формата. В общем случае свести их к одному бинарному формату нельзя.

Это пиковая нагрузка. В обычном режиме может быть в порядки меньше.

Это все отлично делает упаковщик

Пакуем при помощи zlib. В общем, более-менее ничего, но сейчас упаковка логов занимает больше ЦПУ, чем работа приложения.
Может есть другие алгоритмы упаковки, более заточенные на логи?

Разве что cat > /dev/null.

В общем случае свести их к одному бинарному формату нельзя.

В общем случае они сводятся к бинарному формату упаковкой.

Да я уже и не про собственный упаковщик, а про БД.

Еще раз - записи бывают СОВСЕМ разного формата.

Я же не предлагаю вообще ВСЁ разбивать на элементы. Просто из приведённых строк очевидно, что большая часть элементарно разбивается. А маленький хвостик, так уж и быть, можно оставить.

Может посмотреть на HDF5?

А работать на чтение можно и из питона, есть библиотека h5py, причем с поддержкой параллельности через mpi4py.

Только для простейшего анализа придётся распаковывать весь 100500 гиговый файл.

Ротация файлов существует не зря. Периодически открывается новый файл.

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

Его тоже придётся весь распаковывать.

Какой средний объём сейчас за период ротации?

Ротируем после каждого гига незапакованных данных. Архив получается около 110 мб

Может есть другие алгоритмы упаковки, более заточенные на логи?

Не уверен, что такое вообще есть, но есть более быстрые и не такие жрущие алгоритмы, например https://code.google.com/p/snappy/

200k строк в секунду.

То есть 50 мбайт в секунду.

Вы там что каждый пакетик записываете в логи? :)

Ротируем после каждого гига незапакованных данных. Архив получается около 110 мб

Админы не поймут бинарных логов. Им по ним надо грепать

То есть админы распаковывают 1 архив в tmpfs и грепают? :)

Ротируем после каждого гига незапакованных данных. Архив получается около 110 мб

ИМХО как ни пляши, а от необходимых операций не убежишь. Цикл Данные -> упаковка -> хранение -> извлечение будет всегда. НО, в случае БД, эти операции размазаны по каждой записи. Плюс выборка предшествует форматированию результата.

Т.е. ответ на вопрос «к каким процессам подключались с некоторого IP» будет происходить по разному. В твоём случае данные будут преобразованы в текстовый вид, а затем греп прочешет гиг данных для одного из самых неэффективных строковых сравнений.

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

Так же большим плюсом БД является доступность нескольким пользователям одновременно.

в простейшем случае будет делаться так

zgrep some_ip /var/log/xxx/2013-01-*

есть zgrep

Еще раз - база данных, которая может ставлять с такой скоростью будет жрать место на диске, ЦПУ, а главное время админа куа быстрее чем запакованный лог.

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

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

Тот же mysql позволяет дропать отдельные партиции (они по сути отдельные таблицы).

Попробуй теперь сделай описанную табличку и повставляй туда записи с указанной скоростью. Сколько памяти это отнимет? Сколько ЦПУ. А потом попробуй сделать полнотекстовый поиск по тексту сообщения и сравни производительность с поиском по файлу.

Я и так знаю, что нормально будет.

сделать полнотекстовый поиск по тексту сообщения и сравни производительность с поиском по файлу.

Очевидно меньше, т.к. сообщение - малая часть файла.

... А потом попробуй сделать полнотекстовый поиск по тексту сообщения и сравни производительность с поиском по файлу.

+ повставлять и поудалять несколько раз кучу записей и посчитать после отношение размера БД на диске к сырым данным.

Может есть другие алгоритмы упаковки, более заточенные на логи?

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

но сейчас упаковка логов занимает больше ЦПУ

Это нормально, для такой детализации, если напрягает шлите поток логов на другую машину и там их агрегируйте и жмите.

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

пересылка через shm както не але, если пакующий процесс тормознет изза общего высокого la (который он частично и создает), то можно банально из свободной памяти выбежать, а там и oom подключится, и начнет ложить систему.

http://ceur-ws.org/Vol-325/paper06.pdf + lzo или snappy

а для админов надо будет писать распаковщик

Сделать десериализатор не проблема, можно даже из него кормить вывод грепу для простоты пользования админами.

Отличная мысль сделать в довесок к программе еще и десер и пусть хоть обгрепаются :)

А потом окажетсья что этот десереалитор надо делать под винды, солярис и мак. Люди ведь захотят посмотреть логи

logrotate уже упоминали? Если нет, то вот пусть он и пакует. Ненадо решать проблемы, там, где их нет.

Логротате в жопу! 1) Криво ротатит. 2) Мне вовсе ни к чему периодически возникающие пиковые нагрузки на сервере. 3) Он точно также использует упаковщик для паковки. И его можно заменять

Ню-ню, удачи со своим кривым велосипедом. ;)

PS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652600 спасёт отца русской демократии.

Наш велосипед не кривой. У нас как раз работает с пониженным приоритетом. Итого пусть есть 1 гиг логов. При использовании логротате, надо сначал записать 1 гиг на диск, потом прочитать при упаковке и записать снова ~100 мб. наше решение экономит запись и чтение этого гигабайта.

Что такое гиг логов в наше время? Не смеши мои тапочки.¹

Придумал себе проблему и гордо её решаешь. Ню-ню. Подсказку я уже дал, тебе виднее.

1) А настроить то можно как угодно — хоть по дням, хоть по мегабайтам и вид комрессии любой выбрать.

. наше решение экономит запись и чтение этого гигабайта.

Но ведь это неправда! Закон сохранения информации (который я только что придумал и Шеннон тут не при чём) гласит: если речь не о чёрной дыре и прочих сингулярностях, то затраты энергии на изменение и сохранение информации непропорционально велики её рациональному использованию!

sistemd

Вы вопрос читать умеете? Там где-то написано о том, что я жду KO, который бы мне рассказал о logrotate?

можнт обычный zlib?

Им уже пользуемся. Думал есть спецалгоритмы заточенные именно на текстовые файлы или даже логи. Буду смотреть в сторону ppmvc