> Здравствуйте,
> необходимо мониторить 3К узлов (3 параметра мониторинга с кажого узла).[Про NVPS-ы и выбор сервера, вроде, где-то на wiki Zb было. Я документацию не читаю, поэтому напишу своё:]
Если их снимать раз в минуту, то 3k*3/60 = 150 NVPS. В принципе, это немного...
Если снимать раз в 15 минут, то 3k*3/60/15 => 10 NVPS. Это вообще "ничего" почти что.
Если - раз в 6 сек. (считать удобнее|-), то 3k*3/6 => 1500 NVPS.
Это примерно, как мои Zb - нужно много памяти и шпинделей на сервере БД. У меня БД "локально" на одной машине с Zb и апачем. LA5 "в среднем" в районе 3.6 на одном сервере (много "external" скриптов) и 1.2 на другом (snmp в основном). Т.к. LA включает дисковую нагрузку, процессорная, видимо, во вполне допустимых [нижних] пределах [для тех серверных xeon-ов~].
У меня серверы упираются в диски -- при обновлении сервера заказывал начальству "больше шпинделей". Добавление ОЗУ (=системного дискового кеша) тож помогло. Тюнинг PostgreSQL и таращение в графики само-мониторинга -- "забесплатно" и беспрестанно (и, в моём случае, на достаточно любительском уровне: прикинуть к носу, а чего б покрутить -- попробовать параметр-другой, выбрать лучший результат -- забыть на год-другой; почитать слайды про тюнинг Pg -- решить, что у меня-то всё по-другому, пройти мимо; ипт).
Прошлый раз хвастался метриками в апреле 2013-го:
http://www.opennet.me/openforum/vsluhforumID13/848.html#1
//Пойду, наверное, обновлю Доску Само-почёта.
> Есть ли необходимость держать заббикс-сервер на одной вирт. машине, а СУБД на
СУБД в виртуалке обычно как раз _не_ рекомендуют.
Для 10 NVPS вообще без разницы: одна виртуалка на всё и забыть. Для 150 NVPS - наверное, тоже (но у меня опыта с Zb/Pg в вирт.нет никакого - чисто умозрительно), но по мне, так физ.сервер -- было б спокойнее. На 400-700-1000+ NVPS, как мне кажется, виртуализация будет пятой ногой -- лишней ненадёжностью и проедателем ресурсов впустую. (Хотя, допускаю, может, какая "профессиональная" "промышленная" виртуализация и даст какой-нибудь выигрыш в районе дать/поменять забиксу ещё ОЗУ и шпинтелей и не будет [заметно] тормозить при этом. Прямого опыта у меня тут нет.)
> второй? если ли необходимость в использовании заббикс-прокси?
Zb-прокси это вынос сбора ближе к части "целей". При этом _триггеры_ считаются и их собранные данные инсёртятся в "большую" базу на _центральном_ сервере. То есть графики за периоды, когда связи с "в туда" не было, со временем появятся на основном сервере, но _некоторые_ триггеры могут срабатывать ("чувствительность к nodata"~) из-за перерыва в связи с прокси, а не проблемах с самими целями.
Ну, ещё трафик опроса не гонять через "длинные концы" -- какие-то из айтемов м.б., наверное, м.б. чувствительны к плохой/далёкой/пропадающей связи с целью. Лишние SMS по куче триггеров, когда "там просто" притормозил интернет (бывает и с прокси, и с отказом какого-то общего локальныого сервиса (свич "в центре", БД одна на всех, авторизация итп)), -- проблема (особенно, когда их вываливается 100 или 300 или 500 и они "доходят" до людей в течение часа-двух. особенно :/ ночью).
> Или достаточно иметь одну машину, например с8 ядрами и 32гигами памяти с
> ссд-дисками?
ssd хорошо и быстро, но zb постоянно утюжит диски -- про когда он "протрёт" ssd (слышал, когда-то это было проблемой) я ничего сказать не могу.
> P.S. узлы разнесены географически, связь нестабильная.
Вариант для распечатки
