On Fri, 23 Oct 2009 22:32:28 +0400 Artem Chuprina <r...@ran.pp.ru> 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> прочесть") > > Ты и теоретик-то хреновый... Тебе словосочетания "ошибка первого > рода" и "ошибка второго рода" что-нибудь говорят? Тут у нас не статистика с миллиона машин а вполне конечное количество систем под единоначальным управлением, и однократное ложное срабатывание может служить сигналом к тому что надо бы его а) заигнорить и всё б) найти причину ложного срабатывания и устранить. И всего делов!
signature.asc
Description: PGP signature
