Как стать автором
Обновить

Комментарии 39

штука довольно гибкая, но я так понимаю, ты ее используешь не как замену нагиосу, а в дополнение, чтобы рисовать графики?

разводить и поддерживать несколько систем мониторинга не сильно ли геморное занятие? =)
Идеологически геморное, да, но сам знаешь, с заббиксами не судьба, поэтому вот так.
А про рисовать графики да, как дополнение. Если я под 200+ проверок заряжу в нагиос на каждый хост, ему явно не полегчает. А так можно смотреть чего-нить типа — апач затыкался, ага, рама кончалась, а мускуль пух, на дисках росло время ответа, приходил какой-то чудо запрос :)
а почему с забиксами не судьба?
слушай, ну LVM месяц назад только поставили, куда там заббикс
заббикс в инсталляции/настройке прост как валенок, благо мануал просто шикарен — всё по шагам расписано. А функционала дает просто нереальное количество, сохраняя гибкость, удобство и (при правильной настройке БД и поллеров) высокую производительность.
В общем — рекомендую.
не отрицаю его сильных сторон, но лично у меня пока с ним не сложилось
У заббикса была какая-то беда с количеством нод. Тут камрад год назад плевался — ему заббикс сервер повесил своими опросами. Да и mysql там выглядит лишним для простейших задач.
камрад ваш просто неудачник похоже. Заббикс запросто масштабируется до десятков тысяч нод, далеко не каждая проприетарная Enterprise-система на такое способна.
А насчет «простейших задач» и mysql смотрите ниже , там есть табличка интересная.
Лишнее звено просто.
между где?
rrdtool, к вашему сведению — тоже БД, циклическая.
Аллергия на mysql? Используйте sqlite — СУБД на плоских файлах, как rrdtool почти.
Бессмысленный оверхед. rrdtool — это конечно БД, а MySQL это уже СУБД с отдельным уходом за ней. А смысл?
Я так понимаю понятия «гибкость», «масштабируемость», «удобство сопровождения», «мощные инструменты построения отчетов, аудита, разделения прав, эскалация, графики SLA» вам не знакомы? Тогда ОК, продолжайте мониторить свои полтора сервера при помощи самосборных наколенных инструментов. Те же mysql, postgres или тем более sqlite нуждаются в уходе не больше чем rrd, только первичная установка/настройка.
Не надо передёргивать. Всё должно быть оптимально и эффективно. Причём тут «мощные инструменты построения отчетов, аудита, разделения прав, эскалация, графики SLA» и как мне тут поможет mysql я вообще не понял.
mysql тут вообще не при чем. А вот rrd и все обвесы к ней вам однозначно не помогут на в чем, кроме как в построении графиков средней паршивости. Называть это «системой мониторинга» некорректно, это просто примитивная «картинкорисовалка». Согласен, многим конторам а-ля SOHO хватит и этого.
Я вижу в нашем споре много ксенофобии и «энтерпрайз» яду и мало толку. Чем паршивость графиков из одних и тех же данных из MySQL и rrd будут отличаться? Причём тут система мониторинга и картинки? Вы отдаёте себе отчёт в разнице систем мониторинга и систем сбора статистики? А основные проблемы мониторинга статистической информации можете обрисовать? В каком месте там будет роль стораджа?

И что за «конторы а-ля SOHO»? Есть какие-то более расово верные конторы? Назовите их, пожалуйста.
SOHO (wiki)
Раз вы даже этого не знаете, то про остальное просто промолчу. Мы немного в разных весовых категориях, у меня есть опыт внедрения систем мониторинга в компаниях, где количество серверов превышает 2000, причем сервера совершенно разные — HPUX, AS/400, Linux, Windows, SCO. Я работал и с rrd-tool и его производными (munin, cacti, mrtg, etc.), и с системами Ent-класса (WhatsUp, HP OpenView, zabbix) вы знакомы судя по всему, только с простейшими решениями. Разговор не имеет смысла. Пожелаю вам успехов во всех начинаниях и приношу извинения, если чем обидел.
вотсап жив? ничего ж себе!
живее всех живых, курилка. )
Какой молодец, какой пример всем нам!
Мерялка не сломается, меряться постоянно?
выдыхай, бобёр!
Не знаю, как у таких больших и серьёзных дядек, которые одним движением брови 2000 машин настраивают, но у нас, простых смертных, не принято незнакомым людям тыкать.
да что ты, мы — такие же люди. ;)
а можешь мне, по секрету, рассказать почему тут бд это лишнее звено?
Нет смысла. При этом утяжеляет хранилище и вообще становится тонким местом самой системы мониторинга, так как его надо поддерживать в состоянии высокой доступности. Что обычно не так просто. Из-за отсутсвия здравого смысла там такой базы — лишнее звено.
— ну мониторингу все равно нужно какое-то хранилище.
с этим то ты не споришь?

«тонким местом самой системы», «поддерживать в состоянии высокой доступности»
в конкретнос случае с mysql ничего не надо. оно ставится из пакета, и пашет до упора. только баккап в крон пропиши, что бы где-то была копия и логи обрезались.
Я имел ввиду конечно СУБД, а не сторадж.

Ты видимо не настоящий волшебник. MySQL не «пашет до упора» — очень капризная и ломкая вещь.
Тогда для начала очерти, что такое сторадж и чем он принципиально не субд (в рамках нашей задачи).

у меня есть их в количестве. самый старый года с 2003-4 пашет. чяднт?
жрет память как собака.
Хотя по гибкости — да, могуч.
А это е несколько систем мониторинга. Одна система общего мониторинга, а вторая — сбор статистики с оповещениями.
Спасибо за статью, в избранном.
Не видели ли Вы плагина/набора плагинов, который может давать телеметрию? К примеру: у меня на сервере 5 минут назад был Load Average 70: я хочу посмотреть, какие процессы работали 5 минут назад, кто спровоцировал нагрузку, кто занял весь IO, итд. Это умеет collectl, но телеметрия на perl будет отъедать порядка 30-40% ресурсов сервера.
Лично мне collectd понравился, но кроме того, что делает nagios/zabbix — он особо много, как мне показалось, не умеет (поправьте меня, если я неправ)
Нет, так collectd не умеет, тут нужно что-то вроде splunk'a — www.splunk.com/. По заранее заданным критериям отобрать процессы для сбора статистики он может, но чтобы вот вообще всё собирать это несколько другая задача.

Zabbix да, заббикс близко, но нагиос совсем далеко — это алерты, статистика показателей как таковая там отсутствует. Собственно я ссылку в начале привел на предыдущий пост, который как раз немного про статистику ( графики ) в Нагиосе. Я вот только не уверен насчет того сколько «счётчиков» будет держать заббикс на своей стандартной базе в виде posrgresql, что может для 5ти серверов и не критично, а для 500 уже важно.
Заббикс рекомендуется держать в MySQL, по производительности реализация в pg проседает. Это даже в доках было. Вообще, для 500+ серверов на 1.8.2 не так и много надо, говорят. У меня мониторилка на полтора десятка — хорошо работает на офисной машинке.
Ну я про заббикс ничего конкретного не скажу в общем, пользовался пару недель и то года 3 назад.
Действительно, Вы правы. В своё время я одновременно пилил zabbix и otrs, и некоторые требования смешались. Эта проблема была у otrs.
он умеет принимать параметром текстовую строчку и хранить ее?

если да, то все просто, делаем ps, выводим поле %cpu и имя процесса, сортируем по первому, отрезаем первые 5-7 строк, сохраняем их как строчку в базе. то же по памяти.
в итоге на любой момент измерения есть строка с самыми жрущими процессор и память.
Поиграйтесь с atop
в смысле сбор статистики по процессам на разных серверах, графики?
symon+symux->rrd
rrdbotd(snmp)->rrd
rrd->drraw рисовалка

Вот кстати, кто-нибудь знает drraw с нормальной веб-мордой?
Спасибо! Кратко и содержательно! Но, все равно пока посижу еще на munin, для моих 2х никсосерваков и 3 и 4х виндовых(3 из которых в филлиалах) его вполне достаточно.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.