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

Представлен проект Lumberjack, нацеленный на модернизацию си..., opennews (??), 02-Мрт-12, (0) [смотреть все] Судя по неоднократному упоминанию структурированных данных , основной формат хр, Аноним (-), 14:25 , 02-Мрт-12, (1) +8 // А чем бинарный формат принципиально лучше текстового Индексы и по текстовым стр, Аноним (-), 14:34 , 02-Мрт-12, (6) +7   // Основных причины две 1 Недостаточная компактность Особенно неприятно отсутстви, Аноним (-), 14:53 , 02-Мрт-12, (18) +8   // Это попытка переизобрести gzip Феерический бред , anonymous (??), 15:05 , 02-Мрт-12, (30) –4   В какой-то степени Но только такой gzip, который позволяет работать сразу со сж, Аноним (-), 15:11 , 02-Мрт-12, (37) +4   Кто мешает пожать и проиндексировать текстовый файл Где ты увидел стабильный API, anonymous (??), 15:22 , 02-Мрт-12, (46) –5   Если поля не удаляются, а только добавляются новые, то, по идее, старые анализат, Аноним (-), 15:45 , 02-Мрт-12, (50) +1   Ага, щаз Ты представление-то имеешь, как парсеры работают , Аноним (-), 16:16 , 02-Мрт-12, (58) –3   Нет Речь шла о структурированном логе со специальным API для работы с ним Есл, Аноним (-), 16:37 , 02-Мрт-12, (68) +1   Структурированные данные, индексируемые данные, множества данных Если кто не п, Wolfis (?), 16:38 , 02-Мрт-12, (69)   Ну допустим я имею, ламерок Для тех кто в танке что сломается в SQL при добавл, Аноним (-), 19:24 , 02-Мрт-12, (102)   В этой теме про него лучше не вспоминать А то, знаете как помянешь черта и он, XoRe (ok), 22:07 , 02-Мрт-12, (107) +4   OSMщики с XML уже наелись, как стали портянги в 250 гигз, которые в бинарном фор, Аноним (-), 04:02 , 03-Мрт-12, (136)   Это типа каждый раз альтер тейбл, который, конечно же, вовсе не накладная операц, Имя и код (?), 06:07 , 03-Мрт-12, (148) +1   а что сломается в парзере, например, 171 по строке на запись, поля поделены од, arisu (ok), 04:43 , 06-Мрт-12, (233)   хорошо работают, если писались руками и изначально формат нормальный 171 перв, arisu (ok), 04:40 , 06-Мрт-12, (232)   Современный текстовый лог представляет собой текстовую кашу, которую индексирова, Аноним (-), 17:20 , 02-Мрт-12, (76)   чем это отличается от 171 каши 187 , не подскажешь , arisu (ok), 04:44 , 06-Мрт-12, (234)   А индекс образуется сам собой, причём совершенно задаром , anonimous (?), 00:14 , 03-Мрт-12, (115)   А в случае текстаря его еще и хранить надо где-то сильно сбоку , Аноним (-), 04:04 , 03-Мрт-12, (137)   Gzip не позволяет доступ на ходу А 20 гиговую портянку сам, пожалуйста, декомпр, Аноним (-), 17:40 , 02-Мрт-12, (86) +1   Против 20гиговых логов есть ротация Кто не настроил, тот - На средненагружен, XoRe (ok), 22:11 , 02-Мрт-12, (109) +3   Угу, что однако не отменяет факта что логи могут быть большими даже с ротацией , Аноним (-), 03:12 , 03-Мрт-12, (124) –1   Пожалуйста, давайте об устрицах -- емши Локальное хранение логов нередко весьма , Michael Shigorin (ok), 03:38 , 03-Мрт-12, (129)   А чем проблемы с синхронной записью там - лучше чем с синхронной записью где-то , Аноним (-), 04:06 , 03-Мрт-12, (138)   Выделенный коллектор логов обслуживает исключительно логи, а не целевой сервис , anonimous (?), 07:57 , 03-Мрт-12, (158)   Целевой сервис не обязан интенсивно писать на диск, если что Более того, не у в, zzz (??), 12:34 , 03-Мрт-12, (163)   fsync очень даже бьёт и по чтению Если же сервис со всем нужным помещается в, Michael Shigorin (ok), 19:24 , 03-Мрт-12, (189)   Может, но насколько именно - весьма зависит от А еще можно логи хранить на отдел, Аноним (-), 17:35 , 04-Мрт-12, (218)   Дядьку, я Вам это по куче систем с самым разным стораджем говорю Это и упомянул , Michael Shigorin (ok), 20:47 , 04-Мрт-12, (220)   Тем, что подсистема I O может быть к ним лучше готова Даже локально отделить акт, Michael Shigorin (ok), 19:01 , 03-Мрт-12, (187)   Сервер отгружающий бочками файло и не готовый к интенсивному I O довольно странн, Аноним (-), 17:45 , 04-Мрт-12, (219)   см тж 220 Так у отгружающего может быть заточка под отгрузку -- приличный re, Michael Shigorin (ok), 20:48 , 04-Мрт-12, (221)   могут быть - это предположение факт - это бл , вот это логи отожрали А с фак, XoRe (ok), 05:59 , 03-Мрт-12, (147) +5   Элементарно - минимальная атака на сервак где они в крейсерском режиме нормальны, zzz (??), 07:54 , 03-Мрт-12, (157)   Уважаемый, вы бы посмотрели, на какие тезисы я отвечаю Там как раз хотели за сут, XoRe (ok), 14:18 , 03-Мрт-12, (174) +1   Во первых, заранее сложно сказать за какой интервал потребуются логи Во вторых,, Аноним (-), 00:59 , 04-Мрт-12, (192)   Уважаемый, вы хотя бы раз logcheck настраивали , vi (?), 02:08 , 04-Мрт-12, (196)   Ну ётыдь, ну шо за вьюные разжижения мозгофекалий Воопще-то построение скалейбл, Имя и код (?), 06:29 , 03-Мрт-12, (151)   Я тоже не понял Поэтому попробуйте изложить мысль внятно и без задействования ж, Аноним (-), 13:25 , 03-Мрт-12, (168)   Ну что за дети пошли Какие понты, исключительно профессиональная терминология, Имя и код (?), 03:33 , 04-Мрт-12, (200) +1   это не 171 профессиональная терминология 187 , это кулхацкерский мунспик был , arisu (ok), 04:50 , 06-Мрт-12, (235)   Логи в продакшене отключают только идиоты Вменяемые админы, если дисковое и о и, nobody (??), 22:19 , 02-Мрт-12, (111) +9   Мне пытаются впарить мысль, что DB будет быстрее, чем plain-file на одном , anonimous (?), 00:18 , 03-Мрт-12, (116) +1   работа с БД в большинстве случаев быстрее plain-file начиная с того, что нормал, VoDA (ok), 02:58 , 03-Мрт-12, (122)   Значит формат должен допускать лобовой и быстрый инсерт максимально компактных з, zzz (??), 12:28 , 03-Мрт-12, (162) –1   То есть атрибута навроде src_ip в блобгах Вы не предполагаете 8- Упаковка на , Michael Shigorin (ok), 19:20 , 03-Мрт-12, (188)   Предполагаю, но полагаю что возможность сокращенно референсить повторную информа, Аноним (-), 01:25 , 04-Мрт-12, (193)   1 каков критерий повторности 2 референсить можно и в текстовом, вопрос в цене , Michael Shigorin (ok), 01:57 , 04-Мрт-12, (195) +1   Угу С блэкджеком и шлюхами Да пофигу, ибо не уточнять, но идентифицировать , Имя и код (?), 03:38 , 04-Мрт-12, (201)   А кто вас сказал чтоб это будет реляционная СУБД шарашить с спец формате расс, VoDA (ok), 15:06 , 03-Мрт-12, (183)   Вы Вы описываете тютелька в тютельку именно такую DBMS и потом удивлённо развод, Имя и код (?), 03:49 , 04-Мрт-12, (203) +1   Однако, как указывает К Дейт, нормализация в точности и является теми принципам, VoDA (ok), 00:45 , 06-Мрт-12, (227)   йопт на поиск 171 повторяющихся элементов 187 в словарях время уходит, нет , arisu (ok), 04:58 , 06-Мрт-12, (236)   Пытаются впарить мысль что запись эвента в минимальном бинарном виде без повторя, Аноним (-), 03:16 , 03-Мрт-12, (126)   Ну иоптыдь, Опенстриты, они читают на порядки чаще, нежели пишут , Имя и код (?), 04:57 , 03-Мрт-12, (140)   Пишут его тоже часто и много И работать с 250Г чушкой в XML попросту не приколь, Аноним (-), 06:31 , 03-Мрт-12, (152)   Повторюсь на порядки меньше , Имя и код (?), 03:39 , 04-Мрт-12, (202)   ну и какой идиот изначально додумался базу с необходимым по дизайну random acces, arisu (ok), 05:00 , 06-Мрт-12, (237)   Дедупликация подразумевает сложную структуру хранения, подобную реляционной или , gaga (ok), 15:21 , 02-Мрт-12, (45) +1   То же самое можно сказать про любую SQL-совместимую СУБД Но почему-то среди них, Аноним (-), 17:23 , 02-Мрт-12, (77)   все твои улыбки в основном от того, что ты считаешь one size fits all и волшеб, arisu (ok), 05:02 , 06-Мрт-12, (238)   Угу, аж возможность референса в сторону - а вот это уже было, брать вон там вот, Аноним (-), 17:29 , 02-Мрт-12, (80) +2   Анализировать быстро и на автомате и ловить потенциально интересные эвенты довол, Аноним (-), 16:17 , 02-Мрт-12, (59) +1   // Заметим, что идея грепа лога сама по себе порочна Добавление в строку нового по, Аноним (-), 17:25 , 02-Мрт-12, (78) +1   Я бы сказал 50 50, потому что гибкость - хорошая, да И позволяет завернуть очен, Аноним (-), 17:34 , 02-Мрт-12, (83)   Хм Вы когда-нибудь с SQL работали Скажу по секрету там возможностей для хитро, Аноним (-), 17:41 , 02-Мрт-12, (87) +1   Practical Extraction and Report Language На SQL-е - умахаешься Впрочем поЦеринг, Anonymouse (?), 03:13 , 03-Мрт-12, (125) +1   1 Я не считаю что для анализа логов мне надо бросить все и стать DBA2 Я не счи, Аноним (-), 03:50 , 03-Мрт-12, (130) +2   Т е вы хотите сказать, что DSL, коим является SQL имеет больше возможностей, че, cosmonaut (ok), 12:09 , 04-Мрт-12, (213) +1   Да, вспоминается, как аккуратненько добавил разок дополнительное поле в конец ло, Аноним (-), 18:38 , 02-Мрт-12, (99) +1   Узкое место --- не в чтении парсинге поиске, в записи поиск --- значительно бо, anonimous (?), 00:26 , 03-Мрт-12, (117)   Не-а, бинарь в принципе не удобен Эт раз Для первичного анализа берутся не сам, Имя и код (?), 05:16 , 03-Мрт-12, (142) –1   Бинарь в принципе ничем не отличается от текстаря Поскольку вы не читаете секто, zzz (??), 13:18 , 03-Мрт-12, (166)   Не текстовый формат весьма и весьма не удобен Малоюзабелен Никто вотпрямща и н, Имя и код (?), 03:56 , 04-Мрт-12, (204)   Итак, давайте обдумаем Допустим что syslog действительно устарела устаревание , Аноним (-), 15:18 , 02-Мрт-12, (44) –4 // Слишком много букв Но что делать, если утилита посчитает бинарный лог испорченн, anonymous (??), 15:30 , 02-Мрт-12, (48) // Снова на второстепенные вещи отвлекаетесь 1 Много букв потому то в тексте подро, Аноним (-), 15:47 , 02-Мрт-12, (51) –1 Это важный вопрос, но не первой важности, т к он не определяет архитектуру и во, Аноним (-), 15:52 , 02-Мрт-12, (53) Об этом и речь была Цитирую разница между бинарными и текстовымы форматами хр, Аноним (-), 16:01 , 02-Мрт-12, (57) Разница между текстовым и бинарным форматом - логическое следствие разницы между, Аноним (-), 17:46 , 02-Мрт-12, (90) –1 Вы не врубаетесь в самую суть формат хранения логов это второстепенные вещи и н, Аноним (-), 19:17 , 02-Мрт-12, (100) Поддреживаю Собершенно непонятно вокруг чего проблема, если нужны структурирован, Deffic (?), 01:59 , 03-Мрт-12, (119) +2 Проблема сделать логи структурированными Решение этой задачи попутно решит ряд , VoDA (ok), 03:09 , 03-Мрт-12, (123) Она УЖЕ структурирована, в эрэфсях это чётко прописано это свежий The syslog m, Имя и код (?), 06:44 , 03-Мрт-12, (153) +1 Ему раскидали то что он уткнулся лишь в поверхностные, второстепенные вещи, но о, Аноним (-), 10:23 , 03-Мрт-12, (159) И самое забавное, что своими действиями усугубляет именно в этом направлении , Имя и код (?), 12:40 , 03-Мрт-12, (164) Ну так перцы тоже решили реализовать стандарт А то что он бинарный - ну и болт , Аноним (-), 13:37 , 03-Мрт-12, (170) –1 Вы просто передёргиваете gzip, cat, EDITOR -- универсальные, в отличие от , Michael Shigorin (ok), 19:30 , 03-Мрт-12, (190) А что мешает сделать прозрачную развертку этого формата в текст как gzip это дел, Аноним (-), 01:34 , 04-Мрт-12, (194) Вот Вы как понимаю в 193 описали сворачивание по IP Попробуйте набросать ст, Michael Shigorin (ok), 02:08 , 04-Мрт-12, (197) gt оверквотинг удален Вы правы - это тайный набор знаний Его специально выдел, VoDA (ok), 00:54 , 06-Мрт-12, (228) Я и подводил пишущего к мысли, что мы, скорее всего, попадаем на мини-DB и мини-, Michael Shigorin (ok), 01:17 , 06-Мрт-12, (230) Сам MSG не структурирован Как по вашему задаются обязательные и дополнительные , VoDA (ok), 15:23 , 03-Мрт-12, (185) От ёптыдь, попробую объяснить по аналогии Вы про тисипиайпи слыхивали Про т, Имя и код (?), 04:03 , 04-Мрт-12, (205) +1 Аналогия интересна, но не верна Изначальный постулат, который я развиваю это нео, VoDA (ok), 01:02 , 06-Мрт-12, (229) Тогда с ним делать то же что и с испорченным текстовым логом Открыли вы текстар, Аноним (-), 03:52 , 03-Мрт-12, (131) А вы подумали о том, что старый API взаимодействия приложений с syslog не предна, Аноним (-), 17:34 , 02-Мрт-12, (82) // Не вижу никаких проблем чтобы расширить API Это дело одного коммита Длинное соо, Аноним (-), 10:31 , 03-Мрт-12, (160) угу один всемирный такой коммит, который автомагически поправит все клиенты , arisu (ok), 05:09 , 06-Мрт-12, (240) В чем-то вы правы В своем посте я немножечко пожертвовал логичностью ради пров, Аноним (-), 18:25 , 02-Мрт-12, (93) // А мне вот не нравится идея бинарных логов И бинарных конфигов Просто - не нрав, Куяврик (?), 02:40 , 03-Мрт-12, (121) Вот, если бы вы знали, что такое cat,grep,sed и другие умные слова для работы с , cosmonaut (ok), 12:37 , 04-Мрт-12, (214) На 100 выпускник какого-нибудь ВУЗа типа Мэждународного Университета Соломона, Имя и код (?), 05:30 , 03-Мрт-12, (143) +1 // Будем знакомы И как оно вам, бакалаврам , Аноним (-), 13:38 , 03-Мрт-12, (171) Нам такие как Вы бакалавры забавны , Имя и код (?), 04:04 , 04-Мрт-12, (206) Я так понимаю - очепятка В UNIX syslog, и он пишет текстовые логи Я так понима, R (?), 16:34 , 02-Мрт-12, (67) –4 // А еще в UNIX auditd который гораздо важнее syslog , и он пишет бинарные логи , Аноним (-), 17:36 , 02-Мрт-12, (84) // А мексиканского кактуса бритого он важнее аудитди не расскажет мне кто, аутенти, Имя и код (?), 07:06 , 03-Мрт-12, (154) А вот в предлагаемой вон теми парнями схеме - чуть более другой сервис пойдет и , Аноним (-), 13:35 , 03-Мрт-12, (169) Так вот в том-то и дело, шо нет Просто из-за дурацкого формата будут оверхед и , Имя и код (?), 04:06 , 04-Мрт-12, (207) Я так понимаю - вы просто не знакомы с юниксом Действительного, когда в мире ест, Аноним (-), 18:30 , 02-Мрт-12, (95) +2 // имхо, он про солярку , anon9000 (?), 13:48 , 04-Мрт-12, (215) rfc3164 достаточно свежая хреннь Ну Это неуспешно скрыто за зарослями бинарно, Имя и код (?), 05:37 , 03-Мрт-12, (144) // Выбросьте бинарный гзип уже Вы его деревья хаффмана в уме вообще не построите , Аноним (-), 13:40 , 03-Мрт-12, (172) Ну да, ну да, а изчё выинты повыбрасываем - там коды царя соломона используют То, Имя и код (?), 04:09 , 04-Мрт-12, (208) Наверное, стоило особо отметить, что к поддержке проекта уже присоединились комп, Аноним (-), 14:28 , 02-Мрт-12, (2) +2 // app-admin syslog-ng-3 3 4 3 2 5 USE hardened ipv6 pcre ssl tcpd -caps -json , исчо_адын_аноним (?), 15:12 , 03-Мрт-12, (184) +1 // Я против подобного милосердия В назидание , Имя и код (?), 04:10 , 04-Мрт-12, (209) это не интересно где научная ценность где новизна диссертации вот так взял и , Куяврик (?), 00:46 , 13-Мрт-12, (242) Надеюсь, в линуксе наконец появится нормальный механизм удаленной репликации лог, Аноним (-), 14:32 , 02-Мрт-12, (3) +2 Таки тролль man rsyslog-mysql, anonymous (??), 15:57 , 02-Мрт-12, (55) –3 А об ng-syslog никто из анонов, судя по всему, даже не слыхал никогда , Аноним (-), 16:21 , 02-Мрт-12, (63) Конечно нет Все знают про syslog-ng , Имя и код (?), 05:45 , 03-Мрт-12, (145) +1 Хоть горшком назови Только в печь не ставь Судя по тому, что вспомнил о нем од, Аноним (-), 14:42 , 03-Мрт-12, (178) –1 Не-а Искажение названия такого популярного пакета говорит о многом Да прям так, Имя и код (?), 04:12 , 04-Мрт-12, (210) +1 А ты сам-то читал, что там написано Особенно в части репликации логов с поддержк, Аноним (-), 17:37 , 02-Мрт-12, (85) Вы предлагаете конвертировать лог в бинарный формат, а потом реплицировать его с, Аноним (-), 17:44 , 02-Мрт-12, (89) Немного более чем нет , Имя и код (?), 05:47 , 03-Мрт-12, (146) Это что, подтверждение мысли о ненужности rsyslog , Аноним (-), 13:48 , 03-Мрт-12, (173) Нет, подумайте об этом на досуге , Имя и код (?), 04:13 , 04-Мрт-12, (211) Репликация средствами мускула Лол С тем же успехом можно текстовые логи через s, Аноним (-), 18:27 , 02-Мрт-12, (94) –2 Делайте силой мыли, ибо всё остальное - КОСТЫЛИ , Deffic (?), 02:03 , 03-Мрт-12, (120) Не, дядя, мускуль в обязательном порядке для всего лишь ведения логов - это мега, Аноним (-), 03:53 , 03-Мрт-12, (132) –1 Вы передёргиваете , Deffic (?), 22:33 , 05-Мрт-12, (226) Разнообразие форматов журналов следует из разнообразия решаемых задач и разнообр, Аноним (-), 14:32 , 02-Мрт-12, (4) +1 Лучшее враг хорошего , Аноним (-), 14:32 , 02-Мрт-12, (5) +5 а почему сислог они считают устаревшим чем аргументируют , Аноним (-), 14:46 , 02-Мрт-12, (12) +2 // http bb comp-house ru comp-house repo wiki what-i-dont-like-about-journald, anonymous (??), 14:47 , 02-Мрт-12, (13) –2 // Как видим, Герхардса с его проповедями про превосходство rsyslog успешно заткнул, Аноним (-), 14:48 , 02-Мрт-12, (16) // http bb comp-house ru comp-house repo wiki journald-and-rsyslog, anonymous (??), 14:55 , 02-Мрт-12, (23) –1 Устаревшая инфа Судя по сабжевой новости, теперь мнение этого товарища радикальн, Аноним (-), 15:04 , 02-Мрт-12, (28) –1 Не умеет работать со структурированными данными нет поддержки соответствующих ф, Аноним (-), 15:18 , 02-Мрт-12, (43) Так что теперь будет с journald , Аноним (-), 14:55 , 02-Мрт-12, (22) // А ничего не будет Он часть systemd и останется Сделают пересылку в другой журн, anonymous (??), 14:58 , 02-Мрт-12, (25) К нему кроме его текущего API добавят ELAPT А возможно ELAPI будет единственным, VoDA (ok), 15:05 , 02-Мрт-12, (29) +1 // Скорее второе - нынешний API journald пока не стабилизирован, поэтому сейчас его, Аноним (-), 15:06 , 02-Мрт-12, (32) Судя по всем, Lamberjack - это и есть journald, с небольшими косметическими изме, Аноним (-), 15:05 , 02-Мрт-12, (31) Радует то, что постарались обсудить, а не переть своим умом удачи , Michael Shigorin (ok), 15:15 , 02-Мрт-12, (41) +1 // А может, они с systemd upstart еще повторят Для полного счастья , Аноним (-), 16:19 , 02-Мрт-12, (61) +1 // А может, они-таки наймут ОДНОГО вменяемого системного архитектора И сделают ЕДИ, Аноним (-), 16:25 , 02-Мрт-12, (66) // Даже у очень умных людей решения в стиле вот, оно, единое имеют тенденцию оказ, Michael Shigorin (ok), 16:57 , 02-Мрт-12, (71) –1 Мы это видим с каждым новым дистром линукса, которые уже числом, тащемта, за шту, Аноним (-), 14:45 , 03-Мрт-12, (179) Хм, пока похоже, что путаете GNU s Not UNIX с чем-то неприпоминаемым из высказыв, Michael Shigorin (ok), 19:39 , 03-Мрт-12, (191) А кто не согласен - будет расстрелян, так , Аноним (-), 17:04 , 02-Мрт-12, (73) А у несогласных никуда всегда была gentoo , Аноним (-), 00:35 , 03-Мрт-12, (118) –2 LFS, Имя и код (?), 07:10 , 03-Мрт-12, (155) А что делать тем кому не нравится пидон в каждой дырке в системе , zzz (??), 13:21 , 03-Мрт-12, (167) А что там повторять Сейчас разработка upstart фактически превратилась в копипас, Аноним (-), 17:50 , 02-Мрт-12, (91) +1 // Ну вот я как раз за то чтобы они собрались и обсудили как и чего К systemd боль, Аноним (-), 03:55 , 03-Мрт-12, (133) Это вам-то пруф, с предъявами о usr Кто еще не видел http freedesktop org wik, qux (ok), 17:01 , 04-Мрт-12, (217) +1 Чё они х ей занимаются Нужно структурированные, ну прилепи ты syslog2sql и ра, pavlinux (ok), 22:17 , 02-Мрт-12, (110) +1 // бинарное хранение это следствие, а не причина причина же в API для структурирова, VoDA (ok), 03:16 , 03-Мрт-12, (127) всяким там возможным SQL-иньекциям И да, как sql база обеспечит защиту от, Аноним (-), 03:59 , 03-Мрт-12, (134) // REVOKE ALL ON logdbase TO logodmin localhost GRANT INSERT ON logdbase TO logod, pavlinux (ok), 01:24 , 05-Мрт-12, (222) А зачем SQL запросы, когда есть NoSQL решения С хранением данных чисто в операти, XoRe (ok), 06:15 , 03-Мрт-12, (150) –1 Сколько же воплей в этом треде Никаких lumberjack и journald не будет ближайш, Аноним (-), 22:46 , 02-Мрт-12, (113) –2 // См 128 , Аноним (-), 04:00 , 03-Мрт-12, (135) я, например, раз уж ты себя не считаешь достойным , arisu (ok), 05:16 , 06-Мрт-12, (241) Название - игра слов log - бревно Lumberjack - дровосек Т е логоруб Нам предлаг, XoRe (ok), 06:13 , 03-Мрт-12, (149) +5 // Адназначна , Имя и код (?), 07:13 , 03-Мрт-12, (156) Что мы получили 1 программы для дефрагментации реестра2 файлы реестра раскидан, Аноним (-), 11:58 , 03-Мрт-12, (161) +1 ну скажем так если требуется для каких-то целей строить по логам статистику - п, Аноним (186), 17:05 , 03-Мрт-12, (186) // Если нужна статистика, то и сейчас вообще не проблема, например через пайп или п, nobody (??), 02:37 , 04-Мрт-12, (199) +1 Похоже кто то хочет подзаработать на неграмотности админов Что ж, флаг им в руки, vi (?), 02:12 , 04-Мрт-12, (198) Линуксоиды воистину неизлечимы Вместо того что бы механизировать ручной труд, Piter_Ring (ok), 05:06 , 04-Мрт-12, (212) –2 // Некоторые из нас понимают в красителях способны без смывания и закрашивания р, Michael Shigorin (ok), 15:26 , 04-Мрт-12, (216) // Если сильно постараются, то данный проект может вырасти и вместо http www yout, Piter_Ring (ok), 01:42 , 05-Мрт-12, (223) // Это вообще какой-то виндузятник с перочинным топориком непонятно, кто лесорубом, Michael Shigorin (ok), 02:21 , 05-Мрт-12, (224) 1,2,3,4,5,12,22,41,110,113,149,186,198,212

Сообщения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	219. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (-), 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 -- кто-то из знакомых отзывался > сдержанно неплохо, но вот детали уж не упомню. Наверное потому что это что-то для совсем уж энтерпрайзной аналитики. В то время как от сабжа лично мне хотелось бы всего лишь такие базовые и логичные вещи как "а что вот тот айпи делал с вот этой системой от сих до сих", например.
	Ответить | Правка | Наверх | Cообщить модератору

	221. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Michael Shigorin (ok), 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 ' Не, я понимаю, что мужики честно хотят сделать лучше.  Просто это довольно сложно.
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+5 +/–
	Сообщение от XoRe (ok), 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 (??), 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 для логгинговых операций. Куда я смогу пойти и получить ответ на вопрос "а что вон тот айпи за последнюю неделю со всеми моими демонами делал". Ну хотя-бы чтобы понять кто это такое и не надо ли такое в файрвол вообще заносить. > Сетевое логирование + ротация со сжатием - и ваши проблемы решены уже сейчас. А выяснение что вон тот айпишник делал с _разными_ демонами на продолжении _недели_ - как было определенным гемором так и осталось. И вообще, декомпрессовать и грепать неделю логов - не очень прикольная и быстрая операция, знаете ли. > А не когда команда программистов вместе с поттерингом что-то напишет. См. выше. Есть ряд вполне типовых и обыденных задач которые красиво и быстро на данный момент не решены. Грепинг недели логов с декомпрессовкой старых версий - это не ответ, это адовы костыли и подпорки. >> Специально обученная обезьяна при машине. > Смотря что считать костылями. Получите мне информацию о том что делал некий айпишник за последнюю неделю с вашей машиной без костылей и грепинка недельных логов. В случае структурированных логов с индексами выцепить только нужный диапазон дат и пройтись по индексу айпишников - плевое дело, займет секунды. А вот грепинг всех логов за неделю от всех демонов может занять черт знает сколько времени, пардон. > Если в программу добавили функционал работы с сетью, разве это костыль? > Или вам нужно окошечко с галочкой "фича из коробки - включена по дефолту"?) Мне как и этим господам нужна подсистема логинга покрывающая типовые наборы административных операций простыми и быстрыми средствами. Грепать все логи всех демонов за неделю, при том что они еще и в разном формате все - нифига не быстро и не удобно.
	Ответить | Правка | Наверх | Cообщить модератору

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

	192. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от Аноним (-), 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. А ничо, пипл хавает... > Я бы уже сейчас настроил нужный функционал из того, что есть. И? Это не значит что я хочу вплоть до отправки в могилу продолжать так делать если можно делать проще/лучше/удобнее...
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	183. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от VoDA (ok), 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 +/–
	Сообщение от Имя и код (?), 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 раза (мета-информация занимает примерно > треть). Конечно не будет, указал по чему.
	Ответить | Правка | Наверх | Cообщить модератору

	227. "Представлен проект Lumberjack, нацеленный на модернизацию си..."	+/–
	Сообщение от VoDA (ok), 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 пишет в бинарные файлы. ;)
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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