Pull to refresh

Comments 14

Из Ganglia сделать приличный скриншот довольно трудно — ну вот первая картинка, например, оттуда, а так ссылка на дэшборд Wikipedia дает хорошее понимание того, как это выглядит. Выглядит как адская простыня, но в реальности проблемы решает.

Вот так выглядит Shinken «с птичьего полета» www.evernote.com/shard/s8/sh/20331617-23d9-49ea-bb9a-ec9337bea800/9e0aa227ce65b1c0c49a570a159a261f
Вот так — более детально www.evernote.com/shard/s8/sh/9a30e55e-cfea-46e9-bb9c-5f2993a9b261/12e883ad822ee342f3301335af0f830f

Вот так — Kibana www.evernote.com/shard/s8/sh/91fa8548-553b-4e64-8aa0-2e8445009541/1bdf496b2679677828a3d885cf5b9f4b
Спасибо.
То что надо. Как раз ищу такую систему.
Можно вам написать личное сообщение для уточнений?
Конечно можно, можно сразу почту на dvas@webzilla.com.
А как ganglia хранит/ротирует старые данные? Какое-то свое хранилище, RRD, что-то еще?
По умолчанию — RRD, но можно использовать в качестве бэкенда, например, carbon.
Вы RRD используете?

Не совсем понятно как сюда встанет Carbon без потери отказоустойчивости ганглии.
Мы используем RRD, относительно carbon никаких исследований не проводили. А какое фундаментальное препятствие для carbon, вы можете пояснить?
Уже после отправки моего сообщения я подумал, что можно же carbon запускать на каждом хосте (а не централизованно как сперва решил), тогда таких проблем не должно быть.

Спасибо за ответ!
Спасибо огромное за статью, было очень интересно прочитать. Мы тоже используем LS+ES+Kibana. Также обрабатываем логи наших приложений. Часто возникает «проблема неверных дат», когда одна из служб отсылает пару событий «из прошлого», на что LS+ES реагируют созданием нового индекса на этот день. Соответственно если это 100 событий с разными датами — 100 новых индексов. ES загибается, т.к. резервирует минимальные ресурсы под все индексы независимо от их размера.
Не подскажете, случались ли у Вас такие проблемы и как Вы с ними боролись и боролись ли на уровне LS+ES?

Второй вопрос, наверняка смотрели в сторону nagios, что можете сказать о сравнении о нем и связке ganglia+shinken?
Спасибо!
Shinken — это же и есть нагиос, переписанный на питоне.
Ну это ясно, просто интересно мнение автора по поводу оригинальной nagios. Мы используем opsview, построена на базе nagios + web ui, шаблоны, серверные переменные, приятные rrd графики из коробки. Но автоматизацию выходит делать только через rest (конечно можно файлы nagios менять, но это не гарантирует что что-то не сломается), и нет «паков» как в zenoss. Хочу попробовать shinken, выглядит интересно. Никто не знает, как в Shinken обстоят дела с преконфигурированными сервис чеками для железа DELL чтобы не вводить десятки OID и их пороги вручную? Или может родное для nagios что-то хорошее есть?
По какой-то причине я не использовал check_openmanage, ума не приложу почему… Пойду попробую еще разок)))
В сторону nagios смотрели, но как уже было сказано Shinken оказался лучшей его заменой.

Что касается выбора связки Shinken+Ganglia, то основной причиной явилось то, что Shinken(и другие nagios-подобные системы) не особо хорошо решают задачи связанные со сбором perf-data. Ganglia, в свою очередь, именно для этой задачи и предназначена.
Only those users with full accounts are able to leave comments. Log in, please.