示例应用#

比如在本地启动一些样例来让 Prometheus 采集。Go 客户端库包含一个示例，该示例为具有不同延迟分布的三个服务暴露 RPC 延迟。

首先确保已经安装了 Go 环境并启用 go modules，下载 Prometheus 的 Go 客户端库并运行这三个示例：

1
git clone https://github.com/prometheus/client_golang.git
2
cd client_golang/examples/random
3
export GO111MODULE=on
4
export GOPROXY=https://goproxy.cn
5
go build

然后在 3 个独立的终端里面运行 3 个服务：

1
./random -listen-address=:8080
2
./random -listen-address=:8081
3
./random -listen-address=:8082

这个时候可以得到 3 个不同的监控接口：http://localhost:8080/metrics、http://localhost:8081/metrics 和 http://localhost:8082/metrics。

然后配置 Prometheus 来采集这些新的目标，将这三个目标分组到一个名为 example-random 的任务。假设前两个端点（即：http://localhost:8080/metrics、http://localhost:8081/metrics ）都是生产级目标应用，第三个端点（即：http://localhost:8082/metrics ）为金丝雀实例。要在 Prometheus 中对此进行建模，可以将多组端点添加到单个任务中，为每组目标添加额外的标签。 在此示例中，将 group =“production” 标签添加到第一组目标，同时将 group=“canary”添加到第二组。将以下配置添加到 prometheus.yml 中的 scrape_configs 部分，然后重新启动 Prometheus 实例：

1
scrape_configs:
2
  - job_name: "example-random"
3
    # Override the global default and scrape targets from this job every 5 seconds.
4
    scrape_interval: 5s
5
    static_configs:
6
      - targets: ["localhost:8080", "localhost:8081"]
7
        labels:
8
          group: "production"
9
      - targets: ["localhost:8082"]
10
        labels:
11
          group: "canary"

然后到浏览器中查看 Prometheus 的配置是否有新增的任务，这就是 Prometheus 添加监控配置最基本的配置方式了，非常简单，只需要提供一个符合 metrics 格式的可访问的接口配置给 Prometheus 就可以了。

由于最终要运行在 Kubernetes 系统中，所以用 Docker 镜像的方式运行。

为了能够方便的管理配置文件，这里将 prometheus.yml 文件用 ConfigMap 的形式进行管理：prometheus-cm.yaml

1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
  name: prometheus-config
5
  namespace: monitor
6
data:
7
  prometheus.yml: |
8
    global:
9
      scrape_interval: 15s
10
      scrape_timeout: 15s
11
    scrape_configs:
12
    - job_name: 'prometheus'
13
      static_configs:
14
      - targets: ['localhost:9090']

这里暂时只配置了对 prometheus 本身的监控，直接创建该资源对象：

1
kubectl apply -f prometheus-cm.yaml

配置文件创建完成了，以后有新的资源需要被监控，只需要将上面的 ConfigMap 对象更新即可。现在创建 prometheus 的 Pod 资源：

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: prometheus
5
  namespace: monitor
6
  labels:
7
    app: prometheus
8
spec:
9
  selector:
10
    matchLabels:
11
      app: prometheus
12
  template:
13
    metadata:
14
      labels:
15
        app: prometheus
16
    spec:
17
      serviceAccountName: prometheus
18
      containers:
19
        - image: prom/prometheus:v2.48.1
20
          name: prometheus
21
          args:
22
            - "--config.file=/etc/prometheus/prometheus.yml"
23
            - "--storage.tsdb.path=/prometheus" # 指定tsdb数据路径
24
            - "--storage.tsdb.retention.time=24h"
25
            - "--web.enable-admin-api" # 控制对admin HTTP API的访问，其中包括删除时间序列等功能
26
            - "--web.enable-lifecycle" # 支持热更新，直接执行localhost:9090/-/reload立即生效
27
          ports:
28
            - containerPort: 9090
29
              name: http
30
          volumeMounts:
31
            - mountPath: "/etc/prometheus"
32
              name: config-volume
33
            - mountPath: "/prometheus"
34
              name: data
35
          resources:
36
            requests:
37
              cpu: 100m
38
              memory: 512Mi
39
            limits:
40
              cpu: 100m
41
              memory: 512Mi
42
      volumes:
43
        - name: data
44
          persistentVolumeClaim:
45
            claimName: prometheus-data
46
        - configMap:
47
            name: prometheus-config
48
          name: config-volume

另外为了 prometheus 的性能和数据持久化这里是直接将通过一个 LocalPV 来进行数据持久化的，通过 --storage.tsdb.path=/prometheus 指定数据目录，创建如下所示的一个 PVC 资源对象，注意是一个 LocalPV，和 node1 节点具有亲和性：prometheus-pv.yaml

1
apiVersion: v1
2
kind: PersistentVolume
3
metadata:
4
  name: prometheus-local
5
  labels:
6
    app: prometheus
7
spec:
8
  accessModes:
9
    - ReadWriteOnce
10
  capacity:
11
    storage: 20Gi
12
  storageClassName: local-storage
13
  local:
14
    path: /data/k8s/prometheus
15
  nodeAffinity:
16
    required:
17
      nodeSelectorTerms:
18
        - matchExpressions:
19
            - key: kubernetes.io/hostname
20
              operator: In
21
              values:
22
                - node1
23
  persistentVolumeReclaimPolicy: Retain
24
---
25
apiVersion: v1
26
kind: PersistentVolumeClaim
27
metadata:
28
  name: prometheus-data
29
  namespace: monitor
30
spec:
31
  selector:
32
    matchLabels:
33
      app: prometheus
34
  accessModes:
35
    - ReadWriteOnce
36
  resources:
37
    requests:
38
      storage: 20Gi
39
  storageClassName: local-storage

由于 prometheus 可以访问 Kubernetes 的一些资源对象，所以需要配置 rbac 相关认证，这里使用了一个名为 prometheus 的 serviceAccount 对象：prometheus-rbac.yaml

1
apiVersion: v1
2
kind: ServiceAccount
3
metadata:
4
  name: prometheus
5
  namespace: monitor
6
---
7
apiVersion: rbac.authorization.k8s.io/v1
8
kind: ClusterRole
9
metadata:
10
  name: prometheus
11
rules:
12
  - apiGroups:
13
      - ""
14
    resources:
15
      - nodes
16
      - services
17
      - endpoints
18
      - pods
19
      - nodes/proxy
20
    verbs:
21
      - get
22
      - list
23
      - watch
24
  - apiGroups:
25
      - "extensions"
26
    resources:
27
      - ingresses
28
    verbs:
29
      - get
30
      - list
31
      - watch
32
  - apiGroups:
33
      - ""
34
    resources:
35
      - configmaps
36
      - nodes/metrics
37
    verbs:
38
      - get
39
  - nonResourceURLs:
40
      - /metrics
41
    verbs:
42
      - get
43
---
44
apiVersion: rbac.authorization.k8s.io/v1beta1
45
kind: ClusterRoleBinding
46
metadata:
47
  name: prometheus
48
roleRef:
49
  apiGroup: rbac.authorization.k8s.io
50
  kind: ClusterRole
51
  name: prometheus
52
subjects:
53
  - kind: ServiceAccount
54
    name: prometheus
55
    namespace: monitor

由于要获取的资源信息，在每一个 namespace 下面都有可能存在，所以这里使用的是 ClusterRole 的资源对象，值得一提的是这里的权限规则声明中有一个 nonResourceURLs 的属性，是用来对非资源型 metrics 进行操作的权限声明，这个在以前很少遇到过，然后直接创建上面的资源对象即可：

1
kubectl apply -f prometheus-rbac.yaml

现在可以添加 promethues 的资源对象了：

1
kubectl apply -f prometheus-deploy.yaml

1
kubectl get pods -n monitor

创建 Pod 后，看到并没有成功运行，出现了 open /prometheus/queries.active: permission denied 这样的错误信息，这是因为 prometheus 的镜像中是使用的 nobody 用户，但是通过 LocalPV 挂载到宿主机上面的目录的 ownership 却是 root：

1
ls -la /data/k8s

所以当然会出现操作权限问题了，这个时候我们就可以通过 securityContext 来为 Pod 设置下 volumes 的权限，通过设置 runAsUser=0 指定运行的用户为 root，也可以通过设置一个 initContainer 来修改数据目录权限：

1
......
2
initContainers:
3
- name: fix-permissions
4
  image: busybox
5
  command: [chown, -R, "nobody:nobody", /prometheus]
6
  volumeMounts:
7
  - name: data
8
    mountPath: /prometheus

重新更新下 prometheus：

1
kubectl apply -f prometheus-deploy.yaml

Pod 创建成功后，为了能够在外部访问到 prometheus 的 webUI 服务，还需要创建一个 Service 对象：prometheus-svc.yaml

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: prometheus
5
  namespace: monitor
6
  labels:
7
    app: prometheus
8
spec:
9
  selector:
10
    app: prometheus
11
  type: NodePort
12
  ports:
13
    - name: web
14
      port: 9090
15
      targetPort: http

为了方便测试，这里创建一个 NodePort 类型的服务:

1
kubectl apply -f prometheus-svc.yaml

还可以创建一个 Ingress对象，通过域名来进行访问：prometheus-ingress.yaml

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: prometheus-nginx
5
  namespace: monitor
6
spec:
7
  ingressClassName: nginx
8
  rules:
9
    - host: prometheus.tianch.com.cn
10
      http:
11
        paths:
12
          - path: /
13
            pathType: Prefix
14
            backend:
15
              service:
16
                name: prometheus-k8s
17
                port:
18
                  number: 9090

1
kubectl apply -f prometheus-ingress.yaml

现在我们就可以通过域名或者http://任意节点IP:nodePort端口访问 prometheus 的 webUI 服务了。

普通应用#

对于普通应用只需要能够提供一个满足 prometheus 格式要求的 /metrics 接口就可以让 Prometheus 来接管监控，比如 Kubernetes 集群中非常重要的 CoreDNS 插件，一般默认情况下就开启了 /metrics 接口：

1
kubectl get cm coredns -n kube-system -o yaml

1
apiVersion: v1
2
data:
3
  Corefile: |
4
    .:53 {
5
        errors
6
        health {
7
           lameduck 5s
8
        }
9
        ready
10
        kubernetes cluster.local in-addr.arpa ip6.arpa {
11
           pods insecure
12
           fallthrough in-addr.arpa ip6.arpa
13
           ttl 30
14
        }
15
        prometheus :9153
16
        forward . /etc/resolv.conf {
17
           max_concurrent 1000
18
        }
19
        cache 30
20
        loop
21
        reload
22
        loadbalance
23
    }
24
kind: ConfigMap
25
metadata:
26
  creationTimestamp: "2023-11-14T08:49:41Z"
27
  name: coredns
28
  namespace: kube-system
29
  resourceVersion: "234"
30
  uid: febb80f5-bfc7-483b-8484-387e31d7f8ef

上面 ConfigMap 中 prometheus :9153 就是开启 prometheus 的插件：

可以先尝试手动访问下 /metrics 接口，如果能够手动访问到那证明接口是没有任何问题的。

可以看到可以正常访问到，从这里可以看到 CoreDNS 的监控数据接口是正常的了，然后就可以将这个 /metrics 接口配置到 prometheus.yml 中去了，直接加到默认的 prometheus 这个 job 下面：

1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
  name: prometheus-config
5
  namespace: monitor
6
data:
7
  prometheus.yml: |
8
    global:
9
      scrape_interval: 15s
10
      scrape_timeout: 15s
11

12
    scrape_configs:
13
    - job_name: 'prometheus'
14
      static_configs:
15
        - targets: ['localhost:9090']
16

17
    - job_name: 'coredns'
18
      static_configs:
19
        - targets: ['10.233.90.117:9153', '10.233.90.122:9153']

这里只是一个很简单的配置，scrape_configs 下面可以支持很多参数，例如：

• basic_auth 和 bearer_token：比如我们提供的 /metrics 接口需要 basic 认证的时候，通过传统的用户名/密码或者在请求的 header 中添加对应的 token 都可以支持
• kubernetes_sd_configs 或 consul_sd_configs：可以用来自动发现一些应用的监控数据

重新更新这个 ConfigMap 资源对象：

1
kubectl apply -f prometheus-cm.yaml

现在 Prometheus 的配置文件内容已经更改了，过一会儿被挂载到 Pod 中的 prometheus.yml 文件也会更新，由于之前的 Prometheus 启动参数中添加了 --web.enable-lifecycle 参数，所以现在只需要执行一个 reload 命令即可让配置生效：

1
kubectl get pods -n monitor -o wide

由于 ConfigMap 通过 Volume 的形式挂载到 Pod 中去的热更新需要一定的间隔时间才会生效，所以需要稍微等一小会儿。

再去看 Prometheus 的 Dashboard 中查看采集的目标数据：

可以看到刚刚添加的 coredns 这个任务已经出现了，同样的可以切换到 Graph 下面去，可以找到一些 CoreDNS 的指标数据，至于这些指标数据代表什么意义，一般情况下，可以去查看对应的 /metrics 接口，里面一般情况下都会有对应的注释。

使用exporter监控#

上面说过有一些应用可能没有自带 /metrics 接口供 Prometheus 使用，在这种情况下，就需要利用 exporter 服务来为 Prometheus 提供指标数据了。Prometheus 官方为许多应用就提供了对应的 exporter 应用，也有许多第三方的实现，可以前往官方网站进行查看：exporters，当然如果你的应用本身也没有 exporter 实现，那么就要自己想办法去实现一个 /metrics 接口了，只要你能提供一个合法的 /metrics 接口，Prometheus 就可以监控你的应用。

比如这里通过一个 redis-exporter 的服务来监控 redis 服务，对于这类应用，一般会以 sidecar 的形式和主应用部署在同一个 Pod 中，比如这里部署一个 redis 应用，并用 redis-exporter 的方式来采集监控数据供 Prometheus 使用，如下资源清单文件：6.prometheus-redis.yaml

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: redis
5
  namespace: monitor
6
spec:
7
  selector:
8
    matchLabels:
9
      app: redis
10
  template:
11
    metadata:
12
      labels:
13
        app: redis
14
    spec:
15
      containers:
16
        - name: redis
17
          image: redis:6
18
          resources:
19
            limits:
20
              cpu: 100m
21
              memory: 100Mi
22
          ports:
23
            - containerPort: 6379
24
        - name: redis-exporter
25
          image: oliver006/redis_exporter:latest
26
          resources:
27
            limits:
28
              cpu: 100m
29
              memory: 100Mi
30
          ports:
31
            - containerPort: 9121
32
---
33
kind: Service
34
apiVersion: v1
35
metadata:
36
  name: redis
37
  namespace: monitor
38
spec:
39
  selector:
40
    app: redis
41
  ports:
42
    - name: redis
43
      port: 6379
44
      targetPort: 6379
45
    - name: prometheus
46
      port: 9121
47
      targetPort: 9121

可以看到上面 redis 这个 Pod 中包含了两个容器，一个就是 redis 本身的主应用，另外一个容器就是 redis_exporter。现在直接创建上面的应用：

1
kubectl apply -f prome-redis.yaml

创建完成后，可以看到 redis 的 Pod 里面包含有两个容器：

可以通过 9121 端口来校验是否能够采集到数据：

1
curl 10.233.26.191:9121/metrics

同样的，现在只需要更新 Prometheus 的配置文件：

1
- job_name: "redis"
2
  static_configs:
3
    - targets: ["redis:9121"]

由于这里是通过 Service 去配置的 redis 服务，当然直接配置 Pod IP 也是可以的，因为和 Prometheus 处于同一个 namespace，所以直接使用 servicename 即可。配置文件更新后，重新加载：

1
➜ kubectl apply -f prometheus-cm.yaml
2
configmap/prometheus-config configured
3
# 隔一会儿执行reload操作
4
➜ curl -X POST "http://10.233.26.191:9090/-/reload"

这个时候再去看 Prometheus 的 Dashboard 中查看采集的目标数据：

可以看到配置的 redis 这个 job 已经生效了。切换到 Graph 下面可以看到很多关于 redis 的指标数据，选择任意一个指标，比如 redis_exporter_scrapes_total，然后点击执行就可以看到对应的数据图表了：

监控集群节点#

要监控节点其实已经有很多非常成熟的方案了，比如 Nagios、zabbix，甚至自己来收集数据也可以，这里通过 Prometheus 来采集节点的监控指标数据，可以通过 node_exporter 来获取，顾名思义，node_exporter 就是抓取用于采集服务器节点的各种运行指标，目前 node_exporter 支持几乎所有常见的监控点，比如 conntrack，cpu，diskstats，filesystem，loadavg，meminfo，netstat 等，详细的监控点列表可以参考其 Github 仓库。

可以通过 DaemonSet 控制器来部署该服务，这样每一个节点都会自动运行一个这样的 Pod，如果从集群中删除或者添加节点后，也会进行自动扩展。

在部署 node-exporter 的时候有一些细节需要注意，如下资源清单文件：prome-node-exporter.yaml

1
apiVersion: apps/v1
2
kind: DaemonSet
3
metadata:
4
  name: node-exporter
5
  namespace: monitor
6
  labels:
7
    app: node-exporter
8
spec:
9
  selector:
10
    matchLabels:
11
      app: node-exporter
12
  template:
13
    metadata:
14
      labels:
15
        app: node-exporter
16
    spec:
17
      hostPID: true
18
      hostIPC: true
19
      hostNetwork: true
20
      nodeSelector:
21
        kubernetes.io/os: linux
22
      containers:
23
        - name: node-exporter
24
          image: prom/node-exporter:v1.3.1
25
          args:
26
            - --web.listen-address=$(HOSTIP):9100
27
            - --path.procfs=/host/proc
28
            - --path.sysfs=/host/sys
29
            - --path.rootfs=/host/root
30
            - --no-collector.hwmon # 禁用不需要的一些采集器
31
            - --no-collector.nfs
32
            - --no-collector.nfsd
33
            - --no-collector.nvme
34
            - --no-collector.dmi
35
            - --no-collector.arp
36
            - --collector.filesystem.ignored-mount-points=^/(dev|proc|sys|var/lib/containerd/.+|/var/lib/docker/.+|var/lib/kubelet/pods/.+)($|/)
37
            - --collector.filesystem.ignored-fs-types=^(autofs|binfmt_misc|cgroup|configfs|debugfs|devpts|devtmpfs|fusectl|hugetlbfs|mqueue|overlay|proc|procfs|pstore|rpc_pipefs|securityfs|sysfs|tracefs)$
38
          ports:
39
            - containerPort: 9100
40
          env:
41
            - name: HOSTIP
42
              valueFrom:
43
                fieldRef:
44
                  fieldPath: status.hostIP
45
          resources:
46
            requests:
47
              cpu: 150m
48
              memory: 180Mi
49
            limits:
50
              cpu: 150m
51
              memory: 180Mi
52
          securityContext:
53
            runAsNonRoot: true
54
            runAsUser: 65534
55
          volumeMounts:
56
            - name: proc
57
              mountPath: /host/proc
58
            - name: sys
59
              mountPath: /host/sys
60
            - name: root
61
              mountPath: /host/root
62
              mountPropagation: HostToContainer
63
              readOnly: true
64
      tolerations:
65
        - operator: "Exists"
66
      volumes:
67
        - name: proc
68
          hostPath:
69
            path: /proc
70
        - name: dev
71
          hostPath:
72
            path: /dev
73
        - name: sys
74
          hostPath:
75
            path: /sys
76
        - name: root
77
          hostPath:
78
            path: /

由于要获取到的数据是主机的监控指标数据，而 node-exporter 是运行在容器中的，所以在 Pod 中需要配置一些 Pod 的安全策略，这里就添加了 hostPID: true、hostIPC: true、hostNetwork: true 3 个策略，用来使用主机的 PID namespace、IPC namespace 以及主机网络，这些 namespace 就是用于容器隔离的关键技术，要注意这里的 namespace 和集群中的 namespace 是两个完全不相同的概念。

另外还将主机的 /dev、/proc、/sys这些目录挂载到容器中，这些因为采集的很多节点数据都是通过这些文件夹下面的文件来获取到的，比如在使用 top 命令可以查看当前 cpu 使用情况，数据就来源于文件 /proc/stat，使用 free 命令可以查看当前内存使用情况，其数据来源是来自 /proc/meminfo 文件。

另外由于集群使用的是 kk 搭建的，所以如果希望 master 节点也一起被监控，则需要添加相应的容忍，然后直接创建上面的资源对象：

1
kubectl apply -f prome-node-exporter.yaml

1
kubectl get pods -n kubesphere-monitoring-system -l app.kubernetes.io/name=node-exporter -o wide

部署完成后，可以看到在几个节点上都运行了一个 Pod，由于指定了 hostNetwork=true，所以在每个节点上就会绑定一个端口 9100，我们可以通过这个端口去获取到监控指标数据：

1
curl 10.168.1.21:9100/metrics
2
...
3
node_filesystem_device_error{device="shm",fstype="tmpfs",mountpoint="/rootfs/var/lib/docker/containers/aefe8b1b63c3aa5f27766053ec817415faf8f6f417bb210d266fef0c2da64674/shm"} 1
4
node_filesystem_device_error{device="shm",fstype="tmpfs",mountpoint="/rootfs/var/lib/docker/containers/c8652ca72230496038a07e4fe4ee47046abb5f88d9d2440f0c8a923d5f3e133c/shm"} 1
5
node_filesystem_device_error{device="tmpfs",fstype="tmpfs",mountpoint="/dev"} 0
6
node_filesystem_device_error{device="tmpfs",fstype="tmpfs",mountpoint="/dev/shm"} 0
7
...

当然如果觉得上面的手动安装方式比较麻烦，也可以使用 Helm 的方式来安装：

1
helm upgrade --install node-exporter --namespace monitor stable/prometheus-node-exporter

服务发现#

由于每个节点上面都运行了 node-exporter 程序，如果通过一个 Service 来将数据收集到一起用静态配置的方式配置到 Prometheus 去中，就只会显示一条数据，就得自己在指标数据中去过滤每个节点的数据，当然也可以手动的把所有节点用静态的方式配置到 Prometheus 中去，但是以后要新增或者去掉节点的时候就还得手动去配置，那么有没有一种方式可以让 Prometheus 去自动发现节点的 node-exporter 程序，并且按节点进行分组呢？这就是 Prometheus 里面非常重要的服务发现功能了。

在 Kubernetes 下，Promethues 通过与 Kubernetes API 集成，主要支持 5 中服务发现模式，分别是：Node、Service、Pod、Endpoints、Ingress。

通过 kubectl 命令可以很方便的获取到当前集群中的所有节点信息：

1
kubectl get node

但是要让 Prometheus 也能够获取到当前集群中的所有节点信息的话，就需要利用 Node 的服务发现模式，同样的，在 prometheus.yml 文件中配置如下的 job 任务即可：

1
- job_name: "nodes"
2
  kubernetes_sd_configs:
3
    - role: node

通过指定 kubernetes_sd_configs 的模式为 node，Prometheus 就会自动从 Kubernetes 中发现所有的 node 节点并作为当前 job 监控的目标实例，发现的节点 /metrics 接口是默认的 kubelet 的 HTTP 接口。

prometheus 的 ConfigMap 更新完成后，执行 reload 操作，让配置生效：

1
 kubectl apply -f prometheus-cm.yaml
2
# 隔一会儿执行reload操作
3
 curl -X POST "http://10.233.26.191:9090/-/reload"

配置生效后，再去 prometheus 的 dashboard 中查看 Targets 是否能够正常抓取数据

可以看到上面的 nodes 这个 job 任务已经自动发现了我们 4 个 node 节点，但是在获取数据的时候失败了，出现了类似于下面的错误信息：

1
server returned HTTP status 400 Bad Request

这个是因为 prometheus 去发现 Node 模式的服务的时候，访问的端口默认是 10250，而默认是需要认证的 https 协议才有权访问的，但实际上并不是希望让去访问 10250 端口的 /metrics 接口，而是 node-exporter 绑定到节点的 9100 端口，所以应该将这里的 10250 替换成 9100，但是应该怎样替换呢？

这里就需要使用到 Prometheus 提供的 relabel_configs 中的 replace 能力了，relabel 可以在 Prometheus 采集数据之前，通过 Target 实例的 Metadata 信息，动态重新写入 Label 的值。除此之外，还能根据 Target 实例的 Metadata 信息选择是否采集或者忽略该 Target 实例。比如这里就可以去匹配 __address__ 这个 Label 标签，然后替换掉其中的端口，如果不知道有哪些 Label 标签可以操作的话，可以在 Service Discovery 页面获取到相关的元标签，这些标签都是可以进行 Relabel 的标签：

替换掉端口，修改 ConfigMap：

1
- job_name: "nodes"
2
  kubernetes_sd_configs:
3
    - role: node
4
  relabel_configs:
5
    - source_labels: [__address__]
6
      regex: "(.*):10250"
7
      replacement: "${1}:9100"
8
      target_label: __address__
9
      action: replace

这里就是一个正则表达式，去匹配 __address__ 这个标签，然后将 host 部分保留下来，port 替换成了 9100，重新更新配置文件，执行 reload 操作，然后再去看 Prometheus 的 Dashboard 的 Targets 路径下面 kubernetes-nodes 这个 job 任务是否正常了。

但是还有一个问题就是采集的指标数据 Label 标签就只有一个节点的 hostname，这对于在进行监控分组分类查询的时候带来了很多不方便的地方，要是能够将集群中 Node 节点的 Label 标签也能获取到就很好了。这里我们可以通过 labelmap 这个属性来将 Kubernetes 的 Label 标签添加为 Prometheus 的指标数据的标签：

1
- job_name: "kubernetes-nodes"
2
  kubernetes_sd_configs:
3
    - role: node
4
  relabel_configs:
5
    - source_labels: [__address__]
6
      regex: "(.*):10250"
7
      replacement: "${1}:9100"
8
      target_label: __address__
9
      action: replace
10
    - action: labelmap
11
      regex: __meta_kubernetes_node_label_(.+)

添加了一个 action 为 labelmap，正则表达式是 __meta_kubernetes_node_label_(.+) 的配置，这里的意思就是表达式中匹配都的数据也添加到指标数据的 Label 标签中去。

对于 kubernetes_sd_configs 下面可用的元信息标签如下：

• __meta_kubernetes_node_name：节点对象的名称
• _meta_kubernetes_node_label：节点对象中的每个标签
• _meta_kubernetes_node_annotation：来自节点对象的每个注释
• _meta_kubernetes_node_address：每个节点地址类型的第一个地址（如果存在）

关于 kubernets_sd_configs 更多信息可以查看官方文档：kubernetes_sd_config

另外由于 kubelet 也自带了一些监控指标数据，就上面提到的 10250 端口，所以这里也把 kubelet 的监控任务也一并配置上：

1
- job_name: "kubelet"
2
  kubernetes_sd_configs:
3
    - role: node
4
  scheme: https
5
  tls_config:
6
    ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
7
    insecure_skip_verify: true
8
  bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
9
  relabel_configs:
10
    - action: labelmap
11
      regex: __meta_kubernetes_node_label_(.+)

但是这里需要特别注意的是这里必须使用 https 协议访问，这样就必然需要提供证书，这里是通过配置 insecure_skip_verify: true 来跳过了证书校验，但是除此之外，要访问集群的资源，还必须要有对应的权限才可以，也就是对应的 ServiceAccount 棒的 权限允许才可以，这里部署的 prometheus 关联的 ServiceAccount 对象前面已经提到过了，这里只需要将 Pod 中自动注入的 /var/run/secrets/kubernetes.io/serviceaccount/ca.crt 和 /var/run/secrets/kubernetes.io/serviceaccount/token 文件配置上，就可以获取到对应的权限了。

现在再去更新下配置文件，执行 reload 操作，让配置生效，然后访问 Prometheus 的 Dashboard 查看 Targets 路径：

现在可以看到上面添加的 kubernetes-kubelet 和 kubernetes-nodes 这两个 job 任务都已经配置成功了，而且二者的 Labels 标签都和集群的 node 节点标签保持一致了。

现在就可以切换到 Graph 路径下面查看采集的一些指标数据了，比如查询 node_load1 指标：

可以看到将几个节点对应的 node_load1 指标数据都查询出来了，同样的，还可以使用 PromQL 语句来进行更复杂的一些聚合查询操作，还可以根据 Labels 标签对指标数据进行聚合，比如这里只查询 node1 节点的数据，可以使用表达式 node_load1{instance="node1"} 来进行查询：

到这里就把 Kubernetes 集群节点使用 Prometheus 监控起来了，接下来我们再学习怎样监控 Pod 或者 Service 之类的资源对象。

与 metric-server 的对比#

• metric-server 是从 APIServer 中获取 cpu、内存使用率这种监控指标，并把他们发送给存储后端，如 influxdb 或云厂商，当前的核心作用是为 HPA 等组件提供决策指标支持。
• kube-state-metrics 关注于获取 Kubernetes 各种资源的最新状态，如 deployment 或者 daemonset，metric-server 仅仅是获取、格式化现有数据，写入特定的存储，实质上是一个监控系统。而 kube-state-metrics 是获取集群最新的指标。
• 像 Prometheus 这种监控系统，并不会去用 metric-server 中的数据，他都是自己做指标收集、集成的，但 Prometheus 可以监控 metric-server 本身组件的监控状态并适时报警，这里的监控就可以通过 kube-state-metrics 来实现，如 metric-server pod 的运行状态。

安装#

kube-state-metrics 已经给出了在 Kubernetes 部署的 manifest 定义文件，我们直接将代码 Clone 到集群中(能用 kubectl 工具操作就行)，不过需要注意兼容的版本：

1
git clone https://github.com/kubernetes/kube-state-metrics.git
2
cd kube-state-metrics/examples/standard

默认的镜像为gcr 的，这里可以将 deployment.yaml 下面的镜像替换成 cnych/kube-state-metrics:v2.0.0-rc.0，此外上面为 Prometheus 配置了 Endpoints 的自动发现，所以可以给 kube-state-metrics 的 Service 配置上对应的 annotations 来自动被发现，然后直接创建即可：

1
cat service.yaml
2
apiVersion: v1
3
kind: Service
4
metadata:
5
  labels:
6
    app.kubernetes.io/name: kube-state-metrics
7
    app.kubernetes.io/version: 2.0.0-rc.0
8
  annotations:
9
    prometheus.io/scrape: "true"
10
    prometheus.io/port: "8080"  # 8081是kube-state-metrics应用本身指标的端口
11
  name: kube-state-metrics
12
  namespace: kube-system
13
......
14
kubectl apply -f .
15
clusterrolebinding.rbac.authorization.k8s.io/kube-state-metrics created
16
clusterrole.rbac.authorization.k8s.io/kube-state-metrics created
17
deployment.apps/kube-state-metrics created
18
serviceaccount/kube-state-metrics created
19
service/kube-state-metrics created

部署完成后正常就可以被 Prometheus 采集到指标了：

水平缩放(分片)#

kube-state-metrics 已经内置实现了一些自动分片功能，可以通过 --shard 和 --total-shards 参数进行配置。现在还有一个实验性功能，如果将 kube-state-metrics 部署在 StatefulSet 中，它可以自动发现其命名位置，以便自动配置分片，这是一项实验性功能，可能以后会被移除。

要启用自动分片，必须运行一个 kube-state-metrics 的 StatefulSet，并且必须通过 --pod 和 --pod-namespace 标志将 pod 名称和名称空间传递给 kube-state-metrics 进程。可以参考 /examples/autosharding 目录下面的示例清单文件进行说明。

使用#

使用 kube-state-metrics 的一些典型场景：

• 存在执行失败的 Job: kube_job_status_failed
• 集群节点状态错误: kube_node_status_condition{condition="Ready", status!="true"}==1
• 集群中存在启动失败的 Pod：kube_pod_status_phase{phase=~"Failed|Unknown"}==1
• 最近 30 分钟内有 Pod 容器重启: changes(kube_pod_container_status_restarts_total[30m])>0

现在有一个问题是前面做 endpoints 类型的服务发现的时候做了一次 labelmap，将 namespace 和 pod 标签映射到了指标中，但是由于 kube-state-metrics 暴露的指标中本身就包含 namespace 和 pod 标签，这就会产生冲突，这种情况会将映射的标签变成 exported_namespace 和 exported_pod，这变会对指标的查询产生影响，如下所示：

这个情况下可以使用 metric_relabel_configs 这 Prometheus 保存数据前的最后一步重新编辑标签，metric_relabel_configs 模块和 relabel_configs 模块很相似，metric_relabel_configs 一个很常用的用途就是可以将监控不需要的数据，直接丢掉，不在 Prometheus 中保存。比如这里可以重新配置 endpoints 类型的指标发现配置：

1
- job_name: "endpoints"
2
  kubernetes_sd_configs:
3
    - role: endpoints
4
  metric_relabel_configs:
5
    - source_labels: [__name__, exported_pod]
6
      regex: kube_pod_info;(.+)
7
      target_label: pod
8
    - source_labels: [__name__, exported_namespace]
9
      regex: kube_pod_info;(.+)
10
      target_label: namespace
11
    - source_labels: [__name__, exported_node]
12
      regex: kube_pod_info;(.+)
13
      target_label: node
14
    - source_labels: [__name__, exported_service]
15
      regex: kube_pod_info;(.+)
16
      target_label: service
17
  relabel_configs:
18
  # ......

metric_relabel_configs 与 relabel_configs 虽然非常类似，但是还是有很大不同的，relabel_configs 是针对 target 指标采集前和采集中的筛选，而 metric_relabel_configs 是针对指标采集后的筛选，如果一个不起作用，那么可以随时尝试使用另一个！

Prometheus 需要知道要抓取什么，这就是服务发现和 relabel_configs 配置的地方，relabel_configs 允许你选择要抓取的目标以及目标标签是什么，所以如果想抓取这种类型的机器而不是那种类型的机器，请使用relabel_configs。

metric_relabel_configs 相比之下，在抓取发生之后，但在数据被存储系统摄取之前应用，因此，如果你想要删除一些昂贵的指标，或者你想要操作来自抓取目标本身的标签（例如来自 /metrics 页面），那就用 metric_relabel_configs。

譬如下面的 relabel_configs drop 动作：

1
relabel_configs:
2
  - source_labels: [__meta_xxx_label_xxx]
3
    regex: Example.*
4
    action: drop

那么将不会收集这个指标，而 metric_relabel_configs 使用的时候指标已经采集过了：

1
metric_relabel_configs:
2
  - source_labels: [__name__]
3
    regex: "(container_tasks_state|container_memory_failures_total)"
4
    action: drop

所以 metric_relabel_configs 相对来说，更加昂贵，因为指标已经采集了。

关于 kube-state-metrics 的更多用法可以查看官方 GitHub 仓库：https://github.com/kubernetes/kube-state-metrics