教你使用Prometheus-Operator进行K8s集群监控
本文分享自华为云社区《Promethues-operator入门使用指导》,作者:可以交个朋友。
一、 背景
在非operator配置的普罗中我们监控k8s集群都是通过配置configmap进行服务发现和指标拉取。切换到prometheus-operator难免会有些使用问题。不少用户已经习惯底层配置自动发现的方式。当过渡到servicemonitor或者podmonitor或多或少不习惯。所以下面就为大家介绍一下Prometheus-Operator,以及servicemonitor的使用方法
二、 Prometheus-Operator介绍
Prometheus Operator 为 Kubernetes 提供了对 Prometheus 相关监控组件的本地部署和管理方案,该项目的目的是为了简化和自动化基于 Prometheus 的监控栈配置,主要包括以下几个功能:
-
kubernetes自定义资源:使用kubernetes CRD 来部署和管理Prometheus,Alertmanager和相关组件
-
简化的部署配置:直接通过kubernetes资源清单配置Prometheus,比如版本,持久化,副本,保留策略等等配置
-
Prometheus监控目标配置:基于熟知的kubernetes标签查询自动生成监控目标配置,无需学习prometheus特地的配置
2.1 架构
下图是 Prometheus-Operator 官方提供的架构图,各组件以不同的方式运行在 Kubernetes 集群中,其中 Operator 是最核心的部分,作为一个控制器,它会去创建 Prometheus、ServiceMonitor、AlertManager以及 PrometheusRule 等 CRD 资源对象,然后会一直 Watch 并维持这些资源对象的状态。
下面三个yaml文件 很好的表述了,prometheus 如何关联选择 servicemonitor,servicemonitor 如何关联选择目标service。
为了能让prom监控k8s内的应用,Prometheus-Operator通过配置servicemonitor匹配到由service对象自动填充的Endpoints,并配置prometheus监控这些Endpoints后端的pods,ServiceMonitor.Spec的Endpoints部分就是用于配置Endpoints的哪些端口将被scrape指标。
servicemonitor对象很巧妙,它解耦了“监控的需求”和“需求的实现方”。servicemonitor 只需要用到label-selector 这种简单又通用的方式声明一个 “监控需求”,也就是哪些Endpoints 需要搜集,怎么收集就行了。让用户只关心需求,这是一个非常好的关注点分离。当然servicemonitor 最后还是会被operator转化为原始的复 杂的scrape config,但这个复杂度已经完全被operator屏蔽了。
下图很好的展现了prometheus在配置报警时需要操作哪些资源,及各资源起到的作用
首先通过配置servicemonitor/podmonitor来获取应用的监控指标;
Prometheus.spec.alerting字段会匹配Alertmanager中的配置,匹配到alertmanager实例
然后通过prometheusrule对监控到的指标配置报警规则;
最后配置告警接收器,配置alertmanagerconfig来配置如何处理告警,包括如何接收、路由、抑制和发送警报等;
2.2 常见CRD
Prometheus,定义了所需的 Prometheus 部署。
ServiceMonitor,以声明方式指定应如何监控 Kubernetes 服务组。Operator 根据 API 服务器中对象的当前状态自动生成 Prometheus 抓取配置。
PodMonitor,以声明方式指定应如何监控 pod 组。Operator 根据 API 服务器中对象的当前状态自动生成 Prometheus 抓取配置。
PrometheusRule,定义了一组所需的 Prometheus 警报和/或记录规则。Operator 生成一个规则文件,可供 Prometheus 实例使用。
Alertmanager,定义了所需的 Alertmanager 部署。
AlertmanagerConfig,以声明方式指定 Alertmanager 配置的子部分,允许将警报路由到自定义接收器并设置禁止规则。
Probe,以声明方式指定应如何监视入口组或静态目标。Operator 根据定义自动生成 Prometheus scrape 配置。配合blackbox exporter使用。
ThanosRuler,定义了所需的 Thanos Ruler 部署。
三、 Prometheus-Operator安装
Prometheus-Operator对K8S集群的版本有要求,请参照集群版本选择对应Prometheus-Operator版本代码库:https://github.com/prometheus-operator/kube-prometheus
本文档所用环境为1.25k8s集群对应0.12.0版本https://github.com/prometheus-operator/kube-prometheus/archive/refs/heads/release-0.12.zip
3.1 安装
wget https://github.com/prometheus-operator/kube-prometheus/archive/refs/heads/release-0.12.zip unzip release-0.12.zip cd kube-prometheus-release-0.12 kubectl apply --server-side -f manifests/setup kubectl wait \ --for condition=Established \ --all CustomResourceDefinition \ --namespace=monitoring kubectl apply -f manifests/
#注意:kube-state-metrics和prometheus-adapter的镜像为谷歌官方库的镜像,国内可能存在拉取不到的问题,如果由于镜像拉取不到导致pod pending,请将其替换成可获取到的镜像地址。
3.2 卸载
注意:此步骤为卸载步骤,如果想继续保留Prometheus-Operator,请不要执行此步骤kubectl delete --ignore-not-found=true -f manifests/ -f manifests/setup
四、使用servicemonitor监控应用暴露的指标
创建deployment对象和service资源,该服务8080端口会暴露自身指标。
apiVersion: apps/v1 kind: Deployment metadata: labels: app: sample-metrics-app name: sample-metrics-app spec: replicas: 2 selector: matchLabels: app: sample-metrics-app template: metadata: labels: app: sample-metrics-app spec: tolerations: - key: beta.kubernetes.io/arch value: arm effect: NoSchedule - key: beta.kubernetes.io/arch value: arm64 effect: NoSchedule - key: node.alpha.kubernetes.io/unreachable operator: Exists effect: NoExecute tolerationSeconds: 0 - key: node.alpha.kubernetes.io/notReady operator: Exists effect: NoExecute tolerationSeconds: 0 containers: - image: luxas/autoscale-demo:v0.1.2 name: sample-metrics-app ports: - name: web containerPort: 8080 readinessProbe: httpGet: path: / port: 8080 initialDelaySeconds: 3 periodSeconds: 5 livenessProbe: httpGet: path: / port: 8080 initialDelaySeconds: 3 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: sample-metrics-app labels: app: sample-metrics-app spec: ports: - name: web port: 80 targetPort: 8080 selector: app: sample-metrics-app
创建servicemonitor对象采集应用指标
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: sample-metrics-app labels: service-monitor: sample-metrics-app spec: selector: matchLabels: app: sample-metrics-app # 匹配标签为app:sample-metrics-app的service endpoints: - port: web #Promethues采集指标的端口为service中portName表示的端口
查看新建的service,在集群内节点上通过service IP访问应用kubectl get service
通过访问service IP的metrics接口可以查看到应用暴露的指标curl 10.247.227.116/metrics
可以看到,应用暴露的指标是 “http_requests_total” ,且监控采集到的数量是805
浏览器访问Prometheus UI界面查看指标通过IP和端口访问prometheus-server,查看servermonitor及指标监控情况

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
TCP连接断开:为什么要挥手四次
本文分享自华为云社区《解密TCP连接断开:四次挥手的奥秘和数据传输的安全》,作者: 努力的小雨 。 TCP 连接断开 在当今数字化时代,互联网已经成为了人们生活中不可或缺的一部分。而在互联网的基础之上,TCP协议扮演着关键的角色,它负责着数据在网络中的可靠传输。在TCP连接的建立过程中,我们已经了解了三次握手的过程和原理。然而,连接的建立只是TCP协议的一部分,同样重要的是连接的断开过程。本文将重点探讨TCP连接的断开过程,包括四次挥手的过程和状态变迁,以及为什么挥手需要四次和为什么需要TIME_WAIT状态。通过深入理解TCP连接断开的过程,我们可以更好地理解网络通信的原理 TCP 四次挥手过程和状态变迁 TCP断开连接需要通过四次挥手的方式。双方都有能力主动断开连接,一旦断开连接,主机中的各种「资源」将被释放。那么我们将详细讲解下TCP四次挥手的原理及过程! 当客户端打算关闭连接时,它会发送一个TCP首部中FIN标志位被置为1的报文,即FIN报文。随后,客户端进入FIN_WAIT_1状态。 当服务端收到该报文后,会向客户端发送一个ACK应答报文,并进入CLOSED_WAIT状态。 ...
- 下一篇
FQS:一种神奇的数仓查询优化技术
本文分享自华为云社区《根据执行计划优化SQL【绽放吧!GaussDB(DWS)云原生数仓】》,作者:西岭雪山。 引言 如果您刚接触DWS那一定会好奇想要知道"REMOTE_FQS_QUERY" 到底代表什么意思?我们看官网的描述是代表这执行计划已经CN直接将原语句下发到DN,各DN单独执行,并将执行结果在CN上进行汇总。且不需要做过多的调整了,真的是这样吗? FQS计划,完全下推 两表JOIN,且其连接条件为各表的分布列,在关闭stream算子的情况下,CN会直接将该语句发送至各DN执行,最后结果在CN汇总。 SET enable_stream_operator=off; SET explain_perf_mode=normal; EXPLAIN (VERBOSE on,COSTS off) SELECT * FROM tt01,tt02 WHERE tt01.c1=tt02.c2; QUERY PLAN -------------------------------------------------------------------------------...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Linux系统CentOS6、CentOS7手动修改IP地址
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS关闭SELinux安全模块
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Hadoop3单机部署,实现最简伪集群
- CentOS6,7,8上安装Nginx,支持https2.0的开启