форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
Сообщение от opennews (??) on 02-Мрт-12, 14:25
Две недели назад компания Red Hat собрала в своем офисе разработчиков популярных систем ведения логов, чтобы обсудить перспективы системы журналирования Linux и возможности последующего совершенствования уже устаревшей системы syslog. В результате обсуждения, в котором приняли участие Steve Gibbs (auditd), Lennart Poettering (systemd, journald), Rainer Gerhards (rsyslog), William Heinbockel (CEE, Mitre), а также несколько сотрудников компании Red Hat, родился проект Lumberjack (https://fedorahosted.org/lumberjack/), в рамках которого будет вестись работа по совершенствованию компонентов Linux-дистрибутивов, так или иначе связанных с журналированием системных событий. В ходе встречи участники обсудили такие слабые места текущих подходов к ведению журнала событий как недостаточное внимание к журналированию со стороны разработчиков приложений, разнообразие форматов журнальных записей и отсутствие взаимосвязей между журнальными записями различных приложений. Чтобы улучшить сложившуюся ... URL: http://bazsi.blogs.balabit.com/2012/02/project-lumberjack-to.../ Новость: https://www.opennet.ru/opennews/art.shtml?num=33246
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+8 +/–
Сообщение от Аноним (??) on 02-Мрт-12, 14:25
Судя по неоднократному упоминанию "структурированных данных", основной формат хранения логов будет бинарным. Ну наконец-то и линукс дошел до того, что в юниксе сделано уже двадцать лет назад.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+7 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 14:34
	А чем бинарный формат принципиально лучше текстового? Индексы и по текстовым строкам прекрасно делаются, сами журнальные записи тоже текстовые
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	18. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+8 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 14:53
	> А чем бинарный формат принципиально лучше текстового? Индексы и по текстовым строкам > прекрасно делаются, сами журнальные записи тоже текстовые Основных причины две: 1. Недостаточная компактность. Особенно неприятно отсутствие возможности дедупликации повторяющихся данных (например, имя хоста). Соответственно, это сильно замедляет хранение, поиск и обработку. В частности, именно поэтому наиболее нагруженные лог-системы (в частности, юниксовый аудит) работают исключительно с бинарными логами. 2. Неструктурированность. Опять же сильно затрудняет обработку и поиск данных. Кроме того, порождает кучу проблем совместимости - добавление нового поля в структуру не ломает существующие анализаторы логов, в отличие от изменения форматной строки.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	30. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–4 +/–
	Сообщение от anonymous (??) on 02-Мрт-12, 15:05
	> Основных причины две: > 1. Недостаточная компактность. Особенно неприятно отсутствие возможности дедупликации > повторяющихся данных (например, имя хоста). Соответственно, это сильно замедляет хранение, > поиск и обработку. В частности, именно поэтому наиболее нагруженные лог-системы (в > частности, юниксовый аудит) работают исключительно с бинарными логами. Это попытка переизобрести gzip? > 2. Неструктурированность. Опять же сильно затрудняет обработку и поиск данных. Кроме того, > порождает кучу проблем совместимости - добавление нового поля в структуру не > ломает существующие анализаторы логов, в отличие от изменения форматной строки. Феерический бред.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	37. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+4 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 15:11
	> Это попытка переизобрести gzip? В какой-то степени. Но только такой gzip, который позволяет работать сразу со сжатым файлом, и при этом не замедляет доступ, а ускоряет его (за счет индекса). > Феерический бред. Да неужели? Вот, например, в приводимых вами ссылках автор rsyslog жалуется, что поддержка тайм-зоны в его rsyslog давно есть, но включить ее нельзя, потому что она сломает все существующие анализаторы логов. Со структурированными данными при стабильном API такой проблемы нет в принципе.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	46. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–5 +/–
	Сообщение от anonymous (??) on 02-Мрт-12, 15:22
	>> Это попытка переизобрести gzip? > В какой-то степени. Но только такой gzip, который позволяет работать сразу со > сжатым файлом, и при этом не замедляет доступ, а ускоряет его > (за счет индекса). Кто мешает пожать и проиндексировать текстовый файл? > Да неужели? Вот, например, в приводимых вами ссылках автор rsyslog жалуется, что > поддержка тайм-зоны в его rsyslog давно есть, но включить ее нельзя, > потому что она сломает все существующие анализаторы логов. > Со структурированными данными при стабильном API такой проблемы нет в принципе. Где ты увидел стабильный API, если количество полей и их содержимое меняется? Всё равно переписывать придётся. Впрочем, пока даже формат этого бинаря не документирован.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	50. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 15:45
	> Где ты увидел стабильный API, если количество полей и их содержимое меняется? Если поля не удаляются, а только добавляются новые, то, по идее, старые анализаторы это не должно ломать.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	58. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–3 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 16:16
	Ага, щаз. Ты представление-то имеешь, как парсеры работают?
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	68. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 16:37
	Нет :) Речь шла о структурированном логе со специальным API для работы с ним. Если через API из записи можно извлечь отдельные поля, указав их имя, то на добавление новых полей, неизвестных парсеру, ему будет фиолетово. В текстовом виде это тоже реализуется, если журнальные записи имеют вид timestamp: field1=value1 field2=value2 ... - переставляй поля как угодно, и правильно написанный парсер вытащит нужные ему данные
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	69. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Wolfis on 02-Мрт-12, 16:38
	Структурированные данные,  индексируемые данные, множества данных. Если кто не понял, то это  пахнет СУБД, а SQL скажем не пострадает при добавлении поля, запрос не изменится.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	102. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 19:24
	Ну допустим я имею, ламерок. Для тех кто в танке: что сломается в SQL при добавлении колонки? Что сломается в XML при добавлении элемента? Что сломается в protocol buffer при добавленнии поля? Что сломается в наколеночном бинарном формате <число полей> ( <длина поля> <данные поля> ) {число полей раз} при добавлении поля? Ответ: ничего. Иди доучивайся.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	107. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+4 +/–
	Сообщение от XoRe (ok) on 02-Мрт-12, 22:07
	> Что сломается в XML при добавлении элемента? В этой теме про него лучше не вспоминать. А то, знаете как... помянешь черта и он появится)
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	136. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 03-Мрт-12, 04:02
	> А то, знаете как... помянешь черта и он появится) OSMщики с XML уже наелись, как стали портянги в 250 гигз, которые в бинарном формате всего 14, так они и удрали резко на эффективный бинарный формат. Потому что XML на 250 гигз - это полная гопа.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	148. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Имя и код on 03-Мрт-12, 06:07
	> Ну допустим я имею, ламерок. Для тех кто в танке: что сломается > в SQL при добавлении колонки? Это типа каждый раз альтер тейбл, который, конечно же, вовсе не накладная операция и мы, есесно, не упрёмся в, скажем, какойнидь ора-1631? > Ответ: ничего. Иди доучивайся. Да, всё верно: иди, дофапывай эту свою м-м-м.. науку...
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	233. "Представлен проект Lumberjack, нацеленный на..."	+/–
	Сообщение от arisu (ok) on 06-Мрт-12, 04:43
	а что сломается в парзере, например, «по строке на запись, поля поделены одним табом» при добавлении поля? если, конечно, автор не портвейн в подворотне пил, а знает, сколько полей ему надо? правильно, тоже ничего. при этом нормальные логи всё-таки остаются человекочитаемыми, в отличие от.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	232. "Представлен проект Lumberjack, нацеленный на..."	+/–
	Сообщение от arisu (ok) on 06-Мрт-12, 04:40
	> Ага, щаз. Ты представление-то имеешь, как парсеры работают? хорошо работают, если писались руками и изначально формат нормальный. «первые эн полей я знаю, остальное знать не знаю и не хочу.» всё, проблемы с добавлением полей так, чтобы ничего не поломать, нет. и, конечно, любой лог-файл должен иметь фичу «игнорировать строки, которые начинаются с символов, отсутствующих в текущей спецификации». таким образом мы получаем как неломающиеся конвертеры и анализаторы, так и простор для маневра.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	76. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 17:20
	> Кто мешает пожать и проиндексировать текстовый файл? Современный текстовый лог представляет собой текстовую кашу, которую индексировать весьма проблематично. Индексы эффективны только на структурированных данных. > Где ты увидел стабильный API, если количество полей и их содержимое меняется? API для работы со структурированными данными по определению поддерживает произвольный набор полей различного типа. Абстракция, слышали такое слово?
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	234. "Представлен проект Lumberjack, нацеленный на..."	+/–
	Сообщение от arisu (ok) on 06-Мрт-12, 04:44
	> произвольный набор полей различного типа чем это отличается от «каши», не подскажешь?
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	115. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от anonimous on 03-Мрт-12, 00:14
	> Но только такой gzip, который позволяет работать сразу со сжатым файлом, и при этом не замедляет доступ, а ускоряет его (за счет индекса). А индекс образуется сам собой, причём совершенно задаром.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	137. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 03-Мрт-12, 04:04
	> А индекс образуется сам собой, причём совершенно задаром. А в случае текстаря его еще и хранить надо где-то сильно сбоку...
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	86. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 17:40
	> Это попытка переизобрести gzip? Gzip не позволяет доступ на ходу. А 20 гиговую портянку сам, пожалуйста, декомпрессуй своим гзипом. И да, если уж о скорости, тесктовые логи зачастую отключают т.к. на серверах все начинает упираться именно в запись логов.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	109. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+3 +/–
	Сообщение от XoRe (ok) on 02-Мрт-12, 22:11
	>> Это попытка переизобрести gzip? > Gzip не позволяет доступ на ходу. А 20 гиговую портянку сам, пожалуйста, > декомпрессуй своим гзипом. И да, если уж о скорости, тесктовые логи > зачастую отключают т.к. на серверах все начинает упираться именно в запись > логов. Против 20гиговых логов есть ротация. Кто не настроил, тот - ...) На средненагруженном сервере в логи ничего не упирается. А на высоконагруженном... там уже другие способы работы с логами. Например, отправлять на специальный сервер логов, не храня у себя. Кто не настроил - тот ...)
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	124. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–1 +/–
	Сообщение от Аноним (??) on 03-Мрт-12, 03:12
	> Против 20гиговых логов есть ротация. Угу, что однако не отменяет факта что логи могут быть большими даже с ротацией. > Кто не настроил, тот - ...) На объем логов это ВНЕЗАПНО никак не влияет: если я хочу проанализировать логи за сутки, я хочу проанализировать логи за сутки и все тут. Хоть ротейть, хоть не ротейть, суммарное количество данных за сутки никак не изменится. > На средненагруженном сервере в логи ничего не упирается. Сферические кони в вакууме - это здорово. А вот когда приходит атакер и получается что сервер больше пыжится с записью лога чем со всем остальным, так что приходится логгинг отключать - это как-то неправильно. > А на высоконагруженном... там уже другие способы работы с логами. Ну вот в идеале хотелось бы чтобы сабжевый способ был достаточно компактен и быстр чтобы это для него не было проблемой. > Например, отправлять на специальный сервер логов, не храня у себя. > Кто не настроил - тот ...) Да-да-да, кто не понаставил костылей... а есть другой вариант: сделать так чтобы ставить костыли стало не нyжно. Кто десятилетиями ставит костыли не пытаясь ничего изменить - тот, простите, исполнительный ДУРАК. Специально обученная обезьяна при машине.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	129. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Michael Shigorin (ok) on 03-Мрт-12, 03:38
	>> Например, отправлять на специальный сервер логов, не храня у себя. >> Кто не настроил - тот ...) > Да-да-да, кто не понаставил костылей... Пожалуйста, давайте об устрицах -- емши. Локальное хранение логов нередко весьма затруднительно с точки зрения производительности (шибко много синхронной записи), надёжности (если разрешить буферизовать) и доверенности (если всё-таки проломят). Поэтому отправлять на специальный сервер логов при высокой нагрузке приходится практически без вариантов (а то ещё и стекаться через агрегаторы может).  Вне зависимости от того, как именно будут упакованы сами данные.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	138. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 03-Мрт-12, 04:06
	> Поэтому отправлять на специальный сервер логов при высокой нагрузке приходится практически > без вариантов (а то ещё и стекаться через агрегаторы может).   А чем проблемы с синхронной записью там - лучше чем с синхронной записью где-то еще? Это от сервера конечно зависит, но физическую природу явлений то не меняет. Не, понятно что в ряде случаев - разгрузит. > Вне зависимости от того, как именно будут упакованы сами данные. Ну да, конечно, то-то база OSM в XML 250 гигз, а в бинарном 14. Совсем никакой разницы...
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	158. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от anonimous on 03-Мрт-12, 07:57
	> А чем проблемы с синхронной записью там - лучше чем с синхронной записью где-то еще? Это от сервера конечно зависит, но физическую природу явлений то не меняет. Не, понятно что в ряде случаев - разгрузит. Выделенный коллектор логов обслуживает исключительно логи, а не целевой сервис + логи.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	163. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от zzz (??) on 03-Мрт-12, 12:34
	> Выделенный коллектор логов обслуживает исключительно логи, а не целевой сервис + логи. Целевой сервис не обязан интенсивно писать на диск, если что. Более того, не у всех парк по 50 серверов, а ставить к полутора сервакам еще целый отдельный сервак логинга - ну это круто, конечно, но КПД начинает вызывать вопросы.
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

	189. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Michael Shigorin (ok) on 03-Мрт-12, 19:24
	> Целевой сервис не обязан интенсивно писать на диск, если что. fsync() очень даже бьёт и по чтению.  Если же сервис со всем нужным помещается в памяти -- замечательно, но не так часто. > Более того, не у всех парк по 50 серверов Вас же не призывают держать два ноута, чтоб с одного на другой логи лить. :)  На полутора серверах задач, о которых говорят, вообще особо ожидать не приходится.
	Ответить | Правка | ^ к родителю #163 | Наверх | Cообщить модератору

	218. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 04-Мрт-12, 17:35
	> fsync() очень даже бьёт и по чтению.   Может, но насколько именно - весьма зависит от. > Если же сервис со всем нужным помещается в памяти -- замечательно, но не так часто. А еще можно логи хранить на отдельном диске и прочая, например, ну и пусть его чтение проседает наздоровье если хочет. Хотя конечно же когда вы ынтырпрайз, бабла дофига и прочая - проще не греть мозг и просто воткнуть отдельный сервак логинга, кто б спорил. Правда это годится только для богатых жирных ынтырпрайзов которым плюс-минус пару серверов - вообще ничто. >> Более того, не у всех парк по 50 серверов > Вас же не призывают держать два ноута, чтоб с одного на другой логи лить. :)   > На полутора серверах задач, о которых говорят, вообще особо ожидать не приходится. Да ладно, обычная школьная атака - и вот уже полтора сервера ощущают на себе все прелести вымахивания логов до немеряных размеров за короткий срок.
	Ответить | Правка | ^ к родителю #189 | Наверх | Cообщить модератору

	220. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Michael Shigorin (ok) on 04-Мрт-12, 20:47
	>> fsync() очень даже бьёт и по чтению. > Может, но насколько именно - весьма зависит от. Дядьку, я Вам это по куче систем с самым разным стораджем говорю. >> Если же сервис со всем нужным помещается в памяти -- замечательно, но не так часто. > А еще можно логи хранить на отдельном диске Это и упомянул в #187: "помогает по производительности (но не по доверенности)".  См. тж. #221. > Хотя конечно же когда вы ынтырпрайз, бабла дофига и прочая - проще не греть > мозг и просто воткнуть отдельный сервак логинга, кто б спорил. На "Ломоносове" реализовано многостадийное агрегирование и раздельное хранение, не то что "отдельный сервак".  С отбрасыванием архива на более постоянный сторадж. А в местах, где логи интересные уже есть, но выделенной железки ещё не стоят -- вполне можно себе позволить совместить лог-сервер с бэкап-сервером, риски это увеличивает относительно слабо (если не совмещать логи с бэкапами на одной ФС, конечно). > Правда это годится только для богатых жирных ынтырпрайзов которым плюс-минус > пару серверов - вообще ничто. Такая выделенная железка в компактном корпусе с двумя-тремя SATA-дисками спокойно умещается в $500, если что. >> На полутора серверах задач, о которых говорят, вообще особо ожидать не приходится. > Да ладно, обычная школьная атака - и вот уже полтора сервера ощущают на себе > все прелести вымахивания логов до немеряных размеров за короткий срок. Ну так пусть на малом учатся, всему ж своё время. :)
	Ответить | Правка | ^ к родителю #218 | Наверх | Cообщить модератору

	187. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Michael Shigorin (ok) on 03-Мрт-12, 19:01
	>> Поэтому отправлять на специальный сервер логов при высокой нагрузке >> приходится практически без вариантов (а то ещё и стекаться через агрегаторы может). > А чем проблемы с синхронной записью там - лучше чем с синхронной записью где-то еще? Тем, что подсистема I/O может быть к ним лучше готова. > Это от сервера конечно зависит, но физическую природу явлений то не меняет. > Не, понятно что в ряде случаев - разгрузит. Даже локально отделить активные логи на отдельный шпиндель или несколько в RAID сильно помогает по производительности (но не по доверенности). >> Вне зависимости от того, как именно будут упакованы сами данные. > Ну да, конечно, то-то база OSM в XML 250 гигз, > а в бинарном 14. Совсем никакой разницы... 1) User294, повторяетесь; 2) ну так они б ещё этот XML в doc засунули. PS: несколько удивлён полным отсутствием упоминаний Splunk -- кто-то из знакомых отзывался сдержанно неплохо, но вот детали уж не упомню.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	219. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 04-Мрт-12, 17:45
	> Тем, что подсистема I/O может быть к ним лучше готова. Сервер отгружающий бочками файло и не готовый к интенсивному I/O довольно странная штука. И отдельный диск под логи там вполне может быть. Хотя никто не спорит что если денег много то отдельный сервер логгинга - ничем таким не плохо. Кроме того что он денег стоит. >> Это от сервера конечно зависит, но физическую природу явлений то не меняет. >> Не, понятно что в ряде случаев - разгрузит. > Даже локально отделить активные логи на отдельный шпиндель Ну спасибо вам, Капитан. Я чуть выше тоже откапитанил :) >> Ну да, конечно, то-то база OSM в XML 250 гигз, >> а в бинарном 14. Совсем никакой разницы... > 1) User294, повторяетесь; Есть такие грабельки. Но фактов это не отменяет. > 2) ну так они б ещё этот XML в doc засунули. Фиг с ним с doc, взять айпи например, 123.123.123.123 - это сколько байтов как текст? Что, "всего" 15? А в бинарном виде - 4. Такая вот почти 4-кратная разница на ровном месте. А если еще имя хоста дедупануть и прочая - этак логи в несколько раз и сдуются. Это само по себе время их колупания в эти же разы и сократит потом, а если еще индексы прикрутить к наиболее нужным полям - вообще красота станет. > PS: несколько удивлён полным отсутствием упоминаний Splunk -- кто-то из знакомых отзывался > сдержанно неплохо, но вот детали уж не упомню. Наверное потому что это что-то для совсем уж энтерпрайзной аналитики. В то время как от сабжа лично мне хотелось бы всего лишь такие базовые и логичные вещи как "а что вот тот айпи делал с вот этой системой от сих до сих", например.
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	221. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Michael Shigorin (ok) on 04-Мрт-12, 20:48
	(см. тж. #220) >> Тем, что подсистема I/O может быть к ним лучше готова. > Сервер отгружающий бочками файло и не готовый к интенсивному I/O > довольно странная штука. Так у отгружающего может быть заточка под отгрузку -- приличный readahead и прочее.  А затачивание машинки под устойчивую отдачу и сколь-нибудь постоянную плотную запись -- весьма дорогое удовольствие, особенно если по условиям задачи не получается позволить себе xfs (как на зеркале) и надо что-то более деревянное вроде ext4 или вообще ext3. На ftp у нас SATA swRAID, на www с заметным количеством контейнеров и логов -- SAS hwRAID.  При этом понятно, что запись стараемся по возможности уносить на менее нагруженные периоды, но даже по трафику заметно, что при синхронизации на отдачу идёт просадка: http://fly.osdn.org.ua/mrtg/internal.html > И отдельный диск под логи там вполне может быть. Хотя никто не спорит > что если денег много то отдельный сервер логгинга - ничем таким не плохо. > Кроме того что он денег стоит. ...и место занимает, энергию жрёт, тепло выделяет, обслуживания и замены требует... Кстати, ещё есть кросс-логгинг -- при некоторых обстоятельствах позволяет выкрутиться без особых дополнительных вложений, но не универсален и более чреват сюрпризами при прочих равных. > Фиг с ним с doc, взять айпи например, 123.123.123.123 - это сколько > байтов как текст? Что, "всего" 15? А в бинарном виде - 4. $ echo 123.123.123.123 | gzip | wc -c                                 27 $ seq 1 1000 | while read; do echo 123.123.123.123; done | gzip | wc -c 76 > лично мне хотелось бы всего лишь такие базовые и логичные вещи как "а что вот > тот айпи делал с вот этой системой от сих до сих", например. # find /var/log -type f \! -name '*.bz2' | xargs fgrep ' 123.123.123.123 ' Не, я понимаю, что мужики честно хотят сделать лучше.  Просто это довольно сложно.
	Ответить | Правка | ^ к родителю #219 | Наверх | Cообщить модератору

	147. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+5 +/–
	Сообщение от XoRe (ok) on 03-Мрт-12, 05:59
	>> Против 20гиговых логов есть ротация. > Угу, что однако не отменяет факта что логи могут быть большими даже > с ротацией. "могут быть" - это предположение. факт - это "бл*, вот это логи отожрали!" А с фактом уже можно работать - почему отожрали? Это с уровнем логирования debug, или warning? А напуркуа на продакшене debug? Ах, это варнинг, и о чем он варнингует? Так исправьте, чтобы не варнинговал. И т.д. Можно пойти другим путем. 20 гигов текста - это очень дофига. Это примерно 250 миллионов строк (допустим, 80 символов на сообщение). 250 миллионов делим на 86400 (сутки) = 2893 строк в секунду(!) И что у вас там генерирует 3000 записей в лог за секунду? Если это записи уровня debug - отключайте debug скорее! А если это полезные записи, то пора переводить все логи на специальный сервер логов. Пожалейте ваши жесткие диски! >> Кто не настроил, тот - ...) > На объем логов это ВНЕЗАПНО никак не влияет: если я хочу проанализировать > логи за сутки, я хочу проанализировать логи за сутки и все > тут. Хоть ротейть, хоть не ротейть, суммарное количество данных за сутки > никак не изменится. Вот как раз ротация поможет вам посмотреть лог за сутки, а не грепать недельный лог по "2012-03-03". >> На средненагруженном сервере в логи ничего не упирается. > Сферические кони в вакууме - это здорово. А вот когда приходит атакер > и получается что сервер больше пыжится с записью лога чем со > всем остальным, так что приходится логгинг отключать - это как-то неправильно. Отключение логов при атаке? А если атака в 4 утра? Если исходить, что атака очень может быть, лучше заранее к ней подготовиться. Настройка логирования по сети - это не так сложно. Я даже делал логирование по сети сообщений при kernel panic. Ну а подружить zend с syslog - вообще благое дело. >> А на высоконагруженном... там уже другие способы работы с логами. > Ну вот в идеале хотелось бы чтобы сабжевый способ был достаточно компактен > и быстр чтобы это для него не было проблемой. Пока сабжевый способ только обсуждается. Я рекомендую настроить сервер, чтобы он уже сейчас сделал логи вашими друзьями, а не врагами. Сетевое логирование + ротация со сжатием - и ваши проблемы решены уже сейчас. А не когда команда программистов вместе с поттерингом что-то напишет. >> Например, отправлять на специальный сервер логов, не храня у себя. >> Кто не настроил - тот ...) > Да-да-да, кто не понаставил костылей... а есть другой вариант: сделать так чтобы > ставить костыли стало не нyжно. Кто десятилетиями ставит костыли не пытаясь > ничего изменить - тот, простите, исполнительный ДУРАК. Специально обученная обезьяна при > машине. Смотря что считать костылями. Если в программу добавили функционал работы с сетью, разве это костыль? Или вам нужно окошечко с галочкой "фича из коробки - включена по дефолту"?)
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	157. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от zzz (??) on 03-Мрт-12, 07:54
	> "могут быть" - это предположение. Элементарно - минимальная атака на сервак где они в крейсерском режиме нормальные и лог пухнет в десятки раз от номинала. И именно такой лог как ни странно может захотеться проанализировать. > факт - это "бл*, вот это логи отожрали!" > А с фактом уже можно работать - почему отожрали? Мало ли, атака например. Свалилось в 1000 раз больше запросов чем обычно валится. Вполне обыкновенная ситуация. > Так исправьте, чтобы не варнинговал. Больно жирно. Есть например сервант. Не очень нагруженный. А тут вдруг бабах и атака. Логи могли бы помочь понять кто и что и кого надо в баню. Но если в них все и упирается - их придется отключить чтобы машина не дохла, для начала. В свете этого - если их можно записать в 5 раз компактнее, логично что умирать оно начнет при в 5 раз большей нагрузке. Значит отключать придется реже. > И что у вас там генерирует 3000 записей в лог за секунду? Да любая самая пионерская атака на обычный http сервант хотя-бы. > Если это записи уровня debug - отключайте debug скорее! Что за кретинские предположения? Зачем дебаг в продакшне? > А если это полезные записи, то пора переводить все логи на специальный > сервер логов. Ну да, 3000 запросов в секунду могут прилететь на любой хттп сервак, даже хомпагу Васи Пупкина. Достаточно Васе поругаться с Петей и Петя на раз ему 3000 запросов в секунду пришлет. Что, каждому Васе отдельный сервер для логов ставить? Зашибись :) > Пожалейте ваши жесткие диски! Даешь каждому Васе под хомпагу по личному датацентру, с цысками и сисадминшами?! :) > Вот как раз ротация поможет вам посмотреть лог за сутки, а не > грепать недельный лог по "2012-03-03". А что если я хочу посмотреть "а что вот этот айпишник делал с моим сервером за последнюю неделю"? Вариант нормальный: отсортировать по айпишнику ограничив интервал по дате. За счет индекса - должно педалиться за какие-то секунды. Вариант конский: адски грепать неделю логов. Если их много - займет чуть более чем дохрена времени. >> и получается что сервер больше пыжится с записью лога чем со >> всем остальным, так что приходится логгинг отключать - это как-то неправильно. > Отключение логов при атаке? Ну нормально! А ничего что по логам было бы удобно делать допустим автобан атакующих ботов? Хотя конечно может благородный дон и руками кучи ботов банить не обламывается, вдруг он там не ленивый :) > А если атака в 4 утра? Ну так вот мне нравится идея что вкалывают роботы а не человек. Идеальный вариант: анализатор логов разгребая логи видит аномалии ("вот этот товарищ делает 100 запросов в секунду!") и просто гасит такое сам. Без побудки админа в 4 утра. Но с текстовыми простынями это все реализовывать геморно и нетривиально получается и работает через те еще грабли. > Если исходить, что атака очень может быть, лучше заранее к ней подготовиться. Да, например можно запрячь админа круглосуточно дежурить. А можно анализатора логов. Только вот анализатору логов гигантские портянки в которые дописывают без уведомления, и формат которых оставляет желать много лучшего в плане удобства разбора и которые не заточены на какую либо сортировку и аналитику ибо не снабжены индексами - совершенно не удобны. Весь гемор сваливается на анализатор, который должен или сам реализовывать каждый раз нормальный индекс, или каждый раз читать огромные простыни, скорость данной операции думаю понятна :) > Настройка логирования по сети - это не так сложно. Да, проспонсируйте отдельный сервак логирования каждому Васе с хомпагой. И если уж пошла атака - засрать сеть дополнительно еще и траффиком логгинга это хорошо придумано. Правда откуда следует что оно будет надежно работать - вообще не понятно. А, собственно, если сеть захлебнется например - что будет? Логгинг будет перепослан опосля, когда ей полегчает? А программы узнают о том факте что залоггить было не судьба? И есть даже какая-то универсальная стандартная механика для _разных_ демонов все это узнать?! > Я даже делал логирование по сети сообщений при kernel panic. > Ну а подружить zend с syslog - вообще благое дело. Хотелось бы чтобы логгинг работал в каком-то базовом минимальном варианте без всяких приседаний. В частности хотелось бы чтобы посмотреть "а что вот этот айпи делал с моими демонами за последнюю неделю" было бы штатной фичой системного логгера. А не донавертываться 20 слоями костылей где-то сбоку. До сабжей сие кажется дошло, алилуйя. >> Ну вот в идеале хотелось бы чтобы сабжевый способ был достаточно компактен >> и быстр чтобы это для него не было проблемой. > Пока сабжевый способ только обсуждается. Эээ? Там уже сырцы в гите есть, хоть это и journald по сути. > Я рекомендую настроить сервер, чтобы он уже сейчас сделал логи вашими друзьями, > а не врагами. Вот я искренне надеюсь что сабж совместными усилиями допинают и он будет в разных системах стандартной facility для логгинговых операций. Куда я смогу пойти и получить ответ на вопрос "а что вон тот айпи за последнюю неделю со всеми моими демонами делал". Ну хотя-бы чтобы понять кто это такое и не надо ли такое в файрвол вообще заносить. > Сетевое логирование + ротация со сжатием - и ваши проблемы решены уже сейчас. А выяснение что вон тот айпишник делал с _разными_ демонами на продолжении _недели_ - как было определенным гемором так и осталось. И вообще, декомпрессовать и грепать неделю логов - не очень прикольная и быстрая операция, знаете ли. > А не когда команда программистов вместе с поттерингом что-то напишет. См. выше. Есть ряд вполне типовых и обыденных задач которые красиво и быстро на данный момент не решены. Грепинг недели логов с декомпрессовкой старых версий - это не ответ, это адовы костыли и подпорки. >> Специально обученная обезьяна при машине. > Смотря что считать костылями. Получите мне информацию о том что делал некий айпишник за последнюю неделю с вашей машиной без костылей и грепинка недельных логов. В случае структурированных логов с индексами выцепить только нужный диапазон дат и пройтись по индексу айпишников - плевое дело, займет секунды. А вот грепинг всех логов за неделю от всех демонов может занять черт знает сколько времени, пардон. > Если в программу добавили функционал работы с сетью, разве это костыль? > Или вам нужно окошечко с галочкой "фича из коробки - включена по дефолту"?) Мне как и этим господам нужна подсистема логинга покрывающая типовые наборы административных операций простыми и быстрыми средствами. Грепать все логи всех демонов за неделю, при том что они еще и в разном формате все - нифига не быстро и не удобно.
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	174. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от XoRe (ok) on 03-Мрт-12, 14:18
	Уважаемый, вы бы посмотрели, на какие тезисы я отвечаю) Там как раз хотели за сутки логи смотреть. Ротация обычно настроена на сутки. Если вам нужно за неделю - настройте ротацию на неделю) >> А если атака в 4 утра? > Ну так вот мне нравится идея что вкалывают роботы а не человек. > Идеальный вариант: анализатор логов разгребая логи видит аномалии ("вот этот товарищ > делает 100 запросов в секунду!") и просто гасит такое сам. Без > побудки админа в 4 утра. Но с текстовыми простынями это все > реализовывать геморно и нетривиально получается и работает через те еще грабли. Вообще если мы говорим про страничку васи пупкина, то сервис один - http. А логи apache/nginx парсит большое количество программ. В этом случае откройте для себя log2ban - сам парсит, сам гасит. >> Если исходить, что атака очень может быть, лучше заранее к ней подготовиться. > Да, например можно запрячь админа круглосуточно дежурить. А можно анализатора логов. Только > вот анализатору логов гигантские портянки в которые дописывают без уведомления, и > формат которых оставляет желать много лучшего в плане удобства разбора и > которые не заточены на какую либо сортировку и аналитику ибо не > снабжены индексами - совершенно не удобны. Весь гемор сваливается на анализатор, > который должен или сам реализовывать каждый раз нормальный индекс, или каждый > раз читать огромные простыни, скорость данной операции думаю понятна :) Анализатор логов работает в режиме реального времени. Разница между чтением текста и бинаря - в микросекундах. > Мне как и этим господам нужна подсистема логинга покрывающая типовые наборы административных > операций простыми и быстрыми средствами. Грепать все логи всех демонов за > неделю, при том что они еще и в разном формате все > - нифига не быстро и не удобно. Я бы не назвал выдачу данных о подключении ко всем демонам с одно ip - типовой задачей. Но вы знаете, что даже с имеющимися средствами вы можете это сделать. Вы можете настроить rsyslog/syslog-ng на хранение логов в нужном вам формате. Можно даже настроить, чтобы хранилось по папкам: /log/year/month/day/hour/service/ip.log Хотя вы можете ничего не делать, и ждать, пока нужный вам функционал сделают за вас. Могу добавить, что пока рабочей программы нет, неизвестно, удовлетворит ли ваши нужды её функционал. Я бы уже сейчас настроил нужный функционал из того, что есть.
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	192. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 04-Мрт-12, 00:59
	> Если вам нужно за неделю - настройте ротацию на неделю) Во первых, заранее сложно сказать за какой интервал потребуются логи. Во вторых, портянка за неделю будет приличная как ни крути. Что попиленая на ежедневные куски, что одной простыней. От перемены мест слагаемых сумма не меняется. >> Идеальный вариант: анализатор логов разгребая логи видит аномалии ("вот этот товарищ >> делает 100 запросов в секунду!") и просто гасит такое сам. [...] > Вообще если мы говорим про страничку васи пупкина, то сервис один - http. Ну да, конечно. И никаких там MySQL, FTP, а может еще и nntp, dns, ssh, ... :) > А логи apache/nginx парсит большое количество программ. Ну вот взломали вам вашу "хомпагу васи" и вас уже интересует как бы не просто доступ к хттп а доступ к всем сервисам вообще. А вдруг через ftp эксплойт залили. К тому же текстовые логи можно тихонько и без палива подчистить, просто стерев неудобные записи. Минимум шума и пыли, никто и не заметит... > В этом случае откройте для себя log2ban - сам парсит, сам гасит. Эталонный пример костылей. Как только надо шажок в сторону - начинается геморрой. А можно гасить тех кто чрезмерно много запросов в наш днс делает? А FTP? А ssh? А как насчет того чтобы гасить еще и умников вида [100500.000000] TCP: Peer 1.2.3.4:56789/7654 unexpectedly shrunk window XXX:YYY (repaired) ? Очень удобно каждому логу новый парсер подпихивать, ага. [...] >> который должен или сам реализовывать каждый раз нормальный индекс, или каждый >> раз читать огромные простыни, скорость данной операции думаю понятна :) > Анализатор логов работает в режиме реального времени. > Разница между чтением текста и бинаря - в микросекундах. Угу. Поэтому анализатор должен или сам докостыливать некоторые моменты, или просто забить на некоторые вещи. Например быстро посмотреть сколько запросов за некий интервал сделал вон тот айпи - да фиг вам. Или педаль всю портянку или обломись. >> Грепать все логи всех демонов за неделю, при том что они еще и в разном формате все >> - нифига не быстро и не удобно. > Я бы не назвал выдачу данных о подключении ко всем демонам с одно ip - типовой задачей. Нормальная задача при допустим изучении взлома или атаки или попыток скана. Чего тут такого необычного? > Но вы знаете, что даже с имеющимися средствами вы можете это сделать. Могу, просто это будет долго и геморройно. Можно и намного лучше. > Вы можете настроить rsyslog/syslog-ng на хранение логов в нужном вам формате. > Можно даже настроить, чтобы хранилось по папкам: > /log/year/month/day/hour/service/ip.log Угу, только вот откуда следует что я заранее угадаю формат который будет всегда удобен для всех случаев - совершенно не понятно. В случае когда на все более-менее популярные поля есть индексы - все как-то проще: можно быстро построить желаемую выборку не лопатя вообще все данные, оперативно отсеяв только нужное. Тогда и угадывать заранее ничего не нужно. А в вашей схеме недостаток один, зато какой: надо чтобы ЗАРАНЕЕ был припасен РОЯЛЬ В КУСТАХ. При том желательно удобный. > Хотя вы можете ничего не делать, и ждать, пока нужный вам функционал сделают за вас. Не, ну как-то выкручиваться приходится, но хотелось бы чтобы именно сделали за нас, ибо хороший админ - ленив :) > Могу добавить, что пока рабочей программы нет, неизвестно, удовлетворит ли ваши нужды её функционал. Correct. Однако хотелось бы чтобы более-менее типовые задачи оно покрывало сходу и без проблем. И если ко всему этому будет прозрачный интерфейс - почему бы и нет? Никто же не ругается на гзипованые логи, хотя поток гзипа не только бинарный но и довольно задрюченый и руками его фиг разберешь вообще, нужна программа для его парсинга ака gzip. А ничо, пипл хавает... > Я бы уже сейчас настроил нужный функционал из того, что есть. И? Это не значит что я хочу вплоть до отправки в могилу продолжать так делать если можно делать проще/лучше/удобнее...
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	196. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от vi on 04-Мрт-12, 02:08
	>> "могут быть" - это предположение. > Элементарно - минимальная атака на сервак где они в крейсерском режиме нормальные > и лог пухнет в десятки раз от номинала. И именно такой > лог как ни странно может захотеться проанализировать. Уважаемый, вы хотя бы раз logcheck настраивали?
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	151. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Имя и код on 03-Мрт-12, 06:29
	>> Например, отправлять на специальный сервер логов, не храня у себя. >> Кто не настроил - тот ...) > Да-да-да, кто не понаставил костылей... а есть другой вариант: сделать так чтобы > ставить костыли стало не нyжно. Кто десятилетиями ставит костыли не пытаясь > ничего изменить - тот, простите, исполнительный ДУРАК. Специально обученная обезьяна при > машине. Ну ётыдь, ну шо за вьюные разжижения мозгофекалий? Воопще-то построение скалейбл сислог менеджмента, который, сцуко, без централизированной логопомойки с коллекшн стейшенами, ивент манагерами, ротейшенами и ретеншенами, да ещё в придачу с лёгким и - что самое главное - приятным - сайзингом, не есть возможен, если мы хотим строиться согласно её королевского величества айтилом, с третьей версии, ежели мне ни изменяет. А мы ведь хотим, мы презираем этот вонючий МОФ или что там у них, а? :)
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	168. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 03-Мрт-12, 13:25
	> Ну ётыдь, ну шо за вьюные разжижения мозгофекалий? Я тоже не понял. Поэтому попробуйте изложить мысль внятно и без задействования жопно-сортирной темы, в менее бредовом формате. Меньше понта и украшений, больше дела.
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	200. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Имя и код on 04-Мрт-12, 03:33
	>> Ну ётыдь, ну шо за вьюные разжижения мозгофекалий? > Я тоже не понял. Поэтому попробуйте изложить мысль внятно и без задействования > жопно-сортирной темы, в менее бредовом формате. Меньше понта и украшений, больше > дела. Ну что за дети пошли... Какие понты, исключительно профессиональная терминология + капля здорового стёба. ОК, для особо непосвещённых. Построение scalable syslog management решения не представляется возможным в отсутствие как минимум одного выделенного сервера, собирающего логи (сиречь журналы - для непосвещённых), желательно (если строим до конца правильно) с так называемыми Collection Stations, с предобработкой, в том числе и фильтрацией логов от информационного шума, с механизмами retention и rotation. Это хозяйство должно легко поддаваться сайзингу, ибо будущее захлёбывание его в приходящих потоках нарушает ещё один важный элемент, лежащий на нём: это, согласно айтилу - с 3-й версии (ITIL, который, как мы все прекрасно помним, зародился в управленческих недрах Великобритании) event management.   Да, так вот: в этом случае действительно используется db backend, но ЭТА ХРЕНЬ имеет мало общего со скромными демонами журналов на местах. Разве что пропись в конфиге а-ля *.*                          @finlandia Так понятнее?
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	235. "Представлен проект Lumberjack, нацеленный на..."	+/–
	Сообщение от arisu (ok) on 06-Мрт-12, 04:50
	> исключительно профессиональная терминология это не «профессиональная терминология», это кулхацкерский мунспик был. мало ли, где как кулхацкеры разговаривают, что, за каждым деклассированным элементом следить, что ли?
	Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

	111. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+9 +/–
	Сообщение от nobody (??) on 02-Мрт-12, 22:19
	>> Это попытка переизобрести gzip? > Gzip не позволяет доступ на ходу. А 20 гиговую портянку сам, пожалуйста, > декомпрессуй своим гзипом. И да, если уж о скорости, тесктовые логи > зачастую отключают т.к. на серверах все начинает упираться именно в запись > логов. Логи в продакшене отключают только идиоты. Вменяемые админы, если дисковое и/о из-за логов становится проблемой, пишут логи сразу на удаленный сервер логов, потому что сервис без логирования его работы никакому траблшутингу не поддаётся в принципе, а вменяемые админы не любят беспомощно разводить руками, когда случается внезапный service outage, им больше нравится возможность узнать из лога, что просходило с сервисом непосредственно перед отказом. Кстати поэтому, вменяемых админов сабж врядли обрадует, тк если это будет бд в каком-то виде, то никогда нельзя быть уверенным, что сможешь быстро прогрепать логи, чтобы быстро найти причину и восстановить работоспособность сервиса в кратчайшие сроки. Зато точно понятно, что все написанные годами скрипты и парсеры идут лесом. А меж тем, эта новая бд может (а значит будет) крешиться, и тд - это дополнительный point of failure, усложнение на ровном месте, которое никаких серъезных преимуществ не даёт, зато имеет вполне очевидные недостатки. В общем, это печально всё... что так много, судя по выкрикам, ленартов поттерингов вокруг, для которых KISS и бритва оккама - пустые знаки.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	116. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от anonimous on 03-Мрт-12, 00:18
	> ... И да, если уж о скорости, тесктовые логи > зачастую отключают т.к. на серверах все начинает упираться именно в запись > логов. Мне пытаются впарить мысль, что DB (!!!) будет быстрее, чем plain-file на одном оборудовании. Или я что-то пропустил?
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	122. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от VoDA (ok) on 03-Мрт-12, 02:58
	>> ... И да, если уж о скорости, тесктовые логи >> зачастую отключают т.к. на серверах все начинает упираться именно в запись >> логов. > Мне пытаются впарить мысль, что DB (!!!) будет быстрее, чем plain-file на > одном оборудовании. Или я что-то пропустил? работа с БД в большинстве случаев быстрее plain-file. начиная с того, что нормализация уменьшает размер в 10-30 раз и продолжая индексами по любым требуемым полям. plain-file хорошо пока не нужно проводить анализ на больших объемах.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

Часть нити удалена модератором

	162. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–1 +/–
	Сообщение от zzz (??) on 03-Мрт-12, 12:28
	> Тока не в этом конкрэтном. Ибо инсерты будут валить как из ведра. Значит формат должен допускать лобовой и быстрый инсерт максимально компактных записей, ВНЕЗАПНО. И да, в file.log уточнять по 200 раз в секунду что это действительно хост В.Пупкина - явный оверкилл и расход места. А зачем мне 200 раз в секунду это знать?
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	188. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Michael Shigorin (ok) on 03-Мрт-12, 19:20
	> А зачем мне 200 раз в секунду это знать? То есть атрибута навроде src_ip в блобгах Вы не предполагаете? 8-[ ] Упаковка на основе создания контекстов (а-ля X11) возможна, конечно -- но соответственно усложняется анализатор и не при всяком соотношении изменчивых частей к повторяющимся это разумней уже не раз упомянутой компрессии общего назначения.
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

	193. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 04-Мрт-12, 01:25
	> То есть атрибута навроде src_ip в блобгах Вы не предполагаете? 8-[ ] Предполагаю, но полагаю что возможность сокращенно референсить повторную информацию является плюсом.   > Упаковка на основе создания контекстов (а-ля X11) возможна, конечно -- но соответственно > усложняется анализатор и не при всяком соотношении изменчивых частей к повторяющимся > это разумней уже не раз упомянутой компрессии общего назначения. Да зачем контексты то? Просто отсыл что а вот это поле уже было, брать рядом, а именно - там. И все. Ну или взять за правило что поле указывается только если оно изменилось с прошлого раза (что однако ж чревато тем что при парсинге разрушенного лога будет распарсено неправильно).
	Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

	195. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 04-Мрт-12, 01:57
	> Предполагаю, но полагаю что возможность сокращенно референсить повторную информацию > является плюсом. 1) каков критерий повторности? 2) референсить можно и в текстовом, вопрос в цене выяснения факта повторности в т.ч. > Да зачем контексты то? Просто отсыл что а вот это поле уже было, > брать рядом, а именно - там. Откуда оно "туда" попадёт и когда уйдёт? > И все. Ну или взять за правило что поле указывается только если оно изменилось > с прошлого раза (что однако ж чревато тем что при парсинге разрушенного > лога будет распарсено неправильно). Вы будто пытаетесь описать крайне квадратноколёсый компрессор узкоспециального вида. :)
	Ответить | Правка | ^ к родителю #193 | Наверх | Cообщить модератору

	201. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Имя и код on 04-Мрт-12, 03:38
	>> Тока не в этом конкрэтном. Ибо инсерты будут валить как из ведра. > Значит формат должен допускать лобовой и быстрый инсерт максимально компактных записей, > ВНЕЗАПНО. Угу. С блэкджеком и шлюхами. > И да, в file.log уточнять по 200 раз в секунду что это > действительно хост В.Пупкина - явный оверкилл и расход места. А зачем > мне 200 раз в секунду это знать? Да пофигу, ибо не уточнять, но идентифицировать.
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

	183. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от VoDA (ok) on 03-Мрт-12, 15:06
	>> работа с БД в большинстве случаев быстрее plain-file. > Тока не в этом конкрэтном. Ибо инсерты будут валить как из ведра. > И вот када тазик даже не просядет - проляжет (или мы > их транзакциями по n штук пендюрить бум? А кто вас сказал чтоб это будет *реляционная* СУБД? шарашить с спец формате рассчитанном на эффективную запись. даже при снижении скорости чтения анализ будет идти быстрее чем grep. Далее plain-text можно ускорить в несколько раз если заменить hostname на hostId, время указывать в виде unix-time как набор байт, а не "03-Мрт-12 04:48". Какое приложение выдало сообщение - локальный идентификатор размером в int. Ща глянул на дефолтовые логи - половина записи это мета-информация, которая может быть легко нормализована. Т.е. если сейчас система логирования справляется с текущей нагрузкой, то при замене на бинарь она будет в два раза быстрее (уменьшение на 50% размера средней записи, значит за то же время можно записать на 200% больше, т.е. в два раза). Для дефолтового лога апача ускорение будет в 1,5 раза (мета-информация занимает примерно треть).
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	203. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Имя и код on 04-Мрт-12, 03:49
	>>> работа с БД в большинстве случаев быстрее plain-file. >> Тока не в этом конкрэтном. Ибо инсерты будут валить как из ведра. >> И вот када тазик даже не просядет - проляжет (или мы >> их транзакциями по n штук пендюрить бум? > А кто вас сказал чтоб это будет *реляционная* СУБД? шарашить с спец > формате рассчитанном на эффективную запись. даже при снижении скорости чтения анализ > будет идти быстрее чем grep. Вы. Вы описываете тютелька в тютельку именно такую DBMS и потом удивлённо разводите вашими же руками. > Далее plain-text можно ускорить в несколько раз если заменить hostname на hostId, > время указывать в виде unix-time как набор байт, а не "03-Мрт-12 > 04:48". Какое приложение выдало сообщение - локальный идентификатор размером в int. Вот, именно об этом я и говорю. Проведём нормализацию, напендюрим справочников и т.п. - именно это и характеризует _R_DBMS. > Ща глянул на дефолтовые логи - половина записи это мета-информация, которая может > быть легко нормализована. Т.е. если сейчас система логирования справляется с текущей > нагрузкой, то при замене на бинарь она будет в два раза > быстрее (уменьшение на 50% размера средней записи, значит за то же > время можно записать на 200% больше, т.е. в два раза). Чушь. Сислог крайне чувствителен ко времени записи, а запись в DBMS априори медленнее простого добавления строки в файл.    > Для дефолтового лога апача ускорение будет в 1,5 раза (мета-информация занимает примерно > треть). Конечно не будет, указал по чему.
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	227. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от VoDA (ok) on 06-Мрт-12, 00:45
	>> Далее plain-text можно ускорить в несколько раз если заменить hostname на hostId, >> время указывать в виде unix-time как набор байт, а не "03-Мрт-12 >> 04:48". Какое приложение выдало сообщение - локальный идентификатор размером в int. > Вот, именно об этом я и говорю. Проведём нормализацию, напендюрим справочников и > т.п. - именно это и характеризует _R_DBMS. Однако, как указывает К. Дейт, нормализация в точности и является теми принципами здравого смысла, которыми руководствуется в своём сознании зрелый проектировщик, то есть принципы нормализации — это формализованный здравый смысл. Нормализация применима для NoSQL, и для любых систем хранения типа KV. Это здравый смысл и снижение издержек. > Чушь. Сислог крайне чувствителен ко времени записи, а запись в DBMS априори > медленнее простого добавления строки в файл. > Конечно не будет, указал по чему. Не увидел ни одного факта почему запись в DBMS априори медленнее записи в файл. если DBMS работает поверх CSV то скорость записи будет идентична. Если тот же CSV нормализовать и вынести повторяющиеся элементы, то скорост записи повысится банально за счет записи меньшего числа байтов. То, что для скоростного логирования не подходят СУБД общего назначения. Но специально созданные будут конкретно быстрее файлов. PS если бы текстовые файлы были идеалом скорости записи, то СУБД фигарили бы данные именно в плоские файлы. И git хранилищем использовать plain-text. Но хитрый Оракл извращается над файлами БД. Да и Линус тоже такой не хороший - вместо написания git с идеальным для "Имя и код" бэкэндом поверх plain-text пишет в бинарные файлы. ;)
	Ответить | Правка | ^ к родителю #203 | Наверх | Cообщить модератору

	236. "Представлен проект Lumberjack, нацеленный на..."	+/–
	Сообщение от arisu (ok) on 06-Мрт-12, 04:58
	йопт. на поиск «повторяющихся элементов» в словарях время уходит, нет? а если логов *много* и *разных*? а словари при этом активно меняются, что-то устаревает, что-то добавляется. а логи в это время прут. привет, блокировки. привет, синки словарей и вытесняющие хэши. в итоге красивый теоретический нормализованый дизайн приходит к delicious flat chests. ну, может, с очень маленькими бугорками. и да: во многих случаях текстовые файлы — отличный формат *записи*. а ничего, что «СУБД» — они не только для записи? логи — это *очень* специализированая база, и задача скорости выборки тут решается по другому совсем. впрочем, можешь хранить логи в оракле, чо — кто ж тебе запретит. только руководителям — если они люди немного смыслящие — это не предлагай: могут умереть от смеха.
	Ответить | Правка | ^ к родителю #227 | Наверх | Cообщить модератору

	126. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 03-Мрт-12, 03:16
	> Мне пытаются впарить мысль, что DB (!!!) будет быстрее, чем plain-file на > одном оборудовании. Или я что-то пропустил? Пытаются впарить мысль что запись эвента в минимальном бинарном виде без повторяющихся полей может весить в _разы_ меньше. Так, похожий пример: жил был OSM. Хранил карту в XML. Когда карта мира стала весить в XML 250 гигов так что работать с ней стало невозможно, чуваки очень быстро осознали свои ошибки и сделали эффективный бинарный формат где все данные представлены настолько компактно насколько это можно сделать. И оно весит 14 гигз. Небольшая такая разница, всего примерно в 20 раз...
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	140. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Имя и код on 03-Мрт-12, 04:57
	>> Мне пытаются впарить мысль, что DB (!!!) будет быстрее, чем plain-file на >> одном оборудовании. Или я что-то пропустил? > Пытаются впарить мысль что запись эвента в минимальном бинарном виде без повторяющихся > полей может весить в _разы_ меньше. > Так, похожий пример: жил был OSM. Хранил карту в XML. Когда карта > мира стала весить в XML 250 гигов так что работать с > ней стало невозможно, чуваки очень быстро осознали свои ошибки и сделали > эффективный бинарный формат где все данные представлены настолько компактно насколько > это можно сделать. И оно весит 14 гигз. Небольшая такая разница, > всего примерно в 20 раз... Ну иоптыдь, Опенстриты, они читают на порядки чаще, нежели пишут! :)
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	152. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 03-Мрт-12, 06:31
	> Ну иоптыдь, Опенстриты, они читают на порядки чаще, нежели пишут! :) Пишут его тоже часто и много. И работать с 250Г чушкой в XML попросту не прикольно. Это тормозно и на чтение и на запись.
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	202. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Имя и код on 04-Мрт-12, 03:39
	>> Ну иоптыдь, Опенстриты, они читают на порядки чаще, нежели пишут! :) > Пишут его тоже часто и много. И работать с 250Г чушкой в > XML попросту не прикольно. Это тормозно и на чтение и на > запись. Повторюсь: на порядки меньше!
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	237. "Представлен проект Lumberjack, нацеленный на..."	+/–
	Сообщение от arisu (ok) on 06-Мрт-12, 05:00
	ну и какой идиот изначально додумался базу с необходимым по дизайну random access хранить в xml? он грибов объелся, что ли?
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	45. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от gaga (ok) on 02-Мрт-12, 15:21
	>1. Недостаточная компактность. Особенно неприятно отсутствие возможности дедупликации повторяющихся данных (например, имя хоста). Соответственно, это сильно замедляет хранение, поиск и обработку. В частности, именно поэтому наиболее нагруженные лог-системы (в частности, юниксовый аудит) работают исключительно с бинарными логами. Дедупликация подразумевает сложную структуру хранения, подобную реляционной или какой-нибудь другой СУБД. Это усложняет демон не в разы, а на несколько порядков, и замедляет его на столько же. А лог должен быть максимально простым и быстрым. >2. Неструктурированность. Опять же сильно затрудняет обработку и поиск данных. Кроме того, порождает кучу проблем совместимости - добавление нового поля в структуру не ломает существующие анализаторы логов, в отличие от изменения форматной строки.> JSON и ему подобные форматы решают эту проблему.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	77. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 17:23
	> Дедупликация подразумевает сложную структуру хранения, подобную реляционной или какой-нибудь > другой СУБД. Это усложняет демон не в разы, а на несколько > порядков, и замедляет его на столько же. А лог должен быть > максимально простым и быстрым. То же самое можно сказать про любую SQL-совместимую СУБД. Но почему-то среди них популярны мускул, постргрес и скулайт, причем их бакэнды почему-то работают с бинарными форматами :) > JSON и ему подобные форматы решают эту проблему. Но проблему объема они не решают. Поэтому их рациональнее использовать на следующем этапе обработки - формирование отчетов и выборок по БД логов.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	238. "Представлен проект Lumberjack, нацеленный на..."	+/–
	Сообщение от arisu (ok) on 06-Мрт-12, 05:02
	все твои улыбки в основном от того, что ты считаешь: one size fits all. и волшебные слова «база данных» понимаешь очень однобоко.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	80. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+2 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 17:29
	> Дедупликация подразумевает сложную структуру хранения, Угу, аж возможность референса в сторону - "а вот это уже было, брать вон там вот столько". Капитан также сообщает что именно этим занимается например лемпел-зив, известный каждому продвинутому школьнику. Хотя, конечно, скрипткидиотам и это - "слишком сложно". Осознать что такое length и offset - ракетная наука, однако. > JSON и ему подобные форматы решают эту проблему. И чем оно лучше? Могу сказать чем хуже. 1) Жирнее в разы 2) во столько же тормознее в парсинге. 3) Читаемость на глаз, особенно в компактном виде и без переформатирования - никакая, 4) Сложен в парсинге. Требует специальной либы. 5) Вопрос с индексацией не решен. Ну вот хочу я позырить "а что делал айпи XX.YY.ZZ.JJ в системе с разными демонами с AA.BB.CC до DD.EE.FF?". Размер лога - 20 гигз. И чем мне ваш json поможет? Тем что вместо 20 гигсов станет 60, которые к тому же просто грепом - уже как-бы неудобно, да? :)
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	59. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 16:17
	> прекрасно делаются, сами журнальные записи тоже текстовые Анализировать быстро и на автомате и ловить потенциально интересные эвенты довольно геморно. В случае структурированности можно быстро и просто фильтрануть, например. Или отсортировать по критерию. В случае текста надо какие-то костыли. Грепать или индексить всю портянку на 20 гигз можно и задолбаться. А когда она уже в удобном виде - почему бы и нет?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	78. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 17:25
	> Анализировать быстро и на автомате и ловить потенциально интересные эвенты довольно геморно. > В случае структурированности можно быстро и просто фильтрануть, например. Или отсортировать > по критерию. В случае текста надо какие-то костыли. Грепать или индексить > всю портянку на 20 гигз можно и задолбаться. А когда она > уже в удобном виде - почему бы и нет? Заметим, что идея грепа лога сама по себе порочна. Добавление в строку нового поля, или изменение формулировки сообщения ломает работу всех хитроумных regexpов.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	83. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 17:34
	> Заметим, что идея грепа лога сама по себе порочна. Я бы сказал 50/50, потому что гибкость - хорошая, да. И позволяет завернуть очень хитрый критерий для аналитики, которого вот так сходу может и не быть. С другой стороны, грепать 20-гиговую портянку на каждую оказию - удовольствие ниже среднего. > Добавление в строку нового поля, или изменение формулировки сообщения ломает > работу всех хитроумных regexpов. Ну вот поэтому я и полагаю что в принципе сабж имеет право на жизнь, ЕСЛИ оставят нормальный интерфейс для грепалок на случай когда надо завернуть какую-то хитрозагнутую аналитику, скорость которой не важна, а вот готового тулса не оказалось и все тут, так что цепочка грепов - единственный простой вариант.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	87. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 17:41
	> Я бы сказал 50/50, потому что гибкость - хорошая, да. И позволяет > завернуть очень хитрый критерий для аналитики, которого вот так сходу может > и не быть. Хм. Вы когда-нибудь с SQL работали? Скажу по секрету: там возможностей для хитрой аналитики куда больше, чем в простом грепе =) Логично, что для работы со структурированными данными, будет использоваться язык структурированных запросов (a.k.a. SQL), или некий его аналог.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	125. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Anonymouse on 03-Мрт-12, 03:13
	>Хм. Вы когда-нибудь с SQL работали? Скажу по секрету: там возможностей для хитрой аналитики куда больше, чем в простом грепе =) Practical Extraction and Report Language. На SQL-е - умахаешься. Впрочем поЦерингов это не остановит :(
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	130. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+2 +/–
	Сообщение от Аноним (??) on 03-Мрт-12, 03:50
	> Хм. Вы когда-нибудь с SQL работали? Скажу по секрету: там возможностей для > хитрой аналитики куда больше, чем в простом грепе =) 1) Я не считаю что для анализа логов мне надо бросить все и стать DBA 2) Я не считаю что для анализа логов мне надо бросить все и стать SQL programmer. 3) Базы SQL в общем случае не отличаются скоростью и компактностью. 4) Оно слишком много всего умеет: перспектива словить SQL injection в системе логгинга - здорово придумано. А что, пусть хакер и ломится через систему логгинга сразу. 5) В общем случае SQL базы не дизайнились быть устойчивыми от хакинга, удаления записей задним числом без простого обнаружения этого факта, etc.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	213. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от cosmonaut (ok) on 04-Мрт-12, 12:09
	>Скажу по секрету: там возможностей для хитрой аналитики куда больше, чем в простом грепе =) Т.е. вы хотите сказать, что DSL, коим является SQL имеет больше возможностей, чем тьюринг-полный язык (bash+grep+tools+sed+awk)? А где такая трава продается? :)
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	99. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 18:38
	> Заметим, что идея грепа лога сама по себе порочна. Добавление в строку > нового поля, или изменение формулировки сообщения ломает работу всех хитроумных regexpов. Да, вспоминается, как аккуратненько добавил разок дополнительное поле в конец лог-строки апача. И все, вебалайзер тут же загнулся.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	117. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от anonimous on 03-Мрт-12, 00:26
	> Анализировать быстро и на автомате и ловить потенциально интересные эвенты довольно геморно. > В случае структурированности можно быстро и просто фильтрануть, например. Или отсортировать > по критерию. В случае текста надо какие-то костыли. Грепать или индексить > всю портянку на 20 гигз можно и задолбаться. А когда она > уже в удобном виде - почему бы и нет? Узкое место --- не в чтении/парсинге/поиске, в записи. (поиск --- значительно более редкая и менее требовательная к скорости получения результата операция, по сравнению с записью).
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	142. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–1 +/–
	Сообщение от Имя и код on 03-Мрт-12, 05:16
	>> прекрасно делаются, сами журнальные записи тоже текстовые > Анализировать быстро и на автомате и ловить потенциально интересные эвенты довольно геморно. > В случае структурированности можно быстро и просто фильтрануть, например. Или отсортировать > по критерию. В случае текста надо какие-то костыли. Грепать или индексить > всю портянку на 20 гигз можно и задолбаться. А когда она > уже в удобном виде - почему бы и нет? Не-а, бинарь в принципе не удобен. Эт раз. Для первичного анализа берутся не сами логи, но уже очищенные от инфошума, эт два. И тока ежели оно действительно дальше нуна (отрицательная вероятность), берётся часть простыни, локализированная по.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	166. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от zzz (??) on 03-Мрт-12, 13:18
	> Не-а, бинарь в принципе не удобен. Эт раз. Бинарь в принципе ничем не отличается от текстаря. Поскольку вы не читаете сектора диска напрямую с DMA с блинов в мозг, так или иначе нужны какие-то программы. В каком именно они варианте данные прочтут мне не так уж принципиально. Если это потом можно удобным утилям скормить. Кстати gzip вы в уме вообще нифига не распакуете, если уж на то пошло. > Для первичного анализа берутся не сами логи, но уже очищенные от инфошума, эт два. 1) Чистить вотпрямща 100500 гигз логов за последнюю неделю - довольно не прикольное начинание. А критерии того что есть шум становятся известны вот сей момент и только так. 2) Опять же, в рантайм в реальном времени все это делать неудобно. 3) А еще у кучи демонов разные форматы логов. > И тока ежели оно действительно дальше нуна (отрицательная вероятность), > берётся часть простыни, локализированная по. Что есть отрицательная вероятность? :)
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	204. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Имя и код on 04-Мрт-12, 03:56
	>> Не-а, бинарь в принципе не удобен. Эт раз. > Бинарь в принципе ничем не отличается от текстаря. Поскольку вы не читаете > сектора диска напрямую с DMA с блинов в мозг, так или > иначе нужны какие-то программы. Не текстовый формат весьма и весьма не удобен. Малоюзабелен. > В каком именно они варианте данные прочтут > мне не так уж принципиально. Если это потом можно удобным утилям > скормить. Кстати gzip вы в уме вообще нифига не распакуете, если > уж на то пошло. >> Для первичного анализа берутся не сами логи, но уже очищенные от инфошума, эт два. > 1) Чистить вотпрямща 100500 гигз логов за последнюю неделю - довольно не > прикольное начинание. А критерии того что есть шум становятся известны вот > сей момент и только так. Никто вотпрямща и не чистит, кстати. > 2) Опять же, в рантайм в реальном времени все это делать неудобно. Очень удобно. Если, конечно, Вы не собираетесь делать это ручками. > 3) А еще у кучи демонов разные форматы логов. Тем паче текстовый формат. >> И тока ежели оно действительно дальше нуна (отрицательная вероятность), >> берётся часть простыни, локализированная по. > Что есть отрицательная вероятность? :) Это вероятность, меньшая нулевой :)
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	44. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–4 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 15:18
	Итак, давайте обдумаем. Допустим что syslog действительно устарела (устаревание софта понимается однозначно - невозможность решить новые задачи, появившиеся вследствии возникновения новых требовании к системе журналирования, путем доработки/модернизации существующей системы). В этом случае syslog либо потребует замены на систему с расширенным функционалом, либо требует такой переработки, которая может затронуть существующую архитектуру системы вцелом так что увиличение номера мажорного релиза не будет явным образом отражать масштабы прогресса (однако если вспомнить про веб-сервер apache с его развитием веток 1x и 2x и сопоставить с изменениями, то можно предположить что увиличение значения индикатора мажорного релиза будет более чем достаточным). Я вам это описал чтобы вы поняли суть происходящего/предстоящего. Ну а вы увидели лишь формат хранения/представления логов. Понимаете ли, неуважаемый, формат представления данных это, вообще говоря, вопрос второстепенный, поскольку он решается очень просто - путем написания одной единственной утилиты для конвертирования. И еще раз, чтобы дошло наверняка: разница между бинарными и текстовымы форматами хранения не несет сколько-нибудь принципиальной разницы и оба формата представления вполне пригоды для использования. Это я к тому что прикрутить к syslog хранение в бинарном представлении - это простое дело одного коммита (нужны всего лишь две функции кодирования и декодирования, которые можно выбросить в разделяемую библиотеку и позже предоставить API для возможности написания сторонних утилит). Но вы обо всем этом не подумали (по каким-то личным причинам), однако поспешили выступить "громко" в сторону линукса. Вывод: текст вашего сообщения оказался низкокачественным де!!мом (вы со средне-серым образованием или обычный гуманитарии?)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	48. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от anonymous (??) on 02-Мрт-12, 15:30
	Слишком много букв. Но что делать, если утилита посчитает бинарный лог испорченным и пошлёт куда подальше? Представляется ли возможным что-то быстро предпринять на коленке в таком вот экстренном случае?
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	51. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–1 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 15:47
	Снова на второстепенные вещи отвлекаетесь: 1. Много букв потому то в тексте подробности (внезапно?). 2. Утилита утилите рознь (тут надо смотреть на реализацию утилиты и, особенно, на формат логов (бинарность логов не обязательно подразумевает их архивацию в сполшной solid-архив; можно сжимать на уровне сообщения/строк/записи и т.д.) ).
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	53. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 15:52
	Это важный вопрос, но не первой важности, т.к. он не определяет архитектуру и возможности. А разговоры именно об этом
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	57. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 16:01
	Об этом и речь была. Цитирую: "разница между бинарными и текстовымы форматами хранения не несет сколько-нибудь принципиальной разницы". Ключевое здесь: "не несет принципиальной разницы". Просто часть читающих опеннета не осиливает текст моего сообщения (да куда там до понимания сути сообщения когда часть тут новости (пересказ в кратком изложении) не осиливает даже на половину).
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	90. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–1 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 17:46
	> Об этом и речь была. Цитирую: "разница между бинарными и текстовымы форматами > хранения не несет сколько-нибудь принципиальной разницы". Ключевое здесь: "не несет принципиальной > разницы". Просто часть читающих опеннета не осиливает текст моего сообщения (да > куда там до понимания сути сообщения когда часть тут новости (пересказ > в кратком изложении) не осиливает даже на половину). Разница между текстовым и бинарным форматом - логическое следствие разницы между структурированными и неструктурированными данными. Нет, конечно, можно и текстовые данные структурировать (JSON там, XML), но не на таких объемах, как в случае с логами.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	100. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 19:17
	>Разница между текстовым и бинарным форматом - логическое следствие разницы между структурированными и неструктурированными данными. Вы не врубаетесь в самую суть: формат хранения логов это второстепенные вещи и нет никакой проблемы перегнать с одного формата в другой. >Нет, конечно, можно и текстовые данные структурировать (JSON там, XML), но не на таких объемах, как в случае с логами. Проблема сжать существующие логи? Или проблема навесить структуризацию на текущий способ?
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	119. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+2 +/–
	Сообщение от Deffic on 03-Мрт-12, 01:59
	>>Разница между текстовым и бинарным форматом - логическое следствие разницы между структурированными и неструктурированными данными. > Вы не врубаетесь в самую суть: формат хранения логов это второстепенные вещи > и нет никакой проблемы перегнать с одного формата в другой. >>Нет, конечно, можно и текстовые данные структурировать (JSON там, XML), но не на таких объемах, как в случае с логами. > Проблема сжать существующие логи? Или проблема навесить структуризацию на текущий способ? Поддреживаю. Собершенно непонятно вокруг чего проблема, если нужны структурированные данные, загоняем логи через rsyslog в базу на удалённом сервере, параллельно можно оставить в тексте (если требуется). Хранение логов на рабочем сервере (в любом виде) может помочь только в решении системных проблем. В этом случае их структурированность совершенно необязательна, вам всё равно потребуется просматривать всё записи в логе(ах) последовательно в поисках аномалий. Причём отдельные события могут быть абсолютно обыденными, но вот их последовательность может вам сказать об ошибке. В этом случае разворачиваем базу в простыню? Зачем тогда загоняли в базу? В случае взлома, локальные логи теряют смысл, так как доступ к логам/базе логов есть у взломщика есть и изменить данные и даты не составляет особого труда. Кто-нибудь может обьяснить, что _нужного_ умеет  "Lumberjack" ?
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	123. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от VoDA (ok) on 03-Мрт-12, 03:09
	>>Нет, конечно, можно и текстовые данные структурировать (JSON там, XML), но не на таких объемах, как в случае с логами. > Проблема сжать существующие логи? Или проблема навесить структуризацию на текущий способ? Проблема сделать логи структурированными. Решение этой задачи попутно решит ряд проблем таких как размер логов, падение анализаторов при добавлении новых полей, невозможность применения одинаковых анализаторов для различных приложений. Раскрою последнее утверждение: хотя данные, которые создают разные приложения в логах подобны, но различен формат и потому нет универсального анализатора. А случае структурированных логов анализатор проверяющий кто заходил на apache с 3 до 5 однозначно будет работать и на DNS и на любых других системах потому что формат стандартизован. Стандартизация представления логов внешним приложениям - одна из основных задач journald и subj.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	153. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Имя и код on 03-Мрт-12, 06:44
	>>Разница между текстовым и бинарным форматом - логическое следствие разницы между структурированными и неструктурированными данными. > Вы не врубаетесь в самую суть: формат хранения логов это второстепенные вещи > и нет никакой проблемы перегнать с одного формата в другой. >>Нет, конечно, можно и текстовые данные структурировать (JSON там, XML), но не на таких объемах, как в случае с логами. > Проблема сжать существующие логи? Или проблема навесить структуризацию на текущий способ? Она УЖЕ структурирована, в эрэфсях это чётко прописано (это свежий): The syslog message has the following ABNF [RFC5234] definition:       SYSLOG-MSG      = HEADER SP STRUCTURED-DATA [SP MSG]       HEADER          = PRI VERSION SP TIMESTAMP SP HOSTNAME                         SP APP-NAME SP PROCID SP MSGID       PRI             = "<" PRIVAL ">"       PRIVAL          = 1*3DIGIT ; range 0 .. 191       VERSION         = NONZERO-DIGIT 0*2DIGIT       HOSTNAME        = NILVALUE / 1*255PRINTUSASCII       APP-NAME        = NILVALUE / 1*48PRINTUSASCII       PROCID          = NILVALUE / 1*128PRINTUSASCII       MSGID           = NILVALUE / 1*32PRINTUSASCII       TIMESTAMP       = NILVALUE / FULL-DATE "T" FULL-TIME       FULL-DATE       = DATE-FULLYEAR "-" DATE-MONTH "-" DATE-MDAY       DATE-FULLYEAR   = 4DIGIT       DATE-MONTH      = 2DIGIT  ; 01-12       DATE-MDAY       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on                                 ; month/year       FULL-TIME       = PARTIAL-TIME TIME-OFFSET       PARTIAL-TIME    = TIME-HOUR ":" TIME-MINUTE ":" TIME-SECOND                         [TIME-SECFRAC]       TIME-HOUR       = 2DIGIT  ; 00-23       TIME-MINUTE     = 2DIGIT  ; 00-59       TIME-SECOND     = 2DIGIT  ; 00-59       TIME-SECFRAC    = "." 1*6DIGIT       TIME-OFFSET     = "Z" / TIME-NUMOFFSET       TIME-NUMOFFSET  = ("+" / "-") TIME-HOUR ":" TIME-MINUTE       STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT       SD-ELEMENT      = "[" SD-ID *(SP SD-PARAM) "]"       SD-PARAM        = PARAM-NAME "=" %d34 PARAM-VALUE %d34       SD-ID           = SD-NAME       PARAM-NAME      = SD-NAME       PARAM-VALUE     = UTF-8-STRING ; characters '"', '\' and                                      ; ']' MUST be escaped.       SD-NAME         = 1*32PRINTUSASCII                         ; except '=', SP, ']', %d34 (")       MSG             = MSG-ANY / MSG-UTF8       MSG-ANY         = *OCTET ; not starting with BOM       MSG-UTF8        = BOM UTF-8-STRING       BOM             = %xEF.BB.BF       UTF-8-STRING    = *OCTET ; UTF-8 string as specified                         ; in RFC 3629       OCTET           = %d00-255       SP              = %d32       PRINTUSASCII    = %d33-126       NONZERO-DIGIT   = %d49-57       DIGIT           = %d48 / NONZERO-DIGIT       NILVALUE        = "-" Что нужно ищо этому безумному, выпрашивающему бинарного формата, как Моисей Египетович манны (или маны :) )?
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	159. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 03-Мрт-12, 10:23
	>Что нужно ищо этому безумному, выпрашивающему бинарного формата Ему раскидали то что он уткнулся лишь в поверхностные, второстепенные вещи, но он и дальше свое гнет потому что целью для него не является поиск объективной картины (придется принять факт того что форма представления все-такие вещи второстепенные), а его цель - любой ценой не оказаться не правым (возможно, у него проблемы психического плана из далекого детства и/или просто зашкаливает ЧСВ, но нам то до него и его проблем ..). Такие дела ..
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	164. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Имя и код on 03-Мрт-12, 12:40
	>>Что нужно ищо этому безумному, выпрашивающему бинарного формата > Ему раскидали то что он уткнулся лишь в поверхностные, второстепенные вещи, но > он и дальше свое гнет потому что целью для него не > является поиск объективной картины (придется принять факт того что форма представления > все-такие вещи второстепенные), а его цель - любой ценой не оказаться > не правым (возможно, у него проблемы психического плана из далекого детства > и/или просто зашкаливает ЧСВ, но нам то до него и его > проблем ..). Такие дела .. И самое забавное, что своими действиями усугубляет именно в этом направлении :)
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

	170. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–1 +/–
	Сообщение от Аноним (??) on 03-Мрт-12, 13:37
	> Она УЖЕ структурирована, в эрэфсях это чётко прописано (это свежий): Ну так перцы тоже решили реализовать стандарт. А то что он бинарный - ну и болт бы с ним. Я же не воняю что gzip не только бинарный но и вообще не декодируем в уме и с ножом к горлу требует утилиту gzip для работы, правда?
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	190. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Michael Shigorin (ok) on 03-Мрт-12, 19:30
	> Я же не воняю Вы просто передёргиваете. > что gzip не только бинарный gzip, cat, $EDITOR -- универсальные, в отличие от.
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	194. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 04-Мрт-12, 01:34
	> gzip, cat, $EDITOR -- универсальные, в отличие от. А что мешает сделать прозрачную развертку этого формата в текст как gzip это делает для сжатого формата? Ничего? Хм, так это вопрос наличия утилит делающих это.
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	197. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Michael Shigorin (ok) on 04-Мрт-12, 02:08
	>> gzip, cat, $EDITOR -- универсальные, в отличие от. > А что мешает сделать прозрачную развертку этого формата в текст как gzip > это делает для сжатого формата? Ничего? Вот Вы (как понимаю) в #193 описали сворачивание по IP.  Попробуйте набросать структуру данных и псевдокод, который сделает разворачивание в текст. Мне пока кажется, что получится или размазанный по данным словарик (IP-шники же приходят новые, иначе совсем узкий случай), или отдельная вспомогательная сущность.  С первым как раз в случае потоковой обработки _всего_ массива более-менее эффективная реализация просматривается (поскольку можно идти окошком по данным, пополняя словарик и зная, что при записи сперва пополнялся он, затем значения использовались в потоке).  А вот при хвалёном произвольном доступе -- что-то сходу не соображу, как выкрутиться.  Если же держать эту сущность отдельно, то gzip уже не получается, а получается нечто с набором тайных знаний в пузе о том, где эти отдельности искать, или с ключами, которые надо обязательно задать (или же фолбэк с первого на второе, не суть). Есть старое доброе правило: не усложняй сверх необходимого.  И что-то эта молодая гвардия его не выучила, похоже -- ломят непотребства имени себя, как джоэловский MSDN camp... PS: заметьте, это мы с Вами подразумеваем некую фиксированную схему для одного случая.  А если схемы разные... а ещё и корректируемые...
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

	228. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от VoDA (ok) on 06-Мрт-12, 00:54
	>[оверквотинг удален] > приходят новые, иначе совсем узкий случай), или отдельная вспомогательная сущность.   > С первым как раз в случае потоковой обработки _всего_ массива более-менее > эффективная реализация просматривается (поскольку можно идти окошком по данным, пополняя > словарик и зная, что при записи сперва пополнялся он, затем значения > использовались в потоке).  А вот при хвалёном произвольном доступе -- > что-то сходу не соображу, как выкрутиться.  Если же держать эту > сущность отдельно, то gzip уже не получается, а получается нечто с > набором тайных знаний в пузе о том, где эти отдельности искать, > или с ключами, которые надо обязательно задать (или же фолбэк с > первого на второе, не суть). Вы правы - это тайный набор знаний. Его специально выделяют в отдельную сущность с доступом через API. Опять же grep не имеет произвольного доступа - только прямое чтение. И плакальщики из этого треда уверяют, что это самый лучший вариант. Так что меняя plain-text на потоковый файл, где общие сущности живут в пополняемых словарях, получаем ускорение потокового чтения и записи (данные уже сжаты). Сам принцип сохраняется.
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	230. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Michael Shigorin (ok) on 06-Мрт-12, 01:17
	> Так что меняя plain-text на потоковый файл, где общие сущности живут в > пополняемых словарях Я и подводил пишущего к мысли, что мы, скорее всего, попадаем на мини-DB и мини-DBA, а также прочий совершенно излишний в тривиальных случаях оверхед -- за который не должны платить ресурсами и разрывом мозга те, кому он не упёрся. Проблема этих обновленцев в том, что они усложняют тривиальный случай нужным в весьма нетривиальном вместо того, чтобы простое оставить простым, а своё громоздить в сторонке.
	Ответить | Правка | ^ к родителю #228 | Наверх | Cообщить модератору

	185. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от VoDA (ok) on 03-Мрт-12, 15:23
	>>>Разница между текстовым и бинарным форматом - логическое следствие разницы между структурированными и неструктурированными данными. >> Вы не врубаетесь в самую суть: формат хранения логов это второстепенные вещи >> и нет никакой проблемы перегнать с одного формата в другой. >>>Нет, конечно, можно и текстовые данные структурировать (JSON там, XML), но не на таких объемах, как в случае с логами. >> Проблема сжать существующие логи? Или проблема навесить структуризацию на текущий способ? > Она УЖЕ структурирована, в эрэфсях это чётко прописано (это свежий): Сам MSG не структурирован. Как по вашему задаются обязательные и дополнительные поля для MSG? никак. в этом и проблема, которую хотят вылечить. Дальше дыры в безопасности: наличие в теле сообщения APP-NAME, PROCID, TIMESTAMP (возможно и других подобных полей). Приложение не должно иметь API для того чтобы выдать себя за другое или использовать другое время. API должен быть подобный (псевдо код): спикокПолейИЗначений = { "поле1":"значение поля 1", "IP":127.0.0.1, }; LOG.debug("сообщение для человека без данных", списокПолейИЗначений); И нигде не должно запрашиваться у приложения его ИМЯ, procid и дата записи. ДАТА - по факту логирования, ИМЯ и procid - по факту того кто вызвал запись. И т.п. иначе запись что приложение Маша с хоста Вася является скомпрометированной поскольку приложение может подменить и хост и собственное имя. PS спасибо, что подтвердили мои догадки, что RFC не описывает структуру самого сообщения. Ваша цитата наглядно это показывает )))))
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	205. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Имя и код on 04-Мрт-12, 04:03
	>> Она УЖЕ структурирована, в эрэфсях это чётко прописано (это свежий): > Сам MSG не структурирован. Как по вашему задаются обязательные и дополнительные поля > для MSG? никак. в этом и проблема, которую хотят вылечить. ... От ёптыдь, попробую объяснить по аналогии: Вы про тисипиайпи слыхивали? Про то, что опо пакетное? Так вот: Вы сначала предлагаете "структурировать" ай-пи пакет, потом, увидев, что он сто лет в обед как имеет жёсткую структуру, замалчиваете это, при этом громогласно заявляте что дата-часть пакета не структурирована. Вот такой театр абсурда. > PS спасибо, что подтвердили мои догадки, что RFC не описывает структуру самого > сообщения. Ваша цитата наглядно это показывает ))))) Вы даже РФЦ не читаете? Тогда о чём Вы о кто Вы? :))
	Ответить | Правка | ^ к родителю #185 | Наверх | Cообщить модератору

	229. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от VoDA (ok) on 06-Мрт-12, 01:02
	> От ёптыдь, попробую объяснить по аналогии: Вы про тисипиайпи слыхивали? Про то, > что опо пакетное? Так вот: Вы сначала предлагаете "структурировать" ай-пи пакет, > потом, увидев, что он сто лет в обед как имеет жёсткую > структуру, замалчиваете это, при этом громогласно заявляте что дата-часть пакета не > структурирована. Вот такой театр абсурда. Аналогия интересна, но не верна. Изначальный постулат, который я развиваю это необходимость структуризации логирующего сообщения. Не только части формализованной в RFC, но всего сообщения. Чтобы IP клиента был отдельным полем с возможностью поиска или построения иной аналитики. Кроме того RFC пропускает некоторые уязвимости. Попробую объяснить по аналогии: нужно было сделать передачу почтовых сообщение - сделали SMTP. Но сам протокол рассчитывает на ряд аксиом типа защищенности самого сервера. Уже много лет это дыры (просчеты) в протоколе позволяют спамить. Данные RFC на логирование также имеет уязвимости, что терпимо сейчас, но в будущем может привести к повторению судьбы SMTP.
	Ответить | Правка | ^ к родителю #205 | Наверх | Cообщить модератору

	131. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 03-Мрт-12, 03:52
	> Слишком много букв. Но что делать, если утилита посчитает бинарный лог испорченным Тогда с ним делать то же что и с испорченным текстовым логом. Открыли вы текстарь а там бред. Ну и чего?
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	82. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 17:34
	> Это я к тому что прикрутить к syslog хранение в бинарном представлении - это простое дело одного коммита (нужны всего лишь две функции кодирования и декодирования, которые можно выбросить в разделяемую библиотеку и позже предоставить API для возможности написания сторонних утилит). А вы подумали о том, что старый API взаимодействия приложений с syslog не предназначен для передачи структурированных данных, и даже если ввести в современный rsyslog бинарный формат хранения, существенных бонусов это не даст. > Вывод: текст вашего сообщения оказался низкокачественным де!!мом (вы со средне-серым образованием или обычный гуманитарии?) Судя по вашей буйно реакции, а наступил на вашу любимую мозольку. Правда, пока не могу понять, где именно.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	160. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 03-Мрт-12, 10:31
	>А вы подумали о том, что старый API взаимодействия приложений с syslog не предназначен для передачи структурированных данных, и даже если ввести в современный rsyslog бинарный формат хранения, существенных бонусов это не даст. Не вижу никаких проблем чтобы расширить API. Это дело одного коммита. >Судя по вашей буйно реакции, а наступил на вашу любимую мозольку. Правда, пока не могу понять, где именно. Длинное сообщение получилось лишь потому что я попытался описать часть картины более полно (не опуская важные детали). Понять вы не можете вполне закономерно: вы ошиблись в расчетах (реакция у меня вполне обычная, а не буйная (это, кстати, проблема вашего восприятия с уклоном в эмоциональный фон) ). Вы о себе слишком высокого мнения.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	240. "Представлен проект Lumberjack, нацеленный на..."	+/–
	Сообщение от arisu (ok) on 06-Мрт-12, 05:09
	> Не вижу никаких проблем чтобы расширить API. Это дело одного коммита. угу. один всемирный такой коммит, который автомагически поправит все клиенты.
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	93. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 18:25
	> Вывод: текст вашего сообщения оказался низкокачественным де!!мом (вы со средне-серым образованием или обычный гуманитарии?) В чем-то вы правы =) В своем посте я немножечко пожертвовал логичностью ради провокационности. Действительно, ключевым моментом является введение API для работы со _структурированными_ данным. Бинарный формат лога - это лишь внешний атрибут, который сам по себе существенных бонусов не дает. Просто меня забавляет реакция на это словосочетание ("бинарные логи") некоторых местных петушков, знакомых с юниксом исключительно понаслышке, но при этом обожающих рассказывать, что такое юниксвей, и как всем правильно жить =)
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	121. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Куяврик on 03-Мрт-12, 02:40
	А мне вот не нравится идея бинарных логов. И бинарных конфигов. Просто - не нравится. Независимо от API. И совершенно неясно что в этом забавного. А вот забавно как раз наоборот - ваше отношение. "Бинарный формат лога - это лишь внешний атрибут, который сам по себе существенных бонусов не дает." "Просто меня забавляет реакция на это словосочетание ("бинарные логи")" Расщепление сознания детектед?
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	214. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от cosmonaut (ok) on 04-Мрт-12, 12:37
	> Просто меня забавляет реакция на это словосочетание ("бинарные логи") некоторых местных > петушков, знакомых с юниксом исключительно понаслышке, но при этом обожающих рассказывать, > что такое юниксвей, и как всем правильно жить =) Вот, если бы вы знали, что такое cat,grep,sed и другие умные слова для работы с текстовым форматом даных, то знали бы, что при парсинге глазами таких вот бинарных логов (что оч часто бывает полезным, представте) нужно будет либо конвертировать их перед этим в текстовые, либо писать аналоги всего выше сказанного (и не только), что, собственно, смахивает на промышленное велосипедостроение. ...хотя, да, это же дело одного коммита...
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	143. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Имя и код on 03-Мрт-12, 05:30
	> Вывод: текст вашего сообщения оказался низкокачественным де!!мом (вы со средне-серым образованием > или обычный гуманитарии?) На 100% выпускник какого-нибудь "ВУЗа" типа Мэждународного Университета Соломона, фак а-ля "экономическая кибернетика", сп-ть "визуализация табличных данных средствами MS Exhell". Бакалавр околокомпьютерных наук со стажем.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	171. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 03-Мрт-12, 13:38
	> Бакалавр околокомпьютерных наук со стажем. Будем знакомы. И как оно вам, бакалаврам? :)
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	206. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Имя и код on 04-Мрт-12, 04:04
	>> Бакалавр околокомпьютерных наук со стажем. > Будем знакомы. И как оно вам, бакалаврам? :) Нам такие как Вы бакалавры забавны :)))
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	67. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–4 +/–
	Сообщение от R on 02-Мрт-12, 16:34
	> Ну наконец-то и линукс дошел до того, что в юниксе сделано уже > двадцать лет назад. Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	84. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 17:36
	> Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые > логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?. А еще в UNIX auditd (который гораздо важнее syslog), и он пишет бинарные логи.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	154. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Имя и код on 03-Мрт-12, 07:06
	>> Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые >> логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?. > А еще в UNIX auditd (который гораздо важнее syslog), и он пишет > бинарные логи. А мексиканского кактуса бритого он важнее. аудитди не расскажет мне кто, аутентифицированный керберосом и авторизированный ЛДАПом, получил коннект через сквид. И эта, советую поинтересовадзе сколько триггеров/рулз по дефолту в этом ди включено, почему это мизерная часть и шо будет, если этих цацок включить много.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	169. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 03-Мрт-12, 13:35
	> А мексиканского кактуса бритого он важнее. аудитди не расскажет мне кто, аутентифицированный > керберосом и авторизированный ЛДАПом, получил коннект через сквид. А вот в предлагаемой вон теми парнями схеме - чуть более другой сервис пойдет и расскажет кто и какого хрена. В более-менее унифицированном формате.
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	207. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Имя и код on 04-Мрт-12, 04:06
	>> А мексиканского кактуса бритого он важнее. аудитди не расскажет мне кто, аутентифицированный >> керберосом и авторизированный ЛДАПом, получил коннект через сквид. > А вот в предлагаемой вон теми парнями схеме - чуть более другой > сервис пойдет и расскажет кто и какого хрена. В более-менее унифицированном > формате. Так вот в том-то и дело, шо нет! Просто из-за дурацкого формата будут оверхед и неудобства. Всё.
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	95. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+2 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 18:30
	> Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые > логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?. Я так понимаю - вы просто не знакомы с юниксом. Действительного, когда в мире есть лишь две оси - винда и убунта, все, что не убунта, кажется виндой. Но на самом деле в мире гораздо больше решений, и такая примитивная логика не позволит их осмыслить.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	215. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от anon9000 on 04-Мрт-12, 13:48
	имхо, он про солярку)))
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	144. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Имя и код on 03-Мрт-12, 05:37
	>> Ну наконец-то и линукс дошел до того, что в юниксе сделано уже >> двадцать лет назад. rfc3164 достаточно свежая хреннь. > Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые > логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?. Ну... Это неуспешно скрыто за зарослями бинарного формата хранения логофф. :)
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	172. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 03-Мрт-12, 13:40
	> Ну... Это неуспешно скрыто за зарослями бинарного формата хранения логофф. :) Выбросьте бинарный гзип уже? Вы его деревья хаффмана в уме вообще не построите. И на тетрадном листочке - задолбаетесь.
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	208. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Имя и код on 04-Мрт-12, 04:09
	>> Ну... Это неуспешно скрыто за зарослями бинарного формата хранения логофф. :) > Выбросьте бинарный гзип уже? Вы его деревья хаффмана в уме вообще не > построите. И на тетрадном листочке - задолбаетесь. Ну да, ну да, а изчё выинты повыбрасываем - там коды царя соломона используют. Тока ведь гзип-то, текстовой природы лога, сцуко, не меняет :)))
	Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

2. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+2 +/–
Сообщение от Аноним (??) on 02-Мрт-12, 14:28
Наверное, стоило особо отметить, что к поддержке проекта уже присоединились компания Adicson, разрабатывающая rsyslog, и BalaBit, разрабатывающая syslog-ng.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	184. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от исчо_адын_аноним on 03-Мрт-12, 15:12
	> Наверное, стоило особо отметить, что к поддержке проекта уже присоединились компания Adicson, > разрабатывающая rsyslog, и BalaBit, разрабатывающая syslog-ng. app-admin/syslog-ng-3.3.4 [3.2.5] USE="hardened ipv6 pcre ssl tcpd -caps -json% -mongodb% (-selinux) -spoof-source -sql -static%" все как у людей :) хош джисон - бери джисон, хош срать в монго ( угу, свалка ) - сри; скуль тож можно, НО! текст никто не отменя ;) А идиоту поможет только евтаназия
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	209. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Имя и код on 04-Мрт-12, 04:10
	> А идиоту поможет только евтаназия Я против подобного милосердия! В назидание! :))
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

	242. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Куяврик on 13-Мрт-12, 00:46
	> все как у людей :) хош джисон - бери джисон, хош срать > в монго ( угу, свалка ) - сри; скуль тож можно, это не интересно. где научная ценность? где новизна диссертации? вот так взял и бэкэнд заменил. нет, надо раскататть в отдельный
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

3. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+2 +/–
Сообщение от Аноним (??) on 02-Мрт-12, 14:32
Надеюсь, в линуксе наконец появится нормальный механизм удаленной репликации логов, с поддержкой шифрования и аутентификации.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Часть нити удалена модератором

	55. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–3 +/–
	Сообщение от anonymous (??) on 02-Мрт-12, 15:57
	>Нормальной репликации там нет Таки тролль. man rsyslog-mysql
	Ответить | Правка | ^ к родителю #208 | Наверх | Cообщить модератору

	63. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 16:21
	>>Нормальной репликации там нет > Таки тролль. man rsyslog-mysql А об ng-syslog никто из анонов, судя по всему, даже не слыхал никогда?
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	145. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Имя и код on 03-Мрт-12, 05:45
	>>>Нормальной репликации там нет >> Таки тролль. man rsyslog-mysql > А об ng-syslog никто из анонов, судя по всему, даже не слыхал > никогда? Конечно нет. Все знают про syslog-ng.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	178. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–1 +/–
	Сообщение от Аноним (??) on 03-Мрт-12, 14:42
	>>>>Нормальной репликации там нет >>> Таки тролль. man rsyslog-mysql >> А об ng-syslog никто из анонов, судя по всему, даже не слыхал >> никогда? > Конечно нет. Все знают про syslog-ng. Хоть горшком назови. Только в печь не ставь. Судя по тому, что вспомнил о нем один я, фатальный недостаток - основная причина появления ливня из велосипедов, идущего каждую неделю.
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	210. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Имя и код on 04-Мрт-12, 04:12
	>>>>>Нормальной репликации там нет >>>> Таки тролль. man rsyslog-mysql >>> А об ng-syslog никто из анонов, судя по всему, даже не слыхал >>> никогда? >> Конечно нет. Все знают про syslog-ng. > Хоть горшком назови. Только в печь не ставь. Не-а. Искажение названия такого популярного пакета говорит о многом. > Судя по тому, что > вспомнил о нем один я, фатальный недостаток - основная причина появления > ливня из велосипедов, идущего каждую неделю. Да прям таки.
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

	85. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 17:37
	> Таки тролль. man rsyslog-mysql А ты сам-то читал, что там написано? Особенно в части репликации логов с поддержкой шифрования и аутентификации, да в нативном формате.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	89. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 17:44
	> Таки тролль. man rsyslog-mysql Вы предлагаете конвертировать лог в бинарный формат, а потом реплицировать его средствами СУБД? Замечательно, но зачем тогда вообще нужен rsyslog? Не проще ли приложениями сразу свой лог в бинарную БД писать, через клиентскую либу мускула?
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	146. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Имя и код on 03-Мрт-12, 05:47
	>> Таки тролль. man rsyslog-mysql > Вы предлагаете конвертировать лог в бинарный формат, а потом реплицировать его средствами > СУБД? > Замечательно, но зачем тогда вообще нужен rsyslog? Не проще ли приложениями сразу > свой лог в бинарную БД писать, через клиентскую либу мускула? Немного более чем нет.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	173. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 03-Мрт-12, 13:48
	>> свой лог в бинарную БД писать, через клиентскую либу мускула? > Немного более чем нет. Это что, подтверждение мысли о ненужности rsyslog? :)
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	211. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Имя и код on 04-Мрт-12, 04:13
	>>> свой лог в бинарную БД писать, через клиентскую либу мускула? >> Немного более чем нет. > Это что, подтверждение мысли о ненужности rsyslog? :) Нет, подумайте об этом на досуге. :)))
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	94. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–2 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 18:27
	> Таки тролль. man rsyslog-mysql Репликация средствами мускула? Лол. С тем же успехом можно текстовые логи через scp по крону копировать. А че, шифрование и аутентификация есть. Другое дело, что это, во-первых, костыли (и под требование "нормальности" не попадает), во-вторых, rsyslog, который и должен этим заниматься, оказывается какбэ не при делах.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	120. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Deffic on 03-Мрт-12, 02:03
	>> Таки тролль. man rsyslog-mysql > Репликация средствами мускула? Лол. > С тем же успехом можно текстовые логи через scp по крону копировать. > А че, шифрование и аутентификация есть. > Другое дело, что это, во-первых, костыли (и под требование "нормальности" не попадает), > во-вторых, rsyslog, который и должен этим заниматься, оказывается какбэ не при > делах. Делайте силой мыли, ибо всё остальное - КОСТЫЛИ!
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	132. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–1 +/–
	Сообщение от Аноним (??) on 03-Мрт-12, 03:53
	> Делайте силой мыли, ибо всё остальное - КОСТЫЛИ! Не, дядя, мускуль в обязательном порядке для всего лишь ведения логов - это мегакостыль.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	226. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Deffic on 05-Мрт-12, 22:33
	>> Делайте силой мыли, ибо всё остальное - КОСТЫЛИ! > Не, дядя, мускуль в обязательном порядке для всего лишь ведения логов - > это мегакостыль. Вы передёргиваете.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

4. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
Сообщение от Аноним (??) on 02-Мрт-12, 14:32
> В ходе встречи участники обсудили такие слабые места текущих подходов к ведению журнала событий как недостаточное внимание к журналированию со стороны разработчиков приложений, *разнообразие форматов журнальных записей* Разнообразие форматов журналов следует из разнообразия решаемых задач и разнообразия видов отображаемой информации, хотя не всегда. Унификация, конечно, хороша, но тут главное не переборщить
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+5 +/–
Сообщение от Аноним (??) on 02-Мрт-12, 14:32
Лучшее враг хорошего.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+2 +/–
Сообщение от Аноним (??) on 02-Мрт-12, 14:46
а почему сислог они считают устаревшим? чем аргументируют?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–2 +/–
	Сообщение от anonymous (??) on 02-Мрт-12, 14:47
	http://bb.comp-house.ru/comp-house.repo/wiki/what-i-dont-lik...
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	16. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 14:48
	> http://bb.comp-house.ru/comp-house.repo/wiki/what-i-dont-lik... Как видим, Герхардса с его проповедями про превосходство rsyslog успешно заткнули =)
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	23. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–1 +/–
	Сообщение от anonymous (??) on 02-Мрт-12, 14:55
	>> http://bb.comp-house.ru/comp-house.repo/wiki/what-i-dont-lik... > Как видим, Герхардса с его проповедями про превосходство rsyslog успешно заткнули =) http://bb.comp-house.ru/comp-house.repo/wiki/journald-and-rs...
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	28. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–1 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 15:04
	> http://bb.comp-house.ru/comp-house.repo/wiki/journald-and-rs... Устаревшая инфа. Судя по сабжевой новости, теперь мнение этого товарища радикально переменилось, и он уже рвется помочь Поттерингу с допилом journald.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	43. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 15:18
	> а почему сислог они считают устаревшим? > чем аргументируют? Не умеет работать со структурированными данными (нет поддержки соответствующих форматов и API).
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

22. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
Сообщение от Аноним (??) on 02-Мрт-12, 14:55
Так что теперь будет с journald?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	25. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от anonymous (??) on 02-Мрт-12, 14:58
	> Так что теперь будет с journald? А ничего не будет. Он часть systemd и останется. Сделают пересылку в другой журнал, так же как сейчас пересылается в rsyslog. Дублирование журнала в разных форматов уже ни кого не пугает.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	29. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от VoDA (ok) on 02-Мрт-12, 15:05
	> Так что теперь будет с journald? К нему кроме его текущего API добавят ELAPT. А возможно ELAPI будет единственным API к jourland. Плюс для back compatibility оставят некий интерфейс эмулирующий syslog.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	32. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 15:06
	> К нему кроме его текущего API добавят ELAPT. А возможно ELAPI будет единственным API к jourland. Скорее второе - нынешний API journald пока не стабилизирован, поэтому сейчас его проще и удобнее подогнать под ELAPI.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	31. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 15:05
	> Так что теперь будет с journald? Судя по всем, Lamberjack - это и есть journald, с небольшими косметическими изменениями. Так что скорее всего эти проекты объединят.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

41. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
Сообщение от Michael Shigorin (ok) on 02-Мрт-12, 15:15
> Две недели назад компания Red Hat собрала в своем офисе > разработчиков популярных систем ведения логов, чтобы обсудить Радует то, что постарались обсудить, а не переть своим умом; удачи.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	61. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 16:19
	> Радует то, что постарались обсудить, а не переть своим умом; удачи. А может, они с systemd/upstart еще повторят? Для полного счастья? :)
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	66. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 16:25
	>> Радует то, что постарались обсудить, а не переть своим умом; удачи. > А может, они с systemd/upstart еще повторят? Для полного счастья? :) А может, они-таки наймут ОДНОГО вменяемого системного архитектора? И сделают ЕДИНОЕ решение? Совместимость-то важней и производительности и всего остального, если уж на то пошло. Актуальность этой максимы за 35 лет в ИТ посейчас не изменилась.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	71. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–1 +/–
	Сообщение от Michael Shigorin (ok) on 02-Мрт-12, 16:57
	> И сделают ЕДИНОЕ решение? Даже у очень умных людей решения в стиле "вот, оно, единое" имеют тенденцию оказываться ущербными не в одном, так в другом.  Именно поэтому юниксы с совместимостью по интерфейсам, а не искуственным вырождением поля реализаций, и живы вовсю до сих пор. > Актуальность этой максимы за 35 лет в ИТ посейчас не изменилась. Надо же, юниксы пятый десяток разменяли давно, а некоторые всё чуть ли не виндой мерить привыкли...
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	179. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 03-Мрт-12, 14:45
	>> И сделают ЕДИНОЕ решение? > Даже у очень умных людей решения в стиле "вот, оно, единое" имеют > тенденцию оказываться ущербными не в одном, так в другом.  Именно > поэтому юниксы с совместимостью по интерфейсам, а не искуственным вырождением поля > реализаций, и живы вовсю до сих пор. Мы это видим с каждым новым дистром линукса, которые уже числом, тащемта, за штуку перевалили. И, кстати, Linux is NOT UNIX (C) Линус, евжли память мне не врет. Так шта, дорогой друг, ты прокламацию-то с проституцией б не путал. >> Актуальность этой максимы за 35 лет в ИТ посейчас не изменилась. > Надо же, юниксы пятый десяток разменяли давно, а некоторые всё чуть ли > не виндой мерить привыкли... Гонишь. Юникс появился как система примерно в 1975м году. Я 67го года рождения и мне, как ты понимаешь, не пятьдесят. Это ты, видимо, админ с 1995 года.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	191. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Michael Shigorin (ok) on 03-Мрт-12, 19:39
	> И, кстати, Linux is NOT UNIX (C) Линус, евжли память мне не врет. > Так шта, дорогой друг, ты прокламацию-то с проституцией б не путал. Хм, пока похоже, что путаете GNU's Not UNIX с чем-то неприпоминаемым из высказываний Линуса как раз Вы; впрочем, не настаиваю. > Гонишь. Юникс появился как система примерно в 1975м году. Меня тогда ещё не было, как и летом 1969 -- так что спорить об официальной дате появления UNIX Вам придётся с другими людьми. > Я 67го года рождения и мне, как ты понимаешь, не пятьдесят. Hint: стукнет полтинник, вот и разменяете свой шестой десяток. (неужто незнакомое выражение?) > Это ты, видимо, админ с 1995 года. Вы мне льстите, тогда только-только в интернеты добрался... даже локалхоста своего ещё не было и программы многие писались между походами на кружок и другую машину в тетрадках. PS: вру, кружки ввиду 145-ки тогда уже пошли лесом.
	Ответить | Правка | ^ к родителю #179 | Наверх | Cообщить модератору

	73. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 02-Мрт-12, 17:04
	> И сделают ЕДИНОЕ решение? А кто не согласен - будет расстрелян, так?
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	118. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–2 +/–
	Сообщение от Аноним (??) on 03-Мрт-12, 00:35
	А у несогласных никуда всегда была gentoo.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	155. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Имя и код on 03-Мрт-12, 07:10
	> А у несогласных никуда всегда была gentoo. LFS
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	167. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от zzz (??) on 03-Мрт-12, 13:21
	> А у несогласных никуда всегда была gentoo. А что делать тем кому не нравится пидон в каждой дырке в системе? :)
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	91. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Аноним (??) on 02-Мрт-12, 17:50
	> А может, они с systemd/upstart еще повторят? Для полного счастья? :) А что там повторять? Сейчас разработка upstart фактически превратилась в копипасту с systemd, так что понятно, кто в избе хозяин. Вообще, на последнем фосдеме был слушок, что убунта собирается переходить на systemd начиная с 12.10 (сразу после выпуска LTS).
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	133. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 03-Мрт-12, 03:55
	> А что там повторять? Сейчас разработка upstart фактически превратилась в копипасту с > systemd, так что понятно, кто в избе хозяин. Ну вот я как раз за то чтобы они собрались и обсудили как и чего. К systemd больно дофига предъяв - то usr ему не там, то run не там, то еще дерьмо какое-то случается. Почему-то с upstart таковых воплей было ровно НОЛЬ... > Вообще, на последнем фосдеме был слушок, Пруф? Мы тут не старые карги на лавочке, так что сарафанное радио нас не устраивает.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	217. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от qux (ok) on 04-Мрт-12, 17:01
	> К systemd больно дофига предъяв - то usr > ему не там, то run не там, то еще дерьмо какое-то > случается. Почему-то с upstart таковых воплей было ровно НОЛЬ... >> Вообще, на последнем фосдеме был слушок, > Пруф? Мы тут не старые карги на лавочке, так что сарафанное радио > нас не устраивает. Это вам-то пруф, с предъявами о usr? Кто еще не видел: http://freedesktop.org/wiki/Software/systemd/separate-usr-is...
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

110. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
Сообщение от pavlinux (ok) on 02-Мрт-12, 22:17
Чё они х...ей занимаются! Нужно структурированные, ну прилепи ты syslog2sql и радуйся жизни?! Движок есть - mysql, pgsql, mssql,...sql Формат есть - SQL На SQL даже какой-то стандарт есть! Осталось самую малость - заставить программистов писать SQL запросы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	127. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от VoDA (ok) on 03-Мрт-12, 03:16
	> Чё они х...ей занимаются! Нужно структурированные, ну прилепи ты syslog2sql и радуйся > жизни?! бинарное хранение это следствие, а не причина. причина же в API для структурированных данных. структурированные данные можно и текстом хранить (хоть в csv). но syslog имеет API для неструктурированных данных (просто текст). если поменять API то можно безболезненно заменить syslog на journald или иной логгер. вся проблема в том, чтобы сменить API с "лапшового" на строго структурированный.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	134. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 03-Мрт-12, 03:59
	> Чё они х...ей занимаются! Нужно структурированные, ну прилепи ты syslog2sql и радуйся ... всяким там возможным SQL-иньекциям? :) И да, как sql база обеспечит защиту от удаления записи задним числом, например?
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	222. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от pavlinux (ok) on 05-Мрт-12, 01:24
	> И да, как sql база обеспечит защиту от удаления записи задним числом, например? REVOKE ALL ON logdbase TO logodmin@'localhost'; GRANT INSERT ON logdbase TO logodmin@'localhost' IDENTIFIED BY 'passwd';
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	150. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–1 +/–
	Сообщение от XoRe (ok) on 03-Мрт-12, 06:15
	> Чё они х...ей занимаются! Нужно структурированные, ну прилепи ты syslog2sql и радуйся > жизни?! > Движок есть - mysql, pgsql, mssql,...sql > Формат есть - SQL > На SQL даже какой-то стандарт есть! > Осталось самую малость - заставить программистов писать SQL запросы. А зачем SQL запросы, когда есть NoSQL решения? С хранением данных чисто в оперативке! Вам что, жалко пару десятков гигабайт оперативки под логи)
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

113. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–2 +/–
Сообщение от Аноним (??) on 02-Мрт-12, 22:46
Сколько же воплей в этом треде... Никаких lumberjack и journald не будет ближайшее время. Успокойтесь. А что плохо и что хорошо, будут решать люди поумнее нас.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	135. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (??) on 03-Мрт-12, 04:00
	> люди поумнее нас. См. #128 :)
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	241. "Представлен проект Lumberjack, нацеленный на..."	+/–
	Сообщение от arisu (ok) on 06-Мрт-12, 05:16
	> люди поумнее нас. я, например, раз уж ты себя не считаешь достойным.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

149. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+5 +/–
Сообщение от XoRe (ok) on 03-Мрт-12, 06:13
Название - игра слов. log - бревно. Lumberjack - дровосек. Т.е. логоруб) Нам предлагают систему, которая будет рубить логи. На корню) Логи пишутся, чтобы их прочитать, а не чтобы их записать. Имхо, ради средства жертвуют целью - удобством чтения. Процесс ради процесса. <offtopic> В последнее время стало модным внедрять что-то бинарное. systemd, upstart, система логов от Поттеринга. У Microsoft сначала были ini файлы. Потом они разработали "реестр". Если сделать дамп реестра и сравнить его формат с форматом ini файла, можно найти, что они похожи. Примерно, как братья-близнецы. Это тот же самый ini файл, только теперь в бинарном формате, раскиданный по нескольким файлам. MS не придумал ничего лучше, чем сделать ini файлы в бинарном формате. Что мы получили? 1. программы для дефрагментации реестра 2. файлы реестра раскиданы по разным местам 3. эти файлы просто так не скопировать, не открыть 4. а если их и скопировать, то чтобы открыть эти файлы, нужна специальная утилита Прогресс, *ля. Как я рад, что в *nix для системных и пользовательских настроек используется первобытный и допотопный plain text формат. Что позволяет открыть логи и конфиги 20 летней давности даже сейчас. Без риска получить ошибку "неподдерживаемый формат. пересохраните данные в новом формате." </offtopic>
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	156. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Имя и код on 03-Мрт-12, 07:13
	> Название - игра слов. > log - бревно. > Lumberjack - дровосек. > Т.е. логоруб) > Нам предлагают систему, которая будет рубить логи. > На корню) > Логи пишутся, чтобы их прочитать, а не чтобы их записать. > Имхо, ради средства жертвуют целью - удобством чтения. > Процесс ради процесса. Адназначна! :)
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	161. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от Аноним (??) on 03-Мрт-12, 11:58
	> MS не придумал ничего лучше, чем сделать ini файлы в бинарном формате. Что мы получили? 1. программы для дефрагментации реестра 2. файлы реестра раскиданы по разным местам 3. эти файлы просто так не скопировать, не открыть 4. а если их и скопировать, то чтобы открыть эти файлы, нужна специальная утилита Прогресс, *ля. Думаю, это легко объяснимо. MS важно привлечь разработчиков, а реестр - это отличный и легкий способ сохранять всякий мусор между запусками программы, не нагружая мозг программиста на вижуал бейсике вопросами формата конфига и его местонахождения. Реестр непрерывно захламляется, но это не сразу становится заметно и не отталкивает пользователей от системы, которые в это время осторожно двигают мышь одним пальцем и разглядывают иконки на раб. столе, как баран новые ворота. Ну а раз в полгода винду переустанавливать не так уж сложно :)
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

186. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
Сообщение от Аноним (??) on 03-Мрт-12, 17:05
ну скажем так. если требуется для каких-то целей строить по логам статистику - предложенный подход вполне оправдан. если у тебя 50 гигов жатых гзипом логов, делать по ним grep несколько накладно. однако такие задачи возникают редко. то что они пишут о парсерах - тоже правда. вот давеча добавил поле в логформат, пришлось пепенастраивать awstats (тоже описывать там новый логфорат). однако хранение логов в структурированном бинарном формате во многих случаях действительно неудобно. хотя есть дебаг логи где в лог пишется объект в json или что-нибудь такое, грепать по ним нереально.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	199. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+1 +/–
	Сообщение от nobody (??) on 04-Мрт-12, 02:37
	> ну скажем так. если требуется для каких-то целей строить по логам статистику > - предложенный подход вполне оправдан. если у тебя 50 гигов жатых > гзипом логов, делать по ним grep несколько накладно. однако такие задачи > возникают редко. то что они пишут о парсерах - тоже правда. > вот давеча добавил поле в логформат, пришлось пепенастраивать awstats (тоже описывать > там новый логфорат). однако хранение логов в структурированном бинарном формате во > многих случаях действительно неудобно. хотя есть дебаг логи где в лог > пишется объект в json или что-нибудь такое, грепать по ним нереально. Если нужна статистика, то и сейчас вообще не проблема, например через пайп или по сети из сислога получать всё, парсить и складывать то, что нужно в базу. А то что пишут о парсерах - имхо чушь, при добавлении нового поля не так уж сложно поправить парсер, это обычная работа системного инженера/админа - не понимаю, в чём проблема то? какую проблему решает ламберджек? помоему надуманную, которая не существует за пределами сознаний поттерингов... зато проблемы, которые возникнут при попытке эту надуманную проблему "решать", станут вполне реальными. Хочется верить, что по крайней мере в Debian эти инициативы будут расценены адекватно, даже если в итоге красная шляпа подпишется на эти сомнительные инновации и реализует это. Вообще следующим логичным шагом для красной шапки будет перенести в бинарный вид и конфиги, редактировать их через отдельное новое апи сторонними тулзами, привет редакторы реестра :) Останется выпилить шеллы, тк они, внезапно, станут особо больше не нужны никому. И после этого редхет с убунтой станут сильно напоминать то, что хотели забыть как страшный сон, люди мигрировавшие на лиункс с самой популярной ОС. История имеет свойство повторять себя, потому что никто на ней не учится, "10000 ли за спиной, а грабли всё те же" (с).
	Ответить | Правка | ^ к родителю #186 | Наверх | Cообщить модератору

198. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
Сообщение от vi on 04-Мрт-12, 02:12
Похоже кто то хочет подзаработать на неграмотности админов. Что ж, флаг им в руки. Им тоже денежки зарабатывать надо.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

212. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	–2 +/–
Сообщение от Piter_Ring (ok) on 04-Мрт-12, 05:06
Линуксоиды воистину неизлечимы :) Вместо того что бы "механизировать" ручной труд они предлагают разработать очередного "дровосека". Для несведущих; у Финов есть поговорка, дословно не помню, но суть примерно следующая: - мы используем Тимберджек, а Русские - Лумберджек (по фински звучит даже без перевода вполне унизительно). Для справки: тимберджек: http://www.youtube.com/watch?v=QoC3tBwR0eA&feature=related лумберджек: http://www.youtube.com/watch?v=xnpKzOvxaJI&feature=player_de... ЗЫ: модераторам: сообщение написано на стенке химическим карандашом. смывать, закрашивать - бесполезно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	216. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Michael Shigorin (ok) on 04-Мрт-12, 15:26
	> модераторам: сообщение написано на стенке химическим карандашом. Некоторые из нас понимают в красителях => способны без смывания и закрашивания развалить сопряжённые связи ;) Что сказать-то хотели?
	Ответить | Правка | ^ к родителю #212 | Наверх | Cообщить модератору

	223. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Piter_Ring (ok) on 05-Мрт-12, 01:42
	>> модераторам: сообщение написано на стенке химическим карандашом. > Некоторые из нас понимают в красителях => способны без смывания и закрашивания > развалить сопряжённые связи ;) > Что сказать-то хотели? Если сильно постараются, то данный проект может вырасти и вместо http://www.youtube.com/watch?v=xnpKzOvxaJI получат вполне успешный результат типа http://www.youtube.com/watch?v=zFGva6ZS4fU&feature=related
	Ответить | Правка | ^ к родителю #216 | Наверх | Cообщить модератору

	224. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Michael Shigorin (ok) on 05-Мрт-12, 02:21
	> Если сильно постараются, то данный проект может вырасти и вместо Это вообще какой-то виндузятник с перочинным топориком; непонятно, кто лесорубом назвал. > получат вполне успешный результат типа ...способного отхватить ноги сразу двоим, если замешкаются?.. Так ведь не все на машине в булочную за углом ездють, есть и вменяемые люди.  Технологии сейчас и так страдают недостатком человекопознаваемости в разумные сроки и как следствие -- диагностируемости. PS: если что, у нас свою подсистему распределённого журналирования писали.  И я ни разу не хочу столько сущностей у себя на ноутбуке, даже близко.  На несколько тысяч хостов они оправданы, на один -- никак.
	Ответить | Правка | ^ к родителю #223 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема