Мониторинг на основе данных

[monaxide]

можно скриншоты вашей системы?

[dvas]

Из 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

[monaxide]

Спасибо.
То что надо. Как раз ищу такую систему.
Можно вам написать личное сообщение для уточнений?

[dvas]

Конечно можно, можно сразу почту на [e-mail].

[erthad]

А как ganglia хранит/ротирует старые данные? Какое-то свое хранилище, RRD, что-то еще?

[dvas]

По умолчанию — RRD, но можно использовать в качестве бэкенда, например, carbon.

[erthad]

Вы RRD используете?

Не совсем понятно как сюда встанет Carbon без потери отказоустойчивости ганглии.

[dvas]

Мы используем RRD, относительно carbon никаких исследований не проводили. А какое фундаментальное препятствие для carbon, вы можете пояснить?

[erthad]

Уже после отправки моего сообщения я подумал, что можно же carbon запускать на каждом хосте (а не централизованно как сперва решил), тогда таких проблем не должно быть.

Спасибо за ответ!

[AutomationD]

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

Второй вопрос, наверняка смотрели в сторону nagios, что можете сказать о сравнении о нем и связке ganglia+shinken?
Спасибо!

[erthad]

Shinken — это же и есть нагиос, переписанный на питоне.

[AutomationD]

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

[AutomationD]

По какой-то причине я не использовал check_openmanage, ума не приложу почему… Пойду попробую еще разок)))

[CyberFlow]

В сторону nagios смотрели, но как уже было сказано Shinken оказался лучшей его заменой.

Что касается выбора связки Shinken+Ganglia, то основной причиной явилось то, что Shinken(и другие nagios-подобные системы) не особо хорошо решают задачи связанные со сбором perf-data. Ganglia, в свою очередь, именно для этой задачи и предназначена.