Две недели назад компания 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.../
Новость: http://www.opennet.me/opennews/art.shtml?num=33246
Судя по неоднократному упоминанию "структурированных данных", основной формат хранения логов будет бинарным.
Ну наконец-то и линукс дошел до того, что в юниксе сделано уже двадцать лет назад.
А чем бинарный формат принципиально лучше текстового? Индексы и по текстовым строкам прекрасно делаются, сами журнальные записи тоже текстовые
> А чем бинарный формат принципиально лучше текстового? Индексы и по текстовым строкам
> прекрасно делаются, сами журнальные записи тоже текстовыеОсновных причины две:
1. Недостаточная компактность. Особенно неприятно отсутствие возможности дедупликации повторяющихся данных (например, имя хоста). Соответственно, это сильно замедляет хранение, поиск и обработку. В частности, именно поэтому наиболее нагруженные лог-системы (в частности, юниксовый аудит) работают исключительно с бинарными логами.
2. Неструктурированность. Опять же сильно затрудняет обработку и поиск данных. Кроме того, порождает кучу проблем совместимости - добавление нового поля в структуру не ломает существующие анализаторы логов, в отличие от изменения форматной строки.
> Основных причины две:
> 1. Недостаточная компактность. Особенно неприятно отсутствие возможности дедупликации
> повторяющихся данных (например, имя хоста). Соответственно, это сильно замедляет хранение,
> поиск и обработку. В частности, именно поэтому наиболее нагруженные лог-системы (в
> частности, юниксовый аудит) работают исключительно с бинарными логами.Это попытка переизобрести gzip?
> 2. Неструктурированность. Опять же сильно затрудняет обработку и поиск данных. Кроме того,
> порождает кучу проблем совместимости - добавление нового поля в структуру не
> ломает существующие анализаторы логов, в отличие от изменения форматной строки.Феерический бред.
> Это попытка переизобрести gzip?В какой-то степени. Но только такой gzip, который позволяет работать сразу со сжатым файлом, и при этом не замедляет доступ, а ускоряет его (за счет индекса).
> Феерический бред.
Да неужели? Вот, например, в приводимых вами ссылках автор rsyslog жалуется, что поддержка тайм-зоны в его rsyslog давно есть, но включить ее нельзя, потому что она сломает все существующие анализаторы логов.
Со структурированными данными при стабильном API такой проблемы нет в принципе.
>> Это попытка переизобрести gzip?
> В какой-то степени. Но только такой gzip, который позволяет работать сразу со
> сжатым файлом, и при этом не замедляет доступ, а ускоряет его
> (за счет индекса).Кто мешает пожать и проиндексировать текстовый файл?
> Да неужели? Вот, например, в приводимых вами ссылках автор rsyslog жалуется, что
> поддержка тайм-зоны в его rsyslog давно есть, но включить ее нельзя,
> потому что она сломает все существующие анализаторы логов.
> Со структурированными данными при стабильном API такой проблемы нет в принципе.Где ты увидел стабильный API, если количество полей и их содержимое меняется? Всё равно переписывать придётся. Впрочем, пока даже формат этого бинаря не документирован.
> Где ты увидел стабильный API, если количество полей и их содержимое меняется?Если поля не удаляются, а только добавляются новые, то, по идее, старые анализаторы это не должно ломать.
Ага, щаз. Ты представление-то имеешь, как парсеры работают?
Нет :)Речь шла о структурированном логе со специальным API для работы с ним. Если через API из записи можно извлечь отдельные поля, указав их имя, то на добавление новых полей, неизвестных парсеру, ему будет фиолетово. В текстовом виде это тоже реализуется, если журнальные записи имеют вид timestamp: field1=value1 field2=value2 ... - переставляй поля как угодно, и правильно написанный парсер вытащит нужные ему данные
Структурированные данные, индексируемые данные, множества данных. Если кто не понял, то это пахнет СУБД, а SQL скажем не пострадает при добавлении поля, запрос не изменится.
Ну допустим я имею, ламерок. Для тех кто в танке: что сломается в SQL при добавлении колонки? Что сломается в XML при добавлении элемента? Что сломается в protocol buffer при добавленнии поля? Что сломается в наколеночном бинарном формате <число полей> ( <длина поля> <данные поля> ) {число полей раз} при добавлении поля? Ответ: ничего. Иди доучивайся.
> Что сломается в XML при добавлении элемента?В этой теме про него лучше не вспоминать.
А то, знаете как... помянешь черта и он появится)
> А то, знаете как... помянешь черта и он появится)OSMщики с XML уже наелись, как стали портянги в 250 гигз, которые в бинарном формате всего 14, так они и удрали резко на эффективный бинарный формат. Потому что XML на 250 гигз - это полная гопа.
> Ну допустим я имею, ламерок. Для тех кто в танке: что сломается
> в SQL при добавлении колонки?Это типа каждый раз альтер тейбл, который, конечно же, вовсе не накладная операция и мы, есесно, не упрёмся в, скажем, какойнидь ора-1631?
> Ответ: ничего. Иди доучивайся.
Да, всё верно: иди, дофапывай эту свою м-м-м.. науку...
а что сломается в парзере, например, «по строке на запись, поля поделены одним табом» при добавлении поля? если, конечно, автор не портвейн в подворотне пил, а знает, сколько полей ему надо? правильно, тоже ничего. при этом нормальные логи всё-таки остаются человекочитаемыми, в отличие от.
> Ага, щаз. Ты представление-то имеешь, как парсеры работают?хорошо работают, если писались руками и изначально формат нормальный. «первые эн полей я знаю, остальное знать не знаю и не хочу.» всё, проблемы с добавлением полей так, чтобы ничего не поломать, нет. и, конечно, любой лог-файл должен иметь фичу «игнорировать строки, которые начинаются с символов, отсутствующих в текущей спецификации».
таким образом мы получаем как неломающиеся конвертеры и анализаторы, так и простор для маневра.
> Кто мешает пожать и проиндексировать текстовый файл?Современный текстовый лог представляет собой текстовую кашу, которую индексировать весьма проблематично. Индексы эффективны только на структурированных данных.
> Где ты увидел стабильный API, если количество полей и их содержимое меняется?
API для работы со структурированными данными по определению поддерживает произвольный набор полей различного типа. Абстракция, слышали такое слово?
> произвольный набор полей различного типачем это отличается от «каши», не подскажешь?
> Но только такой gzip, который позволяет работать сразу со сжатым файлом, и при этом не замедляет доступ, а ускоряет его (за счет индекса).А индекс образуется сам собой, причём совершенно задаром.
> А индекс образуется сам собой, причём совершенно задаром.А в случае текстаря его еще и хранить надо где-то сильно сбоку...
> Это попытка переизобрести gzip?Gzip не позволяет доступ на ходу. А 20 гиговую портянку сам, пожалуйста, декомпрессуй своим гзипом. И да, если уж о скорости, тесктовые логи зачастую отключают т.к. на серверах все начинает упираться именно в запись логов.
>> Это попытка переизобрести gzip?
> Gzip не позволяет доступ на ходу. А 20 гиговую портянку сам, пожалуйста,
> декомпрессуй своим гзипом. И да, если уж о скорости, тесктовые логи
> зачастую отключают т.к. на серверах все начинает упираться именно в запись
> логов.Против 20гиговых логов есть ротация.
Кто не настроил, тот - ...)
На средненагруженном сервере в логи ничего не упирается.
А на высоконагруженном... там уже другие способы работы с логами.
Например, отправлять на специальный сервер логов, не храня у себя.
Кто не настроил - тот ...)
> Против 20гиговых логов есть ротация.Угу, что однако не отменяет факта что логи могут быть большими даже с ротацией.
> Кто не настроил, тот - ...)
На объем логов это ВНЕЗАПНО никак не влияет: если я хочу проанализировать логи за сутки, я хочу проанализировать логи за сутки и все тут. Хоть ротейть, хоть не ротейть, суммарное количество данных за сутки никак не изменится.
> На средненагруженном сервере в логи ничего не упирается.
Сферические кони в вакууме - это здорово. А вот когда приходит атакер и получается что сервер больше пыжится с записью лога чем со всем остальным, так что приходится логгинг отключать - это как-то неправильно.
> А на высоконагруженном... там уже другие способы работы с логами.
Ну вот в идеале хотелось бы чтобы сабжевый способ был достаточно компактен и быстр чтобы это для него не было проблемой.
> Например, отправлять на специальный сервер логов, не храня у себя.
> Кто не настроил - тот ...)Да-да-да, кто не понаставил костылей... а есть другой вариант: сделать так чтобы ставить костыли стало не нyжно. Кто десятилетиями ставит костыли не пытаясь ничего изменить - тот, простите, исполнительный ДУРАК. Специально обученная обезьяна при машине.
>> Например, отправлять на специальный сервер логов, не храня у себя.
>> Кто не настроил - тот ...)
> Да-да-да, кто не понаставил костылей...Пожалуйста, давайте об устрицах -- емши.
Локальное хранение логов нередко весьма затруднительно с точки зрения производительности (шибко много синхронной записи), надёжности (если разрешить буферизовать) и доверенности (если всё-таки проломят).
Поэтому отправлять на специальный сервер логов при высокой нагрузке приходится практически без вариантов (а то ещё и стекаться через агрегаторы может). Вне зависимости от того, как именно будут упакованы сами данные.
> Поэтому отправлять на специальный сервер логов при высокой нагрузке приходится практически
> без вариантов (а то ещё и стекаться через агрегаторы может).А чем проблемы с синхронной записью там - лучше чем с синхронной записью где-то еще? Это от сервера конечно зависит, но физическую природу явлений то не меняет. Не, понятно что в ряде случаев - разгрузит.
> Вне зависимости от того, как именно будут упакованы сами данные.
Ну да, конечно, то-то база OSM в XML 250 гигз, а в бинарном 14. Совсем никакой разницы...
> А чем проблемы с синхронной записью там - лучше чем с синхронной записью где-то еще? Это от сервера конечно зависит, но физическую природу явлений то не меняет. Не, понятно что в ряде случаев - разгрузит.Выделенный коллектор логов обслуживает исключительно логи, а не целевой сервис + логи.
> Выделенный коллектор логов обслуживает исключительно логи, а не целевой сервис + логи.Целевой сервис не обязан интенсивно писать на диск, если что. Более того, не у всех парк по 50 серверов, а ставить к полутора сервакам еще целый отдельный сервак логинга - ну это круто, конечно, но КПД начинает вызывать вопросы.
> Целевой сервис не обязан интенсивно писать на диск, если что.fsync() очень даже бьёт и по чтению. Если же сервис со всем нужным помещается в памяти -- замечательно, но не так часто.
> Более того, не у всех парк по 50 серверов
Вас же не призывают держать два ноута, чтоб с одного на другой логи лить. :) На полутора серверах задач, о которых говорят, вообще особо ожидать не приходится.
> fsync() очень даже бьёт и по чтению.Может, но насколько именно - весьма зависит от.
> Если же сервис со всем нужным помещается в памяти -- замечательно, но не так часто.
А еще можно логи хранить на отдельном диске и прочая, например, ну и пусть его чтение проседает наздоровье если хочет. Хотя конечно же когда вы ынтырпрайз, бабла дофига и прочая - проще не греть мозг и просто воткнуть отдельный сервак логинга, кто б спорил. Правда это годится только для богатых жирных ынтырпрайзов которым плюс-минус пару серверов - вообще ничто.
>> Более того, не у всех парк по 50 серверов
> Вас же не призывают держать два ноута, чтоб с одного на другой логи лить. :)
> На полутора серверах задач, о которых говорят, вообще особо ожидать не приходится.Да ладно, обычная школьная атака - и вот уже полтора сервера ощущают на себе все прелести вымахивания логов до немеряных размеров за короткий срок.
>> fsync() очень даже бьёт и по чтению.
> Может, но насколько именно - весьма зависит от.Дядьку, я Вам это по куче систем с самым разным стораджем говорю.
>> Если же сервис со всем нужным помещается в памяти -- замечательно, но не так часто.
> А еще можно логи хранить на отдельном дискеЭто и упомянул в #187: "помогает по производительности (но не по доверенности)". См. тж. #221.
> Хотя конечно же когда вы ынтырпрайз, бабла дофига и прочая - проще не греть
> мозг и просто воткнуть отдельный сервак логинга, кто б спорил.На "Ломоносове" реализовано многостадийное агрегирование и раздельное хранение, не то что "отдельный сервак". С отбрасыванием архива на более постоянный сторадж.
А в местах, где логи интересные уже есть, но выделенной железки ещё не стоят -- вполне можно себе позволить совместить лог-сервер с бэкап-сервером, риски это увеличивает относительно слабо (если не совмещать логи с бэкапами на одной ФС, конечно).
> Правда это годится только для богатых жирных ынтырпрайзов которым плюс-минус
> пару серверов - вообще ничто.Такая выделенная железка в компактном корпусе с двумя-тремя SATA-дисками спокойно умещается в $500, если что.
>> На полутора серверах задач, о которых говорят, вообще особо ожидать не приходится.
> Да ладно, обычная школьная атака - и вот уже полтора сервера ощущают на себе
> все прелести вымахивания логов до немеряных размеров за короткий срок.Ну так пусть на малом учатся, всему ж своё время. :)
>> Поэтому отправлять на специальный сервер логов при высокой нагрузке
>> приходится практически без вариантов (а то ещё и стекаться через агрегаторы может).
> А чем проблемы с синхронной записью там - лучше чем с синхронной записью где-то еще?Тем, что подсистема I/O может быть к ним лучше готова.
> Это от сервера конечно зависит, но физическую природу явлений то не меняет.
> Не, понятно что в ряде случаев - разгрузит.Даже локально отделить активные логи на отдельный шпиндель или несколько в RAID сильно помогает по производительности (но не по доверенности).
>> Вне зависимости от того, как именно будут упакованы сами данные.
> Ну да, конечно, то-то база OSM в XML 250 гигз,
> а в бинарном 14. Совсем никакой разницы...1) User294, повторяетесь;
2) ну так они б ещё этот XML в doc засунули.PS: несколько удивлён полным отсутствием упоминаний Splunk -- кто-то из знакомых отзывался сдержанно неплохо, но вот детали уж не упомню.
> Тем, что подсистема I/O может быть к ним лучше готова.Сервер отгружающий бочками файло и не готовый к интенсивному I/O довольно странная штука. И отдельный диск под логи там вполне может быть. Хотя никто не спорит что если денег много то отдельный сервер логгинга - ничем таким не плохо. Кроме того что он денег стоит.
>> Это от сервера конечно зависит, но физическую природу явлений то не меняет.
>> Не, понятно что в ряде случаев - разгрузит.
> Даже локально отделить активные логи на отдельный шпиндельНу спасибо вам, Капитан. Я чуть выше тоже откапитанил :)
>> Ну да, конечно, то-то база OSM в XML 250 гигз,
>> а в бинарном 14. Совсем никакой разницы...
> 1) User294, повторяетесь;Есть такие грабельки. Но фактов это не отменяет.
> 2) ну так они б ещё этот XML в doc засунули.Фиг с ним с doc, взять айпи например, 123.123.123.123 - это сколько байтов как текст? Что, "всего" 15? А в бинарном виде - 4. Такая вот почти 4-кратная разница на ровном месте. А если еще имя хоста дедупануть и прочая - этак логи в несколько раз и сдуются. Это само по себе время их колупания в эти же разы и сократит потом, а если еще индексы прикрутить к наиболее нужным полям - вообще красота станет.
> PS: несколько удивлён полным отсутствием упоминаний Splunk -- кто-то из знакомых отзывался
> сдержанно неплохо, но вот детали уж не упомню.Наверное потому что это что-то для совсем уж энтерпрайзной аналитики. В то время как от сабжа лично мне хотелось бы всего лишь такие базовые и логичные вещи как "а что вот тот айпи делал с вот этой системой от сих до сих", например.
(см. тж. #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 'Не, я понимаю, что мужики честно хотят сделать лучше. Просто это довольно сложно.
>> Против 20гиговых логов есть ротация.
> Угу, что однако не отменяет факта что логи могут быть большими даже
> с ротацией."могут быть" - это предположение.
факт - это "бл*, вот это логи отожрали!"
А с фактом уже можно работать - почему отожрали?
Это с уровнем логирования debug, или warning?
А напуркуа на продакшене debug?
Ах, это варнинг, и о чем он варнингует?
Так исправьте, чтобы не варнинговал.
И т.д.Можно пойти другим путем.
20 гигов текста - это очень дофига.
Это примерно 250 миллионов строк (допустим, 80 символов на сообщение).
250 миллионов делим на 86400 (сутки) = 2893 строк в секунду(!)
И что у вас там генерирует 3000 записей в лог за секунду?
Если это записи уровня debug - отключайте debug скорее!
А если это полезные записи, то пора переводить все логи на специальный сервер логов.
Пожалейте ваши жесткие диски!>> Кто не настроил, тот - ...)
> На объем логов это ВНЕЗАПНО никак не влияет: если я хочу проанализировать
> логи за сутки, я хочу проанализировать логи за сутки и все
> тут. Хоть ротейть, хоть не ротейть, суммарное количество данных за сутки
> никак не изменится.Вот как раз ротация поможет вам посмотреть лог за сутки, а не грепать недельный лог по "2012-03-03".
>> На средненагруженном сервере в логи ничего не упирается.
> Сферические кони в вакууме - это здорово. А вот когда приходит атакер
> и получается что сервер больше пыжится с записью лога чем со
> всем остальным, так что приходится логгинг отключать - это как-то неправильно.Отключение логов при атаке?
А если атака в 4 утра?
Если исходить, что атака очень может быть, лучше заранее к ней подготовиться.
Настройка логирования по сети - это не так сложно.
Я даже делал логирование по сети сообщений при kernel panic.
Ну а подружить zend с syslog - вообще благое дело.>> А на высоконагруженном... там уже другие способы работы с логами.
> Ну вот в идеале хотелось бы чтобы сабжевый способ был достаточно компактен
> и быстр чтобы это для него не было проблемой.Пока сабжевый способ только обсуждается.
Я рекомендую настроить сервер, чтобы он уже сейчас сделал логи вашими друзьями, а не врагами.
Сетевое логирование + ротация со сжатием - и ваши проблемы решены уже сейчас.
А не когда команда программистов вместе с поттерингом что-то напишет.>> Например, отправлять на специальный сервер логов, не храня у себя.
>> Кто не настроил - тот ...)
> Да-да-да, кто не понаставил костылей... а есть другой вариант: сделать так чтобы
> ставить костыли стало не нyжно. Кто десятилетиями ставит костыли не пытаясь
> ничего изменить - тот, простите, исполнительный ДУРАК. Специально обученная обезьяна при
> машине.Смотря что считать костылями.
Если в программу добавили функционал работы с сетью, разве это костыль?
Или вам нужно окошечко с галочкой "фича из коробки - включена по дефолту"?)
> "могут быть" - это предположение.Элементарно - минимальная атака на сервак где они в крейсерском режиме нормальные и лог пухнет в десятки раз от номинала. И именно такой лог как ни странно может захотеться проанализировать.
> факт - это "бл*, вот это логи отожрали!"
> А с фактом уже можно работать - почему отожрали?Мало ли, атака например. Свалилось в 1000 раз больше запросов чем обычно валится. Вполне обыкновенная ситуация.
> Так исправьте, чтобы не варнинговал.
Больно жирно. Есть например сервант. Не очень нагруженный. А тут вдруг бабах и атака. Логи могли бы помочь понять кто и что и кого надо в баню. Но если в них все и упирается - их придется отключить чтобы машина не дохла, для начала. В свете этого - если их можно записать в 5 раз компактнее, логично что умирать оно начнет при в 5 раз большей нагрузке. Значит отключать придется реже.
> И что у вас там генерирует 3000 записей в лог за секунду?
Да любая самая пионерская атака на обычный http сервант хотя-бы.
> Если это записи уровня debug - отключайте debug скорее!Что за кретинские предположения? Зачем дебаг в продакшне?
> А если это полезные записи, то пора переводить все логи на специальный
> сервер логов.Ну да, 3000 запросов в секунду могут прилететь на любой хттп сервак, даже хомпагу Васи Пупкина. Достаточно Васе поругаться с Петей и Петя на раз ему 3000 запросов в секунду пришлет. Что, каждому Васе отдельный сервер для логов ставить? Зашибись :)
> Пожалейте ваши жесткие диски!
Даешь каждому Васе под хомпагу по личному датацентру, с цысками и сисадминшами?! :)
> Вот как раз ротация поможет вам посмотреть лог за сутки, а не
> грепать недельный лог по "2012-03-03".А что если я хочу посмотреть "а что вот этот айпишник делал с моим сервером за последнюю неделю"? Вариант нормальный: отсортировать по айпишнику ограничив интервал по дате. За счет индекса - должно педалиться за какие-то секунды. Вариант конский: адски грепать неделю логов. Если их много - займет чуть более чем дохрена времени.
>> и получается что сервер больше пыжится с записью лога чем со
>> всем остальным, так что приходится логгинг отключать - это как-то неправильно.
> Отключение логов при атаке?Ну нормально! А ничего что по логам было бы удобно делать допустим автобан атакующих ботов? Хотя конечно может благородный дон и руками кучи ботов банить не обламывается, вдруг он там не ленивый :)
> А если атака в 4 утра?
Ну так вот мне нравится идея что вкалывают роботы а не человек. Идеальный вариант: анализатор логов разгребая логи видит аномалии ("вот этот товарищ делает 100 запросов в секунду!") и просто гасит такое сам. Без побудки админа в 4 утра. Но с текстовыми простынями это все реализовывать геморно и нетривиально получается и работает через те еще грабли.
> Если исходить, что атака очень может быть, лучше заранее к ней подготовиться.
Да, например можно запрячь админа круглосуточно дежурить. А можно анализатора логов. Только вот анализатору логов гигантские портянки в которые дописывают без уведомления, и формат которых оставляет желать много лучшего в плане удобства разбора и которые не заточены на какую либо сортировку и аналитику ибо не снабжены индексами - совершенно не удобны. Весь гемор сваливается на анализатор, который должен или сам реализовывать каждый раз нормальный индекс, или каждый раз читать огромные простыни, скорость данной операции думаю понятна :)
> Настройка логирования по сети - это не так сложно.Да, проспонсируйте отдельный сервак логирования каждому Васе с хомпагой. И если уж пошла атака - засрать сеть дополнительно еще и траффиком логгинга это хорошо придумано. Правда откуда следует что оно будет надежно работать - вообще не понятно. А, собственно, если сеть захлебнется например - что будет? Логгинг будет перепослан опосля, когда ей полегчает? А программы узнают о том факте что залоггить было не судьба? И есть даже какая-то универсальная стандартная механика для _разных_ демонов все это узнать?!
> Я даже делал логирование по сети сообщений при kernel panic.
> Ну а подружить zend с syslog - вообще благое дело.Хотелось бы чтобы логгинг работал в каком-то базовом минимальном варианте без всяких приседаний. В частности хотелось бы чтобы посмотреть "а что вот этот айпи делал с моими демонами за последнюю неделю" было бы штатной фичой системного логгера. А не донавертываться 20 слоями костылей где-то сбоку. До сабжей сие кажется дошло, алилуйя.
>> Ну вот в идеале хотелось бы чтобы сабжевый способ был достаточно компактен
>> и быстр чтобы это для него не было проблемой.
> Пока сабжевый способ только обсуждается.Эээ? Там уже сырцы в гите есть, хоть это и journald по сути.
> Я рекомендую настроить сервер, чтобы он уже сейчас сделал логи вашими друзьями,
> а не врагами.Вот я искренне надеюсь что сабж совместными усилиями допинают и он будет в разных системах стандартной facility для логгинговых операций. Куда я смогу пойти и получить ответ на вопрос "а что вон тот айпи за последнюю неделю со всеми моими демонами делал". Ну хотя-бы чтобы понять кто это такое и не надо ли такое в файрвол вообще заносить.
> Сетевое логирование + ротация со сжатием - и ваши проблемы решены уже сейчас.
А выяснение что вон тот айпишник делал с _разными_ демонами на продолжении _недели_ - как было определенным гемором так и осталось. И вообще, декомпрессовать и грепать неделю логов - не очень прикольная и быстрая операция, знаете ли.
> А не когда команда программистов вместе с поттерингом что-то напишет.
См. выше. Есть ряд вполне типовых и обыденных задач которые красиво и быстро на данный момент не решены. Грепинг недели логов с декомпрессовкой старых версий - это не ответ, это адовы костыли и подпорки.
>> Специально обученная обезьяна при машине.
> Смотря что считать костылями.Получите мне информацию о том что делал некий айпишник за последнюю неделю с вашей машиной без костылей и грепинка недельных логов. В случае структурированных логов с индексами выцепить только нужный диапазон дат и пройтись по индексу айпишников - плевое дело, займет секунды. А вот грепинг всех логов за неделю от всех демонов может занять черт знает сколько времени, пардон.
> Если в программу добавили функционал работы с сетью, разве это костыль?
> Или вам нужно окошечко с галочкой "фича из коробки - включена по дефолту"?)Мне как и этим господам нужна подсистема логинга покрывающая типовые наборы административных операций простыми и быстрыми средствами. Грепать все логи всех демонов за неделю, при том что они еще и в разном формате все - нифига не быстро и не удобно.
Уважаемый, вы бы посмотрели, на какие тезисы я отвечаю)
Там как раз хотели за сутки логи смотреть.
Ротация обычно настроена на сутки.
Если вам нужно за неделю - настройте ротацию на неделю)>> А если атака в 4 утра?
> Ну так вот мне нравится идея что вкалывают роботы а не человек.
> Идеальный вариант: анализатор логов разгребая логи видит аномалии ("вот этот товарищ
> делает 100 запросов в секунду!") и просто гасит такое сам. Без
> побудки админа в 4 утра. Но с текстовыми простынями это все
> реализовывать геморно и нетривиально получается и работает через те еще грабли.Вообще если мы говорим про страничку васи пупкина, то сервис один - http.
А логи apache/nginx парсит большое количество программ.
В этом случае откройте для себя log2ban - сам парсит, сам гасит.>> Если исходить, что атака очень может быть, лучше заранее к ней подготовиться.
> Да, например можно запрячь админа круглосуточно дежурить. А можно анализатора логов. Только
> вот анализатору логов гигантские портянки в которые дописывают без уведомления, и
> формат которых оставляет желать много лучшего в плане удобства разбора и
> которые не заточены на какую либо сортировку и аналитику ибо не
> снабжены индексами - совершенно не удобны. Весь гемор сваливается на анализатор,
> который должен или сам реализовывать каждый раз нормальный индекс, или каждый
> раз читать огромные простыни, скорость данной операции думаю понятна :)Анализатор логов работает в режиме реального времени.
Разница между чтением текста и бинаря - в микросекундах.> Мне как и этим господам нужна подсистема логинга покрывающая типовые наборы административных
> операций простыми и быстрыми средствами. Грепать все логи всех демонов за
> неделю, при том что они еще и в разном формате все
> - нифига не быстро и не удобно.Я бы не назвал выдачу данных о подключении ко всем демонам с одно ip - типовой задачей.
Но вы знаете, что даже с имеющимися средствами вы можете это сделать.
Вы можете настроить rsyslog/syslog-ng на хранение логов в нужном вам формате.
Можно даже настроить, чтобы хранилось по папкам:
/log/year/month/day/hour/service/ip.logХотя вы можете ничего не делать, и ждать, пока нужный вам функционал сделают за вас.
Могу добавить, что пока рабочей программы нет, неизвестно, удовлетворит ли ваши нужды её функционал.
Я бы уже сейчас настроил нужный функционал из того, что есть.
> Если вам нужно за неделю - настройте ротацию на неделю)Во первых, заранее сложно сказать за какой интервал потребуются логи. Во вторых, портянка за неделю будет приличная как ни крути. Что попиленая на ежедневные куски, что одной простыней. От перемены мест слагаемых сумма не меняется.
>> Идеальный вариант: анализатор логов разгребая логи видит аномалии ("вот этот товарищ
>> делает 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. А ничо, пипл хавает...
> Я бы уже сейчас настроил нужный функционал из того, что есть.
И? Это не значит что я хочу вплоть до отправки в могилу продолжать так делать если можно делать проще/лучше/удобнее...
>> "могут быть" - это предположение.
> Элементарно - минимальная атака на сервак где они в крейсерском режиме нормальные
> и лог пухнет в десятки раз от номинала. И именно такой
> лог как ни странно может захотеться проанализировать.Уважаемый, вы хотя бы раз logcheck настраивали?
>> Например, отправлять на специальный сервер логов, не храня у себя.
>> Кто не настроил - тот ...)
> Да-да-да, кто не понаставил костылей... а есть другой вариант: сделать так чтобы
> ставить костыли стало не нyжно. Кто десятилетиями ставит костыли не пытаясь
> ничего изменить - тот, простите, исполнительный ДУРАК. Специально обученная обезьяна при
> машине.Ну ётыдь, ну шо за вьюные разжижения мозгофекалий? Воопще-то построение скалейбл сислог менеджмента, который, сцуко, без централизированной логопомойки с коллекшн стейшенами, ивент манагерами, ротейшенами и ретеншенами, да ещё в придачу с лёгким и - что самое главное - приятным - сайзингом, не есть возможен, если мы хотим строиться согласно её королевского величества айтилом, с третьей версии, ежели мне ни изменяет.
А мы ведь хотим, мы презираем этот вонючий МОФ или что там у них, а? :)
> Ну ётыдь, ну шо за вьюные разжижения мозгофекалий?Я тоже не понял. Поэтому попробуйте изложить мысль внятно и без задействования жопно-сортирной темы, в менее бредовом формате. Меньше понта и украшений, больше дела.
>> Ну ётыдь, ну шо за вьюные разжижения мозгофекалий?
> Я тоже не понял. Поэтому попробуйте изложить мысль внятно и без задействования
> жопно-сортирной темы, в менее бредовом формате. Меньше понта и украшений, больше
> дела.Ну что за дети пошли... Какие понты, исключительно профессиональная терминология + капля здорового стёба. ОК, для особо непосвещённых.
Построение scalable syslog management решения не представляется возможным в отсутствие как минимум одного выделенного сервера, собирающего логи (сиречь журналы - для непосвещённых), желательно (если строим до конца правильно) с так называемыми Collection Stations, с предобработкой, в том числе и фильтрацией логов от информационного шума, с механизмами retention и rotation. Это хозяйство должно легко поддаваться сайзингу, ибо будущее захлёбывание его в приходящих потоках нарушает ещё один важный элемент, лежащий на нём: это, согласно айтилу - с 3-й версии (ITIL, который, как мы все прекрасно помним, зародился в управленческих недрах Великобритании) event management.
Да, так вот: в этом случае действительно используется db backend, но ЭТА ХРЕНЬ имеет мало общего со скромными демонами журналов на местах. Разве что пропись в конфиге а-ля
*.* @finlandia
Так понятнее?
> исключительно профессиональная терминологияэто не «профессиональная терминология», это кулхацкерский мунспик был. мало ли, где как кулхацкеры разговаривают, что, за каждым деклассированным элементом следить, что ли?
>> Это попытка переизобрести gzip?
> Gzip не позволяет доступ на ходу. А 20 гиговую портянку сам, пожалуйста,
> декомпрессуй своим гзипом. И да, если уж о скорости, тесктовые логи
> зачастую отключают т.к. на серверах все начинает упираться именно в запись
> логов.Логи в продакшене отключают только идиоты. Вменяемые админы, если дисковое и/о из-за логов становится проблемой, пишут логи сразу на удаленный сервер логов, потому что сервис без логирования его работы никакому траблшутингу не поддаётся в принципе, а вменяемые админы не любят беспомощно разводить руками, когда случается внезапный service outage, им больше нравится возможность узнать из лога, что просходило с сервисом непосредственно перед отказом.
Кстати поэтому, вменяемых админов сабж врядли обрадует, тк если это будет бд в каком-то виде, то никогда нельзя быть уверенным, что сможешь быстро прогрепать логи, чтобы быстро найти причину и восстановить работоспособность сервиса в кратчайшие сроки. Зато точно понятно, что все написанные годами скрипты и парсеры идут лесом. А меж тем, эта новая бд может (а значит будет) крешиться, и тд - это дополнительный point of failure, усложнение на ровном месте, которое никаких серъезных преимуществ не даёт, зато имеет вполне очевидные недостатки. В общем, это печально всё... что так много, судя по выкрикам, ленартов поттерингов вокруг, для которых KISS и бритва оккама - пустые знаки.
> ... И да, если уж о скорости, тесктовые логи
> зачастую отключают т.к. на серверах все начинает упираться именно в запись
> логов.Мне пытаются впарить мысль, что DB (!!!) будет быстрее, чем plain-file на одном оборудовании. Или я что-то пропустил?
>> ... И да, если уж о скорости, тесктовые логи
>> зачастую отключают т.к. на серверах все начинает упираться именно в запись
>> логов.
> Мне пытаются впарить мысль, что DB (!!!) будет быстрее, чем plain-file на
> одном оборудовании. Или я что-то пропустил?работа с БД в большинстве случаев быстрее plain-file. начиная с того, что нормализация уменьшает размер в 10-30 раз и продолжая индексами по любым требуемым полям. plain-file хорошо пока не нужно проводить анализ на больших объемах.
> Тока не в этом конкрэтном. Ибо инсерты будут валить как из ведра.Значит формат должен допускать лобовой и быстрый инсерт максимально компактных записей, ВНЕЗАПНО.
И да, в file.log уточнять по 200 раз в секунду что это действительно хост В.Пупкина - явный оверкилл и расход места. А зачем мне 200 раз в секунду это знать?
> А зачем мне 200 раз в секунду это знать?То есть атрибута навроде src_ip в блобгах Вы не предполагаете? 8-[ ]
Упаковка на основе создания контекстов (а-ля X11) возможна, конечно -- но соответственно усложняется анализатор и не при всяком соотношении изменчивых частей к повторяющимся это разумней уже не раз упомянутой компрессии общего назначения.
> То есть атрибута навроде src_ip в блобгах Вы не предполагаете? 8-[ ]Предполагаю, но полагаю что возможность сокращенно референсить повторную информацию является плюсом.
> Упаковка на основе создания контекстов (а-ля X11) возможна, конечно -- но соответственно
> усложняется анализатор и не при всяком соотношении изменчивых частей к повторяющимся
> это разумней уже не раз упомянутой компрессии общего назначения.Да зачем контексты то? Просто отсыл что а вот это поле уже было, брать рядом, а именно - там. И все. Ну или взять за правило что поле указывается только если оно изменилось с прошлого раза (что однако ж чревато тем что при парсинге разрушенного лога будет распарсено неправильно).
> Предполагаю, но полагаю что возможность сокращенно референсить повторную информацию
> является плюсом.1) каков критерий повторности?
2) референсить можно и в текстовом, вопрос в цене выяснения факта повторности в т.ч.> Да зачем контексты то? Просто отсыл что а вот это поле уже было,
> брать рядом, а именно - там.Откуда оно "туда" попадёт и когда уйдёт?
> И все. Ну или взять за правило что поле указывается только если оно изменилось
> с прошлого раза (что однако ж чревато тем что при парсинге разрушенного
> лога будет распарсено неправильно).Вы будто пытаетесь описать крайне квадратноколёсый компрессор узкоспециального вида. :)
>> Тока не в этом конкрэтном. Ибо инсерты будут валить как из ведра.
> Значит формат должен допускать лобовой и быстрый инсерт максимально компактных записей,
> ВНЕЗАПНО.Угу. С блэкджеком и шлюхами.
> И да, в file.log уточнять по 200 раз в секунду что это
> действительно хост В.Пупкина - явный оверкилл и расход места. А зачем
> мне 200 раз в секунду это знать?Да пофигу, ибо не уточнять, но идентифицировать.
>> работа с БД в большинстве случаев быстрее plain-file.
> Тока не в этом конкрэтном. Ибо инсерты будут валить как из ведра.
> И вот када тазик даже не просядет - проляжет (или мы
> их транзакциями по n штук пендюрить бум?А кто вас сказал чтоб это будет *реляционная* СУБД? шарашить с спец формате рассчитанном на эффективную запись. даже при снижении скорости чтения анализ будет идти быстрее чем grep.
Далее plain-text можно ускорить в несколько раз если заменить hostname на hostId, время указывать в виде unix-time как набор байт, а не "03-Мрт-12 04:48". Какое приложение выдало сообщение - локальный идентификатор размером в int.
Ща глянул на дефолтовые логи - половина записи это мета-информация, которая может быть легко нормализована. Т.е. если сейчас система логирования справляется с текущей нагрузкой, то при замене на бинарь она будет в два раза быстрее (уменьшение на 50% размера средней записи, значит за то же время можно записать на 200% больше, т.е. в два раза).
Для дефолтового лога апача ускорение будет в 1,5 раза (мета-информация занимает примерно треть).
>>> работа с БД в большинстве случаев быстрее plain-file.
>> Тока не в этом конкрэтном. Ибо инсерты будут валить как из ведра.
>> И вот када тазик даже не просядет - проляжет (или мы
>> их транзакциями по n штук пендюрить бум?
> А кто вас сказал чтоб это будет *реляционная* СУБД? шарашить с спец
> формате рассчитанном на эффективную запись. даже при снижении скорости чтения анализ
> будет идти быстрее чем grep.Вы. Вы описываете тютелька в тютельку именно такую DBMS и потом удивлённо разводите вашими же руками.
> Далее plain-text можно ускорить в несколько раз если заменить hostname на hostId,
> время указывать в виде unix-time как набор байт, а не "03-Мрт-12
> 04:48". Какое приложение выдало сообщение - локальный идентификатор размером в int.Вот, именно об этом я и говорю. Проведём нормализацию, напендюрим справочников и т.п. - именно это и характеризует _R_DBMS.
> Ща глянул на дефолтовые логи - половина записи это мета-информация, которая может
> быть легко нормализована. Т.е. если сейчас система логирования справляется с текущей
> нагрузкой, то при замене на бинарь она будет в два раза
> быстрее (уменьшение на 50% размера средней записи, значит за то же
> время можно записать на 200% больше, т.е. в два раза).Чушь. Сислог крайне чувствителен ко времени записи, а запись в DBMS априори медленнее простого добавления строки в файл.
> Для дефолтового лога апача ускорение будет в 1,5 раза (мета-информация занимает примерно
> треть).Конечно не будет, указал по чему.
>> Далее 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 пишет в бинарные файлы. ;)
йопт. на поиск «повторяющихся элементов» в словарях время уходит, нет? а если логов *много* и *разных*? а словари при этом активно меняются, что-то устаревает, что-то добавляется. а логи в это время прут. привет, блокировки. привет, синки словарей и вытесняющие хэши. в итоге красивый теоретический нормализованый дизайн приходит к delicious flat chests. ну, может, с очень маленькими бугорками.и да: во многих случаях текстовые файлы — отличный формат *записи*. а ничего, что «СУБД» — они не только для записи? логи — это *очень* специализированая база, и задача скорости выборки тут решается по другому совсем.
впрочем, можешь хранить логи в оракле, чо — кто ж тебе запретит. только руководителям — если они люди немного смыслящие — это не предлагай: могут умереть от смеха.
> Мне пытаются впарить мысль, что DB (!!!) будет быстрее, чем plain-file на
> одном оборудовании. Или я что-то пропустил?Пытаются впарить мысль что запись эвента в минимальном бинарном виде без повторяющихся полей может весить в _разы_ меньше.
Так, похожий пример: жил был OSM. Хранил карту в XML. Когда карта мира стала весить в XML 250 гигов так что работать с ней стало невозможно, чуваки очень быстро осознали свои ошибки и сделали эффективный бинарный формат где все данные представлены настолько компактно насколько это можно сделать. И оно весит 14 гигз. Небольшая такая разница, всего примерно в 20 раз...
>> Мне пытаются впарить мысль, что DB (!!!) будет быстрее, чем plain-file на
>> одном оборудовании. Или я что-то пропустил?
> Пытаются впарить мысль что запись эвента в минимальном бинарном виде без повторяющихся
> полей может весить в _разы_ меньше.
> Так, похожий пример: жил был OSM. Хранил карту в XML. Когда карта
> мира стала весить в XML 250 гигов так что работать с
> ней стало невозможно, чуваки очень быстро осознали свои ошибки и сделали
> эффективный бинарный формат где все данные представлены настолько компактно насколько
> это можно сделать. И оно весит 14 гигз. Небольшая такая разница,
> всего примерно в 20 раз...Ну иоптыдь, Опенстриты, они читают на порядки чаще, нежели пишут! :)
> Ну иоптыдь, Опенстриты, они читают на порядки чаще, нежели пишут! :)Пишут его тоже часто и много. И работать с 250Г чушкой в XML попросту не прикольно. Это тормозно и на чтение и на запись.
>> Ну иоптыдь, Опенстриты, они читают на порядки чаще, нежели пишут! :)
> Пишут его тоже часто и много. И работать с 250Г чушкой в
> XML попросту не прикольно. Это тормозно и на чтение и на
> запись.Повторюсь: на порядки меньше!
ну и какой идиот изначально додумался базу с необходимым по дизайну random access хранить в xml? он грибов объелся, что ли?
>1. Недостаточная компактность. Особенно неприятно отсутствие возможности дедупликации повторяющихся данных (например, имя хоста). Соответственно, это сильно замедляет хранение, поиск и обработку. В частности, именно поэтому наиболее нагруженные лог-системы (в частности, юниксовый аудит) работают исключительно с бинарными логами.Дедупликация подразумевает сложную структуру хранения, подобную реляционной или какой-нибудь другой СУБД. Это усложняет демон не в разы, а на несколько порядков, и замедляет его на столько же. А лог должен быть максимально простым и быстрым.
>2. Неструктурированность. Опять же сильно затрудняет обработку и поиск данных. Кроме того, порождает кучу проблем совместимости - добавление нового поля в структуру не ломает существующие анализаторы логов, в отличие от изменения форматной строки.>
JSON и ему подобные форматы решают эту проблему.
> Дедупликация подразумевает сложную структуру хранения, подобную реляционной или какой-нибудь
> другой СУБД. Это усложняет демон не в разы, а на несколько
> порядков, и замедляет его на столько же. А лог должен быть
> максимально простым и быстрым.То же самое можно сказать про любую SQL-совместимую СУБД. Но почему-то среди них популярны мускул, постргрес и скулайт, причем их бакэнды почему-то работают с бинарными форматами :)
> JSON и ему подобные форматы решают эту проблему.
Но проблему объема они не решают. Поэтому их рациональнее использовать на следующем этапе обработки - формирование отчетов и выборок по БД логов.
все твои улыбки в основном от того, что ты считаешь: one size fits all. и волшебные слова «база данных» понимаешь очень однобоко.
> Дедупликация подразумевает сложную структуру хранения,Угу, аж возможность референса в сторону - "а вот это уже было, брать вон там вот столько".
Капитан также сообщает что именно этим занимается например лемпел-зив, известный каждому продвинутому школьнику. Хотя, конечно, скрипткидиотам и это - "слишком сложно". Осознать что такое length и offset - ракетная наука, однако.
> JSON и ему подобные форматы решают эту проблему.
И чем оно лучше? Могу сказать чем хуже.
1) Жирнее в разы
2) во столько же тормознее в парсинге.
3) Читаемость на глаз, особенно в компактном виде и без переформатирования - никакая,
4) Сложен в парсинге. Требует специальной либы.
5) Вопрос с индексацией не решен.Ну вот хочу я позырить "а что делал айпи XX.YY.ZZ.JJ в системе с разными демонами с AA.BB.CC до DD.EE.FF?". Размер лога - 20 гигз. И чем мне ваш json поможет? Тем что вместо 20 гигсов станет 60, которые к тому же просто грепом - уже как-бы неудобно, да? :)
> прекрасно делаются, сами журнальные записи тоже текстовыеАнализировать быстро и на автомате и ловить потенциально интересные эвенты довольно геморно. В случае структурированности можно быстро и просто фильтрануть, например. Или отсортировать по критерию. В случае текста надо какие-то костыли. Грепать или индексить всю портянку на 20 гигз можно и задолбаться. А когда она уже в удобном виде - почему бы и нет?
> Анализировать быстро и на автомате и ловить потенциально интересные эвенты довольно геморно.
> В случае структурированности можно быстро и просто фильтрануть, например. Или отсортировать
> по критерию. В случае текста надо какие-то костыли. Грепать или индексить
> всю портянку на 20 гигз можно и задолбаться. А когда она
> уже в удобном виде - почему бы и нет?Заметим, что идея грепа лога сама по себе порочна. Добавление в строку нового поля, или изменение формулировки сообщения ломает работу всех хитроумных regexpов.
> Заметим, что идея грепа лога сама по себе порочна.Я бы сказал 50/50, потому что гибкость - хорошая, да. И позволяет завернуть очень хитрый критерий для аналитики, которого вот так сходу может и не быть. С другой стороны, грепать 20-гиговую портянку на каждую оказию - удовольствие ниже среднего.
> Добавление в строку нового поля, или изменение формулировки сообщения ломает
> работу всех хитроумных regexpов.Ну вот поэтому я и полагаю что в принципе сабж имеет право на жизнь, ЕСЛИ оставят нормальный интерфейс для грепалок на случай когда надо завернуть какую-то хитрозагнутую аналитику, скорость которой не важна, а вот готового тулса не оказалось и все тут, так что цепочка грепов - единственный простой вариант.
> Я бы сказал 50/50, потому что гибкость - хорошая, да. И позволяет
> завернуть очень хитрый критерий для аналитики, которого вот так сходу может
> и не быть.Хм. Вы когда-нибудь с SQL работали? Скажу по секрету: там возможностей для хитрой аналитики куда больше, чем в простом грепе =)
Логично, что для работы со структурированными данными, будет использоваться язык структурированных запросов (a.k.a. SQL), или некий его аналог.
>Хм. Вы когда-нибудь с SQL работали? Скажу по секрету: там возможностей для хитрой аналитики куда больше, чем в простом грепе =)Practical Extraction and Report Language. На SQL-е - умахаешься.
Впрочем поЦерингов это не остановит :(
> Хм. Вы когда-нибудь с SQL работали? Скажу по секрету: там возможностей для
> хитрой аналитики куда больше, чем в простом грепе =)1) Я не считаю что для анализа логов мне надо бросить все и стать DBA
2) Я не считаю что для анализа логов мне надо бросить все и стать SQL programmer.
3) Базы SQL в общем случае не отличаются скоростью и компактностью.
4) Оно слишком много всего умеет: перспектива словить SQL injection в системе логгинга - здорово придумано. А что, пусть хакер и ломится через систему логгинга сразу.
5) В общем случае SQL базы не дизайнились быть устойчивыми от хакинга, удаления записей задним числом без простого обнаружения этого факта, etc.
>Скажу по секрету: там возможностей для хитрой аналитики куда больше, чем в простом грепе =)Т.е. вы хотите сказать, что DSL, коим является SQL имеет больше возможностей, чем тьюринг-полный язык (bash+grep+tools+sed+awk)?
А где такая трава продается? :)
> Заметим, что идея грепа лога сама по себе порочна. Добавление в строку
> нового поля, или изменение формулировки сообщения ломает работу всех хитроумных regexpов.Да, вспоминается, как аккуратненько добавил разок дополнительное поле в конец лог-строки апача. И все, вебалайзер тут же загнулся.
> Анализировать быстро и на автомате и ловить потенциально интересные эвенты довольно геморно.
> В случае структурированности можно быстро и просто фильтрануть, например. Или отсортировать
> по критерию. В случае текста надо какие-то костыли. Грепать или индексить
> всю портянку на 20 гигз можно и задолбаться. А когда она
> уже в удобном виде - почему бы и нет?Узкое место --- не в чтении/парсинге/поиске, в записи. (поиск --- значительно более редкая и менее требовательная к скорости получения результата операция, по сравнению с записью).
>> прекрасно делаются, сами журнальные записи тоже текстовые
> Анализировать быстро и на автомате и ловить потенциально интересные эвенты довольно геморно.
> В случае структурированности можно быстро и просто фильтрануть, например. Или отсортировать
> по критерию. В случае текста надо какие-то костыли. Грепать или индексить
> всю портянку на 20 гигз можно и задолбаться. А когда она
> уже в удобном виде - почему бы и нет?Не-а, бинарь в принципе не удобен. Эт раз.
Для первичного анализа берутся не сами логи, но уже очищенные от инфошума, эт два.
И тока ежели оно действительно дальше нуна (отрицательная вероятность), берётся часть простыни, локализированная по.
> Не-а, бинарь в принципе не удобен. Эт раз.Бинарь в принципе ничем не отличается от текстаря. Поскольку вы не читаете сектора диска напрямую с DMA с блинов в мозг, так или иначе нужны какие-то программы. В каком именно они варианте данные прочтут мне не так уж принципиально. Если это потом можно удобным утилям скормить. Кстати gzip вы в уме вообще нифига не распакуете, если уж на то пошло.
> Для первичного анализа берутся не сами логи, но уже очищенные от инфошума, эт два.
1) Чистить вотпрямща 100500 гигз логов за последнюю неделю - довольно не прикольное начинание. А критерии того что есть шум становятся известны вот сей момент и только так.
2) Опять же, в рантайм в реальном времени все это делать неудобно.
3) А еще у кучи демонов разные форматы логов.> И тока ежели оно действительно дальше нуна (отрицательная вероятность),
> берётся часть простыни, локализированная по.Что есть отрицательная вероятность? :)
>> Не-а, бинарь в принципе не удобен. Эт раз.
> Бинарь в принципе ничем не отличается от текстаря. Поскольку вы не читаете
> сектора диска напрямую с DMA с блинов в мозг, так или
> иначе нужны какие-то программы.Не текстовый формат весьма и весьма не удобен. Малоюзабелен.
> В каком именно они варианте данные прочтут
> мне не так уж принципиально. Если это потом можно удобным утилям
> скормить. Кстати gzip вы в уме вообще нифига не распакуете, если
> уж на то пошло.
>> Для первичного анализа берутся не сами логи, но уже очищенные от инфошума, эт два.
> 1) Чистить вотпрямща 100500 гигз логов за последнюю неделю - довольно не
> прикольное начинание. А критерии того что есть шум становятся известны вот
> сей момент и только так.Никто вотпрямща и не чистит, кстати.
> 2) Опять же, в рантайм в реальном времени все это делать неудобно.
Очень удобно. Если, конечно, Вы не собираетесь делать это ручками.
> 3) А еще у кучи демонов разные форматы логов.Тем паче текстовый формат.
>> И тока ежели оно действительно дальше нуна (отрицательная вероятность),
>> берётся часть простыни, локализированная по.
> Что есть отрицательная вероятность? :)Это вероятность, меньшая нулевой :)
Итак, давайте обдумаем. Допустим что syslog действительно устарела (устаревание софта понимается однозначно - невозможность решить новые задачи, появившиеся вследствии возникновения новых требовании к системе журналирования, путем доработки/модернизации существующей системы). В этом случае syslog либо потребует замены на систему с расширенным функционалом, либо требует такой переработки, которая может затронуть существующую архитектуру системы вцелом так что увиличение номера мажорного релиза не будет явным образом отражать масштабы прогресса (однако если вспомнить про веб-сервер apache с его развитием веток 1x и 2x и сопоставить с изменениями, то можно предположить что увиличение значения индикатора мажорного релиза будет более чем достаточным). Я вам это описал чтобы вы поняли суть происходящего/предстоящего. Ну а вы увидели лишь формат хранения/представления логов. Понимаете ли, неуважаемый, формат представления данных это, вообще говоря, вопрос второстепенный, поскольку он решается очень просто - путем написания одной единственной утилиты для конвертирования. И еще раз, чтобы дошло наверняка: разница между бинарными и текстовымы форматами хранения не несет сколько-нибудь принципиальной разницы и оба формата представления вполне пригоды для использования. Это я к тому что прикрутить к syslog хранение в бинарном представлении - это простое дело одного коммита (нужны всего лишь две функции кодирования и декодирования, которые можно выбросить в разделяемую библиотеку и позже предоставить API для возможности написания сторонних утилит). Но вы обо всем этом не подумали (по каким-то личным причинам), однако поспешили выступить "громко" в сторону линукса.Вывод: текст вашего сообщения оказался низкокачественным де!!мом (вы со средне-серым образованием или обычный гуманитарии?)
Слишком много букв. Но что делать, если утилита посчитает бинарный лог испорченным и пошлёт куда подальше? Представляется ли возможным что-то быстро предпринять на коленке в таком вот экстренном случае?
Снова на второстепенные вещи отвлекаетесь:1. Много букв потому то в тексте подробности (внезапно?).
2. Утилита утилите рознь (тут надо смотреть на реализацию утилиты и, особенно, на формат логов (бинарность логов не обязательно подразумевает их архивацию в сполшной solid-архив; можно сжимать на уровне сообщения/строк/записи и т.д.) ).
Это важный вопрос, но не первой важности, т.к. он не определяет архитектуру и возможности. А разговоры именно об этом
Об этом и речь была. Цитирую: "разница между бинарными и текстовымы форматами хранения не несет сколько-нибудь принципиальной разницы". Ключевое здесь: "не несет принципиальной разницы". Просто часть читающих опеннета не осиливает текст моего сообщения (да куда там до понимания сути сообщения когда часть тут новости (пересказ в кратком изложении) не осиливает даже на половину).
> Об этом и речь была. Цитирую: "разница между бинарными и текстовымы форматами
> хранения не несет сколько-нибудь принципиальной разницы". Ключевое здесь: "не несет принципиальной
> разницы". Просто часть читающих опеннета не осиливает текст моего сообщения (да
> куда там до понимания сути сообщения когда часть тут новости (пересказ
> в кратком изложении) не осиливает даже на половину).Разница между текстовым и бинарным форматом - логическое следствие разницы между структурированными и неструктурированными данными.
Нет, конечно, можно и текстовые данные структурировать (JSON там, XML), но не на таких объемах, как в случае с логами.
>Разница между текстовым и бинарным форматом - логическое следствие разницы между структурированными и неструктурированными данными.Вы не врубаетесь в самую суть: формат хранения логов это второстепенные вещи и нет никакой проблемы перегнать с одного формата в другой.
>Нет, конечно, можно и текстовые данные структурировать (JSON там, XML), но не на таких объемах, как в случае с логами.
Проблема сжать существующие логи? Или проблема навесить структуризацию на текущий способ?
>>Разница между текстовым и бинарным форматом - логическое следствие разницы между структурированными и неструктурированными данными.
> Вы не врубаетесь в самую суть: формат хранения логов это второстепенные вещи
> и нет никакой проблемы перегнать с одного формата в другой.
>>Нет, конечно, можно и текстовые данные структурировать (JSON там, XML), но не на таких объемах, как в случае с логами.
> Проблема сжать существующие логи? Или проблема навесить структуризацию на текущий способ?Поддреживаю.
Собершенно непонятно вокруг чего проблема, если нужны структурированные данные, загоняем
логи через rsyslog в базу на удалённом сервере, параллельно можно оставить в тексте (если требуется).Хранение логов на рабочем сервере (в любом виде) может помочь только в решении системных проблем. В этом случае их структурированность совершенно необязательна, вам всё равно потребуется просматривать всё записи в логе(ах) последовательно в поисках аномалий.
Причём отдельные события могут быть абсолютно обыденными, но вот их последовательность может вам сказать об ошибке.
В этом случае разворачиваем базу в простыню? Зачем тогда загоняли в базу?
В случае взлома, локальные логи теряют смысл, так как доступ к логам/базе логов
есть у взломщика есть и изменить данные и даты не составляет особого труда.Кто-нибудь может обьяснить, что _нужного_ умеет "Lumberjack" ?
>>Нет, конечно, можно и текстовые данные структурировать (JSON там, XML), но не на таких объемах, как в случае с логами.
> Проблема сжать существующие логи? Или проблема навесить структуризацию на текущий способ?Проблема сделать логи структурированными. Решение этой задачи попутно решит ряд проблем таких как размер логов, падение анализаторов при добавлении новых полей, невозможность применения одинаковых анализаторов для различных приложений. Раскрою последнее утверждение: хотя данные, которые создают разные приложения в логах подобны, но различен формат и потому нет универсального анализатора.
А случае структурированных логов анализатор проверяющий кто заходил на apache с 3 до 5 однозначно будет работать и на DNS и на любых других системах потому что формат стандартизован.
Стандартизация представления логов внешним приложениям - одна из основных задач journald и subj.
>>Разница между текстовым и бинарным форматом - логическое следствие разницы между структурированными и неструктурированными данными.
> Вы не врубаетесь в самую суть: формат хранения логов это второстепенные вещи
> и нет никакой проблемы перегнать с одного формата в другой.
>>Нет, конечно, можно и текстовые данные структурировать (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*255PRINTUSASCIIAPP-NAME = NILVALUE / 1*48PRINTUSASCII
PROCID = NILVALUE / 1*128PRINTUSASCII
MSGID = NILVALUE / 1*32PRINTUSASCIITIMESTAMP = 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 3629OCTET = %d00-255
SP = %d32
PRINTUSASCII = %d33-126
NONZERO-DIGIT = %d49-57
DIGIT = %d48 / NONZERO-DIGIT
NILVALUE = "-"
Что нужно ищо этому безумному, выпрашивающему бинарного формата, как Моисей Египетович манны (или маны :) )?
>Что нужно ищо этому безумному, выпрашивающему бинарного форматаЕму раскидали то что он уткнулся лишь в поверхностные, второстепенные вещи, но он и дальше свое гнет потому что целью для него не является поиск объективной картины (придется принять факт того что форма представления все-такие вещи второстепенные), а его цель - любой ценой не оказаться не правым (возможно, у него проблемы психического плана из далекого детства и/или просто зашкаливает ЧСВ, но нам то до него и его проблем ..). Такие дела ..
>>Что нужно ищо этому безумному, выпрашивающему бинарного формата
> Ему раскидали то что он уткнулся лишь в поверхностные, второстепенные вещи, но
> он и дальше свое гнет потому что целью для него не
> является поиск объективной картины (придется принять факт того что форма представления
> все-такие вещи второстепенные), а его цель - любой ценой не оказаться
> не правым (возможно, у него проблемы психического плана из далекого детства
> и/или просто зашкаливает ЧСВ, но нам то до него и его
> проблем ..). Такие дела ..И самое забавное, что своими действиями усугубляет именно в этом направлении :)
> Она УЖЕ структурирована, в эрэфсях это чётко прописано (это свежий):Ну так перцы тоже решили реализовать стандарт. А то что он бинарный - ну и болт бы с ним. Я же не воняю что gzip не только бинарный но и вообще не декодируем в уме и с ножом к горлу требует утилиту gzip для работы, правда?
> Я же не воняюВы просто передёргиваете.
> что gzip не только бинарный
gzip, cat, $EDITOR -- универсальные, в отличие от.
> gzip, cat, $EDITOR -- универсальные, в отличие от.А что мешает сделать прозрачную развертку этого формата в текст как gzip это делает для сжатого формата? Ничего? Хм, так это вопрос наличия утилит делающих это.
>> gzip, cat, $EDITOR -- универсальные, в отличие от.
> А что мешает сделать прозрачную развертку этого формата в текст как gzip
> это делает для сжатого формата? Ничего?Вот Вы (как понимаю) в #193 описали сворачивание по IP. Попробуйте набросать структуру данных и псевдокод, который сделает разворачивание в текст.
Мне пока кажется, что получится или размазанный по данным словарик (IP-шники же приходят новые, иначе совсем узкий случай), или отдельная вспомогательная сущность. С первым как раз в случае потоковой обработки _всего_ массива более-менее эффективная реализация просматривается (поскольку можно идти окошком по данным, пополняя словарик и зная, что при записи сперва пополнялся он, затем значения использовались в потоке). А вот при хвалёном произвольном доступе -- что-то сходу не соображу, как выкрутиться. Если же держать эту сущность отдельно, то gzip уже не получается, а получается нечто с набором тайных знаний в пузе о том, где эти отдельности искать, или с ключами, которые надо обязательно задать (или же фолбэк с первого на второе, не суть).
Есть старое доброе правило: не усложняй сверх необходимого. И что-то эта молодая гвардия его не выучила, похоже -- ломят непотребства имени себя, как джоэловский MSDN camp...
PS: заметьте, это мы с Вами подразумеваем некую фиксированную схему для одного случая. А если схемы разные... а ещё и корректируемые...
>[оверквотинг удален]
> приходят новые, иначе совсем узкий случай), или отдельная вспомогательная сущность.
> С первым как раз в случае потоковой обработки _всего_ массива более-менее
> эффективная реализация просматривается (поскольку можно идти окошком по данным, пополняя
> словарик и зная, что при записи сперва пополнялся он, затем значения
> использовались в потоке). А вот при хвалёном произвольном доступе --
> что-то сходу не соображу, как выкрутиться. Если же держать эту
> сущность отдельно, то gzip уже не получается, а получается нечто с
> набором тайных знаний в пузе о том, где эти отдельности искать,
> или с ключами, которые надо обязательно задать (или же фолбэк с
> первого на второе, не суть).Вы правы - это тайный набор знаний. Его специально выделяют в отдельную сущность с доступом через API.
Опять же grep не имеет произвольного доступа - только прямое чтение. И плакальщики из этого треда уверяют, что это самый лучший вариант. Так что меняя plain-text на потоковый файл, где общие сущности живут в пополняемых словарях, получаем ускорение потокового чтения и записи (данные уже сжаты). Сам принцип сохраняется.
> Так что меняя plain-text на потоковый файл, где общие сущности живут в
> пополняемых словаряхЯ и подводил пишущего к мысли, что мы, скорее всего, попадаем на мини-DB и мини-DBA, а также прочий совершенно излишний в тривиальных случаях оверхед -- за который не должны платить ресурсами и разрывом мозга те, кому он не упёрся.
Проблема этих обновленцев в том, что они усложняют тривиальный случай нужным в весьма нетривиальном вместо того, чтобы простое оставить простым, а своё громоздить в сторонке.
>>>Разница между текстовым и бинарным форматом - логическое следствие разницы между структурированными и неструктурированными данными.
>> Вы не врубаетесь в самую суть: формат хранения логов это второстепенные вещи
>> и нет никакой проблемы перегнать с одного формата в другой.
>>>Нет, конечно, можно и текстовые данные структурировать (JSON там, XML), но не на таких объемах, как в случае с логами.
>> Проблема сжать существующие логи? Или проблема навесить структуризацию на текущий способ?
> Она УЖЕ структурирована, в эрэфсях это чётко прописано (это свежий):Сам MSG не структурирован. Как по вашему задаются обязательные и дополнительные поля для MSG? никак. в этом и проблема, которую хотят вылечить.
Дальше дыры в безопасности: наличие в теле сообщения APP-NAME, PROCID, TIMESTAMP (возможно и других подобных полей). Приложение не должно иметь API для того чтобы выдать себя за другое или использовать другое время.
API должен быть подобный (псевдо код):
спикокПолейИЗначений = {
"поле1":"значение поля 1",
"IP":127.0.0.1,
};
LOG.debug("сообщение для человека без данных", списокПолейИЗначений);И нигде не должно запрашиваться у приложения его ИМЯ, procid и дата записи. ДАТА - по факту логирования, ИМЯ и procid - по факту того кто вызвал запись. И т.п. иначе запись что приложение Маша с хоста Вася является скомпрометированной поскольку приложение может подменить и хост и собственное имя.
PS спасибо, что подтвердили мои догадки, что RFC не описывает структуру самого сообщения. Ваша цитата наглядно это показывает )))))
>> Она УЖЕ структурирована, в эрэфсях это чётко прописано (это свежий):
> Сам MSG не структурирован. Как по вашему задаются обязательные и дополнительные поля
> для MSG? никак. в этом и проблема, которую хотят вылечить....
От ёптыдь, попробую объяснить по аналогии: Вы про тисипиайпи слыхивали? Про то, что опо пакетное? Так вот: Вы сначала предлагаете "структурировать" ай-пи пакет, потом, увидев, что он сто лет в обед как имеет жёсткую структуру, замалчиваете это, при этом громогласно заявляте что дата-часть пакета не структурирована. Вот такой театр абсурда.
> PS спасибо, что подтвердили мои догадки, что RFC не описывает структуру самого
> сообщения. Ваша цитата наглядно это показывает )))))Вы даже РФЦ не читаете? Тогда о чём Вы о кто Вы? :))
> От ёптыдь, попробую объяснить по аналогии: Вы про тисипиайпи слыхивали? Про то,
> что опо пакетное? Так вот: Вы сначала предлагаете "структурировать" ай-пи пакет,
> потом, увидев, что он сто лет в обед как имеет жёсткую
> структуру, замалчиваете это, при этом громогласно заявляте что дата-часть пакета не
> структурирована. Вот такой театр абсурда.Аналогия интересна, но не верна.
Изначальный постулат, который я развиваю это необходимость структуризации логирующего сообщения. Не только части формализованной в RFC, но всего сообщения. Чтобы IP клиента был отдельным полем с возможностью поиска или построения иной аналитики.
Кроме того RFC пропускает некоторые уязвимости. Попробую объяснить по аналогии: нужно было сделать передачу почтовых сообщение - сделали SMTP. Но сам протокол рассчитывает на ряд аксиом типа защищенности самого сервера. Уже много лет это дыры (просчеты) в протоколе позволяют спамить.
Данные RFC на логирование также имеет уязвимости, что терпимо сейчас, но в будущем может привести к повторению судьбы SMTP.
> Слишком много букв. Но что делать, если утилита посчитает бинарный лог испорченнымТогда с ним делать то же что и с испорченным текстовым логом. Открыли вы текстарь а там бред. Ну и чего?
> Это я к тому что прикрутить к syslog хранение в бинарном представлении - это простое дело одного коммита (нужны всего лишь две функции кодирования и декодирования, которые можно выбросить в разделяемую библиотеку и позже предоставить API для возможности написания сторонних утилит).А вы подумали о том, что старый API взаимодействия приложений с syslog не предназначен для передачи структурированных данных, и даже если ввести в современный rsyslog бинарный формат хранения, существенных бонусов это не даст.
> Вывод: текст вашего сообщения оказался низкокачественным де!!мом (вы со средне-серым образованием или обычный гуманитарии?)
Судя по вашей буйно реакции, а наступил на вашу любимую мозольку. Правда, пока не могу понять, где именно.
>А вы подумали о том, что старый API взаимодействия приложений с syslog не предназначен для передачи структурированных данных, и даже если ввести в современный rsyslog бинарный формат хранения, существенных бонусов это не даст.Не вижу никаких проблем чтобы расширить API. Это дело одного коммита.
>Судя по вашей буйно реакции, а наступил на вашу любимую мозольку. Правда, пока не могу понять, где именно.
Длинное сообщение получилось лишь потому что я попытался описать часть картины более полно (не опуская важные детали). Понять вы не можете вполне закономерно: вы ошиблись в расчетах (реакция у меня вполне обычная, а не буйная (это, кстати, проблема вашего восприятия с уклоном в эмоциональный фон) ). Вы о себе слишком высокого мнения.
> Не вижу никаких проблем чтобы расширить API. Это дело одного коммита.угу. один всемирный такой коммит, который автомагически поправит все клиенты.
> Вывод: текст вашего сообщения оказался низкокачественным де!!мом (вы со средне-серым образованием или обычный гуманитарии?)В чем-то вы правы =)
В своем посте я немножечко пожертвовал логичностью ради провокационности.
Действительно, ключевым моментом является введение API для работы со _структурированными_ данным. Бинарный формат лога - это лишь внешний атрибут, который сам по себе существенных бонусов не дает.
Просто меня забавляет реакция на это словосочетание ("бинарные логи") некоторых местных петушков, знакомых с юниксом исключительно понаслышке, но при этом обожающих рассказывать, что такое юниксвей, и как всем правильно жить =)
А мне вот не нравится идея бинарных логов. И бинарных конфигов. Просто - не нравится. Независимо от API. И совершенно неясно что в этом забавного. А вот забавно как раз наоборот - ваше отношение.
"Бинарный формат лога - это лишь внешний атрибут, который сам по себе существенных бонусов не дает."
"Просто меня забавляет реакция на это словосочетание ("бинарные логи")"
Расщепление сознания детектед?
> Просто меня забавляет реакция на это словосочетание ("бинарные логи") некоторых местных
> петушков, знакомых с юниксом исключительно понаслышке, но при этом обожающих рассказывать,
> что такое юниксвей, и как всем правильно жить =)Вот, если бы вы знали, что такое cat,grep,sed и другие умные слова для работы с текстовым форматом даных, то знали бы, что при парсинге глазами таких вот бинарных логов (что оч часто бывает полезным, представте) нужно будет либо конвертировать их перед этим в текстовые, либо писать аналоги всего выше сказанного (и не только), что, собственно, смахивает на промышленное велосипедостроение.
...хотя, да, это же дело одного коммита...
> Вывод: текст вашего сообщения оказался низкокачественным де!!мом (вы со средне-серым образованием
> или обычный гуманитарии?)На 100% выпускник какого-нибудь "ВУЗа" типа Мэждународного Университета Соломона, фак а-ля "экономическая кибернетика", сп-ть "визуализация табличных данных средствами MS Exhell".
Бакалавр околокомпьютерных наук со стажем.
> Бакалавр околокомпьютерных наук со стажем.Будем знакомы. И как оно вам, бакалаврам? :)
>> Бакалавр околокомпьютерных наук со стажем.
> Будем знакомы. И как оно вам, бакалаврам? :)Нам такие как Вы бакалавры забавны :)))
> Ну наконец-то и линукс дошел до того, что в юниксе сделано уже
> двадцать лет назад.Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?.
> Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые
> логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?.А еще в UNIX auditd (который гораздо важнее syslog), и он пишет бинарные логи.
>> Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые
>> логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?.
> А еще в UNIX auditd (который гораздо важнее syslog), и он пишет
> бинарные логи.А мексиканского кактуса бритого он важнее. аудитди не расскажет мне кто, аутентифицированный керберосом и авторизированный ЛДАПом, получил коннект через сквид.
И эта, советую поинтересовадзе сколько триггеров/рулз по дефолту в этом ди включено, почему это мизерная часть и шо будет, если этих цацок включить много.
> А мексиканского кактуса бритого он важнее. аудитди не расскажет мне кто, аутентифицированный
> керберосом и авторизированный ЛДАПом, получил коннект через сквид.А вот в предлагаемой вон теми парнями схеме - чуть более другой сервис пойдет и расскажет кто и какого хрена. В более-менее унифицированном формате.
>> А мексиканского кактуса бритого он важнее. аудитди не расскажет мне кто, аутентифицированный
>> керберосом и авторизированный ЛДАПом, получил коннект через сквид.
> А вот в предлагаемой вон теми парнями схеме - чуть более другой
> сервис пойдет и расскажет кто и какого хрена. В более-менее унифицированном
> формате.Так вот в том-то и дело, шо нет! Просто из-за дурацкого формата будут оверхед и неудобства. Всё.
> Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые
> логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?.Я так понимаю - вы просто не знакомы с юниксом.
Действительного, когда в мире есть лишь две оси - винда и убунта, все, что не убунта, кажется виндой. Но на самом деле в мире гораздо больше решений, и такая примитивная логика не позволит их осмыслить.
имхо, он про солярку)))
>> Ну наконец-то и линукс дошел до того, что в юниксе сделано уже
>> двадцать лет назад.rfc3164 достаточно свежая хреннь.
> Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые
> логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?.Ну... Это неуспешно скрыто за зарослями бинарного формата хранения логофф. :)
> Ну... Это неуспешно скрыто за зарослями бинарного формата хранения логофф. :)Выбросьте бинарный гзип уже? Вы его деревья хаффмана в уме вообще не построите. И на тетрадном листочке - задолбаетесь.
>> Ну... Это неуспешно скрыто за зарослями бинарного формата хранения логофф. :)
> Выбросьте бинарный гзип уже? Вы его деревья хаффмана в уме вообще не
> построите. И на тетрадном листочке - задолбаетесь.Ну да, ну да, а изчё выинты повыбрасываем - там коды царя соломона используют.
Тока ведь гзип-то, текстовой природы лога, сцуко, не меняет :)))
Наверное, стоило особо отметить, что к поддержке проекта уже присоединились компания Adicson, разрабатывающая rsyslog, и BalaBit, разрабатывающая syslog-ng.
> Наверное, стоило особо отметить, что к поддержке проекта уже присоединились компания 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%"
все как у людей :) хош джисон - бери джисон, хош срать в монго ( угу, свалка ) - сри; скуль тож можно, НО! текст никто не отменя ;)
А идиоту поможет только евтаназия
> А идиоту поможет только евтаназияЯ против подобного милосердия! В назидание! :))
> все как у людей :) хош джисон - бери джисон, хош срать
> в монго ( угу, свалка ) - сри; скуль тож можно,это не интересно. где научная ценность? где новизна диссертации? вот так взял и бэкэнд заменил. нет, надо раскататть в отдельный
Надеюсь, в линуксе наконец появится нормальный механизм удаленной репликации логов, с поддержкой шифрования и аутентификации.
>Нормальной репликации там нетТаки тролль. man rsyslog-mysql
>>Нормальной репликации там нет
> Таки тролль. man rsyslog-mysqlА об ng-syslog никто из анонов, судя по всему, даже не слыхал никогда?
>>>Нормальной репликации там нет
>> Таки тролль. man rsyslog-mysql
> А об ng-syslog никто из анонов, судя по всему, даже не слыхал
> никогда?Конечно нет. Все знают про syslog-ng.
>>>>Нормальной репликации там нет
>>> Таки тролль. man rsyslog-mysql
>> А об ng-syslog никто из анонов, судя по всему, даже не слыхал
>> никогда?
> Конечно нет. Все знают про syslog-ng.Хоть горшком назови. Только в печь не ставь. Судя по тому, что вспомнил о нем один я, фатальный недостаток - основная причина появления ливня из велосипедов, идущего каждую неделю.
>>>>>Нормальной репликации там нет
>>>> Таки тролль. man rsyslog-mysql
>>> А об ng-syslog никто из анонов, судя по всему, даже не слыхал
>>> никогда?
>> Конечно нет. Все знают про syslog-ng.
> Хоть горшком назови. Только в печь не ставь.Не-а. Искажение названия такого популярного пакета говорит о многом.
> Судя по тому, что
> вспомнил о нем один я, фатальный недостаток - основная причина появления
> ливня из велосипедов, идущего каждую неделю.Да прям таки.
> Таки тролль. man rsyslog-mysqlА ты сам-то читал, что там написано?
Особенно в части репликации логов с поддержкой шифрования и аутентификации, да в нативном формате.
> Таки тролль. man rsyslog-mysqlВы предлагаете конвертировать лог в бинарный формат, а потом реплицировать его средствами СУБД?
Замечательно, но зачем тогда вообще нужен rsyslog? Не проще ли приложениями сразу свой лог в бинарную БД писать, через клиентскую либу мускула?
>> Таки тролль. man rsyslog-mysql
> Вы предлагаете конвертировать лог в бинарный формат, а потом реплицировать его средствами
> СУБД?
> Замечательно, но зачем тогда вообще нужен rsyslog? Не проще ли приложениями сразу
> свой лог в бинарную БД писать, через клиентскую либу мускула?Немного более чем нет.
>> свой лог в бинарную БД писать, через клиентскую либу мускула?
> Немного более чем нет.Это что, подтверждение мысли о ненужности rsyslog? :)
>>> свой лог в бинарную БД писать, через клиентскую либу мускула?
>> Немного более чем нет.
> Это что, подтверждение мысли о ненужности rsyslog? :)Нет, подумайте об этом на досуге. :)))
> Таки тролль. man rsyslog-mysqlРепликация средствами мускула? Лол.
С тем же успехом можно текстовые логи через scp по крону копировать. А че, шифрование и аутентификация есть.
Другое дело, что это, во-первых, костыли (и под требование "нормальности" не попадает), во-вторых, rsyslog, который и должен этим заниматься, оказывается какбэ не при делах.
>> Таки тролль. man rsyslog-mysql
> Репликация средствами мускула? Лол.
> С тем же успехом можно текстовые логи через scp по крону копировать.
> А че, шифрование и аутентификация есть.
> Другое дело, что это, во-первых, костыли (и под требование "нормальности" не попадает),
> во-вторых, rsyslog, который и должен этим заниматься, оказывается какбэ не при
> делах.Делайте силой мыли, ибо всё остальное - КОСТЫЛИ!
> Делайте силой мыли, ибо всё остальное - КОСТЫЛИ!Не, дядя, мускуль в обязательном порядке для всего лишь ведения логов - это мегакостыль.
>> Делайте силой мыли, ибо всё остальное - КОСТЫЛИ!
> Не, дядя, мускуль в обязательном порядке для всего лишь ведения логов -
> это мегакостыль.Вы передёргиваете.
> В ходе встречи участники обсудили такие слабые места текущих подходов к ведению журнала событий как недостаточное внимание к журналированию со стороны разработчиков приложений, *разнообразие форматов журнальных записей*Разнообразие форматов журналов следует из разнообразия решаемых задач и разнообразия видов отображаемой информации, хотя не всегда. Унификация, конечно, хороша, но тут главное не переборщить
Лучшее враг хорошего.
а почему сислог они считают устаревшим?чем аргументируют?
http://bb.comp-house.ru/comp-house.repo/wiki/what-i-dont-lik...
> http://bb.comp-house.ru/comp-house.repo/wiki/what-i-dont-lik...Как видим, Герхардса с его проповедями про превосходство rsyslog успешно заткнули =)
>> 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...
> http://bb.comp-house.ru/comp-house.repo/wiki/journald-and-rs...Устаревшая инфа.
Судя по сабжевой новости, теперь мнение этого товарища радикально переменилось, и он уже рвется помочь Поттерингу с допилом journald.
> а почему сислог они считают устаревшим?
> чем аргументируют?Не умеет работать со структурированными данными (нет поддержки соответствующих форматов и API).
Так что теперь будет с journald?
> Так что теперь будет с journald?А ничего не будет. Он часть systemd и останется. Сделают пересылку в другой журнал, так же как сейчас пересылается в rsyslog. Дублирование журнала в разных форматов уже ни кого не пугает.
> Так что теперь будет с journald?К нему кроме его текущего API добавят ELAPT. А возможно ELAPI будет единственным API к jourland.
Плюс для back compatibility оставят некий интерфейс эмулирующий syslog.
> К нему кроме его текущего API добавят ELAPT. А возможно ELAPI будет единственным API к jourland.Скорее второе - нынешний API journald пока не стабилизирован, поэтому сейчас его проще и удобнее подогнать под ELAPI.
> Так что теперь будет с journald?Судя по всем, Lamberjack - это и есть journald, с небольшими косметическими изменениями. Так что скорее всего эти проекты объединят.
> Две недели назад компания Red Hat собрала в своем офисе
> разработчиков популярных систем ведения логов, чтобы обсудитьРадует то, что постарались обсудить, а не переть своим умом; удачи.
> Радует то, что постарались обсудить, а не переть своим умом; удачи.А может, они с systemd/upstart еще повторят? Для полного счастья? :)
>> Радует то, что постарались обсудить, а не переть своим умом; удачи.
> А может, они с systemd/upstart еще повторят? Для полного счастья? :)А может, они-таки наймут ОДНОГО вменяемого системного архитектора? И сделают ЕДИНОЕ решение? Совместимость-то важней и производительности и всего остального, если уж на то пошло. Актуальность этой максимы за 35 лет в ИТ посейчас не изменилась.
> И сделают ЕДИНОЕ решение?Даже у очень умных людей решения в стиле "вот, оно, единое" имеют тенденцию оказываться ущербными не в одном, так в другом. Именно поэтому юниксы с совместимостью по интерфейсам, а не искуственным вырождением поля реализаций, и живы вовсю до сих пор.
> Актуальность этой максимы за 35 лет в ИТ посейчас не изменилась.
Надо же, юниксы пятый десяток разменяли давно, а некоторые всё чуть ли не виндой мерить привыкли...
>> И сделают ЕДИНОЕ решение?
> Даже у очень умных людей решения в стиле "вот, оно, единое" имеют
> тенденцию оказываться ущербными не в одном, так в другом. Именно
> поэтому юниксы с совместимостью по интерфейсам, а не искуственным вырождением поля
> реализаций, и живы вовсю до сих пор.Мы это видим с каждым новым дистром линукса, которые уже числом, тащемта, за штуку перевалили. И, кстати, Linux is NOT UNIX (C) Линус, евжли память мне не врет.
Так шта, дорогой друг, ты прокламацию-то с проституцией б не путал.
>> Актуальность этой максимы за 35 лет в ИТ посейчас не изменилась.
> Надо же, юниксы пятый десяток разменяли давно, а некоторые всё чуть ли
> не виндой мерить привыкли...Гонишь. Юникс появился как система примерно в 1975м году. Я 67го года рождения и мне, как ты понимаешь, не пятьдесят. Это ты, видимо, админ с 1995 года.
> И, кстати, Linux is NOT UNIX (C) Линус, евжли память мне не врет.
> Так шта, дорогой друг, ты прокламацию-то с проституцией б не путал.Хм, пока похоже, что путаете GNU's Not UNIX с чем-то неприпоминаемым из высказываний Линуса как раз Вы; впрочем, не настаиваю.
> Гонишь. Юникс появился как система примерно в 1975м году.
Меня тогда ещё не было, как и летом 1969 -- так что спорить об официальной дате появления UNIX Вам придётся с другими людьми.
> Я 67го года рождения и мне, как ты понимаешь, не пятьдесят.
Hint: стукнет полтинник, вот и разменяете свой шестой десяток. (неужто незнакомое выражение?)
> Это ты, видимо, админ с 1995 года.
Вы мне льстите, тогда только-только в интернеты добрался... даже локалхоста своего ещё не было и программы многие писались между походами на кружок и другую машину в тетрадках.
PS: вру, кружки ввиду 145-ки тогда уже пошли лесом.
> И сделают ЕДИНОЕ решение?А кто не согласен - будет расстрелян, так?
А у несогласных никуда всегда была gentoo.
> А у несогласных никуда всегда была gentoo.LFS
> А у несогласных никуда всегда была gentoo.А что делать тем кому не нравится пидон в каждой дырке в системе? :)
> А может, они с systemd/upstart еще повторят? Для полного счастья? :)А что там повторять? Сейчас разработка upstart фактически превратилась в копипасту с systemd, так что понятно, кто в избе хозяин.
Вообще, на последнем фосдеме был слушок, что убунта собирается переходить на systemd начиная с 12.10 (сразу после выпуска LTS).
> А что там повторять? Сейчас разработка upstart фактически превратилась в копипасту с
> systemd, так что понятно, кто в избе хозяин.Ну вот я как раз за то чтобы они собрались и обсудили как и чего. К systemd больно дофига предъяв - то usr ему не там, то run не там, то еще дерьмо какое-то случается. Почему-то с upstart таковых воплей было ровно НОЛЬ...
> Вообще, на последнем фосдеме был слушок,
Пруф? Мы тут не старые карги на лавочке, так что сарафанное радио нас не устраивает.
> К systemd больно дофига предъяв - то usr
> ему не там, то run не там, то еще дерьмо какое-то
> случается. Почему-то с upstart таковых воплей было ровно НОЛЬ...
>> Вообще, на последнем фосдеме был слушок,
> Пруф? Мы тут не старые карги на лавочке, так что сарафанное радио
> нас не устраивает.Это вам-то пруф, с предъявами о usr?
Кто еще не видел: http://freedesktop.org/wiki/Software/systemd/separate-usr-is...
Чё они х...ей занимаются! Нужно структурированные, ну прилепи ты syslog2sql и радуйся жизни?!Движок есть - mysql, pgsql, mssql,...sql
Формат есть - SQL
На SQL даже какой-то стандарт есть!Осталось самую малость - заставить программистов писать SQL запросы.
> Чё они х...ей занимаются! Нужно структурированные, ну прилепи ты syslog2sql и радуйся
> жизни?!бинарное хранение это следствие, а не причина.
причина же в API для структурированных данных. структурированные данные можно и текстом хранить (хоть в csv). но syslog имеет API для неструктурированных данных (просто текст). если поменять API то можно безболезненно заменить syslog на journald или иной логгер.
вся проблема в том, чтобы сменить API с "лапшового" на строго структурированный.
> Чё они х...ей занимаются! Нужно структурированные, ну прилепи ты syslog2sql и радуйся... всяким там возможным SQL-иньекциям? :)
И да, как sql база обеспечит защиту от удаления записи задним числом, например?
> И да, как sql база обеспечит защиту от удаления записи задним числом, например?REVOKE ALL ON logdbase TO logodmin@'localhost';
GRANT INSERT ON logdbase TO logodmin@'localhost' IDENTIFIED BY 'passwd';
> Чё они х...ей занимаются! Нужно структурированные, ну прилепи ты syslog2sql и радуйся
> жизни?!
> Движок есть - mysql, pgsql, mssql,...sql
> Формат есть - SQL
> На SQL даже какой-то стандарт есть!
> Осталось самую малость - заставить программистов писать SQL запросы.А зачем SQL запросы, когда есть NoSQL решения?
С хранением данных чисто в оперативке!
Вам что, жалко пару десятков гигабайт оперативки под логи)
Сколько же воплей в этом треде... Никаких lumberjack и journald не будет ближайшее время. Успокойтесь. А что плохо и что хорошо, будут решать люди поумнее нас.
> люди поумнее нас.См. #128 :)
> люди поумнее нас.я, например, раз уж ты себя не считаешь достойным.
Название - игра слов.
log - бревно.
Lumberjack - дровосек.
Т.е. логоруб)
Нам предлагают систему, которая будет рубить логи.
На корню)Логи пишутся, чтобы их прочитать, а не чтобы их записать.
Имхо, ради средства жертвуют целью - удобством чтения.
Процесс ради процесса.<offtopic>
В последнее время стало модным внедрять что-то бинарное.
systemd, upstart, система логов от Поттеринга.У Microsoft сначала были ini файлы.
Потом они разработали "реестр".
Если сделать дамп реестра и сравнить его формат с форматом ini файла, можно найти, что они похожи.
Примерно, как братья-близнецы.
Это тот же самый ini файл, только теперь в бинарном формате, раскиданный по нескольким файлам.MS не придумал ничего лучше, чем сделать ini файлы в бинарном формате.
Что мы получили?
1. программы для дефрагментации реестра
2. файлы реестра раскиданы по разным местам
3. эти файлы просто так не скопировать, не открыть
4. а если их и скопировать, то чтобы открыть эти файлы, нужна специальная утилита
Прогресс, *ля.Как я рад, что в *nix для системных и пользовательских настроек используется первобытный и допотопный plain text формат.
Что позволяет открыть логи и конфиги 20 летней давности даже сейчас.
Без риска получить ошибку "неподдерживаемый формат. пересохраните данные в новом формате."
</offtopic>
> Название - игра слов.
> log - бревно.
> Lumberjack - дровосек.
> Т.е. логоруб)
> Нам предлагают систему, которая будет рубить логи.
> На корню)
> Логи пишутся, чтобы их прочитать, а не чтобы их записать.
> Имхо, ради средства жертвуют целью - удобством чтения.
> Процесс ради процесса.Адназначна! :)
> MS не придумал ничего лучше, чем сделать ini файлы в бинарном формате.Что мы получили?
1. программы для дефрагментации реестра
2. файлы реестра раскиданы по разным местам
3. эти файлы просто так не скопировать, не открыть
4. а если их и скопировать, то чтобы открыть эти файлы, нужна специальная утилита
Прогресс, *ля.Думаю, это легко объяснимо. MS важно привлечь разработчиков, а реестр - это отличный и легкий способ сохранять всякий мусор между запусками программы, не нагружая мозг программиста на вижуал бейсике вопросами формата конфига и его местонахождения. Реестр непрерывно захламляется, но это не сразу становится заметно и не отталкивает пользователей от системы, которые в это время осторожно двигают мышь одним пальцем и разглядывают иконки на раб. столе, как баран новые ворота. Ну а раз в полгода винду переустанавливать не так уж сложно :)
ну скажем так. если требуется для каких-то целей строить по логам статистику - предложенный подход вполне оправдан. если у тебя 50 гигов жатых гзипом логов, делать по ним grep несколько накладно. однако такие задачи возникают редко. то что они пишут о парсерах - тоже правда. вот давеча добавил поле в логформат, пришлось пепенастраивать awstats (тоже описывать там новый логфорат). однако хранение логов в структурированном бинарном формате во многих случаях действительно неудобно. хотя есть дебаг логи где в лог пишется объект в json или что-нибудь такое, грепать по ним нереально.
> ну скажем так. если требуется для каких-то целей строить по логам статистику
> - предложенный подход вполне оправдан. если у тебя 50 гигов жатых
> гзипом логов, делать по ним grep несколько накладно. однако такие задачи
> возникают редко. то что они пишут о парсерах - тоже правда.
> вот давеча добавил поле в логформат, пришлось пепенастраивать awstats (тоже описывать
> там новый логфорат). однако хранение логов в структурированном бинарном формате во
> многих случаях действительно неудобно. хотя есть дебаг логи где в лог
> пишется объект в json или что-нибудь такое, грепать по ним нереально.Если нужна статистика, то и сейчас вообще не проблема, например через пайп или по сети из сислога получать всё, парсить и складывать то, что нужно в базу. А то что пишут о парсерах - имхо чушь, при добавлении нового поля не так уж сложно поправить парсер, это обычная работа системного инженера/админа - не понимаю, в чём проблема то?
какую проблему решает ламберджек? помоему надуманную, которая не существует за пределами сознаний поттерингов... зато проблемы, которые возникнут при попытке эту надуманную проблему "решать", станут вполне реальными. Хочется верить, что по крайней мере в Debian эти инициативы будут расценены адекватно, даже если в итоге красная шляпа подпишется на эти сомнительные инновации и реализует это.
Вообще следующим логичным шагом для красной шапки будет перенести в бинарный вид и конфиги, редактировать их через отдельное новое апи сторонними тулзами, привет редакторы реестра :) Останется выпилить шеллы, тк они, внезапно, станут особо больше не нужны никому. И после этого редхет с убунтой станут сильно напоминать то, что хотели забыть как страшный сон, люди мигрировавшие на лиункс с самой популярной ОС. История имеет свойство повторять себя, потому что никто на ней не учится, "10000 ли за спиной, а грабли всё те же" (с).
Похоже кто то хочет подзаработать на неграмотности админов.
Что ж, флаг им в руки. Им тоже денежки зарабатывать надо.
Линуксоиды воистину неизлечимы :)
Вместо того что бы "механизировать" ручной труд они предлагают разработать очередного "дровосека".Для несведущих;
у Финов есть поговорка, дословно не помню, но суть примерно следующая:
- мы используем Тимберджек, а Русские - Лумберджек (по фински звучит даже без перевода вполне унизительно).Для справки:
тимберджек: http://www.youtube.com/watch?v=QoC3tBwR0eA&feature=related
лумберджек: http://www.youtube.com/watch?v=xnpKzOvxaJI&feature=player_de...ЗЫ:
модераторам: сообщение написано на стенке химическим карандашом. смывать, закрашивать - бесполезно.
> модераторам: сообщение написано на стенке химическим карандашом.Некоторые из нас понимают в красителях => способны без смывания и закрашивания развалить сопряжённые связи ;)
Что сказать-то хотели?
>> модераторам: сообщение написано на стенке химическим карандашом.
> Некоторые из нас понимают в красителях => способны без смывания и закрашивания
> развалить сопряжённые связи ;)
> Что сказать-то хотели?Если сильно постараются, то данный проект может вырасти и вместо http://www.youtube.com/watch?v=xnpKzOvxaJI
получат вполне успешный результат типа http://www.youtube.com/watch?v=zFGva6ZS4fU&feature=related
> Если сильно постараются, то данный проект может вырасти и вместоЭто вообще какой-то виндузятник с перочинным топориком; непонятно, кто лесорубом назвал.
> получат вполне успешный результат типа
...способного отхватить ноги сразу двоим, если замешкаются?..
Так ведь не все на машине в булочную за углом ездють, есть и вменяемые люди. Технологии сейчас и так страдают недостатком человекопознаваемости в разумные сроки и как следствие -- диагностируемости.
PS: если что, у нас свою подсистему распределённого журналирования писали. И я ни разу не хочу столько сущностей у себя на ноутбуке, даже близко. На несколько тысяч хостов они оправданы, на один -- никак.