чтобы учится читать.

предпочитаю не спать чтобы дать пинка богу

И все же простительно иногда назвать локальную переменную в небольшой функции 'proverka', например. Мужик расслабился и захотел домашнего теплого уюта в коде, а тут сразу высмотрели и начали пальцем тыкать. Нехорошо =)

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

Скажи, ты долбоёб, да? Серверное приложение крутится в продакшене 7/24 и считает потоки денег. Каждые 2 недели выходит релиз с новыми функциями, и рефакторингом. В приложении куча разных модулей, которые обязаны писать в один лог, и новые модули добавляются. И ты весь в белом предлагаешь ЗАРАНЕЕ создать формат ВСЕХ сообщений? Ты правда долбоёб?

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

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

вся писечка в том, что формат фиксированный.

Засунь свою писечку себе в рот.

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

А вот и разгадка: парень с писечкой решил выкладывать entrprise решения в аппсторе! Ущербный леннарт вынес предложение для entrprise сектора и ему тут же начинаю подвывать недоумки с аппсторе: «я джва года ждал такой лог!». Нормальных людей, пишущих для аппсторе и не использующих БД для логов, прошу не нервничать.

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

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

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

Да твоюжбогадушумать! Вася из третьего класса способен писать запросы на кат, греп и сорт! А ты не можешь, потому что ты долбоёб!

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

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

Скорее всего ты и в сортир нормально ходить не умеешь, а прокладываешь маршрут с помощью запросов на SQL.

хватит репостить фэйковый вброс стива про БД тех кто пишет не читая ту и так дофига, ленарт в их числе, ок?

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

Бинарные логи, это крафне важная штука для Тру Энтерпрайза, т.к. копаться в 50 гигах логов за несколько часов в виде текстового файла не так прикольно, как делать запросы к базе.

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

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

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

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

Читая о PA что-то подобное вот этому:

[ненависти тред][gnome3][pulseaudio]Лучи ненависти разработчикам

Я начинаю сомневаться, действительно ли это хорошая вещь.

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

Кто-то сказал «rsyslog», «dsyslog»?

Мда... а теперь подумайте о двух вещах относительно хранения логов в БД: 1) когда должна стартовать БД, чтобы в нее логи писались? 2) как прочесть логи, если система не «взлетела» в штатном режиме?

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

Ключевое слово - 50 гигов

вот чем хороша слака, что там ни пульса, ни systemd, ни этого гавна не будет. вива Патрик.

> И как мне потом просматривать бинарные логи, спрашивается?

разделяемой библиотекой.

по-моему, это перегиб. ЛОГИ ДОЛЖНЫ БЫТЬ ТЕКСТОВЫЕ! это он потом btail и bgrep ваять будет?

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

Индекс меняется при каждой вставке. Принципиально - большая часть файла, много блоков ФС и метаданных.

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

>я агитирую за то, чтобы воткнуть в БД вообще Всё, а не только логи. Размер там будет, по крайней мере, в гигабайтах.

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

мда... ты нифига не понимаешь в базах данных, посему дальнейший диалог с тобой не имеет смысла

Вообще все-все-все в БД — это т.н. «single point of failure». Разок глюкнет базу данных, так вся система медным тазом накроется и будешь с компом тр@хаться, чтоб все это в рабочее состояние вернуть.

Хотя с учетом ника автора идеи «все в БД» удивляться нечему — маководы, они такие. :-)

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

• Нежелание зафиксировать формат журнала «на данном этапе». Если разработка ещё настолько сырая, то как можно её использовать в реальных системах?
• Принципиальное нежелание стандартизировать идентификаторы (UUID) ряда системных сообщений. Как прикажете работать, если разные реализации одной утилиты в разных системах будут использовать разные UUID?
• Жёсткая привязка к systemd

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

Ну можете и подождать - мы, пользователи, Fedora, выступим early >adopters (мы постоянно проверяем за вас опенсоурс новинки, это >нормально), проверим, чтоб все работало, а мэйнтейнеры ваших дистров >подберут уже готовое и отлаженное. Главное, чтоб они ничего не >попортили.

хорошо, что в gentoo хоть какая-то есть свобода выбора

>> bzcat /var/log/messages.0.bz2 | less

bzless /var/log/messages.0.bz2

Можешь не сомневаться - плохая.

>> возможно, unix-way устарел.

LOL.

>а тут раз - формат сменился, билиотека сменилась, и старая версия не берет новый формат, а новая версия - не понимает старый!
opensource во всей красе.

> Толку-то? Найдутся другие молодцы, которые таким же поттерингом займутся.

поттеринг — это разновидность троллинга? :)

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

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

:оверчеснок:

Такими темпами от Линукса скоро ничего хорошего не останется... бинарные форматы - он ниасилил текстовый файл парсить шоле? ;/ И куда дальше? Давай, певратим теперь хорошую ось в оффтопик. У этого психа что, аллергия на нормальные вещи? И да, пульсу выпилил первым делом после установки дистра;/

opensource во всей красе.

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

>> system X fault, writing log... log fault, wrong format...log fault log fault...fault...fault...fault...

http://rghost.ru/31503521/image.png

>> И еще - в этих ваших линуксах хоть одна подсистема бывает хоть какое-нибудь время стабильной и без революций?

syslog, например.

Как прикажете работать, если разные реализации одной утилиты в разных системах будут использовать разные UUID?

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

А вот теперь «А вот мы сделаем надежный журнал...» - угу. Если раньше я мог бросать выхлоп syslog по сети на другой хост, и при краше системы видеть эти логи до последней секунды жизни системы, то теперь мне предлагают использовать scp, в результате чего по построению есть временной лаг! А в онлайне журналировать на другой хост в systemd-journal нельзя по построению.

Типичный девелопер для мечты одмина локалхоста, что тут еще сказать

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

Где твои багрепорты?

>В каком месте он бинарный?

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

Файл лога двоичный. Обычный, индексированный по всем полям Db.

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

Лол, разумеется, именно поэтому логгер намертво впилен в init, который, в свою очередь, приклеен к шине IPC.

5. формат данных не имеет никакого значения в концепции unix-way.

«Философия UNIX гласит:

Пишите программы, которые делают что-то одно и делают это хорошо.

Пишите программы, которые бы работали вместе.

Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс».

>> а ядро несовместимым.

Так это же прекрасно! Пускай ищет другое ядро, а Linux оставит в покое.

Лол, разумеется, именно поэтому логгер намертво впилен в init, который, в свою очередь, приклеен к шине IPC

... которая реализован через DBus, который весь из себя XML...

> У него будет не база, а Бинарный Формат (ц)(тм)(р). Который будет как текстовый лог, только другой. Enjoy!

Просто он обнаружил у текстового лога фатальный недостаток. ;)

сходил на сайт Поттеринга, увидел видео, где он модерирует kernel-panel c участием Линуса, Алана Кокса и ещё 2х перцев, видимо Линус тоже хочет закопать линукс. пичаль.

Просто он обнаружил у текстового лога фатальный недостаток

Ага. Пользователь может работать с логом без утилит поттеринга! :-)

То есть теперь побаловаться в стиле «сделаю вместо файла логов пайп и повешу на него программку для обработки и складирования как я хочу» нельзя будет? Класс. В сочетании с системд и перезапуском сервисов вообще прелестно. Там как и в винде будет: сервис интеллектуальной фоновой загрузки, локатор удалённых вызовов и прочая поипень? И так же как в винде при остановке определённого сервиса фиг его запустишь, только через правку реестра.
Ну и нафиг такой линух нужен. Ещё пару лет такого движения и уйду на винду, благо лицензия есть. Спрашивается зачем нужен будет линух - такое кривое подобие винды, да ещё без кучи софта. Останется в кастрированном виде, типа пускалки виртуальных виндов из вмваре. Да и то с такими потугами впору в микрософтовую виртуализацию уйти.

Подписываюсь.

в этой реализации syslog нет поддержки протокола передачи syslog и вообще нет поддержки сети

Годные вещи неосилил.

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

Зато? Сказочный долбое% (С) «Даун Хаус»

Подписываюсь под каждым словом.

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

1. Спроектировать API для логгинга

2. Написать демон который этот API обслуживает

3. Ввести для демона плагины, в том числе плагин лога в текст и плагин лога в бинарник

4. PROFIT

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

Логгер не прибит гвоздями к systemd и может использоваться везде - в том числе на фряхах, солярисах, макосях и прочем.

Нет же, этот дятел даже подумать не может нормально...

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

Кстати да. Довелось недавно в логах семерочкочки поковыряться изрядно. Это ядрёная жесть. Ощущение, что попал в начало 90-х. 2011 год на дворе, алё.

> Хорошее слово подделия. Очень точное!

Лол. +1

Кусок из статьи (вырвано из контекста про UUID):

the 128bit ID that is used to identify “Sector bad on block device” should be the same regardless which device generates the message, or which driver. If userspace software needs to distinguish journal entries from different services, drivers or devices, it should use additional journal matches on the service/device/driver fields.

The nice thing about 128bit random IDs is that their namespace does not need to be managed. Everybody can just pull a random UUID out of /proc/sys/kernel/random/uuid, and it is his. Developers can generate as many UUIDs as they need without having to ask any central entity. UUIDs allow us to have a common namespace without any bureaucracy.

Т.е. нам предлагается использовать, как в венде для компонентов COM, UUID (вместо нормально читаемых строк в виде названия компонента с версией) для идентификации типа сообщения.

Все помнят, как в венде вылазят сообщения об ошибках:

Ошибка #018e::39fe

Посоны, мочи его!!!

>pulseaudio таки win.

Искренне интересуюсь, что сделать, чтобы pulseaudio заработал с наушниками в моём ноутбуке? Уже больше 2 лет висит баг в ланчпаде.

>Спасибо за перевод!

Всегда пожалста!

Нежелание зафиксировать формат журнала «на данном этапе». Если разработка ещё настолько сырая, то как можно её использовать в реальных системах?

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

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

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

Принципиальное нежелание стандартизировать идентификаторы (UUID) ряда системных сообщений. Как прикажете работать, если разные реализации одной утилиты в разных системах будут использовать разные UUID?

В этом нет необходимостио. Уникален не UUID, а связка сервис-UUID. Так то если разные реализации одной и той же службы используют разные UUID или если разные службы используют один UUID - это не страшно, потому что в любом случае после фильтрации по службе ты получишь внутренне непртиворечивые UUID-ы одной службы.

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

Жёсткая привязка к systemd

На это тоже есть причина. Необходимо обеспечивать логирование всего и с самого начала, то есть сразу после биоса или с момента старта UEFI. А значит необходима теснейшая интеграция в менеджер загрузки. Так куда предложите интегрировать его, кроме как в systemd?

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

прочитал перевод статьи. выводы для себя сделал такие:
- да, у syslog есть проблемы архитектурного плана, которые трудно или даже невозможно преодолеть частичным дописыванием/расширением кода;
- да, у syslog есть проблемы с верификацией источника; так же есть проблемы с раздачей содержимого в зависимости от привилегий пользователя;
- да, у syslog есть _особенности_ в части организации работы с логами (нет единого стандарта записи).
при этом некоторые моменты весьма спорны (трудно согласиться с тем, что в syslog нельзя поместить двоичные данные - почему-то сразу думается о base64).
и да - сложилось впечатление, что можно было и переписать сервис логгирования с нуля.

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

где внятная цель у всего этого? цели надо декларировать. если цель - создание единого программного интерфейса для взаимодействия с сервисами логгирования (где и решались бы задачи аутентификации источника, например), то так и надо делать. делать библиотеку, где объявлены функции работы с системным логом. API надо делать.
а вот уже за кулисами этого API можно уже и бинарные логи прикручивать, и текстовые, и XML и СУБД и что угодно. вот почему это не так - мне непонятно.

unix-way поттерингу непонятен, видимо.

>Т.е. нам предлагается использовать, как в венде для компонентов COM, UUID (вместо нормально читаемых строк в виде названия компонента с версией) для идентификации типа сообщения.

А можно узнать, на каком языке будут эти строки? И как их локализовывать?

И что делать, если Поттеринг, как тут написали на первых страницах, написал в качестве идентификатора слово «trenslate», а не «translate» и поэтому каждый раз, когда вы это видите, вас терзает жестокий баттхерт? Менять идентификаторы? Да в каждом проекте раз в полгода штормит из за того, что в оередной раз тупо пееименовали пару переменных, потому что разрабы осознали, что так будет «красивше».

И таки да, для системы реального времени с большим журналом на пару сотен хостов есть большая разница, вести и использовать индекс по varchar или по char[128]