LINUX.ORG.RU

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

 , ,


1

3

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

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

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

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

★★★★★

Проверено: timur_dav ()

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

Да-да, тебя комментарий про чайников тоже касается=) Кроме hello world'а, который успел послать в syslog ты, есть разные задачи. В твоей любимой книжке, которую ты привёл, такого не пишут.

дампам не место в логере. в нормальных системах они просто связаны uuid

и что же здесь нормального, раз уж зашла речь о дампах?

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

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

toon ()
Ответ на: комментарий от farafonoff

> Линукс был единственной свободной ОС, и ему потребовалось 20 лет чтобы перейти от версии 0.1 к более менее пригодной. Думаешь с хурдом получится быстрее?

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

Я вот вспоминаю ASPLinux 10-летней давности - у меня к собственно линуксовому ядру претензий уже тогда не было, разве только по части оборудования (но то оборудование, которое у меня было тогда, поддерживалось хорошо). Были претензии к кедам, к mc, к wine (ибо всё равно попадаются виндовые программы). Всё перечисленное сейчас ушло очень далеко и с хурдом, думаю, будет работать замечательно.

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

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

А так не быстрее будет?

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

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

>А так не быстрее будет?

Так не будет работать.

sort | uniq -c выводит количество повторений уникальных строк, а sort -u просто уникальные отсортированные.

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

Меня прёт, как раздуваются чайники

Не осилил? Бывает, попробуй ещё раз через полгодика.

Толсто.

Ага, минимум треть

Я и говорю --- мизер.

где могут быть нужны бинарные данные.

Очень мало где. Т.е. почти нигде за исключением очень частных случаев.

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

68% работает через 10 лет разработки - это нет проблем? Пригодность для десктопа ограничена драйверами, а к хурду прилепляют соплями линуксовые драйвера.

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

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

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

>Очень мало где. Т.е. почти нигде за исключением очень частных случаев.

никто не заставляет слать блобы в журнал.

Просто он (декларативно!) закрывает необходимость в логгере, в том числе, в логгере бинарных данных.

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

никто не заставляет слать блобы в журнал.

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

ugoday ★★★★★ ()

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

qnikst ★★★★★ ()
Ответ на: regexp и sql от mumpster

Кривой пример, но тем не менее.

select sum(counts) from ( SELECT COUNT(THIRD_FIELD) as counts,THIRD_FIELD from LOG where day(DATE)=1 or day(DATE) between 10 and 19 group by THIRD_FIELD having COUNT(THIRD_FIELD)>100 )

И не похоже на результат работы обфускатора.

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

Особенно удобно будет искать песни или картинки. Хочу песню «лалала» в амароке.

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

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

sprintf vs. fputs(isprint).

размер буфера, ошибки в sprintf, ошибки в форматировании...

Разница просто до омерзения огромна.

sergv ()
Ответ на: having nuisance от mumpster

Я бы сказал про tr ... \012 ... , но не буду. Ваш пример 5 раз перекачивает весь файл через временные файлы/оперативную память, а пример с sql срабатывает за один проход по индексам. на паре миллионов записей sql сработает за 100-200 мс, а скрипт будет работать несколько минут (если не часов).

farafonoff ★★ ()
Ответ на: having nuisance от mumpster

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

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

Nov 28 12:20:16 localhost dnsmasq-dhcp[1781]: 1017028219 client provides name: WINSERV Nov 28 12:20:16 localhost dnsmasq-dhcp[1781]: 1017028219 vendor class: MSFT 5.0 Nov 28 12:20:16 localhost dnsmasq-dhcp[1781]: 1017028219 user class: RRAS.Microsoft Nov 28 12:21:00 localhost dnsmasq-dhcp[1781]: 4149981684 available DHCP subnet: 192.168.0.0/255.255.255.0 Nov 28 12:21:00 localhost dnsmasq-dhcp[1781]: 4149981684 available DHCP subnet: 192.168.0.0/255.255.255.0 Nov 28 12:21:00 localhost dnsmasq-dhcp[1781]: 4149981684 vendor class: MSFT 5.0 Nov 28 12:21:05 localhost dnsmasq-dhcp[1781]: 2041821640 available DHCP subnet: 192.168.0.0/255.255.255.0 Nov 28 12:21:05 localhost dnsmasq-dhcp[1781]: 2041821640 available DHCP subnet: 192.168.0.0/255.255.255.0 Nov 28 12:21:05 localhost dnsmasq-dhcp[1781]: 2041821640 client provides name: disp2 Nov 28 12:21:05 localhost dnsmasq-dhcp[1781]: 2041821640 vendor class: MSFT 5.0

Это разве эффективный формат лога? запись про одного клиента пишется в 3 строчки, с кучей лишних слов вроде client provides name. Был бы лог бинарным, ip адрес ужался бы до 4х байт, а сообщение свелось бы к кортежу (disp2, MSFT 5.0)

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

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

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

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

Останется

(123456789,localhost,dnsmasq-dhcp,1781,disp2,MSFT 5.0)

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

хорошо, поехали дальше:

1). этот кортеж не эквивалентен приведённому выше логу (там конечно мешанина, но уже очевидно, что части данных тут нет)

2). в каких типах хранится каждое значение

3). все кортежи такого типа?

4). как будет выглядеть вызов syslog из программы?

5). вы уверены, что все строки по которым вы формируете кортеж пишутся из одного места в программе?

6). как мне сделать grep «client privides name»

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

1) Все важные я взял. Убрал какое-то непонятное число, значения которого я не понимаю (а значит оно для меня все равно бесполезно)

2) Для дат, чисел, ип-адресов - свои бинарные типы, для строк - строки.

3) Все кортежи типа dnsmasq_log

4) Самое сложное. К сожалению в убогом недоязычке C нету типизации для параметров переменной длины. Рискну предположить, что можно собирать такие вещи в строки на подобие SQL INSERT через sprintf

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

6) SELECT CLIENT_NAME from DNSMASQ_LOG...

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

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

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

Да я забыл, вы за sql или просто за бинарный лог?

1) Все важные я взял. Убрал какое-то непонятное число, значения которого я не понимаю (а значит оно для меня все равно бесполезно)

/0.

2) Для дат, чисел, ип-адресов - свои бинарные типы, для строк - строки.

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

3) Все кортежи типа dnsmasq_log

т.е. для каждой! программы кол-во таблиц равно количеству типов сообщений? да ещё и небось с индексами...

4) Самое сложное. К сожалению в убогом недоязычке C нету типизации для параметров переменной длины. Рискну предположить, что можно собирать такие вещи в строки на подобие SQL INSERT через sprintf

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

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

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

6) SELECT CLIENT_NAME from DNSMASQ_LOG...

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

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

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

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

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

1) хост (localhost)

2) програма (dnsmasq-dhcp)

И локальные для серсиса.

3)name (WINSERV)

4)class: (MSFT 5.0)

И никакого сжатия.

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

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

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

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

т.е. для каждой! программы кол-во таблиц равно количеству типов сообщений? да ещё и небось с индексами...

с какой стати?

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

зачем? программа, наоборот, будет генерить куда меньше. в минимуме, просто сообщение об ошибке. А в максимуме тип сообщения, строка ошибки и набор пар имя -значение.

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

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

зачем? и какие таблицы, когда она только одна?

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

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

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

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

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

с какой стати?

а ты читал, что farafonoff предложил?

зачем? программа, наоборот, будет генерить куда меньше. в минимуме, просто сообщение об ошибке. А в максимуме тип сообщения, строка ошибки и набор пар имя -значение.

см. предыдущий пункт.

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

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

зачем? и какие таблицы, когда она только одна?

структуру таблицы в студию. Да, ещё раз повторюсь, что лучше читать более, чем 1 комментарий в ветке разговора

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

Документация на логи - отдельная печаль. Если заставить программеров ее документировать и описывать - всем будет только лучше.

Нет, только для самых популярных (даты, ип-адреса). Их все равно использует каждая первая программа.

Это можно на выбор программиста оставить. Можно часть сообщений хранить как строки, а самые частые - в отдельных таблицах.

Контекст нужен _особенно_ если произошла ошибка.

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

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

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

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

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

Какие либо вопросы по этим пунктам есть?

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

Это можно на выбор программиста оставить. Можно часть сообщений хранить как строки, а самые частые - в отдельных таблицах.

так это ж совсем грустно получается.

Контекст нужен _особенно_ если произошла ошибка.

и ломать модульность программ.

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

верно боишься.

зачем всё это когда все инструменты уже есть? и инструмент передачи в лог _любых_ данных и модули к rsyslog позволяющие обрабатывать поступающие данные и класть и в БД в нужной структуре. и куча утилит работающих с текстовыми логами.

Т.е. понятно, что развиваться надо и возможно, можно улучшить данную ситуацию, но развитие должно быть другим. Сидел бы поттеринг спокойно в RH пилил бы программу, и потом _когда_ она будет готова, доказывал, что она нужна. Но к сожалению, благодаря весомости RH ситуация несколько иная.

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

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

ну так в прототипе так и делается. иди в git и смотри.

я вот утверждаю, что создание словарей

Это один запрос по индексу на каждый словарь.

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

А во сколько раз глобальные словари повысят надежность хранения логов?

ни во сколько. Они ее не изменят.

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

есть разные задачи.

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

и что же здесь нормального, раз уж зашла речь о дампах?

например, то что их можно держать на другом разделе|носителе.

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

Принцип опенсорса - выкидывать неработающие поделки в паблик. «Сидел бы торвальдс в свом подвале, пилил свой линупс 0.0.1».

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

Логи работающие только на запись - бесполезные логи. Чтобы логи были эффективным полезным инструментом их надо читать. Почему-то к большому количеству программ есть плагины для записи логов в mysql.

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

не тупи. и не делай вид, будто syslog не умеет работать с mysql _сейчас_

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

ты ошибаешься и с принципами opensource. И ситуация с товальдсом тоже весьма иная была.

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

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

И я буду говорить, что в rsyslog и так всё есть, а все утверждающие что поттерлог хорош его не осилили.

Это один запрос по индексу на каждый словарь.

k*O(lnN), где k - кол-во слов в логе, а N - кол-во слов в словаре и это на каждое сообщение как при записи, так и при чтении. Тебе всё ещё не кажется, что это _тебе_ нужно доказывать мне, что предлагаемый метод эффективен?

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