Kubernetes集群部署史上最详细（二）Prometheus监控Kubernetes集群

使用Prometheus监控Kubernetes集群

监控方面Grafana采用YUM安装经过服务形式运行，部署在Master上，而Prometheus则经过POD运行，Grafana经过使用Prometheus的service地址来获取数据源。

Prometheus的配置清单在kubernetes二进制程序包中就有，下载地址，

解压后有一个cluster目录，该目录里面的addons里面有所须要的插件，好比dns、dashboard以及prometheus等。

我用的就是它自带的这个prometheus清单文件，可是它里面有些问题好比prometheus这个组件须要PV可是原始的包里面没有这个PV你须要手动创建，我这里已经写好了yaml文件不过使用的是hostpath，主要是为了测试方便若是是生产环境中不建议这样使用至少也要用个NFS这种存储，另外它原始的清单文件中使用的prometheus等镜像版本较低虽然也可使用可是我修改了这些版本使用的最新的版本，最新版本中有些启动参数变化了因此也修改了响应的内容。因此你直接使用我修改的这个就能够，从下面的连接下载，另外这里还包括了grafana的2个dashboard，这两个也作了修改，由于从官网下载的模板对于有些指标识别不了（由于版本问题或者其余问题致使指标名称对不上），因此须要修改。

文件说明

上图是原始内容，我包里的yaml文件只比它多一个。上面分红4个部分，

下面这4个是部署prometheus服务端用的
prometheus-configmap.yaml # 我在原有的配置中增长了global区域
prometheus-rabc.yaml
prometheus-service.yaml
prometheus-statefulset.yaml

下面这2个是部署node_exporter用的
node-exporter-ds.yaml
node-exporter-service.yaml

下面3个是部署kube-state-metrics用的，这个组件是对监控内容的补充，虽然你部署了metric-server、kubelet也提供了cadvisor接口以及上面
部署的node_exporter，可是还有一些指标须要监控好比调度了多少副本如今有几个可用、不一样状态的POD有多少、POD重启了多少次、运行了多少job等
这个组件也是从API SERVER上去获取数据可是这些数据是原始数据而不像kubectl那样可能会为了便于理解而对某些数据作修改
kube-state-metrics-deployment.yaml
kube-state-metrics-rabc.yaml
kube-state-metrics-service.yaml

下面4个是alertmanager报警组件的部署
alertmanager-service.yaml
alertmanager-pvc.yaml
alertmanager-deployment.yaml
alertmanager-configmap.yaml

kube-state-metrics与metric-server的对比

metric-server（或heapster）是一个集群组件按期经过kubelet来获取集群节点的cpu、内存使用率这种监控指标，并且它只保留最新数据且存储在内存中，不负责发送给第三方，你能够经过其余方式把他们发送给存储后端，如influxdb或云厂商，他当前的核心做用是：为HPA等组件提供决策指标支持。

kube-state-metrics关注于获取k8s各类资源对象的最新状态，如deployment或者daemonset，它在内存中保留kubernetes集群状态的快照而且在随后的时间里基于这个快照生成新的指标，并且它也不负责发数据发给第三方。将kube-state-metrics做为单独的项目，还能够从Prometheus等监控系统访问这些指标。

之因此没有把kube-state-metrics归入到metric-server的能力中，是由于他们的关注点本质上是不同的。metric-server仅仅是获取、格式化现有数据，写入特定的存储，实质上是一个监控系统。而kube-state-metrics是将k8s的运行情况在内存中作了个快照，而且获取新的指标，但他没有能力导出这些指标 换个角度讲，kube-state-metrics自己是metric-server的一种数据来源，虽然如今没有这么作。 另外，像Prometheus这种监控系统，并不会去用metric-server中的数据，他都是本身作指标收集、集成的（Prometheus包含了metric-server的能力），但Prometheus能够监控metric-server自己组件的监控状态并适时报警，这里的监控就能够经过kube-state-metrics来实现，如metric-serverpod的运行状态。

POD的Annotations是什么

Annotations将任何非标识metadata附加到对象，标签可用于选择对象并查找知足某些条件的对象集合。相比之下，Annotations不用于标识和选择对象，虽然它也是键值形式。Annotations不会被Kubernetes直接使用，其主要目的是方便用户阅读查找。

Prometheus配置文件说明

# Kubernetes的API SERVER会暴露API服务，Promethues集成了对Kubernetes的自动发现，它有5种模式：Node、Service
# 、Pod、Endpoints、ingress，下面是Prometheus官方给出的对Kubernetes服务发现的实例。这里你会看到大量的relabel_configs，
# 其实你就是把全部的relabel_configs去掉同样能够对kubernetes作服务发现。relabel_configs仅仅是对采集过来的指标作二次处理，好比
# 要什么不要什么以及替换什么等等。而以__meta_开头的这些元数据标签都是实例中包含的，而relabel则是动态的修改、覆盖、添加删除这些标签
# 或者这些标签对应的值。并且以__开头的标签一般是系统内部使用的，所以这些标签不会被写入样本数据中，若是咱们要收集这些东西那么则要进行
# relabel操做。固然reabel操做也不只限于操做__开头的标签。
#
# action的行为：
# replace：默认行为，不配置action的话就采用这种行为，它会根据regex来去匹配source_labels标签上的值，并将并将匹配到的值写入target_label中
# labelmap：它会根据regex去匹配标签名称，并将匹配到的内容做为新标签的名称，其值做为新标签的值
# keep：仅收集匹配到regex的源标签，而会丢弃没有匹配到的全部标签，用于选择
# drop：丢弃匹配到regex的源标签，而会收集没有匹配到的全部标签，用于排除
# labeldrop：使用regex匹配标签，符合regex规则的标签将从target实例中移除，其实也就是不收集不保存
# labelkeep：使用regex匹配标签，仅收集符合regex规则的标签，不符合的不收集
#
global:
scrape_interval: 10s
evaluation_interval: 30s
scrape_configs:
# 用于发现API SERVER
- job_name: 'kubernetes-apiservers'

kubernetes_sd_configs:
# 发现endpoints，它是从列出的服务端点发现目标，这个endpoints来自于Kubernetes中的service，每个service都有对应的endpoints，这里是一个列表
# 能够是一个IP:PORT也能够是多个，这些IP:PORT就是service经过标签选择器选择的POD的IP和端口。因此endpoints角色就是用来发现server对应的pod的IP的
# kubernetes会有一个默认的service，经过找到这个service的endpoints就找到了api server的IP:PORT，那endpoints有不少，我怎么知道哪一个是api server呢
# 这个就靠source_labels指定的标签名称了。
- role: endpoints
# 经过什么形式来链接，默认是https
scheme: https
# 下面这个ca_file和token_file的路径都是默认的，你可能默认设置能用么？其实能够，由于每个运行起来的POD kubernetes都会为其
# 建立一个serviceaccout的Secret而且挂载到下面的目录上，里面就有ca.crt和token这两个文件，你能够本身启动一个POD，而后经过
# kubectl describe pods 来查看，必定会在Volumes下面有一个default-token-XXX的东西，而且Mounts里面有下面的目录。
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

# 下面的含义是源标签__meta_kubernetes_namespace等若是其值为default;kubernetes;https标签顺序和值要对应。换句话说就是
# 当__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name三者对应的
# 值为default、kubernetes、https则进行保留，并且该endpoints对应的地址为api server的地址。
#
# __meta_kubernetes_namespace 端点对象的命名空间，在不一样对象上这个标签的含义不一样，在角色是endpoints中这个是端点对象的名称空间
# __meta_kubernetes_service_name 端点对象的服务名称
# __meta_kubernetes_endpoint_port_name 端点的端口名称
#
# kubernetes默认在default名称空间有一个叫作kubernetes的service，因此这个service的有3个设置对应的就是下面三个标签
# __meta_kubernetes_namespace 值为default
# __meta_kubernetes_service_name 值为kubernetes
# __meta_kubernetes_endpoint_port_name 值为https
relabel_configs:
- source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
action: keep
regex: default;kubernetes;https

# 配置针对kubelet的服务发现以及对标签的处理，是获取kubelet上/metrics接口数据来获取node的资源使用状况
- job_name: 'kubernetes-nodes-kubelet'
scheme: https
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
# 跳过CA验证
# insecure_skip_verify: true
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

kubernetes_sd_configs:
# 使用node角色，它使用默认的kubelet提供的http端口来发现集群中每一个node节点。那具体地址是什么呢？
# 地址类型有四种NodeInternalIP, NodeExternalIP, NodeLegacyHostIP 和 NodeHostName，默认为这四个中第一个可用的地址。
# 那么这里为何使用node角色呢？由于node角色就是用来发现kubelet的
# __meta_kubernetes_node_name：节点对象的名字
# __meta_kubernetes_node_label_<labelname>：表示节点对象上的每个标签
# __meta_kubernetes_node_annotation_<annotationname>：表示节点对象上的每个annotation
# __meta_kubernetes_node_address_<address_type>：若是存在，那么将是每个节点地址类型的第一个地址
# Node模式，Prometheus会自动发现Kubernetes中全部Node节点的信息并做为监控的目标Target。
# 而这些Target的访问地址实际上就是Kubelet的访问地址，而且Kubelet实际上直接内置了对Promtheus的支持
- role: node

relabel_configs:
# 保留(.+)匹配到的内容，去掉__meta_kubernetes_node_label_，实际上就是把(.+)当作新标签，而后老标签的值给这个新标签，
# 这里没有设置source_labels，则表示匹配全部标签
- action: labelmap
# 匹配节点对象上的每个标签
regex: __meta_kubernetes_node_label_(.+)

# 抓取cAdvisor数据，是获取kubelet上/metrics/cadvisor接口数据来获取容器的资源使用状况
- job_name: 'kubernetes-nodes-cadvisor'
scheme: https
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

kubernetes_sd_configs:
# 使用角色为node
- role: node

relabel_configs:
- action: labelmap
regex: __meta_kubernetes_node_label_(.+)
# 把__metrics_path__的值替换为/metrics/cadvisor，由于默认是/metrics
- target_label: __metrics_path__
replacement: /metrics/cadvisor

# 抓取服务端点，整个这个任务都是用来发现node-exporter和kube-state-metrics-service的，这里用的是endpoints角色，这是经过这二者的service来发现
# 的后端endpoints。另外须要说明的是若是知足采集条件，那么在service、POD中定义的labels也会被采集进去
- job_name: 'kubernetes-service-endpoints'

kubernetes_sd_configs:
- role: endpoints

relabel_configs:
# 从新打标仅抓取到的具备 "prometheus.io/scrape: true" 的annotation的端点，意思是说若是某个service具备prometheus.io/scrape = true annotation声明则抓取
# annotation自己也是键值结构，因此这里的源标签设置为键，而regex设置值，当值匹配到regex设定的内容时则执行keep动做也就是保留，其他则丢弃.
# node-exporter这个POD的service里面就有一个叫作prometheus.io/scrape = true的annotations因此就找到了node-exporter这个POD
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
action: keep
regex: true

# 应用中自定义暴露的指标，也许你暴露的API接口不是/metrics这个路径，那么你能够在这个POD对应的service中作一个
# "prometheus.io/path = /mymetrics" 声明，下面的意思就是把你声明的这个路径赋值给__metrics_path__
# 其实就是让prometheus来获取自定义应用暴露的metrices的具体路径，不过这里写的要和service中作好约定
# 若是service中这样写 prometheus.io/app-metrics-path: '/metrics' 那么你这里就要
# __meta_kubernetes_service_annotation_prometheus_io_app_metrics_path这样写
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
action: replace
target_label: __metrics_path__
regex: (.+)

# 暴露自定义的应用的端口，就是把地址和你在service中定义的 "prometheus.io/port = <port>" 声明作一个拼接
# 而后赋值给__address__，这样prometheus就能获取自定义应用的端口，而后经过这个端口再结合__metrics_path__来获取
# 指标，若是__metrics_path__值不是默认的/metrics那么就要使用上面的标签替换来获取真正暴露的具体路径
- source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
action: replace
regex: ([^:]+)(?::\d+)?;(\d+)
replacement: $1:$2
target_label: __address__

# 从新设置scheme
# 匹配源标签__meta_kubernetes_service_annotation_prometheus_io_scheme也就是prometheus.io/scheme annotation
# 若是源标签的值匹配到regex则把值替换为__scheme__对应的值
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
action: replace
target_label: __scheme__
regex: (https?)

# 下面主要是为了给样本添加额外信息
- action: labelmap
regex: __meta_kubernetes_service_label_(.+)
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: kubernetes_namespace
- source_labels: [__meta_kubernetes_service_name]
action: replace
target_label: kubernetes_name

# 下面是自动发现service，不过若是要想监控service则须要安装blackbox-exporter
- job_name: 'kubernetes-services-http'

metrics_path: /probe
# 生成__param_module="http_2xx"的label，若是是TCP探测则使用 module: [tcp_connect]
params:
module: [http_2xx]

kubernetes_sd_configs:
- role: service

relabel_configs:
# 为了让service能够被探测到，那须要在service的annotation中增长 prometheus.io/scrape: true 声明
# 也就是只保留prometheus.io/scrape: true的service
- action: keep
regex: true
source_labels:
- __meta_kubernetes_service_annotation_prometheus_io_scrape
# 用__address__这个label的值建立一个名为__param_target的label为blackbox-exporter,值为内部service的访问地址，做为blackbox-exporter采集用
- source_labels: [__address__]
target_label: __param_target

# 用blackbox-exporter的service地址值”prometheus-blackbox-exporter:9115"替换原__address__的值
- target_label: __address__
replacement: blackbox-exporter.example.com:9115
- source_labels: [__param_target]
target_label: instance

# 下面主要是为了给样本添加额外信息
- action: labelmap
regex: __meta_kubernetes_service_label_(.+)
- source_labels: [__meta_kubernetes_namespace]
target_label: kubernetes_namespace
- source_labels: [__meta_kubernetes_service_name]
target_label: kubernetes_name

# 下面是对ingresses监控，不过若是要想监控ingresses则须要安装blackbox-exporter
- job_name: 'kubernetes-ingresses'

metrics_path: /probe
# 生成__param_module="http_2xx"的label
params:
module: [http_2xx]

kubernetes_sd_configs:
- role: ingress

relabel_configs:
# Example relabel to probe only some ingresses that have "example.io/should_be_probed = true" annotation
# - source_labels: [__meta_kubernetes_ingress_annotation_example_io_should_be_probed]
# action: keep
# regex: true
- source_labels: [__meta_kubernetes_ingress_scheme,__address__,__meta_kubernetes_ingress_path]
regex: (.+);(.+);(.+)
replacement: ${1}://${2}${3}
target_label: __param_target
- target_label: __address__
replacement: blackbox-exporter.example.com:9115
- source_labels: [__param_target]
target_label: instance
# 下面主要是为了给样本添加额外信息
- action: labelmap
regex: __meta_kubernetes_ingress_label_(.+)
- source_labels: [__meta_kubernetes_namespace]
target_label: kubernetes_namespace
- source_labels: [__meta_kubernetes_ingress_name]
target_label: kubernetes_name

# 抓取POD进行监控
- job_name: 'kubernetes-pods'

kubernetes_sd_configs:
- role: pod
relabel_configs:
# POD的 annotation 中含有"prometheus.io/scrape: true" 的则保留，意思就是会被Prometheus抓取，不具备这个的POD则不会被抓取
- action: keep
regex: true
source_labels:
- __meta_kubernetes_pod_annotation_prometheus_io_scrape
# 获取POD的 annotation 中定义的"prometheus.io/path: XXX"定义的值，这个值就是你的程序暴露符合prometheus规范的metrics的地址
# 若是你的metrics的地址不是 /metrics 的话，经过这个标签说，那么这里就会把这个值赋值给 __metrics_path__这个变量，由于prometheus
# 是经过这个变量获取路径而后进行拼接出来一个完整的URL，并经过这个URL来获取metrics值的，由于prometheus默认使用的就是 http(s)://X.X.X.X/metrics
# 这样一个路径来获取的。
- action: replace
regex: (.+)
source_labels:
- __meta_kubernetes_pod_annotation_prometheus_io_path
target_label: __metrics_path__
# 这里是端口信息，由于你的程序颇有可能在容器中并非以80端口运行的，那么就须要作一个拼接http(s)://x.x.x.x:xx/metrics
# __address__在prometheus中表明的就是实例的IP地址，而POD中的annotation 中定义的"prometheus.io/port: XX"就是你程序
# 被访问到的端口，最终在prometheus中将会被显示为 instance=X.X.X.X:XX这样
- action: replace
regex: ([^:]+)(?::\d+)?;(\d+)
replacement: $1:$2
source_labels:
- __address__
- __meta_kubernetes_pod_annotation_prometheus_io_port
target_label: __address__

- action: labelmap
regex: __meta_kubernetes_pod_label_(.+)
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: kubernetes_namespace
- source_labels: [__meta_kubernetes_pod_name]
action: replace
target_label: kubernetes_pod_name

prometheus是如何识别apiserver的呢？

这些乱七八糟的标签可能让你眼花缭乱，咱们举一个简单的例子看一下，prometheus是如何识别apiserver的，看下图

其余说明和参考文档

另外在grafana主机安装插件 grafana-cli plugins install grafana-piechart-panel 而后重启grafana服务。不然8919中的饼图使用不了。

https://github.com/1046102779/prometheus/blob/master/operating/configuration.md

https://blog.csdn.net/liukuan73/article/details/78881008

https://github.com/yunlzheng/prometheus-book

监控清单文件下载