API Server 监控

API Server 是 Kubernetes 集群中所有组件交互的中枢。下表列出了 API Server 的主要监控指标。

指标	描述
请求延迟	资源请求响应延迟，单位为毫秒。该指标按照 HTTP 请求方法进行分类。 It’s a good idea to use percentiles to understand the latency spread: histogram_quantile(0.99, sum(rate(apiserver_request_latencies_count{job="kubernetes-apiservers"}[5m])) by (verb, le))
每秒请求次数	kube-apiserver 每秒接受的请求数。

指标

描述

请求延迟

资源请求响应延迟，单位为毫秒。该指标按照 HTTP 请求方法进行分类。

It’s a good idea to use percentiles to understand the latency spread:

histogram_quantile(0.99, sum(rate(apiserver_request_latencies_count{job="kubernetes-apiservers"}[5m])) by (verb, le))

每秒请求次数

kube-apiserver 每秒接受的请求数。

Histogram

摘要非常有用，但是平均值会隐藏一些细节，如果我们想查看时间花在什么地方了，那么我们就需要直方图了。

直方图以 bucket 桶的形式记录数据，所以我们可能有一个桶用于需要 1s 或更少的计算，另一个桶用于 5 秒或更少、10 秒或更少、20 秒或更少、60 秒或更少。该指标返回每个存储桶的计数，其中 3 个在 5 秒或更短的时间内完成，6 个在 10 秒或更短的时间内完成。

Prometheus 中的直方图是累积的，因此所有 10 次计算都属于 60 秒或更少的时间段，而在这 10 次中，有 9 次的处理时间为 20 秒或更少，这显示了数据的分布。所以可以看到我们的大部分计算都在 10 秒以下，只有一个超过 20 秒，这对于计算百分位数很有用。

在 Prometheus Server 自身返回的样本数据中，我们也能找到类型为 Histogram 的监控指标prometheus_tsdb_compaction_chunk_range_seconds_bucket：可以看到这个值是一直增加的，因为是累计增加的，因为1600是包含前面400和100的。

# HELP prometheus_tsdb_compaction_chunk_range_seconds Final time range of chunks on their first compaction
# TYPE prometheus_tsdb_compaction_chunk_range_seconds histogram
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="100"} 71
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="400"} 71
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="1600"} 71
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="6400"} 71
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="25600"} 405
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="102400"} 25690
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="409600"} 71863
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="1.6384e+06"} 115928
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="6.5536e+06"} 2.5687892e+07
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="2.62144e+07"} 2.5687896e+07
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="+Inf"} 2.5687896e+07
prometheus_tsdb_compaction_chunk_range_seconds_sum 4.7728699529576e+13
prometheus_tsdb_compaction_chunk_range_seconds_count 2.5687896e+07

Histogram vs Summary

与 Summary 类型的指标相似之处在于 Histogram 类型的样本同样会反应当前指标的记录的总数(以 _count 作为后缀)以及其值的总量（以 _sum 作为后缀）。

不同在于 Histogram 指标直接反应了在不同区间内样本的个数，区间通过标签 le 进行定义。histogram有专门的函数去计算。

直方图

在这一节中，我们将学习直方图指标，了解如何根据这些指标来计算分位数。Prometheus 中的直方图指标允许一个服务记录一系列数值的分布。

直方图通常用于跟踪请求的延迟或响应大小等指标值，当然理论上它是可以跟踪任何根据某种分布而产生波动数值的大小。Prometheus 直方图是在客户端对数据进行的采样，它们使用的一些可配置的（例如延迟）bucket 桶对观察到的值进行计数，然后将这些 bucket 作为单独的时间序列暴露出来。

下图是一个非累积直方图的例子：（x轴是区间，y轴对应的是值。，统计的是每个区间里面的个数，一个区间就是一个bucket，比如0-25是一个bucket，25-50也是一个bucket。25-50这个区间值是40，这个40可能是延时时长也可能是响应大小，得看具体的值）

在 Prometheus 内部，直方图被实现为一组时间序列（不是单个的，0-25实际上代表一个bucket桶，但是在Prometheus也是一个时间序列，25-50 50-100 100-25都是序列），每个序列代表指定桶的计数（例如25ms以下的请求数20个、50ms以下的请求数20+40个、100ms以下的请求数20+40+30等）。

在 Prometheus 中每个 bucket 桶的计数器是累加的，这意味着较大值的桶也包括所有低数值的桶的计数。（后面的时间序列包含前面时间序列值的）

在作为直方图一部分的每个时间序列上，相应的桶由特殊的 le 标签表示。le 代表的是小于或等于。

与上面相同的直方图在 Prometheus 中的累积直方图如下所示：

可以看到在 Prometheus 中直方图的计数是累计的，这是很奇怪的，因为通常情况下非累积的直方图更容易理解。Prometheus 为什么要这么做呢？

想象一下，如果直方图指标中加入了额外的标签，或者划分了更多的 bucket，那么样本数据的分析就会变得越来越复杂，如果直方图是累积的，在抓取指标时就可以根据需要丢弃某些 bucket，这样可以在降低 Prometheus 维护成本的同时，还可以粗略计算样本值的分位数。(有些时候区间需要划分的更加细粒度，但是真正来抓取这些指标的时候，这些细粒度的可对我们意义不是特别大，那么我们之间丢弃就行了。丢弃了之后不会影响后面去计算的一些值。如果是非累计直方图，如果将前面的丢弃了，那么小于100区间的请求就不能获取了，只知道50-100之间，0-50的被丢弃了)通过这种方法，用户不需要修改应用代码，便可以动态减少抓取到的样本数量。

另外直方图还提供了 _sum 指标和 _count 指标，所以即使你丢弃了所有的 bucket，仍然可以通过这两个指标值来计算请求的平均响应时间。通过累积直方图的方式，还可以很轻松地计算某个 bucket 的样本数占所有样本数的比例。

我们在演示的 demo 服务中暴露了一个直方图指标 demo_api_request_duration_seconds_bucket，用于跟踪 API 请求时长的分布，由于这个直方图为每个跟踪的维度导出了 26 个 bucket，因此这个指标有很多时间序列。我们可以先来看下来自一个服务实例的一个请求维度组合的直方图，查询语句如下所示：

demo_api_request_duration_seconds_bucket{instance="demo-service-0:10000", method="POST", path="/api/bar", status="200", job="demo"}

正常我们可以看到 26 个序列，每个序列代表一个 bucket，由 le 标签标识：(所有bucket的值加起来等于+inf的值，都包含进去了)

直方图可以帮助我们了解这样的问题，比如"我有多少个请求超过了100ms的时间？" (当然需要直方图中配置了一个以 100ms 为边界的桶)，又比如"我99%的请求是在多少延迟下完成的？"，这类数值被称为百分位数或分位数。在 Prometheus 中这两个术语几乎是可以通用，只是百分位数指定在 0-100 范围内，而分位数表示在 0 和 1 之间，所以第 99 个百分位数相当于目标分位数 0.99。

如果你的直方图桶粒度足够小，那么我们可以使用 histogram_quantile(φ scalar, b instant-vector) 函数用于计算历史数据指标一段时间内的分位数。该函数将目标分位数 (0 ≤ φ ≤ 1) 和直方图指标作为输入，就是大家平时讲的 pxx，p50 就是中位数，参数 b 一定是包含 le 这个标签的瞬时向量，不包含就无从计算分位数了，但是计算的分位数是一个预估值，并不完全准确，因为这个函数是假定每个区间内的样本分布是线性分布来计算结果值的，预估的准确度取决于 bucket 区间划分的粒度，粒度越大，准确度越低。

回到我们的演示服务，我们可以尝试计算所有维度在所有时间内的第 90 个百分位数，也就是 90% 的请求的持续时间。

# BAD!
histogram_quantile(0.9, demo_api_request_duration_seconds_bucket{job="demo"})

但是这个查询方式是有一点问题的，当单个服务实例重新启动时，bucket 的 Counter 计数器会被重置，而且我们常常想看看现在的延迟是多少（比如在过去 5 分钟内），而不是整个时间内的指标。我们可以使用 rate() 函数应用于底层直方图计数器来实现这一点，该函数会自动处理 Counter 重置，又可以只计算每个桶在指定时间窗口内的平均增长。

我们可以这样去计算过去 5 分钟内第 90 个百分位数的 API 延迟：

# GOOD!
histogram_quantile(0.9, rate(demo_api_request_duration_seconds_bucket{job="demo"}[5m]))

这个查询就好很多了。

这个查询会显示每个维度（job、instance、path、method 和 status）的第 90 个百分点，但是我们可能对单独的这些维度并不感兴趣，想把他们中的一些指标聚合起来，这个时候我们可以在查询的时候使用 Prometheus 的 sum 运算符与 histogram_quantile() 函数结合起来，计算出聚合的百分位，假设在我们想要聚合的维度之间，直方图桶的配置方式相同（桶的数量相同，上限相同），我们可以将不同维度之间具有相同 le 标签值的桶加在一起，得到一个聚合直方图。然后，我们可以使用该聚合直方图作为 histogram_quantile() 函数的输入。

注意：这是假设直方图的桶在你要聚合的所有维度之间的配置是相同的，桶的配置也应该是相对静态的配置，不会一直变化，因为这会破坏你使用 histogram_quantile() 查看的时间范围内的结果。

下面的查询计算了第 90 个百分位数的延迟，但只按 job，le，instance 和 path 维度进行聚合结果：

计算完分位数之后le标签就不存在了。

如果不是特别理解histogram_quantile计算出来值的话，只需要记住，前面这个是分位数，计算的是90个分位数，后面是一个瞬时的向量，而且一定要包含le这个标签的。

练习：

1.构建一个查询，计算在 0.0001 秒内完成的 demo 服务 API 请求的总百分比，与过去 5 分钟内所有请求总数的平均值。
sum(rate(demo_api_request_duration_seconds_bucket{le="0.0001"}[5m]))
/
sum(rate(demo_api_request_duration_seconds_bucket{le="+Inf"}[5m])) * 100
或者可以使用下面的语句查询
sum(rate(demo_api_request_duration_seconds_bucket{le="0.0001"}[5m]))
/sum(rate(demo_api_request_duration_seconds_count[5m])) * 100
2.构建一个查询，计算 demo 服务 API 请求的第 50 个百分位延迟，按 status code 和 method 进行划分，在过去一分钟的平均值。
histogram_quantile(0.5, sum by(status, method, le) (rate(demo_api_request_duration_seconds_bucket[1m])))

PromQL 直方图跟踪请求的延迟或响应大小 99%的请求是在多少延迟下完成的？相关推荐

java实现请求发送_java实现响应重定向发送post请求操作示例
本文实例讲述了java实现响应重定向发送post请求操作.分享给大家供大家参考,具体如下: 关于重定向我们用的比较多的还是redirect:重定向,默认发送的get请求. return "r ...
http详解请求报文格式和响应报文格式
题外话: <Pi Network 免费挖矿国外热门项目一个π币大约值3元到10元>相信过去BTC的人,信不信未来的PI,了解一下,唯一一个高度与之持平的项目 HTTP 工作原理超文本传 ...
php设置http请求头信息和响应头信息
php设置http请求头信息和响应头信息设置请求服务器的头信息可以用fsockopen,curl组件,header函数只能用来设置客户端响应的头信息,不能设置服务器的头信息. 例子; 一.heade ...
【项目学习】C++实现高并发服务器——代码学习（二）存储解析HTTP请求报文，创建响应报文
项目来源:WebServer 上一篇:Reactor高并发模型本文介绍以下功能的代码实现利用标准库容器封装char,实现自动增长的缓冲区: 利用正则与状态机解析HTTP请求报文,实现处理静态资源的 ...
Http请求报文格式和响应报文格式
HTTP请求报文格式客户端连上服务器后,向服务器发出获取某个Web资源的消息,称之为客户端向服务器发送了一个HTTP请求. HTTP请求报文主要由请求行.请求头部.请求正文3部分组成.例如,GET ...
vue中的请求拦截器与响应拦截器的使用
之前讲到在项目中封装了axios,vue中对axios封装就有了request.js这个文件,那么在这个文件中就可以写请求拦截器与响应拦截器. 请求拦截器: 请求拦截器的作用是在请求发送前进行一些操 ...
HTTP请求报文和HTTP响应报文(转)
原文地址:http://blog.csdn.net/zhangliang_571/article/details/23508953 HTTP报文是面向文本的,报文中的每一个字段都是一些ASCII码串, ...
IIS弹出服务没有及时响应启动或控制请求
前些日子IIS都还可以正常运转,今天突然打开WebSerivce发现不能正常打开,然后就在 "开始"-->"运行"中输入inetmgr,打开Interne ...
Oracle错误 1053：该服务没有响应启动或控制请求
在服务中,启动oracleDBConsolenewdb服务时,出现了错误 1053: 该服务没有响应启动或控制请求在网上查了以后你会发现这是一个非常宽泛的错误,然而我们的建议是去看传说中的orac ...

PromQL 直方图跟踪请求的延迟或响应大小 99%的请求是在多少延迟下完成的？

API Server 监控

Histogram

直方图

PromQL 直方图跟踪请求的延迟或响应大小 99%的请求是在多少延迟下完成的？相关推荐

最新文章

热门文章

PromQL 直方图 跟踪请求的延迟或响应大小 99%的请求是在多少延迟下完成的？

API Server 监控

Histogram

直方图

PromQL 直方图 跟踪请求的延迟或响应大小 99%的请求是在多少延迟下完成的？相关推荐

最新文章

热门文章

PromQL 直方图跟踪请求的延迟或响应大小 99%的请求是在多少延迟下完成的？

PromQL 直方图跟踪请求的延迟或响应大小 99%的请求是在多少延迟下完成的？相关推荐