logger

> чтобы писать в syslog
нужно волевое решение админа - logger тот же уж сколько лет?

сакральное знание

ну как бы rtfm - или и о main(){} -тоже леннарт должен позаботиться?;)

> грязно ругается «Пошли вы на ..., у вас /usr не на корневой ФС, ничего у вас теперь работать не будет...

И это называется - „работает же systemd - вроде никаких особых нареканий к нему нет“ ?

Может все-таки скинуться?

> Раз уж я ее переводил, то заодно и прочитал ;).

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

мне и интересно было, почему вы решили, что всё будет так прозрачно. текст оригинала не говорит об этом:

Wherever protocol compatibility with syslog is required, a classic syslog implementation needs to be used. To ensure this works nicely, we implemented the journal so that it can cooperate cleanly with a local syslog daemon and messages are forwarded as needed so that syslog continues to work exactly as it did without journald in the mix.

перенаправление будет, но откуда и куда - непонятно. хотя ведь «we implemented the journal so ... messages are forwarded» намекает на то, что сообщения из журнала будут перенаправляться в syslog.

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

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

Не, к четвёртому ноября сделал.

С другой стороны, работает же systemd - вроде никаких особых нареканий к нему нет.

Это тебе не приходилось проблемы разбирать. У меня как-то раз в системе с systemd при старте начал падать dirsrv-admin. Так я зае...ся разбираться с этой гребаной хренью, которая в принципе не переводится в интерактивный последовательный режим, и я потратил хренову тучу времени чтобы понять в чем дело и потом это исправить. Так что пусть леннарт со своими поделиями идет на..й, а лечше еще дальше!

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

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

Как? Каким образом?

> С другой стороны, работает же systemd - вроде никаких особых нареканий к нему нет.

Да, ладно... А эпичную попытку systemd вызвать программу из /usr/, в то время, как сам же systemd ещё не сподобился его смонтировать, уже пофиксили?

P.S. Лично не проверял (не использую systemd).

>> В отличие от пульсы, он не зависит от железа, так что с отладкой гораздо проще.

Вот не вижу я никакой разницы в легкости отладки между пульсом и systemd

А она есть.

> думаю, что всё-таки случай с Хромом - нетипичен. мне эта тема интересна, начал копать, забавные вещи накопал, если всё действительно так обстоит как авторы Хрома писали - закопать его надо немедленно.:)

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

а вообще, тебе же совет был от чела - переходи на Генту, будет тебе счастье!

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

в конце концов - тебе шашечки или ехать?;)

Мне ехать, но чтобы колеса не квадратные.

вот только былинно как-то с /usr отдельно :-)

Уже тысячу раз сказано - это не из-за systemd. Аналогичное решение рассматривается даже в Debian, безотносительно systemd.

Так скидываемся или Ганса из тюряги вытаскиваем?

Нет. Но твое мнение на эту тему — мнение типичного обывательского говна, которое жрёт попкорн и улюлюкает на тех, кто фэйлит эпичные таски. То есть ты один из тех кто обосрался просто по жизни. Ты просто не шаришь, даже _попытка_ запустить космический аппарат на 100500 уровней выше любой рекламы.

Но тебе, как и любому бездельнику, космос не светит. Ты будешь «жрать, срать, ржать», как говаривал один мемовый персонаж.

> > вот только былинно как-то с /usr отдельно :-)

Уже тысячу раз сказано - это не из-за systemd. Аналогичное решение

рассматривается даже в Debian, безотносительно systemd.

Ссылочку можно? Что-то не нашел и очень плохо верится, что debian свалит все в одну кучу без возможности разделения мух и котлет.

> Насколько я понимаю, он сам — «служба, использующая dbus».

Даже если так - что в этом плохого? Кроме 1.5 мегабайт зависимостей.

> 1. А это ничего, что логи на сервер логирования должны уходить сразу же? Использовать старые демоны лога. Перейти на journald только после появления фичи ремотной передачи логов.

2. Что делать с тыщами устройств которые умеют только syslog?

Сделают плагин эмулирующий syslog - это наверняка одна из няшных фишек journald.

Уже тысячу раз сказано - это не из-за systemd. Аналогичное решение рассматривается даже в Debian, безотносительно systemd.

Ссылочку можно? Что-то не нашел

http://lists.debian.org/debian-devel/2011/10/msg00157.html

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

Свалит или не свалит - другой вопрос. Мой пойнт в том, что вопрос обсуждается в дистре, не использующем systemd. И, насколько я понял, раньше в Debian обсуждался вопрос «а не передвинуть ли нам /usr в /» (ИМХО, гораздо более логичное решение, чем передвинуть всё в /usr).

> А когда дело доходит до реализации, то исполнять он не будет,

ты ничего не понимаешь в работе лидера

Где ты, шут гороховый, увидел «условиях жесткого прессинга» на «home media desktop», а?

когда шеф придет и скажет, что ты должен за этот день пофиксать баг в «home media desktop»-приложении, произошедший месяц назад, который встречатся аж у 2х человек на всей планете, и не один из них не может сформулировать его конкретнее чем «ничего не работает», ты поймешь

Журнал никто не читает,

напомнило «Ъ по ссылкам не ходят». Говори-ка ты за себя и свои поделия.

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

Журнал никто не читает, пока всё нормально

мы точно говорим о линуксах? в линуксах _постоянно_ что-то ненормально. Каждую секунду что-то не работает и пишет в лог «аааа спасити памагити нет пути».

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

Сисадмину это вещь #1. А простому пользователю такую штуку неплохо было бы повесить в качестве виджета на рабочий стол, например.

парочка наблюдений: сейчас такая система будет жрать _значительное_ время на периодический ретроспективный анализ (анализ неочевидных трендов, например).
Плюс чтобы написать ее, придется потратить много больше 9000 человекочасов, т.к. на каждую мельчайшую хреновину нужно будет написать парсер логов и апдейтить этот парсер на каждый коммит в транк разработчиков софтины.

Спасибо за ссылку. Ничего нового не нашел - тот-же срач, что и на LOR, только язык отличается.

Ну что-ж, коли все в кучу свалят и там, придется переползать на BSD.

> зато Леннарт предлагает ВСЕМ дружно перескочить на его поделие

Леннарт двигает то, что ему удобнее.
Мне тоже удобно то, что удобно Леннарту.
Уже два человека.

Чую баттхерт в твоих словах, потому что ты знаешь — таких людей куда более чем 2, и сислог таки выпилят ;)

20G/день логов

И ещё куча других

Если у тебя 20G логов в час (и все эти логи критичны и требуют аналитики) — то это какой-то Ъ ынтерпрайз.
За такие деньги можно написать и свою систему логгирования, если Леннартовская не нравится.
Ну или по крайней мере асилить прикрутить назад сислог -)

он эти нефтебаксы зарабатывает! Зарабатывает с помощью башскриптов

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

>> 1. А это ничего, что логи на сервер логирования должны уходить сразу же?

Использовать старые демоны лога. Перейти на journald только после появления фичи ремотной передачи логов.

Т.е. никогда не использовать journald.

2. Что делать с тыщами устройств которые умеют только syslog?

Сделают плагин эмулирующий syslog - это наверняка одна из няшных фишек journald.

См. первый ответ.

> и если она вопреки заветам Партии всё-таки вынесена, грязно ругается «Пошли вы на ..., у вас /usr не на корневой ФС, ничего у вас теперь работать не будет, я это гарантирую!»

И правильно делает, потому что в Федорке сломана загрузка с отдельным /usr. Сломана вне зависимости от того, юзался бы systemd или нет.

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

можно где нить поподробнее про него почиттать? биография, разработки и тд

> в линуксах _постоянно_ что-то ненормально. Каждую секунду что-то не работает и пишет в лог «аааа спасити памагити нет пути».

Да ты бредишь!

>лучшая OpenSuSE - это Slackware
лучше слаки только арч

И ты вообще не понимаешь ни UNIX-way, ни KISS-принцип. Абсолютно.

Да, в порядке издевательства:

поскольку systemd не фурычит, если бинари у него на отдельном, не рутовом разделе, то уж наверняка journald не будет фурычить, если у него /var отдельно.

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

Ну, зачем же так мучить своё воображение? :)

Вот, бери, пользуйся: http://www.nagios.com/products/nagiosxi/screenshots

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

Это ты сейчас пытаешься изобрести хранилище данных (DWH).

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

Уже есть парсеры логов на много сколько мельчайших хреновин.

P.S. Ломать зачем?

> Т.е. никогда не использовать journald.

т.е. не использовать jourland до появления нужного для вас функционала. как и с любым другим ПО ;)

> вместо системы где главным форматом является текст и которая может быть расширена до системы работающей любым форматом (в том числе и с бинарным/СУБД), нам предлагают систему которая работает только с бинарным форматом.

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

journal -node=server123 -user=apache | grep whatever

> Я тебя расстрою - копаться в 50ГБ логов в бинарном виде ничуть не легче и не быстрее, потому что дял «легче и быстрее» нужны очень хорошие алгоритмы и индексы. Чего у поттеринга (ага!) реализовано, естественно, не будет.

базовые величины можно проиндексировать заранее, так что большинство common запросов будет работать быстрее by design (ага!)

Читаю этот тред и умиляюсь... Бинарные логи, быстрый доступ, grep тормозной, а индексы такие быстрые. И почти никто(!!!) не понимает, что индексы строить это такой тупо размазанный по времени grep. Причём, если индексы не в памяти хранятся, то это еще и дикая фрагментированная нагрузка на hdd. Во вменяемой системе важнее чёткая детерминированность, и вместо постоянного обновления индекса там выберут 'grep' раз в сутки во время когда система наименее нагружена. Или аналог грепа с построением индексов в памяти, выдёргиванием нужной статистики и архивированием лога за это время.

Очень надеюсь, что эта поделка никогда не попадёт ни в федору ни в редхат.

> и этот бинарный работает на критериальный поиск быстрее

Разложите журналы syslog НОРМАЛЬНО и не нужно будет из ЕДИНОЙ БИНАРНОЙ ПОМОЙКИ через заднее место под grep что-то вытаскивать.

Как следствие - оно будет МЕДЛЕННЕЕ, ибо конвертация + grep, а не просто grep.

Где сказано, что эти приницпы обязательны к применению?

>И правильно делает, потому что в Федорке сломана загрузка с отдельным /usr

Э... Мда. Не знаю, как это прокомментировать, но в общем они неправы.

>Все его разработки пока что были epic win'ом здравого смысла.

Назови хоть одну.

> Единственное общее, что есть у записей логов разных программ, это «когда, на каком хосте, какой процесс, какой юзер, важность». И всё, что ты можешь сделать для реализации логов в базе, это одну большую таблицу с указанными полями и одним большим CLOB/BLOB под всё остальное.

Так это и есть основное преимущество ))) еще хост может именоваться начиная с сети: local.finland.helsinki.espoo.user_vasya

Тогда можно посмотреть какие события уровня ВАЖНО произошли со всеми компами в офисе, расположенном в Espoo, Финляндия в определенный период времени.

SELECT * FROM data WHERE date between " and " AND host like 'local.finland.helsinki.espoo.%' AND lever > WARNING

На grep или perl это довольно хитровыебнуто реализуется.

> Накопил я типа 10ГБ логов, а тут раз - формат сменился, билиотека сменилась, и старая версия не берет новый формат, а новая версия - не понимает старый! Слава поттербляди, ага.

а GIT / Hg / Bzr никогда не меняли формат хранения? вроде все живы ;)

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

> SELECT * FROM data WHERE date between " and " AND host like 'local.finland.helsinki.espoo.%' AND lever > WARNING

На grep или perl это довольно хитровыебнуто реализуется.

Напиши функцию date_between, и всё станет тривиально. И да, хранение записей лога в БД достигается и без поттерлога.

>Как? Каким образом?

Что-то я не понимаю, а это разве не самоочевидно?
Вместо того, чтобы заморачиваться с грудой файлов, одни из которых сжаты, а другие нет (разные расширения, если вращалось, то разный формат имени в целом), а ещё нужно понять, в каком порядке их читать, чтобы не «начать с конца» - более компактный бинарный формат хоть и предполагает необходимость добавления аж одной команды в pipe до grep'а, sed'а или awk, но при этом позволяет: а) не сжимать файлы вообще б) вращать их настолько редко, чтобы в большинстве случаев считывание нескольих файлов было просто не нужно.
Ведь чаще всего в реальной практике сисадминства необходимо изучить логи в пределах недели. И если для какой-нибудь почты текстовые логи за неделю хранить в несжатом виде проблематично, то в бинарном формате они вполне могут изначально занимать не очень много места.

> А в онлайне журналировать на другой хост в systemd-journal нельзя по построению.

Есть пруф что сетевая передача (PUSH / PULL) никогда не будет реализована? Выше по треду пробегала ссылка, что сеть будет сделана позднее.

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

Что вы все такие кровожадные: «Убейте, отрежьте пальцы...!!!»?

Достаточно просто перевезти его в Нефтеюганск и назначить «пенсию» 4 т.руб.

Тогда не до дури будет!

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

Время на индексацию сам посчитаешь? А не постоянную переиндексацию, поскольку данные постоянно валятся?

образом

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

Есть пруф что сетевая передача (PUSH / PULL) никогда не будет реализована? Выше по треду пробегала ссылка, что сеть будет сделана позднее.

PUSH/PULL это «еще одна реализация scp». Она не дает онлайновости.

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

Как? Каким образом?

Что-то я не понимаю, а это разве не самоочевидно?

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

Вместо того, чтобы заморачиваться с грудой файлов, одни из которых сжаты, а другие нет (разные расширения, если вращалось, то разный формат имени в целом), а ещё нужно понять, в каком порядке их читать, чтобы не «начать с конца»

Проблема имени файла в полный рост? Тебе сколько лет?

- более компактный бинарный формат

* почему ты уверен, что он будет более компактный, за счёт чего?

С чего ты решил, что бинарный формат будет компактный?

хоть и предполагает необходимость добавления аж одной команды в pipe до grep'а, sed'а или awk, но при этом позволяет:

* что это за магическая «одна» команда?

Продемонстрируй прототип вызова.

а) не сжимать файлы вообще

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

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

* насколько редко или часто следует «вращать» базу данных?
* чем твоя фантазия отличается от реальности предлагаемой Леннартом Поттерингом?

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

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

Нахрена спрашивается, ты лезешь в организацию системных логов, если твоя сфера интересов - почта?

> 1. Разве не O(N) стоит создать индекс, который в дальнейшем нащи доблестные небыдло-илитарии будут обходить за O(logN)?

Создание идет только один раз. Обычно на пустой БД. Дальше только вставка.

2. Разве не требуется пересоздавать индекс (по цене O(N), к стати) каждые раз, как в лог добавляется новая запись?

Нет, не требуется. Только вставка нового значения в индекс. Если индекс на основе деревьев, то еще изредка ребалансинг индекса.

> и ага, добавляет невдолбенный секас с ротацией бинарных блобов по типу archivelogs в оракакеле.

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

Тут же, по аналогии, проявляются несколько вопросов:
Бинарные логи Леннарта Поттера можно заставить писать в несколько мест параллельно? Как обеспечивается безопасность?
Как предполагается автоматически решать проблему возможного рассогласования результата параллельной записи бинарных логов?

И, все-таки, Леннарт будет терять системные бинарные логи, объявляя нечитаемыми или отсутствующими?
Каким будет механизм обеспечения целостности данных?
Как система будет реагировать на отказ подсистемы логирования?

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

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

Тогда можно посмотреть какие события уровня ВАЖНО произошли со всеми компами в офисе, расположенном в Espoo, Финляндия в определенный период времени.

Раскладывать по файлам нормальным образом образом не пробовал? Говорят, помогает.

Я не имею ничего против новой системы логгирования, ЕСЛИ ОНА БУДЕТ РЕАЛИЗОВАНА НОРМАЛЬНЫМ РАСШИРЯЕМЫМ ОБРАЗОМ! Тот же rsyslog - он умеет не только тупо писать поток событий в файл, но и производить некоторый первичный анализ сообщения, отдавать сообщения сразу в базу, отдавать их на через пайпы другим программам, рассылать SNMP трапы и много чего еще - просто потому, что он плагинный. Хоть что-то из этого будет реализовано в поттерлоге? Хрен там.

Так что лучше бы поттеринг заткнулся, сделал нормальный API для нового логгера, написал бы расширяемый логгер с плагинной архитектурой и, если уж ему так вперлось сделать бинарный лог, сделал бы его. Через plugin. А более разумные люди сделали бы другие плагины. И самое главное - не прибивать ЭТО гвоздями к systemd. Потому, что прибитый к systemd он автоматом прибивается к линуксу, а это плохо.

Если индекс на основе деревьев, то еще изредка ребалансинг индекса.

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

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

+100500 )))

> И самое главное - не прибивать ЭТО гвоздями к systemd. Потому, что прибитый к systemd он автоматом прибивается к линуксу, а это плохо.

Не говоря уже о том, что systemd уже слишком толстый.