Инструменты мониторинга, которые могут работать с высокой скоростью и большим объемом?

Мы используем Cacti с RRDTool для мониторинга и отображения около 100000 счетчиков, распределенных по 1000 узлам на базе Linux. Однако наша текущая настройка обычно дает нам только 5-минутные графики (с некоторыми данными, основанными на минутах); мы часто вносим изменения, когда было бы полезно увидеть обратную связь в "почти реальном времени". Мне нужны примерно 5- или 10-секундные данные за неделю, 1-минутные данные за год и 10-минутные данные за 5 лет. У меня есть SSD-диски и сервер с двумя шестигранными ядрами.

Я попытался настроить сервер Graphite/carbon/whisper, и к нему было подключено около 15 узлов, но он имел только "среднее" для функции сохранения при переходе на более старые сегменты. Это почти бесполезно - я хотел бы, чтобы было доступно минимальное, максимальное, среднее, стандартное отклонение и, возможно, "общая сумма" и "количество выборок" или, возможно, "95-й процентиль". Разработчик утверждает, что есть новый бэк-энд "в бета-версии", который позволяет вам написать свою собственную функцию, но, похоже, она сохраняет только 1:1 (при сохранении более старых данных вы действительно хотите, чтобы статистика рассчитывалась во множество потоков из один вход. Кроме того, "в бета-версии" кажется немного рискованным для этой установки. Если я ошибаюсь в этом предположении, я был бы рад, если мне будет показана моя ошибка!

Я слышал, что рекомендуется Zabbix, но он помещает данные в MySQL или в другую базу данных SQL. 100000 счетчиков с 5-секундным интервалом означают 20 000 т / с, и, хотя у меня есть SSD, у меня нет 8-канального RAID-6 с кэш-памятью резервного копирования, который, я думаю, мне понадобится для этого:-) Опять же, если это на самом деле что-то, что не является проблемой, я был бы счастлив, если бы мне показали ошибку моих путей. Кроме того, может ли Zabbix делать единый поток данных -> продвигать с помощью статистики?

Наконец, Munin утверждает, что новая 2.0 выходит "в бета-версии" прямо сейчас, и она может похвастаться собственными планами хранения. Однако, опять же, это часть "в бета-версии" - кто-нибудь использовал это по-настоящему и в масштабе? Как это работает, если так?

Я почти думаю об использовании графического интерфейса (такого как Graphite) и накатывания собственного механизма хранения с простым слоем поверх mmap() и некоторой статистикой. Это не было бы особенно сложно, и, вероятно, работало бы очень хорошо, позволяя ядру выяснить баланс между частотой записи на диск и процессами.

Любые другие предложения, которые я должен рассмотреть? Примечание: он должен показать, что способен выдерживать те виды данных, которые я предлагаю выше; если вы можете указать на конкретную реализацию, на которую вы ссылаетесь, тем лучше!

4 ответа

Вы смотрели на ганглиев?

Я сильно сомневаюсь, что Мунин подойдет для вашего размера. Но Ganglia спроектирован с нуля для больших кластеров серверов.

Известно, что Zabbix хорошо работает на средах с более чем 1000 хостов, ваше 5-секундное обновление немного неслыханно (может быть, вам нужна эта периодичность для большинства из них, а для некоторых из них что-то вроде 30 секунд - нормально).

Zabbix прокси-серверы (представьте их как мини-Zabbix серверы) используются в огромных инсталляциях для снижения нагрузки на Zabbix Server. http://www.packtpub.com/article/proxies-monitor-remote-locations-zabbix-1.8

От самого Алексея:

"Он будет собирать данные о производительности и доступности, а также выполнять автоматическое обнаружение от имени ZABBIX Server:

  1. Он невосприимчив к проблемам общения. Данные хранятся локально.
  2. Для этого требуются только односторонние (от прокси к серверу) TCP-соединения.
  3. Почти нулевое обслуживание. Например, если локальная база данных прокси не существует, прокси создаст ее автоматически. Таким образом, для настройки прокси требуется двоичный и небольшой конфигурационный файл.
  4. Конфигурация хранится и полностью управляется на стороне сервера из обычного веб-интерфейса. "

Проверьте Графит, http://graphite.wikidot.com/. У них есть это, чтобы сказать о высокой пропускной способности:

Графит был внутренне разработан Orbitz.com, где он используется для визуализации разнообразных критически важных для работы данных, включая метрики приложений, базы данных, продажи и т. Д. На момент написания этой статьи производственная система Orbitz может обрабатывать около 160000 различных метрик. в минуту на двух серверах Sun niagra-2 в очень быстром SAN.

Я с другими людьми, которые прокомментировали вопрос о том, почему вам нужно следить за таким количеством элементов на такой короткой частоте. Самая большая проблема при этом заключается в том, что ваша система мониторинга начнет вызывать ложные срабатывания в отношении загрузки, а вы уменьшаете время ЦП, доступное для другой обработки. Перемещение вашего интервала мониторинга с 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, чтобы помочь вам, когда это необходимо.

Другие вопросы по тегам