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

> И при первом старте начальная соль будет получена злоумышленником.

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

А ещё, мне жаль тебя, если побьётся хоть один бит твоего лога... Уж больно это ненадёжная защита с таким кодом...

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

Не смогут, потому что его нет. Ну или надо обрубить возможность делать ptrace на systemd, добавить SElinux или изоляцию.. WAIT.. OH SHI~~

Это у которого сказано «каждый раз, когда вы парсите html при помощи regexp'ов, бог убивает котёнка»? Резонно.

> поскольку одна запись - это просто две строки

А одна запись у вас в отдельном файле или вы её будете искать сперва?

Поскольку у нас есть определенный формат, мы можем строить индексы по любому параметру.

Индексы, надо полагать будут двоичными?

> потом 3 часа программу на любимо ЯП низкого уровня быдлокодить

С чего это мне быдлокодить утилиту, которая в комплекте с системой логирования и чей вызов не сложнее «cat /var/log/messages | less»?

А если она повреждена, то для справедливости можете считать, что у вас нет grep. Желаю удачи написать его с нуля.

Если нужна автоматизация, то логи стоит писать в БД. А чтоб какир их не затер, все логи стоит переправлять на отдельный хост. Все современные логгеры это умеют. Для локалхоста много приятнее и удобнее plain text.

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

ну конечно это хороший ход. но не ценой же КАЖДОЙ строки лога?! ИМХО потери производительности будут ОЧЕНЬ большие, а вот на секьюрность это повлияет мало.

В конце концов - можно сразу заплатить пару сотенных бумажек (рублей), и не парится, вести лог на другом сервере - это будет на 3-4 ПОРЯДКА дешевле, чем покупать такой сервер. Я не прав?

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

Поттеринг разве что-то лучше предложил? ИМХО туже схему. Ну пусть он в бинарники её обернёт, толку-то? даже я ломать не буду - нагуглю ломалку при необходимости.

>С чего это мне быдлокодить утилиту, которая в комплекте с системой логирования и чей вызов не сложнее

ну речь шла о запутанном бинарном логе.

кстати, причём тут котята? мои боты постоянно парсят HTML ИЧСХ regexами. Они ещё до сих пор живы. Лично Я - не парсю. мне лень. Да и зачем?

Запись искать, это ж обычный текстовый файл, поэтому и O(n).

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

Похоже, не все поняли суть таких логов.

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

С другой, мы получаем возможность более мощной обработки и поиска, и все инструменты для этого уже есть, ничего писать не нужно. Например, есть mongoDb. Сколько всего он умеет перечислять, надеюсь, не требуется. А засунуть такие логи в него можно скриптом из пары строк в постобработке в фоновом режиме.

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

> С чего это мне быдлокодить утилиту, которая в комплекте с системой логирования и чей вызов не сложнее «cat /var/log/messages | less»?

ну дайте сцылку на эту утилиту.

2 А если она повреждена, то для справедливости можете считать, что у вас нет grep. Желаю удачи написать его с нуля.

см. п1

ну logrotate решает чтоб большие файлы не парсить.

> ну дайте сцылку на эту утилиту.

А дайте ссылку на пакет с готовой системой бинарных логов.

ну logrotate решает чтоб большие файлы не парсить.

Ну смешно же, это костыль.

Хорошо бы все это вбросить в какой-нибудь федоровский список рассылки..

> Запись искать, это ж обычный текстовый файл, поэтому и O(n).

Вы уж определитесь - или обычный текстовый файл или JSON.

С одной стороны, они ничем не отличаются от обычных текстовых, тех что есть сейчас.

Если обычные текстовые, то решается только одна проблема - скорость доступа. Но остаётся проблема парсинга для автоматизированного анализа. И каждый раз вам придётся делать его заново. Или это всё-таки JSON. Но тогда там уже другой разговор о сложности будет.

Например, есть mongoDb.

MongoDB - это не плохо. Умеет достаточно и даже больше. Вот только его плюшки доступны через его API, а при этом варианте уже не важно в каком виде хранятся данные. Но при этом Mongo жрёт памяти и весит 30 мегабайт в архиве. Многовато для системы журналирования. :) А так - неплохо.

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

Это, конечно, лишь предположение. Я не знаю что выберет Поттеринг, но врядли что-то сложное.

Я иронизирую. Пост по ссылке оперирует аргументами вроде того, что я указал.

Насколько я понял, все, кто здесь в том или ином ключе упоминают «парсинг html регекспами» вкладывают в эту фразу разный смысл. Просто в основном все говорят и мало кто пытается понять собеседника. Впрочем, это в духе лора :)

Сторонники скорее всего ограничиваются извлечением какой-то доли интересующей их информации из документов, игнорируя всю его структуру в целом. Если это всё, что им нужно - регекспы годятся. А противники говорят о парсинге в более широком смысле - как о полном разборе структуры документа. Тут регекспы непригодны. Благо для распространённых языков реализованы парсеры-построители объектов DOM.

> Или это всё-таки JSON. Но тогда там уже другой разговор о сложности будет.

JSON описывает некоторую дополнительную структуру внутри plain text. Что мешает эту структуру тупо игнорировать (так что сложность поиска не превысит сложность поиска в аналогичном plain text)?

Вы уж определитесь - или обычный текстовый файл или JSON.

Это обычный текстовый файл в JSON ) см. комментарий

Но при этом Mongo жрёт памяти и весит 30 мегабайт в архиве

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

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

Ну а чем отличается текстовый лог от бинарного, было неоднократно объяснено в исходной новости)

> Что мешает эту структуру тупо игнорировать (так что сложность поиска не превысит сложность поиска в аналогичном plain text)?

Мешает то, что именно данные из этой структуры и нужны. Как бы чувствуется, что вы Ъ. :) Для человека никто не мешает сохранить messages, но логи нередко приходится читать не людям.

> Это обычный текстовый файл в JSON )

Знаете, это большая ошибка считать xml, html, json - текстовыми файлами. Текстовые файлы - это файлы, в которых информация разбита построчно. Здесь же перевод строки зачастую игнорируется, а разбиение информации производится собственными управляющими символами.

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

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

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

> Мешает то, что именно данные из этой структуры и нужны.

Структура теряется, данные остаются. По-прежнему не вижу проблемы.

Как бы чувствуется, что вы Ъ.

Ъ, ты тред хотя бы прочитал, прежде чем сюда писать? :)

Для человека никто не мешает сохранить messages, но логи нередко приходится читать не людям.

У не-людей парсинг json/xml никаких трудностей не вызывает. Ну будет там машина со стеком вместо регэкспа, ну и пофиг.

> Знаете, это большая ошибка считать xml, html, json - текстовыми файлами. Текстовые файлы - это файлы, в которых информация разбита построчно. Здесь же перевод строки зачастую игнорируется, а разбиение информации производится собственными управляющими символами.

Нет-нет-нет. Ты не понял идеи. Лог - это последовательность json-документов, отделенных друг от друга переносами строк. Никаких переносов строк _внутри_ здешнего json-а не допускается. То есть традиционное для plain text построчное разделение по-прежнему в силе.

> По-прежнему не вижу проблемы.

Пичалька. Не могу тогда помочь.

Ъ, ты тред хотя бы прочитал, прежде чем сюда писать? :)

Не без этого.

У не-людей парсинг json/xml никаких проблем не вызывает.

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

Или сейчас вспомним эпические срачи на тему gconf хранит всё в xml?

===== А теперь не удалённое. :)

Ты не понял идеи. Лог - это последовательность json-документов, отделенных друг от друга переносами строк.

И что? Операция перехода к следующей строке всё равно имеет «цену» O(n). Т.е. без бинарного индекса-костыля всё равно тормоз. (А есть нет разницы...)

Никаких переносов строк _внутри_ здешнего json-а не допускается.

Вы так говорите, как будто это преимущество. Желаю вам почитать такой лог глазами, когда у него длина будет под несколько мегабайт. :)

И да, O(n) это если нам надо найти известную i-ую запись. А если по значеню параметра, то всё равно парсить JSON-строки. Со всеми прелестями O(2^N), если регулярками с рекурсией. Ну или полегче, если нормальным парсером. :)

> Операция перехода к следующей строке всё равно имеет «цену» O(n).

Стоимость перехода к следующей строке равна длине текущей строки. То есть типично это просмотр нескольких десятков символов.

O(n) это если нам надо найти известную i-ую запись.

Зачем такое могла бы понадобиться?

А если по значеню параметра, то всё равно парсить JSON-строки.

С чего бы? Последовательность вроде « «pid»: 2104 » прекрасно выцепляется простым грепом, безо всяких парсеров.

Со всеми прелестями O(2^N), если регулярками с рекурсией.

Ты про backreferences что ли?

> Ну или полегче, если нормальным парсером.

Нормальный парсер разбирает документ за O(n).

> С чего бы? Последовательность вроде « «pid»: 2104 » прекрасно выцепляется простым грепом, безо всяких парсеров.

О, это просто замечательно, до тех пор, пока `«pid»: 2104` не окажется частью какого-нибудь другого блока, например, текстового примечания. Или не будет написан иначе, но допустимо, в рамках JSON:
1. «pid» : 2104
2. «pid» :2104
3. «pid»:2104
4. «pid»: 2104
5. etc...

А если жестко зафиксировать формат, то считайте, что над таким логом будет вечно горящая надписть: «И чем это принципиально отличается от бинарного вида».

Ты про backreferences что ли?

Ну, а как без них древовидную в общем виде структуру пытаться разобрать? Или это уже не JSON получается, нечего вводить в заблуждение. :)

Нормальный парсер разбирает документ за O(n).

Это у вас офигенный парсер! Даже простой поиск подстроки в строке даёт O(n) только в лучшем случае.

> А если жестко зафиксировать формат, то считайте, что над таким логом будет вечно горящая надписть: «И чем это принципиально отличается от бинарного вида».

Тем, что human-readable.

Ты про backreferences что ли?

Ну, а как без них древовидную в общем виде структуру пытаться разобрать?

И давно регэкспы с backreferences позволяют разбирать контекстно-свободные грамматики? :D

Это у вас офигенный парсер!

Тривиально же. Попробуй написать свою версию. Читаешь букву за буквой. Открывающая скобка - push в стек. Закрывающая скобка - pop из стека. Попутно конструируешь DOM-дерево.

Даже простой поиск подстроки в строке даёт O(n) только в лучшем случае.

В наихудшем случае. Если алгоритм нормальный, а не школоло.

>бида... У меня-же права рута!

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

>мои боты постоянно парсят HTML ИЧСХ regexами.

И ты переписывашь регэкспы с нуля при каждом незначительном изменении HTML?

> Тем, что human-readable.

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

И давно регэкспы с backreferences позволяют разбирать контекстно-свободные грамматики? :D

Никогда не могли, но некоторые (не будем показывать пальцем на TC) настолько в это не верят, что даже спорить не хочется. :)

Тривиально же.

А, это мы снова исключительно про JSON.

Ты либо не прочитал основные посты, либо не понял идеи. По поводу производительности: она примерно такая же, как и текстовых логов с поиском по регуляркам. Может чуть больше, может чуть меньше, это не принципиально.

А вот принципиально то, что в этом случае, в отличие от голого текста, ее можно увеличить многократно запихиванием логов (не в реальном времени - в пост-обработке для аудита!) в что-то вроде MongoDB.

О, это просто замечательно, до тех пор, пока `«pid»: 2104` не окажется частью какого-нибудь другого блока, например, текстового примечания.

Тут смотря что тебе надо: выше была сформулирована задача «найти все записи, в которых упоминается pid 2104». Это делается просто грепом: grep «pid: 2104». Теперь ты добавляешь условие, что оно должно встречаться только в главном заголовке. Это по-прежнему можно сделать регуляркой, а можно указать парсеру json конкретное поле, что-то вроде ".pid" = 2104.

Ну, а как без них древовидную в общем виде структуру пытаться разобрать?

Никто не предлагает разбирать json регулярками.

Да ни фига оно не readable

{ «date»: «2011-11-23 23:25:36.0545 +0400», «pid»: 2104, «name»:«dbus», «severity»:1, ...

«msg»: «entering main loop» }

Текст: Nov 24 20:23:53 gaga dbus-daemon[786]: ** Message: entering main loop

По-моему примерно то же самое, если учесть, что в json интересна вторя строка

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

Вместо json можно использовать любой другой формат, например такой

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

> она примерно такая же, как и текстовых логов с поиском по регуляркам

Т.е. не очень.

По-моему примерно то же самое

Для робота - да. Человекам не удобно читать текст, разбитый на блоки, не удобно читать текст через одну строку.

Короче, я не понимаю, что тебя конкретно здесь не устраивает

То, что на замену сегодняшнему плохому, но хорошо читаемому глазами и медленно и трудно кодом, предлагается нечто, тяжелее читаемое глазами и медленно, хотя и легче - кодом.

>И ты переписывашь регэкспы с нуля при каждом незначительном изменении HTML?

веришь? только на ЛОРе переписывают.

>Т.е. не очень. Да. Не очень, если не использовать индексы. Очень только индексированная БД.

Человекам не удобно читать текст, разбитый на блоки, не удобно читать текст через одну строку.

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

Мне нравится мой вариант, потому что он ничего не ломает и тривиально реализуется, добавляя довольно много интересных возможностей. Понятное дело, что нельзя сказать, что это прямо-таки вах и серебрянная пуля, но плюсы, по-моему, довольно весомы. Я бы сказал, что такое решение можно назвать костылем, но ничего лучше в голову не приходит, потому что все остальное это уже революционные решения, вроде journald. И, кстати, прочитав статью поттеринга целиком, я пришел к выводу, что все поставленные им задачи такие логи решают. Костыльно, но зато в разы проще и без анальной зависимости от systemd.

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