управление логами

Graylog?

спс посмотрю

файлы логов будут не файлами а fifo что бы там ничего не оставалось, сервер логов настроен на нужные папки, рекурсивно обходит их и собирает логи со всех *.log и складывает в бд с индексацией, удалением старых логов и прочей хренью, доступ к логам через веб интерфейс с кнопками для зарание заготовленных запросов и возможностью выводить логи постоянно (watch)

цену хотя бы приблизительно

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

И как мне в него добавить папку с лог файлами?

Лучше никак, выбросить и сразу писать в него.

Можно засунуть, но метаданных не будет:

systemd-cat cat file.log

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

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

syslog-ng так работает. У меня. Еще и по разным файлам раскладывает по спец. фильтрам. Еще и в программу может передавать - у меня так была настроена сигнализация пользователю о спец. событях, которые я отлавливал.

И не знаю на кой нужны fifo (хотя какой-то fifo у меня там есть), но все нормальные программы поддерживают logger интерфейс, чтобы сразу в syslog-ng передавать.

удалением старых логов

logrotate. По крайней мере для для текста (на кой вообще нужна эта база данных?)

доступ к логам через веб интерфейс с кнопками для зарание заготовленных запросов

В гугле забанили? Вот первая ссылка:
https://czanik.blogs.balabit.com/2015/12/web-interfaces-for-your-syslog-serve...

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

Что именно он умеет из коробки ? Свалить все логи в один файл ? Ну так и любой syslog так может. На какие фантазии только не идут люди, чтобы пропиарить journalctl от ненужнод. :-)

1) какой сервер логов умеет рекурсивно собирать логи из папок ?

А зачем ? Или речь про приложения, которые не умеют писать в syslog ?

Но, вроде как, у syslog-ng и file() есть, и pipe().

The syslog-ng Open Source Edition 3.7 Administrator Guide
Chapter 6. Collecting log messages — sources and source drivers

https://www.balabit.com/sites/default/files/documents/syslog-ng-ose-latest-gu...

Что именно он умеет из коробки ?

Всё это и умеет:

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

Разве что кнопки с фильтрами придётся самому прикрутить

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

find /var/log -type f -exec systemd-cat cat {} +

rsyslog+LogAnalyzer+MySQL чем-то не устроил?

Всё это и умеет:

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

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

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

Не пробовал, посмотрю

Или речь про приложения, которые не умеют писать в syslog ?

именно

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

А проприетарным балабитам с закрытым syslog-ng доверяешь? Ok

к тому же совершенно никакой кастомизации

Cудя по треду, ты journald ни разу не видел. Откуда тогда такие заявления?

Велосипед ты ведь сам выбрал с файлами, fifo и рекурсивными обходами. В дистрибутивах с systemd всё уже работает само, сервисы просто пишут (через интерфейс или stdout) в journalctl, который уже сам расправляется с логами

А проприетарным балабитам с закрытым syslog-ng доверяешь? Ok

У них закрытая только платная версия вроде

Cудя по треду, ты journald ни разу не видел. Откуда тогда такие заявления?

journald я видел, толку от него как с козла молока. Какие у него преимущества перед нормальным сервером логов + бд?

Велосипед ты ведь сам выбрал с файлами, fifo и рекурсивными обходами.

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

В дистрибутивах с systemd всё уже работает само, сервисы просто пишут (через интерфейс или stdout) в journalctl, который уже сам расправляется с логами

В идеальном мире бегают пони, какают бабочками и пишут логи в systemd

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

У них закрытая только платная версия вроде

Ну да, а из открытой намеренно выпилены фичи => обрезок

journald я видел, толку от него как с козла молока. Какие у него преимущества перед нормальным сервером логов + бд?

Я не очень понимаю что ты подразумеваешь под «сервером логов»?

journald никакой сервер не заменяет, это скорее замена syslog, это коллектор логов, который занимается хранением, поиском и удалением. Преимущества перед файлами:

• приложению не нужно заморачиваться логами, просто пишет в stdout/интерфейс, дальше «оно само». Заодно отпадают проблемы с logrotate
• унифицированный интерфейс, можно настроить что и как хранить одним способом.
• унификация выборки и фильтрации. Допустим, у тебя было какое то событие с 8 до 9 часов, как ты вытащишь из всех файлов с разным форматом времени этот интервал? А это потом в один поток надо склеить по хронологии
• метаданные, которых в текстовых файлах не может быть
• эффективное хранение, компрессия
• защита от модификации
• встроенные средства для транспорта

Вот этому всему замены нет

Теперь расскажи про сервер логов + бд, тем более нормальный. (syslog-ng и rsyslog это просто транспорты)

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

Никто ж не запрещает точно так же, из fifo в journald отправлять

Какие у него преимущества перед нормальным сервером логов + бд?

Преимущества перед файлами:...

Ты наркоман что ли?

приложению не нужно заморачиваться логами, просто пишет в stdout/интерфейс, дальше «оно само». Заодно отпадают проблемы с logrotate

Только если приложение запущено через systemd

унифицированный интерфейс, можно настроить что и как хранить одним способом.

как и везде

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

Ты базы данных видел когда нибудь?

метаданные, которых в текстовых файлах не может быть

Какие метаданные?

эффективное хранение, компрессия

Как и в любой бд

защита от модификации

как и в любой бд

встроенные средства для транспорта

как и везде

Теперь расскажи про сервер логов + бд, тем более нормальный. (syslog-ng и rsyslog это просто транспорты)

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

Никто ж не запрещает точно так же, из fifo в journald отправлять

Можно из буханки хлеба сделать троллейбус но зачем?

Только если приложение запущено через systemd

нет, есть три варианта, как минимум: syslog интерфейс, systemd-cat, fifo

Какие метаданные?

Для начала имя хоста, имя приложения, дату-время поступления, severity, facility (это всё то, о чём знает syslog: https://en.wikipedia.org/wiki/Syslog)

склеить по хронологии

Ты базы данных видел когда нибудь?

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

<эффективное хранение, компрессия
Как и в любой бд

защита от модификации

как и в любой бд

postgresql (the world's most advanced open source database), например, ни того, ни другого не умеет. Ты про какие «любые бд»? Лол, интересно посмотреть на «бд» с защитой от модификации (нет, это не разграничение пользователей, https://lwn.net/Articles/512895/)

Теперь расскажи про сервер логов + бд

Нет

Что нет то? Я действительно не понимаю, с чем ты пытаешься его сравнить. Какие-то мифические «бд», которые нельзя называть?

в journald проставить индексы

Никак, journald не база данных

Можно из буханки хлеба сделать троллейбус но зачем?

Давай конкретные имена альтернатив, как ты это решишь без костылей?

перед нормальным сервером логов + бд

Для указанных в шапке требований не нужен «сервер логов + бд». Судя по тому, что ты пишешь, тебе действительно хватит этого самого journald (который с высокой вероятностью у тебя уже установлен).

Если он тебе на самом деле не подходит (по объективным причинам, а не по религиозным), то уточни свои требования.

Для начала имя хоста, имя приложения, дату-время поступления, severity, facility (это всё то, о чём знает syslog: https://en.wikipedia.org/wiki/Syslog)

Круто но у меня файлы

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

магия

select '2015-10-02 00:23:32 +0300'::timestamp with time zone;
      timestamptz       
------------------------
 2015-10-02 00:23:32+03

postgresql (the world's most advanced open source database), например, ни того, ни другого не умеет.

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

Что нет то? Я действительно не понимаю, с чем ты пытаешься его сравнить. Какие-то мифические «бд», которые нельзя называть?

любые бд

Давай конкретные имена альтернатив, как ты это решишь без костылей?

Вон выше написали что syslog-ng умеет в рекурсивный обход директории, еще не успел проверить. Ну и так вообще в любом случае такие вещи принято через конфиги указывать а не как в journald команду отдельную запускать.

Для указанных в шапке требований не нужен «сервер логов + бд». Судя по тому, что ты пишешь, тебе действительно хватит этого самого journald (который с высокой вероятностью у тебя уже установлен).

Там всего одно требование «рекурсивный сбор логов из файлов в директории и поддиректориях» и journald этого не умеет.

Если он тебе на самом деле не подходит (по объективным причинам, а не по религиозным), то уточни свои требования.

Судя по треду сообщество journald не совсем адекватно, для меня это минус.

Там всего одно требование «рекурсивный сбор логов из файлов в директории и поддиректориях» и journald этого не умеет.

Я же специально отметил — объективные причины, а не религиозные. Рекурсивный сбор логфайлов в журнал пишется на шелле за значительно меньшее время, чем ты будешь разбираться с «сервером логов + бд».

Судя по треду сообщество journald не совсем адекватно

xkcd://Extrapolating

Я же специально отметил — объективные причины, а не религиозные. Рекурсивный сбор логфайлов в журнал пишется на шелле за значительно меньшее время, чем ты будешь разбираться с «сервером логов + бд».

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

магия
select '2015-10-02 00:23:32 +0300'::timestamp with time zone;

А теперь то же самое, только с настоящей строкой из лога. Например вот дефолтный access лог nginx:

1.2.3.4 - - [10/Apr/2016:06:51:14 +0300] "GET /test HTTP/1.1" 301 155 "-" "Mozilla/5.0 (UA)"

модифицировать их ни кто не собирается

Точно, они никому не нужны => проблема решена

Проблема компрессии в моем случае решается удалением старых логов.

Отличное решение проблемы! Хранить данные за 1 месяц, когда с тупым gzip можно было бы хранить за 10 месяцев. А еще у postgres минимум 40 байт оверхеда на запись, так что данных влезет еще меньше

syslog-ng и реляционная СУБД чтобы хранить месяц логов с локалхоста, или данные за 10 месяцев в встроенном стандартном хранилище с метаданными, что же выбрать?

А теперь то же самое, только с настоящей строкой из лога.

# select '10/Apr/2016:06:51:14 +0300'::timestamp with time zone;
      timestamptz       
------------------------
 2016-04-10 06:51:14+03
(1 row)

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

Точно, они никому не нужны => проблема решена

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

Отличное решение проблемы! Хранить данные за 1 месяц, когда с тупым gzip можно было бы хранить за 10 месяцев.

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

что же выбрать?

то что лучше подходит для решения конкретной проблемы.

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

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

select ... from (select '1.2.3.4 - - [10/Apr/2016:06:51:14 +0300] "GET /test HTTP/1.1" 301 155 "-" "Mozilla/5.0 (UA)"') foo;

ни кому не нужны
мне не нужны логи за 10 месяцев

«мне не нужны все возможности системного механизма хранения логов, поэтому я сбоку прикручу РСУБД и положу в неё логи»

Ok

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

Реально думаешь что только journald умеет парсить логи по образцу? Но в общем то и средствами базы решать такие задачи не проблема.

postgres=# select substring('1.2.3.4 - - [10/Apr/2016:06:51:14 +0300] "GET /test HTTP/1.1" 301 155 "-" "Mozilla/5.0 (UA)"' from '\[(.*)\]')::timestamp with time zone;
       substring        
------------------------
 2016-04-10 06:51:14+03
(1 row)

«мне не нужны все возможности системного механизма хранения логов, поэтому я сбоку прикручу РСУБД и положу в неё логи»

Те возможности которые мне нужны в journald нету. А костылять их скриптами ради возможностей journald которые мне не нужны это мягко говоря глупо, ты не согласен?