The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Представлен проект Lumberjack, нацеленный на модернизацию системы ведения журналов Linux

02.03.2012 14:02

Две недели назад компания Red Hat собрала в своем офисе разработчиков популярных систем ведения логов, чтобы обсудить перспективы системы журналирования Linux и возможности последующего совершенствования уже устаревшей системы syslog. В результате обсуждения, в котором приняли участие Steve Gibbs (auditd), Lennart Poettering (systemd, journald), Rainer Gerhards (rsyslog), William Heinbockel (CEE, Mitre), а также несколько сотрудников компании Red Hat, родился проект Lumberjack, в рамках которого будет вестись работа по совершенствованию компонентов Linux-дистрибутивов, так или иначе связанных с журналированием системных событий.

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

Так родился проект Lumberjack, основанный на концепциях и спецификациях, описанных в стандарте CEE, определяющем способ описания диагностических сообщений, метод их записи в журнал и интерфейс обмена с другими приложениями.

Основные задачи проекта:

  • Интеграция уже существующих структурированных форматов сообщений (например, auditd);
  • Создание механизма передачи структурированных сообщений журнальным сервисам (для этого планируется задействовать наработки проекта ELAPI, в рамках которого идет работа над универсальным журнальным API;
  • Доработка существующих журнальных сервисов с целью их совместимости со структурированными данными (фактически уже решенная задача);
  • Создание механизма, который бы позволил эффективно хранить структурированные данные и отдавать их по запросу;
  • Разработка схемы именования данных, совместимой с CEE;

    В данный момент проект находится в стадии планирования. В будущем наработки проекта будут размещены в git-репозитории fedorahosted.org. Для обсуждения деталей разработки создана дискуссионная рассылка.



  1. Главная ссылка к новости (http://bazsi.blogs.balabit.com...)
  2. OpenNews: Релиз systemd v38 c поддержкой Journal, замены системе syslog
  3. OpenNews: Разработчики systemd представили Journal, замену системе syslog
Автор новости: Evgeny Zobnin
Тип: К сведению
Короткая ссылка: https://opennet.ru/33246-syslog
Ключевые слова: syslog, log, event, syslog-ng, journald, rsyslog
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (179) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 14:25, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Судя по неоднократному упоминанию "структурированных данных", основной формат хранения логов будет бинарным.
    Ну наконец-то и линукс дошел до того, что в юниксе сделано уже двадцать лет назад.
     
     
  • 2.6, Аноним (-), 14:34, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +7 +/
    А чем бинарный формат принципиально лучше текстового? Индексы и по текстовым строкам прекрасно делаются, сами журнальные записи тоже текстовые
     
     
  • 3.18, Аноним (-), 14:53, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +8 +/
    > А чем бинарный формат принципиально лучше текстового? Индексы и по текстовым строкам
    > прекрасно делаются, сами журнальные записи тоже текстовые

    Основных причины две:
    1. Недостаточная компактность. Особенно неприятно отсутствие возможности дедупликации повторяющихся данных (например, имя хоста). Соответственно, это сильно замедляет хранение, поиск и обработку. В частности, именно поэтому наиболее нагруженные лог-системы (в частности, юниксовый аудит) работают исключительно с бинарными логами.
    2. Неструктурированность. Опять же сильно затрудняет обработку и поиск данных. Кроме того, порождает кучу проблем совместимости - добавление нового поля в структуру не ломает существующие анализаторы логов, в отличие от изменения форматной строки.

     
     
  • 4.30, anonymous (??), 15:05, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > Основных причины две:
    > 1. Недостаточная компактность. Особенно неприятно отсутствие возможности дедупликации
    > повторяющихся данных (например, имя хоста). Соответственно, это сильно замедляет хранение,
    > поиск и обработку. В частности, именно поэтому наиболее нагруженные лог-системы (в
    > частности, юниксовый аудит) работают исключительно с бинарными логами.

    Это попытка переизобрести gzip?


    > 2. Неструктурированность. Опять же сильно затрудняет обработку и поиск данных. Кроме того,
    > порождает кучу проблем совместимости - добавление нового поля в структуру не
    > ломает существующие анализаторы логов, в отличие от изменения форматной строки.

    Феерический бред.

     
     
  • 5.37, Аноним (-), 15:11, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Это попытка переизобрести gzip?

    В какой-то степени. Но только такой gzip, который позволяет работать сразу со сжатым файлом, и при этом не замедляет доступ, а ускоряет его (за счет индекса).

    > Феерический бред.

    Да неужели? Вот, например, в приводимых вами ссылках автор rsyslog жалуется, что поддержка тайм-зоны в его rsyslog давно есть, но включить ее нельзя, потому что она сломает все существующие анализаторы логов.
    Со структурированными данными при стабильном API такой проблемы нет в принципе.

     
     
  • 6.46, anonymous (??), 15:22, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • –5 +/
    >> Это попытка переизобрести gzip?
    > В какой-то степени. Но только такой gzip, который позволяет работать сразу со
    > сжатым файлом, и при этом не замедляет доступ, а ускоряет его
    > (за счет индекса).

    Кто мешает пожать и проиндексировать текстовый файл?

    > Да неужели? Вот, например, в приводимых вами ссылках автор rsyslog жалуется, что
    > поддержка тайм-зоны в его rsyslog давно есть, но включить ее нельзя,
    > потому что она сломает все существующие анализаторы логов.
    > Со структурированными данными при стабильном API такой проблемы нет в принципе.

    Где ты увидел стабильный API, если количество полей и их содержимое меняется? Всё равно переписывать придётся. Впрочем, пока даже формат этого бинаря не документирован.


     
     
  • 7.50, Аноним (-), 15:45, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Где ты увидел стабильный API, если количество полей и их содержимое меняется?

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

     
     
  • 8.58, Аноним (-), 16:16, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Ага, щаз Ты представление-то имеешь, как парсеры работают ... текст свёрнут, показать
     
     
  • 9.68, Аноним (-), 16:37, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет Речь шла о структурированном логе со специальным API для работы с ним Ес... текст свёрнут, показать
     
  • 9.69, Wolfis (?), 16:38, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Структурированные данные, индексируемые данные, множества данных Если кто не п... текст свёрнут, показать
     
  • 9.102, Аноним (-), 19:24, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну допустим я имею, ламерок Для тех кто в танке что сломается в SQL при добавл... текст свёрнут, показать
     
     
  • 10.107, XoRe (ok), 22:07, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    В этой теме про него лучше не вспоминать А то, знаете как помянешь черта и о... текст свёрнут, показать
     
     
  • 11.136, Аноним (-), 04:02, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    OSMщики с XML уже наелись, как стали портянги в 250 гигз, которые в бинарном фор... текст свёрнут, показать
     
  • 10.148, Имя и код (?), 06:07, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это типа каждый раз альтер тейбл, который, конечно же, вовсе не накладная операц... текст свёрнут, показать
     
  • 10.233, arisu (ok), 04:43, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    а что сломается в парзере, например, 171 по строке на запись, поля поделены од... текст свёрнут, показать
     
  • 9.232, arisu (ok), 04:40, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    хорошо работают, если писались руками и изначально формат нормальный 171 перв... текст свёрнут, показать
     
  • 7.76, Аноним (-), 17:20, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Кто мешает пожать и проиндексировать текстовый файл?

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

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

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

     
     
  • 8.234, arisu (ok), 04:44, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    чем это отличается от 171 каши 187 , не подскажешь ... текст свёрнут, показать
     
  • 6.115, anonimous (?), 00:14, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Но только такой gzip, который позволяет работать сразу со сжатым файлом, и при этом не замедляет доступ, а ускоряет его (за счет индекса).

    А индекс образуется сам собой, причём совершенно задаром.

     
     
  • 7.137, Аноним (-), 04:04, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А индекс образуется сам собой, причём совершенно задаром.

    А в случае текстаря его еще и хранить надо где-то сильно сбоку...

     
  • 5.86, Аноним (-), 17:40, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Это попытка переизобрести gzip?

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

     
     
  • 6.109, XoRe (ok), 22:11, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >> Это попытка переизобрести gzip?
    > Gzip не позволяет доступ на ходу. А 20 гиговую портянку сам, пожалуйста,
    > декомпрессуй своим гзипом. И да, если уж о скорости, тесктовые логи
    > зачастую отключают т.к. на серверах все начинает упираться именно в запись
    > логов.

    Против 20гиговых логов есть ротация.
    Кто не настроил, тот - ...)
    На средненагруженном сервере в логи ничего не упирается.
    А на высоконагруженном... там уже другие способы работы с логами.
    Например, отправлять на специальный сервер логов, не храня у себя.
    Кто не настроил - тот ...)

     
     
  • 7.124, Аноним (-), 03:12, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Угу, что однако не отменяет факта что логи могут быть большими даже с ротацией ... большой текст свёрнут, показать
     
     
  • 8.129, Michael Shigorin (ok), 03:38, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Пожалуйста, давайте об устрицах -- емши Локальное хранение логов нередко весьма... текст свёрнут, показать
     
     
  • 9.138, Аноним (-), 04:06, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А чем проблемы с синхронной записью там - лучше чем с синхронной записью где-то ... текст свёрнут, показать
     
     
  • 10.158, anonimous (?), 07:57, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Выделенный коллектор логов обслуживает исключительно логи, а не целевой сервис ... текст свёрнут, показать
     
     
  • 11.163, zzz (??), 12:34, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Целевой сервис не обязан интенсивно писать на диск, если что Более того, не у в... текст свёрнут, показать
     
     
  • 12.189, Michael Shigorin (ok), 19:24, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    fsync очень даже бьёт и по чтению Если же сервис со всем нужным помещается в... текст свёрнут, показать
     
     
  • 13.218, Аноним (-), 17:35, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Может, но насколько именно - весьма зависит от А еще можно логи хранить на отде... большой текст свёрнут, показать
     
     
  • 14.220, Michael Shigorin (ok), 20:47, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Дядьку, я Вам это по куче систем с самым разным стораджем говорю Это и упомянул... большой текст свёрнут, показать
     
  • 10.187, Michael Shigorin (ok), 19:01, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Тем, что подсистема I O может быть к ним лучше готова Даже локально отделить ак... большой текст свёрнут, показать
     
     
  • 11.219, Аноним (-), 17:45, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Сервер отгружающий бочками файло и не готовый к интенсивному I O довольно странн... большой текст свёрнут, показать
     
     
  • 12.221, Michael Shigorin (ok), 20:48, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    см тж 220 Так у отгружающего может быть заточка под отгрузку -- приличный r... большой текст свёрнут, показать
     
  • 8.147, XoRe (ok), 05:59, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +5 +/
    могут быть - это предположение факт - это бл , вот это логи отожрали А с ф... большой текст свёрнут, показать
     
     
  • 9.157, zzz (??), 07:54, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Элементарно - минимальная атака на сервак где они в крейсерском режиме нормальны... большой текст свёрнут, показать
     
     
  • 10.174, XoRe (ok), 14:18, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Уважаемый, вы бы посмотрели, на какие тезисы я отвечаю Там как раз хотели за су... большой текст свёрнут, показать
     
     
  • 11.192, Аноним (-), 00:59, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Во первых, заранее сложно сказать за какой интервал потребуются логи Во вторых,... большой текст свёрнут, показать
     
  • 10.196, vi (?), 02:08, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Уважаемый, вы хотя бы раз logcheck настраивали ... текст свёрнут, показать
     
  • 8.151, Имя и код (?), 06:29, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну ётыдь, ну шо за вьюные разжижения мозгофекалий Воопще-то построение скалейбл... большой текст свёрнут, показать
     
     
  • 9.168, Аноним (-), 13:25, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Я тоже не понял Поэтому попробуйте изложить мысль внятно и без задействования ж... текст свёрнут, показать
     
     
  • 10.200, Имя и код (?), 03:33, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну что за дети пошли Какие понты, исключительно профессиональная терминология... большой текст свёрнут, показать
     
     
  • 11.235, arisu (ok), 04:50, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    это не 171 профессиональная терминология 187 , это кулхацкерский мунспик был ... текст свёрнут, показать
     
  • 6.111, nobody (??), 22:19, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +9 +/
    >> Это попытка переизобрести gzip?
    > Gzip не позволяет доступ на ходу. А 20 гиговую портянку сам, пожалуйста,
    > декомпрессуй своим гзипом. И да, если уж о скорости, тесктовые логи
    > зачастую отключают т.к. на серверах все начинает упираться именно в запись
    > логов.

    Логи в продакшене отключают только идиоты. Вменяемые админы, если дисковое и/о из-за логов становится проблемой, пишут логи сразу на удаленный сервер логов, потому что сервис без логирования его работы никакому траблшутингу не поддаётся в принципе, а вменяемые админы не любят беспомощно разводить руками, когда случается внезапный service outage, им больше нравится возможность узнать из лога, что просходило с сервисом непосредственно перед отказом.

    Кстати поэтому, вменяемых админов сабж врядли обрадует, тк если это будет бд в каком-то виде, то никогда нельзя быть уверенным, что сможешь быстро прогрепать логи, чтобы быстро найти причину и восстановить работоспособность сервиса в кратчайшие сроки. Зато точно понятно, что все написанные годами скрипты и парсеры идут лесом. А меж тем, эта новая бд может (а значит будет) крешиться, и тд - это дополнительный point of failure, усложнение на ровном месте, которое никаких серъезных преимуществ не даёт, зато имеет вполне очевидные недостатки. В общем, это печально всё... что так много, судя по выкрикам, ленартов поттерингов вокруг, для которых KISS и бритва оккама - пустые знаки.

     
  • 6.116, anonimous (?), 00:18, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > ... И да, если уж о скорости, тесктовые логи
    > зачастую отключают т.к. на серверах все начинает упираться именно в запись
    > логов.

    Мне пытаются впарить мысль, что DB (!!!) будет быстрее, чем plain-file на одном оборудовании. Или я что-то пропустил?

     
     
  • 7.122, VoDA (ok), 02:58, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> ... И да, если уж о скорости, тесктовые логи
    >> зачастую отключают т.к. на серверах все начинает упираться именно в запись
    >> логов.
    > Мне пытаются впарить мысль, что DB (!!!) будет быстрее, чем plain-file на
    > одном оборудовании. Или я что-то пропустил?

    работа с БД в большинстве случаев быстрее plain-file. начиная с того, что нормализация уменьшает размер в 10-30 раз и продолжая индексами по любым требуемым полям. plain-file хорошо пока не нужно проводить анализ на больших объемах.


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

  • 9.162, zzz (??), 12:28, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Значит формат должен допускать лобовой и быстрый инсерт максимально компактных з... текст свёрнут, показать
     
     
  • 10.188, Michael Shigorin (ok), 19:20, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    То есть атрибута навроде src_ip в блобгах Вы не предполагаете 8- Упаковка на... текст свёрнут, показать
     
     
  • 11.193, Аноним (-), 01:25, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Предполагаю, но полагаю что возможность сокращенно референсить повторную информа... текст свёрнут, показать
     
     
  • 12.195, Michael Shigorin (ok), 01:57, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    1 каков критерий повторности 2 референсить можно и в текстовом, вопрос в цене... текст свёрнут, показать
     
  • 10.201, Имя и код (?), 03:38, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Угу С блэкджеком и шлюхами Да пофигу, ибо не уточнять, но идентифицировать ... текст свёрнут, показать
     
  • 9.183, VoDA (ok), 15:06, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А кто вас сказал чтоб это будет реляционная СУБД шарашить с спец формате расс... большой текст свёрнут, показать
     
     
  • 10.203, Имя и код (?), 03:49, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы Вы описываете тютелька в тютельку именно такую DBMS и потом удивлённо развод... большой текст свёрнут, показать
     
     
  • 11.227, VoDA (ok), 00:45, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Однако, как указывает К Дейт, нормализация в точности и является теми принципам... большой текст свёрнут, показать
     
     
  • 12.236, arisu (ok), 04:58, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    йопт на поиск 171 повторяющихся элементов 187 в словарях время уходит, нет ... большой текст свёрнут, показать
     
  • 7.126, Аноним (-), 03:16, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне пытаются впарить мысль, что DB (!!!) будет быстрее, чем plain-file на
    > одном оборудовании. Или я что-то пропустил?

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

    Так, похожий пример: жил был OSM. Хранил карту в XML. Когда карта мира стала весить в XML 250 гигов так что работать с ней стало невозможно, чуваки очень быстро осознали свои ошибки и сделали эффективный бинарный формат где все данные представлены настолько компактно насколько это можно сделать. И оно весит 14 гигз. Небольшая такая разница, всего примерно в 20 раз...

     
     
  • 8.140, Имя и код (?), 04:57, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну иоптыдь, Опенстриты, они читают на порядки чаще, нежели пишут ... текст свёрнут, показать
     
     
  • 9.152, Аноним (-), 06:31, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Пишут его тоже часто и много И работать с 250Г чушкой в XML попросту не приколь... текст свёрнут, показать
     
     
  • 10.202, Имя и код (?), 03:39, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Повторюсь на порядки меньше ... текст свёрнут, показать
     
  • 8.237, arisu (ok), 05:00, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    ну и какой идиот изначально додумался базу с необходимым по дизайну random acces... текст свёрнут, показать
     
  • 4.45, gaga (ok), 15:21, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Дедупликация подразумевает сложную структуру хранения, подобную реляционной или ... большой текст свёрнут, показать
     
     
  • 5.77, Аноним (-), 17:23, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Дедупликация подразумевает сложную структуру хранения, подобную реляционной или какой-нибудь
    > другой СУБД. Это усложняет демон не в разы, а на несколько
    > порядков, и замедляет его на столько же. А лог должен быть
    > максимально простым и быстрым.

    То же самое можно сказать про любую SQL-совместимую СУБД. Но почему-то среди них популярны мускул, постргрес и скулайт, причем их бакэнды почему-то работают с бинарными форматами :)

    > JSON и ему подобные форматы решают эту проблему.

    Но проблему объема они не решают. Поэтому их рациональнее использовать на следующем этапе обработки - формирование отчетов и выборок по БД логов.

     
     
  • 6.238, arisu (ok), 05:02, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    все твои улыбки в основном от того, что ты считаешь: one size fits all. и волшебные слова «база данных» понимаешь очень однобоко.
     
  • 5.80, Аноним (-), 17:29, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Угу, аж возможность референса в сторону - а вот это уже было, брать вон там вот... большой текст свёрнут, показать
     
  • 3.59, Аноним (-), 16:17, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > прекрасно делаются, сами журнальные записи тоже текстовые

    Анализировать быстро и на автомате и ловить потенциально интересные эвенты довольно геморно. В случае структурированности можно быстро и просто фильтрануть, например. Или отсортировать по критерию. В случае текста надо какие-то костыли. Грепать или индексить всю портянку на 20 гигз можно и задолбаться. А когда она уже в удобном виде - почему бы и нет?

     
     
  • 4.78, Аноним (-), 17:25, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Анализировать быстро и на автомате и ловить потенциально интересные эвенты довольно геморно.
    > В случае структурированности можно быстро и просто фильтрануть, например. Или отсортировать
    > по критерию. В случае текста надо какие-то костыли. Грепать или индексить
    > всю портянку на 20 гигз можно и задолбаться. А когда она
    > уже в удобном виде - почему бы и нет?

    Заметим, что идея грепа лога сама по себе порочна. Добавление в строку нового поля, или изменение формулировки сообщения ломает работу всех хитроумных regexpов.

     
     
  • 5.83, Аноним (-), 17:34, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Заметим, что идея грепа лога сама по себе порочна.

    Я бы сказал 50/50, потому что гибкость - хорошая, да. И позволяет завернуть очень хитрый критерий для аналитики, которого вот так сходу может и не быть. С другой стороны, грепать 20-гиговую портянку на каждую оказию - удовольствие ниже среднего.

    > Добавление в строку нового поля, или изменение формулировки сообщения ломает
    > работу всех хитроумных regexpов.

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

     
     
  • 6.87, Аноним (-), 17:41, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Я бы сказал 50/50, потому что гибкость - хорошая, да. И позволяет
    > завернуть очень хитрый критерий для аналитики, которого вот так сходу может
    > и не быть.

    Хм. Вы когда-нибудь с SQL работали? Скажу по секрету: там возможностей для хитрой аналитики куда больше, чем в простом грепе =)
    Логично, что для работы со структурированными данными, будет использоваться язык структурированных запросов (a.k.a. SQL), или некий его аналог.

     
     
  • 7.125, Anonymouse (?), 03:13, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Хм. Вы когда-нибудь с SQL работали? Скажу по секрету: там возможностей для хитрой аналитики куда больше, чем в простом грепе =)

    Practical Extraction and Report Language. На SQL-е - умахаешься.
    Впрочем поЦерингов это не остановит :(

     
  • 7.130, Аноним (-), 03:50, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Хм. Вы когда-нибудь с SQL работали? Скажу по секрету: там возможностей для
    > хитрой аналитики куда больше, чем в простом грепе =)

    1) Я не считаю что для анализа логов мне надо бросить все и стать DBA
    2) Я не считаю что для анализа логов мне надо бросить все и стать SQL programmer.
    3) Базы SQL в общем случае не отличаются скоростью и компактностью.
    4) Оно слишком много всего умеет: перспектива словить SQL injection в системе логгинга - здорово придумано. А что, пусть хакер и ломится через систему логгинга сразу.
    5) В общем случае SQL базы не дизайнились быть устойчивыми от хакинга, удаления записей задним числом без простого обнаружения этого факта, etc.

     
  • 7.213, cosmonaut (ok), 12:09, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Скажу по секрету: там возможностей для хитрой аналитики куда больше, чем в простом грепе =)

    Т.е. вы хотите сказать, что DSL, коим является SQL имеет больше возможностей, чем тьюринг-полный язык (bash+grep+tools+sed+awk)?
    А где такая трава продается? :)

     
  • 5.99, Аноним (-), 18:38, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Заметим, что идея грепа лога сама по себе порочна. Добавление в строку
    > нового поля, или изменение формулировки сообщения ломает работу всех хитроумных regexpов.

    Да, вспоминается, как аккуратненько добавил разок дополнительное поле в конец лог-строки апача. И все, вебалайзер тут же загнулся.

     
  • 4.117, anonimous (?), 00:26, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Анализировать быстро и на автомате и ловить потенциально интересные эвенты довольно геморно.
    > В случае структурированности можно быстро и просто фильтрануть, например. Или отсортировать
    > по критерию. В случае текста надо какие-то костыли. Грепать или индексить
    > всю портянку на 20 гигз можно и задолбаться. А когда она
    > уже в удобном виде - почему бы и нет?

    Узкое место --- не в чтении/парсинге/поиске, в записи. (поиск --- значительно более редкая и менее требовательная к скорости получения результата операция, по сравнению с записью).

     
  • 4.142, Имя и код (?), 05:16, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> прекрасно делаются, сами журнальные записи тоже текстовые
    > Анализировать быстро и на автомате и ловить потенциально интересные эвенты довольно геморно.
    > В случае структурированности можно быстро и просто фильтрануть, например. Или отсортировать
    > по критерию. В случае текста надо какие-то костыли. Грепать или индексить
    > всю портянку на 20 гигз можно и задолбаться. А когда она
    > уже в удобном виде - почему бы и нет?

    Не-а, бинарь в принципе не удобен. Эт раз.
    Для первичного анализа берутся не сами логи, но уже очищенные от инфошума, эт два.
    И тока ежели оно действительно дальше нуна (отрицательная вероятность), берётся часть простыни, локализированная по.

     
     
  • 5.166, zzz (??), 13:18, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Бинарь в принципе ничем не отличается от текстаря Поскольку вы не читаете секто... большой текст свёрнут, показать
     
     
  • 6.204, Имя и код (?), 03:56, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Не текстовый формат весьма и весьма не удобен Малоюзабелен Никто вотпрямща и ... большой текст свёрнут, показать
     
  • 2.44, Аноним (-), 15:18, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Итак, давайте обдумаем Допустим что syslog действительно устарела устаревание ... большой текст свёрнут, показать
     
     
  • 3.48, anonymous (??), 15:30, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Слишком много букв. Но что делать, если утилита посчитает бинарный лог испорченным и пошлёт куда подальше? Представляется ли возможным что-то быстро предпринять на коленке в таком вот экстренном случае?
     
     
  • 4.51, Аноним (-), 15:47, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Снова на второстепенные вещи отвлекаетесь:

    1. Много букв потому то в тексте подробности (внезапно?).
    2. Утилита утилите рознь (тут надо смотреть на реализацию утилиты и, особенно, на формат логов (бинарность логов не обязательно подразумевает их архивацию в сполшной solid-архив; можно сжимать на уровне сообщения/строк/записи и т.д.) ).

     
  • 4.53, Аноним (-), 15:52, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это важный вопрос, но не первой важности, т.к. он не определяет архитектуру и возможности. А разговоры именно об этом
     
     
  • 5.57, Аноним (-), 16:01, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Об этом и речь была. Цитирую: "разница между бинарными и текстовымы форматами хранения не несет сколько-нибудь принципиальной разницы". Ключевое здесь: "не несет принципиальной разницы". Просто часть читающих опеннета не осиливает текст моего сообщения (да куда там до понимания сути сообщения когда часть тут новости (пересказ в кратком изложении) не осиливает даже на половину).
     
     
  • 6.90, Аноним (-), 17:46, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Об этом и речь была. Цитирую: "разница между бинарными и текстовымы форматами
    > хранения не несет сколько-нибудь принципиальной разницы". Ключевое здесь: "не несет принципиальной
    > разницы". Просто часть читающих опеннета не осиливает текст моего сообщения (да
    > куда там до понимания сути сообщения когда часть тут новости (пересказ
    > в кратком изложении) не осиливает даже на половину).

    Разница между текстовым и бинарным форматом - логическое следствие разницы между структурированными и неструктурированными данными.
    Нет, конечно, можно и текстовые данные структурировать (JSON там, XML), но не на таких объемах, как в случае с логами.

     
     
  • 7.100, Аноним (-), 19:17, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Разница между текстовым и бинарным форматом - логическое следствие разницы между структурированными и неструктурированными данными.

    Вы не врубаетесь в самую суть: формат хранения логов это второстепенные вещи и нет никакой проблемы перегнать с одного формата в другой.

    >Нет, конечно, можно и текстовые данные структурировать (JSON там, XML), но не на таких объемах, как в случае с логами.

    Проблема сжать существующие логи? Или проблема навесить структуризацию на текущий способ?

     
     
  • 8.119, Deffic (?), 01:59, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Поддреживаю Собершенно непонятно вокруг чего проблема, если нужны структурирова... большой текст свёрнут, показать
     
  • 8.123, VoDA (ok), 03:09, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Проблема сделать логи структурированными Решение этой задачи попутно решит ряд ... большой текст свёрнут, показать
     
  • 8.153, Имя и код (?), 06:44, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Она УЖЕ структурирована, в эрэфсях это чётко прописано это свежий The syslog ... большой текст свёрнут, показать
     
     
  • 9.159, Аноним (-), 10:23, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ему раскидали то что он уткнулся лишь в поверхностные, второстепенные вещи, но о... текст свёрнут, показать
     
     
  • 10.164, Имя и код (?), 12:40, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    И самое забавное, что своими действиями усугубляет именно в этом направлении ... текст свёрнут, показать
     
  • 9.170, Аноним (-), 13:37, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну так перцы тоже решили реализовать стандарт А то что он бинарный - ну и болт ... текст свёрнут, показать
     
     
  • 10.190, Michael Shigorin (ok), 19:30, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Вы просто передёргиваете gzip, cat, EDITOR -- универсальные, в отличие от ... текст свёрнут, показать
     
     
  • 11.194, Аноним (-), 01:34, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А что мешает сделать прозрачную развертку этого формата в текст как gzip это дел... текст свёрнут, показать
     
     
  • 12.197, Michael Shigorin (ok), 02:08, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Вот Вы как понимаю в 193 описали сворачивание по IP Попробуйте набросать ст... большой текст свёрнут, показать
     
     
  • 13.228, VoDA (ok), 00:54, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Вы правы - это тайный набор знаний Его специально выдел... большой текст свёрнут, показать
     
     
  • 14.230, Michael Shigorin (ok), 01:17, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Я и подводил пишущего к мысли, что мы, скорее всего, попадаем на мини-DB и мини-... текст свёрнут, показать
     
  • 9.185, VoDA (ok), 15:23, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Сам MSG не структурирован Как по вашему задаются обязательные и дополнительные ... большой текст свёрнут, показать
     
     
  • 10.205, Имя и код (?), 04:03, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    От ёптыдь, попробую объяснить по аналогии Вы про тисипиайпи слыхивали Про ... текст свёрнут, показать
     
     
  • 11.229, VoDA (ok), 01:02, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Аналогия интересна, но не верна Изначальный постулат, который я развиваю это не... большой текст свёрнут, показать
     
  • 4.131, Аноним (-), 03:52, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Слишком много букв. Но что делать, если утилита посчитает бинарный лог испорченным

    Тогда с ним делать то же что и с испорченным текстовым логом. Открыли вы текстарь а там бред. Ну и чего?

     
  • 3.82, Аноним (-), 17:34, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Это я к тому что прикрутить к syslog хранение в бинарном представлении - это простое дело одного коммита (нужны всего лишь две функции кодирования и декодирования, которые можно выбросить в разделяемую библиотеку и позже предоставить API для возможности написания сторонних утилит).

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

    > Вывод: текст вашего сообщения оказался низкокачественным де!!мом (вы со средне-серым образованием или обычный гуманитарии?)

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

     
     
  • 4.160, Аноним (-), 10:31, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >А вы подумали о том, что старый API взаимодействия приложений с syslog не предназначен для передачи структурированных данных, и даже если ввести в современный rsyslog бинарный формат хранения, существенных бонусов это не даст.

    Не вижу никаких проблем чтобы расширить API. Это дело одного коммита.

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

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

     
     
  • 5.240, arisu (ok), 05:09, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Не вижу никаких проблем чтобы расширить API. Это дело одного коммита.

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

     
  • 3.93, Аноним (-), 18:25, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Вывод: текст вашего сообщения оказался низкокачественным де!!мом (вы со средне-серым образованием или обычный гуманитарии?)

    В чем-то вы правы =)
    В своем посте я немножечко пожертвовал логичностью ради провокационности.
    Действительно, ключевым моментом является введение API для работы со _структурированными_ данным. Бинарный формат лога - это лишь внешний атрибут, который сам по себе существенных бонусов не дает.
    Просто меня забавляет реакция на это словосочетание ("бинарные логи") некоторых местных петушков, знакомых с юниксом исключительно понаслышке, но при этом обожающих рассказывать, что такое юниксвей, и как всем правильно жить =)

     
     
  • 4.121, Куяврик (?), 02:40, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А мне вот не нравится идея бинарных логов. И бинарных конфигов. Просто - не нравится. Независимо от API. И совершенно неясно что в этом забавного. А вот забавно как раз наоборот - ваше отношение.
    "Бинарный формат лога - это лишь внешний атрибут, который сам по себе существенных бонусов не дает."
    "Просто меня забавляет реакция на это словосочетание ("бинарные логи")"
    Расщепление сознания детектед?
     
  • 4.214, cosmonaut (ok), 12:37, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Просто меня забавляет реакция на это словосочетание ("бинарные логи") некоторых местных
    > петушков, знакомых с юниксом исключительно понаслышке, но при этом обожающих рассказывать,
    > что такое юниксвей, и как всем правильно жить =)

    Вот, если бы вы знали, что такое cat,grep,sed и другие умные слова для работы с текстовым форматом даных, то знали бы, что при парсинге глазами таких вот бинарных логов (что оч часто бывает полезным, представте) нужно будет либо конвертировать их перед этим в текстовые, либо писать аналоги всего выше сказанного (и не только), что, собственно, смахивает на промышленное велосипедостроение.
    ...хотя, да, это же дело одного коммита...

     
  • 3.143, Имя и код (?), 05:30, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вывод: текст вашего сообщения оказался низкокачественным де!!мом (вы со средне-серым образованием
    > или обычный гуманитарии?)

    На 100% выпускник какого-нибудь "ВУЗа" типа Мэждународного Университета Соломона, фак а-ля "экономическая кибернетика", сп-ть "визуализация табличных данных средствами MS Exhell".
    Бакалавр околокомпьютерных наук со стажем.

     
     
  • 4.171, Аноним (-), 13:38, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Бакалавр околокомпьютерных наук со стажем.

    Будем знакомы. И как оно вам, бакалаврам? :)

     
     
  • 5.206, Имя и код (?), 04:04, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Бакалавр околокомпьютерных наук со стажем.
    > Будем знакомы. И как оно вам, бакалаврам? :)

    Нам такие как Вы бакалавры забавны :)))

     
  • 2.67, R (?), 16:34, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > Ну наконец-то и линукс дошел до того, что в юниксе сделано уже
    > двадцать лет назад.

    Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?.

     
     
  • 3.84, Аноним (-), 17:36, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые
    > логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?.

    А еще в UNIX auditd (который гораздо важнее syslog), и он пишет бинарные логи.

     
     
  • 4.154, Имя и код (?), 07:06, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые
    >> логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?.
    > А еще в UNIX auditd (который гораздо важнее syslog), и он пишет
    > бинарные логи.

    А мексиканского кактуса бритого он важнее. аудитди не расскажет мне кто, аутентифицированный керберосом и авторизированный ЛДАПом, получил коннект через сквид.

    И эта, советую поинтересовадзе сколько триггеров/рулз по дефолту в этом ди включено, почему это мизерная часть и шо будет, если этих цацок включить много.

     
     
  • 5.169, Аноним (-), 13:35, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А мексиканского кактуса бритого он важнее. аудитди не расскажет мне кто, аутентифицированный
    > керберосом и авторизированный ЛДАПом, получил коннект через сквид.

    А вот в предлагаемой вон теми парнями схеме - чуть более другой сервис пойдет и расскажет кто и какого хрена. В более-менее унифицированном формате.

     
     
  • 6.207, Имя и код (?), 04:06, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> А мексиканского кактуса бритого он важнее. аудитди не расскажет мне кто, аутентифицированный
    >> керберосом и авторизированный ЛДАПом, получил коннект через сквид.
    > А вот в предлагаемой вон теми парнями схеме - чуть более другой
    > сервис пойдет и расскажет кто и какого хрена. В более-менее унифицированном
    > формате.

    Так вот в том-то и дело, шо нет! Просто из-за дурацкого формата будут оверхед и неудобства. Всё.

     
  • 3.95, Аноним (-), 18:30, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые
    > логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?.

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

     
     
  • 4.215, anon9000 (?), 13:48, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    имхо, он про солярку)))
     
  • 3.144, Имя и код (?), 05:37, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ну наконец-то и линукс дошел до того, что в юниксе сделано уже
    >> двадцать лет назад.

    rfc3164 достаточно свежая хреннь.

    > Я так понимаю - очепятка. В UNIX syslog, и он пишет текстовые
    > логи. Я так понимаю, это об ОднойОченьИзвестнойОСи ОднойОченьИзвестнойФирмы?.

    Ну... Это неуспешно скрыто за зарослями бинарного формата хранения логофф. :)

     
     
  • 4.172, Аноним (-), 13:40, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну... Это неуспешно скрыто за зарослями бинарного формата хранения логофф. :)

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

     
     
  • 5.208, Имя и код (?), 04:09, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ну... Это неуспешно скрыто за зарослями бинарного формата хранения логофф. :)
    > Выбросьте бинарный гзип уже? Вы его деревья хаффмана в уме вообще не
    > построите. И на тетрадном листочке - задолбаетесь.

    Ну да, ну да, а изчё выинты повыбрасываем - там коды царя соломона используют.
    Тока ведь гзип-то, текстовой природы лога, сцуко, не меняет :)))

     

     ....большая нить свёрнута, показать (115)

  • 1.2, Аноним (-), 14:28, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Наверное, стоило особо отметить, что к поддержке проекта уже присоединились компания Adicson, разрабатывающая rsyslog, и BalaBit, разрабатывающая syslog-ng.
     
     
  • 2.184, исчо_адын_аноним (?), 15:12, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Наверное, стоило особо отметить, что к поддержке проекта уже присоединились компания 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%"

    все как у людей :) хош джисон - бери джисон, хош срать в монго ( угу, свалка ) - сри; скуль тож можно, НО! текст никто не отменя ;)
    А идиоту поможет только евтаназия

     
     
  • 3.209, Имя и код (?), 04:10, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А идиоту поможет только евтаназия

    Я против подобного милосердия! В назидание! :))

     
  • 3.242, Куяврик (?), 00:46, 13/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > все как у людей :) хош джисон - бери джисон, хош срать
    > в монго ( угу, свалка ) - сри; скуль тож можно,

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

     

  • 1.3, Аноним (-), 14:32, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Надеюсь, в линуксе наконец появится нормальный механизм удаленной репликации логов, с поддержкой шифрования и аутентификации.
     
     
     
     
     
     
    Часть нити удалена модератором

  • 6.55, anonymous (??), 15:57, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >Нормальной репликации там нет

    Таки тролль. man rsyslog-mysql

     
     
  • 7.63, Аноним (-), 16:21, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >>Нормальной репликации там нет
    > Таки тролль. man rsyslog-mysql

    А об ng-syslog никто из анонов, судя по всему, даже не слыхал никогда?

     
     
  • 8.145, Имя и код (?), 05:45, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Конечно нет Все знают про syslog-ng ... текст свёрнут, показать
     
     
  • 9.178, Аноним (-), 14:42, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Хоть горшком назови Только в печь не ставь Судя по тому, что вспомнил о нем од... текст свёрнут, показать
     
     
  • 10.210, Имя и код (?), 04:12, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не-а Искажение названия такого популярного пакета говорит о многом Да прям та... текст свёрнут, показать
     
  • 7.85, Аноним (-), 17:37, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Таки тролль. man rsyslog-mysql

    А ты сам-то читал, что там написано?
    Особенно в части репликации логов с поддержкой шифрования и аутентификации, да в нативном формате.

     
  • 7.89, Аноним (-), 17:44, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Таки тролль. man rsyslog-mysql

    Вы предлагаете конвертировать лог в бинарный формат, а потом реплицировать его средствами СУБД?
    Замечательно, но зачем тогда вообще нужен rsyslog? Не проще ли приложениями сразу свой лог в бинарную БД писать, через клиентскую либу мускула?

     
     
  • 8.146, Имя и код (?), 05:47, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Немного более чем нет ... текст свёрнут, показать
     
     
  • 9.173, Аноним (-), 13:48, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это что, подтверждение мысли о ненужности rsyslog ... текст свёрнут, показать
     
     
  • 10.211, Имя и код (?), 04:13, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, подумайте об этом на досуге ... текст свёрнут, показать
     
  • 7.94, Аноним (-), 18:27, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Таки тролль. man rsyslog-mysql

    Репликация средствами мускула? Лол.
    С тем же успехом можно текстовые логи через scp по крону копировать. А че, шифрование и аутентификация есть.
    Другое дело, что это, во-первых, костыли (и под требование "нормальности" не попадает), во-вторых, rsyslog, который и должен этим заниматься, оказывается какбэ не при делах.

     
     
  • 8.120, Deffic (?), 02:03, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Делайте силой мыли, ибо всё остальное - КОСТЫЛИ ... текст свёрнут, показать
     
     
  • 9.132, Аноним (-), 03:53, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не, дядя, мускуль в обязательном порядке для всего лишь ведения логов - это мега... текст свёрнут, показать
     
     
  • 10.226, Deffic (?), 22:33, 05/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Вы передёргиваете ... текст свёрнут, показать
     

     ....большая нить свёрнута, показать (14)

  • 1.4, Аноним (-), 14:32, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > В ходе встречи участники обсудили такие слабые места текущих подходов к ведению журнала событий как недостаточное внимание к журналированию со стороны разработчиков приложений, *разнообразие форматов журнальных записей*

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

     
  • 1.5, Аноним (-), 14:32, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Лучшее враг хорошего.
     
  • 1.12, Аноним (-), 14:46, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    а почему сислог они считают устаревшим?

    чем аргументируют?

     
     
  • 2.13, anonymous (??), 14:47, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    http://bb.comp-house.ru/comp-house.repo/wiki/what-i-dont-like-about-journald
     
     
  • 3.16, Аноним (-), 14:48, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > http://bb.comp-house.ru/comp-house.repo/wiki/what-i-dont-like-about-journald

    Как видим, Герхардса с его проповедями про превосходство rsyslog успешно заткнули =)

     
     
  • 4.23, anonymous (??), 14:55, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> http://bb.comp-house.ru/comp-house.repo/wiki/what-i-dont-like-about-journald
    > Как видим, Герхардса с его проповедями про превосходство rsyslog успешно заткнули =)

    http://bb.comp-house.ru/comp-house.repo/wiki/journald-and-rsyslog

     
     
  • 5.28, Аноним (-), 15:04, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > http://bb.comp-house.ru/comp-house.repo/wiki/journald-and-rsyslog

    Устаревшая инфа.
    Судя по сабжевой новости, теперь мнение этого товарища радикально переменилось, и он уже рвется помочь Поттерингу с допилом journald.

     
  • 2.43, Аноним (-), 15:18, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > а почему сислог они считают устаревшим?
    > чем аргументируют?

    Не умеет работать со структурированными данными (нет поддержки соответствующих форматов и API).

     

  • 1.22, Аноним (-), 14:55, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Так что теперь будет с journald?
     
     
  • 2.25, anonymous (??), 14:58, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Так что теперь будет с journald?

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

     
  • 2.29, VoDA (ok), 15:05, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Так что теперь будет с journald?

    К нему кроме его текущего API добавят ELAPT. А возможно ELAPI будет единственным API к jourland.

    Плюс для back compatibility оставят некий интерфейс эмулирующий syslog.

     
     
  • 3.32, Аноним (-), 15:06, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > К нему кроме его текущего API добавят ELAPT. А возможно ELAPI будет единственным API к jourland.

    Скорее второе - нынешний API journald пока не стабилизирован, поэтому сейчас его проще и удобнее подогнать под ELAPI.

     
  • 2.31, Аноним (-), 15:05, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Так что теперь будет с journald?

    Судя по всем, Lamberjack - это и есть journald, с небольшими косметическими изменениями. Так что скорее всего эти проекты объединят.

     

  • 1.41, Michael Shigorin (ok), 15:15, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Две недели назад компания Red Hat собрала в своем офисе
    > разработчиков популярных систем ведения логов, чтобы обсудить

    Радует то, что постарались обсудить, а не переть своим умом; удачи.

     
     
  • 2.61, Аноним (-), 16:19, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Радует то, что постарались обсудить, а не переть своим умом; удачи.

    А может, они с systemd/upstart еще повторят? Для полного счастья? :)

     
     
  • 3.66, Аноним (-), 16:25, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Радует то, что постарались обсудить, а не переть своим умом; удачи.
    > А может, они с systemd/upstart еще повторят? Для полного счастья? :)

    А может, они-таки наймут ОДНОГО вменяемого системного архитектора? И сделают ЕДИНОЕ решение? Совместимость-то важней и производительности и всего остального, если уж на то пошло. Актуальность этой максимы за 35 лет в ИТ посейчас не изменилась.

     
     
  • 4.71, Michael Shigorin (ok), 16:57, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > И сделают ЕДИНОЕ решение?

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

    > Актуальность этой максимы за 35 лет в ИТ посейчас не изменилась.

    Надо же, юниксы пятый десяток разменяли давно, а некоторые всё чуть ли не виндой мерить привыкли...

     
     
  • 5.179, Аноним (-), 14:45, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Мы это видим с каждым новым дистром линукса, которые уже числом, тащемта, за шту... большой текст свёрнут, показать
     
     
  • 6.191, Michael Shigorin (ok), 19:39, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Хм, пока похоже, что путаете GNU s Not UNIX с чем-то неприпоминаемым из высказыв... большой текст свёрнут, показать
     
  • 4.73, Аноним (-), 17:04, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > И сделают ЕДИНОЕ решение?

    А кто не согласен - будет расстрелян, так?

     
     
  • 5.118, Аноним (-), 00:35, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А у несогласных никуда всегда была gentoo.
     
     
  • 6.155, Имя и код (?), 07:10, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А у несогласных никуда всегда была gentoo.

    LFS

     
  • 6.167, zzz (??), 13:21, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А у несогласных никуда всегда была gentoo.

    А что делать тем кому не нравится пидон в каждой дырке в системе? :)

     
  • 3.91, Аноним (-), 17:50, 02/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А может, они с systemd/upstart еще повторят? Для полного счастья? :)

    А что там повторять? Сейчас разработка upstart фактически превратилась в копипасту с systemd, так что понятно, кто в избе хозяин.

    Вообще, на последнем фосдеме был слушок, что убунта собирается переходить на systemd начиная с 12.10 (сразу после выпуска LTS).

     
     
  • 4.133, Аноним (-), 03:55, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А что там повторять? Сейчас разработка upstart фактически превратилась в копипасту с
    > systemd, так что понятно, кто в избе хозяин.

    Ну вот я как раз за то чтобы они собрались и обсудили как и чего. К systemd больно дофига предъяв - то usr ему не там, то run не там, то еще дерьмо какое-то случается. Почему-то с upstart таковых воплей было ровно НОЛЬ...

    > Вообще, на последнем фосдеме был слушок,

    Пруф? Мы тут не старые карги на лавочке, так что сарафанное радио нас не устраивает.

     
     
  • 5.217, qux (ok), 17:01, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > К systemd больно дофига предъяв - то usr
    > ему не там, то run не там, то еще дерьмо какое-то
    > случается. Почему-то с upstart таковых воплей было ровно НОЛЬ...
    >> Вообще, на последнем фосдеме был слушок,
    > Пруф? Мы тут не старые карги на лавочке, так что сарафанное радио
    > нас не устраивает.

    Это вам-то пруф, с предъявами о usr?
    Кто еще не видел: http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

     

  • 1.110, pavlinux (ok), 22:17, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Чё они х...ей занимаются! Нужно структурированные, ну прилепи ты syslog2sql и радуйся жизни?!

    Движок есть - mysql, pgsql, mssql,...sql
    Формат есть - SQL
    На SQL даже какой-то стандарт есть!

    Осталось самую малость - заставить программистов писать SQL запросы.
        

     
     
  • 2.127, VoDA (ok), 03:16, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Чё они х...ей занимаются! Нужно структурированные, ну прилепи ты syslog2sql и радуйся
    > жизни?!

    бинарное хранение это следствие, а не причина.

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

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


     
  • 2.134, Аноним (-), 03:59, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Чё они х...ей занимаются! Нужно структурированные, ну прилепи ты syslog2sql и радуйся

    ... всяким там возможным SQL-иньекциям? :)

    И да, как sql база обеспечит защиту от удаления записи задним числом, например?

     
     
  • 3.222, pavlinux (ok), 01:24, 05/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > И да, как sql база обеспечит защиту от удаления записи задним числом, например?

    REVOKE ALL ON logdbase TO logodmin@'localhost';
    GRANT INSERT ON logdbase TO logodmin@'localhost' IDENTIFIED BY 'passwd';

     
  • 2.150, XoRe (ok), 06:15, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Чё они х...ей занимаются! Нужно структурированные, ну прилепи ты syslog2sql и радуйся
    > жизни?!
    > Движок есть - mysql, pgsql, mssql,...sql
    > Формат есть - SQL
    > На SQL даже какой-то стандарт есть!
    > Осталось самую малость - заставить программистов писать SQL запросы.

    А зачем SQL запросы, когда есть NoSQL решения?
    С хранением данных чисто в оперативке!
    Вам что, жалко пару десятков гигабайт оперативки под логи)

     

  • 1.113, Аноним (-), 22:46, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Сколько же воплей в этом треде... Никаких lumberjack и journald не будет ближайшее время. Успокойтесь. А что плохо и что хорошо, будут решать люди поумнее нас.
     
     
  • 2.135, Аноним (-), 04:00, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > люди поумнее нас.

    См. #128 :)

     
  • 2.241, arisu (ok), 05:16, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > люди поумнее нас.

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

     

  • 1.149, XoRe (ok), 06:13, 03/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Название - игра слов.
    log - бревно.
    Lumberjack - дровосек.
    Т.е. логоруб)
    Нам предлагают систему, которая будет рубить логи.
    На корню)

    Логи пишутся, чтобы их прочитать, а не чтобы их записать.
    Имхо, ради средства жертвуют целью - удобством чтения.
    Процесс ради процесса.

    <offtopic>
    В последнее время стало модным внедрять что-то бинарное.
    systemd, upstart, система логов от Поттеринга.

    У Microsoft сначала были ini файлы.
    Потом они разработали "реестр".
    Если сделать дамп реестра и сравнить его формат с форматом ini файла, можно найти, что они похожи.
    Примерно, как братья-близнецы.
    Это тот же самый ini файл, только теперь в бинарном формате, раскиданный по нескольким файлам.

    MS не придумал ничего лучше, чем сделать ini файлы в бинарном формате.
    Что мы получили?
    1. программы для дефрагментации реестра
    2. файлы реестра раскиданы по разным местам
    3. эти файлы просто так не скопировать, не открыть
    4. а если их и скопировать, то чтобы открыть эти файлы, нужна специальная утилита
    Прогресс, *ля.

    Как я рад, что в *nix для системных и пользовательских настроек используется первобытный и допотопный plain text формат.
    Что позволяет открыть логи и конфиги 20 летней давности даже сейчас.
    Без риска получить ошибку "неподдерживаемый формат. пересохраните данные в новом формате."
    </offtopic>

     
     
  • 2.156, Имя и код (?), 07:13, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Название - игра слов.
    > log - бревно.
    > Lumberjack - дровосек.
    > Т.е. логоруб)
    > Нам предлагают систему, которая будет рубить логи.
    > На корню)
    > Логи пишутся, чтобы их прочитать, а не чтобы их записать.
    > Имхо, ради средства жертвуют целью - удобством чтения.
    > Процесс ради процесса.

    Адназначна! :)

     
  • 2.161, Аноним (-), 11:58, 03/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что мы получили 1 программы для дефрагментации реестра 2 файлы реестра раскид... большой текст свёрнут, показать
     

  • 1.186, Аноним (186), 17:05, 03/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ну скажем так. если требуется для каких-то целей строить по логам статистику - предложенный подход вполне оправдан. если у тебя 50 гигов жатых гзипом логов, делать по ним grep несколько накладно. однако такие задачи возникают редко. то что они пишут о парсерах - тоже правда. вот давеча добавил поле в логформат, пришлось пепенастраивать awstats (тоже описывать там новый логфорат). однако хранение логов в структурированном бинарном формате во многих случаях действительно неудобно. хотя есть дебаг логи где в лог пишется объект в json или что-нибудь такое, грепать по ним нереально.
     
     
  • 2.199, nobody (??), 02:37, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если нужна статистика, то и сейчас вообще не проблема, например через пайп или п... большой текст свёрнут, показать
     

  • 1.198, vi (?), 02:12, 04/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Похоже кто то хочет подзаработать на неграмотности админов.
    Что ж, флаг им в руки. Им тоже денежки зарабатывать надо.
     
  • 1.212, Piter_Ring (ok), 05:06, 04/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Линуксоиды воистину неизлечимы :)
    Вместо того что бы "механизировать" ручной труд они предлагают разработать очередного "дровосека".

    Для несведущих;
    у Финов есть поговорка, дословно не помню, но суть примерно следующая:
    - мы используем Тимберджек, а Русские - Лумберджек (по фински звучит даже без перевода вполне унизительно).

    Для справки:
    тимберджек: http://www.youtube.com/watch?v=QoC3tBwR0eA&feature=related
    лумберджек: http://www.youtube.com/watch?v=xnpKzOvxaJI&feature=player_detailpage#t=69s

    ЗЫ:
    модераторам: сообщение написано на стенке химическим карандашом. смывать, закрашивать - бесполезно.

     
     
  • 2.216, Michael Shigorin (ok), 15:26, 04/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > модераторам: сообщение написано на стенке химическим карандашом.

    Некоторые из нас понимают в красителях => способны без смывания и закрашивания развалить сопряжённые связи ;)

    Что сказать-то хотели?

     
     
  • 3.223, Piter_Ring (ok), 01:42, 05/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> модераторам: сообщение написано на стенке химическим карандашом.
    > Некоторые из нас понимают в красителях => способны без смывания и закрашивания
    > развалить сопряжённые связи ;)
    > Что сказать-то хотели?

    Если сильно постараются, то данный проект может вырасти и вместо http://www.youtube.com/watch?v=xnpKzOvxaJI

    получат вполне успешный результат типа http://www.youtube.com/watch?v=zFGva6ZS4fU&feature=related

     
     
  • 4.224, Michael Shigorin (ok), 02:21, 05/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Если сильно постараются, то данный проект может вырасти и вместо

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

    > получат вполне успешный результат типа

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

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

    PS: если что, у нас свою подсистему распределённого журналирования писали.  И я ни разу не хочу столько сущностей у себя на ноутбуке, даже близко.  На несколько тысяч хостов они оправданы, на один -- никак.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру