• Оригинал: http://blog.gerhards.net/2011/11/what-i-dont-like-about-journald.html
• Переводчик: Любимов Алексей

Условия использования перевода

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

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

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

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

Что мне не нравится в journald / Линукс-журнале

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

Все аргументы против syslog можно разделить на два класса - надуманные и реальные факты. К мнимым аргументам можно отнести вещи типа "городской миф о безопасности" про хеш-цепочки, аргумент про временные зоны (думаю, он верный, если рассматривать сложившуюся практику в дистрибутивах), сетевой транспорт syslog и сжатие (и это неполный список). Технически корректными аргументами можно назвать текущий формат хранения, различные источники журналов и свободно-бесформенные сообщения (Мне больше нравится термин "полу-структурированные" (semi-structuredness)). Этот список тоже не окончательный.

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

Вопрос в том, как наилучшим образом решить актуальные проблемы. Так ли уж необходимо создавать полностью новую инфраструктуру и выбросить все то, что уже существует? Возможно. Я все еще предпочитаю альтернативный вариант: почему бы не расширить существующую технологию? Я специально для этого спроектировал rsyslog как модульную систему, в которую можно легко добавлять расширения. Насколько я знаю, syslog-ng тоже движется к такому дизайну в последней версии v3. В rsyslog я оперативно принимаю в дерево исходников даже экспериментальные технологии. Несколько месяцев новое хранилище журналов стояло у меня в планах (а коммерческий форк syslog-ng уже имеет его). К сожалению. у меня не было времени, чтобы реализовать его и никто не помог мне с этим. Разве не было бы хорошей идеей внести что-то новое в rsyslog, вместо того, чтобы переписывать все заново?

Другая мысль состоит в том, что я сильно сомневаюсь, что идея Линукс-журнала действительно позволит решить дилемму формата журналирования. Event log от компании Микрософт существует уже 15 с лишним лет, а разработчики приложений до сих пор не используют его правильно (как я уже писал, Линукс-журнал сильно смахивает на Windows Event Log). Хотя я нахожу идею использования UUID совсем неплохой, я серьезно сомневаюсь в том, что все разработчики ее поймут и будут (корректно) использовать. Это та проблема, которая присутствует в Windows Event log. Необходимо понимать, что множество высококлассных специалистов работали годами (10 с лигним лет) над решением этой дилеммы. Вполне возможно, что Леонарт гений, но я опасаюсь, что слишком много обещает (но я на самом деле желаю ему успеха, потому что это было бы очень, очень большим подспорьем для сообщества).

Еще я должен признаться, что меня разочаровывает то, что Леонарт ни разу не обратился ко мне со своими предложениями. Он знает меня (даже лично) и мы совместно работали над интеграцией systemd с rsyslog. Я впервые узнал о journald из оповещения Гугла и сразу после этого несколько человек спросили меня, что происходит. Затем я обнаружил, что в списке рассылки разработчиков systemd тоже ни разу не было упоминаний о работе над journald. Так что для меня все это выглядит как попытка преподнести сюрприз на Kernel Summit. Здорово, но это не мой стиль. ;-) Меня задевает такое отсутствие открытости. Мои решения, относящиеся к rsyslog многда были спорными или диктаторскими (и наверняка иногда неверными). И сейчас у нас проходят несколько больших и спорных дискуссий относительно того, куда двигать rsyslog (которые отчасти подпитываются появлением journald). Но я всегда играю открыто, заранее сообщаю, что за мысли роятся у меня в голове, дискутирую и никогда не пытаюсь что-то скрывать. Это как раз то, что по правде говоря, я ожидаю увидеть в работе над одним из важных компонентов системы. Я также н разу не общался с Леонартом ни в одном из органов по сдандартизации журналирования. Не все работают в линуксе и возможно не все в линуксе будут использовать journald. Так что стандартизация, это важно.