Counter（计数器）模型
计数器是一个累积指标，单调递增，其值仅能增长或重置为0。类似于“服务请求数”、“任务完成数”和“错误数”等可以使用计数器模型，而“进程数”等可能会出现下降的指标不适合使用计数器模型
Gauge（数值）模型
数值模型代表了简单的整形或非整形数字值，值可任意上升或下降。类似于“温度”、“内存使用率”等可以使用数值模型。
Histogram（直方图）模型
直方图模型比较复杂，用于对监控数据的采样，这里的采样指的是你不需要完整的记录全部监控数据就可以获取一些统计指标。以“请求响应时间”为例，通过直方图模型可以获取平均响应时间，请求次数，甚至是响应时间按比例的分布情况。
如何实现的呢？Histogram记录了几个关键数据：
- 总数据条数 count，例如请求次数
- 数据值汇总 sum，例如响应时间综合
- 各数据值范围内的数据条数 bucket count，例如
0~100ms的请求有20个、100~200ms的请求由30个，数据值范围被称为bucket，bucket可自由设定
数据结构大概是这个样子
# HELP rpc_durations_histogram_seconds RPC latency distributions.
# TYPE rpc_durations_histogram_seconds histogram
rpc_durations_histogram_seconds_bucket{le="-0.00099"} 0
rpc_durations_histogram_seconds_bucket{le="-0.00089"} 0
rpc_durations_histogram_seconds_bucket{le="-0.0007899999999999999"} 0
rpc_durations_histogram_seconds_bucket{le="-0.0006899999999999999"} 5
rpc_durations_histogram_seconds_bucket{le="-0.0005899999999999998"} 18
rpc_durations_histogram_seconds_bucket{le="-0.0004899999999999998"} 98
rpc_durations_histogram_seconds_bucket{le="-0.0003899999999999998"} 422
rpc_durations_histogram_seconds_bucket{le="-0.0002899999999999998"} 1245
rpc_durations_histogram_seconds_bucket{le="-0.0001899999999999998"} 2927
rpc_durations_histogram_seconds_bucket{le="-8.999999999999979e-05"} 5520
rpc_durations_histogram_seconds_bucket{le="1.0000000000000216e-05"} 8845
rpc_durations_histogram_seconds_bucket{le="0.00011000000000000022"} 12333
rpc_durations_histogram_seconds_bucket{le="0.00021000000000000023"} 15034
rpc_durations_histogram_seconds_bucket{le="0.0003100000000000002"} 16696
rpc_durations_histogram_seconds_bucket{le="0.0004100000000000002"} 17452
rpc_durations_histogram_seconds_bucket{le="0.0005100000000000003"} 17749
rpc_durations_histogram_seconds_bucket{le="0.0006100000000000003"} 17840
rpc_durations_histogram_seconds_bucket{le="0.0007100000000000003"} 17862
rpc_durations_histogram_seconds_bucket{le="0.0008100000000000004"} 17866
rpc_durations_histogram_seconds_bucket{le="0.0009100000000000004"} 17866
rpc_durations_histogram_seconds_bucket{le="+Inf"} 17866
rpc_durations_histogram_seconds_sum 0.17511515233805508
rpc_durations_histogram_seconds_count 17866
除了平均值、总和这样比较简单的统计值外，Histogram还提供了Apdex（满意度）和Quantiles（百分占比）这样高级的统计方法。
Apdex常用来代表用户满意度，以响应时间为例，设定某一时间阈值T为用户完全满意，则4T代表用户完全无法忍受，T~4T代表用户略为不满，单次请求响应时间小于T得1分，大于4T得0分，T~4T得0.5分，所有分值求平均即为Apdex，约接近1代表用户满意度越高。套用Histogram模型，小于T的count为a，小于4T的count为b，总count为c，则apdex=(a+b)/2/c
Quantiles代表不同数值的百分占比，比如90%的请求响应时间小于哪个值，类似于percentline
summary（汇总）模型
与histogram模型类似，summary模型也是用来对监控数据进行采样的，区别在于histogram统计的是各个bucket内数据的个数（Count），而summary统计的是不同Quantiles的值，数据结构大概是这个样子
# HELP rpc_durations_seconds RPC latency distributions.
# TYPE rpc_durations_seconds summary
rpc_durations_seconds{service="exponential",quantile="0.5"} 8.061037124684969e-07
rpc_durations_seconds{service="exponential",quantile="0.9"} 2.3397222029430324e-06
rpc_durations_seconds{service="exponential",quantile="0.99"} 4.5890358621042235e-06
rpc_durations_seconds_sum{service="exponential"} 0.02676656013791554
rpc_durations_seconds_count{service="exponential"} 26836
rpc_durations_seconds{service="normal",quantile="0.5"} 2.0027285858645033e-05
rpc_durations_seconds{service="normal",quantile="0.9"} 0.00027552023061180175
rpc_durations_seconds{service="normal",quantile="0.99"} 0.00048129683518079587
rpc_durations_seconds_sum{service="normal"} 0.17511515233805508
rpc_durations_seconds_count{service="normal"} 17866
rpc_durations_seconds{service="uniform",quantile="0.5"} 8.919043658000242e-05
rpc_durations_seconds{service="uniform",quantile="0.9"} 0.00017954262339800665
rpc_durations_seconds{service="uniform",quantile="0.99"} 0.0001980928237747443
rpc_durations_seconds_sum{service="uniform"} 1.3429687752363637
rpc_durations_seconds_count{service="uniform"} 13391
即表示一共采集了1000个样本，这些样本总和为29969.50000000001，其中50%的样本值低于31.1，90%的样本值低于41.3，99%的样本值低于41.9
histogram与summary的区别
histogram与summary的区别主要在于quantiles，百分占比在监控中是一个很重要的统计维度，以请求响应时间为例，仅仅知道平均响应时间是不够的，我们常常还需要90%、95%的请求落在什么响应时间范围内，以更好的掌握响应时间的整体分布。
两者根本的区别在于summary模型在监控数据的采集端计算quantiles，histograms则是在数据的分析端根据bucket count计算。
| 对比项 | Histogram | Summary |
|---|---|---|
| 配置要求 | 根据期望的数据范围设置合适的bucket | 根据期望的占比设置合适的quantile，未设置的quantile将无法再计算 |
| 数据采集端性能 | 性能要求很低，因为只需要简单的统计次数 | 性能要求较高，因为需要实时计算百分比 |
| 数据分析端性能 | 性能要求高，计算耗时可能较高 | 性能要求低 |
| Quantile统计误差 | 取决于bucket设定的数据范围 | 取决于预先设定的Quantile |
| 数据聚合 | 可聚合 | 一般情况下不能聚合 |
可以看出来histogram的灵活度更高，尤其是监控数据分散在多个节点，又需要将各个节点的数据汇总起来计算quantiles时，summary的方式是不可行的。
Quantiles（百分占比）统计误差
无论采用哪种方式计算Quantiles都会存在误差，以请求响应时间举例：
histogram的方式下，假设请求响应时间均为220ms，而bucket设置为200ms和300ms，我们需要知道95%的请求在多少ms以内。histogram模型只能保证95th percentline在200ms和300ms之间，并且会通过线性拟合的方式估算95th percentline具体是多少，这就产生了误差。
summary的方式似乎是没有误差的，只要数据采集端的算法正确就应该是准确的，但是如果你需要从多个节点汇总聚合数据，summary的方式是不支持的。
所以选用histogram还是summary需要结合监控数据的特点，但有一点可以确定，如果你需要数据聚合，就需要选择histogram了。
