prometheus四种数据类型
Prometheus定义了4中不同的指标类型(metric type)：Counter（计数器）、Gauge（仪表盘）、Histogram（直⽅图）、
Summary（摘要）
Counter：只增不减的计数器
Counter类型的指标其⼯作⽅式和计数器⼀样，只增不减（除⾮系统发⽣重置）。常见的监控指标，如http_requests_total，node_cpu都是Counter类型的监控指标。 ⼀般在定义Counter类型指标的名称时推荐使⽤_total作为后缀。
Counter是⼀个简单但有强⼤的⼯具，例如我们可以在应⽤程序中记录某些事件发⽣的次数，通过以时序的形式存储这些数据，我们可以轻松的了解该事件产⽣速率的变化。PromQL内置的聚合操作和函数可以⽤户对这些数据进⾏进⼀步的分析：
例如，通过rate()函数获取HTTP请求量的增长率：
rate(http_requests_total[5m])
煮水
查询当前系统中，访问量前10的HTTP地址：
居家空间topk(10, http_requests_total)
Gauge：可增可减的仪表盘
与Counter不同，Gauge类型的指标侧重于反应系统的当前状态。因此这类指标的样本数据可增可减。常见指标如：
资料员工作总结node_memory_MemFree（主机当前空闲的内容⼤⼩）、node_memory_MemAvailable（可⽤内存⼤⼩）都是Gauge类型的监控指标。
通过Gauge指标，⽤户可以直接查看系统的当前状态：
node_memory_MemFree
对于Gauge类型的监控指标，通过PromQL内置函数delta()可以获取样本在⼀段时间返回内的变化情况。例如，计算CPU温度在两个⼩时内的差异：
delta(cpu_temp_celsius{host="zeus"}[2h])
还可以使⽤deriv()计算样本的线性回归模型，甚⾄是直接使⽤predict_linear()对数据的变化趋势进⾏预测。例如，预测系统磁盘空间在4个⼩时之后的剩余情况：
predict_linear(node_filesystem_free{job="node"}[1h], 4 * 3600)
使⽤Histogram和Summary分析数据分布情况
除了Counter和Gauge类型的监控指标以外，Prometheus还定义分别定义Histogram和Summary的指标类型。Histogram和Summary 主⽤⽤于统计和分析样本的分布情况。
人物画简单
在⼤多数情况下⼈们都倾向于使⽤某些量化指标的平均值，例如CPU的平均使⽤率、页⾯的平均响应时间。这种⽅式的问题很明显，以系统API调⽤的平均响应时间为例：如果⼤多数API请求都维持在100ms的响应时间范围内，⽽个别请求的响应时间需要5s，那么就会导致某些WEB页⾯的响应时间落到中位数的情况，⽽这种现象被称为长尾问题。
为了区分是平均的慢还是长尾的慢，最简单的⽅式就是按照请求延迟的范围进⾏分组。例如，统计延迟在0~10ms之间的请求数有多少⽽10~20ms之间的请求数⼜有多少。通过这种⽅式可以快速分析系统慢的原因。Histogram和Summary都是为了能够解决这样问题的存在，通过Histogram和Summary类型的监控指标，我们可以快速了解监控样本的分布情况。
超市蔬菜
例如，指标prometheus_tsdb_wal_fsync_duration_conds的指标类型为Summary。 它记录了Prometheus Server中wal_fsync处理的处理时间，通过访问Prometheus Server的/metrics地址，可以获取到以下监控样本数据：
# HELP prometheus_tsdb_wal_fsync_duration_conds Duration of WAL fsync.
# TYPE prometheus_tsdb_wal_fsync_duration_conds summary七五三
prometheus_tsdb_wal_fsync_duration_conds{quantile="0.5"} 0.012352463
prometheus_tsdb_wal_fsync_duration_conds{quantile="0.9"} 0.014458005
prometheus_tsdb_wal_fsync_duration_conds{quantile="0.99"} 0.017316173
prometheus_tsdb_wal_fsync_duration_conds_sum 2.888716127000002
prometheus_tsdb_wal_fsync_duration_conds_count 216
从上⾯的样本中可以得知当前Prometheus Server进⾏wal_fsync操作的总次数为216次，耗时2.888716127000002s。其中中位数（quantile=0.5）的耗时为0.012352463，9分位数（quantile=0.9）的耗时为0.014458005s。
在Prometheus Server⾃⾝返回的样本数据中，我们还能找到类型为Histogram的监控指标
prometheus_tsdb_compaction_chunk_range_bucket。
# HELP prometheus_tsdb_compaction_chunk_range Final time range of chunks on their first compaction
# TYPE prometheus_tsdb_compaction_chunk_range histogram
prometheus_tsdb_compaction_chunk_range_bucket{le="100"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="400"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="1600"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="6400"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="25600"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="102400"} 0李皆乐
prometheus_tsdb_compaction_chunk_range_bucket{le="409600"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="1.6384e+06"} 260
prometheus_tsdb_compaction_chunk_range_bucket{le="6.5536e+06"} 780
prometheus_tsdb_compaction_chunk_range_bucket{le="2.62144e+07"} 780
prometheus_tsdb_compaction_chunk_range_bucket{le="+Inf"} 780
prometheus_tsdb_compaction_chunk_range_sum 1.1540798e+09
prometheus_tsdb_compaction_chunk_range_count 780
与Summary类型的指标相似之处在于Histogram类型的样本同样会反应当前指标的记录的总数(以_count作为后缀)以及其值的总量（以
_sum作为后缀）。不同在于Histogram指标直接反应了在不同区间内样本的个数，区间通过标签len进⾏定义。
同时对于Histogram的指标，我们还可以通过histogram_quantile()函数计算出其值的分位数。不同在于Histogram通过
histogram_quantile函数是在服务器端计算的分位数。 ⽽Sumamry的分位数则是直接在客户端计算完成。因此对于分位数的计算⽽
⾔，Summary在通过PromQL进⾏查询时有更好的性能表现，⽽Histogram则会消耗更多的资源。反之对于客户端⽽⾔Histogram消耗的资源更少。在选择这两种⽅式时⽤户应该按照⾃⼰的实际场景进⾏选择。
>香菱本子
