Denis Feklushkin -> [email protected] @ 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> проблеме не узнать вообще >> >> >> >> >> >> Ты и так о ней не узнаешь - у тебя либо слишком много вывода, >> >> >> либо самое интересное будет зарезано настройкой, сжимающей >> >> >> логи до уровня "реально прочесть". >> >> >> >> DF> Ошибки либо есть либо их нет. >> >> >> >> Так ты не путай ошибки и сообщения об ошибках. Это сильно не >> >> одно и то же. >> >> DF> Анноящие сообщения об ошибках, которые на самом деле не >> DF> свидетельствуют об ошибках ставятся в игнор (ровно так же как и >> DF> при "зарезании настройкой, сжимающей логи уровня реально >> DF> прочесть") >> >> Ты и теоретик-то хреновый... Тебе словосочетания "ошибка первого >> рода" и "ошибка второго рода" что-нибудь говорят? DF> Тут у нас не статистика с миллиона машин а вполне конечное DF> количество систем под единоначальным управлением, и однократное 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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
