使用 nodetool 命令 cfstats 和 cfhistograms 结果了解 opscenter 指标答案

【问题标题】：Understanding opscenter metrics with that of nodetool commands cfstats and cfhistograms results使用 nodetool 命令 cfstats 和 cfhistograms 结果了解 opscenter 指标
【发布时间】：2016-03-25 17:34:14
【问题描述】：

我正在对 cassandra 集群进行基准测试，因此正在使用 cassandra-stress 工具。能够在复制因子为 2、CL 为仲裁、线程率为 40、在 2 个节点上并从 11.43.600.66 运行压力的表中插入 1M 条记录。

./cassandra-stress user profile= demo.yaml n=1000000 ops(insert=1,likelyquery0=2) cl= quorum -node 11.43.600.66,11.43.600.65 -rate threads=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

我试图了解 nodetool cfstats、cfhistograms 与 OpsCenter 的结果。 Opscenter 的写入和读取请求延迟 (ms/op) 的表级指标为：

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的结果不匹配？是否像写的 opscenter y 轴值，读请求延迟必须在 micros/op 而不是 ms/op 中？

版本：
卡桑德拉 2.1.8.689
OpsCenter 5.2.2

如果我错了请告诉我..!!
谢谢

【问题讨论】：

标签： cassandra opscenter nodetool cassandra-stress

【解决方案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 秒的请求平均需要 1ms。

“更好”的指标仍然有一些统计损失，但在描述延迟分布方面要好得多。这些（cfhistograms 的 opscenter 中的百分位数）通过表示桶中的延迟来更新，每个桶代表一个时间范围。此直方图在请求期间更新。在 OpsCenter 中，它每分钟跟踪一次直方图的状态，并根据差异可以确定每个时间段内发生了多少请求。这还允许在集群视图中跨节点更准确地合并数据。如果一个节点有 1000 个请求，而另一个节点有 1 个，则平均将给出一半。通过添加每个节点桶的总数，它可以更好地代表实际的延迟分布。这里仍有损失，但相对较小。每个存储桶代表一个范围，我们不知道该存储桶中的每个请求在该范围内的哪个位置发生，但它足够小以“足够好”并且足够好地代表数量级。

Nodetool cfhistograms 有几个版本需要警惕。它使用https://en.wikipedia.org/wiki/Reservoir_sampling 水库采样算法 (vitters r) 而不是直方图，该直方图基于可以用较小的数据样本表示正态分布的想法。不幸的是，延迟是一个非常重的尾非正态分布，它很容易减少几个数量级。 https://issues.apache.org/jira/browse/CASSANDRA-8662

【讨论】：