LINUX.ORG.RU

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

 , ,


1

2

В своей новой статье Леннарт Поттеринг (Lennart Poettering), известный разработкой звукового сервера PulseAudio и системы загрузки systemd, объяснил, чем его не устраивает syslog, и предложил свою универсальную реализацию системного журнала в Linux.

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

Поскольку данная разработка Леннарта войдёт в Fedora 17 и далее, скорее всего, разойдётся по всем дистрибутивам, я взял на себя труд перевести и предложить вашему вниманию эту статью.

>>> Перевод статьи

★★★★★

Проверено: timur_dav ()
Последнее исправление: JB (всего исправлений: 2)

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

>> Ничего подобного. В Xorg напихали всякой херни (с подачки красношапочников или ими самими): DBus, HAL (теперь выпиливают), udev,

И благодаря этому в большинстве систем xorg.conf пуст. В нем по дефолту больше нет необходимости.

ВО!

Значит для достижения OS-ЗАВИСИМОЙ возможности запуска без файла конфигурации к стройной и OS-НЕЗАВИСИМОЙ X-Windows ПРИБИЛИ гвоздями монструозный (как, впрочем, и все гномоподелия последнего десятилетия, наверное) D-Bus и кривущий наколенный HAL???

Раньше были FAQ по генерации файла конфигурации. Теперь ВДВОЕ, наверное, большии количество FAQ по обходу кривоты HAL/D-Bus/udev.

А не проще было вызов автогенерилки конфига в случае его отсутствия в старт-скрипт внести???

Если твое понимание нужного не совпадает с пониманием девелоперов конкретного дистра...

1) D-Bus и HAL прибиты к Xorg. Мне искать дистриб, где их выдрали с корнем?

2) Теперь к гномосятине прибивают (уж поверьте, для нее, родимой!) systemd как раскрутку системы и менеджер сессий. А к нему - бинарные журналы. Причем и то, и другое пропитано непереносимым кодом так, что аж из монитора капает. Как следствие - ВСЕМ дистрибутам, которые хотят иметь у себя гном ПРИДЕТСЯ переходить именно на эту систему раскрутки/ведения журналов. Альтернатива - послать гном нафиг.

Смысл понятен?

sergv
()
Ответ на: комментарий от taker

>задача была - ввести новые возможности либо с сохранением текстового представления логов, либо с введением открытого бинарного формата (типа dbf).

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

естественно, никто никого никогда не заставит переписывать вызовы syslog(int,char*) на syslog(int,int,int,dword,char*), например. понятно, что нужна новая функция, типа syslog2(int,int,int,dword,char*,...). от этого - от написания новой функции - никуда не уйти, если нужна стандартизация набора данных логов. здесь вы меня просто неверно поняли.

так и сделали. Вот только вызовом syslog2 начнут пользоваться лет через 5-10.

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

а зачем, если уже есть старые текстовые логи? Какой в этом смысл?

об этом давайте подробнее. почему переменный? разве не дополненный?

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

и ещё раз - что мешает оставить хранилище текстовым?

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

Во вторых предполагается, что этот файл будет читать программа - просмотрщик журнала. Не важно, утилита journalctl, tailjournal или гуй wxjournalviewer. И эта программа будет передавать запросы в стиле sql. «Все записи» «последние N записи» «след N записей», «записи за тот-то день» «записи с таким-то типом», «записи от ткаого-то сервиса с полем таикм-то равным такому-то и полем другим не равном другому-то» и пр. и все это быстро и с живым обновлением.

Да, прекрасно подойдет xml. И к нему внешние индексы. Но это же будет адский ад...

что мешает индексы физически хранить не в том же файле, а в соседнем?

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

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

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

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

Так ведь тоже самое можно сказать и про бигтейбл для логов! Он действительно никому не нужен, кроме коллектора логов.

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

Как? я что-то пропустил.

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

А что делать? Когда-то точно также говорили об иксах. Мол, есть прозрачная сетевая консоль. Все быстро и легко. А тут пришли, все проги перепиши и все ради чего, чтобы кнопочки в графике рисовать?

это шоу-стопперы. никто не рад очередному шоу-стопперу.

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

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

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

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

>Значит для достижения OS-ЗАВИСИМОЙ возможности

возможность как раз ОС-независима. Все, что нужно, это портировать соответствующие инструменты ее реализации.

запуска без файла конфигурации к стройной и OS-НЕЗАВИСИМОЙ X-Windows ПРИБИЛИ гвоздями монструозный (как, впрочем, и все гномоподелия последнего десятилетия, наверное) D-Bus и кривущий наколенный HAL???

попробуй сделать лучше. кто против-то?

Раньше были FAQ по генерации файла конфигурации. Теперь ВДВОЕ, наверное, большии количество FAQ по обходу кривоты HAL/D-Bus/udev

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

1) D-Bus и HAL прибиты к Xorg. Мне искать дистриб, где их выдрали с корнем?

сред тех разрабов, которые считают, что это жизненно важно - выдрать с корнем. Или самому. Как вариант, старый дебьян.

Альтернатива - послать гном нафиг.

я так и сделал. Уже два года как...

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

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

Итак, дык чем плоха динамическая ГЕНЕРАЦИЯ конфига при запуске???

Вставили-бы xorg-os-config какой-нить с скрипт запуска. И на осестроителя возложили труд его написания.

Вопрос остается прежним - НАФУЯ гвоздями-то прибивать?

Альтернатива - послать гном нафиг.

я так и сделал. Уже два года как...

Не в смысле - из установки. В смысле - из дистрибутива. Как debian в сове время KDE выкорчевал.

sergv
()
Ответ на: комментарий от taker

>хорошо, что поттеринг пока оставил нам возможность не использовать его поделия :)

Собственно говоря, это главное его преимущество. Он не столько пишет софт, сколько гениально его внедряет.

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

O(logN), решения это только деление базы, создания разделов таблиц в любом случае телодвижений и проблем больше, нежели чем с файлами

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

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

> хорошо, что поттеринг пока оставил нам возможность не использовать его поделия :)

Ключевое слово «ПОКА» ? :-)

sergv
()
Ответ на: комментарий от ugoday

ибо (что вероятнее) будет менее выразительно, чем он

Это нам подходит, спасибо. Мне не нужны поэмы о любви в системном журнале

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

> Тупо выделение нового блока. Если выставить большой размер блоков...

О! Лучше с автоудвоением размера. И size_t как единица размера. Потом отладить на 64-х битной системе и удивляться, почему оно на 32-х битах лагает...

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

>Итак, дык чем плоха динамическая ГЕНЕРАЦИЯ конфига при запуске???

А в чем вопрос? Именно так и делается.

Вставили-бы xorg-os-config какой-нить с скрипт запуска. И на осестроителя возложили труд его написания.

Не пойдет.

если клавиатура/джойстик/планшет/монитор etc воткнуть в компьютер, когда иксы уже стартовали? Пролет или ребут компьютера?

Вопрос остается прежним - НАФУЯ гвоздями-то прибивать?

а как иначе?

Не в смысле - из установки. В смысле - из дистрибутива. Как debian в сове время KDE выкорчевал.

ну тоже вариант. где-то иксы вычеркивают, кто а где-то гном выкинут. Была бы мотивация. В чем проблема?

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

> если клавиатура/джойстик/планшет/монитор etc воткнуть в компьютер, когда иксы уже стартовали? Пролет или ребут компьютера?

syskeyboard, sysmouse, DPMI и т.п. Не?

Есть подозрение, что из-за перьев приделали, но могли и еще один интерфейс приделать. Не уневерсально-монструозный.

где-то иксы вычеркивают, кто а где-то гном выкинут. Была бы мотивация. В чем проблема?

Графику хоцца на десктопе. Форточки не хоцца (давно ими не пользуюсь, лет 15, наверное). А выбора, походу, не оставят... :-(

sergv
()
Ответ на: комментарий от AVL2

xml - это ни разу не текстовый, а только таким кажется.

anon8
()
Ответ на: комментарий от sergv

О! Лучше с автоудвоением размера. И size_t как единица размера. Потом отладить на 64-х битной системе и удивляться, почему оно на 32-х битах лагает...

Плюх!

Мне неловко говорить, но эти проблемы решены давно. Тебе LARGE_FILES что-нибудь говорит?

Divius ★★
()

Пусть использование journal будет опциональным, и все будут довольны.

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

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

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

Я отвечал на возможности повторного использования. И то и другое нужно только для старта системы, я предпочту systemd тому зоопарку глючных init.d скриптов, который есть сейчас. При недоступности интернета какой-нибудь bind или openvpn может задержать загрузку системы на 10 минут, что я считаю недопустимым.

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

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

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

farafonoff ★★
()
Ответ на: -k от mumpster

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

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

есть какая то программа для этого - module

module load ...
module use...
module avail...

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

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

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

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

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

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

> как то не вериться в допиливаемость GNU/Hurd

Теоретически оно должно быть намного более допиливаемо в силу своей модульной структуры. Другое дело, что до недавнего времени это было никому нафиг не нужно. Но поскольку монолитный линукс с каждым годом всё тяжелее и тяжелее, просыпается интерес к альтернативам - Minix3 и Hurd.

Не зря же выпускают Debian GNU/Hurd...

hobbit ★★★★★
()

Прочитал всё по диагонали. Понял только что:

  • О кросс-платформенности можно забыть, так как всё будет прибито к linux в видении красношапки (а если я хочу хранить и анализировать логи на винде или в какой qnx то ой)
  • О реализации анализаторов логов в железе например на микроконтроллерах тоже можно забыть (например прозрачный аппаратный watchdog)
  • Весь unix-way совместной работы фильтров, врапперов, пайпов и сокетов летит к чертям и подменяется куцым api. Что ломает совместимости со старым инструментарием и делает нетривиальной генерацию нового. (интересно Поттеринг вообще читал литературу по nix или осилил только спецификацию на си)
  • «Замыкание на вендоре» в виду неповторяемости инструментария из за закрытости/нестабильности конечного формата (чтение исходников сомнительный вариант)
  • Необходимость генерации специальных конвертеров в независимый от инструментария формат для длительного хранения логов или какой-то спецобработки ( генерация ещё одного костыля чтобы не потерять логи из за несовместимости версий чудного логгера или возможности обработки логов)
  • Никакой помехозащищенности, малейшие ошибки на диске или в памяти проявятся потерей базы логов
  • Затруднённость анализа человеком для нетривиальных случаев ( как это проявляется в «оптимизированных системах логирования» видно по винде) Буквально все перечисленные так называемые недостатки syslog реализуемы в рамках существующих принципов unix-way. Преимущества jornald надуманны и нужны только для пропихивания красношапки во все дыры. И меня удивляют защитники этого пути которые даже весомой аргументации так и не привели. Надеюсь я просто невнимательно прочитав не так понял истинного светоча мысли Поттеринга. Иначе страшно жить.
toon
()

Народ, а чего спорите то??!!!!!! Не нравится - сделайте свой как считаете нужным, в чем проблема то??

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

Проблема в том, что если ты не Потт^w сотрудник крупной манетизированной компании то твой syslog никому как правило не нужен.

toon
()
Ответ на: комментарий от qnikst

В том и дело, что поля кроме текста и даты опциональные. Схемы уже 100 раз проработаны - в любой нормальной СУБД хранятся строки таблиц разных размеров, многие оптимизируют разреженные таблицы.

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

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

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

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

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

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

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

Я так понял для каждого формата предлагается вводить свод UUID. Ничто не мешает создать по таблице для каждого UUID'a (самый тупой вариант, можно реализовать за пару дней)

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

Интерес не просыпается, а откапывается. Ему еще метров 5 копать.

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

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

>О кросс-платформенности можно забыть, так как всё будет прибито к linux в видении красношапки (а если я хочу хранить и анализировать логи на винде или в какой qnx то ой)

Не думаю что перенести библиотеку для работы с логами будет сложно для того, кто на самом деле хочет разбирать логи на венде (но зачем?)

Весь unix-way совместной работы фильтров, врапперов, пайпов и сокетов летит к чертям и подменяется куцым api. Что ломает совместимости со старым инструментарием и делает нетривиальной генерацию нового. (интересно Поттеринг вообще читал литературу по nix или осилил только спецификацию на си)

logviever --errors | grep ... | awk ... | sed ...

«Замыкание на вендоре» в виду неповторяемости инструментария из за закрытости/нестабильности конечного формата (чтение исходников сомнительный вариант)

Где написано, что формат не будет документирован (в итоге, после отладки)? В любом случае, остается возможность использовать библиотеку.

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

Надо подкинуть Поттерингу идею об избыточности

О реализации анализаторов логов в железе например на микроконтроллерах тоже можно забыть (например прозрачный аппаратный watchdog)

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

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

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

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

Одну такую платформу изжить никак не выходит, а вам ещё парочку подавай? И каким боком БД и легко поддерживаемость коррелируют?

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

я не компетентен в данном вопросе. Время рассудит

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