Что лучше MRTG, Cacti и т.д.? [re: [perl] Вышел 5.14]

AlexV769

Если кто-то хочет от MRTG что-то большего, он ставит Cacti

doublemother

Cacti

Страшный тормоз и много жрёт.

Sharp

Имхо, если кто-то хочет чего-то большего от MRTG, то он выбирает решение под свои требования.
Кто-то выбирает доделывание MRTG, кто-то выбирает дополнение MRTG сторонними продуктами, кто-то выбирает Cacti, а кто-то выбирает другое решение. Их, на самом деле, довольно много, и выбор конкретного всегда зависит. Не думаю, что тут можно назвать некоторого бесспорного лидера, а остальных причислить к числу неудачников.
Под каждые цели свое решение.

AlexV769

Что, по-твоему, при сохранении подобного функционала, жрет меньше и лучше педалит?

doublemother

Ну, смотря какой именно функционал тебе нужен. Если собирать данные и рисовать картинки — то, например, заббикс.

AlexV769

И на какой нагрузке (объеме данных по твоему мнению, cacti уже не будет справляться, а заббикс будет педалить как и прежде?
Есть у меня подозрение, что zabbix с его SQL для хранения данных загнется гораздо быстрее при росте объема данных.
Правильно приготовленный Cacti вполне себе способен переварить 2М датчиков раз в 5 минут на одном сервере конфигурации вроде
2 x Intel Xeon 5530
48G RAM
15xSAS15k
У тебя есть подобная статистика для zabbix?

Dasar

как долго обычно данные хранятся?
и какой период и в каком разрезе обычно визуализируется?
зы
вообще, имхо, 24M данных в час - это немного для sql даже на десктопной машине

doublemother

И на какой нагрузке (объеме данных по твоему мнению, cacti уже не будет справляться, а заббикс будет педалить как и прежде?
Есть у меня подозрение, что zabbix с его SQL для хранения данных загнется гораздо быстрее при росте объема данных.

Насчё "загнётся" сказать не могу, такой инфы у меня нет ни для одного, ни для другого. Зато могу привести в качестве примера то, что заббикс сейчас мониторит всю инфраструктуру без видимой нагрузки на неё, а какти работает на одном единственном сервисе, получая 2к точек раз в минуту, при этом его поллер висит и непрерывно кушает 200М оперативки, а в моменты опроса сервиса он без тени сомнения отъедает на сервисе 10% ядра Xeon E5420.

Marinavo_0507

и какой период и в каком разрезе обычно визуализируется?

обычно среднее или другой агрегат (максимум, квантиль) за 5 мин, 30 мин, сутки за период времени в сутки, неделю, месяц, год
для этого придумали round-robin database, а sql тут не очень подходит

Dasar

для этого придумали round-robin database, а sql тут не очень подходит

round-robin поверх sql делается проще, чем round-robin поверх сырых байт

conv3rsje

round-robin поверх sql делается проще, чем round-robin поверх сырых байт

"Все сортировки должны делаться через SQL!" (ц)
Вообще-то round-robin поверх RRD делается проще чем RR поверх SQL.
И при этом гораздо лучше.
Почему-то незаслуженно забыт collectd. Очень приятная шняга

Dasar

Вообще-то round-robin поверх RRD делается проще чем RR поверх SQL.
И при этом гораздо лучше.

в sql db вложено больше усилий, чем в RRD; что косвенно позволяет сделать вывод, что sql db эффективнее(производительнее, функциональнее, масштабируемее и т.д. чем RRD

conv3rsje

Для хранения табличных данных - безусловно.
Для хранения RR-статистики - совершенно не так.
RRD специально сделан под такую задачу.
Что косвенно позволяет сделать вывод, что RRD эффективнее(производительнее, функциональнее, масштабируемее и т.д. чем sql db
ЗЫ
Ты вообще с ним работал, или так, слышал звон?

Marinavo_0507

Почему-то незаслуженно забыт collectd. Очень приятная шняга

Ну например после апгрейда коллектора оказалось, что протокол предыдущей версии, используемый агентами, он не понимает. Типа invalid packet и всё - это значит, там даже версии протокола нет в заголовках.

Marinavo_0507

в sql db вложено больше усилий, чем в RRD;

и сортировку он лучше делает, значит визуализация будет надёжнее

conv3rsje

Не было, есть такое. Между 3 и 4 он менялся, причем весьма радикально.
В нынешней вроде тоже нету версии, но могу ошибаться, давно с ним ковырялся.

AlexV769

как долго обычно данные хранятся?



Name				Steps	Rows	Timespan

Daily (5 Minute Average) 	 1 	 9000 	 86400 	 

Weekly (30 Minute Average) 	 6 	 700 	 604800 	 

Monthly (2 Hour Average) 	 24 	 775 	 2678400 	 

Yearly (1 Day Average) 		 288 	 797 	 33053184

Steps - это уровень агрегации с квантилем в 1 polling interval (в данном случае 5 минут)

и какой период и в каком разрезе обычно визуализируется?

Как захочет пользователь. Данные можно посмотреть за любой период, где есть данные.

24M данных в час - это немного для sql даже на десктопной машине

А в месяц?

AlexV769

раз
два
Поставь эти патчи, с процессором должно стать немного получше.

Dasar

Ты вообще с ним работал, или так, слышал звон?

я делал RR (и ручной, и поверх sql) , и я представляю как эта штука устроена внутри.
и при правильной реализации RR поверх sql, там почти нет лишних оверхедов в sql

Для хранения табличных данных - безусловно.
Для хранения RR-статистики - совершенно не так.

если верить http://oss.oetiker.ch/rrdtool-trac/wiki/TuningRRD, то структура RRD слабо отличается от табличного хранения в sql db

Dasar

А в месяц?

24M * 24 часа * 30 дней * 20 байт/запись = 340Гб
еще подъемно

Dasar

timespan и rows что такое?

AlexV769

Rows - кол-во записей данного типа (глубина RR-архива)
Timespan тебя не должно волновать, эта характеристика используется при построении графиков.

Dasar

Rows - кол-во записей данного типа (глубина RR-архива)

т.е. база получается: 2 млн параметров(датчиков) * ~13 тыс. записей * ~20байт/запись = ~500Гб?
и в таком состоянии крутится из месяца в месяц?

conv3rsje

Хочешь для всего пользоваться SQL - на здоровье.
Но если, как ты говоришь, что уже пытался сделать RR на SQL то должен понимать, сколько дополнительного барахла придется делать руками (хотя бы аналог нормального RRA).
Зачем это нужно, если в RRD это всё есть в весьма хорошем виде, мне не понять.

Dasar

Зачем это нужно, если в RRD это всё есть в весьма хорошем виде, мне не понять.

проще пристыковать доп. функционал

AlexV769

Вроде того, только RRD в реальности будут занимать около 240гиг.

AlexV769

К RRD очень просто пристегивать дополнительный функционал: для этого специально есть функция xport (если нужно сджойнить кучу всего) и fetch (если дернуть надо только один RRD-архив)

doublemother

Спасибо, конечно, но мы всё равно планируем выкинуть какти окончательно

У заббикса, помимо картинок есть ещё и ценные плюшки в виде всякой сигнализации посредством почты/смс и т. п. в случае различных былинных отказов ⇒ графики не нужно мониторить, если случается панеко, сразу об этом узнаёшь. В какти я такого не видел.

AlexV769

к кактусу можно привязать Nagios. Хотя для полноценного мониторинга такая связка подходит хуже, чем специально заточенная под это система.
Но, я продолжаю утверждать, что для задачи нарисовать кучу графиков (с чего, кстати тред и начался - с MRTG) Cacti подходит лучше.

Dasar

под доб. функционалом я понимаю:
взаимосвязи между параметрами
качество данных
привязка данных к внешним данным и документам
отчеты
тренды
диаграммы
гис
алерты
OLAP
мнемосхемы
пользовательские пометки
система прав
зы
все эти модули(функционал) проще подружить со "стандартным" sql-интерфейсом, чем с RRD-интерфейсом

doublemother

Но, я продолжаю утверждать, что для задачи нарисовать кучу графиков (с чего, кстати тред и начался - с MRTG) Cacti подходит лучше.

Обоснуй?
Поскольку с верхним лимитом я ни у одной из систем не сталкивался, то ограничением я считаю всё-таки потребляемые ресурсы. А они, как уже упоминалось, такие:

$ ps -eo rss,pcpu,cmd ax|grep cacti|grep -v grep

  600  0.0 /bin/sh -c php /usr/share/cacti/site/poller.php >/dev/null 2>/var/log/cacti/poller-error.log

20108  6.0 php /usr/share/cacti/site/poller.php

19740  0.2 /usr/bin/php -q /usr/share/cacti/site/cmd.php 1 1

  584  0.2 sh -c php /usr/share/cacti/site/scripts/somewatcher.php someparam

 5724  0.2 php /usr/share/cacti/site/scripts/somewatcher.php someparam



$ ps -eo rss,pcpu,cmd |grep zabbix|grep -v grep

  496  0.0 /opt/zabbix/sbin/zabbix_agentd

 1024  0.0 /opt/zabbix/sbin/zabbix_agentd

  976  0.0 /opt/zabbix/sbin/zabbix_agentd

  976  0.0 /opt/zabbix/sbin/zabbix_agentd

  980  0.0 /opt/zabbix/sbin/zabbix_agentd

  976  0.0 /opt/zabbix/sbin/zabbix_agentd

  996  0.0 /opt/zabbix/sbin/zabbix_agentd

  880  0.0 /opt/zabbix/sbin/zabbix_agentd

Dasar

Но если, как ты говоришь, что уже пытался сделать RR на SQL то должен понимать, сколько дополнительного барахла придется делать руками (хотя бы аналог нормального RRA).

один раз сделали и забыли.
зато для визуализации и дальнейшей обработки можно использовать готовые модули, которые заточены под работу с sql

AlexV769

Грубо говоря, у zabbix'а характеристика потребляемых ресурсов с ростом объёма данных линейная, у Cacti - логарифмическая. Ты ресурсы считаешь где-то в районе нуля, а я вижу обе системы несколько подальше. Ключевое слово в моём утверждении "куча" (сотни тысяч).
Кроме этого я не знаю профиль твоей нагрузки на текущую реализацию Cacti - вполне допускаю, что у тебя там далеко не всё хорошо настроено.
Версия, кстати, какая?

doublemother

0.8.7e

conv3rsje

один раз сделали и забыли.

Ага, как же.

зато для визуализации и дальнейшей обработки можно использовать готовые модули, которые заточены под работу с sql

Конечно, если SQL - потолок знаний, то прикрутить что-нибудь к RRD будет нереально.
Ведь это что-то _не_ SQL!
Если серьезно, то никаких проблем прикручивать какие-нибудь обработки к RRD данным нет.
Другое дело что это обычно нафиг не нужно, штатных DEF/CDEF/VDEF для отображения хватает за глаза.
А больше мне никаких осмысленных операций с такими данными в голову не приходит.
Всякие приведенные тобой примеры типа гис - это честно говоря какая-то надуманная хрень.
Может быть еще осмысленным вычисление корреляций, но в реальных применениях,
насколько я понимаю, имеет смысл обработка потока текущих данных, а не архивов.
И вообще как уже написал БорисЛ, обработка данных из РРД это достаточно просто.
Причем, благодаря РРА они у тебя уже сгруппированы так как надо

Dasar

но в реальных применениях, насколько я понимаю, имеет смысл обработка потока текущих данных, а не архивов.

текущие данные имеют смысл только для срочных оповещений
всё остальное делается по архивам, особенно анализ (наличие проблем, условия и причины проблем и т.д.)

А больше мне никаких осмысленных операций с такими данными в голову не приходит.

имо, вы не решаете тех задач, которые можно было решать, имея такой набор диагностики.
как только появляются задачи: увеличить наработку на отказ (уменьшить кол-во проблем) и увеличить производительность(эффективность то всё вышеперечисленное и становится необходимым.
зы
гис, конечно, необходим только для случая - когда прикладная задача географически разнесенная, или "география" может влиять на задачу

AlexV769

RRD для тебя лучше по нескольким причинам:
1) RRD компактнее в несколько раз
2) в RRD данные уже отсортированы как надо и НИКОГДА не возникает фрагментации ни данных, ни ключа
3) при добавлении новых значений на диск пишется около 4кб данных (одна за'mmap'ленная страница).
4) бекап данных тривиален и не требует специальных ритуальных танцев с бубном: rsync -ac --block-size=(4,8,16)k и ВСЁ!
И это всё - из коробки, готовое к использованию и с возможностью скейлиться до описанных мною объёмов.
Твои теоретические изыскания, насколько я понимаю, даже близко к цифрам вроде сотни Гб данных не подбирались.

Marinavo_0507

а чё кстати в rrdtool с локами? в мане, помнится, не нашёл

AlexV769

RTFS Luke!
src/rrd_update.c:

/*

 * get exclusive lock to whole file.

 * lock gets removed when we close the file

 *

 * returns 0 on success

 */

int

LockRRD(FILE *rrdfile)

Dasar

1) RRD компактнее в несколько раз

в RRD время каждой записи хранится, или вычисляется исходя из позиции?

Dasar

Твои теоретические изыскания, насколько я понимаю, даже близко к цифрам вроде сотни Гб данных не подбирались.

пару теров сейчас вроде на самом большом внедрении, но там не одна машина

AlexV769

А если в пересчете на один сервер?

AlexV769

вычисляется исходя из позиции

Dasar

А если в пересчете на один сервер?

где-то по пол тера

Оставить комментарий