Сабж: Существует около трех сотен интерфейсов на различных свичах и маршрутизаторах. Требуется система визуализации загруженности интерфейсов + возможность раздачи определенных графиков определенным пользователям + графики пингов серверов + возможность все это нормально обозвать.1. MRTG вещь явно не для средних сетей и не удовлетворяет требованиям. Смотрю в сторону cacti. Что скажете?
2. Очень важно все это нормально обозвать! Как следует поступить? Нормально и понятно прописать Description на всех свичах и маршрутизаторах, чтобы потом они автоматически подставлялись в заголовки страниц. Ведь руками писать с ума можно сойти.
Сейчас у нас несколько сотен сервисов мониторится Cacti.
Проблем особых не замечено, только дефолтный PHP-поллер заменили на C-шный.
Description'ы оно вполне себе умеет брать по SNMP с тех интерфейсов, которые мониторит.
>Сейчас у нас несколько сотен сервисов мониторится Cacti.
>Проблем особых не замечено, только дефолтный PHP-поллер заменили на C-шный.
>Description'ы оно вполне себе умеет брать по SNMP с тех интерфейсов, которые
>мониторит.>Проблем особых не замечено, только дефолтный PHP-поллер заменили на C-шный.
Поллеры заменяемы? Есть сторонние разработки в виде плагинов, да? Чем этот поллер лучше? Гораздо быстрее опрашивает?
На какой системе у Вас крутится cacati?
>Description'ы оно вполне себе умеет брать по SNMP с тех интерфейсов, которые
>мониторит.Дело в том, что у нас все description'ы понятны только тому кто настраивал когда-то этот интерфес. Неужели придется все переназывать?
>Поллеры заменяемы? Есть сторонние разработки в виде плагинов, да? Чем этот поллер
>лучше? Гораздо быстрее опрашивает?
>Нашел о поллере Cactid. В самом деле пишут, что быстрее, но конретных данных нет. Поверим на слово или даже свой бенчмарк сделаем.
>Сабж: Существует около трех сотен интерфейсов на различных свичах и маршрутизаторах. Требуется
>система визуализации загруженности интерфейсов + возможность раздачи определенных графиков определенным пользователям
>+ графики пингов серверов + возможность все это нормально обозвать.
>
>1. MRTG вещь явно не для средних сетей и не удовлетворяет требованиям.
>Смотрю в сторону cacti. Что скажете?
>
>2. Очень важно все это нормально обозвать! Как следует поступить? Нормально и
>понятно прописать Description на всех свичах и маршрутизаторах, чтобы потом они
>автоматически подставлялись в заголовки страниц. Ведь руками писать с ума можно
>сойти.
SNMPc минус - платна.
плюсы - умеет ВСЕ поистине все. у нас стоит .. мониторим все что знает что такое ip и snmp.
умеет подгружать мибы и многое многое другое.
сам я из воронежа, воронежская АС мониторит свои девайсы с помощью нее.
стоит, смотря какая конфигурация, от 700у.е до 3000у.е
Если сеть действительно большая, если действительно очень важна быстрая дианостика и поиск неисправностей, то подойдет.
либо nagios.
плюсы - все тоже самое что и у snmpc, ну может чего то нет, бесплатен.
минус - все еще нетривиален в установке, настройке, иногда глючит.
>SNMPc минус - платна.
>плюсы - умеет ВСЕ поистине все. у нас стоит .. мониторим все
>что знает что такое ip и snmp.
>умеет подгружать мибы и многое многое другое.
>сам я из воронежа, воронежская АС мониторит свои девайсы с помощью нее.
>
>стоит, смотря какая конфигурация, от 700у.е до 3000у.е
>Если сеть действительно большая, если действительно очень важна быстрая дианостика и поиск
>неисправностей, то подойдет.
>либо nagios.
>плюсы - все тоже самое что и у snmpc, ну может чего
>то нет, бесплатен.
>минус - все еще нетривиален в установке, настройке, иногда глючит.В чем преимущетсва nagios над cacti?
Возможно я неправильно выразился. Нужна именно система визуализации загруженности и доступности устройств. nagios позиционируется, как система мониторинга и оповещения в случае возникновения аварий или критических ситуаций. Этого не требуется.
>1. MRTG вещь явно не для средних сетей и не удовлетворяет требованиям.
>Смотрю в сторону cacti. Что скажете?
вообще, кактус это просто морда к MRTG, точнее к ее реинкарнации rrd
>вообще, кактус это просто морда к MRTG, точнее к ее реинкарнации rrdРазве RRDtool - это реинкарнация MRTG? Я думал, что это разные проекты. RRDtool просто навороченней.
А что морда - это да.
>Сабж: Существует около трех сотен интерфейсов на различных свичах и маршрутизаторах. Требуется
>система визуализации загруженности интерфейсов + возможность раздачи определенных графиков определенным пользователям
>+ графики пингов серверов + возможность все это нормально обозвать.
>
>1. MRTG вещь явно не для средних сетей и не удовлетворяет требованиям.
>Смотрю в сторону cacti. Что скажете?
>
>2. Очень важно все это нормально обозвать! Как следует поступить? Нормально и
>понятно прописать Description на всех свичах и маршрутизаторах, чтобы потом они
>автоматически подставлялись в заголовки страниц. Ведь руками писать с ума можно
>сойти.Cacti, классная вещь, позволяет всё, плюс под неё постоянно пишутся куча плагинов, которые позволяют к примеру добавить возможности нагиоса.
>Cacti, классная вещь, позволяет всё, плюс под неё постоянно пишутся куча плагинов,
>которые позволяют к примеру добавить возможности нагиоса.Ну плагины пишутся и под MRTG и под все остальное.
>>Cacti, классная вещь, позволяет всё, плюс под неё постоянно пишутся куча плагинов,
>>которые позволяют к примеру добавить возможности нагиоса.
>
>Ну плагины пишутся и под MRTG и под все остальное.Угу, только mrtg себе ставят люди, которые не видели какти. Потому что отличия, как между запорожцем и мерседесом.
>Угу, только mrtg себе ставят люди, которые не видели какти. Потому что
>отличия, как между запорожцем и мерседесом.MRTG ставят и люди, которые знают о cacti, но которым не требуется столь навороченная и относительно более сложная в настройке система.
>>Угу, только mrtg себе ставят люди, которые не видели какти. Потому что
>>отличия, как между запорожцем и мерседесом.
>
>MRTG ставят и люди, которые знают о cacti, но которым не требуется
>столь навороченная и относительно более сложная в настройке система.Помоему какти как раз проще настраивать.
>Помоему какти как раз проще настраивать.Вопрос спорный. cacti настраивать дольше. Каждый раз тыкаешь кнопки для добавления нового устройства, потом галочки для графиков ставишь и т.д. Ладно если устройств 20, а если 200?
В MRTG ./cfgmaker запустил быстренько с нужным списком устройств и все.
А есть вобще в cacti возможность сделать backup текущего состояния со списком устройств и графиков на случай если система будет переставляться?
>Ладно если устройств 20, а если 200?
Можно всем устройствам сразу сказать, чтоб рисовали график с такого-то шаблона.
>А есть вобще в cacti возможность сделать backup текущего состояния со
списком
>устройств и графиков на случай если система будет переставляться?
Ну конечно, обычное копирование рабочего каталога.
>>Ладно если устройств 20, а если 200?
>Можно всем устройствам сразу сказать, чтоб рисовали график с такого-то шаблона.Да, можно задать на кучу графиков один тэмплэйт, это быстро. Я имею ввиду, что каждое устройство добавлять отдельно - довольно муторно.
>>А есть вобще в cacti возможность сделать backup текущего состояния со
>списком
>>устройств и графиков на случай если система будет переставляться?
>Ну конечно, обычное копирование рабочего каталога.Под рабочим каталогом подразумевается /foo/cacti/rra? Т.о. я скопирую только графики (а все настройки?) или я ошибаюсь?
>Под рабочим каталогом подразумевается /foo/cacti/rra? Т.о. я скопирую только графики (а все
>настройки?) или я ошибаюсь?
В /foo/cacti/rra лежат только графики. Если нужен полный бэкап то достаточно просто скопировать папку /foo/cacti.
>Под рабочим каталогом подразумевается /foo/cacti/rra? Т.о. я скопирую только графики (а все
>настройки?) или я ошибаюсь?Настройки хранятся в БД, соответсвенно, помимо каталога с cacti надо ещё дамп базы делать при архивации.
А по поводу скорости поллера - сейчас у нас несколько тысяч data sources (там не только интерфейсы и не только по SNMP мониторятся), С-шный поллер (1 процесс, 5 потоков) отрабатывает за 15 секунд в среднем. Правда, это отдельный двухпроцессорный мониторинговый сервер, но на нём ещё и Nagios тоже крутится.
>А по поводу скорости поллера - сейчас у нас несколько тысяч data
>sources (там не только интерфейсы и не только по SNMP мониторятся),
>С-шный поллер (1 процесс, 5 потоков) отрабатывает за 15 секунд в
>среднем. Правда, это отдельный двухпроцессорный мониторинговый сервер, но на нём ещё
>и Nagios тоже крутится.С ума сойти. Сколько же вам потребовалось времени для стартовой настройки?
Кстати, вы разбивали дата сорсы в дерево? На вид реализовано это очень неудобно. Каждый интерфейс нужно забивать в дерево отдельно. Почему не сделано как с графиками (отметил галочками, указал один тэмплэйт на всех и поехали) не понимаю. Я ничего не проглядел?
Боюсь, не совсем понял вопроса...Графики существуют сами по себе, и размещение их в graph tree - это исключительно дело вкуса и удобства, причём одни и те же графики можно одновременно использовать в разных ветвях (например, есть ветка по типам устройств и ветка по роли определённых сервисов на них в функционировании сети).
Сами дивайсы добавляются/удаляются по мере необходимости, но даже если за раз нужно добавить их много, то задача всё равно существенно облегчается тем, что имеется ограниченный список их типов - поэтому можно создать относительно небольшой список шаблонов устройтв (например, коммутатор, сервер доступа, UPS etc.), использующих определённый набор типов источников данных, отображаемых в определённый набор графиков.
При добавлени устройства заранее определённого типа, как правило, указывается его IP-адрес и SNMP read community, а cacti уже сама на основании представленной в шаблоне информации определяет доступные источники данных и графики, которые можно построить на основе данных, из них получаемых.
Так что на стартовой настройке основоное требуемое время - это время на понимание принципов работы и создание шаблонов. Дальше уже чисто механическая работа - выбрал тип устройства, выбрал нужные графики из тех, что доступны для данного типа устройства, решил, где их разместить в graph tree.
>>А по поводу скорости поллера - сейчас у нас несколько тысяч data
>>sources (там не только интерфейсы и не только по SNMP мониторятся),>С ума сойти. Сколько же вам потребовалось времени для стартовой настройки?
>
>Кстати, вы разбивали дата сорсы в дерево? На вид реализовано это очень
>неудобно. Каждый интерфейс нужно забивать в дерево отдельно. Почему не сделано
>как с графиками (отметил галочками, указал один тэмплэйт на всех и
>поехали) не понимаю. Я ничего не проглядел?
Исчерпывающий ответ.Я имел ввиду следующее. Например я хочу сформировать дерево из графиков. Каждый график добавляется в ветку дерева поочереди, а т.к. их существенно большое количество, то процесс затягивается.
Удобно бы было, если нужные графики можно было бы выбрать в диалоге галочками и скопом добавить в ветку.
Просто вопрос удобства. Жалко что этого нет.
В итоге я решил формировать дерево из устройств, а не графиков. Это существенно быстрее и подходит по логике.
Если Вас не затруднит ответить на пару вопросов по поводу cacti, не могли бы вы дать свой номер ICQ? Если да, то можете отправить письмом: nik@kemsu.ru. Не хочу устраивать в форуме чат.
Я Вам письмо отправил.А графики можно на дереве "скопом" размещать - Graph Management -> Выбрать нужные галками и внизу выбрать действие "Place on tree".
>Если Вас не затруднит ответить на пару вопросов по поводу cacti, не
>могли бы вы дать свой номер ICQ? Если да, то можете
>отправить письмом: nik@kemsu.ru. Не хочу устраивать в форуме чат.
>Я Вам письмо отправил.
>
>А графики можно на дереве "скопом" размещать - Graph Management -> Выбрать нужные галками и внизу выбрать действие "Place on tree".
>
>>Если Вас не затруднит ответить на пару вопросов по поводу cacti, не
>>могли бы вы дать свой номер ICQ? Если да, то можете
>>отправить письмом: nik@kemsu.ru. Не хочу устраивать в форуме чат.
Как то делал mrtg+rrd можно любое колво машин главное чтобы сервак вытянул ... ставили у прова при построении 200 графиков садит проц мин на 5 ... :-) причем графики рисуются только те которые нада и только тогда когда их смотрят ... щас у прова за 1к клиентов так чтосистему пришлось свернуть ...