The Journal: жизнь после syslog

Зачем?

Затем, что если система не будет достаточно гибкой, она моментально устареет.

системными логами

т.е. ты предлагаешь держать два логгера: для «системы» (что бы это ни значило в мире линукса) и для «пользовательского софта»? Ну, удачи в продавливании своего велосипеда пионерам.

>тащемта бывает и так. а если дамп маленький, то зачем? Особливо если писать некуда - корень только на чтение.

Если дамп маленький его можно и в текстовом виде скинуть в лог. И как может помочь журнал если корень не доступен на запись, а все виртуальные фс обнулятся без питания?

да вроде нет.

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

ну откуда на рутере иксы и место под опенофис? Стало быть текстовые конфиги отстой...

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

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

Значит вам либо это не нужно вообще. Либо вы такой «специалист» раз для вас собрание логов занимает столько времени и настолько нетривиально. Другие почему-то этим пользуются.

по дефолту логи сворачиваются раз в сутки.

Какая разница сколько раз сворачиваются логи когда текущий инструментарий может обеспечить к ним прозрачный доступ?

журнал частично вытесняет оба варианта. «И это хорошо!» (С)

О да давайте заменим два отлично работающих со своими задачами инструмента одним трудно-поддерживаемым комбайном. И получим одну точку сбоя. Отличный выход.

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

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

...разруха не в клозетах, а в головах. (c) Филипп Филиппович

Наверное то, что это никому кроме редхата и Птоттернига не нужно не?

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

А зачем изживать удобную легкоподдерживаемую платформу? Таким чудом конечно надо пользоваться. Анализатор логов в бд написать куда проще, чем парсер текстовых файлов. Было бы в syslog обязательное поле «важность» - сколько головной боли снялось бы с разработчиков систем мониторинга.

Мне всю остальную систему без интернета надо. А не дожидаться по 10 минут пока эта парочка осознает что интернета нет и не будет.

Очень удобно использовать grep/sed/awk чтобы проверить наличие бинарного файла демона, а также проверить запущен ли он. Именно это меня и выбешивает в текущем init-е - базовые вещи start-stop демона написать _надежно_ очень не тривиально. Надеюсь systemd исправил эту проблему. Впрочем я уже пополнил зоопарк скриптов еще одним скриптом, который создает сессии screen для разных программ и позволяет запускать/останавливать их.

Может расскажешь, как количество звёздочек связано со стабильностью?

Я думаю если таблица меняется - создается новый UUID. Схему может нести в себе программа которая пишет в лог - это было бы разумно в качестве этакой машиночитаемой документации.

>Двумерный массив это частный случай одномерного. И какой от этого выигрыш кроме накладных расходов на манипуляции при записи и обсчете всей этой кортэжной ерунды?

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

Затем, что если система не будет достаточно гибкой, она моментально устареет.

Устареет - это как текстовые файлы? Давайте писать журнал в виде свободного сочинения MS Word! Столько гибкости получим.

Открываю глаза на правду: это не та гибкость, которая нужна в журнале. А вот возможность вставлять бинарные данные (из статьи) - это та гибкость, у текстовых файлов её нет.

т.е. ты предлагаешь держать два логгера: для «системы» (что бы это ни значило в мире линукса) и для «пользовательского софта»

Приплыли! Это какой «пользовательский софт» у нас сислог-то использует? Журнал один, не надо цепляться к словам. Он потому и системный, что в него не принято класть данные несущественных пользовательских программ.

что бы это ни значило в мире линукса

Я уже догадался, что ты совсем не в курсе, о чём говоришь, но зачем так явно палиться?

примерно 50k строк vs 8k

хорошая идея - сравнивать количество строк на C и на Bash. дна из задачи systemd - не тратить время на бесконечные fork->exec->парсинг скрипта

Линукс был единственной свободной ОС, и ему потребовалось 20 лет чтобы перейти от версии 0.1 к более менее пригодной. Думаешь с хурдом получится быстрее?

>Я думаю если таблица меняется - создается новый UUID.

круто. А Леннарт полагал. что uuid создается на событие. То есть как было событие, например, «login» в мейнфреймах 30 лет назад, так оно и осталось. А полей пишется разное количество.

Более того, тот же тип может использовать не только демон входа в систему, но и демон ftp, ssh и т.д. У них ведь тоже есть событие «логин». При этом набор полей у них разный.

И на сладкое. Одна и таже программа может писать разное количество полей в одно и тоже событие при разных уровнях loglevel.

Схему может нести в себе программа которая пишет в лог - это было бы разумно в качестве этакой машиночитаемой документации.

Тогда уж пусть лучше regexp для разбора своей строки сислога несет.

ЗЫ

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

Ну как можно представить себе, что все программы, которые пишут в лог, вдруг начнут тащить в себе схемы таблиц для хранения своих логов?! И где-то их регистрировать и все это будет работать?! Нет слов...

>Приплыли! Это какой «пользовательский софт» у нас сислог-то использует?

не знаю. о чем вы спорили, но почти во всех своих прожках пишу в сислог. Не всегда же stderr подключен...

>Если дамп маленький его можно и в текстовом виде скинуть в лог. И как может помочь журнал если корень не доступен на запись, а все виртуальные фс обнулятся без питания?

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

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

я политкорректно говорю «нет». журналы сливать не надо. Они сливаются библиотекой на лету.

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

да вроде как они меньше, чем полновесный сислог.

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

да вроде как все наоборот. В логах тривиальная дедупликация (нормализация в терминах sql) дает хорошее сжатие без гемора на распаковку.

Другие почему-то этим пользуются.

ерунда. все дело в цене вопроса. Если надо выцепить логи космической станции, которая стоит 6 миллиардов и сейчас свалится на землю, да, будем через netcat снимать хоть какие текстовые или бинарные дампы и грепать, грепать и грепать.

А если вопрос от пользователя, почему у меня вчера инета не было? То как думаешь, стоит ответ на него нескольких часов отупляющей работы специалиста?

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

Какая разница сколько раз сворачиваются логи когда текущий инструментарий может обеспечить к ним прозрачный доступ?

не может. zcat существенно замедляет процесс, превращая его в оффлайновый.

О да давайте заменим два отлично работающих со своими задачами инструмента одним трудно-поддерживаемым комбайном. И получим одну точку сбоя. Отличный выход.

Есть только один неплохой инструмент. сислог. Хорошей свободной, надежной системы для анализа логов нет. Опять-таки, отсылаю васк оригиналу или переводу статьи. Там перечислены основные причины и в их числе необходимость использовать закрытые анализаторы, ибо свободных кот наплакал.

Это поттерлог то удобный и лёгкий? Ну та то-то администраторы радуются написанию запросов в бд вместо регекспов. И а администраторы баз данных как должности не существует. Ведь так легко составлять запросы. Откуда программа может знать о важности того или иного события? Важность событий оценивается людьми. А они могут ошибаться. И потом приходится отлавливать иглу в стоге важнейших событий. Ой как сложно то разработчикам всех этих десятков систем мониторинга на каждый чих. В поте лица плодят они велосипеды. А вот с изделием Поттеринга велосипедистость велосипедов выйдет на новый недосягаемый до селе уровень.

Устареет - это как текстовые файлы?

А текстовые файлы устарели? Ещё пару фраз и я пойму какая область твоего мозга поражена (ц) хвостострел.

Давайте писать журнал в виде свободного сочинения MS Word!

MS Word --- это излишнее.

возможность вставлять бинарные данные (из статьи) - это та гибкость, у текстовых файлов её нет.

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

А откуда они беруться? Память то плоская, а не двумерная. Вы проигнорировали моё высказывание о бОльших накладных расходах в рантайме.

По-видимому, только и останется, что сидеть на слаке или собирать LFS.

>А вот возможность вставлять бинарные данные (из статьи) - это та гибкость, у текстовых файлов её нет.

Это в какой школе на уроке информатики не учат записывать двоичные данные в текстовом формате в тетрадку? Надо будет накатать петицию в департамент образования.

Необходимость перезагружать систему каждые пять минут нужна не всем, и более того выключение компьютера навязанная привычка. А вот отлаживаемость и гибкость этих fork->exec->парсинг гораздо выше ваших хваленых systemd ибо без половины скриптов можно будет худо бедно систему запустить, а без systemd нет.

>И а администраторы баз данных как должности не существует. Ведь так легко составлять запросы

это только в вашей реальности администраторы БД пишут запросы. В остальных это делают программисты в своих программах, которые работают с БД.

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

Нагромождение лишних абстракций никому не поможет кроме Леннарата и кучки его оголтелых приверженцев революций ради революций. Как лишнего ключа на событие login облегчит поиск в базе с миллионами логинов в разные сервисы? Всё равно в конечном итоге придётся искать в редких параметрах идентифицирующих какое-то уникальное свойство или пришествие. А то и в безразмерных полях этого нового журнала. То есть это замена шила на мыло. Выгода от которого будет сиюминутной.

«Остановка машины - навязанная привычка»

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

И для этого жизненно необходим именно jornald. Ну-ну.

я политкорректно говорю «нет». журналы сливать не надо. Они сливаются библиотекой на лету.

А стоимость этого слития пропорциональна количеству источников.

да вроде как они меньше, чем полновесный сислог.

В статье говориться что будет и сислог и ещё журнальный демон. Да ещё и библиотеки вы не находите, что это перебор? К тому же самодельный сислог можно на коленке написать. А заменить поделие Поттеринга без стабильного описания формата не получится.

да вроде как все наоборот. В логах тривиальная дедупликация (нормализация в терминах sql) дает хорошее сжатие без гемора на распаковку.

Гемор на распаковку только в ваших умозрительных представлениях. Примеры уже были читайте тред. Он нисколько не сопоставим с геомором по обслуживанию БД и накладных расходах в рантайме.

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

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

не может. zcat существенно замедляет процесс, превращая его в оффлайновый.

Опять двадцать пять. Если вам нужен рантайм доступ к логам, а не оффлайн то используйте бэкэнд и варпперы для наполнения БД расщепления заданий анализа на кластеры и прочее. Зачем ломать то что уже работает гибко дешево и эффективно? Кроме как для того чтобы срубить по быстрому бабла для радхата и себя? А после нас хоть потоп.

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

Читал и перевод и оригинал статьи не впечатлён нисколько. Все эти аргументы уже видел не раз применительно к разным ПО и разным системам. И как правило после победы Поттеризма лучше не становилось. И хорошей свободной надёжной системы для анализа логов и не будет даже после создания журнала. Потому что энтерпрайз будет платить энтерпрайзу, а не студентам. Например в лице редхата и его журнала с какой нибудь платной энтерпрайзной надстройкой. Потому что бизнесу важен системный подход и возможность с кого-то спросить. А те кто так рьяно отставили поттерлог продолжат кусать какту^w локти в надежде быть осчастливленными.

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

В мире найдётся рынок для сбыта хотя-бы трёх компьютеров. Мы не сомневаемся в этом. (c) Какой-то шишка их IBM

Вот у меня dhcp пишет в лог о каждом выданном ip адресе. Это событие не важное. А вот если вдруг он обнаружит ошибку, при которой продолжение работы станет невозможным - это событие важное. Тут все просто и однозначно. Может быть ты предложишь идеальную систему мониторинга?

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

>И для этого жизненно необходим именно jornald. Ну-ну.

учитывая, что сислог в этот момент еще не стартует, /var/log отсутствует, да, нужен или журнал или его аналог.

А стоимость этого слития пропорциональна количеству источников.

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

В статье говориться что будет и сислог и ещё журнальный демон. Да ещё и библиотеки вы не находите, что это перебор?

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

А так, пока журнал не взлетит, сислог никто не убъет. Но если журнал отработает годик на базе пользователей федоры и докажет свою состоятельность, будут дописаны гейт сетевого сислога в журнал, то от нативного сислога можно будет отказаться. Как говорил Энштейн, ASAP,но не раньше.

К тому же самодельный сислог можно на коленке написать.

Сколько можно писать на коленке то, что уже 30 лет как написано?!

А заменить поделие Поттеринга без стабильного описания формата не получится.

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

Гемор на распаковку только в ваших умозрительных представлениях. Примеры уже были читайте тред. Он нисколько не сопоставим с геомором по обслуживанию БД и накладных расходах в рантайме.

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

Вот и выясняется, что в обслуживаемой системе просто не решена задача выявления однотипных проблем.

а в какой линукс-коробке она решена?

И потом, проблема как раз в том, что в проблемы не однотипные. Сегодня не работает одно, а завтра другое. И зачастую узнаешь ты об этом через неделю после инцидента.

Опять двадцать пять. Если вам нужен рантайм доступ к логам, а не оффлайн то используйте бэкэнд и варпперы для наполнения БД расщепления заданий анализа на кластеры и прочее.

и 26 раз ответ - в сисллоге нет всей необходимой информации, в сислоге часть информации подделана, и стоимость поддержания системы расщепления строк сислога в поля БД крайне высока.

Поэтому сислог в линукс-системах есть, а вот надежных систем анализа нет.

Зачем ломать то что уже работает гибко дешево и эффективно?

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

И как правило после победы Поттеризма лучше не становилось.

ну, тут ничего не скажешь. Поттеринг и во мне постоянно будит гомофоба...

И хорошей свободной надёжной системы для анализа логов и не будет даже после создания журнала.

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

А инструмент отображения срезов, надежный парсер будет сразу в коробке.

Потому что энтерпрайз будет платить энтерпрайзу, а не студентам.

я вас умоляю. студенты - единственная реальная движущая сила энтерпрайза.

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

+1

С этим постом совершенно и полностью согласен.

> хорошая идея - сравнивать количество строк на C и на Bash.

Я вообще-то строки на C сравнил. 8k - приблизительный объем кода sysvinit (не только собственно init в 1000 строк, но и кучи утилит). Сравните с 90k (сейчас!) у systemd. И тварь эта только пухнуть собирается.

Даже если добавить к 8k еще и «строки на bash» (вообще-то на sh ;)) из /etc/init.d/ - увы, все равно по 100 тысяч строк не наберется.

дна из задачи systemd - не тратить время на бесконечные fork->exec->парсинг скрипта

Ну, стало быть:
1) Он с этой задачей не справился (см. ExecStartPre/Post - они нужны для мало-мальски нетривиального сервиса)
2) Задача глупа в общем случае. Это оптимизация, интересная в некоторых ситуациях. Большинство разумных людей не считают _это_ существенным недостатком SysV init.

>к четвёртому ноября

охтыж вместоклавымышь! Провославно-то как!

//даже от тебя такого не ожидал.

>> с systemd такой возможности нет.

пересобрать systemd? убрать ненужные сервисы (или как они это называют)?

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

добиться безошибочной работы столь сложно устроенной системы исключительно трудно

а что так такого сложного, что сложнее ядра?

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

проверенные временем принципы проектирования *nix систем

вопрос на засыпку: отсутствие серьёзных систем безопасности мы тоже должны бережно хранить?

ты хочешь сказать, что эти принципы мешают безопасности ?

Мне всю остальную систему без интернета надо. А не дожидаться по 10 минут пока эта парочка осознает что интернета нет и не будет.

Ну настройте систему нормально. Init-то причем? Проверил: выдернул шнурок, перегрузился. Бинд был несчастлив, но система это как-то пережила без драматизму. Debian. ЧЯДНТ?

Очень удобно использовать grep/sed/awk чтобы проверить наличие бинарного файла демона, а также проверить запущен ли он.

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

Именно это меня и выбешивает в текущем init-е - базовые вещи start-stop демона написать _надежно_ очень не тривиально.

-->8--
        log_daemon_msg «Starting OpenBSD Secure Shell server» «sshd»
        if start-stop-daemon --start --quiet --oknodo --pidfile /var/run/sshd.pid --exec /usr/sbin/sshd — $SSHD_OPTS; then
            log_end_msg 0
        else
            log_end_msg 1
        fi
...
        log_daemon_msg «Stopping OpenBSD Secure Shell server» «sshd»
        if start-stop-daemon --stop --quiet --oknodo --pidfile /var/run/sshd.pid; then
            log_end_msg 0
        else
            log_end_msg 1
        fi
-->8--

Что тут нетривиального?

угу, дважды.

А если процесс умирает уже после старта?

А если пид не создает?

> А если процесс умирает уже после старта?

А как systemd поможет от этого?

А если пид не создает?

Помним что мешает некоторым танцорам?

- Отправить очередного песателя делать что-то более полезное. Лес валить, например...

а с гентой и арчем что не так?

Провославно-то как!

Расово. Расово и православно.

Да всё бы ничего - ещё один инструмент.
И ему есть применение. На пример - реалтаймовая обработка протоколов работы...
Вот только зачем столько пафоса и использование вентилятора в качестве транспорта плодов обработки пищи?

Ведь мы же не узкомонетизированную систему обсуждаем? Тут всегда можно найти приемлемый набор инструментов.

Беда будет у РедХэта, если они ограничат выбор системы протоколирования. Но это (я надеюсь) будет проблемой только тех, кто намертво привязан к RadHat.

Лично мне plaintext в протоколах представляется гораздо более рациональным вариантом.

А текстовые файлы устарели?

А по ссылке в посте сходить?

MS Word --- это излишнее

А почему? На грамотном английском языке, в виде текста.

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

Пук в лужу. Base64? Base85? Escape? А неламера не смущает, что при этом размер логов неимоверно раздуется? То, что текстовое представление бинарных данных ощутимо больше, чем бинарное? То, что анализировать такие данные будет куда сложнее? А то, что их читать будет невозможно, если туда, например, полетит хотя бы килобайт бинарных данных, зато 1000 раз?

Не стоит после прочтения пары статей из википедии обзывать программистов ламерами=) Ты слишком многие аспекты пока не видишь.

Это в какой школе на уроке информатики не учат записывать двоичные данные в текстовом формате в тетрадку

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

без половины скриптов можно будет худо бедно систему запустить, а без systemd нет

Опять сравнил! Systemd надо сравнивать с init, без него ты тоже далеко не уйдёшь.

ты хочешь сказать, что эти принципы мешают безопасности ?

я хочу сказать, что если бы все так считали, мы бы до сих пор сидели с дефолтной моделью безопасности (rwxr-xr-x).

А по ссылке в посте сходить?

Досужие фантазии поттеринга не впечатлили.

А почему?

А потому, что с вордовым форматом не работают стандартные юниксовые утилиты. Кроме того, он избыточен.

Base64? Base85? Escape?

Это хорошо, что ты узнал о таких замечательных вещах. Есть польза от лоровских срачиков.

размер логов неимоверно раздуется?

С чего бы это? Накладные расходы на представление весьма умеренные, количество бинарных данных само по себе ничтожно ибо мало где они нужны. Так откуда у нас неимоверно раздутые логи возникнут?

Не стоит после прочтения пары статей из википедии обзывать программистов ламерами=) Ты слишком многие аспекты пока не видишь.

Продолжай. Тебе осталось пол шажочка до сакраментального «мне вас жаль».

Это не было ответом, а было лишь уходом в сторону

>>А то, что их читать будет невозможно, если туда, например, полетит хотя бы килобайт бинарных данных, зато 1000 раз?

это откуда такое может прилететь, не приведешь пример, погромист? Ж)
дампам не место в логере. в нормальных системах они просто связаны uuid.
и да, не стоит после прочтения пары книг «программируем за 24 часа» обзывать себя программистом=) Ты слишком многие аспекты пока не видишь. (с)

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

Досужие фантазии поттеринга не впечатлили.

Не осилил? Бывает, попробуй ещё раз через полгодика.

Накладные расходы на представление весьма умеренные

Ага, минимум треть с потерей возможности непосредственного анализа (ты Base85 погугли для начала, чтобы не позориться).

количество бинарных данных само по себе ничтожно ибо мало где они нужны

640 килобайт хватит всем, да-да.

Так откуда у нас неимоверно раздутые логи возникнут?

Ну хорошо, ты не знаешь, где могут быть нужны бинарные данные. Предположим, что они всегда небольшие (искусственное допущение из-за фанатиков текстовых файлов). Вот только сколько раз они повторятся?