schors Mar 26 2013 at 18:15

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

4 min

8.1K

System administration*

+10

Comments 54

ZonD80 Mar 26 2013 at 18:27

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

schors Mar 26 2013 at 18:34

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

ZonD80 Mar 26 2013 at 18:36

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

thunderspb Mar 26 2013 at 18:41

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

schors Mar 26 2013 at 18:46

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

thunderspb Mar 27 2013 at 01:25

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

schors Mar 31 2013 at 16:30

github.com/schors/peruserlog

thunderspb Apr 1 2013 at 13:17

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

hoxnox Mar 26 2013 at 18:41

splunk?

schors Mar 26 2013 at 18:46

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

schors Mar 26 2013 at 18:52

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

ASC7_Uni Mar 26 2013 at 21:07

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

schors Mar 26 2013 at 21:11

Да

icCE Mar 26 2013 at 22:14

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

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

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

schors Mar 26 2013 at 22:20

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

icCE Mar 26 2013 at 22:26

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

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

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

schors Mar 26 2013 at 22:28

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

schors Mar 26 2013 at 22:28

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

icCE Mar 26 2013 at 22:36

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

thunderspb Mar 27 2013 at 01:27

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

icCE Mar 27 2013 at 12:12

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

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

schors Mar 27 2013 at 12:14

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

icCE Mar 27 2013 at 12:27

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

schors Mar 27 2013 at 13:35

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

icCE Mar 27 2013 at 13:41

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

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

schors Mar 27 2013 at 13:45

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

icCE Mar 27 2013 at 13:52

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

aim Mar 27 2013 at 01:24

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

thunderspb Mar 27 2013 at 01:27

Ждем :)

schors Mar 27 2013 at 02:53

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

schors Mar 31 2013 at 16:31

github.com/schors/peruserlog

ragus Mar 27 2013 at 11:05

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

schors Mar 27 2013 at 11:10

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

ragus Mar 27 2013 at 11:40

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

schors Mar 27 2013 at 11:52

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

ragus Mar 27 2013 at 11:58

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

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

schors Mar 27 2013 at 12:03

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

lol2Fast4U Mar 27 2013 at 14:11

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

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

schors Mar 27 2013 at 14:15

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

pansa Mar 27 2013 at 23:40

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

schors Mar 27 2013 at 23:43

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

pansa Mar 27 2013 at 23:46

Чем лучше?

schors Mar 28 2013 at 00:36

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

schors Mar 28 2013 at 00:57

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

ragus Mar 28 2013 at 17:16

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

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

schors Mar 29 2013 at 03:02

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

ragus Mar 29 2013 at 04:54

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

schors Mar 31 2013 at 16:31

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

pansa Mar 27 2013 at 23:59

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

schors Mar 28 2013 at 00:56

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

ragus Mar 28 2013 at 00:30

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

schors Mar 28 2013 at 00:38

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

ragus Mar 28 2013 at 01:24

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

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

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

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

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

schors Mar 28 2013 at 02:16

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

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

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

Show the best of all time