Понимание метрик opscenter с помощью команд nodetool результатов cfstats и cfhistograms

Question

Я работаю над сравнительным анализом кластера кассандры и, следовательно, использую инструмент стресса кассандры. Возможность вставлять 1M записей в одну из таблиц с коэффициентом репликации 2, CL как кворум, скоростью потоков 40, на 2 узлах и нагрузкой от 11.43.600.66.

./cassandra-stress профиль пользователя = demo.yaml n=1000000 операций (вставка =1, вероятный запрос0=2) cl= кворум -узел 11.43.600.66,11.43.600.65 -скорость потоков =40

**demo.yaml script:**  
columnspec:  
  - name: user_name  
    size: gaussian(20..45)  
    population: gaussian(10000..50000)  
  - name: system_name  
    size: gaussian(20..45)  
    population: gaussian(50..60)  
  - name: time  
    size: uniform(15..25)  
    population: uniform(100000..1000000)  
  - name: request_uri  
    size: gaussian(50..80)  
    population: gaussian(100..150)  

insert:  
  partitions: fixed(1)            
  select:  fixed(1)/1000        
  batchtype: UNLOGGED   

Я пытаюсь понять результаты cfstats nodetool, cfhistograms с тем из OpsCenter. Метрики уровня таблицы Write и чтения RequestLatencies (ms/op) от Opscenter:

Результаты cfhistograms для расчета времени записи и чтения. Задержки в микросекундах

cfstats приводит к миллисекундам

a) As per the results of cfhistograms and cfstats  
Write Latency: 0.0117ms = 11.7 micros
Read Latency:  0.0943ms = 94.3 micros
This would approximately match the results at 50% as 
Write Latency: 10micros
Read Latency: 103micros  

Вопрос 1: На основании какого процентиля cfstats и cfhistograms показывают результаты? Я бы всегда рассматривал 95%, но для 95% результаты cfstats здесь не совпадают с cfhistograms здесь. Я рассматриваю что-то не так?

b) From OpsCenter results:
Write Latency: 1.6ms/op = 1600 micros
Read Latency:  1.9ms/op = 1900 micros 

Вопрос 2: Почему несоответствие с результатами cfhistograms и opscenter? Это как значения записи по оси Y opscenter, задержка чтения должна быть в микро / операциях, а не в мс / операциях?

Версии:
Кассандра 2.1.8.689
OpsCenter 5.2.2

Пожалуйста, дайте мне знать, если я ошибаюсь..!!
Спасибо

Answer 1

Это два разных типа метрик, которые отслеживаются статистически по-разному.

Начнем с того, что задержки чтения / записи кластера представляют собой представление координатора, включая возможную связь между узлами. Из opscenter, если навести указатель мыши на метрику для определения:

Среднее время ответа (в миллисекундах) клиентской записи. Период времени начинается, когда узел получает запрос на запись от клиента, и заканчивается, когда узел отвечает клиенту. В зависимости от уровня согласованности и коэффициента репликации это может включать задержку сети от записи в реплики.

В то время как в cfhistograms вы смотрите на локальные задержки для этого узла, это также сохраняется в OpsCenter под метриками CF: или TBL: (в зависимости от версии). Существует график процентиля, который на самом деле покажет это

Минимальный, средний, максимальный, 90-й и 99-й процентили времени отклика для чтения данных из memtable и sstables для конкретной таблицы. Время, прошедшее с момента, когда реплика получает запрос от координатора и отправляет ответ.

Таким образом, с точки зрения того, что описывают две метрики, это разные уровни чтения / записи.

Дополнительно - статистика, используемая для их измерения, различна.

Средняя задержка займет общее количество времени записи координатора с момента последней проверки, деленное на количество записей координатора с момента последней проверки (см. https://github.com/apache/cassandra/blob/94ff639429a65acb5f122ed559e98dd60a40e42d/src/java/org/apache/cassandra/metrics/LatencyMetrics.java#L125). Это может быть далеко от того, что ожидается, так как может быть много запросов sub ms и один 30-секундный запрос, который в среднем пока составляет 1 мс.

"Лучшие" показатели по-прежнему имеют некоторые статистические потери, но гораздо лучше описывают распределение задержек. Они (процентили в opscenter cfhistograms) обновляются путем представления задержек в сегментах, каждый из которых представляет временной диапазон. Эта гистограмма обновляется во время запроса. В OpsCenter он отслеживает состояние гистограммы каждую минуту и ​​по разнице может определить, сколько запросов произошло за каждый период времени. Это также позволяет статистически точнее объединять данные между узлами в представлении кластера. Если один узел имеет 1000 запросов, а другой - 1, усреднение даст половину пути. Сложив итоговые значения для каждого узла, можно лучше представить фактическое распределение задержки. Здесь все еще есть потеря, но сравнительно небольшая. Каждый сегмент представляет диапазон, и мы не знаем, где в этом диапазоне происходил каждый из запросов в этом сегменте, но он достаточно мал, чтобы быть "достаточно хорошим" и достаточно хорошо представлять порядок величины.

У cdehistograms Nodetool было несколько версий, чтобы насторожиться. Он использовал https://en.wikipedia.org/wiki/Reservoir_sampling алгоритм отбора проб резервуара (vitters r) вместо гистограммы, которая основана на идее, что нормальное распределение может быть представлено с меньшей выборкой данных. К сожалению, задержки - это очень тяжелое распределение с ненормальными значениями, и они могут быть на несколько порядков меньше. https://issues.apache.org/jira/browse/CASSANDRA-8662