The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Разработчики systemd: загрузка с initrd оказалась быстрее за..., opennews (??), 07-Апр-13, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


50. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  +4 +/
Сообщение от Аноним (-), 07-Апр-13, 15:35 
> Нет. Для этого придумали logrotate, который успешно gzip-ит (bzip-ит, xz-ит, на ваш
> выбор) логи уже пару десятков лет. Если хочется, то в обычном
> rsyslog-е есть потоковое сжатие, чтобы писать логи сразу в сжатом формате,
> для экономии места. Идея бинарных логов была в том, чтобы превратить
> их в базу данных, по которой можно делать быстрый поиск, типа
> "выдайте мне лог такой-то программы за такое-то число". В ответ ему,
> кажется, автор rsyslog-а писал, что для этого не нужен бинарный формат,
> есть уже куча готовых программ, которые можно цеплять на обычный syslog,
> они его проиндексируют, и даже в базу данных могут сложить (навскидку
> GrayLog2, ElasticSearch, Solr...)

Все эти костыли по-своему замечательны, но проблем дизайна протокола syslog они не решают. Наиболее паршивых проблем две:
1. Неструктурированная запись. syslog by design ориентирован на человека, а не на машинный парсинг, поэтому вместо структурированной записи с именами полей, получается одна текстовая строчка, которую в общем случае может понять только человек. Такое вот сжатие с потерями. В то время как в Journal это сжатие происходит не на стадии записи лога, а на стадии выдачи его человеку. При необходимости, и программы, и человек могут использовать полезную информацию о структуре записи (например, искать сообщения по UUID).
2. Недоверенная информация. В syslog может писать кто угодно и что угодно. Даже из-под nobody можно написать туда такого, что админ будет месяц разбираться.

В UNIX эту проблему решили много лет назад, введя специальный защищенный бинарный лог (BSM). Так появилась инфраструктура аудита.

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

> а при переходе на systemd геморроя много, а толку нет.

С точки зрения диванного теоретика - да :)

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

А вот тырпрайз-админы с нетерпением ожидают RHEL/CentOS/OL 7. В основном из-за Journal, конечно.

> Поттеринг меня раздражает.

Ну и опять поток сознания какого-то хипстера. Скучища...

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

87. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  +3 +/
Сообщение от Аноним (-), 07-Апр-13, 16:51 
> Все эти костыли по-своему замечательны, но проблем дизайна протокола syslog они не
> решают. Наиболее паршивых проблем две:
> 1. Неструктурированная запись. syslog by design ориентирован на человека, а не на
> машинный парсинг, поэтому вместо структурированной записи с именами полей, получается
> одна текстовая строчка, которую в общем случае может понять только человек.
> Такое вот сжатие с потерями. В то время как в Journal
> это сжатие происходит не на стадии записи лога, а на стадии
> выдачи его человеку. При необходимости, и программы, и человек могут использовать
> полезную информацию о структуре записи (например, искать сообщения по UUID).

Ась? Какое-какое "сжатие с потерями"? Эк Вас приложило-то... А "сжатие происходит не на стадии записи лога, а на стадии выдачи его человеку" - это вообще шедевр! И, к стати, журнал, чем бы он ни был записан (хоть syslog, хоть journal, хоть админом на бумажке) нужен для анализа его человеком. Компьютер, конечно же, может ему в этом помочь, но журнал в текстовом виде в этом случае предпочтительнее, чем в бинарном, поскольку для работы с текстами УЖЕ ЕСТЬ КУЧА ГОТОВЫХ И ПРОВЕРЕННЫХ ИНСТРУМЕНТОВ (grep, awk, perl etc), а для бинарного их (аналоги) нужно создавать с нуля, и ошибок при этом будет немало... Логичный вопрос - зачем терять существующие инструменты ради еще несуществующих и, скорее всего, бажных?

> 2. Недоверенная информация. В syslog может писать кто угодно и что угодно.
> Даже из-под nobody можно написать туда такого, что админ будет месяц
> разбираться.

Вы хотите сказать, что в journal писать может не кто угодно? Тогда смысл в этом журнале, если нужная МНЕ (не Вам и не Поттеру, а именно мне на моем компьютере!) программа не может писать в журнал? А если может - то кто мешает мне (ну или тому, кто может запустить програму на этом компьютере) написать в журнал что угодно?
Вы (ну, не лично, а в лице Поттера, или кто там сейчас главный идеолог проекта) пытаетесь проблему безопасности решать инструментом, для этого не предназначеным (системным журналом). Можно, конечно, микроскопом гвозди забивать, но неудобно - молотком значительно удобнее и для пальцев безопаснее.

> А вот тырпрайз-админы с нетерпением ожидают RHEL/CentOS/OL 7. В основном из-за Journal,
> конечно.

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

Ответить | Правка | Наверх | Cообщить модератору

89. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  –1 +/
Сообщение от Аноним (-), 07-Апр-13, 17:02 
> Ась? Какое-какое "сжатие с потерями"? Эк Вас приложило-то... А "сжатие происходит не
> на стадии записи лога, а на стадии выдачи его человеку" -
> это вообще шедевр!

Попробую еще раз, для самых несообразительных: структура записи (какая информация какому полю принадлежит) - это информация. И при выводе в формате /var/log/messages она теряется.

> но журнал в текстовом виде в этом случае предпочтительнее, чем
> в бинарном, поскольку для работы с текстами УЖЕ ЕСТЬ КУЧА ГОТОВЫХ
> И ПРОВЕРЕННЫХ ИНСТРУМЕНТОВ (grep, awk, perl etc), а для бинарного их
> (аналоги) нужно создавать с нуля, и ошибок при этом будет немало...

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

> Вы хотите сказать, что в journal писать может не кто угодно? Тогда
> смысл в этом журнале, если нужная МНЕ (не Вам и не
> Поттеру, а именно мне на моем компьютере!) программа не может писать
> в журнал? А если может - то кто мешает мне (ну
> или тому, кто может запустить програму на этом компьютере) написать в
> журнал что угодно?

Записать в журнал вы можете все, что угодно. Но только от своего имени (UID, GID, session ID). И столь ненавидимый вами бинарный формат позволит легко отфильтровать это.

А при записи в syslog регистрируется не UID программы (протокол syslog это не поддерживает), а тот UID, который сама программа изволит сообщить. Поэтому даже nobody может писать от имени рута.

> А если завтра "тырпрайз-админы" возьмут веревки и дружно вешаться станут

Скорее, завтра станут вешаться противники systemd, в знак протеста :)

Ответить | Правка | Наверх | Cообщить модератору

94. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  +1 +/
Сообщение от Аноним (-), 07-Апр-13, 17:15 
> Попробую еще раз, для самых несообразительных: структура записи (какая информация какому
> полю принадлежит) - это информация. И при выводе в формате /var/log/messages
> она теряется.

Вот, для сравнения, несжатый вариант

Tue, 2012-10-23 23:51:38 CEST
PRIORITY=6
SYSLOG_FACILITY=3
_MACHINE_ID=a91663387a90b89f185d4e860000001a
_HOSTNAME=epsilon
_TRANSPORT=syslog
SYSLOG_IDENTIFIER=avahi-daemon
_COMM=avahi-daemon
_EXE=/usr/sbin/avahi-daemon
_SYSTEMD_CGROUP=/system/avahi-daemon.service
_SYSTEMD_UNIT=avahi-daemon.service
_SELINUX_CONTEXT=system_u:system_r:avahi_t:s0
_UID=70
_GID=70
_CMDLINE=avahi-daemon: registering [epsilon.local]
MESSAGE=Joining mDNS multicast group on interface wlan0.IPv4 with address 172.31.0.53.
_BOOT_ID=5335e9cf5d954633bb99aefc0ec38c25
_PID=27937
SYSLOG_PID=27937
_SOURCE_REALTIME_TIMESTAMP=1351029098747042

И сжатый:

Oct 23 23:51:38 epsilon avahi-daemon[27937]: Joining mDNS multicast group on interface wlan0.IPv4 with address 172.31.0.53.

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

Ответить | Правка | Наверх | Cообщить модератору

102. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  +3 +/
Сообщение от Аноним (-), 07-Апр-13, 18:07 
> А при записи в syslog регистрируется не UID программы (протокол syslog это
> не поддерживает), а тот UID, который сама программа изволит сообщить. Поэтому
> даже nobody может писать от имени рута.

http://blog.gerhards.net/2011/11/trusted-properties-in-rsysl... просвещайся.

Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

296. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  +/
Сообщение от qux (ok), 09-Апр-13, 18:57 
> http://blog.gerhards.net/2011/11/trusted-properties-in-rsysl... просвещайся.

Оттуда:

> The idea is rooted in the journald proposal

:)

Ответить | Правка | Наверх | Cообщить модератору

132. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  +1 +/
Сообщение от jOKer (ok), 07-Апр-13, 20:45 
А между прочим кто сказал, что поступающая в журнал инфа должна укладываться в прокрустово ложе представлений Леонардо о нормализации?

И почему бы не хранить данные в NoSQL DB?

И с какого перепуга Леонардо смешал в кучу нормализацию данных (которая очевидно в журнале никому не упала) и бинарный формат, который возможно кому-то и понадобится? Между этими понятиями, если что, знак равенства не стоит!

Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

148. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  –1 +/
Сообщение от all_glory_to_the_hypnotoad (ok), 07-Апр-13, 22:40 
> И почему бы не хранить данные в NoSQL DB?

считай, что бинарный лог и есть такая DB.

Ответить | Правка | Наверх | Cообщить модератору

152. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  +2 +/
Сообщение от jOKer (ok), 07-Апр-13, 22:58 
Наивный вопрос имею: а почему бы не считать такой БД обычный текстовик в формате "ключ-значение"?
Ответить | Правка | Наверх | Cообщить модератору

155. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  –1 +/
Сообщение от all_glory_to_the_hypnotoad (ok), 07-Апр-13, 23:16 
можно и так считать, под 'NoSQL БД' попадает всё что угодно
Ответить | Правка | Наверх | Cообщить модератору

156. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  +1 +/
Сообщение от jOKer (ok), 07-Апр-13, 23:32 
Тогда последний наивный вопрос: а не проще ли было бы прикрутить к rsyslog (как вариант) NoSQL backend на вкус админа хоста и расслабится? На все-про-все пол-часа работы...
Ответить | Правка | Наверх | Cообщить модератору

162. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  +1 +/
Сообщение от all_glory_to_the_hypnotoad (ok), 08-Апр-13, 00:17 
> а не проще ли было бы прикрутить к rsyslog (как вариант) NoSQL backend

сислог не предоставляет равноценный интерфейс приложению. Mеняется не только способ хранения, но и API между логгером и сервисом (+ некоторые метаданные из приложения). Правда, текущее API сделано убоговато и не раскрывает всего потенциала технологии.

[сообщение отредактировано модератором]

Ответить | Правка | Наверх | Cообщить модератору

214. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  –1 +/
Сообщение от Аноним (-), 08-Апр-13, 10:23 
> Наивный вопрос имею: а почему бы не считать такой БД обычный текстовик в формате "ключ-значение"?

Потому что у него нет индексов для быстрого лукапа в основном. Ну и потому что он неэффективен для хранения всего что отличается от текста. Например IPv4 занимает в бинарном виде 4 байта. А сколько он займет в виде текста? Ах, вплоть до 15 байтов? И как вам перспектива получить лог не на 4 гига а на 15? Ну, если немного отмасштабировать.

А потом будет очень круто, когда 15-гиговый лог без индекса надо будет целиком лопатить грепом.

Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

226. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  +/
Сообщение от jOKer (ok), 08-Апр-13, 12:12 
На самом деле, вы немножко забегаете вперед: сначала надо условится о том "что" храним, а уж потом думать о том "как" храним.

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

Теперь о том, "как" хранить. Есть разные случаи и разные потребности: кому-то и индексы будут не нужны, а кому-то потребуются множественные параллельные запросы в стиле map-reduce. ОК, ну так для этой цели как раз и нужна архитектура фронтэнд-бакэнд, причем в качестве бакэнда должна иметь возможность выступить *любая* NoSQL СУБД. От текстовика, до промышленных МонгоДБ  и ОриентДБ. Но, насколько я понимаю, изделие Леонардо этого не умеет и работает строго со своим хранилищем. Так что и тут неувязочка.

Подытоживая: возможно, rsyslog и иже с ними и устарели (не буду спорить, хотя спорить есть о чем), но и то что пихает г-н Поттеринг - это не то. ИМХО, это сильно урезанная и пропущенная через призму его мнения версия того что надо. И ничего другого от него ждать и не стоит: практически все его программы очень неопрятны и размазаны архитектурно. Риск их применения ну очень велик, а профит напротив - ничтожен.

Ответить | Правка | Наверх | Cообщить модератору

141. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  +1 +/
Сообщение от Michael Shigorinemail (ok), 07-Апр-13, 21:02 
> Попробую еще раз, для самых несообразительных:

Вы бы сами для начала перестали путать "формат /var/log/messages" и RFC 3164/5424.

> Бинарный формат не требует создания таких инструментов, по определению.

Сказочник.

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

Вопрос в надежде на то, что это был всё-таки помрачённый User294: зачем в РСУБД хранимые процедуры придумали -- сами сообразите или подсказать надо?

>> А если завтра "тырпрайз-админы" возьмут веревки и дружно вешаться станут
> Скорее, завтра станут вешаться противники systemd, в знак протеста :)

Завтра он начнёт интересными пакетиками с сетью обмениваться, что-то мне подсказывает.

Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

147. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  –1 +/
Сообщение от quuxemail (??), 07-Апр-13, 22:28 
> зачем в РСУБД хранимые процедуры придумали -- сами сообразите или подсказать надо?

Ну и зачем ?

Ответить | Правка | Наверх | Cообщить модератору

151. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  +1 +/
Сообщение от Michael Shigorinemail (ok), 07-Апр-13, 22:49 
>> зачем в РСУБД хранимые процедуры придумали -- сами сообразите или подсказать надо?
> Ну и зачем ?

...когда всё решается высокоуровневыми запросами по структурированным данным, ага... ;-)

Ответить | Правка | Наверх | Cообщить модератору

196. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  +/
Сообщение от жабабыдлокодер (ok), 08-Апр-13, 09:12 
Хранимые процедуры придуманы для реализации бизнес-логики, когда скорость критична или когда необходимо преобразование данных прямо в базе. И что?
Ответить | Правка | Наверх | Cообщить модератору

311. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  +1 +/
Сообщение от Michael Shigorinemail (ok), 10-Апр-13, 00:11 
> И что?

Если мне не изменяет склероз по мотивам давно уж прочтённого Дейта, то изначально высоколобые теоретики предполагали, что всем(tm) будет достаточно языка четвёртого поколения.

Жизнь оказалась заковыристей.

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

При этом и ручки нужны, и SQL полезен -- спору нет.  В отличие от людей с табличным или псевдосистемным подходом ко всему подряд.

Ответить | Правка | Наверх | Cообщить модератору

193. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  +/
Сообщение от anonymous (??), 08-Апр-13, 09:01 
> > зачем в РСУБД хранимые процедуры придумали -- сами сообразите или подсказать надо?
>
> Ну и зачем ?

В процессе отработки кошерного реляционного запроса легко получаются многомерные массивы нехилого объема. И тогда придумать sql clause, который engine может переварить становится нетривиально и он (clause) сильно зависит от engine (т.е. формально переносимо, фактически --- нет).

Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

133. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  +1 +/
Сообщение от Аноним (-), 07-Апр-13, 20:47 
1) Структурированный лог это замечательно.
2) Двоичный лог это просто глупость.
3) "Доверенное" логгирование это палка о двух концах, поскольку добавляет в систему еще одну Точку Отказа Всего.
Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

181. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  +1 +/
Сообщение от Аноним (-), 08-Апр-13, 05:30 
> Все эти костыли по-своему замечательны, но проблем дизайна протокола syslog они не
> решают. Наиболее паршивых проблем две:
> 1. Неструктурированная запись. syslog by design ориентирован на человека, а не на
> машинный парсинг, поэтому вместо структурированной записи с именами полей, получается
> одна текстовая строчка, которую в общем случае может понять только человек.
> Такое вот сжатие с потерями. В то время как в Journal
> это сжатие происходит не на стадии записи лога, а на стадии
> выдачи его человеку. При необходимости, и программы, и человек могут использовать
> полезную информацию о структуре записи (например, искать сообщения по UUID).

Все программисты сразу кинулись переписывать программы под journald ?

> 2. Недоверенная информация. В syslog может писать кто угодно и что угодно.
> Даже из-под nobody можно написать туда такого, что админ будет месяц
> разбираться.

А вот ненадо ставить права на лог 777.

> В UNIX эту проблему решили много лет назад, введя специальный защищенный бинарный
> лог (BSM). Так появилась инфраструктура аудита.
> Но вопросы структурирования, индексирования информации, быстрого поиска по ней и т.д. актуальны
> не только для событий безопасности, но и для всех системных событий,
> так что появление Journal было неизбежно.

вы действительно хотите индексировать логи на боевом сервере?

Как там у journald с удаленными логами, не стриминг по http а именно удаленная запись логов.

Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

283. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  –1 +/
Сообщение от Анноннимм (?), 09-Апр-13, 00:32 
> вы действительно хотите индексировать логи на боевом сервере?

А вы действительно используете syslog для логирования запросов, к скажем, высоконагруженному nginx? Мне кажется, тут безальтернативно - либо писать их в файл самим nginx'ом, что и делается в 90 из 100 инсталляций, либо, если есть реальная необходимость, то докупить озу и хранить их какое-то время в рамдиске, а потом сливать куда нибудь по сети. Можно ещё писать на отдельный диск, да, должно быть не очень печально в плане нагрузки. Впрочем, это меня уже в сторону понесло, основная мысль - писать быстро генерирующиеся большими пачками логи что в syslog, что в journal - глупость. А для системных логов, я практически уверен, переубедите меня тестами или примерами, существенной разницы и нет.

> Как там у journald с удаленными логами, не стриминг по http а
> именно удаленная запись логов.

Не знаю. Но вообще, journald более чем спорная штука, тут не поспоришь.

Ответить | Правка | Наверх | Cообщить модератору

295. "Разработчики systemd: загрузка с initrd оказалась быстрее за..."  +/
Сообщение от qux (ok), 09-Апр-13, 18:55 
> А вот ненадо ставить права на лог 777.

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

Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру