Главная » Форум » Gentoo Linux » Системное администрирование

Loggers (syslog-ng, rsyslog and etc)

HolyBoy 9 января, 2009 - 09:47

Добрый день.

Кто какие логгеры использует на серверах?

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

rsyslog умеет всё, что умеет syslog-ng и чуточку больше: записи в разных файлах не повторяются, можно задавать нужный формат логов, писать в базу данных и тд и тп, но для amd64 нестабилен, зараза. Т.е. после определённого времени работы крешится.

Кто может что посоветовать на тему допиливания syslog-ng или иной другой логгер, одинаково хороший как для x86, так и для amd64?

‹ Доступ нескольких пользователей к одной папке фтп Как отключить PIE+SSP/SElinux/grsec/PAX [напостил об этом в другой ветке - здесь прошу удалить] ›
»

я почти всегда использовал

Автор evadim, дата создания 9 января, 2009 - 11:19.

я почти всегда использовал metalog, он идёт уже более-менее настроеный и со своим logrotate. всё бы хорошо, но с русским в UTF есть проблемы, сообщения плохо читаются... если на сервере локаль не русская (а зачем она там) то можно попробовать.

»

Я пробовал metalog, но он не

Автор HolyBoy, дата создания 9 января, 2009 - 13:30.

Я пробовал metalog, но он не очень понравился мне. Для меня средства ротирования логов не очень важны, т.к. есть logrotate.

»

Давайте пофлеймим :)

Автор Anarchist, дата создания 11 января, 2009 - 11:56.
HolyBoy написал(а):
syslog-ng (x86, amd64) работает стабильно, но раздражают его небогатые возможности, типа неумения создать папку с логами, неумения отфильтровывать логи так, чтобы не дублировать записи в разных файлах, не умеет менять формат выводимых логов.

Как раз фильтры syslog-ng меня очччень порадовали.
Поэтому предлагаю рассмотреть предметно: что и как разносим. Могу поделиться своей конфигурацией для случая разруливания логов почты.

Изменение формата выводимых логов: что имеется в виду? Мне почему-то кажется, что это - не является задачей логгера.

Создание каталога с логами? Опять же: при чём здесь syslog-ng??? При ротации средствами logrotate - видится вполне реальным. Хотя лично я такой задачи не решал.

HolyBoy написал(а):
rsyslog умеет всё, что умеет syslog-ng и чуточку больше: записи в разных файлах не повторяются, можно задавать нужный формат логов, писать в базу данных и тд и тп, но для amd64 нестабилен, зараза. Т.е. после определённого времени работы крешится.

Мн глючится, или syslog-ng тоже умеет работать с СУБД (вопрос: зачем приплетать СУБД к механизму логирования пока оставим в стороне, но он сам по себе является поводом для великоленого флейма)?..

—

:wq
--
Live free or die

»

Ну давай. :P

Автор HolyBoy, дата создания 11 января, 2009 - 12:25.

К самим фильтрам syslog-ng у меня претензий нет.

Разговор немного о другом. Вот, возьмем, к примеру, логи фаерволла. В iptables создаем цепочку вида

iptables -N DROP1 2> /dev/null                                                                                                                  
iptables -A DROP1 -j LOG --log-prefix 'DROP1:'                                                                                                  
iptables -A DROP1 -j DROP

и все дропнутые пакеты, к которым мы применим это, будут помечены DROP1. Казалось бы, всё хорошо, но…

Если логировать syslog-ng, то это выглядит как:

(здесь кусок из конфига)

destination kern { file("/var/log/system/kern.log"); };
destination fw_blocked { file("/var/log/firewall/block.log"); };

filter f_kern { facility(kern); };
filter f_fwblocked { match("DROP1"); };

log { source(src); filter(f_fwblocked); destination(fw_blocked); };

и тут возникает проблема: логи дропнутых пакетов попадают не только в файл /var/log/firewall/block.log, но и в /var/log/system/kern.log, безбожно засоряя его. А почему? Да вот почему:

Jan 11 11:12:03 gate kernel: DROP1:IN=eth1 OUT= MAC=anyone:mac SRC=192.168.1.32 DST=192.168.1.255 LEN=229 TOS=0x00 PREC=0x00 TTL=128 ID=46390 PROTO=UDP SPT=138 DPT=138 LEN=209

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

Аналогичная задача в rsyslog решается так:

:msg, contains, "DROP1"                 /var/log/firewall/drop.log;RSYSLOG_TraditionalFileFormat                                            
& ~

kern.*                  /var/log/kernel;RSYSLOG_TraditionalFileFormat                                                                       
& ~

Всё.
Сообщения, содержащие DROP1 попадут в /var/log/firewall/drop.log и больше никуда. Всё прочее, относящееся к ядру — в /var/log/kernel.

По поводу использования БД для хранения логов — это выгодно для случаев, когда делается один сервер для централизованного хранения и обработки данных с нескольких(!) серверов. Во всех остальных, ИМХО, обычного текстового файла достаточно. Это ИМХО я вынес из собственноручных тестов. :)

syslog-ng умеет работать с БД, но делает это через сторонние либы. rsyslog делает это нативно. Вот, тут сравнение можно глянуть: http://www.rsyslog.com/doc-rsyslog_ng_comparison.html

»

.

Автор Anarchist, дата создания 11 января, 2009 - 14:14.
HolyBoy написал(а):
Разговор немного о другом.

Так понятнее.

HolyBoy написал(а):
Вот, возьмем, к примеру, логи фаерволла. В iptables создаем цепочку вида

iptables -N DROP1 2> /dev/null                                                                                                                  
iptables -A DROP1 -j LOG --log-prefix 'DROP1:'                                                                                                  
iptables -A DROP1 -j DROP

и все дропнутые пакеты, к которым мы применим это, будут помечены DROP1. Казалось бы, всё хорошо, но…

Если логировать syslog-ng, то это выглядит как:

(здесь кусок из конфига)

destination kern { file("/var/log/system/kern.log"); };
destination fw_blocked { file("/var/log/firewall/block.log"); };

filter f_kern { facility(kern); };
filter f_fwblocked { match("DROP1"); };

log { source(src); filter(f_fwblocked); destination(fw_blocked); };

и тут возникает проблема: логи дропнутых пакетов попадают не только в файл /var/log/firewall/block.log, но и в /var/log/system/kern.log, безбожно засоряя его. А почему?

Можно не продолжать.
Ты выделил сообщения файрволла в отдельный файл, но не изменил настройки kern.log. А (в рамках сформулированной тобой задачи) надо было бы.

HolyBoy написал(а):
Аналогичная задача в rsyslog решается так:

:msg, contains, "DROP1"                 /var/log/firewall/drop.log;RSYSLOG_TraditionalFileFormat                                            
& ~

kern.*                  /var/log/kernel;RSYSLOG_TraditionalFileFormat                                                                       
& ~

Всё.
Сообщения, содержащие DROP1 попадут в /var/log/firewall/drop.log и больше никуда. Всё прочее, относящееся к ядру — в /var/log/kernel.

Та же задача в случае использования syslog-ng решается исправлением filter f_kern { facility(kern); }; на filter f_kern { facility(kern) and not match("DROP1"); };
ИМХО - логичнее некуда.

HolyBoy написал(а):
По поводу использования БД для хранения логов — это выгодно для случаев, когда делается один сервер для централизованного хранения и обработки данных с нескольких(!) серверов.

Оно понятно.
Интереснее: в каких случаях это обоснованно и чем расплчиваешься.

HolyBoy написал(а):
syslog-ng умеет работать с БД, но делает это через сторонние либы. rsyslog делает это нативно.

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

—

:wq
--
Live free or die

»

..

Автор HolyBoy, дата создания 11 января, 2009 - 15:35.
Anarchist написал(а):
Можно не продолжать.
Ты выделил сообщения файрволла в отдельный файл, но не изменил настройки kern.log. А (в рамках сформулированной тобой задачи) надо было бы.

Ага. Знать бы как.

Anarchist написал(а):
Та же задача в случае использования syslog-ng решается исправлением filter f_kern { facility(kern); }; на filter f_kern { facility(kern) and not match("DROP1"); };
ИМХО - логичнее некуда.

Ты мне подсказываешь: вот так. Ок. Я бы не сказал, что логика работы фильтра syslog-ng очевидна, особенно, если надо много условий задавать. Например, вот полностью часть конфига rsyslog, в которой ясно видно, что куда валится: 

*.*         /dev/tty12;RSYSLOG_TraditionalFileFormat                                                                                        
                                                                                                                                            
                                                                                                                                            
                                                                                                                                            
#iptables                                                                                                                                   
:msg, contains, "DROP1"                 /var/log/firewall/drop.log;RSYSLOG_TraditionalFileFormat                                            
& ~                                                                                                                                         
:msg, contains, "REJECT1"                       /var/log/firewall/reject.log;RSYSLOG_TraditionalFileFormat                                  
& ~                                                                                                                                         
                                                                                                                                            
kern.*                  /var/log/kernel;RSYSLOG_TraditionalFileFormat                                                                       
& ~                                                                                                                                         
                                                                                                                                            
                                                                                                                                            
:programname, isequal, "upsmon"                         /var/log/ups/upsmon.log;RSYSLOG_TraditionalFileFormat                               
& ~                                                                                                                                         
:programname, isequal, "upsd"                   /var/log/ups/upsd.log;RSYSLOG_TraditionalFileFormat                                         
& ~                                                                                                                                         
:programname, isequal, "megatec"                        /var/log/ups/upsdriver.log;RSYSLOG_TraditionalFileFormat                            
& ~                                                                                                                                         
                                                                                                                                            
                                                                                                                                            
:programname, isequal, "openvpn"                        /var/log/openvpn.log;RSYSLOG_TraditionalFileFormat                                  
& ~                                                                                                                                         
                                                                                                                                            
:programname, isequal, "freshclam"                      /var/log/clamav/freshclam.log;RSYSLOG_TraditionalFileFormat                         
& ~                                                                                                                                         
:programname, isequal, "clamd"                  /var/log/clamav/clamd.log;RSYSLOG_TraditionalFileFormat                                     
& ~                                                                                                                                         
:programname, isequal, "MailScanner"                    /var/log/mailscanner.log;RSYSLOG_TraditionalFileFormat                              
& ~
*.info;mail.none;authpriv.none;cron.none                        /var/log/messages;RSYSLOG_TraditionalFileFormat                             
& ~                                                                                                                                         
                                                                                                                                            
auth,authpriv.*                 /var/log/secure.log;RSYSLOG_TraditionalFileFormat                                                           
& ~                                                                                                                                         
                                                                                                                                            
mail.*                  /var/log/mail.log;RSYSLOG_TraditionalFileFormat                                                                     
& ~                                                                                                                                         
                                                                                                                                            
cron.*                  /var/log/cron;RSYSLOG_TraditionalFileFormat                                                                         
& ~                                                                                                                                         
                                                                                                                                            
daemon.*                        /var/log/daemon;RSYSLOG_TraditionalFileFormat                                                               
& ~                                                                                                                                         
                                                                                                                                            
user.*                  /var/log/user.log;RSYSLOG_TraditionalFileFormat                                                                     
& ~
                                                                                                                                            
#Display using wall to all logged in users                                                                                                  
*.emerg *                                                                                                                                   
& ~                                                                                                                                         
                                                                                                                                            
uucp,news.crit                  /var/log/spooler;RSYSLOG_TraditionalFileFormat                                                              
& ~                                                                                                                                         
                                                                                                                                            
#Finally log everything else                                                                                                                
*.*                     /var/log/uncategorized.log;RSYSLOG_TraditionalFileFormat

Из приятных мелочей здесь можно отметить не только работу с сообщением по содержанию (msg, contains = match), но и обработку имени программы programname, isequal (чего в syslog-ng не встретил сходу).

Anarchist написал(а):
Оно понятно.
Интереснее: в каких случаях это обоснованно и чем расплчиваешься.

Обоснованно в случаях, когда у тебя работает монитор, обрабатывающий статистику каждые, скажем, 10 минут. в таких случаях оптимальнее использовать запрос, который выдернет данные только за определённый период, не парся весь несколькосотмегабайтный файл. Расплата за использование БД только одна (при условии, что у нас выделена отдельная машина сбора логов в БД или в текстовые файлы): невозможность онлайн отслеживать и отлаживать программу, т.к. все данные надо предварительно запросить. Здесь, конечно, надо использовать вывод в текстовый файл и весь инструментарий для работы с ним: tail, grep, less, sed, awk и тд и тп.
В обработке статистики БД намного превосходит по скорости текстовые файлы. Точные данные не проси. Я это мерял давно и цифр не записал.

Anarchist написал(а):
И чем использование дополнительных библиотек (минус лишний код в случае, когда фича не используется) хуже?

Здесь я сходу не отвечу. Знаю, что в rsyslog для работы с БД используются собственные подключаемые модули или libdbi, тогда как syslog-ng только с libdbi работает. Осмелюсь предположить, что с нативным модулем быстрее работает и безглючнее. Но это надо проверить.

»

.

Автор Anarchist, дата создания 11 января, 2009 - 16:27.
HolyBoy написал(а):
Я бы не сказал, что логика работы фильтра syslog-ng очевидна, особенно, если надо много условий задавать.

Да, для большого количества условий описанный мной принцип выглядит не шибко изящно.
С другой стороны: тот факт, что запись обрабатывается только один раз я бы не назвал интуитивно-очевидным.

HolyBoy написал(а):
Например, вот полностью часть конфига rsyslog, в которой ясно видно, что куда валится

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

А ещё могу сказать, что отдельные индивидуумы в подобной ситуации предлагают валить всё в один файл и использовать grep :)))

HolyBoy написал(а):
Из приятных мелочей здесь можно отметить не только работу с сообщением по содержанию (msg, contains = match), но и обработку имени программы programname, isequal (чего в syslog-ng не встретил c ходу).

isequal - не понял.
Разруливать по LOG FACILITY, progname, match STRING syslog-ng умеет.

HolyBoy написал(а):
Anarchist написал(а):
Оно понятно.
Интереснее: в каких случаях это обоснованно и чем расплчиваешься.

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

Я же тут сразу задумался о нагрузке, конфигурации/настройке производительности и прочей радости...

HolyBoy написал(а):
Расплата за использование БД только одна (при условии, что у нас выделена отдельная машина сбора логов в БД или в текстовые файлы): невозможность онлайн отслеживать и отлаживать программу, т.к. все данные надо предварительно запросить.

Если бы только этим...
Здесь мне думается о поведении различных СУБД при перегрузке. А также о том, что разные (преимущественно самопровзглашённые) "гуру" от рассмотрения данной темы просто уходят (не, тут конечно есть уйма индивидуальных параметров, но они не отменяют общих принципов).

—

:wq
--
Live free or die

»

..

Автор HolyBoy, дата создания 11 января, 2009 - 17:53.
Anarchist написал(а):
А ещё могу сказать, что отдельные индивидуумы в подобной ситуации предлагают валить всё в один файл и использовать grep :)))

Подобные товарищи считаются в данном топике несуществующими. :)

Anarchist написал(а):
isequal - не понял.

Имеется в виду, что можно разруливать по точному совпадению isequal, по частичному contains.

Anarchist написал(а):
Если бы только этим...
Здесь мне думается о поведении различных СУБД при перегрузке. А также о том, что разные (преимущественно самопровзглашённые) "гуру" от рассмотрения данной темы просто уходят (не, тут конечно есть уйма индивидуальных параметров, но они не отменяют общих принципов).

Я не гуру и на тему загруженности СУБД много сказать не смогу. Те базы, что есть у меня, нагружены невысоко.

То, что я пробовал с ради интереса с rsyslog выглядело так: включал максимальную детализацию у всех программ на двух отдельных серверах и на третьем, пишущем логи; направлял этот поток весь в БД. А потом запросы делал с измерением времени. Потом перенаправлял не в БД, а в файл и также мерял. Кроме того, измерял парсинг файлов на самих серверах локально. По быстродействию получилось так:
1. До определённого размера быстрее всего локальный парсинг файлов.
2. СУБД.
3. Централизованный сбор логов в текстовые файлы и парсинг.

После некоторого момента 1. и 2. п. меняются местами или становятся сравнимыми по временным затратам. Параметры сервера с БД: 2xPIII, 512 Mb RAM, HDD IDE. В среднем скорость записи была 1 Гб/ч. СУБД PostgreSQL.

»

.

Автор Anarchist, дата создания 12 января, 2009 - 15:19.
HolyBoy написал(а):
Anarchist написал(а):
isequal - не понял.

Имеется в виду, что можно разруливать по точному совпадению isequal, по частичному contains.

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

HolyBoy написал(а):
Я не гуру и на тему загруженности СУБД много сказать не смогу. Те базы, что есть у меня, нагружены невысоко.

Ну, мои знания тоже далеко не достаточны, но хочу обратить Ваше внимание на тот факт, что загрузка СУБД - характеристика далеко не одно- (много-мало) и даже не двух- (много-мало; чтение-запись) мерная.

В данной номинации (по объёму заносимой информации, числу потоков/интенсивности запросов на добавление записей, частоте и типу запросов на выборку) оптимизация СУБД не то, чтобы является головоломной задачей.

А ещё лично меня здесь интересует вопрос: логи каких приложений (полагаю: web-сервер, сервер электронной почты, где-то - прокси) предполагается обрабатывать и чем (насколько распространены в данном случае самописные парсеры)?

HolyBoy написал(а):
То, что я пробовал...

Думается мне, сначала нужно ответить на вопрос "зачем пишем логи". Из ответа достаточно очевидно следует таблица приоритетов.
А ещё интересная тема для обсуждения: где и какие логи имеет смысл писать.

Возвращаясь к теме rsyslog vs syslog-ng скажу следующее:
Где его достоинства дают заметные преимущества - мне лично не вполне представляется.
Но есть подозрение, что весовой коэффициент недостатка в виде некоторой нестабильности там тоже вырастет.
Все нужные мне функции по фильтрации сообщений syslog-ng обеспечивает (это я к тому, что не вполне представляю зачем может потребоваться разруливать сообщения по isequal и что возможно то же распределение можно реализовать как-то иначе).

—

:wq
--
Live free or die

»

...

Автор HolyBoy, дата создания 14 января, 2009 - 12:57.
Anarchist написал(а):
А ещё лично меня здесь интересует вопрос: логи каких приложений (полагаю: web-сервер, сервер электронной почты, где-то - прокси) предполагается обрабатывать и чем (насколько распространены в данном случае самописные парсеры)?

Это частности. Складывать в БД можно любые логи, которые надо часто дёргать и которые имеют очень большие объемы. Зачем дёргать? Ну, к примеру, для построения отчётов в рил-тайм, частого поиска нужной информации за разные, достаточно большие периоды. Кроме почты, кстати, существуют логи с различных устройств: АТС, физических приборов и тд. ;)

Anarchist написал(а):
Возвращаясь к теме rsyslog vs syslog-ng скажу следующее:
Где его достоинства дают заметные преимущества - мне лично не вполне представляется.

Многопоточность, отсутствующая у syslog-ng, модульность rsyslog и прочие вещи уже сейчас достаточно интересны. Также, плюсом является постоянное развитие этого проекта, в отличие от syslog-ng. Разумеется, если не требуются особенные фичи, которые даёт rsyslog, то можно и syslog-ng обходиться, а некоторым и metalog хватает. :)

»

.

Автор Anarchist, дата создания 19 января, 2009 - 11:41.
HolyBoy написал(а):
Это частности.

Думается мне, ты несколько преувеличиваешь.

HolyBoy написал(а):
Складывать в БД можно любые логи, которые надо часто дёргать и которые имеют очень большие объемы. Зачем дёргать? Ну, к примеру, для построения отчётов в рил-тайм

Насколько жёсткое требование к Real Time (на РЕАЛЬНО БОЛЬШИХ) объёмах данных.
Есть мнение, что incremental mode парсера будет куда как экономичнее.

HolyBoy написал(а):
частого поиска нужной информации за разные, достаточно большие периоды.

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

HolyBoy написал(а):
Кроме почты, кстати, существуют логи с различных устройств: АТС, физических приборов и тд. ;)

Про АТС ты это зря сказал ;) Здесь я тебе про реалии много чего весёлого рассказать могу (как на уровне присоединяющего оператора, так и на уровне присоединяемого)... :)
И про логи в том числе.

HolyBoy написал(а):
Многопоточность, отсутствующая у syslog-ng, модульность rsyslog и прочие вещи уже сейчас достаточно интересны.

Вопрос: где и насколько они реально необходимы?

HolyBoy написал(а):
Также, плюсом является постоянное развитие этого проекта, в отличие от syslog-ng. Разумеется, если не требуются особенные фичи, которые даёт rsyslog, то можно и syslog-ng обходиться, а некоторым и metalog хватает. :)

metalog - это который syslogd?
Вопрос ИМХО не в том: какие фичи насколько нужны, а в том: насколько ты готов платить надёжностью (в случае той же почты - ещё не сильно страшно, а вот если речь идёт о логах АТС, с достаточно большим числом портов и высокой долей дорогого трафика... там и поныне заради надёжности забивают на оперативность и используют встроенные возможности АТС по записи статистики в файл)?
Относительно же развития рекомендую посмотреть на график развития webalizer'а ;)

—

:wq
--
Live free or die

»

неа

Автор evadim, дата создания 19 января, 2009 - 18:41.
Anarchist написал(а):
metalog - это который syslogd?

metalog это metalog, когда-то он рекомендовался по умолчанию в gentoo. Имеет встроенный и базово настроенный logrotate, единственно что мне несколько ненравится - с UTF несовсем дружит...

»

>>А ещё могу сказать, что

Автор wi, дата создания 12 января, 2009 - 18:04.

>>А ещё могу сказать, что отдельные индивидуумы в подобной ситуации предлагают валить всё в один файл

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

По теме
Испоьзую syslog-ng. Вполне достойный и гибкий логгер. Если не нравится ваш собственный фильтр - откорректируйте его.
По поводу хранения логов целиком в бд. Если запись лога не парсить по полям и таблицам - то особого смысла в этом нет. Накладные расходы на парсинг и добавление записи в субд значительно превышают оные при выводе строки в файл. Задача логгера всеж таки ближе к оперативности записи. Плюс к тому 99% логов это мусор, в котором надо найти некий перл. Какой - никто точно не скажет, зависит от постановки задачи. Причем старый лог - штука постоянная. Потому конкретный отчет по логу за определенный период неизменен. Соответсвенно запрос к бд посылаем 1 раз и забываем про него. Ну и зачем тогда мы строили индексы?

»

.

Автор Anarchist, дата создания 13 января, 2009 - 11:48.
wi написал(а):
>>А ещё могу сказать, что отдельные индивидуумы в подобной ситуации предлагают валить всё в один файл

Это, как бы, нормальная практика.

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

wi написал(а):
Иногда для поиска врагов полезно видеть общую картину завала.

Не только поиска врагов.
Но! Практически всего - по горячим следам.
Отдельные же логи для анализа/обработки запросов необходимо хранить месяцами.

wi написал(а):
Разбить общий поток лога на несколько не вопрос

И каждый из полученных кусков обрабатывать в соответствии с индивидуальными условиями??? :)

wi написал(а):
к тому же очень удобно отслеживать один класс событий отдельно от остальнеого окружения. А вот собрать из нескольких один в той же последовательности нереально.

В переводе: чем задуматься над частным решением: что, как и зачем логировать - валим всё в один файл, а там - видно будет? Так? :)

wi написал(а):
Испоьзую syslog-ng. Вполне достойный и гибкий логгер. Если не нравится ваш собственный фильтр - откорректируйте его.

Речь идёт о логике работы и принципах написания фильтров (которые не всегда смотрятся изящно). Это - факт.

wi написал(а):
Задача логгера всеж таки ближе к оперативности записи.

Я бы сказал: надёжной и лишь достаточно оперативной.

wi написал(а):
Плюс к тому 99% логов это мусор, в котором надо найти некий перл.

Думаю, корректнее сказать: где-то в 60-80% случаев нельзя априори сказать что будешь искать.

wi написал(а):
старый лог - штука постоянная

Только обращения к логам далеко не сводятся к формированию отчётов.

—

:wq
--
Live free or die

»

+

Автор Anarchist, дата создания 13 января, 2009 - 10:30.

Да, забыл (в силу того что лично мне на данном этапе не нужно): syslog-ng умеет фильтровать и по уровням (info, notice /etc).

—

:wq
--
Live free or die

»

Хорошая статейка:

Автор S-anches, дата создания 19 января, 2009 - 19:54.

Хорошая статейка: http://belgorod.lug.ru/wiki/index.php/Настройка_syslog-ng

»

Меня в значительно бОльшей

Автор Anarchist, дата создания 20 января, 2009 - 10:23.

Меня в значительно бОльшей степени порадовала (в качестве нулевого приближения) http://sial.org/howto/logging/syslog-ng/

Ну а дальше - здравый смысл && представления о том, что и как должно логировать + man syslog-ng.conf.

—

:wq
--
Live free or die

»

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".