> Вам надо книги писать. И перевод хороший.

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

ты неграмотен. Принципиально более правильное как раз простой текстовый файл. Читай классиков, неуч.

>Вообще структура логов как таковых полностью соответствует законам реляционной алгебры

facepalm.sql

но только для каждой строчки нужно распарсать две даты, которые в них содержатся, из второй вычесть первую и распечатать на экран

Т.е. ты хочешь сказать, что вот это вот что ты написал на SQL будет сделать проще?

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

>>Лучше Oracle. Ынтерпрайзно же! И сделать туда вывод early_printk/dmesg!

и вообще отказаться от понятия файловой системы и все хранить в базе. wait... oh shi~

> Чем это отличается от посыпавшегося текстовика?

Блин, возьми hex-редактор и покоцай текстовик и бинарный файлы базы данных в random-mode. Если и после этого будет непонятно...

Текстовый файл сыпется вместе с файловой системой или диском. Вероятность первого сильно ниже, чем вероятность осыпания индексов в DB.

>Но мне интересно, почему ты считаешь нормальным такой зазор - три с половиной задачи в текстовый файл, а затем сразу какой-то датамайнинг на кластере?

Потому что как ни странно но косить узкие вырезки для локальных неопределенных задач руками проще и быстрее. Вон там сверху пример. Чтобы заменить эту строчку на SQL это целый неделедевелоперсолюшен нужен. У меня заняло 3 минуты и еще 6 сек на обсчет.

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

Чем проще система, тем меньше вероятность того, что она сломается. База может посыпаться из-за косячной памяти например.

aRts был в KDE 3 и перестал быть актуален с тех пор, как ALSA пришёл на смену OSS, то есть лет 10 назад. Его основная задача, как и задача ESD (умершего буквально недавно в пришествием Gnome 3), была совместить несколько потоков аудиоприложений в один аудиовыход. Остальное было второстепенно. Всё, ALSA есть, есть в ядре, и ничего больше не надо, кроме разве что нового OSS.

>Предлагаю тот же тест, но только для каждой строчки нужно распарсать две даты, которые в них содержатся, из второй вычесть первую и распечатать на экран.
Не Ъ. Нужно еще отправить результат на email.

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

То есть представить этот набор лично ты не можешь слишком сложная задача? Thats exactly my point.

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

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

ты просто не заметил как за тебя уже решили эту проблему первый раз,

Ниче за меня не решили. Как решили видно по вендовому администрированию - на это без рыдания смотреть нельзя.

Жизнь после смерти.

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

Ну, покажи

> Нет слов! Отпустите мужика макос курочить, отстаньте от линукса!

В макос его не пустят. Там УЖЕ сделали то, о чем он талдычит, только грамотно.

Например, логи там текстовые. Вполне нормальный syslog. Если бы альтернатива была так уж нужна, они бы разве за добрых два десятка лет (считаем вместе с NeXT) не сделали? Но почему-то не делают.

Да, конфиги в launchd в XML, но это не проблема. Там ключи предсказуемо называются и предсказуемый же дают результат. Я бы вообще говорил, что портануть launchd на линукс, и это была бы вменяемая альтернатива init'у.

У кого там тоглстый Ынтырпрайз?

Кто там с жирным толстым Ынтырпрайзом? Запайпить хвост лога на свой примитивный парсер и толкать его в базу самому слабо? Или ума не хватает на перле за 10 мнут написать такую прогу и не морочить людям голову?

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

При чем корку еще и Abort сожрет, падла. Который в свою очередь в корку выпадет. Во жисть будет интересная!

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

и чём это будет лучше поиска по текстовому файлу?

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

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

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

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

Именно по этому в главам про partitions и разденения таблиц на основе наследования посвящено немалые куски мануалов. И поиск O(ln(N)), вместо адекватного, естественно это круто..

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

индексы, логи, бинарные логи... 10Tб 13Тб какая разница...

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

1). что такое apt-get 2). мой роутер прямо так и мечтает о том, чтобы на нём стоят postgres, так же как и кастомная железка.

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

Т.е. БД вводит кучу лишних проблем, хочется БД, делайте плагин к syslog, и всем будет счастье.

нет, не троллю

одна из самых заветных мечт — выкинуть нафиг разнородные форматы, и загнать всю (вообще всю какая есть!) инфу в базу с поиском на чем-то вроде SQL

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

А давайте всем ЛОРом скинемся на киллера.

+1 адназначна. Лучше бы доделывали alsa/jack. Про systemd молчу - с ним система у меня грузится раза в три дольше чем с init. Массовое помутнение что-ли к 12му году? Гном3... бинарные логи.... Ждём /etc в виде system.dat плин.

Грепать по логу стоит O(n), создавать запросы к базе, в которой все уже отсортировано по строчкам и колонкам - гораздо дешевле.

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

И потом, если у меня лог не 50 гигов, а 2 мега, то я, конечно, просмотрю его на 100 миллисекунд быстрее, но за это я должен буду отказаться от своего любимого вьюера и использовать чьи-то костыли.

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

...и одновременно родилось бы ровно столько же

SQL головного мозга.

Извините.

> Как решили видно по вендовому администрированию - на это без рыдания смотреть нельзя.

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

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

>код события (централизованный)

Я в просто в экстазе. У вас событие 46734. Радуйтесь!

текстовый контент (примечания)

Да неужто?

Почему в этом логе нет инфы что же собственно произошло - когда, кто, как, но не _что_. В качестве «что» мне подсовывают код события. А знаешь куда я предлагаю пойти пацанам которые в 21 веке предлагают мне шарится по списку кодов события сравнивая их с различными манами кодов события чтобы понять что это, но не понятно к чему это? Банальный file not found /var/x/z в таком логгере не отформатируешь - слишком много информации, в примечание придется записать.

Я просто плачу: http://www.opossumsoft.com/images/screenshots/big/139335_main.jpg

А что именно произошло написано в обычном неструктурированном тестовом поле. Ага - да - «отформатировали». Черезжопный доступ устроили и все.

линуксокапец

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

> одна из самых заветных мечт — выкинуть нафиг разнородные форматы, и загнать всю (вообще всю какая есть!) инфу в базу с поиском на чем-то вроде SQL

Серебряных пуль, увы, нет, как нет и абсолютно универсальных инструментов.

А линукс хорош именно тем, что он «ящик с инструментами», а не громоздкий «кухонный комбайн».

Вообще структура логов как таковых полностью соответствует законам реляционной алгебры, и ВНЕЗАПНО для таких структур данных были специально разработаны базы данных!

ты и в базах данных не шаришь.

Скорее, Google головного мозга. Имхо это хорошо.

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

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

А где он найдёт весомые аргументы, коли нет их в природе? Использование БД в логах, наверное, было бы возможно в качестве узкоспециального применения для каких-то случаев. И, если бы «Journal» пилили как отдельную фичу, то и протестовать не имело бы смысла: авось пригодится. Вот пилят же btrfs, некоторые, как Э. Шишкин, её резко критикуют, но ведь никто же не пихает btrfs в качестве основной и единственной линуксовой ФС! Поэтому она потихоньку допиливается, и, вероятно, найдёт своё применение на специальных задачах.

А поттер опупел: сперва навязал всем пульс, который реально нужен 1% пользователей, теперь systemd впендюривает, так ещё логи решил поломать.

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

Это неплохо, конечно, но к логам не имеет отношения :-)

Так это не поцеринг впендюривает. Это неадекваты соскучились по десктопу XXI века

>А если анализировать структурно и парсить каждую строчку - поседеешь.

В этой строчке - вполне нетривиальные структурные трансформации - посмотри внимательнее. На SQL так не выпендришься.

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

То есть анализ логв за 1 + 10-19 числа, вырезать первое поле, отсортировать, трансформаировать в таблицу вида count(x),x, найти трехзначные каунты и сложить их все - тебе мало? Хочу видеть это на sql в цвете и со звуком.

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

А вот здесь я с тобой полностью согласен. Сам пытаюсь кое-что пилить в этом направлении...

>Т.е. ты хочешь сказать, что вот это вот что ты написал на SQL будет сделать проще?

А главное быстрее и b-деревья тут помогут просто немеряно.

> Ждем копипасты!
http://www.linuxquestions.org/questions/slackware-14/slackware-and-systemd-88...

Здравая идея там - стандартизация бардака. А вот то, что её можно было бы сделать и в рамках текстового формата - это верно.

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

Ага, одна кнопка посреди экрана: «Хочу чтоб было за*бись!» - и тебе впрыскивают наркотик. Вуаля! Интерфейс будущего, ага.

ещё sphinx ко всему прочему добавить надо, чтобы летало выше.

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

Скажите, пожалуйста, каким именно местом неотключаемое поделие, намертво приколоченное к другому поделию, без поддержки сети, да еще и с бинарным форматом данных, соответствует unix-way?

>Кто там с жирным толстым Ынтырпрайзом? Запайпить хвост лога на свой примитивный парсер и толкать его в базу самому слабо?

У меня:) Зуб даю - не нужно это.

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

Зачем так сложно? SQLite же! Нет лишнего демона, один простой файл, одна маленькая библиотека к нему, есть индексы, есть полнотекстовый поиск.

Слов просто нет... ни один реальный сисадмин, не винодовый дро..ла, а сисадмин, не захочет логов в базе или еще какого-то бинарного дерьма. Логи - не для просмотра в красивых окошках, логи - инструмент анализа работы системы. И для сисадмина гораздо удобнее текстовый файл + Perl или попросту grep, чем SQL. Еще раз - кому хочеться в SQL:

«tail -f /var/log/messages | my_idiotic_parser_and_db_inserter»

Если у меня отнимут возможность

«tail -f /var/log/messages | grep мое_рег_выражение», я снесу такое г...но сразу же. Потому что это не *NIX, а винда.

> У меня:) Зуб даю - не нужно это.

У меня тоже. Максимум - графики порисовать раз в неделю. База нафиг не нужна.

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

Т.е. вместо парсанья строчки «фигзнаетчтоздесьнаписано», есть таблица вида:

дата_события
сабжевая_дата_1
сабжевая_дата_2

запрос можно составить даже на естественном языке, «из журнала „ерунда“ для каждой строчки вывести на экран сабжевая_дата_2 минус сабжевая_дата_1».

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

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

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

Пульс нравится, бинарные логи — нет.