LINUX.ORG.RU
Форум — Talks  

[syslog][поттерингосрач]логи в JSON

 


0

1

Почитал я тут срач в теме про journald, в принципе могу сказать, что скорее солидарен со сторонниками текстовых логов. Но я подумал вот что: существует же множество человекочитаемых форматов, которые также поддаются машинной обработке, например JSON. Пример:
{ «date»: «2011-11-23 23:25:36.0545 +0400», «pid»: 2104, «name»:«apache», «severity»:1, ...
«msg»: «127.0.0.1 - frank [11/Nov/2011:23:25:36 +0400] \„GET /apache_pb.gif HTTP/1.0\“ 200 2326» }
и т.д. Т.е. две строки для удобства грепания: строка самого syslog и строка приложения. На самом деле полей может быть дофига.

Преимущества перед простым текстом:
- формат легко и быстро парсится, быстрее регулярок
- формализованный заголовок
- можно написать набор утилиток, которые будут выдергивать текст перед грепанием, при этом добавлении произвольных полей в любую часть все продолжает работать как ни в чем не бывало
- можно легко создать SQL-подобный язык запросов. Например: SELECT msg FROM apache.log WHERE date >2011.11.22;
- приложения могут добавлять свои поля (они добавятся как поля «msg»), которые могут обрабатываться тем же способом теми же утилитами: SELECT pid, name from apache.log WHERE msg.code=200 AND date >2011.11.22
- можно одним запросом обрабатывать одновременно несколько логов
- можно в фоне строить индекс (кстати, для тескта тоже можно)
- если уж очень всралось, можно вставлять блобы в base64, они легко выкидываются парсером JSON

Преимущества перед бинарными логами
- текстовый формат. nuff said
- обрабатывается грепами, седами и прочими перлами на ура. Можно вообще не пользоваться сторонними утилитами
- скорость и простота
- добавляется в syslog элементарно
- расширяется просто путем добавления новых полей, при этом все старые скрипты и утилиты продолжают работать
- приложение само может регистрировать произвольные поля и объекты без гемора

В общем, на мой взгляд, так одни плюсы. Почему бы не начать с этого?

★
← [ЖЖ][МТС][ЕРУНДА] Invalid IMSI
Радостные вести про HDD →
 ← 1 2 3

Выглядит неплохо в принципе. Да и удобнее в таком формате логи импортировать во всякие рисовалки красивых графиков.

Tark ★★★
()

Преимущества перед бинарными логами
...
- скорость и простота

Ты что-то путаешь.

Deleted
()
Ответ на: комментарий от x3al

если формат значимых полей определен - почему нет? по переменному количеству полей, конечно, нет

marvin_yorke ★★★
()
Ответ на: комментарий от stevejobs

Людей, считающих, что парсинг и обработка это одно и тоже, не истребить. Они постоянно новые рождаются.

Tark ★★★
()
Ответ на: комментарий от stevejobs

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

gaga ★
() автор топика

Так возьми и напиши Поттерингу, за чем дело стало?

roq ★
()
Ответ на: комментарий от gaga

> тебе привести пример регекспа для парсинга json?

Для начала приведи пример регэкспа, проверяющего, что в json-е правильно расставлены скобочки.

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

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

gaga ★
() автор топика
Ответ на: комментарий от Deleted

>Так бинарные данные что так, что так быстрее получаются.

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

gaga ★
() автор топика

> можно легко создать SQL-подобный язык запросов. Например: SELECT msg FROM apache.log WHERE date >2011.11.22;

Постарайтесь только без велосипедирования. Идея хранить и индексировать json-объекты отнюдь не нова. http://www.mongodb.org/display/DOCS/Schema+Design#SchemaDesign-Example

Manhunt ★★★★★
()
Ответ на: комментарий от gaga

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

Строк будет меньше.

Плюс если уж писать бинарники, то это будет что-то вроде БД, а туда вставка не такая уж тривиальная.

В случае логов вставка не требуется, нужно только добавление в конец.

Deleted
()
Ответ на: комментарий от gaga

> нахера?

Ок, перефразирую (и усложню) вопрос. Вычлени из лога все записи, в которых встречается слово «217.76.32.61». То есть я должен увидеть всё, что упоминалось всвязи с «217.76.32.61». Регэксп в студию.

Manhunt ★★★★★
()

> - можно в фоне строить индекс (кстати, для тескта тоже можно)

Проблема еще и в том, чтобы не дать дорвавшемуся до рутовских прав злоумышленникау подделать индекс (помешать вычистить ненужные по его мнению записи).

Manhunt ★★★★★
()
Ответ на: комментарий от stevejobs

> во имя провокации срача

ТС же написал: «приложение само может регистрировать произвольные поля и объекты без гемора». Произвольные объекты.

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

тогда автору нужно срочно поспорить самому с собой, прямо в этом треде

stevejobs ★★★★☆
()
Ответ на: комментарий от Manhunt

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

GAMer ★★★★★
()
Ответ на: комментарий от Deleted

Ах, да. А вот за это

можно легко создать SQL-подобный язык запросов


я даже не знаю что нужно сделать, но что-то очень нехорошее.

Deleted
()
Ответ на: комментарий от Deleted

> А вот за это я даже не знаю что нужно сделать, но что-то очень нехорошее.

До расстрела или после? :D

логи в JSON

Расстрел на месте.


Да, и расскажи, что бы ты хотел сделать с Поттерингом? :D

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

>До расстрела или после? :D

Ну, можно же и после если найдутся некрофилы или некроманты :)

Да, и расскажи, что бы ты хотел сделать с Поттерингом? :D


Подарить ему лопату, как символ того, что он делает :} Кроме systemd мне у него ничего не понравилось. И даже это пока ещё непонятно, ибо сначала щупать надо, а это надо тестинг и костыли изучить для обхода некоторых вещей, что там для этого не работают. Лениво…

Deleted
()

2011-11-23 23:25:36.0545 +0400\t2104\tapache\t1\t...\t127.0.0.1 - frank [11/Nov/2011:23:25:36 +0400] «GET /apache_pb.gif HTTP/1.0» 200 2326

\t символ табуляции, если что. По-моему удобнее, чем все эти ваши JSON-ы. Прикрутить индекс, который обновляется, когда машине скучно и нечего делать, поиск, который использует индекс для проиндексированных данных и линейный поиск для остальных данных и всё.

Legioner ★★★★★
()
Ответ на: комментарий от dismal_faun

> имхо в YAML логи делать еще няшнее

Читал я про этот ваш YAML. Закопать и для надежности вбить сверху осиновый кол.

Manhunt ★★★★★
()
Ответ на: комментарий от Legioner

>\t символ табуляции, если что. По-моему удобнее, чем все эти ваши JSON-ы.

Ага. А теперь представь многострочную запись в этом.

x3al ★★★★★
()

Я конечно все прослоупочил, но зачем? Зачем хранить логи в неведомом бинарном формате? Зачем хранить логи в убогом жсон? Зачем не хранить логи просто в виде текстовых записей?

staseg ★★★★★
()
Ответ на: комментарий от x3al

Вообще, возможность отдавать логи в json ‒ здравая идея. Но не хранить же их текстом.

x3al ★★★★★
()
Ответ на: комментарий от staseg

>Зачем не хранить логи просто в виде текстовых записей?

Распарси простые текстовые записи пары разных демонов. Назови число велосипедов, которые ты изобретёшь/стянешь из гугля.

x3al ★★★★★
()
Ответ на: Традиционно от Deleted

> Читать самый заплюсованный коммент до просветления :)

Твой линк не релевантен, ведь все и без того знают, что XML - какашка, не читается, регэкспами не парсится, и тд. Вот тут-то и появляется Спаситель - весь в белом - чудодейственный json :D

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

<evangelist-mode>
если прочтать по диагонали спеку, то не трудно понять что он охренителен, ибо взял лучшее из языков разметки и объединил в удобный для человеков вид

развеж можно в такое не влюбиться? :3

---
Time: 2001-11-23 15:01:42 -5
User: ed
Warning:
  This is an error message
  for the log file
---
Time: 2001-11-23 15:02:31 -5
User: ed
Warning:
  A slightly different error
  message.
---
Date: 2001-11-23 15:03:17 -5
User: ed
Fatal:
  Unknown variable "bar"
Stack:
  - file: TopClass.py
    line: 23
    code: |
      x = MoreObject("345\n")
  - file: MoreClass.py
    line: 58
    code: |-
      foo = bar

</evangelist-mode>

dismal_faun ★★
()
Ответ на: комментарий от Manhunt

Мой линк релевантен, твой коммент — нет. Deal with it :3

Deleted
()
Ответ на: комментарий от dismal_faun

> если прочтать по диагонали спеку развеж можно в такое не влюбиться? :3

Можно. Если прочитать спеку не по диагонали, а пристально и вдумчиво. YAML - зло.

Manhunt ★★★★★
()

>- формат легко и быстро парсится, быстрее регулярок

в целом не плохо. Я такое sed'ом легко распарсю.

drBatty ★★
()
Ответ на: комментарий от x3al

>Распарси простые текстовые записи пары разных демонов. Назови число велосипедов, которые ты изобретёшь/стянешь из гугля.

Я видимо что-то делал не так, потому что мне всегда хватало одной утилиты греп. И tail для онлайн-мониторинга.

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

staseg ★★★★★
()

Идея неплохая, мне нравится. Тем более, есть готовые библиотеки для работы с JSON, не надо писать свой парсер, и читается нормально.

Black_Shadow ★★★★★
()
Ответ на: комментарий от Manhunt

>Для начала приведи пример регэкспа, проверяющего, что в json-е правильно расставлены скобочки.

дык если все нечётные с {, а все чётные }, то что сложного?

sed '1~2{/^{/!q70;};2~2{/}$/!q71;}'

(не проверил) вернёт 70 или 71 если не то.

drBatty ★★
()
Ответ на: комментарий от staseg

>Я видимо что-то делал не так, потому что мне всегда хватало одной утилиты греп. И tail для онлайн-мониторинга.

Неверно. Вытащи, например, дату. Тебе понадобится по велосипеду на демон.

x3al ★★★★★
()
Ответ на: комментарий от staseg

>Зачем хранить логи в неведомом бинарном формате? Зачем хранить логи в убогом жсон? Зачем не хранить логи просто в виде текстовых записей?

если я правильно распарсил вы-ер Паттеринга, то фишка в том, что придёт злой какер, и sed'ом почикает лог. А если его в бинарь сунуть, то не почикает. Как-то так.

ЗЫЖ дайте ссылку на эту тему плз.

drBatty ★★
()
Вы не можете добавлять комментарии в эту тему: топик перемещен в архив.
 ← 1 2 3
← [ЖЖ][МТС][ЕРУНДА] Invalid IMSI
Talks
Радостные вести про HDD →