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

>json описывается КС-грамматикой и не может быть распарсен регулярными выражениями

sed-скрипт является Тьюринг-полным, а следовательно может распарсить что угодно.

Да, ты не писал _автоматические_ мониторилки, которые на основании логов принимают какие-то решения и производят действия.

> sed-скрипт является Тьюринг-полным, а следовательно может распарсить что угодно.

мышление хомячков (на которых собственно и нужно рассчитывать элементарные интерфейсы, если мы хотим добиться 99%-й популярности линукса в массах) не является тьюринг-полным, и ему подчас сложно поять смысл даже отдельно взятой гнутой утилиты, не то что всего стандартного набора. Ты можешь седом переехать что угодно, а мой среднестатистический одногруппник со специальности «системы и сети» даже SQL-ем то не может ничего найти.

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

этот IP будет в чётных, в нечётных, или и там и там?

>мышление хомячков (на которых собственно и нужно рассчитывать элементарные интерфейсы, если мы хотим добиться 99%-й популярности линукса в массах)

1. а мы хотим 99%?

2. сделать конвертор => ViewLogs.exe никогда не поздно. Ну или как там их БД для логов завётся?

>sed-скрипт является Тьюринг-полным, а следовательно может распарсить что угодно.

По-твоему sed - это регулярное выражение?

>Да, ты не писал _автоматические_ мониторилки, которые на основании логов принимают какие-то решения и производят действия.

Ну да. Посмотрим, что выйдет из его затеи.

> sed-скрипт является Тьюринг-полным

В таком случае он не является регулярным выражением.

> на которых собственно и нужно рассчитывать элементарные интерфейсы

Глупые хомячки ничего сложнее соски понять не могут в принципе да и не хотят. Но это не повод делать из линукса вторую макось.

>Читай: http://www.opennet.ru/opennews/art.shtml?num=32347

почитал. сейчас федоре в текстовом режиме установки надо 640Мб (1100+ рекомендуется), 17й понадобится 6400Мб и i9+. После таких-то нововведений...

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

Не понял этой фразы. Разъясни, что за четные-нечетные?

>В таком случае он не является регулярным выражением.

верно.

Правильно, конвертер! Для начала можно прикрутить виртуальный /proc/json/logXXX, там видно будет, удобно или нет. Хотя не обязательно /proc конечно, хехе.

как я понял, предлагается подмножество JSON

Т.е. две строки для удобства грепания: строка самого syslog и строка приложения.

> как я понял, предлагается подмножество JSON

Неа. [syslog][поттерингосрач]логи в JSON (комментарий)

да. В одну строчку. чётные строки пишет syslog, чётные - приложение. Примерно как сейчас и есть, но в 2 строки.

Ок, понял. Дейтсвительно, при таком синтаксисе потроха json-а разгребать не обязательно и grep хорошо работает.

>Кроме systemd мне у него ничего не понравилось.

Чем avahi не угодил?

У меня в нём необходимости, потому любое, что его вдруг вытянет, сразу станет ненужным.

ух, сколько понаписали, пока я в магаз ходил.

всё, что упоминалось всвязи с «217.76.32.61». Регэксп в студию.

cat apache.log | grep «217.76.32.61»
греп ведь по-прежнему работает.

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

Я не говорю, что сислог с логами в json решит эту проблему. Но обрати внимание, что система поттеринга ее _тоже не решает_, вопреки его заверениям. Более того, ее таким способом вообще невозможно решить.

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

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

yaml не погрепать, поэтому нет

Ну, положим, что сам демон, по идее, тянет довольно мало вещей. А с клиентскими либами немного сложнее, но они хоть демонов не вешают.

Бинарные данные в JSON не засунешь.

Всё это не нужно. Это не энтерпрайс.

Хорошие логи должны собираться на специально выделенном для логов кластере, а поиск по ним должен производится с помощью map-reduce-запросов.

man base64

> Но обрати внимание, что система поттеринга ее _тоже не решает_, вопреки его заверениям.

Не уверен. Но в любом случае ничто не мешает параллельно вести файл с подписями.

Бинарные данные в JSON не засунешь.

1. в данном случае не нужно;
2. ты ошибаешься.

>ничто не мешает параллельно вести файл с подписями

Леннарт предлагает подписывать сообщения с учетом всех предыдущих, начиная с «нулевого», хэш которого хранится в «secure write-only place». Я не разбирался глубоко в деталях, кроме этой статьи ничего не читал по journald, но это попахивает бредом: если это защищенное место на текущей машине, то оно доступно взломщику по определению. Если ты один хрен синхронизируешься по сети, почему не перенаправлять логи туда? Да и в этом случае, почему взломщик не может перехватить первый хэш?

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

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

Если бы файлы были в json, чтение параметров выглядело бы примерно так: int nr_dirty = json_int_from_file( «/proc/vmstat», «nr_dirty» ); и все!

Вместо этого приходится писать кучу глючного быдлокода с fgets()/fscanf()/..., причем для каждого файла разную.

>man base64

Это уже совсем не human readable.

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

Что значит легко и быстро? Вы не на базаре. Дайте оценку сложности тогда уже. А так, для сортировки пяти значений, например, и пузырёк быстр. :)

напиши поттерингу, делов-то.

Поттеринг об этом писал.

O(n)

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

Поскольку у нас есть определенный формат, мы можем строить индексы по любому параметру. Тогда сложность поиска будет O(log2(n)), сложность разбора одной записи остается прежней, но, поскольку она короткая, можно особо не обращать на нее внимания.

Впрочем, даже не в человекочитаемости дело. А дело в том, что бинарные данные, форматнутые в base64, будут очень много места занимать. JSON — это текстовый формат, он не предназначен для хранения бинарных данных. Хотя, если извратиться, то можно. Но это будет не самым лучшим решением. Если же изначально хранить это в бинарном формате «заголовок, длина содержания», то таких проблем не будет.

[gaga@gaga ~]$ cat /bin/cat | wc -c
48424
[gaga@gaga ~]$ cat /bin/cat | base64 | wc -c
65418

т.е. примерно на 30% больше получается в base64 - несмертельно, если бинарников не очень много. Если ты собираешься в лог пихать много бинарников, то у меня для тебя плохие новости.

Если же изначально хранить это в бинарном формате «заголовок, длина содержания», то таких проблем не будет.

Зато будет много других проблем, по сравнению с которыми эта покажется семечками.

>Не уверен. Но в любом случае ничто не мешает параллельно вести файл с подписями.

что мешает мне зачистить файл с подписями и подписать по новой? ИМХО подчистку логов решает только удалённый лог.

>Леннарт предлагает подписывать сообщения с учетом всех предыдущих, начиная с «нулевого», хэш которого хранится в «secure write-only place»

такую схему можно реализовать и на обычном логе. Особо и думать не надо - logrotate+mercurial. ну и checkin каждые N минут. и hg push туда-же... И я не думаю, что такая схема будет существеннее тормозить.

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

наверное он немного сэкономит траффика, отправляя только хеши. Вот только...

Nov 21 12:40:51 dt ntpd[1738]: peers refreshed

5364d69907727c6a96420e516796679e90f03d38b9d9a36566ebde2875716510

Строчка в логе, и её sha256. И что короче?

Про бинарники и говорить не хочется. Корки можно и в отдельных файлах хранить, если чё. Можно подумать их так много, и они все так необходимы. А что там ещё из бинарников?

могу предложить полусвой велик
(:date 2011/12/13 :pid 2000 (:msg GET 127.0.0.1 /index.html 200))
строки без пробелов оборачивать в скобки не обязательно
из минусов - надо эскекйпить () слешем и сам слеш двойным слешем а так вполне человекочитаемо и главное что префиксная форма записи ( : перед именем поля ) что для глаз гораздо лучше чем выискивать : после имени поля

а ну и да если не нравяится круглые лиспоскобки то они меняются на любые другие

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

Что значит легко и быстро? Вы не на базаре. Дайте оценку сложности тогда уже.

значит, что для поиска нужного значения достаточно простого и штатного инструмента, типа grep/sed.

А для бинарного лога вам во первых 3 часа формат курить, потом 3 часа программу на любимо ЯП низкого уровня быдлокодить. Да пусть grep хоть десять минут парсит - по любому, 6 часов _вашего_ труда больше.

>могу предложить полусвой велик

э не... не надо. Такое только на этом вашем лиспе и можно распарсить :(

Логи нужно вести в XML, для анализа юзать XSLT и LINQ-подобные запросы.

> Это уже совсем не human readable.

Бинарные данные и так не очень-то readable.

> что мешает мне зачистить файл с подписями и подписать по новой?

Мне видится такой механизм (не знаю, правильно ли его уагадал):
подпись_строки_N+1 := md5(секретная_соль_N + подпись_строки_N + строка_N+1)
секретная_соль_N+1 := md5(секретная_соль_N)

Ты ломаешь систему, дырявая программа в процессе пролома падает в корку.

Факт падения логгируется, строчкой номер N+1, и эта строчка лога подписывается. В этот момент секретная соль внутри оперативной памяти подписывателя, пригодная для подписывания строки номер N+1, безвозвратно перезаписывается своей же криптостойкой хеш-суммой (которая является секретной солью для строки N+2).

Теперь ты хочешь подделать строки номер N+1 и старше, вместе с их подписями. Чтобы подписать строку номер N+1, тебе нужно узнать ту самую соль, но взять ее не откуда.

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

> пригодная для подписывания строки номер N+1, безвозвратно перезаписывается

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

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

А ещё, мне жаль тебя, если побьётся хоть один бит твоего лога... Уж больно это ненадёжная защита с таким кодом... Ещё и с модификацией на каждую строчку лога.

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

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

Ну а вообще, ИМХО от рута защиты никакой нет, и если уж есть append-only сервер, туда и надо регулярно слать логи, или если трафика мало - хеши. Но вот только зачем для этого Поттеринг? Просто добавляем правило в logrotate.

Впрочем, даже не в человекочитаемости дело. А дело в том, что бинарные данные, форматнутые в base64, будут очень много места занимать. JSON — это текстовый формат, он не предназначен для хранения бинарных данных. Хотя, если извратиться, то можно. Но это будет не самым лучшим решением. Если же изначально хранить это в бинарном формате «заголовок, длина содержания», то таких проблем не будет.

Ты много курил? Познакомь с дилером. Речь идёт о логах. О ЛОГАХ (!!!) какие нах бинарные данные? Или ты знаешь о творении такого-же укурка-программера, которое в syslog отправляет лог в бинарном виде?

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

>(:date 2011/12/13 :pid 2000 (:msg GET 127.0.0.1 /index.html 200))

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

(:date 2011/12/13 :pid 2000 (:msg
GET 127.0.0.1 /index.html 200))

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