Java / Scala Metrics - Codahale - кластерный / многоузловой и графитный репортер

Question

Java / Scala Metrics - Codahale - кластерный / многоузловой и графитный репортер

1

При использовании CodaHale Metrics в Java или Scala кодирует кластеризованную среду, что такое getchas при отправке отчета Graphite?

Если у меня есть несколько экземпляров моего приложения и создание разных показателей, может ли Graphite справиться, т.е. Сообщать о совокупности?

Например, если у меня есть AppInstance A и B. Если B имеет показатель 1.2, а другой отчет 1.3 - что будет результатом Graphite? Будет ли это в среднем? или одно переопределит другое.

Совокупны ли счетчики?

Являются ли таймеры кумулятивными?

Или я должен каким-то образом дать каждому экземпляру какой-либо тег, чтобы различать разные экземпляры JVM?

NightWolf 23 нояб. 2014, в 11:19

Источник

1

Или я должен как-то дать каждому экземпляру какой-нибудь тег для различения разных экземпляров JVM? это также имеет смысл с точки зрения выявления неправильного поведения
om-nom-nom 23 нояб. 2014, в 12:57

Теги:

java

scala

metrics

graphite

codahale-metrics

3 ответа

1

Мы обнаружили, что самый простой способ справиться с этим - это использовать показатели каждого экземпляра. Таким образом вы можете видеть, как каждый экземпляр ведет себя независимо. Если вы хотите получить общее представление о кластере, вам также легко посмотреть на sumSeries набора показателей с помощью подстановочных знаков в имени метрики.

Предостережение к этому подходу состоит в том, что вы отслеживаете больше показателей в своем графическом экземпляре, поэтому, если вы используете размещенное решение, это стоит дороже.

Kevin Stewart 25 нояб. 2014, в 20:18

1

Я добавил поле "count" для каждого набора показателей, которые, как я знал, вошли одновременно. Затем я агрегировал все значения, включая counts, как "sum". Это позволило мне найти как среднее значение, так и сумму для всех показателей в наборе. (Да, графит по умолчанию должен взять последний образец за определенный период времени. Вам нужно использовать передний конец углеродного агрегатора.)

Добавление IP-адреса в имя метрики позволяет рассчитать относительные скорости для разных серверов. Если они все одного типа, а у некоторых 4 раза быстрее, чем у других, у вас есть проблема. (Я видел это). Как отмечено выше, добавление переходного значения, такого как IP, создает мертвую метрическую проблему. Если вы заботитесь об истории, вы можете создать специальный IP для "старого" и собирать мертвые показатели там, а затем удалить мертвые записи. Фактически, количество машин в любой период таймера было бы очень полезной метрикой.

Jack Parsons 23 нояб. 2014, в 21:18

Ещё вопросы

Или я должен как-то дать каждому экземпляру какой-нибудь тег для различения разных экземпляров JVM? это также имеет смысл с точки зрения выявления неправильного поведения

kamaradclimber · Accepted Answer · 2014-11-23T15-16-00.000Z

Вы можете найти свое поведение по умолчанию для случая, когда графит получает несколько точек в течение периода агрегации в aggreagtion-rules.conf. Я думаю, что графит по умолчанию должен принимать последнюю полученную точку в период агрегации.

Если вас может заинтересовать метрическая деталь экземпляром процесса (и вы, вероятно, будете в какой-то момент), вы должны каким-то образом пометить экземпляры и использовать этот тег в метрическом пути. Графит чрезвычайно полезен для агрегирования во время запроса и поиска способа агрегирования индивидуумов (сумма, средняя, максимальная или более сложная), вам будет сложно.

Одна вещь, которая может сделать вас неохотой иметь разные показатели по процессу отправителя, будет заключаться в том, что у вас очень универсальная среда, где экземпляры меняются все время (таким образом создавая много переходных показателей). В противном случае просто используйте ip + pid, и все будет в порядке.