LINUX.ORG.RU
ФорумAdmin

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

 ,


0

1

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

теперь вопросы:

1) какой сервер логов умеет рекурсивно собирать логи из папок? вроде как syslog-ng но в премиум версии и на сайте ни где нету цены, предлагают написать их менеджерам. мне все это надо не для сервера, а просто для своего компа на котором работаю, кто нибудь в курсе какую я там могу услышать цену хотя бы приблизительно? Ну или может другой какой сервер есть который и папки рекурсивно обходить умеет и в базу все складывать.

2) веб интерфейс для логов из базы, че то вообще ничего не нагуглил внятного, а писать самому очень не хочется.

★★★★★

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

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

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

disarmer ★★★
()

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

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

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

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

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

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

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

Kroz ★★★★★
()
Последнее исправление: Kroz (всего исправлений: 3)
Ответ на: комментарий от disarmer

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

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

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)

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...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

именно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

как и везде

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

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

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

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

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

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

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

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

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

как и везде

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

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

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

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

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

Только если приложение запущено через 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 не база данных

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

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

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

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

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от disarmer

Для начала имя хоста, имя приложения, дату-время поступления, 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 команду отдельную запускать.

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

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

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

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

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

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

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

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

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

xkcd://Extrapolating

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

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

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

магия
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 месяцев в встроенном стандартном хранилище с метаданными, что же выбрать?

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

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

# 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 месяцев, не существует ситуации при которой они мне могут понадобиться.

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

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

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

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

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

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

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

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

Реально думаешь что только 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 которые мне не нужны это мягко говоря глупо, ты не согласен?

TDrive ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.