LINUX.ORG.RU

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

 , ,


1

2

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

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

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

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

★★★★★

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

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

> Не смеши меня. В наших системах логи считает ETL-кластер, никакая базка и близко не справится.

У тебя какие-то совсем Тру Энтерпрайз задачи, видимо. Я пока с такими не сталкивался. Но мне интересно, почему ты считаешь нормальным такой зазор - три с половиной задачи в текстовый файл, а затем сразу какой-то датамайнинг на кластере? Леннарт-то как раз и говорит, что посередине этого есть куча задач, которые не влазят в стандарт syslog.

А он не думал что его нету именно по той причине что невозможно придумать стандарт лога на все случаи жизни?

Возможно. Кстати, народ, попробуйте сбросить бинарный дамп в syslog - многие приложения ведут себя удивительно, когда сталкиваются с таким. Я, когда об этом узнал и локализовал проблемы, то даже придумал пару интересных вариантов DoS для нескольких популярных веб-фреймворков.

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

Да я в принципе не против сетевой прозрачности звуковой подсистемы, если бы PulseAudio работало без проблем. А то уже сколько лет прошло, а пользоваться этой штукой все как-то стремно. Если хорошие идеи внедрять, но не доводить до ума на протяжении длительного времени - то лучше бы таких идей и не было. А то наобещают преимуществ с три короба - а потом оно даже базовых функций своих не выполняет, и то что раньше работало без проблем - теперь глючит безбожно. Как бы и с этим Journal такой петрушки не получилось. Рано или поздно все это допилят, но до этого оно успеет изнасиловать все дистрибутивы, включая debian stable.

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

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

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

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

> Как минимум rsyslog умеет хранить логи в БД. А поделка Потцринга - нет. Дальше что?

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

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

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

хехехе

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

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

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

> Ну вот, наконец-то - ты спрашиваешь вопросы, вместо нытья и детских подколок (типа «я не надеюсь на ответ, но все-таки»).

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

Грепать в файле, если он большой - очень долго

tail уже отменили?

затем вырабатывать какие-то скрипты, чтоб вытащить нужную инфу

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

выгоднее предварительно рассовать запись по базе

«Выгоднее» - это как? Записи в логе ещё нет, а данные о ней уже «рассовываются»? :)

насколько сложно записать, это не так и важно.

А чуть раньше ты, вроде, говорил, что это важно...

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

>> Как минимум rsyslog умеет хранить логи в БД. А поделка Потцринга - нет. Дальше что?

Там неправильно хранятся.

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

Суть-то в том, что ты все-равно манипулируешь текстом в свободном формате.

Ты уже готов определять стандартные форматы лог-мессаг? Всё сообщество уже готово следовать за тобой?

tailgunner ★★★★★
()

Дать дарованию в бубен и лишить талонов на Интернет пожизненно. Развелось, понимаешь, «улучшателей» классических *NIX'ов, как собак.

Rexy-Craxy
()
Ответ на: комментарий от Gorthauer

За что я люблю лор, так это за отборный и разнообразный бред.

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

> Как человек, закончивший сов. школу с побрякушкой, я хотел бы распечатать мнение этого неуча на рулоне туалетной бумаги.

+1

anonymous
()

Вроде, ещё классик сказал:

Store data in flat text files.

Каждый раз убеждаюсь в правильности этого принципа. А идея сделать лог бинарным чтобы злоумышленник не смог бы его редактировать - бредовая. Злоумышленник будет точно так же его редактировать, но только с помощью этого API, а пользователю/админу будет лишний геморрой. Это как с запретом на свободную продажу оружия: бандит в любом случае вооружён, а страдать будет законопослушный гражданин :) Если уж так нужно защитить лог, шифруй его на лету под отдельным паролем, а потом расшифровывай одной командой и никаких API-костылей городить не надо.

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

>Я винимательно жду от тебя предложения по форматированию следующих сообщений в принципиально более правильный формат.

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

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

Концепция journal полностью соответствует unix-way, проблемы?

А в возможности все это построить так как я хочу а не так как Леттарт задумал.

И именно поэтому ты хлопаешь крыльями и кудахтаешь с самого начала топика. Потому что не осилишь сделать по-своему, ты просто не заметил как за тебя уже решили эту проблему первый раз, правда во времена создания syslog. А теперь всего лишь решат во второй. Можешь кричать «Не бывать этому!», но паровоз поедет, и ему насрать будешь ли ты в вагоне.

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

глянь скрины логгера шиндовс -)

по сабжу, таблица с полями вроде:

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

итп

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

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

Я уж не знаю чья это проблема, но пульс нормально не умеет работать с emu10k с 5.1 в штатном режиме. Тем не менее я могу его настроить руками. Я высрал тонну кирпичей в их багзилле пару лет назад, с тех пор забил и Имею Мнение.

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

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

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

и написать нормальный поиск

зачем писать всякие индексы, SQL и репликацию самому, когда всё это уже изобретено в базках?

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

Я советскую школу без троек (совсем!) закончил, но это к теме спора не относится. :)

Пусть высказывает своё мнение, интересно же. Правда, он так и не нашёл весомых аргументов в пользу применения БД в логах. Пока неубедительно.

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

> И, кстати, да, иерархическое хранилище конфигов — это нормально

Конечно, нормально. Понадобилась иерархия - создай дерево каталогов с файлами.

Чудила, бинарные форматы глазами не почитаешь, грепом не попарсишь. Я посмотрю, как ты будешь читать бинарный лог сдохшей системы без чудо-библиотечки поттера.

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

И тебе «до свидания»! Хами дальше - у тебя это здорово получается.

OldFatMan
()

Так и надо. Нет поддержки сети, нет читабельных логов... Вообще нихрена нет. Здравая идея. Может тогда вообще нафиг логи - вон в венде народ просто систему переставляет.

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

вставка логов O(ln(N)), обновление индексов, лишнее занимаемое место, головная боль с созданием разделов таблиц, чтобы поиск был адекватный, требование иметь базу в почти любой системе. Офигенный набор... Необходимость иметь инструмент для поиска по базе, необходимость создания новых инструментов для преобразования данных..

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

> зачем писать всякие индексы, SQL и репликацию самому, когда всё это уже изобретено в базках?

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

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

Та никуда... просто на ноуте оно как-то с линухом веселее, а BSD у меня кургом на серваках лет так-эдак двести... И музыка, опять же... rosegarden, ardour ... Вот почему я поттеринга ненавижу больше всех! :)

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

> обновление индексов

индексы могут и нае*нуться.

anonymous
()

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

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

Ага, понятно.

Ну не во всех же дистрах эту поттеровскую фигню внедрят. Будет из чего выбрать. :)

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

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

qnikst ★★★★★
()

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

закопать вместе с systemd и пппппульшшшшшшшааааудиииио

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

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

Для логов не нужна транзакционность (только в редких случаях). Из лога не надо считать инфу через секунду после записи. Ау, лог - это ассиметричная система хранения информации, по большей части write-only.

На счет базы - ты можешь структурировать по пиду, юзеру, правам доступа, как угодно. Сделаешь стопицот колоночек. Но в конечном итоге у тебя все равно будет поле для хранения блоба - либо двоичных данных, специфичных для системы, либо текстового описания. Так вот, все это можно засунуть и в plain-text. При том на запись скорость будет выше. А базовый индекс на чтение уже есть - это время записи, в каждом логе оно есть.

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

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

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

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

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

Здравая идея там ровно одна - атрибуты. Никакие бинарные файлы для этого не нужны.

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

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

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

Так вот, я считаю, что plain text - самый лучший вариант. И патриарх подтвердил бы это! Вы - закоренелый виндузятник, которому нужно дать readonly доступ к святому святых - ЛОРу.

P.S. Обращаю внимание - я совершенно не ставил целью Вас оскорбить, любезный. Я просто выразил свое скромное мнение. За сим удаляюсь.

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

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

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

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

Боюсь, что многие будут со мной не согласны, но pulseaudio таки win.

Я с тобой полностью согласен, ибо ещё в 2006 году плакал кровавыми слезами из-за этой корявой алсы и вопрошал небо, почему на m$ вындовс уже 6 лет никаких проблем нет, чтобы пучёк разнообразного софта с одной самой примитивной звуковухой играл без проблем, а в «продвинутом» линуксе - это дикая попоболь. Вместо делания нормальной работы я потерял недели, ковыряясь в нескольких чужих библиотеках, чтобы заставить их выводить звук с разной частотой дискретизации и уровнем квантования через одно устройство. И запись ещё при этом чтобы работала, и два писателя могли звук захватывать.

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

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

он называется SQL. Всё уже придумано.

вставка логов со сложностью...


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

Но тогда потом ты ВНЕЗАПНО решишь в этой базе что-то найти, поиск займет времени как раз до пенсии (60 лет для мужчин?).

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

обновление индексов, головная боль с созданием разделов таблиц,


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

лишнее занимаемое место


лишнее занимаемое место на что? На индексы что ли? :) Ну разрастется на треть, кто это заметит?

требование иметь базу в почти любой системе.


apt-get install postgresql. Воистину сложно.

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

>> требование иметь базу в почти любой системе.

apt-get install postgresql. Воистину сложно.

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

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

Грепать в файле, если он большой - очень долго,

Правда?

> du -sh 2011_11_1*  
51M     2011_11_1
20M     2011_11_10
20M     2011_11_11
20M     2011_11_12
20M     2011_11_13
21M     2011_11_14
21M     2011_11_15
11M     2011_11_16
19M     2011_11_17
15M     2011_11_18
15M     2011_11_19

> cat 2011_11_1*/* | wc -l
1464293

> time cat 2011_11_1*/* | cut -f 1 | sort | uniq -c | grep -e "^[ ]\{4\}[^ ]" | cut -b 5,6,7 | (tr "\012" "+"; echo 0)  | bc
163652

real    0m6.279s
user    0m4.824s
sys     0m1.456s

Я внимательно слушаю тебя сколько у тебя займет ресурсов сделать подобный подвиг на sql базе. Не забудь сюда добавтить ее работу развертывание индексирование и т.д.

Главное - быстро получить результат, а насколько сложно записать, это не так и важно.

Мне правда смешно с ващих объемов. Чем больше индексов - тем дороже insert.

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

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

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