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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

Толсто.

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

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

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

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

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

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

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

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

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

regexp и sql

> написать запрос легче, чем регэксп
хорошо, жду анАлога вот этому:
The Journal: жизнь после syslog (комментарий)

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

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

Часто у вас на серверах проги в корку падают?

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

Не редко, к сожалению. Firebird, asterisk - глюкавое говно, к сожалению безальтернативное.

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

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 )

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

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

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

sprintf vs. fputs(isprint).

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

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

having nuisance

Кривой ... select...from ( SELECT...having...

можете дальше не продолжать. следующий!

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

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

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)

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

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

Останется

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

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

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

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

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

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

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

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

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

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

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

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

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

6) SELECT CLIENT_NAME from DNSMASQ_LOG...

asterisk

есть freeswitch, имхо постабильней.

но он тоже, бывает, падает.

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

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

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

/0.

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

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

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

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

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

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

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

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

6) SELECT CLIENT_NAME from DNSMASQ_LOG...

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

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

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

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

1) хост (localhost)

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

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

3)name (WINSERV)

4)class: (MSFT 5.0)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ln растет очень медленно. ln(4 миллиарда) - 32.