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

logviever --errors | grep ... | awk ... | sed ...

У вас однобокие представления о unix-way. Не только грепать иногда надо, да и это медленнее простого grep /var/log/mylog. А ещё например слияние разделение логов тоже может быть нужно. В итоге куча утилит или один монстр для обслуживания этого бинарного зоопарка, где можно было обойтись простейшими утилитами которые напишет даже школьник на бэйсике. К тому же враппер верхнего уровня придется внедрять выше api. Все преимущества в конечном итоге будут съедены стоимостью обслуживания. Большой интерпрайз немного поворчав так и останется на своих системах анализа и обслуживания логов в которых будут пилится бэкэнды к этому поттероделию. Небольшая нишевая прослойка порадуется. А остальным так и страдать.

Где написано, что формат не будет документирован (в итоге, после отладки)? В любом случае, остается возможность использовать библиотеку.

А где написано что будет? Библиотеку использовать где и для чего? На микроконтроллере её использовать? Библиотека это не плоский файл и даже не документированный бинарник.

Никакой помехозащищенности, малейшие ошибки на диске или в памяти проявятся потерей базы логов

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

Ага и где тогда будет хвалёная экономия и быстродействие? Лишние данные больше ошибок. Прекрасная замена «избыточности» текстового формата. Почитали бы уж что-нибудь общеобразовательное от апологетов юникс.

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

Почему он должен сломаться? Вы хоть суть вопроса поняли? Прикажите на микроконтроллер поттеротеку для обработки его болбов портировать? Уморили.

> И то и другое нужно только для старта системы

Вам объяснили, что 99% кода в этих скриптах - используется и в других местах. Все эти вызовы grep/sed/awk/mount/ionice/etc. Большая часть C кода systemd - специально написана для этого чуда. В сравнении с init получается примерно 50k строк vs 8k (причем последние - не только собственно сам init, но и всякие telinit, shutdown).

И эти 50k строк - не предел, т.к. у разработчика нет абсолютно никакой идеи чем _не должен_ заниматься systemd. Вот появится в ядре новая крутилка для ограничения процессов (как сейчас есть rlimit, приоритет/класс IO шедулера, etc) - попусту добавят какие-нибудь новые ублюдочные параметры в INI-файл.

При недоступности интернета какой-нибудь bind или openvpn может задержать загрузку системы на 10 минут, что я считаю недопустимым.

Пардон, зачем Вам bind/openvpn без интернета?

>Я так понял для каждого формата предлагается вводить свод UUID.

Во первых, вообще нет. И формата никакого тоже нет. Формат, это первый аргумент функции printf(). А предлагается прямо передавать все остальные аргументы этой функции как есть. В том числе uuid, если только он нужен.

Ничто не мешает создать по таблице для каждого UUID'a (самый тупой вариант, можно реализовать за пару дней)

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

> Очень напоминает ситуацию с дуалбутом винда-линукс.

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

> что?

Что «что?»? Тебе чтобы полтора приложения при входе в сеанс запустить, нужно дерево зависимостей?

> Вопрос остается прежним - НАФУЯ гвоздями-то прибивать?

А в чем проблема? Я не смогу больше собрать иксы без dbus-а? Или не смогу написать руками конфиг, чтобы оно его использовало вместо автоконфигуратора?

Не в курсе просто.

> Собственно говоря, это главное его преимущество. Он не столько пишет софт, сколько гениально его внедряет.

В условиях, когда этот софт — редкостное говно, это «преимущество» становится главной проблемой.

> При недоступности интернета какой-нибудь bind или openvpn может задержать загрузку системы на 10 минут, что я считаю недопустимым.

УМВР, ЧЯДНТ?

> Надеюсь я просто невнимательно прочитав не так понял истинного светоча мысли Поттеринга. Иначе страшно жить.

Ты всё правильно понял. Единственная реальная цель внедрения — вендор лок-ин.

> я слышал что ядро minix3 в разы тормознее линуксового несмотря на теоретическое превосходство

Академическая поделка же.

Вообще, декстопная система — это по своей сути система мягкого реального времени. Тут было бы хорошо грамотное, технологичное микроядро с планировщиком, использующим fixed priority scheduling для разделения разных классов задач (обработчики высокоприоритеных прерываний, обработчики низкоприоритетных прерываний, кричиные системные сервисы, приложения пользователя), earliest deadline first scheduling для задач внутри одного приоритета и с наследованием характеристик планирования через объекты синхронизации.

logviever --errors | grep ... | awk ... | sed ...

Супер, вместо cat /var/log/messages.log в пайпе будет поттеросмотрелка. Это просто кардинально меняет дело, да. Что характерно задача анализа, собственно, сообщений лога никуда не делась и никак не упростилась. Проще стало разве что выводить список записей за определенную дату или с определенной маркировкой, что, собственно, само по себе довольно бесполезно. Но зато теперь у нас есть мегагитлер-смотрелка логов. Просто супер, всю жизнь мечтал.
Впрочем, всё это уже говорили.

> Мне неловко говорить, но эти проблемы решены давно. Тебе LARGE_FILES что-нибудь говорит?

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

> Ты уже выкинул xorg?

С серверов - да. Давно.

толстый

> в 90% случаев самосборные ядра работают менее стабильно
надо же, какой толстый...кот

XML

> прекрасно подойдет xml
да, да. и прсматривать логи станет возможно только с помощью программ на жабе и решётке. тут-то конец света и настанет!

дампы

> в журнале будут не только строки, но и дампы
о, нет! всё смешалось в доме Облонских!
зачем?????

или гуй wxjournalviewer

ога, размеров в 100500 мб. самому-то не смешно?

сложнее переносить

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

а в лого молчок

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

Леннарт ...оставил

пока оставил

> Во первых, вообще нет. И формата никакого тоже нет. Формат, это первый аргумент функции printf()

К syslog-у? Классненая ДЫРЕНЬ для взлома!

Дайте ДВЕ!

redhat

> Замыкание на вендоре
ты знал! наверное это так и задумано новой корпорацией добра

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

P.S. Ну не всем же котегов на аватарах размещать.

>о, нет! всё смешалось в доме Облонских! зачем?????

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

ога, размеров в 100500 мб. самому-то не смешно?

хотя бы и так. Файрфокс большой, опенофис большой и никого это н останавливает. Обычный гуй весит 100к. Но если нужен гуй на 500 МБ, то в чем проблема, если сделают и такой?

ну скажи, вот зачем переносить индексы?8)

чтобы хранить историю в центральном хранилище.

либо ты целиком все файлы двигаешь - и тексты (данные, и индексы - тогда вообще проблем не вижу

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

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

Есть и другие тайны - 1) никто хомячков и не спрашивает. 2) спецу тоже нужна информация.

В текущем состоянии единственный универсальный способ понять, что там в логах - повторить проблемную ситуацию с tail -f /var/log/messages | grep XXX на другой консоли. Именно поэтому все так молятся на нахождение «воссоздаваемой последовательности» приводящей к проблеме.

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

>К syslog-у? Классненая ДЫРЕНЬ для взлома!

Эта дырень давно уже в сислоге. Там все делается по формату.

А в журнале как раз формата нет.

логи

>для демонов и модулей ядра это единственный ... способ
ДООО ;-)
тащемта принято обычно дампы валить в особое обученное место
тем более что по объёму дамп может быть очень большим - в отличие от лога

хранить историю

если ты собираешь инфу с нескольких мест в одно - тебе всё равно придётся пересоздавать индекс каждый раз=>нет profit

Файрфокс большой, опенофис большой

не будем говорить за всех
есть много мест, где все эти FF и OO никому не сплющились=>отсутствуют как класс
я уже промолчу про рутеры и прочие мелкие железки

спецу тоже нужна информация

спеца текстовые логи вполне устраивают

воссоздаваемой последовательности

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

логи раз в сутки

и снова не будем говорить за всех.;)
есть где и раз в минуту и раз в месяц или даже в год

> Эта дырень давно уже в сислоге. Там все делается по формату.

Одно дело - syslog(3).

Другое дело - формат записи конкретного бинарного журнала.

Вот если ТАМ дать возможность ДЕМОНУ жрать ФОРМАТ (в смысле первого аргумента printf) для создания журнала...

Это будет поимелово...

>Супер, вместо cat /var/log/messages.log в пайпе будет поттеросмотрелка. Это просто кардинально меняет дело, да.

почитайте статью. Это кардинально меняет дело.

Логи

1) чой-то мне не по себе

2) Ленина убили!

и

1) Ленина убили!

2) чой-то мне не по себе

это разные логи!

>Вот если ТАМ дать возможность ДЕМОНУ жрать ФОРМАТ (в смысле первого аргумента printf) для создания журнала...

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

Технических аргументов против этого «добра» - дофига и больше. Systemd, PulseAudio - дерьмецо еще то, но это «новшество» - просто шедевр.

Линух и так уже давно не UNIX, но после такого нововведдения ... Хоть я и тепреть на могу винду, но это будет хуже винды. Винда хоть более-менее стабильно более-менне работает, в отиличие от творений «гения» поттеринга.

systemd в 16-й федоре просто достал, блин что-то там такое наковыряли, что эта дрянь виснет где ей вздумается... И ваще 16-я - такое же дерьмо как 9-я, если не хуже. В кедах падает kded4 рандомно и половина всего перестает работать. Kmail испаганили...

Вывод: если в сообщетсве начали рулить придурки типа Леннарта и Аарона, надо или выгонять их, или сваливать нафиг самому.

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

>тащемта принято обычно дампы валить в особое обученное место

тащемта бывает и так. а если дамп маленький, то зачем? Особливо если писать некуда - корень только на чтение.

если ты собираешь инфу с нескольких мест в одно - тебе всё равно придётся пересоздавать индекс каждый раз=>нет profit

да вроде нет.

есть много мест, где все эти FF и OO никому не сплющились=>отсутствуют как класс я уже промолчу про рутеры и прочие мелкие железки

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

Ну держи vi, gedit, openoffice.

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

спеца текстовые логи вполне устраивают

меня не всегда. Я просто не могу себе позволить час собирать логи по архивам и грепать их. Так что анализ ситуации недельной давности для меня закрыт (хотя и возможен).

к тому же это стандартная практика не только в линуксе, но и в той же венде например

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

логи раз в сутки
и снова не будем говорить за всех.;)
есть где и раз в минуту и раз в месяц или даже в год

по дефолту логи сворачиваются раз в сутки.

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

журнал частично вытесняет оба варианта. «И это хорошо!» (С)

>systemd в 16-й федоре просто достал, блин что-то там такое наковыряли, что эта дрянь виснет где ей вздумается...

Поттеринг не был бы самим собой, если бы не подгадил с реализацией...

И ваще 16-я - такое же дерьмо как 9-я, если не хуже.

а здесь не соглашусь. мне она понравилась больше, чем 15.

> журнал частично вытесняет оба варианта

Еще не написан, но уже вытесняет.

> Народ, а чего спорите то??!!!!!! Не нравится - сделайте свой как считаете нужным, в чем проблема то??

Проблема всего лишь в том, что у нас у же есть сислог, который эффективно выполняет свои задачи, и никакие бинарные логи от Поттеринга нам не нужны. Но так как системд уже укоренился во многих дистрибах (и это зря), а поттероевентлог прибит гвоздями к системд имеем либо а) ШINDOШс-like eventlog в уютных линухах; б) нормальный человеческий сислог с нагрузкой в виде эвентлога, срущено непонятно зачем на мой диск. НЕ ХОТЕТ.

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

Вот и я про то - если ТАК журналировать, то как раз и наступит полный...

Т.е., если вызов syslog(3) с кривыми аргументами обваливает вызвавшего, то передача такого вызова в journald обвалит последнего. С присвоением, как результат, его привилегий.

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

И тогда Дебиан окажется самым вменяемым дистрибутивом

>Еще не написан, но уже вытесняет.

как концепция, да. А как реализация, не знаю.

>Т.е., если вызов syslog(3) с кривыми аргументами обваливает вызвавшего, то передача такого вызова в journald обвалит последнего. С присвоением, как результат, его привилегий.

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

>> Еще не написан, но уже вытесняет.

как концепция

Как концепция, всех вытесняет syslog с плагинами. Но у этой концепции есть фатальный недостаток - это придумал не Поцеринг.

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

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

Самое неприятное в том, что это падло и иже с ним в редхете ломают хорошо работающие вещи и засовывают вместо них свое непросохшее дерьмо.

dump

> а если дамп маленький
обычно как-то так:
-rw-r--r--   1 root     root     4166590464 Aug 26 10:52 vmcore.0
или так:
-rw-r--r--   1 root     root     6563037184 Sep  1 01:13 vmcore.0

ну откуда на рутере иксы

ты сказал. про FF и OO. не я. а в отличии от - syslog есть почти везде

час собирать логи по архивам

бггг. я наконец понял - вещества?8)

венда столь же ущербна

и ты на пару с пётирнгом тянешь на студа же, к «светлому будущему» с event log и DCOM.

по дефолту логи сворачиваются раз в сутки

OMG!

Для систем анализа

ты путаешь (смешиваешь) 2 совершенно разные вещи - сбор данных (логов) и обработка (анализ)

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

спасибо, я уже наелся кухонных комбайнов и МФУ!
в итоге ни одна из 2 частей этим комбайном сделана хорошо не будет!
про UNIX way - вообще молчу

>ты сказал. про FF и OO. не я. а в отличии от - syslog есть почти везде

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

и ты на пару с пётирнгом тянешь на студа же, к «светлому будущему» с event log и DCOM.

в венде все по другому.

ты путаешь (смешиваешь) 2 совершенно разные вещи - сбор данных (логов) и обработка (анализ)

логи без анализа бесполезны. Вопрос, где проходит водораздел между ними. tail -f /var/log/messages - тоже анализ, которые делается на основе данных сислога безо всякой предварительной обработки, так почему бы не сделать его чуть-чуть посильнее?

>Как концепция, всех вытесняет syslog с плагинами.

Что мешало реализовать все эти плагины раньше? сислогу уже 30 лет.

Ну разве линукс не предоставляет свободу выбора? Нельзя отрубить systemd и/или заменить его на upstart или другое решение. И тоже самое с сислогом.

>> Как концепция, всех вытесняет syslog с плагинами.

Что мешало реализовать все эти плагины раньше? сислогу уже 30 лет.

Какие «эти» и что мешает реализовать их как плагины _сейчас_, если они нужны? Как минимум rsyslog давно поддерживает плагины.

в 90% случаев самосборные ядра работают менее стабильно

надо же, какой толстый...кот

сухая статистика помноженная на здравый смысл

Боюсь, ты пребываешь в царстве своих иллюзий

^^^ Пример того, что лучше не писать в логах.

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

Зачем? Мы тут системными логами занимаемся, вообще-то, ты в курсе? Там нет бесконечного множества допустимых проблем!

размер

> я сказал, что сам по себе размер
понятно, слив засчитан.:-)

в венде все по другому.

да ну? а ещё -её марсиане пишут

логи без анализа бесполезны

вопрос очень спорный
ответ про tail - чистой воды слив

плагины сейчас

> то мешает реализовать их как плагины _сейчас_
+100500!

выбор

> линукс не предоставляет свободу выбора?
пока да, но с такими подходами он очень быстро превратится в УГ без выбора в mainstream и магриналами-слаквареводами

сборка

> сухая статистика помноженная на здравый смысл
давно так не смеялся ;-)
значит у нас - совершенно разная статистика и отличающейся здравый смысл

есть правда ещё вариант что вы выбирали ВСЕ звёздочки при сборке.;)

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

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

да, нужно

юзерское приложение может например полезть в dictd, который еще не запущен

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

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

хотя бы и так. Файрфокс большой, опенофис большой и никого это н останавливает. Обычный гуй весит 100к. Но если нужен гуй на 500 МБ, то в чем проблема, если сделают и такой?

Это никого не останавливает только тех кого не волнует. То есть хомяков. Покажите мне опенофис и фаерфокс на ведроидных телефонах. Что-то гугл не взял готовое, а пилил что поменьше.

В текущем состоянии единственный универсальный способ понять, что там в логах - повторить проблемную ситуацию с tail -f /var/log/messages | grep XXX на другой консоли. Именно поэтому все так молятся на нахождение «воссоздаваемой последовательности» приводящей к проблеме.

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

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

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