排查 Kubernetes HPA 通过 Prometheus 获取不到 http_requests 指标的问题

部署好了 kube-prometheus 与 k8s-prometheus-adapter （详见之前的博文 k8s 安装 prometheus 过程记录），使用下面的配置文件部署 HPA(Horizontal Pod Autoscaling) 却失败。

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: blog-web
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: blog-web
  minReplicas: 2
  maxReplicas: 12
  metrics:
    - type: Pods
      pods:
        metric:
          name: http_requests
        target:
          type: AverageValue
          averageValue: 100

错误信息如下：

unable to get metric http_requests: unable to fetch metrics from custom metrics API: the server could not find the metric http_requests for pods

通过下面的命令查看 custom.metrics.k8s.io api 支持的 http_requests（每秒请求数QPS)监控指标：

$kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1/ | jq . | egrep pods/.*http_requests
      "name": "pods/alertmanager_http_requests_in_flight",
      "name": "pods/prometheus_http_requests"

发现只有 prometheus_http_requests 指标 ，没有所需的 http_requests 开头的指标。

打开 prometheus 控制台，发现 /service-discovery 中没有出现我们想监控的应用 blog-web ，网上查找资料后知道了需要部署 ServiceMonitor 让 prometheus 发现所监控的 service 。

添加下面的 ServiceMonitor 配置文件：

kind: ServiceMonitor
apiVersion: monitoring.coreos.com/v1
metadata:
  name: blog-web-monitor
  labels:
    app: blog-web-monitor
spec:
  selector:
    matchLabels:
      app: blog-web
  endpoints:
  - port: http

部署后还是没有被 prometheus 发现，查看 prometheus 的日志发现下面的错误：

Failed to list *v1.Pod: pods is forbidden: User \"system:serviceaccount:monitoring:prometheus-k8s\" cannot list resource \"pods\" in API group \"\" at the cluster scope

在园子里的博文 PrometheusOperator服务自动发现-监控redis样例 中找到了解决方法，将 prometheus-clusterRole.yaml 改为下面的配置：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-k8s
rules:
- apiGroups:
  - ""
  resources:
  - nodes
  - services
  - endpoints
  - pods
  - nodes/proxy
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - configmaps
  - nodes/metrics
  verbs:
  - get
- nonResourceURLs:
  - /metrics
  verbs:
  - get

重新部署即可

kubectl apply -f prometheus-clusterRole.yaml

注1：如果采用上面的方法还是没被发现，需要强制刷新 prometheus 的配置，参考 部署 ServiceMonitor 之后如何让 Prometheus 立即发现 。
注2：也可以将 prometheus 配置为自动发现 service 与 pod ，参考园子里的博文 prometheus配置pod和svc的自动发现和监控 与 PrometheusOperator服务自动发现-监控redis样例 。

但是这时还有问题，虽然 service 被 prometheus 发现了，但 service 所对应的 pod 一个都没被发现。

production/blog-web-monitor/0 (0/19 active targets)

排查后发现是因为 ServiceMonitor 与 Service 配置不对应，Service 配置文件中缺少 ServiceMonitor 配置中 matchLabels 所对应的 label ，ServiceMonitor 中的 port 没有对应 Service 中的 ports 配置，修正后的配置如下：
service-blog-web.yaml

apiVersion: v1
kind: Service
metadata:
  name: blog-web
  labels:
    app: blog-web
spec:
  type: NodePort
  selector:
    app: blog-web
  ports:
  - name: http-blog-web
    nodePort: 30080
    port: 80
    targetPort: 80

servicemonitor-blog-web.yaml

kind: ServiceMonitor
apiVersion: monitoring.coreos.com/v1
metadata:
  name: blog-web-monitor
  labels:
    app: blog-web
spec:
  selector:
    matchLabels:
      app: blog-web
  endpoints:
  - port: http-blog-web

用修正后的配置部署后，pod 终于被发现了：

production/blog-web-monitor/0 (0/5 up)

但是这些 pod 全部处于 down 状态。

Endpoint                          State  Scrape Duration    Error
http://192.168.107.233:80/metrics DOWN   server returned HTTP status 400 Bad Request

通过园子里的博文 使用Kubernetes演示金丝雀发布 知道了原来需要应用自己提供 metrics 监控指标数据让 prometheus 抓取。

标准Tomcat自带的应用没有/metrics这个路径，prometheus获取不到它能识别的格式数据，而指标数据就是从/metrics这里获取的。所以我们使用标准Tomcat不行或者你就算有这个/metrics这个路径，但是返回的格式不符合prometheus的规范也是不行的。

我们的应用是用 ASP.NET Core 开发的，所以选用了 prometheus-net ，由它提供 metrics 数据给 prometheus 抓取。

  • 安装 nuget 包
dotnet add package prometheus-net.AspNetCore
  • 添加 HttpMetrics 中间件
app.UseRouting();
app.UseHttpMetrics();
  • 添加 MapMetric 路由
app.UseEndpoints(endpoints =>
{
   endpoints.MapMetrics();
};

当通过下面的命令确认通过 /metrics 路径可以获取监控数据时，

$ docker exec -t $(docker ps -f name=blog-web_blog-web -q | head -1) curl 127.0.0.1/metrics | grep http_request_duration_seconds_sum
http_request_duration_seconds_sum{code="200",method="GET",controller="AggSite",action="SiteHome"} 0.44973779999999997
http_request_duration_seconds_sum{code="200",method="GET",controller="",action=""} 0.0631272

Prometheus 控制台 /targets 页面就能看到 blog-web 对应的 pod 都处于 up 状态。

production/blog-web-monitor/0 (5/5 up)

这时通过 custom metrics api 可以查询到一些 http_requests 相关的指标。

$ kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1/ | jq . | egrep pods/*/http_requests
      "name": "pods/http_requests_in_progress",
      "name": "pods/http_requests_received"

这里的 http_requests_received 就是 QPS（每秒请求数） 指标数据，用下面的命令请求 custom metrics api 获取数据：

kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1/namespaces/production/pods/*/http_requests_received | jq .

其中1个 pod 的 http_requests_received 指标数据如下：

{
  "kind": "MetricValueList",
  "apiVersion": "custom.metrics.k8s.io/v1beta1",
  "metadata": {
    "selfLink": "/apis/custom.metrics.k8s.io/v1beta1/namespaces/production/pods/%2A/http_requests_received"
  },
  "items": [
    {
      "describedObject": {
        "kind": "Pod",
        "namespace": "production",
        "name": "blog-web-65f7bdc996-8qp5c",
        "apiVersion": "/v1"
      },
      "metricName": "http_requests_received",
      "timestamp": "2020-01-18T14:35:34Z",
      "value": "133m",
      "selector": null
    }
  ]
}

其中的 133m 表示 0.133 。

然后就可以在 HPA 配置文件中基于这个指标进行自动伸缩

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: blog-web
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: blog-web
  minReplicas: 5
  maxReplicas: 12
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_received
      target:
        type: AverageValue
        averageValue: 100

终于搞定了！

# kubectl get hpa
NAME       REFERENCE             TARGETS    MINPODS   MAXPODS   REPLICAS   AGE
blog-web   Deployment/blog-web   133m/100   5         12        5          4d

原文地址：https://www.cnblogs.com/dudu/p/12197646.html

时间： 2024-07-30 13:05:36

排查 Kubernetes HPA 通过 Prometheus 获取不到 http_requests 指标的问题的相关文章

探索 Kubernetes HPA

作者:魔方云,原文链接 HPA简介 HPA(Horizontal Pod Autoscaler)是kubernetes(以下简称k8s)的一种资源对象,能够根据某些指标对在statefulSet.replicaController.replicaSet等集合中的pod数量进行动态伸缩,使运行在上面的服务对指标的变化有一定的自适应能力. HPA目前支持四种类型的指标,分别是Resource.Object.External.Pods.其中在稳定版本autoscaling/v1中只支持对CPU指标的动

kubernetes生态--交付prometheus监控及grafana炫酷dashboard到k8s集群

由于docker容器的特殊性,传统的zabbix无法对k8s集群内的docker状态进行监控,所以需要使用prometheus来进行监控: 什么是Prometheus? Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB).Prometheus使用Go语言开发,是Google BorgMon监控系统的开源版本. 2016年由Google发起Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation), 将Prom

Kubernetes实战总结 - Prometheus部署

什么是普罗米修斯? Prometheus是最初在SoundCloud上构建的开源系统监视和警报工具包 . 自2012年成立以来,许多公司和组织都采用了Prometheus,该项目拥有非常活跃的开发人员和用户社区. 组件说明 MetricServer:是kubernetes集群资源使用情况的聚合器,收集数据给kubernetes集群内使用,如kubectl,hpa,scheduler等. PrometheusOperator:是一个系统监测和警报工具箱,用来存储监控数据. NodeExporter

Kubernetes 弹性伸缩全场景解析（三） - HPA 实践手册

在上一篇文章中,给大家介绍和剖析了 HPA 的实现原理以及演进的思路与历程.本文我们将会为大家讲解如何使用 HPA 以及一些需要注意的细节. autoscaling/v1 实践 v1 的模板可能是大家平时见到最多的也是最简单的,v1 版本的 HPA 只支持一种指标 ——  CPU.传统意义上,弹性伸缩最少也会支持 CPU 与 Memory 两种指标,为什么在 Kubernetes 中只放开了 CPU 呢?其实最早的 HPA 是计划同时支持这两种指标的,但是实际的开发测试中发现:内存不是一个非常好

Kubernetes 监控方案之 Prometheus Operator(十七)

目录 一.Prometheus 介绍 1.1.Prometheus 架构 1.2.Prometheus Operator 架构 二.安装部署 2.1.安装 一.Prometheus 介绍 Prometheus Operator 是 CoreOS 开发的基于 Prometheus 的 Kubernetes 监控方案,也可能是目前功能最全面的开源方案. Prometheus Operator 通过 Grafana 展示监控数据,预定义了一系列的 Dashboard 1.1.Prometheus 架构

Kubernetes系列之Kubernetes的弹性伸缩（HPA）

###前言在kubernetes中,我们使用pod对外提供服务.这时候,我们需要以下两种情形需要关注: Pod因为不明原因挂掉,导致服务不可用Pod在高负荷的情况下,不能支撑我们的服务 如果我们人工监控pods,人工进行调整副本那么这个工作量无疑是巨大的,但kubernetes已经有了相应的机制来应对了. ###HPA全称Horizontal Pod Autoscaler控制器工作流程(V1版本) 更详细的介绍参考官方文档Horizontal Pod Autoscaler 流程 创建HPA资源对

从Spring Cloud到Kubernetes的微服务迁移实践

写在前面 要出发周边游(以下简称要出发)是国内知名的主打「周边游」的在线旅行网站,为了降低公司内部各个业务模块的耦合度,提高开发.交付及运维效率,我们在 2017 年就基于 Spring Cloud 完成了公司内部业务微服务化的改造,并在 2019 年实现了 Spring Cloud 至 UK8S 平台的迁移.? 本文从要出发的业务架构.Prometheus JVM 监控.基于 HPA 的峰值弹性伸缩.基于 Elastic 的APM链路跟踪及 Istio 服务治理等方面介绍了我们基于UK8S的

我听说，Prometheus与技术中台更配哦

前言 随着容器技术这几年的迅速发展,Kubernetes已经逐渐成为云生态圈CNCF(Cloud Native Computing Foundation)当之无愧的老大.而Prometheus稳坐CNCF基金会的"第二把交椅",已然成为Kubernetes群集监控系统的必要组成部分. 现在有越来越多的企业,有意向或正在由传统技术基础架构向云环境迁移.在开源监控系统方面,企业有Zabbix.Prometheus等系统可以选择.不可否认,Zabbix的产品成熟度很高,同时也与时俱进,且仍然

Kubernetes为什么使用静态调度

Kubernetes为什么使用静态调度 静态调度,是指根据容器请求的资源进行装箱调度,而不考虑节点的实际负载.静态调度最大的优点就是调度简单高效.集群资源管理方便,最大的缺点也很明显,就是不管节点实际负载,极容易导致集群负载不高. Kubernetes为什么会使用静态调度呢?因为要做好通用的动态调度几乎是不可能的,对,是通用的动态调度很难都满足不同企业不同业务的诉求,结果可能适得其反.那是不是我们就没必要去往动态调度做技术尝试呢?未必!平台根据托管的业务属性,可以适当的通过scheduler e