Мы используем Cacti с RRDTool для мониторинга и построения графиков около 100 000 счетчиков, распределенных примерно на 1000 узлах на базе Linux. Однако наша текущая настройка обычно дает нам только 5-минутные графики (с некоторыми данными на основе минут); мы часто вносим изменения, когда обратная связь «почти в реальном времени» была бы полезной. Я бы хотел примерно за неделю 5 или 10 секунд данных, год 1 минут данных и 5 лет 10 минут данных. У меня есть SSD-диски и двухъядерный сервер в запасе.
Я попытался настроить сервер Graphite / Carbon / Whper, и к нему было подключено около 15 узлов, но он имеет только «среднее» значение для функции удержания при переходе на более старые корзины. Это почти бесполезно - мне нужны минимальное, максимальное, среднее, стандартное отклонение и, возможно, «общая сумма» и «количество образцов» или, возможно, «95-й процентиль». Разработчик утверждает, что есть новый бета-сервер, который позволяет вам писать свои собственные функции, но он, похоже, по-прежнему сохраняет только 1: 1 (при сохранении старых данных вам действительно нужно, чтобы статистика рассчитывалась для многих потоков из одиночный ввод. Кроме того, "бета-версия" кажется немного рискованной для этой установки. Если я ошибаюсь в этом предположении, я был бы счастлив, если бы мне показали мою ошибку!
Я слышал, что Zabbix рекомендуется, но он помещает данные в MySQL или другую базу данных SQL. 100000 счетчиков с 5-секундным интервалом означают 20000 транзакций в секунду, и хотя у меня есть SSD, у меня нет 8-полосного RAID-6 с кешем резервного питания, который, я думаю, мне понадобится для этого :-) Опять же, если это на самом деле не проблема, я был бы счастлив, если бы мне показали ошибку моего пути. Кроме того, может ли Zabbix делать единый поток данных -> продвигать со статистикой?
Наконец, Мунин утверждает, что прямо сейчас выходит новая версия 2.0 «в стадии бета-тестирования» и может похвастаться индивидуальными планами хранения. Однако, опять же, это та часть, которая находится «в бета-версии» - кто-нибудь использовал ее по-настоящему и масштабно? Как это работало, если да?
Я почти подумываю об использовании графического интерфейса (такого как Graphite) и развертывания моего собственного бэкенда удержания с простым слоем поверх mmap () и некоторой статистикой. Это не будет особенно сложно и, вероятно, будет работать очень хорошо, позволив ядру определить баланс между частотой сброса на диск и операциями процесса.
Есть ли другие предложения, на которые я должен обратить внимание? Примечание: он должен показать себя способным выдерживать нагрузки, которые я предлагаю выше; если вы можете указать конкретную реализацию, на которую вы ссылаетесь, тем лучше!
Вы смотрели на Ганглии?
Я сильно сомневаюсь, что Мунин подойдет к вашим размерам. Но Ganglia разработан с нуля для больших кластеров серверов.
Я с другими людьми, которые комментировали, спрашивая, почему вам нужно отслеживать так много элементов с такой короткой периодичностью. Самая большая проблема с этим заключается в том, что ваша система мониторинга начнет вызывать ложные срабатывания в отношении загрузки, а вы сокращаете время ЦП, доступное для другой обработки. Изменение интервала мониторинга с 5 до 15 секунд приведет к снижению накладных расходов на мониторинг на 80%, но при этом обеспечит вам как минимум вдвое большую минимальную видимость, которая часто составляет около 30 секунд. Также, когда вы присмотритесь, вы можете определить, что некоторые элементы не нужно проверять каждые 15 или 30 секунд. Одним из примеров является диск, вы можете обрабатывать его каждые 30 или 60 секунд. Например, если вы пишете только 1,7 МБ / с, вы сможете передать только 100 МБ за минуту. Если ваша система мониторинга настроена на тревогу на уровне 1 ГБ, например, у вас теперь есть около 100 минут, прежде чем у вас закончится диск (используя этот пример медленного диска). CPU, зачем вам знать, что он делает при разрешении менее 30 секунд? Он загружен на 100% в облаке, отлично, он выполняет некоторую работу, как и должен делать узел кластера. Но если он загружен на 100%, когда его рабочая очередь равна 0, то у вас проблема.
Кроме того, мониторинг на такой жесткой частоте увеличивает вашу погоню за ложными срабатываниями из-за наведенных артефактов в вашем наборе данных. Например, если ваша система мониторинга вызывает базовую нагрузку 20% и 100 КБ / с из-за мониторинга всего с интервалом в 5 секунд, действительно ли вы получаете точную картину того, что делает ваш хост? Что касается ложных срабатываний, рассмотрите возможность срабатывания при загрузке сети 500 КБ / с, одна только ваша система мониторинга даст вам 20% пути.
Также вы не предложили ничего из вышеизложенного, что заставляет меня думать, что Zabbix не может справиться с тем, что вы хотите сделать. Попробуйте, мы будем ждать в сообществе Zabbix, чтобы помочь вам, когда это необходимо.
Проверьте графит, http://graphite.wikidot.com/. Они говорят о высокой емкости:
Graphite был разработан внутри компании Orbitz.com, где он используется для визуализации различных критически важных данных, включая показатели приложений, показатели базы данных, продажи и т. Д. На момент написания этой статьи производственная система Orbitz могла обрабатывать примерно 160 000 различных показателей. в минуту на двух серверах niagra-2 Sun в очень быстрой сети SAN.
Известно, что Zabbix хорошо работает в средах с 1000+ хостами, ваше 5-секундное обновление немного неслыханно (возможно, вам нужна такая периодичность для большинства из них, и что-то вроде 30 секунд для некоторых из них подходит для вас).
Прокси Zabbix (думайте о них как о мини-серверах Zabbix) рекомендуются в больших установках для снижения нагрузки на Zabbix Server. http://www.packtpub.com/article/proxies-monitor-remote-locations-zabbix-1.8
От самого Алексея:
«Он будет собирать данные о производительности и доступности, а также выполнять автоматическое обнаружение от имени ZABBIX Server: