Kibana 3 Milestone 4 и интеграция графита

У меня возникают трудности с пониманием интеграции Graphite и Kibana 3 для мониторинга журналов и системных жизненно важных функций. Я имею в виду цифру в Система управления журналом, описанная здесь.

Учитывая новые возможности в Kibana 3 Milestone 4, мы можем собирать системные ботаники и хранить их непосредственно в эластичном поиске вместо графита и использовать единую панель управления kibana (что может быть правильным выбором для реализации в распределенной системе, в которой акцент делается на производительность и низкая память).
Почему мы должны использовать StatsD и графит, когда подсчет и простая статистика теперь поддерживаются комбинацией kibana - Elasticsearch?
В случае, мы решили использовать как графит, так и кибану. Как мы интегрируем его в одну панель мониторинга?
Есть ли учебник по интеграции панелей мониторинга (kibana и graphitos/graph explorer/orion/pencil)?

Спасибо заранее.

Ответ 1

Почему statsd-graphite:

Statsd и Graphite могут помочь вам визуализировать что угодно, а не только журналы и системные жизненные силы. Это очень просто с стеком statsd-graphite, чтобы измерить количество пользователей, которое зависало в левой нижней части вашего сайта более 10 секунд.
Поскольку не существует промежуточного ведения журнала, масштабируемость, предоставляемая графитом, не имеет аналогов с точки зрения ввода-вывода. Также учтите тот факт, что statsd говорит UDP, поэтому сбор 300 тыс. Метриков в минуту - это бриз.
Вам не нужно регистрировать что-то, чтобы увидеть его.

Интеграция:

Как ясно показано на общей архитектурной диаграмме, вы можете отфильтровать статистику, которую вы хотите визуализировать, переслать в statsd. Это параллельно с визуализацией кибаны непосредственно из логсташа-elasticsearch. Исключение избыточности данных - это более простой подход, если вы хотите просматривать данные Graphite и Kibana через Graphite, так как webapp не будет запрашивать elasticsearch напрямую.

Vimeo Графический проводник - это то, что вы, возможно, захотите изучить. Он запрашивает поиск elastics.

Обновление:

Не то, чтобы Logstash этого не делал, но не предназначен для этой роли, тогда как statsd и др.

Мне было интересно, есть ли у нас более простой язык запросов.

Врожденная схема организации в графите является древовидной, и, следовательно, поиски do-not/can-not получают результаты из другого поддерева. Это делает его не очень подходящим для кросс-мерных поисков. GE является простейшим, если вы хотите власти.

Поток графического проводника -

Graph Explorer обращается к этому с помощью добавления тегов к метрикам и интеграции его с elasticsearch. Итак, что действительно делает GE, так это то, что

Один раз - он подключается к вашему интерфейсу Graphite, вызывает вызовы API для получения всех показателей.
Затем он "преобразует" метрики старого прототипа 1 (A.B.C) в метрики прото 2-го уровня (host = A.app = B.username = C).
Затем он экспортируется в ES, который поддерживает индекс.
Когда вы запрашиваете интерфейс GE, он подключается к ES, чтобы понять, что вы хотите.
GE затем запрашивает Graphite-API и доставляет результаты в интерфейсе GE.

Кроме того, разве граф-исследователь полагает, что мы используем алмаз для коллекции?

Нет.

Как это сравнить с карандашом, орином и графити?

Это оптимизация на поверхности для визуализации. Они -

измените внешний вид графиков.
упростить запрос API.
позволяют улучшить поток мониторинга.

Они НЕ изменяют способ хранения или поиска информации. GE, внедряется "глубже" в метрические данные и, следовательно, имеет реальное преимущество над тем, как вы запрашиваете метрики. (Поиск по размеру)

Заголовки вверх -

GE-метрический импортирующий плагин далеко не идеален. Он успешно импортировал 300 из моих 1000 показателей. Он также более тяжелый для рендеринга, а front-end ест больше NW (из-за зависающих, масштабируемых функций).

Update -

Grafana отсутствует.