Comments 54
Отлично! А где, собственно, программа?
+4
А надо? Все косяки и особенности я описал. А парсинг логов специфических программ — оно надо кому-то? Если реально интересно — я могу подрихтовать кода и выложить. Но уж очень специфичная вещь.
+1
Конечно надо, вдруг кто-то захочет это использовать как standalone-решение, сделайте планин-архитектуру, чтобы можно было добавлять свои парсеры, например.
0
Ради развития было бы полезно.
0
Здорово. На ваших серверах это уже работает, ведь так?
0
У меня то же была задача, читать логи и делать определенные вещи. Думал про tail, но понимал, что как то оно не то :)
В итоге все логи плавно завернул в БД — mysql как вариант.
вместо syslog — rsyslog.
Далее уже логи в БД — а там делаем все, что угодно.
В итоге все логи плавно завернул в БД — mysql как вариант.
вместо syslog — rsyslog.
Далее уже логи в БД — а там делаем все, что угодно.
0
1. БД сдохнет на логах шареда
2. А интерактивность для пользователя? Логами часто для отладки ползуются.
3. Это не решает проблемы «как логи сканировать»
2. А интерактивность для пользователя? Логами часто для отладки ползуются.
3. Это не решает проблемы «как логи сканировать»
0
2) Можно писать как в БД так и оставить стандартные логи для пользователя.
3) Не решает, но сканировать как по мне проще.
1 пунк очень спорный, очень много сразу возникает вопросов. Да и БД они то же разные.
Но ссылку на GitHub ждем :)
3) Не решает, но сканировать как по мне проще.
1 пунк очень спорный, очень много сразу возникает вопросов. Да и БД они то же разные.
Но ссылку на GitHub ждем :)
0
Ну зависит от проекта же. Когда логов в день на несколько гигабайт, то держать отдельную ферму БД-серверов будет накладно же.
0
Когда логов в день несколько гигабайт, держать отдельно сервер логирование — это вообще самое разумное решение! У меня вообще привычка держать как минимум дублирование для систем логирования.
На текущий момент у меня лично стоит задача обрабатывать и хранить объемные логи. Пока тесты на кластаре с mysql будут, дальше будем смотреть.
На текущий момент у меня лично стоит задача обрабатывать и хранить объемные логи. Пока тесты на кластаре с mysql будут, дальше будем смотреть.
0
Вспоминая тётку Немет: «Сложный путь решения не существующей проблемы» ©
0
Главное правило линуксоида
xxx: Если есть два способа, простой и сложный, то выбирай сложный, так как он проще простого способа, который тоже сложный, но ещё и кривой
xxx: Если есть два способа, простой и сложный, то выбирай сложный, так как он проще простого способа, который тоже сложный, но ещё и кривой
0
Хехе :) Вот за это я линукс и не люблю, и не использую :))
0
Если не предератся к деталям, одного поля ягоды.
Хотя конечно соглашусь, метод жизненый. Я сейчас прикинул как будет себя чуствовать БД с 21326438 строк за 2 дня :)
И это только по 1 сервису. Буду думать.
Хотя конечно соглашусь, метод жизненый. Я сейчас прикинул как будет себя чуствовать БД с 21326438 строк за 2 дня :)
И это только по 1 сервису. Буду думать.
0
Главное — в чём смысл? Разложить по файликам, по хостам, по сервисам, по дням, если угодно — по часам. И всё.
0
в конце статьи напрашивается ссылка на гитхаб…
0
Ждем :)
0
Да не напрашивается, Эйм. Это специфичный скрипт, в котором 80% кода это перловые регекспы строк логов программ, которые 90% читателей не используют и использовать никогда не будут. Остальные 10% это простые задачки на 3 строки из бумажного кукбука и конфиги специфичные для конкретного хостинга. Не, я не против, но мне сейчас придётся сесть и превратить его в общий вид с результатом «удовлетворил публику». Сделаю, но это бессмысленно. Всё на что надо обратить внимание, я обратил. Когда ты станешь сотрудником OpenSSH ты вспомнишь мою статью и влепишь туда идентификатор сессии и uid после аутентификации ;)
0
Очень странное ощущение после прочтения.
Филипп, а смысл играть в догонялки с системой, бороться с логротацией вместо того чтобы не взять syslog-ng?
Филипп, а смысл играть в догонялки с системой, бороться с логротацией вместо того чтобы не взять syslog-ng?
0
А чем мне в описываемой задаче поможет syslog-ng?
0
судя по статье+комментам, нетленочка состоит из неслабого набора регекспов, так?
в syslog-ng определяешь источники логов(сокеты, пайпы, проч-проч...), фильтры(там в том числе есть регекспы) и цели(куда логи класть. это к пользователю в ~ ). а дальше понесласть любая разумная комбинация фильтров(выделил ssh в отдельный стрим, потом раскидал это per user).
в syslog-ng определяешь источники логов(сокеты, пайпы, проч-проч...), фильтры(там в том числе есть регекспы) и цели(куда логи класть. это к пользователю в ~ ). а дальше понесласть любая разумная комбинация фильтров(выделил ssh в отдельный стрим, потом раскидал это per user).
+1
Про источники в описаниях сходу не нашёл, но верю. Это всё очень хорошо, но «нельзя просто взять и отгрепать лог по пользователю». Это один из основных моментов — кроме cron все остальные приходится «вести». Например самый простой случай — sendmail. Он говорит какой юзер отсылает письмо утилиткой, но если письмо сразу не ушло дальше и попало в очередь, то для разборщика очереди пользователь уже неизвестен, надо вспоминать, какой он был у этого идентификатора очереди. Самое сложное с ssh — коннект естественно не подписан, строки ключей и аутентификации с коннектом можно связать только следя за pid, потом он ещё и форкается меняя pid — надо тоже отслеживать. Если бы было можно просто фильтр натравить, то всё было бы очень просто.
0
что мешает полуфабрикат выплюнуть в named pipe, обработать в своём демоне и обратно отдать в syslog-ng?
вполне себе unix-way.
вполне себе unix-way.
0
«не все программы умеют работать с системой syslog»
А зачем это внутри самих программ? Программы должны тупо писать в stdout.
Запускаем как «someserverd | logger» и все пишется в syslog.
А зачем это внутри самих программ? Программы должны тупо писать в stdout.
Запускаем как «someserverd | logger» и все пишется в syslog.
0
Мне кажется, или вы что-то перемудрили с отслеживанием переименования, переоткрытия файлов и крутилки?
Если вы сделали open файла в процессе «раскладывалки», то и читайте его, пока он пополняется. До тех пор, пока ваш хэндл не будет закрыт, другие процессы могут хоть переименвывать, хоть удалять этот файл — для вашего процесса это никак не скажется.
Или я не так понял проблему.
Если вы сделали open файла в процессе «раскладывалки», то и читайте его, пока он пополняется. До тех пор, пока ваш хэндл не будет закрыт, другие процессы могут хоть переименвывать, хоть удалять этот файл — для вашего процесса это никак не скажется.
Или я не так понял проблему.
0
Ну честно говоря, лучше конечно отслеживать, открыт ли он для кого-то на запись.
0
Чем лучше?
0
Потому что мне надо читать свежие логи? Мне не интересно висеть на файле, в который уже не пишут. Сейчас сделано проверкой переименования. Это не совсем верно, да, но в общем случае работает.
0
Хотя я вот сходу не знаю как простым способом посмотреть, сколько процессов держит открытым файл на запись. Кроме как fstat ничего не приходит в голову.
0
я ещё вчера упоминал kevent.
benno.id.au/blog/2008/05/15/simplefilemon
forums.freebsd.org/showthread.php?t=25547
benno.id.au/blog/2008/05/15/simplefilemon
forums.freebsd.org/showthread.php?t=25547
0
Хотя, простите, прочитал ваше «Хехе :) Вот за это я линукс и не люблю, и не использую :)) ». Могу ошибаться, но у меня складывается впечатление, что вы просто «не умеете его готовить». Ну и не понимаете, как работают базовые функции ядра с VFS, уж простите за прямоту.
0
кстати, про механизм отслеживания ничего не сказано. kevent?
0
Простой цикл чтения из Perl Cookbook с задержкой в 0.1 секунду и снятием EOF.
0
зря. очень зря.
если бы у меня была аналогичная задача, то:
1)с помощью фильтров syslog-ng из разных источников формируем поток событий и передаём их нашему демону
2)демон хранит в памяти N последних событий(допустим, 1000), имеет правила по корелляции событий + каждое правило заканчивается цепочкой действий(дропнуть, логировать в syslog-ng со соотв. префиксом и проч-проч).
3)syslog-ng раскидывает это по пользователям.
в этой схеме не надо следить за файлами и бороться с ротацией логов. вместо этого можно спокойно концентрироваться на логике(и оперировать событиями, а лог-файлами). если правила просто захардкодить, то получится твой же вариант, только проще.
я бы ещё подумал об AUDIT.
если бы у меня была аналогичная задача, то:
1)с помощью фильтров syslog-ng из разных источников формируем поток событий и передаём их нашему демону
2)демон хранит в памяти N последних событий(допустим, 1000), имеет правила по корелляции событий + каждое правило заканчивается цепочкой действий(дропнуть, логировать в syslog-ng со соотв. префиксом и проч-проч).
3)syslog-ng раскидывает это по пользователям.
в этой схеме не надо следить за файлами и бороться с ротацией логов. вместо этого можно спокойно концентрироваться на логике(и оперировать событиями, а лог-файлами). если правила просто захардкодить, то получится твой же вариант, только проще.
я бы ещё подумал об AUDIT.
0
в чём смысл этого огорода, если скрипт простым способом делает то, что делает syslog-ng? это имело бы смысл, если бы syslog-ng был в системе. тогда да — двумя задачами меньше. а так — ротация логов вообще проблем не вызвала — закрыли, открыли. ну вот разве что чтение источника до сих пор теоретически неточное — я не проверяю после переименования, пишет ли туда ещё кто. не уверен, кстати, что syslog-ng проверяет )
кстати, почему 1000? у меня хранит до срабатывания автомата или до чистки раз в сколько-то по явно не сработавшим (я проверял — обычно это когда я невовремя лог переключаю при ротации). а 1000 это что? цифра с неба? смысл?
о да, разбирать AUDIT на шареде — это то, о чём я мечтал :) нет смысла
кстати, почему 1000? у меня хранит до срабатывания автомата или до чистки раз в сколько-то по явно не сработавшим (я проверял — обычно это когда я невовремя лог переключаю при ротации). а 1000 это что? цифра с неба? смысл?
о да, разбирать AUDIT на шареде — это то, о чём я мечтал :) нет смысла
0
Sign up to leave a comment.
Журналы сервисов — пользователям