gzip

> логи сжатые gzip'ом.
сравнил опу с пальцем!
1) не все логи жмутся - есть выбор
2) всё равно они текстовые

> над чем леннарт думал месяцы...

Ты наивный. ^__^

эта либа должна работать всегда и везде сверхнадежно и сверхбыстро.

И «случайно» забываем о обратной совместимости.

И «случайно» забываем о том, что в поттеринговоской схеме гарнтирован лаг при централизованом ведении логов, которого у нынешнего syslog нет.

для системы реального времени с большим журналом на пару сотен хостов

... индексирование противопоказно. Основная задача ее - оперативно хватать события и сохранять их с минимальными лагами, что невозможно при ведении индексов, но естественным образом реализуется при использовании append-only формата (а.к.а text) :-)

Друзья, это же просто жесть какая-то. Чувствую, вакханалия Поттеринга кончится распадом сообщества Linux на два лагеря, во главе с Red Hat с одной стороны, и с Debian - с другой.

>Все рады - у поттеринга есть новая игрушка
Ты не понял, он не новую игрушку пилит. Просто у syslog'а обнаружился фатальный недостаток - у systemd с ним проблемы.

>так же есть проблемы с раздачей содержимого в зависимости от привилегий пользователя;

если честно, я не очень понял, чем новый журнал _принципиально_ лучше в этом плане.

Поттеринг предлагает делить журнал на файлы по одному на каждую службу и давать доступ к ним. Но по идее, rsyslog делает тоже самое. По крайней мере я веду отдельны логи на dhcp, бинд, самбу, фтп и т.д. средствами именно rsyslog

цели надо декларировать. если цель - создание единого программного интерфейса для взаимодействия с сервисами логгирования (где и решались бы задачи аутентификации источника, например), то так и надо делать. делать библиотеку, где объявлены функции работы с системным логом. API надо делать.

а вот уже за кулисами этого API можно уже и бинарные логи прикручивать, и текстовые, и XML и СУБД и что угодно.

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

И продвигает он именно API, которое реализует его сошка, «где объявлены функции работы с системным логом».

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

>>> Искренне интересуюсь, что сделать, чтобы pulseaudio заработал с наушниками в моём ноутбуке? Уже больше 2 лет висит баг в ланчпаде.

Давай чтоли ссылку для начала. Правда, заранее подозреваю, что дело таки в драйвере.

В данной статье он приоткрыл завесу, что же там, за этим апи прячется

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

> Классическая традиция Syslog не пригодна для поддержки журналирования ранней стадии загрузки или поздней стадии выключения

Почему? Очень интересно

Автор, молодец! Отличный перевод

Ни понял? Шо серьезно все в одном?

X11

> Х-терминалы никогда популярны «в народе» не были
это смотря в каком. который format c: делает - навернео не были.

не я реально не знаю над чем он думал и каковы его реальные мотивы

Ладно, ждем релиза и будем посмотреть

известный разработкой звукового сервера PulseAudio и системы загрузки systemd, объяснил, чем его не устраивает syslog

Не... таки заберите у него компьютер! :}

>И «случайно» забываем о обратной совместимости.

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

И «случайно» забываем о том, что в поттеринговоской схеме гарнтирован лаг при централизованом ведении логов, которого у нынешнего syslog нет.

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

Но здесь есть два объективных момента.

1) Вся та функциональность, которая была, никуда не девается. Все, кого устраивает лог сислога, могут и дальше использовать rsyslog без лагов.

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

>Почему? Очень интересно

потому что в первом случае он еще не стартовал, а в последнем уже убит.

> Без обид, но вы его сути, по-моему, не понимаете

я понимаю, что его сути не понимают простые пацанчики с семками на лавочках. Если мы хотим 99%й популярности ОС, нужно выпиливать культуру адептов.

от виндоподходов

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

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

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

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

Я говорил об уже написанных программах, присутствующих в разных ОС. Например, login в linux и в bsd. Для подобных вещей можно заранее сгенерировать идентификаторы, чтобы у разработчиков не возникало искушения использовать разные значения из-за нежелания лезть в код конкурирующей программы.

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

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

>Да в каждом проекте раз в полгода штормит из за того, что в оередной раз тупо пееименовали пару переменных, потому что разрабы осознали, что так будет «красивше».

Бежать от таких проектов надо. Подальше. И быстро-быстро.

Хотя сейчас такого софта - большинство:

1) XFree86 -> Xorg. И наступил звездец. Кто в лес, кто по дрова. DBus гвоздями прибили. Будет HAL, не будет HAL... Девочка на выданье, блин.

2) Поттеринг - ваще вещь! Прибитый к Гному pulseaudio (который плющит и лагает почем зря), нахер не нужный avahi, велосипедАстый systemd (ну посмоти ты на раскрутку системы в NetBSD/FreeBSD etc. ! Там этот велИсапет уже давненько изобрели. И без привязки к шине).

3) Мастодонтские KDE/GNOME3 - тема для отдельного флэйма. Вот там точно «а завтра будем опять прыгать вправо, только правильно».

> возможно ты еще не дорос до понимания концепции UNIX-way, инфа 100%

дело не во мне, а в рынке хомячков.

Я-то как раз кекс готовлю

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

Ты не понял. Предположим, сейчас я «включу дурака» и перейду на его Journal, и как этот «мастер костыля и подпорки» и предлагает, начну по scp складывать файлы на сервер логов. Ага. И вдруг в следующей версии он меняет формат журнала, и пишет новую версию бибилиотеки. Которая оказывает НЕСОВМЕСТИМА со старым форматом бинарного журнала. И что теперь делать? Хранить в системе два каталога с поттерлогами, и использовать два поттеркостыля с разными версиями поттербиблиотеки для доступа к поттерлогам. Ахрененно.

если гарантируется обратная совместимость с «устаревающими» форматами.

Никакой совместимости. Это лёнчик «бескомпромисный» поттеринг.

> Ага, гуйню по ssh через медленный интернет

медленного интернета больше нет, а простые пользователи не пользуются ssh и консолью (разве что в случае ЧП)

Бинарный лог - более тупой идеи трудно представить.
ЗЫ. Может не киллера а просто пальцы мужику поломать?

потому что то, что делает сислог просто кошмарно, хуже чем телнет и т.д.

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

> Может не киллера а просто пальцы мужику поломать?

Будет «идеи» генерировать вслух. Без лоботомии не обойтись...

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

gconf? то-то не слышно вашего «ура». Сказали бы, что демон журнала жирный и с xml внутре.

Но там systemd и гвоздями прибитый надуманый функционал, который ломает всю инфраструктуру

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

Что касается привязки именно к systemd, я не оень понимаю, а к чему его привязывать еще? initscripts? от него отказались и через два релиза федоры его вообще забудут. upstart? так он тоже уйдет в забытье. Какой смысл в напрасных усилиях по интеграции с ушедшим?

блин, убейте его уже кто-нибудь...

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

Поттеринг сам и сказал - /run.

systemd делат fork(), в форке стартует логгер, он пишет всё в /run

После монтирования ФС на чтение-запись, демон логгера по сигналу берет кэ из /run и сторит его в постоянное место хранения

Что сложного?

> entrprise решения

при чем тут вообще enterprise? Я говорю о home media desktop.

В ынтерпрайзе можно ковыряться хоть с баш-скриптами и напильником, говноынтепрайз всё выдюжит на нефтебаксах.

Ущербный леннарт

Леннарт — крутой чел. Все его разработки пока что были epic win'ом здравого смысла.

И ты весь в белом предлагаешь ЗАРАНЕЕ создать формат ВСЕХ сообщений? Ты правда не в своем уме?

«я джва года ждал такой лог!».

я говорю с позиции практики использования анализа строго структурированной базы в условиях жесткого прессинга со стороны обстоятельств.

более того, у меня такой лог уже есть. А у тебя?

Почти как у поттеринга, вот только жесткой завязки на systemd нет. И сам демон можно выкинуть и поставить другой. Ура. Компонентная архитектура.

> 1) когда должна стартовать БД, чтобы в нее логи писались?

чем раньше, тем лучше. Желательно с ядром.

как прочесть логи, если система не «взлетела» в штатном режиме?

с другого компьютера, который взлетел.

Лорчую.

Внимание! Всем, всем, всем!

Я много слышу про то КАК надо делать журнал. Кто-нибудь скажет мне ЗАЧЕМ переделывать существующую систему логирования?

Или если будет проще, - то задам еще более формальный вопрос: «какие требования (к службе) существующая система ведения логов не в состоянии решить?»

Я лично пока вижу (из высказываний) только:

- медленно работает при поиске информации

- не имеет унифицированный формат хранения

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

И я спрашиваю ЗАЧЕМ менять то, что и так выполняет все требования, на то, что частично НЕ выполняет?!

>Давай я тебе предложу идею? Передавать в каждом сообщении лога собственно сообщение и сигнатуру от «кодового слова». Кодовое слово для источника зашито в его конфиг. Кодовое слово источника знает сервер принимающий логи. И он сбрасывает или помечает как фейковые все сообщения, чья сигнатура не совпала с ожидаемой. Всё, задача решена.

Во первых, это изменение все равно сломает протокол.

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

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

И в третьих, добавив сюда передачу дополнительных полей, ты получишь то, что Леннарт обещает сделать чуть позже. А пока - фаллбек в сислог.

>Или если будет проще, - то задам еще более формальный вопрос: «какие требования (к службе) существующая система ведения логов не в состоянии решить?»

Этому посвящена примерно треть простынки по ссылке в новости.

И я спрашиваю ЗАЧЕМ менять то, что и так выполняет все требования, на то, что частично НЕ выполняет?!

А этому посвящена другая треть той же статьи.

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

Сформулируйте плиз требования (простым списком), которые по вашему мнению существующая система логирования не в состоянии решить?

И мы тогда все дружно рассудим кто тут прав, а кто нет?

ЗЫ! И за детали реализации тоже давайте не прятаться. Интересуют ТРЕБОВАНИЯ к службе логирования.

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

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

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

Конкурентность там не нужна, но нужно уметь как можно быстрее записать много данных. Не сильно медленнее.. Бенчмарки extN vs SQLite уже забыл? При этом при росте размеров базы скорость записи в неё будет успешно падать.

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

ipsec в середине не решает проблему?

>Поттеринг сам и сказал - /run.

systemd делат fork(), в форке стартует логгер, он пишет всё в /run

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

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

Логично, что проще было внести логгер в systemd, чем реализовывать надежный клей между ним и логгером? Особенно с учтом того, что других клиентов к этому логгеру на горизонет не видно?

> да вроде бы именно это он и декларирует.

вроде бы нет. он говорит о проблемах syslog, кое-что притягивая за уши. потом он говорит о journald - новом сервисе, гвоздями прибитом к systemd. намерения создать стандарт общения с журналом в статье не наблюдаю: наблюдаю намерение сделать новый сервис журнала. естественно, API будет :)

Журнал, это хорошо, но systemd отвратителен, могу я использовать journald без systemd?

Нет, не можете

Моему приложению необходимы традиционные текстовые логи на диске. Могу я сконфигурировать journald так, чтобы он генерировал их?

Нет, не можете

Я использую systemd во встраиваемой системе и не заинтересован в постоянном журналировании, могу я опционально выключить журнал?

Нет, никогда

Он не про API говорит, но про абсолютно конкретное видение реализации хранилища и работу с ним.

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

ты клоун :)

бинарный сислог не нужен.

> вендоподходы помогают захватить десктопный рынок, а юниксподходы - серверный. Соответственно в «линуксе для чайников» должны использоваться именно вендоподходы. Красть умные идеи не стыдно.

хехе. Изучение двух разных инструментов вместо одного. Нафиг не надо. Уже есть пауэршелл. И с каждым релизом микрософт всё больше кишков вытаскивает в консоль. Можно посмотреть скрипты как почекать письма в ящиках эксченджа и удалить ненужные. А прагыть в одном линухе с грепом а во втором с поттерепом никому не сплюшилось.

>ipsec в середине не решает проблему?

возможно. Но

1) это надо делать.

2) не совсем ipsec. тунель, это хорошо, но проверку данных от логгера он не обеспечивает.

Думаю, там будет что-то более простои и специализрованное. Типа, взял запись журнала, вложил хеш предыдущей записи, зашифровал, подписал и отправил.

Я имел в виду для бинарного представления. Сейчас я все вижу замечательно.

Ждём бинарных рее^Wконфигов.