Журналы сервисов — пользователям

[@ZonD80]

Отлично! А где, собственно, программа?

[@schors]

А надо? Все косяки и особенности я описал. А парсинг логов специфических программ — оно надо кому-то? Если реально интересно — я могу подрихтовать кода и выложить. Но уж очень специфичная вещь.

[@ZonD80]

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

[@thunderspb]

Ради развития было бы полезно.

[@schors]

Тогда чуть позже на github закину версию с вырезанными матерными словами.

[@thunderspb]

Ок, будем подождать)

[@schors]

github.com/schors/peruserlog

[@thunderspb]

Спасибо, будем учиться. Плюс не могу — кармы нет(

[@hoxnox]

splunk?

[@schors]

Нет, это вообще не о том. «О том» была бы статья как кто-то написал на языке этого спланка такой парсер. С возвратом логов обратно пользователю на сервер :)

[@schors]

И я не увидел там ни одной строчки «писатели OpenSSH, вы — ослы». А у меня это чуть ли не основное, что я хотел донести.

[@ASC7_Uni]

Здорово. На ваших серверах это уже работает, ведь так?

[@schors]

Да

[@icCE]

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

В итоге все логи плавно завернул в БД — mysql как вариант.
вместо syslog — rsyslog.

Далее уже логи в БД — а там делаем все, что угодно.

[@schors]

1. БД сдохнет на логах шареда
2. А интерактивность для пользователя? Логами часто для отладки ползуются.
3. Это не решает проблемы «как логи сканировать»

[@icCE]

2) Можно писать как в БД так и оставить стандартные логи для пользователя.
3) Не решает, но сканировать как по мне проще.

1 пунк очень спорный, очень много сразу возникает вопросов. Да и БД они то же разные.

Но ссылку на GitHub ждем :)

[@schors]

И основным пунктом было не где хранить, а как распарсить и показать пользователю :)

[@schors]

И как вообще собрать

[@icCE]

Оно понятно. Просто я немного ушел дальше, хотя конечно первая мысль было про tail :D
Показать уже можно было через web интерфейс, да и добавить в некую админку для администратора.
Хотя конечно это более долгий и сложный путь. Возможно да же не нужный.

[@thunderspb]

Ну зависит от проекта же. Когда логов в день на несколько гигабайт, то держать отдельную ферму БД-серверов будет накладно же.

[@icCE]

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

На текущий момент у меня лично стоит задача обрабатывать и хранить объемные логи. Пока тесты на кластаре с mysql будут, дальше будем смотреть.

[@schors]

Вспоминая тётку Немет: «Сложный путь решения не существующей проблемы» ©

[@icCE]

Главное правило линуксоида
xxx: Если есть два способа, простой и сложный, то выбирай сложный, так как он проще простого способа, который тоже сложный, но ещё и кривой

[@schors]

Хехе :) Вот за это я линукс и не люблю, и не использую :))

[@icCE]

Если не предератся к деталям, одного поля ягоды.

Хотя конечно соглашусь, метод жизненый. Я сейчас прикинул как будет себя чуствовать БД с 21326438 строк за 2 дня :)
И это только по 1 сервису. Буду думать.

[@schors]

Главное — в чём смысл? Разложить по файликам, по хостам, по сервисам, по дням, если угодно — по часам. И всё.

[@icCE]

ну у меня это единственный файл логов, которая генерирует 1 программа. Размер файла за 1 день вырастает до 600 метров, а это еще не боевая система, просто тесты.
Задача собрать некую статистику и обрабатывать в разных вариациях.

[@aim]

в конце статьи напрашивается ссылка на гитхаб…

[@thunderspb]

Ждем :)

[@schors]

Да не напрашивается, Эйм. Это специфичный скрипт, в котором 80% кода это перловые регекспы строк логов программ, которые 90% читателей не используют и использовать никогда не будут. Остальные 10% это простые задачки на 3 строки из бумажного кукбука и конфиги специфичные для конкретного хостинга. Не, я не против, но мне сейчас придётся сесть и превратить его в общий вид с результатом «удовлетворил публику». Сделаю, но это бессмысленно. Всё на что надо обратить внимание, я обратил. Когда ты станешь сотрудником OpenSSH ты вспомнишь мою статью и влепишь туда идентификатор сессии и uid после аутентификации ;)

[@schors]

github.com/schors/peruserlog

[@ragus]

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

[@schors]

А чем мне в описываемой задаче поможет syslog-ng?

[@ragus]

судя по статье+комментам, нетленочка состоит из неслабого набора регекспов, так?
в syslog-ng определяешь источники логов(сокеты, пайпы, проч-проч...), фильтры(там в том числе есть регекспы) и цели(куда логи класть. это к пользователю в ~ ). а дальше понесласть любая разумная комбинация фильтров(выделил ssh в отдельный стрим, потом раскидал это per user).

[@schors]

Про источники в описаниях сходу не нашёл, но верю. Это всё очень хорошо, но «нельзя просто взять и отгрепать лог по пользователю». Это один из основных моментов — кроме cron все остальные приходится «вести». Например самый простой случай — sendmail. Он говорит какой юзер отсылает письмо утилиткой, но если письмо сразу не ушло дальше и попало в очередь, то для разборщика очереди пользователь уже неизвестен, надо вспоминать, какой он был у этого идентификатора очереди. Самое сложное с ssh — коннект естественно не подписан, строки ключей и аутентификации с коннектом можно связать только следя за pid, потом он ещё и форкается меняя pid — надо тоже отслеживать. Если бы было можно просто фильтр натравить, то всё было бы очень просто.

[@ragus]

что мешает полуфабрикат выплюнуть в named pipe, обработать в своём демоне и обратно отдать в syslog-ng?

вполне себе unix-way.

[@schors]

Да. Но я при виде этой цепочке начал терять смысл затеи с syslog-ng. Если бы он уже был — это одно, можно подумать и повзвешивать. А так его тоже ставить, а толку с него — он просто возьмёт часть функций моего скрипта на себя. Причём, самую простую часть.

[@lol2Fast4U]

«не все программы умеют работать с системой syslog»

А зачем это внутри самих программ? Программы должны тупо писать в stdout.
Запускаем как «someserverd | logger» и все пишется в syslog.

[@schors]

1. Вариант
2. Причём плохой вариант — лишняя точка смены контекста
3. Не умеют :)

[@pansa]

Мне кажется, или вы что-то перемудрили с отслеживанием переименования, переоткрытия файлов и крутилки?
Если вы сделали open файла в процессе «раскладывалки», то и читайте его, пока он пополняется. До тех пор, пока ваш хэндл не будет закрыт, другие процессы могут хоть переименвывать, хоть удалять этот файл — для вашего процесса это никак не скажется.
Или я не так понял проблему.

[@schors]

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

[@pansa]

Чем лучше?

[@schors]

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

[@schors]

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

[@ragus]

я ещё вчера упоминал kevent.

benno.id.au/blog/2008/05/15/simplefilemon
forums.freebsd.org/showthread.php?t=25547

[@schors]

kevant это немножко не то. меня интересует счётчик обращений к файлу (есть такое, не могу найти как по аглицки называется)

[@ragus]

стартуешь с системой, считаешь обращения к файлу. всё придумано до нас ;)

[@schors]

Это не тот млять счётчик :))) Термин есть такое не имеющий отношения к тыканию файла.

[@pansa]

Хотя, простите, прочитал ваше «Хехе :) Вот за это я линукс и не люблю, и не использую :)) ». Могу ошибаться, но у меня складывается впечатление, что вы просто «не умеете его готовить». Ну и не понимаете, как работают базовые функции ядра с VFS, уж простите за прямоту.

[@schors]

Это был троллинг, я бсдюк.

[@ragus]

кстати, про механизм отслеживания ничего не сказано. kevent?

[@schors]

Простой цикл чтения из Perl Cookbook с задержкой в 0.1 секунду и снятием EOF.

[@ragus]

зря. очень зря.

если бы у меня была аналогичная задача, то:

1)с помощью фильтров syslog-ng из разных источников формируем поток событий и передаём их нашему демону
2)демон хранит в памяти N последних событий(допустим, 1000), имеет правила по корелляции событий + каждое правило заканчивается цепочкой действий(дропнуть, логировать в syslog-ng со соотв. префиксом и проч-проч).
3)syslog-ng раскидывает это по пользователям.

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

я бы ещё подумал об AUDIT.

[@schors]

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

кстати, почему 1000? у меня хранит до срабатывания автомата или до чистки раз в сколько-то по явно не сработавшим (я проверял — обычно это когда я невовремя лог переключаю при ротации). а 1000 это что? цифра с неба? смысл?

о да, разбирать AUDIT на шареде — это то, о чём я мечтал :) нет смысла