Re: syslog и дебианизированн ый софт
Jurgen V. Uzbekoff wrote: On Sat, Oct 24, 2009 at 11:06:22AM +0400, Dmitry E. Oboukhov wrote: следом tail -f syslog и зачастую не успеваешь увидеть чего там бинд то матюкнулся. VN> tail -f syslog | grep bind во первых как сказано tail -f уже может не успеть увидеть /etc/init.d/bind9 reload; tail -f /var/log/syslog | grep named во вторых когд tail -f направляешь в пайп получаешь кучу траблов связанных с тем что пайп буферизируется Вот про это не скажу — не сталкивался с такой проблемой. буфферизует тут скорее не tail, а grep. В связи с чем я использую grep --line-buffered -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: syslog и дебианизированн ый софт
Dmitry E. Oboukhov пишет: > Кстати о сислоге. я вот не далее чем вчера ковырялся с биндом. вопросы > вон в рассылке в соседнем топике. так вот раза три поймал себя на > мысли "чтож у бинда не как у людей? занафига его так неудобно в сислог > запхали?" > PS: на хосте с этим биндом вертится екзим, спамчекер, ppp, итп и > суммарная активность в логах высокая. даешь команду на апдейт зоны и > следом tail -f syslog и зачастую не успеваешь увидеть чего там бинд то > матюкнулся. > > так что каждого приложения лог в своем каталоге это наиболее > правильный подход На сколько я помню, bind и syslog в debian настроен так, что логи от бинда в daemon.log сыпятся и с логами exim никак не смешиваются т.к. логи от exim складываются тоже отдельно. signature.asc Description: OpenPGP digital signature
Re: syslog и дебианизированн ый софт
=D0=91=D0=B8=D0=BD=D0=B4 =D1=83=D0=BC=D0=B5=D0=B5=D1=82 =D0=B2=D0=B5=D1=81= =D1=82=D0=B8 =D0=BB=D0=BE=D0=B3=D0=B8 =D0=BD=D0=B5 =D0=B2 =D1=81=D0=B8=D1= =81=D0=BB=D0=BE=D0=B3. =D0=A1=D0=B8=D1=81=D0=BB=D0=BE=D0=B3 =D0=B2 =D0=B4=D0=B5=D0=B1=D0=B8=D0=B0= =D0=BD=D0=B5 =D0=BF=D0=BE=D1=83=D0=BC=D0=BE=D0=BB=D1=87=D0=B0=D0=BD=D0=B8= =D1=8E =D0=BD=D0=B0=D1=81=D1=82=D1=80=D0=BE=D0=B5=D0=BD =D1=82=D0=B0=D0=BA= , =D1=87=D1=82=D0=BE =D0=BB=D0=BE=D0=B3=D0=B8 =D0=BE=D1=82 exim =D0=BD=D0= =B5 =D1=81=D0=BC=D0=B5=D1=88=D0=B8=D0=B2=D0=B0=D1=8E=D1=82=D1=81=D1=8F =D1= =81 =D0=B1=D0=B8=D0=BD=D0=B4=D0=BE=D0=BC. =D0=90 =D1=83=D0=B6 =D0=B5=D1=81=D0=BB=D0=B8 =D1=82=D1=8B =D0=B8=D1=85 =D1= =81=D0=B0=D0=BC =D1=81=D0=BC=D0=B5=D1=88=D0=B0=D0=BB - =D0=A1=D0=A1=D0=97= =D0=91. =D0=94=D0=B0 =D0=B8 =D0=BF=D0=BE=D0=B3=D1=80=D0=B5=D0=BF=D0=B0=D1= =82=D1=8C =D0=BA=D1=82=D0=BE =D0=BC=D0=B5=D1=88=D0=B0=D0=B5=D1=82? signature.asc Description: OpenPGP digital signature
Re: syslog и дебианизированн ый софт
On Sat, 24 Oct 2009 04:54:28 +0800 Denis Feklushkin wrote: > Мне пока только причина интересна Кстати, реальной причиной может быть возможность подделки логов. Стандартные команды записи лога из С позволяют записать в лог абсолютно любую строку, имя демона вызвавшего функцию при этом не проверяется. Так было раньше, как оно сейчас обстоит не знаю. signature.asc Description: PGP signature
Re: syslog и дебианизированн ый софт
On Sat, 24 Oct 2009 00:34:42 +0400 Artem Chuprina wrote: > Denis Feklushkin -> debian-russian@lists.debian.org @ Sat, 24 Oct > 2009 03:05:20 +0800: > > >> >> DF> А как мониторить ошибки? Есть много серверов, надо > >> >> DF> следить как бы чего не вышло. Появление ошибки в логе > >> >> DF> вполне себе признак что что-то случилось. Но как вы об > >> >> DF> этом узнаете? > >> >> > >> >> Система мониторинга - это система роботов, которые регулярно > >> >> проверяют _функционирование_ серверов. То есть тот факт, что > >> >> сервер обслуживает запросы так, как должен. И сообщает она о > >> >> том факте, что сервер не обслужил запрос, как положено. > >> > >> DF> Такая система никогда не будет проверять все возможные ошибки > >> DF> (аналогия- борьба с багами в софте, когда никогда нельзя > >> DF> сказать что в конкретной версии софта багов точно нет) > >> > >> Денис, _никакая_ система никогда не будет проверять _все_ > >> возможные ошибки. Это математически неразрешимая задача. Но > >> нужно не это. Нужно, чтобы сервер выполнял свои функции. Если он > >> их выполняет, но ругается в лог - это менее страшно, чем если он > >> не ругается в лог, но не выполняет свои функции. > > DF> Не согласен. Лог в большинстве случаев будет информативнее и > DF> быстрее > > - Ваша программа работает в 10 раз медленнее моей! > - Да. Но зато она работает ПРАВИЛЬНО. Именно, это как раз иллюстрация к якобы медленной работе syslog :) > Лог, вероятно, информативнее. Если его мониторить - может быть, и > быстрее. Но очень не факт, что он таки поймает ошибку своевременно... Мы уже договорились что одно другое не отменяет > >> DF> не пофигу, т.к. в этом случае это систему придётся на каждую > >> DF> машину ставить и настраивать. а при её смене ставить другую и > >> DF> опять таки настраивать > >> > >> Это тоже неправда. Ничто, в общем, не мешает держать и, > >> соответственно, настраивать ее на машине мониторинга. Уж это-то > >> даже теоретик должен бы сообразить... > > DF> Что за машина мониторинга? Уж не та ли эта машина, на которую > DF> стекаются логи с других машин? А как они туда стекаются, уж не > DF> сислогами ли удалённо? > > Нет, это та машина, которая проверяет, что сервер отзывается так, как > он должен отзываться. А заодно может и в логи позаглядывать... > Совершенно не обязательно имея их для этого локально. man ssh, если > чо... Да, давайте придумаем свою собственную систему сбора логов взамен существующией > > >> >> >> DF> Потому что нормально когда 10 серверов и все сливают > >> >> >> DF> логи (копии их) на одну машину где админ сможет > >> >> >> DF> централизованно их прочесть перед началом рабочего > >> >> >> DF> дня > >> >> >> > >> >> >> Теоретик... > >> >> > >> >> DF> Да > >> >> > >> >> Это вторая половина ответа на твой изначальный вопрос. > >> >> "Потому что _на практике_ удобнее так, как сделано в > >> >> дистрибутиве". > >> > >> DF> Пока обоснования логичного я не увидел. > >> > >> А практику не нужно _логичное_ обоснование. Если так удобнее - > >> ему пофигу, как это обосновывается, и обосновывается ли вообще. > > DF> Я допускаю другое объяснение: ни один маинтайнер не может > DF> заменить всю систему логгирования в дистрибутиве. Поэтому каждый > DF> из них вынужден следовать в общей канве. > > Так никому и не надо менять всю систему логгирования. Каждому > достаточно поменять свою. Если та система, на которую меняют, не > позволяет это сделать удобно - значит, она плохая. Согласен. > > Только вот никому оно не надо, менять свою систему. > > >> >> Пакеты у нас, > >> >> знаешь ли, мейнтейнят в основном те, кто их использует... Ну > >> >> и естественно, что в рамках соблюдения полиси мейнтейнер > >> >> делает так, как удобнее ему на практике - а не в возвышенной > >> >> теории. > >> > >> DF> Ну маразматиков то везде хватает, чего уж там ) > >> > >> Знаешь, есть, гм, подозрение, что маразматику не по силам > >> поддерживать работоспособными такие сложные пакеты, как apache и > >> samba. Ты много сравнимых по сложности пакетов в Debian > >> поддерживаешь? > > DF> Полно случаев когда специалисты в своей области упираются рогом в > DF> какую-нибудь параллельную ничего не значащую хрень. > DF> (Вспоминается, например, автор оконного менеджера Ion) > > Форкни и сделай свое. Мне пока только причина интересна > Или вот, конструктивнее, сделай дополнение - > хотя бы к нужным тебе демонам, - позволяющее при инсталляции включать > логгинг сообразно локальной политике системы. И перенастраивать его, > опять же, глобально по всем демонам, эту систему поддерживающим. И > протолкни мейнтейнерам. Невменяемых все же меньшинство, а > большинство вполне согласится принять дополнение, ничего не ломающее, > но добавляющее новую функциональность. > > Глядишь, народу понравится, и к следующему релизу большинство демонов > уже будут это уметь... > > >> >> >> У ме
Re: syslog и дебианизированн ый софт
Denis Feklushkin -> debian-russian@lists.debian.org @ Sat, 24 Oct 2009 03:05:20 +0800: >> >> DF> А как мониторить ошибки? Есть много серверов, надо следить >> >> DF> как бы чего не вышло. Появление ошибки в логе вполне себе >> >> DF> признак что что-то случилось. Но как вы об этом узнаете? >> >> >> >> Система мониторинга - это система роботов, которые регулярно >> >> проверяют _функционирование_ серверов. То есть тот факт, что >> >> сервер обслуживает запросы так, как должен. И сообщает она о том >> >> факте, что сервер не обслужил запрос, как положено. >> >> DF> Такая система никогда не будет проверять все возможные ошибки >> DF> (аналогия- борьба с багами в софте, когда никогда нельзя сказать >> DF> что в конкретной версии софта багов точно нет) >> >> Денис, _никакая_ система никогда не будет проверять _все_ возможные >> ошибки. Это математически неразрешимая задача. Но нужно не это. >> Нужно, чтобы сервер выполнял свои функции. Если он их выполняет, но >> ругается в лог - это менее страшно, чем если он не ругается в лог, но >> не выполняет свои функции. DF> Не согласен. Лог в большинстве случаев будет информативнее и быстрее - Ваша программа работает в 10 раз медленнее моей! - Да. Но зато она работает ПРАВИЛЬНО. Лог, вероятно, информативнее. Если его мониторить - может быть, и быстрее. Но очень не факт, что он таки поймает ошибку своевременно... >> DF> не пофигу, т.к. в этом случае это систему придётся на каждую >> DF> машину ставить и настраивать. а при её смене ставить другую и >> DF> опять таки настраивать >> >> Это тоже неправда. Ничто, в общем, не мешает держать и, >> соответственно, настраивать ее на машине мониторинга. Уж это-то даже >> теоретик должен бы сообразить... DF> Что за машина мониторинга? Уж не та ли эта машина, на которую DF> стекаются логи с других машин? А как они туда стекаются, уж не DF> сислогами ли удалённо? Нет, это та машина, которая проверяет, что сервер отзывается так, как он должен отзываться. А заодно может и в логи позаглядывать... Совершенно не обязательно имея их для этого локально. man ssh, если чо... >> >> >> DF> Потому что нормально когда 10 серверов и все сливают логи >> >> >> DF> (копии их) на одну машину где админ сможет >> >> >> DF> централизованно их прочесть перед началом рабочего дня >> >> >> >> >> >> Теоретик... >> >> >> >> DF> Да >> >> >> >> Это вторая половина ответа на твой изначальный вопрос. "Потому >> >> что _на практике_ удобнее так, как сделано в дистрибутиве". >> >> DF> Пока обоснования логичного я не увидел. >> >> А практику не нужно _логичное_ обоснование. Если так удобнее - ему >> пофигу, как это обосновывается, и обосновывается ли вообще. DF> Я допускаю другое объяснение: ни один маинтайнер не может заменить DF> всю систему логгирования в дистрибутиве. Поэтому каждый из них DF> вынужден следовать в общей канве. Так никому и не надо менять всю систему логгирования. Каждому достаточно поменять свою. Если та система, на которую меняют, не позволяет это сделать удобно - значит, она плохая. Только вот никому оно не надо, менять свою систему. >> >> Пакеты у нас, >> >> знаешь ли, мейнтейнят в основном те, кто их использует... Ну и >> >> естественно, что в рамках соблюдения полиси мейнтейнер делает >> >> так, как удобнее ему на практике - а не в возвышенной теории. >> >> DF> Ну маразматиков то везде хватает, чего уж там ) >> >> Знаешь, есть, гм, подозрение, что маразматику не по силам >> поддерживать работоспособными такие сложные пакеты, как apache и >> samba. Ты много сравнимых по сложности пакетов в Debian >> поддерживаешь? DF> Полно случаев когда специалисты в своей области упираются рогом в DF> какую-нибудь параллельную ничего не значащую хрень. (Вспоминается, DF> например, автор оконного менеджера Ion) Форкни и сделай свое. Или вот, конструктивнее, сделай дополнение - хотя бы к нужным тебе демонам, - позволяющее при инсталляции включать логгинг сообразно локальной политике системы. И перенастраивать его, опять же, глобально по всем демонам, эту систему поддерживающим. И протолкни мейнтейнерам. Невменяемых все же меньшинство, а большинство вполне согласится принять дополнение, ничего не ломающее, но добавляющее новую функциональность. Глядишь, народу понравится, и к следующему релизу большинство демонов уже будут это уметь... >> >> >> У меня всего один сервер. Но читать его логи по всем сервисам >> >> >> перед началом рабочего дня нереально. Вернее, читать-то >> >> >> реально. Нереально прочесть. >> >> >> >> >> >> DF> Софта много, ставится/удаляется он не редко, каждому >> >> >> DF> лазить в конфиг и перенастраивать устать можно. Или того >> >> >> DF> хуже - забыть что-то перенастроить на сислог и о >> >> >> DF> проблеме не узнать вообще >> >> >> >> >> >> Ты и так о ней не узнаешь - у тебя либо слишком много вывода, >> >> >> либо самое интересное будет за
Re: syslog и дебианизированн ый софт
On Sat, 24 Oct 2009 04:18:42 +0800 Denis Feklushkin wrote: > On Fri, 23 Oct 2009 23:54:22 +0400 > "Evgeniy M. Solodookhin" wrote: > > > ,-[Fri, Oct 23, 2009 at 23:40 +0800, Denis Feklushkin:] > > |> Ну и настрой в своем конкретном случае логгинг в сислог. Зачем > > |> всем-то это навязывать? > > | > > |Так решительно всё приходётся перенастраивать! > > > > вот и истина. > > выцыганить изменения в полиси, оказывается, быстрее, нежели > > перенастроить логирование по собственному эстетическому > > восприятию. ) > > Если существующая система плоха почему нет? > > По хорошему я бы предложил пропускать логи через rsyslog и > раскладывать их по файлам уже в настройках сислога так как они > разложены сейчас. (Как сейчас маинтайнерам приходится для logrotate > писать настройку вместо этого будут писат) ...вместо этого будут писать строчку конфига для rsyslog) signature.asc Description: PGP signature
Re: syslog и дебианизированн ый софт
On Fri, 23 Oct 2009 23:54:22 +0400 "Evgeniy M. Solodookhin" wrote: > ,-[Fri, Oct 23, 2009 at 23:40 +0800, Denis Feklushkin:] > |> Ну и настрой в своем конкретном случае логгинг в сислог. Зачем > |> всем-то это навязывать? > | > |Так решительно всё приходётся перенастраивать! > > вот и истина. > выцыганить изменения в полиси, оказывается, быстрее, нежели > перенастроить логирование по собственному эстетическому восприятию. ) Если существующая система плоха почему нет? По хорошему я бы предложил пропускать логи через rsyslog и раскладывать их по файлам уже в настройках сислога так как они разложены сейчас. (Как сейчас маинтайнерам приходится для logrotate писать настройку вместо этого будут писат) Тогда те кому это не надо не теряют ничего. Тем же, кто хочет логи передавать и обрабатывать в других местах получат такую возможность настроив локальный rsyslog в одном месте Но я уверен на 100% что где-то эта идея уже обсуждалась или обсуждается, пока, правда, не нашёл > > |Вот вы можете сходу точно > |сказать сколько у вас демонов крутится в системе? А если завтра > |поставите ещё 1 не забудете его лог завернуть в сислог? > > signature.asc Description: PGP signature
Re: syslog и дебианизированн ый софт
On Fri, 23 Oct 2009 22:53:08 +0400 Artem Chuprina wrote: > Ну, во-первых, не сислог, а в лучшем случае syslog-ng. У нас пока что > по умолчанию ставится sysklogd, который как раз не умеет. Многие не в курсе как я понял: http://wiki.debian.org/Rsyslog Starting with Lenny, Debian will use rsyslog instead of sysklogd by default. Here are some arguments from the discussions 1 2 3: * rsyslog is a drop in replacement for former syslog (If you have a custom syslog.conf, you can copy it to /etc/rsyslog.conf) * Support for logging into databases (MySQL and PostgreSQL). * A real plus is also upstream, who is very responsive and active and it's a pleasure to work with him. * Automated log rotation. * Configure remote logging via debconf. * sysklogd in itself is not bad, but the package has been nearly fully unmaintained for years. и там же текст как мигрировать signature.asc Description: PGP signature
Re: syslog и дебианизированн ый софт
On Fri, 23 Oct 2009 23:23:48 +0400 James Brown wrote: > Ужос, срач на техническую тему хуже чем на политическую :) А он и есть на политическую signature.asc Description: PGP signature
Re: syslog и дебианизированн ый софт
Ужос, срач на техническую тему хуже чем на политическую :) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: syslog и дебианизированн ый софт
On Fri, 23 Oct 2009 22:40:20 +0400 "Dmitry E. Oboukhov" wrote: > Кстати о сислоге. я вот не далее чем вчера ковырялся с биндом. вопросы > вон в рассылке в соседнем топике. так вот раза три поймал себя на > мысли "чтож у бинда не как у людей? занафига его так неудобно в сислог > запхали?" ты под работой сислога понимаешь один результирующий файл? сейчас в rsyslog на сколько я знаю можно настроить всё так, что отличаться оно не будет от того к чему ты привык но появятся преимущества, например можно будет логи завернуть или задублировать на другую машину > PS: на хосте с этим биндом вертится екзим, спамчекер, ppp, итп и > суммарная активность в логах высокая. даешь команду на апдейт зоны и > следом tail -f syslog и зачастую не успеваешь увидеть чего там бинд то > матюкнулся. > > так что каждого приложения лог в своем каталоге это наиболее > правильный подход signature.asc Description: PGP signature
Re: syslog и дебианизированн ый софт
On Fri, 23 Oct 2009 22:53:08 +0400 Artem Chuprina wrote: > Denis Feklushkin -> debian-russian@lists.debian.org @ Sat, 24 Oct > 2009 01:55:07 +0800: > > >> >> DF> Слишком много это не аргумент. Если есть не 1 сервер с > >> >> DF> приличным трафиком а 10 то без сислога придётся ходить на > >> >> DF> каждый и смотреть логи (а вдруг чего случилось?) > >> >> > >> >> Для "а вдруг чего случилось" существуют средства мониторинга. > >> > >> DF> Лог это тоже стредство мониторинга > >> > >> Лог - это средство разбирательства с проблемой, о которой сообщили > >> средства мониторинга. > > DF> Нет, лог - часть мониторинга > >> Путать одно с другим вредно для > >> работоспособности серверов. > > DF> обоснуй (с) > > Перепутав одно с другим, ты подменяешь мониторинг логгингом. Попутно, > как заметно из соседнего письма, часть ошибок ставя в игнор. (Я там, кстати, откаментил по какому принципу можно их ставить а лучше не ставить) > И видишь > дивной чистоты логи... и неработающий сервер. Потому что откуда у > него возьмутся сообщения в логе, если он словил сегфолт и упал? > Или > если его ненавязчиво хакнули и подменили страницу? слова о том что логгинг - часть мониторинга мониторинг другими методами не исключают. > DF> Откуда известно то? Ну не может система мониторинга проверить > DF> функциональность в полном объёме никогда! > > Не может. Но логгинг - и подавно. Нет, не так! Просто: оба не могут. И всё, без "подавно" > >> >> >> Опять же, на хостинговом web-сервере нужно давать права на > >> >> >> чтение логов от разных виртуальных хостов разным > >> >> >> пользователям. Если это настраивается прямо в описании > >> >> >> виртуального сервера, то это гораздо проще, чем сначала > >> >> >> поправить описание виртуального сервера, а потом syslog. > >> >> > >> >> DF> В этом конкретном случае использовать в апаче настройку > >> >> DF> записи лога и в сислог и пользователям в их маленькие > >> >> DF> логи виртуальных хостов отдельно > >> >> > >> >> Ну и настрой в своем конкретном случае логгинг в сислог. > >> >> Зачем всем-то это навязывать? > >> > >> DF> Так решительно всё приходётся перенастраивать! Вот вы можете > >> DF> сходу точно сказать сколько у вас демонов крутится в > >> DF> системе? А если завтра поставите ещё 1 не забудете его лог > >> DF> завернуть в сислог? > >> > >> А мне (surprise!) не надо перенастраивать их логгинг в сислог > >> (потому что я применяю для решения задач адекватные им > >> инструменты?). Меня вполне устраивает, как они настроены в > >> дистрибутиве, а там, где не устраивает, мне нужно более тонкое > >> разделение логов, а не слияние. > > DF> Разделение сислог умеет > > Ну, во-первых, не сислог, а в лучшем случае syslog-ng. > У нас пока что > по умолчанию ставится sysklogd, который как раз не умеет. На здоровский rsyslog хотят поменять, судя по wiki. Он и файлы sysklogd понимает и все о чем я говорил умеет > Зато умеет > терять сообщения об ошибках. rsyslog на эту тему ок > Впрочем, syslog-ng, кажется, тоже умеет > - а под непотерю заточен какой-то другой логгер, и ресурсы системы, > подозреваю, он жрет не по-детски. ой ну вот не надо только о жрущем ресурсы сислоге. смешно. > А во-вторых, и зачем мне тратить ресурсы систем на то, чтобы сначала > склеить сообщения, а потом расклеить их обратно? :))) > >> То есть, возвращаясь к твоему изначальному вопросу - вот тут в > >> рассылке на одного тебя, которому было бы удобнее в сислог, > >> нашлись по крайней мере двое, если не трое, которым удобнее как > >> раз раздельными файлами. > > DF> Пока их обоснование собственных хотелок меня не убедило > > А оно нам надо - тебя убеждать? Скажи спасибо, что ответ вообще > оказался более развернутым, чем просто "нам так удобнее". Спасибо > >> Вопрос: так каким в таком раскладе должно быть > >> поведение дистрибутивных пакетов "из коробки"? Чтобы "решительно > >> всё" приходилось перенастраивать одному тебе или нам двоим? Мне > >> кажется, что первое... > > DF> Я ни к чему не призываю, > > http://lists.debian.org/debian-russian/2009/10/msg01381.html : > Вот я и спрашиваю, на самом деле, почему не сказано? Пора уже внести > его может для систем, на которых есть демоны, пищущие логи? ^ > > (Кстати, видел ли ты хотя бы одну дебиановскую систему, в которой нет > таких демонов?) Видел ли я дебиан без демонов? да, видел > DF> я только спросил почему сделано так а не иначе > > Тебе ответили. Тебе не нравится ответ? Он от этого не изменится. > signature.asc Description: PGP signature
Re: syslog и дебианизированн ый софт
On Fri, 23 Oct 2009 22:32:28 +0400 Artem Chuprina wrote: > >> DF> А как мониторить ошибки? Есть много серверов, надо следить > >> DF> как бы чего не вышло. Появление ошибки в логе вполне себе > >> DF> признак что что-то случилось. Но как вы об этом узнаете? > >> > >> Система мониторинга - это система роботов, которые регулярно > >> проверяют _функционирование_ серверов. То есть тот факт, что > >> сервер обслуживает запросы так, как должен. И сообщает она о том > >> факте, что сервер не обслужил запрос, как положено. > > DF> Такая система никогда не будет проверять все возможные ошибки > DF> (аналогия- борьба с багами в софте, когда никогда нельзя сказать > DF> что в конкретной версии софта багов точно нет) > > Денис, _никакая_ система никогда не будет проверять _все_ возможные > ошибки. Это математически неразрешимая задача. Но нужно не это. > Нужно, чтобы сервер выполнял свои функции. Если он их выполняет, но > ругается в лог - это менее страшно, чем если он не ругается в лог, но > не выполняет свои функции. Не согласен. Лог в большинстве случаев будет информативнее и быстрее > Поэтому первична проверка > функциональности. А проверка логов на сообщения об ошибках - так, > небесполезное дополнение. > > >> Система мониторинга может _включать_ проверку логов на сообщения > >> об ошибках > > DF> обязана, ибо смотри выше. это ещё один рубеж, если угодно > > Ключевое слово - "включать", а не "может". > > Кроме того, ни в коем случае не обязана. В лучшем случае - > "рекомендуется, так как это, вероятно, довольно дешево". > > >> (на случай, если сервер вообще-то на запросы отвечает - но не > >> на все, допустим) - но ни в коем случае не _сводиться_ к ней. > >> Поэтому ей как раз пофигу, сколько у нас логов и на скольких они > >> машинах - это лишь малая часть положенных проверок. > > DF> не пофигу, т.к. в этом случае это систему придётся на каждую > DF> машину ставить и настраивать. а при её смене ставить другую и > DF> опять таки настраивать > > Это тоже неправда. Ничто, в общем, не мешает держать и, > соответственно, настраивать ее на машине мониторинга. Уж это-то даже > теоретик должен бы сообразить... Что за машина мониторинга? Уж не та ли эта машина, на которую стекаются логи с других машин? А как они туда стекаются, уж не сислогами ли удалённо? > >> >> DF> Потому что нормально когда 10 серверов и все сливают логи > >> >> DF> (копии их) на одну машину где админ сможет > >> >> DF> централизованно их прочесть перед началом рабочего дня > >> >> > >> >> Теоретик... > >> > >> DF> Да > >> > >> Это вторая половина ответа на твой изначальный вопрос. "Потому > >> что _на практике_ удобнее так, как сделано в дистрибутиве". > > DF> Пока обоснования логичного я не увидел. > > А практику не нужно _логичное_ обоснование. Если так удобнее - ему > пофигу, как это обосновывается, и обосновывается ли вообще. Я допускаю другое объяснение: ни один маинтайнер не может заменить всю систему логгирования в дистрибутиве. Поэтому каждый из них вынужден следовать в общей канве. > > >> Пакеты у нас, > >> знаешь ли, мейнтейнят в основном те, кто их использует... Ну и > >> естественно, что в рамках соблюдения полиси мейнтейнер делает > >> так, как удобнее ему на практике - а не в возвышенной теории. > > DF> Ну маразматиков то везде хватает, чего уж там ) > > Знаешь, есть, гм, подозрение, что маразматику не по силам поддерживать > работоспособными такие сложные пакеты, как apache и samba. Ты много > сравнимых по сложности пакетов в Debian поддерживаешь? Полно случаев когда специалисты в своей области упираются рогом в какую-нибудь параллельную ничего не значащую хрень. (Вспоминается, например, автор оконного менеджера Ion) > А то что-то мне подсказывает, что поиск маразматиков тут надо > начинать с тебя... > > >> >> У меня всего один сервер. Но читать его логи по всем сервисам > >> >> перед началом рабочего дня нереально. Вернее, читать-то > >> >> реально. Нереально прочесть. > >> >> > >> >> DF> Софта много, ставится/удаляется он не редко, каждому > >> >> DF> лазить в конфиг и перенастраивать устать можно. Или того > >> >> DF> хуже - забыть что-то перенастроить на сислог и о > >> >> DF> проблеме не узнать вообще > >> >> > >> >> Ты и так о ней не узнаешь - у тебя либо слишком много вывода, > >> >> либо самое интересное будет зарезано настройкой, сжимающей > >> >> логи до уровня "реально прочесть". > >> > >> DF> Ошибки либо есть либо их нет. > >> > >> Так ты не путай ошибки и сообщения об ошибках. Это сильно не > >> одно и то же. > > DF> Анноящие сообщения об ошибках, которые на самом деле не > DF> свидетельствуют об ошибках ставятся в игнор (ровно так же как и > DF> при "зарезании настройкой, сжимающей логи уровня реально > DF> прочесть") > > Ты и теоретик-то хреновый... Тебе словосочетания "ошибка первого > рода" и "ошибка второго рода" что-нибудь говорят? Тут у нас не статистика с миллиона машин
Re: syslog и дебианизированн ый софт
Denis Feklushkin -> debian-russian@lists.debian.org @ Sat, 24 Oct 2009 01:55:07 +0800: >> >> DF> Слишком много это не аргумент. Если есть не 1 сервер с >> >> DF> приличным трафиком а 10 то без сислога придётся ходить на >> >> DF> каждый и смотреть логи (а вдруг чего случилось?) >> >> >> >> Для "а вдруг чего случилось" существуют средства мониторинга. >> >> DF> Лог это тоже стредство мониторинга >> >> Лог - это средство разбирательства с проблемой, о которой сообщили >> средства мониторинга. DF> Нет, лог - часть мониторинга >> Путать одно с другим вредно для >> работоспособности серверов. DF> обоснуй (с) Перепутав одно с другим, ты подменяешь мониторинг логгингом. Попутно, как заметно из соседнего письма, часть ошибок ставя в игнор. И видишь дивной чистоты логи... и неработающий сервер. Потому что откуда у него возьмутся сообщения в логе, если он словил сегфолт и упал? Или если его ненавязчиво хакнули и подменили страницу? DF> Откуда известно то? Ну не может система мониторинга проверить DF> функциональность в полном объёме никогда! Не может. Но логгинг - и подавно. >> >> >> Опять же, на хостинговом web-сервере нужно давать права на >> >> >> чтение логов от разных виртуальных хостов разным >> >> >> пользователям. Если это настраивается прямо в описании >> >> >> виртуального сервера, то это гораздо проще, чем сначала >> >> >> поправить описание виртуального сервера, а потом syslog. >> >> >> >> DF> В этом конкретном случае использовать в апаче настройку >> >> DF> записи лога и в сислог и пользователям в их маленькие логи >> >> DF> виртуальных хостов отдельно >> >> >> >> Ну и настрой в своем конкретном случае логгинг в сислог. Зачем >> >> всем-то это навязывать? >> >> DF> Так решительно всё приходётся перенастраивать! Вот вы можете >> DF> сходу точно сказать сколько у вас демонов крутится в системе? А >> DF> если завтра поставите ещё 1 не забудете его лог завернуть в >> DF> сислог? >> >> А мне (surprise!) не надо перенастраивать их логгинг в сислог (потому >> что я применяю для решения задач адекватные им инструменты?). Меня >> вполне устраивает, как они настроены в дистрибутиве, а там, где не >> устраивает, мне нужно более тонкое разделение логов, а не слияние. DF> Разделение сислог умеет Ну, во-первых, не сислог, а в лучшем случае syslog-ng. У нас пока что по умолчанию ставится sysklogd, который как раз не умеет. Зато умеет терять сообщения об ошибках. Впрочем, syslog-ng, кажется, тоже умеет - а под непотерю заточен какой-то другой логгер, и ресурсы системы, подозреваю, он жрет не по-детски. А во-вторых, и зачем мне тратить ресурсы систем на то, чтобы сначала склеить сообщения, а потом расклеить их обратно? >> То есть, возвращаясь к твоему изначальному вопросу - вот тут в >> рассылке на одного тебя, которому было бы удобнее в сислог, нашлись >> по крайней мере двое, если не трое, которым удобнее как раз >> раздельными файлами. DF> Пока их обоснование собственных хотелок меня не убедило А оно нам надо - тебя убеждать? Скажи спасибо, что ответ вообще оказался более развернутым, чем просто "нам так удобнее". >> Вопрос: так каким в таком раскладе должно быть >> поведение дистрибутивных пакетов "из коробки"? Чтобы "решительно >> всё" приходилось перенастраивать одному тебе или нам двоим? Мне >> кажется, что первое... DF> Я ни к чему не призываю, http://lists.debian.org/debian-russian/2009/10/msg01381.html : Вот я и спрашиваю, на самом деле, почему не сказано? Пора уже внести его может для систем, на которых есть демоны, пищущие логи? (Кстати, видел ли ты хотя бы одну дебиановскую систему, в которой нет таких демонов?) DF> я только спросил почему сделано так а не иначе Тебе ответили. Тебе не нравится ответ? Он от этого не изменится. -- В теории нет различия между теорией и практикой. На практике - есть. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: syslog и дебианизированн ый софт
Denis Feklushkin -> debian-russian@lists.debian.org @ Sat, 24 Oct 2009 01:52:40 +0800: >> >> >> Сислог хорош там, где _надо объединить_ записи от разных >> >> >> демонов. Или там, где надо логгировать на другую машину. А >> >> >> там, где не надо - зачем сначала заворачивать логгинг в >> >> >> сислог, а потом грепом разворачивать обратно? "К чему этот >> >> >> долгий и мучительный процесс?" >> >> >> >> DF> Так по умолчанию надо предполагать что лог идёт на удалённую >> >> DF> машину. >> >> >> >> Неразумно. Потому что на удаленную машину оно идет очень редко. >> >> У меня, скажем, за 15 лет ни разу такого сетапа не было. >> >> DF> А как мониторить ошибки? Есть много серверов, надо следить как бы >> DF> чего не вышло. Появление ошибки в логе вполне себе признак что >> DF> что-то случилось. Но как вы об этом узнаете? >> >> Система мониторинга - это система роботов, которые регулярно проверяют >> _функционирование_ серверов. То есть тот факт, что сервер обслуживает >> запросы так, как должен. И сообщает она о том факте, что сервер не >> обслужил запрос, как положено. DF> Такая система никогда не будет проверять все возможные ошибки DF> (аналогия- борьба с багами в софте, когда никогда нельзя сказать что в DF> конкретной версии софта багов точно нет) Денис, _никакая_ система никогда не будет проверять _все_ возможные ошибки. Это математически неразрешимая задача. Но нужно не это. Нужно, чтобы сервер выполнял свои функции. Если он их выполняет, но ругается в лог - это менее страшно, чем если он не ругается в лог, но не выполняет свои функции. Поэтому первична проверка функциональности. А проверка логов на сообщения об ошибках - так, небесполезное дополнение. >> Система мониторинга может _включать_ проверку логов на сообщения об >> ошибках DF> обязана, ибо смотри выше. это ещё один рубеж, если угодно Ключевое слово - "включать", а не "может". Кроме того, ни в коем случае не обязана. В лучшем случае - "рекомендуется, так как это, вероятно, довольно дешево". >> (на случай, если сервер вообще-то на запросы отвечает - но не >> на все, допустим) - но ни в коем случае не _сводиться_ к ней. >> Поэтому ей как раз пофигу, сколько у нас логов и на скольких они >> машинах - это лишь малая часть положенных проверок. DF> не пофигу, т.к. в этом случае это систему придётся на каждую машину DF> ставить и настраивать. а при её смене ставить другую и опять таки DF> настраивать Это тоже неправда. Ничто, в общем, не мешает держать и, соответственно, настраивать ее на машине мониторинга. Уж это-то даже теоретик должен бы сообразить... >> >> DF> Потому что нормально когда 10 серверов и все сливают логи >> >> DF> (копии их) на одну машину где админ сможет централизованно >> >> DF> их прочесть перед началом рабочего дня >> >> >> >> Теоретик... >> >> DF> Да >> >> Это вторая половина ответа на твой изначальный вопрос. "Потому что >> _на практике_ удобнее так, как сделано в дистрибутиве". DF> Пока обоснования логичного я не увидел. А практику не нужно _логичное_ обоснование. Если так удобнее - ему пофигу, как это обосновывается, и обосновывается ли вообще. >> Пакеты у нас, >> знаешь ли, мейнтейнят в основном те, кто их использует... Ну и >> естественно, что в рамках соблюдения полиси мейнтейнер делает так, как >> удобнее ему на практике - а не в возвышенной теории. DF> Ну маразматиков то везде хватает, чего уж там ) Знаешь, есть, гм, подозрение, что маразматику не по силам поддерживать работоспособными такие сложные пакеты, как apache и samba. Ты много сравнимых по сложности пакетов в Debian поддерживаешь? А то что-то мне подсказывает, что поиск маразматиков тут надо начинать с тебя... >> >> У меня всего один сервер. Но читать его логи по всем сервисам >> >> перед началом рабочего дня нереально. Вернее, читать-то >> >> реально. Нереально прочесть. >> >> >> >> DF> Софта много, ставится/удаляется он не редко, каждому лазить в >> >> DF> конфиг и перенастраивать устать можно. Или того хуже - забыть >> >> DF> что-то перенастроить на сислог и о проблеме не узнать вообще >> >> >> >> Ты и так о ней не узнаешь - у тебя либо слишком много вывода, либо >> >> самое интересное будет зарезано настройкой, сжимающей логи до >> >> уровня "реально прочесть". >> >> DF> Ошибки либо есть либо их нет. >> >> Так ты не путай ошибки и сообщения об ошибках. Это сильно не одно и >> то же. DF> Анноящие сообщения об ошибках, которые на самом деле не свидетельствуют DF> об ошибках ставятся в игнор (ровно так же как и при "зарезании DF> настройкой, сжимающей логи уровня реально прочесть") Ты и теоретик-то хреновый... Тебе словосочетания "ошибка первого рода" и "ошибка второго рода" что-нибудь говорят? -- Functional programming is like describing your problem to a mathematician. Imperative programming is like giving instructions to an idiot. -- arcus, #scheme on Freenode -- To UNSUBSCRIBE, email t
Re: syslog и дебианизированн ый софт
On Fri, 23 Oct 2009 20:38:03 +0400 Artem Chuprina wrote: > Denis Feklushkin -> debian-russian@lists.debian.org @ Fri, 23 Oct > 2009 23:40:25 +0800: > > >> DF> Слишком много это не аргумент. Если есть не 1 сервер с > >> DF> приличным трафиком а 10 то без сислога придётся ходить на > >> DF> каждый и смотреть логи (а вдруг чего случилось?) > >> > >> Для "а вдруг чего случилось" существуют средства мониторинга. > > DF> Лог это тоже стредство мониторинга > > Лог - это средство разбирательства с проблемой, о которой сообщили > средства мониторинга. Нет, лог - часть мониторинга > Путать одно с другим вредно для > работоспособности серверов. обоснуй (с) > >> И когда > >> они тебе сообщают, что что-то случилось, ты уже знаешь, с кем. > >> Уже знаешь, в какой именно error_log смотреть. Причем это как > >> раз случай, где зачастую grep не поможет, и смотреть надо глазами > >> - а значит, записи от других серверов будут сильно мешаться. > > DF> Почему это grep не поможет? отфильтровать и посмотреть важность > DF> большую чем notice очень даже поможет > > Потому что "важнее notice" будет только сообщение о том, что проблема > случилась. (И то, к тому моменту, как ты утром пришел на работу и > начал логи читать, мне про нее уже несколько часов как известно, а > скорее всего, она уже несколько часов как решена - потому что если уж > мне надо мониторить, что сервера живы, так у меня система мониторинга > заведена, и проверяет она именно работоспособность серверов, а не их > способность записать в лог сообщение об ошибке.) А чтобы ее > диагностировать, бывает нужен debug, full debug, а порой и sovsem > debug... Откуда известно то? Ну не может система мониторинга проверить функциональность в полном объёме никогда! > > >> >> Опять же, на хостинговом web-сервере нужно давать права на > >> >> чтение логов от разных виртуальных хостов разным > >> >> пользователям. Если это настраивается прямо в описании > >> >> виртуального сервера, то это гораздо проще, чем сначала > >> >> поправить описание виртуального сервера, а потом syslog. > >> > >> DF> В этом конкретном случае использовать в апаче настройку > >> DF> записи лога и в сислог и пользователям в их маленькие логи > >> DF> виртуальных хостов отдельно > >> > >> Ну и настрой в своем конкретном случае логгинг в сислог. Зачем > >> всем-то это навязывать? > > DF> Так решительно всё приходётся перенастраивать! Вот вы можете > DF> сходу точно сказать сколько у вас демонов крутится в системе? А > DF> если завтра поставите ещё 1 не забудете его лог завернуть в > DF> сислог? > > А мне (surprise!) не надо перенастраивать их логгинг в сислог (потому > что я применяю для решения задач адекватные им инструменты?). Меня > вполне устраивает, как они настроены в дистрибутиве, а там, где не > устраивает, мне нужно более тонкое разделение логов, а не слияние. Разделение сислог умеет > > То есть, возвращаясь к твоему изначальному вопросу - вот тут в > рассылке на одного тебя, которому было бы удобнее в сислог, нашлись > по крайней мере двое, если не трое, которым удобнее как раз > раздельными файлами. Пока их обоснование собственных хотелок меня не убедило > Вопрос: так каким в таком раскладе должно быть > поведение дистрибутивных пакетов "из коробки"? Чтобы "решительно > всё" приходилось перенастраивать одному тебе или нам двоим? Мне > кажется, что первое... Я ни к чему не призываю, я только спросил почему сделано так а не иначе signature.asc Description: PGP signature
Re: syslog и дебианизированн ый софт
On Fri, 23 Oct 2009 20:46:20 +0400 Artem Chuprina wrote: > >> >> Сислог хорош там, где _надо объединить_ записи от разных > >> >> демонов. Или там, где надо логгировать на другую машину. А > >> >> там, где не надо - зачем сначала заворачивать логгинг в > >> >> сислог, а потом грепом разворачивать обратно? "К чему этот > >> >> долгий и мучительный процесс?" > >> > >> DF> Так по умолчанию надо предполагать что лог идёт на удалённую > >> DF> машину. > >> > >> Неразумно. Потому что на удаленную машину оно идет очень редко. > >> У меня, скажем, за 15 лет ни разу такого сетапа не было. > > DF> А как мониторить ошибки? Есть много серверов, надо следить как бы > DF> чего не вышло. Появление ошибки в логе вполне себе признак что > DF> что-то случилось. Но как вы об этом узнаете? > > Система мониторинга - это система роботов, которые регулярно проверяют > _функционирование_ серверов. То есть тот факт, что сервер обслуживает > запросы так, как должен. И сообщает она о том факте, что сервер не > обслужил запрос, как положено. Такая система никогда не будет проверять все возможные ошибки (аналогия- борьба с багами в софте, когда никогда нельзя сказать что в конкретной версии софта багов точно нет) > > Система мониторинга может _включать_ проверку логов на сообщения об > ошибках обязана, ибо смотри выше. это ещё один рубеж, если угодно > (на случай, если сервер вообще-то на запросы отвечает - но не > на все, допустим) - но ни в коем случае не _сводиться_ к ней. > Поэтому ей как раз пофигу, сколько у нас логов и на скольких они > машинах - это лишь малая часть положенных проверок. не пофигу, т.к. в этом случае это систему придётся на каждую машину ставить и настраивать. а при её смене ставить другую и опять таки настраивать > >> DF> Потому что нормально когда 10 серверов и все сливают логи > >> DF> (копии их) на одну машину где админ сможет централизованно > >> DF> их прочесть перед началом рабочего дня > >> > >> Теоретик... > > DF> Да > > Это вторая половина ответа на твой изначальный вопрос. "Потому что > _на практике_ удобнее так, как сделано в дистрибутиве". Пока обоснования логичного я не увидел. > Пакеты у нас, > знаешь ли, мейнтейнят в основном те, кто их использует... Ну и > естественно, что в рамках соблюдения полиси мейнтейнер делает так, как > удобнее ему на практике - а не в возвышенной теории. Ну маразматиков то везде хватает, чего уж там ) > >> У меня всего один сервер. Но читать его логи по всем сервисам > >> перед началом рабочего дня нереально. Вернее, читать-то > >> реально. Нереально прочесть. > >> > >> DF> Софта много, ставится/удаляется он не редко, каждому лазить в > >> DF> конфиг и перенастраивать устать можно. Или того хуже - забыть > >> DF> что-то перенастроить на сислог и о проблеме не узнать вообще > >> > >> Ты и так о ней не узнаешь - у тебя либо слишком много вывода, либо > >> самое интересное будет зарезано настройкой, сжимающей логи до > >> уровня "реально прочесть". > > DF> Ошибки либо есть либо их нет. > > Так ты не путай ошибки и сообщения об ошибках. Это сильно не одно и > то же. > Анноящие сообщения об ошибках, которые на самом деле не свидетельствуют об ошибках ставятся в игнор (ровно так же как и при "зарезании настройкой, сжимающей логи уровня реально прочесть") signature.asc Description: PGP signature
Re: syslog и дебианизированн ый софт
Denis Feklushkin -> debian-russian@lists.debian.org @ Fri, 23 Oct 2009 23:47:21 +0800: >> >> >> > Почему многие (почти все) программы в дебиане при наличии >> >> >> > syslog не настроены на его использованиепо умолчанию? Среди >> >> >> > таких программ широкоиспользуемые, например apache2 >> >> >> > >> >> >> >> >> >> Потому что в противном случае в syslog'е был бы нечитаемый >> >> >> фарш. Разделенные логи более удобны. >> >> >> >> DF> Почему нечитаемый? разве нельзя настройть новый сислог на то >> >> DF> чтобы записывать имя демона в начале строки-записи? >> >> >> >> Можно. Но как ты при этом будешь разделять записи, >> >> соответствующие разным виртуальным хостам (если мы об апаче), >> >> DF> Как будто он не умеет указывать имя миртуального хоста в логе! >> >> Умеет. Но вот скрипт, stderr которого сыплется в error_log, уже не >> умеет предварять каждую строчку именем виртуального хоста. DF> ЕМНИП, потому что error.log един для всех. Если DF> случилась ошибка то она случилась не с виртуальным хостом. (код ответа DF> 4хх ошибкой сервера не считается) Теоретик. >> >> Сислог хорош там, где _надо объединить_ записи от разных >> >> демонов. Или там, где надо логгировать на другую машину. А там, >> >> где не надо - зачем сначала заворачивать логгинг в сислог, а >> >> потом грепом разворачивать обратно? "К чему этот долгий и >> >> мучительный процесс?" >> >> DF> Так по умолчанию надо предполагать что лог идёт на удалённую >> DF> машину. >> >> Неразумно. Потому что на удаленную машину оно идет очень редко. У >> меня, скажем, за 15 лет ни разу такого сетапа не было. DF> А как мониторить ошибки? Есть много серверов, надо следить как бы DF> чего не вышло. Появление ошибки в логе вполне себе признак что DF> что-то случилось. Но как вы об этом узнаете? Система мониторинга - это система роботов, которые регулярно проверяют _функционирование_ серверов. То есть тот факт, что сервер обслуживает запросы так, как должен. И сообщает она о том факте, что сервер не обслужил запрос, как положено. Система мониторинга может _включать_ проверку логов на сообщения об ошибках (на случай, если сервер вообще-то на запросы отвечает - но не на все, допустим) - но ни в коем случае не _сводиться_ к ней. Поэтому ей как раз пофигу, сколько у нас логов и на скольких они машинах - это лишь малая часть положенных проверок. >> DF> Потому что нормально когда 10 серверов и все сливают логи (копии >> DF> их) на одну машину где админ сможет централизованно их прочесть >> DF> перед началом рабочего дня >> >> Теоретик... DF> Да Это вторая половина ответа на твой изначальный вопрос. "Потому что _на практике_ удобнее так, как сделано в дистрибутиве". Пакеты у нас, знаешь ли, мейнтейнят в основном те, кто их использует... Ну и естественно, что в рамках соблюдения полиси мейнтейнер делает так, как удобнее ему на практике - а не в возвышенной теории. >> У меня всего один сервер. Но читать его логи по всем сервисам перед >> началом рабочего дня нереально. Вернее, читать-то реально. Нереально >> прочесть. >> >> DF> Софта много, ставится/удаляется он не редко, каждому лазить в >> DF> конфиг и перенастраивать устать можно. Или того хуже - забыть >> DF> что-то перенастроить на сислог и о проблеме не узнать вообще >> >> Ты и так о ней не узнаешь - у тебя либо слишком много вывода, либо >> самое интересное будет зарезано настройкой, сжимающей логи до уровня >> "реально прочесть". DF> Ошибки либо есть либо их нет. Так ты не путай ошибки и сообщения об ошибках. Это сильно не одно и то же. -- Дело говоришь! Теперь делай его. Кнышев. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: syslog и дебианизированн ый софт
Denis Feklushkin -> debian-russian@lists.debian.org @ Fri, 23 Oct 2009 23:40:25 +0800: >> DF> Слишком много это не аргумент. Если есть не 1 сервер с приличным >> DF> трафиком а 10 то без сислога придётся ходить на каждый и смотреть >> DF> логи (а вдруг чего случилось?) >> >> Для "а вдруг чего случилось" существуют средства мониторинга. DF> Лог это тоже стредство мониторинга Лог - это средство разбирательства с проблемой, о которой сообщили средства мониторинга. Путать одно с другим вредно для работоспособности серверов. >> И когда >> они тебе сообщают, что что-то случилось, ты уже знаешь, с кем. Уже >> знаешь, в какой именно error_log смотреть. Причем это как раз случай, >> где зачастую grep не поможет, и смотреть надо глазами - а значит, >> записи от других серверов будут сильно мешаться. DF> Почему это grep не поможет? отфильтровать и посмотреть важность большую DF> чем notice очень даже поможет Потому что "важнее notice" будет только сообщение о том, что проблема случилась. (И то, к тому моменту, как ты утром пришел на работу и начал логи читать, мне про нее уже несколько часов как известно, а скорее всего, она уже несколько часов как решена - потому что если уж мне надо мониторить, что сервера живы, так у меня система мониторинга заведена, и проверяет она именно работоспособность серверов, а не их способность записать в лог сообщение об ошибке.) А чтобы ее диагностировать, бывает нужен debug, full debug, а порой и sovsem debug... >> >> Опять же, на хостинговом web-сервере нужно давать права на чтение >> >> логов от разных виртуальных хостов разным пользователям. Если это >> >> настраивается прямо в описании виртуального сервера, то это >> >> гораздо проще, чем сначала поправить описание виртуального >> >> сервера, а потом syslog. >> >> DF> В этом конкретном случае использовать в апаче настройку записи >> DF> лога и в сислог и пользователям в их маленькие логи виртуальных >> DF> хостов отдельно >> >> Ну и настрой в своем конкретном случае логгинг в сислог. Зачем >> всем-то это навязывать? DF> Так решительно всё приходётся перенастраивать! Вот вы можете сходу DF> точно сказать сколько у вас демонов крутится в системе? А если DF> завтра поставите ещё 1 не забудете его лог завернуть в сислог? А мне (surprise!) не надо перенастраивать их логгинг в сислог (потому что я применяю для решения задач адекватные им инструменты?). Меня вполне устраивает, как они настроены в дистрибутиве, а там, где не устраивает, мне нужно более тонкое разделение логов, а не слияние. То есть, возвращаясь к твоему изначальному вопросу - вот тут в рассылке на одного тебя, которому было бы удобнее в сислог, нашлись по крайней мере двое, если не трое, которым удобнее как раз раздельными файлами. Вопрос: так каким в таком раскладе должно быть поведение дистрибутивных пакетов "из коробки"? Чтобы "решительно всё" приходилось перенастраивать одному тебе или нам двоим? Мне кажется, что первое... -- В какой тебя среде сформировало?.. -- http://www.psy.msu.ru/people/leontiev_da.html -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: syslog и дебианизированн ый софт
On Fri, 23 Oct 2009 19:18:32 +0400 Artem Chuprina wrote: > Denis Feklushkin -> debian-russian@lists.debian.org @ Fri, 23 Oct > 2009 22:30:14 +0800: > > >> >> > Почему многие (почти все) программы в дебиане при наличии > >> >> > syslog не настроены на его использованиепо умолчанию? Среди > >> >> > таких программ широкоиспользуемые, например apache2 > >> >> > > >> >> > >> >> Потому что в противном случае в syslog'е был бы нечитаемый > >> >> фарш. Разделенные логи более удобны. > >> > >> DF> Почему нечитаемый? разве нельзя настройть новый сислог на то > >> DF> чтобы записывать имя демона в начале строки-записи? > >> > >> Можно. Но как ты при этом будешь разделять записи, > >> соответствующие разным виртуальным хостам (если мы об апаче), > > DF> Как будто он не умеет указывать имя миртуального хоста в логе! > > Умеет. Но вот скрипт, stderr которого сыплется в error_log, уже не > умеет предварять каждую строчку именем виртуального хоста. ЕМНИП, потому что error.log един для всех. Если случилась ошибка то она случилась не с виртуальным хостом. (код ответа 4хх ошибкой сервера не считается) > > >> разным клиентским > >> машинам или пользователям (если о самбе) и т.п.? > > DF> Не совсем понял тут > > Самба умеет разделять лог по файлам соответственно клиентской машине, > шаре, юзеру и ряду других параметров. Причем если ты ловишь проблему > и включил отладку, там не просто много данных, а, как бы это помягче > выразиться, дохренища. Отладил - выключи. Ещё можно данные в 2 лога писать - один более подробный, другой всё что выше warning. Дело вкуса и настраивается в 1 месте - в сислоге > > >> Что ты будешь > >> делать, если на разные сервисы тебе нужны разные циклы ротации > >> логов? > > DF> зачем? забился лог сислога до определённого размера - прокрутили > DF> его > > В этом случае его проще вообще не вести. Смысл примерно тот же, а > нагрузка на процессор существенно меньше. Логи вообще-то обычно > хранят определенное время, а не сколько скопилось. Я, скажем, знаю, > что лог почтовки у меня есть за прошлую неделю. Я _уверен_ в этом. > А ситуация, когда от неожиданного всплеска оно у меня вместо этого > почистится через два дня, меня не устраивает. Здравый аргумент. Предлагаю делить логи на группы. Одни должны храниться неделю, другие месяц, третьи - лишь бы размер за мегабайт не вылез. > > >> Сислог хорош там, где _надо объединить_ записи от разных > >> демонов. Или там, где надо логгировать на другую машину. А там, > >> где не надо - зачем сначала заворачивать логгинг в сислог, а > >> потом грепом разворачивать обратно? "К чему этот долгий и > >> мучительный процесс?" > > DF> Так по умолчанию надо предполагать что лог идёт на удалённую > DF> машину. > > Неразумно. Потому что на удаленную машину оно идет очень редко. У > меня, скажем, за 15 лет ни разу такого сетапа не было. А как мониторить ошибки? Есть много серверов, надо следить как бы чего не вышло. Появление ошибки в логе вполне себе признак что что-то случилось. Но как вы об этом узнаете? > > DF> И все логи сливаются в один большой а в нём стоит настройка > DF> показывать только важное. > > А это вообще бессмысленно. Потому что когда мне надо включить > отладку в конкретном демоне - для меня важна отладочная информация. > А от остальных не важна и информация с уровнем info. Мне помимо > демона еще и в том сислоге ручку крутить? Так мне платят не за > количество подкрученных ручек, а за результат... Значит включать уровень лога для конкретного демона, очевидно. Я главным образом хочу чтобы ко мне в одну машину стекалась информация о сообщниях уровня важности, скажем, LOG_ERR. Сейчас непонятно как этого добиться не крутя кучу демонов вручную > > DF> Потому что нормально когда 10 серверов и все сливают логи (копии > DF> их) на одну машину где админ сможет централизованно их прочесть > DF> перед началом рабочего дня > > Теоретик... > Да > У меня всего один сервер. Но читать его логи по всем сервисам перед > началом рабочего дня нереально. Вернее, читать-то реально. Нереально > прочесть. > > DF> Софта много, ставится/удаляется он не редко, каждому лазить в > DF> конфиг и перенастраивать устать можно. Или того хуже - забыть > DF> что-то перенастроить на сислог и о проблеме не узнать вообще > > Ты и так о ней не узнаешь - у тебя либо слишком много вывода, либо > самое интересное будет зарезано настройкой, сжимающей логи до уровня > "реально прочесть". Ошибки либо есть либо их нет. > > О проблемах узнают не так. И так тоже signature.asc Description: PGP signature
Re: syslog и дебианизированн ый софт
On Fri, 23 Oct 2009 19:08:16 +0400 Artem Chuprina wrote: > Denis Feklushkin -> debian-russian@lists.debian.org @ Fri, 23 Oct > 2009 22:55:15 +0800: > > DF> Слишком много это не аргумент. Если есть не 1 сервер с приличным > DF> трафиком а 10 то без сислога придётся ходить на каждый и смотреть > DF> логи (а вдруг чего случилось?) > > Для "а вдруг чего случилось" существуют средства мониторинга. Лог это тоже стредство мониторинга > И когда > они тебе сообщают, что что-то случилось, ты уже знаешь, с кем. Уже > знаешь, в какой именно error_log смотреть. Причем это как раз случай, > где зачастую grep не поможет, и смотреть надо глазами - а значит, > записи от других серверов будут сильно мешаться. Почему это grep не поможет? отфильтровать и посмотреть важность большую чем notice очень даже поможет > > >> Опять же, на хостинговом web-сервере нужно давать права на чтение > >> логов от разных виртуальных хостов разным пользователям. Если это > >> настраивается прямо в описании виртуального сервера, то это > >> гораздо проще, чем сначала поправить описание виртуального > >> сервера, а потом syslog. > > DF> В этом конкретном случае использовать в апаче настройку записи > DF> лога и в сислог и пользователям в их маленькие логи виртуальных > DF> хостов отдельно > > Ну и настрой в своем конкретном случае логгинг в сислог. Зачем > всем-то это навязывать? Так решительно всё приходётся перенастраивать! Вот вы можете сходу точно сказать сколько у вас демонов крутится в системе? А если завтра поставите ещё 1 не забудете его лог завернуть в сислог? signature.asc Description: PGP signature
Re: syslog и дебианизированн ый софт
Denis Feklushkin -> debian-russian@lists.debian.org @ Fri, 23 Oct 2009 22:30:14 +0800: >> >> > Почему многие (почти все) программы в дебиане при наличии >> >> > syslog не настроены на его использованиепо умолчанию? Среди >> >> > таких программ широкоиспользуемые, например apache2 >> >> > >> >> >> >> Потому что в противном случае в syslog'е был бы нечитаемый фарш. >> >> Разделенные логи более удобны. >> >> DF> Почему нечитаемый? разве нельзя настройть новый сислог на то >> DF> чтобы записывать имя демона в начале строки-записи? >> >> Можно. Но как ты при этом будешь разделять записи, соответствующие >> разным виртуальным хостам (если мы об апаче), DF> Как будто он не умеет указывать имя миртуального хоста в логе! Умеет. Но вот скрипт, stderr которого сыплется в error_log, уже не умеет предварять каждую строчку именем виртуального хоста. >> разным клиентским >> машинам или пользователям (если о самбе) и т.п.? DF> Не совсем понял тут Самба умеет разделять лог по файлам соответственно клиентской машине, шаре, юзеру и ряду других параметров. Причем если ты ловишь проблему и включил отладку, там не просто много данных, а, как бы это помягче выразиться, дохренища. >> Что ты будешь >> делать, если на разные сервисы тебе нужны разные циклы ротации логов? DF> зачем? забился лог сислога до определённого размера - прокрутили его В этом случае его проще вообще не вести. Смысл примерно тот же, а нагрузка на процессор существенно меньше. Логи вообще-то обычно хранят определенное время, а не сколько скопилось. Я, скажем, знаю, что лог почтовки у меня есть за прошлую неделю. Я _уверен_ в этом. А ситуация, когда от неожиданного всплеска оно у меня вместо этого почистится через два дня, меня не устраивает. >> Сислог хорош там, где _надо объединить_ записи от разных демонов. Или >> там, где надо логгировать на другую машину. А там, где не надо - >> зачем сначала заворачивать логгинг в сислог, а потом грепом >> разворачивать обратно? "К чему этот долгий и мучительный процесс?" DF> Так по умолчанию надо предполагать что лог идёт на удалённую машину. Неразумно. Потому что на удаленную машину оно идет очень редко. У меня, скажем, за 15 лет ни разу такого сетапа не было. DF> И все логи сливаются в один большой а в нём стоит настройка DF> показывать только важное. А это вообще бессмысленно. Потому что когда мне надо включить отладку в конкретном демоне - для меня важна отладочная информация. А от остальных не важна и информация с уровнем info. Мне помимо демона еще и в том сислоге ручку крутить? Так мне платят не за количество подкрученных ручек, а за результат... DF> Потому что нормально когда 10 серверов и все сливают логи (копии DF> их) на одну машину где админ сможет централизованно их прочесть DF> перед началом рабочего дня Теоретик... У меня всего один сервер. Но читать его логи по всем сервисам перед началом рабочего дня нереально. Вернее, читать-то реально. Нереально прочесть. DF> Софта много, ставится/удаляется он не редко, каждому лазить в конфиг и DF> перенастраивать устать можно. Или того хуже - забыть что-то DF> перенастроить на сислог и о проблеме не узнать вообще Ты и так о ней не узнаешь - у тебя либо слишком много вывода, либо самое интересное будет зарезано настройкой, сжимающей логи до уровня "реально прочесть". О проблемах узнают не так. -- There's no sense in being precise, when you don't even know what you're talking about. -- John von Neumann -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: syslog и дебианизированн ый софт
Denis Feklushkin -> debian-russian@lists.debian.org @ Fri, 23 Oct 2009 22:55:15 +0800: DF> Слишком много это не аргумент. Если есть не 1 сервер с приличным DF> трафиком а 10 то без сислога придётся ходить на каждый и смотреть DF> логи (а вдруг чего случилось?) Для "а вдруг чего случилось" существуют средства мониторинга. И когда они тебе сообщают, что что-то случилось, ты уже знаешь, с кем. Уже знаешь, в какой именно error_log смотреть. Причем это как раз случай, где зачастую grep не поможет, и смотреть надо глазами - а значит, записи от других серверов будут сильно мешаться. >> Опять же, на хостинговом web-сервере нужно давать права на чтение >> логов от разных виртуальных хостов разным пользователям. Если это >> настраивается прямо в описании виртуального сервера, то это гораздо >> проще, чем сначала поправить описание виртуального сервера, а потом >> syslog. DF> В этом конкретном случае использовать в апаче настройку записи лога DF> и в сислог и пользователям в их маленькие логи виртуальных хостов DF> отдельно Ну и настрой в своем конкретном случае логгинг в сислог. Зачем всем-то это навязывать? -- The effort of using machines to mimic the human mind has always struck me as rather silly. I would rather use them to mimic something better -- Edsger Dijkstra -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: syslog и дебианизированн ый софт
On Fri, 23 Oct 2009 18:34:50 +0400 Victor Wagner wrote: > On 2009.10.23 at 22:31:15 +0800, Denis Feklushkin wrote: > > > > > > > > Почему многие (почти все) программы в дебиане при наличии > > > > syslog не настроены на его использованиепо умолчанию? Среди > > > > таких программ широкоиспользуемые, например apache2 > > > > > > Потому, что: > > > > > > 1) в Policy ничего не сказано насчет syslog > > > > Вот я и спрашиваю, на самом деле, почему не сказано? Пора уже внести > > его может для систем, на которых есть демоны, пищущие логи? > > Потому что рассчитывается, что Debian может быть использован не только > для домашних машинок, но и для серверов с приличным траффиком. > А там будет слишком много записей в сислоге от таких программ как > apache, если это web-сервер или samba, если это корпоративный файловый > сервер. Слишком много это не аргумент. Если есть не 1 сервер с приличным трафиком а 10 то без сислога придётся ходить на каждый и смотреть логи (а вдруг чего случилось?) Сислог сейчас позволяет настроить разделение на отдельные лог-файлы по происхождению логов в них > > Опять же, на хостинговом web-сервере нужно давать права на чтение > логов от разных виртуальных хостов разным пользователям. Если это > настраивается прямо в описании виртуального сервера, то это гораздо > проще, чем сначала поправить описание виртуального сервера, а потом > syslog. В этом конкретном случае использовать в апаче настройку записи лога и в сислог и пользователям в их маленькие логи виртуальных хостов отдельно > > В общем, для высоконагруженных серверов использовать собственную > систему логгирования, отличную от syslog - удобнее. Пока не верю ) signature.asc Description: PGP signature
Re: syslog и дебианизированн ый софт
On Fri, 23 Oct 2009 15:30:29 +0800 Alexey Trunyov wrote: > On Fri, 23 Oct 2009 02:46:42 +0800 > Denis Feklushkin wrote: > > > Почему многие (почти все) программы в дебиане при наличии syslog не > > настроены на его использованиепо умолчанию? Среди таких программ > > широкоиспользуемые, например apache2 > > Потому, что: > > 1) в Policy ничего не сказано насчет syslog Вот я и спрашиваю, на самом деле, почему не сказано? Пора уже внести его может для систем, на которых есть демоны, пищущие логи? > 2) мэнтейнеры конкретных пакетов считают, что так лучше. Почему они так считают? Все скопом, причем signature.asc Description: PGP signature
Re: syslog и дебианизированн ый софт
On Fri, 23 Oct 2009 08:37:35 +0400 Artem Chuprina wrote: > Denis Feklushkin -> debian-russian@lists.debian.org @ Fri, 23 Oct > 2009 05:22:28 +0800: > > >> > Почему многие (почти все) программы в дебиане при наличии > >> > syslog не настроены на его использованиепо умолчанию? Среди > >> > таких программ широкоиспользуемые, например apache2 > >> > > >> > >> Потому что в противном случае в syslog'е был бы нечитаемый фарш. > >> Разделенные логи более удобны. > > DF> Почему нечитаемый? разве нельзя настройть новый сислог на то > DF> чтобы записывать имя демона в начале строки-записи? > > Можно. Но как ты при этом будешь разделять записи, соответствующие > разным виртуальным хостам (если мы об апаче), Как будто он не умеет указывать имя миртуального хоста в логе! > разным клиентским > машинам или пользователям (если о самбе) и т.п.? Не совсем понял тут > Что ты будешь > делать, если на разные сервисы тебе нужны разные циклы ротации логов? зачем? забился лог сислога до определённого размера - прокрутили его > Сислог хорош там, где _надо объединить_ записи от разных демонов. Или > там, где надо логгировать на другую машину. А там, где не надо - > зачем сначала заворачивать логгинг в сислог, а потом грепом > разворачивать обратно? "К чему этот долгий и мучительный процесс?" Так по умолчанию надо предполагать что лог идёт на удалённую машину. И все логи сливаются в один большой а в нём стоит настройка показывать только важное. Потому что нормально когда 10 серверов и все сливают логи (копии их) на одну машину где админ сможет централизованно их прочесть перед началом рабочего дня Софта много, ставится/удаляется он не редко, каждому лазить в конфиг и перенастраивать устать можно. Или того хуже - забыть что-то перенастроить на сислог и о проблеме не узнать вообще signature.asc Description: PGP signature
Re: syslog и дебианизированн ый софт
On Fri, 23 Oct 2009 02:46:42 +0800 Denis Feklushkin wrote: > Почему многие (почти все) программы в дебиане при наличии syslog не > настроены на его использованиепо умолчанию? Среди таких программ > широкоиспользуемые, например apache2 Потому, что: 1) в Policy ничего не сказано насчет syslog 2) мэнтейнеры конкретных пакетов считают, что так лучше. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: syslog и дебианизированн ый софт
Denis Feklushkin -> debian-russian@lists.debian.org @ Fri, 23 Oct 2009 05:22:28 +0800: >> > Почему многие (почти все) программы в дебиане при наличии syslog не >> > настроены на его использованиепо умолчанию? Среди таких программ >> > широкоиспользуемые, например apache2 >> > >> >> Потому что в противном случае в syslog'е был бы нечитаемый фарш. >> Разделенные логи более удобны. DF> Почему нечитаемый? разве нельзя настройть новый сислог на то чтобы DF> записывать имя демона в начале строки-записи? Можно. Но как ты при этом будешь разделять записи, соответствующие разным виртуальным хостам (если мы об апаче), разным клиентским машинам или пользователям (если о самбе) и т.п.? Что ты будешь делать, если на разные сервисы тебе нужны разные циклы ротации логов? Сислог хорош там, где _надо объединить_ записи от разных демонов. Или там, где надо логгировать на другую машину. А там, где не надо - зачем сначала заворачивать логгинг в сислог, а потом грепом разворачивать обратно? "К чему этот долгий и мучительный процесс?" -- Вот .NET и Mono - это современные технологии. В смысле - сырые и глюкавые. Victor Wagner в -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: syslog и дебианизированн ый софт
On Fri, 23 Oct 2009 00:43:50 +0400 Prokofyev Vladislav wrote: > 22 октября 2009 г. 22:46 пользователь Denis Feklushkin < > denis.feklush...@gmail.com> написал: > > > Почему многие (почти все) программы в дебиане при наличии syslog не > > настроены на его использованиепо умолчанию? Среди таких программ > > широкоиспользуемые, например apache2 > > > > Потому что в противном случае в syslog'е был бы нечитаемый фарш. > Разделенные логи более удобны. Почему нечитаемый? разве нельзя настройть новый сислог на то чтобы записывать имя демона в начале строки-записи? signature.asc Description: PGP signature
