实战Prometheus

最近手头的项目开始从 PHP,Lua 迁移到 Golang,心想正好趁此机会夯实监控,提到 Golang 的监控,不得不说 prometheus 已经是标配,在 Golang 里集成起来非常简单:

package main

import (
        "net/http"

        "github.com/prometheus/client_golang/prometheus/promhttp"
)

func main() {
        http.Handle("/metrics", promhttp.Handler())
        http.ListenAndServe(":6060", nil)
}

如果想在本地 docker 里部署 prometheus,那么只需一条 docker run 命令:

shell> docker run -p 9090:9090 prom/prometheus

运行后打开浏览器浏览 http://localhost:9090/targets 即可,这里显示了相关的监控信息,缺省情况下,监控了 prometheus 本身。

虽然在本地 docker 里部署非常简单,但是如果想在 kubenetes 里部署的话却是另一番经景象了,加之官方文档语焉不详,以至于我几次想中途而废,还好最后坚持下来了,本文记录了我在部署过程中遇到的一些坑坑洼洼以及解决方法。

关于配置的问题

Prometheus 缺省的配置文件是「/etc/prometheus/prometheus.yml」,如果我们要修改配置文件的话,那么按照官方文档里的说明,需要自定义一个 Dockerfile 文件:

FROM prom/prometheus
ADD prometheus.yml /etc/prometheus/

然后再构建新的镜像:

shell> docker build -t my-prometheus .
shell> docker run -p 9090:9090 my-prometheus

不得不说有点繁琐,实际上利用 kubenetes 的 ConfigMap 即可:

apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus
  namespace: bpd-ie
data:
  prometheus.yml: |
    # my global config
    global:
      scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
      evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
      # scrape_timeout is set to the global default (10s).

    # Alertmanager configuration
    alerting:
      alertmanagers:
      - static_configs:
        - targets:
          # - alertmanager:9093

    # Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
    rule_files:
      # - "first_rules.yml"
      # - "second_rules.yml"

    # A scrape configuration containing exactly one endpoint to scrape:
    # Here it's Prometheus itself.
    scrape_configs:
      # The job name is added as a label `job=` to any timeseries scraped from this config.
      - job_name: 'prometheus'

        # metrics_path defaults to '/metrics'
        # scheme defaults to 'http'.

        static_configs:
        - targets: ['localhost:9090']

至于如何把 ConfigMap 挂到容器里,可以参考后面的配置。

关于服务发现的问题

传统监控软件往往采用的是 push 模式,而 prometheus 采用的是 pull 模式。好处是架构简单,被监控的节点不需要部署 agent 之类的代理进程,坏处是 prometheus 必须知道所有需要被监控的节点,比如缺省配置(/etc/prometheus/prometheus.yml)就会通过 static_configs 抓取 prometheus 服务本身的节点信息:

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
    - targets: ['localhost:9090']

如果需要被监控的节点比较固定的话,那么通过 static_configs 来硬编码倒也无妨,不过在 kubenetes 中,各个业务需要被监控的容器个数随时可能会发生变化,相应的容器地址也随时可能会发生变化,此时如果再通过 static_configs 来硬编码的话,那么无疑是自讨苦吃,相对而言更合理的方法是使用 kubernetes_sd_config 打通服务发现机制,从而实现自动配置节点信息,不过前提条件是我们必须先在 kubenetes 中配置 RBAC 信息:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus
rules:
- apiGroups: [""]
  resources:
  - nodes
  - nodes/metrics
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups:
  - extensions
  - networking.k8s.io
  resources:
  - ingresses
  verbs: ["get", "list", "watch"]
- nonResourceURLs: ["/metrics", "/metrics/cadvisor"]
  verbs: ["get"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: default

不过我的 kubenetes 账号权限不够,配置 RBAC 信息的时候会报错:

clusterrolebindings.rbac.authorization.k8s.io “prometheus” is forbidden: User “…” cannot patch resource “clusterrolebindings” in API group “rbac.authorization.k8s.io” at the cluster scope

找 kubenetes 管理员来配置固然可以解决问题,但是以后有相关问题的话会不可避免的依赖上别人了,最好还是能自己解决问题:既然 kubernetes_sd_config 有困难,那么我们不妨考虑换一种服务发现机制,比如说 dns_sd_config,通过域名解析动态获取节点:

scrape_configs:
  - job_name: 'foo'
  dns_sd_configs:
  - names: ['foo.default.svc.cluster.local']
    type: A
    port: 6060

当然,我们还需要在 kubenetes 里把需要被监控的业务配置成 Headless Service,以便 kubenets 能够为每一个 POD 提供一个稳定的并且唯一的网络标识,也就是内网域名:

apiVersion: v1
kind: Service
metadata:
  name: foo
  namespace: default
spec:
  clusterIP: None

说明:关于 Headeless Service 和内网域名的相关知识,如果不清楚,那么可以参考我以前写的文章:「手把手教你用ETCD」,里面有详细的介绍。

此外,说一点题外话,假如使用 kubernetes_sd_config 作为服务发现方式,设想下面一个场景:集群里有非常多的节点,但是你只想监控其中的一部分,那么如何配置呢?答案是通过 kubenetes 的 annotations 功能,标识出你要监控的节点,然后在 prometheus 里 relable,详细的介绍可以参考 stackoverflow 上的相关内容

关于数据持久化的问题

一般来说,我们通过 kubenetes 部署的都是一些无状态的服务,而对于 prometheus 服务而言,它应该是一个有状态的服务(StatefulSet),也就是说需要考虑数据持久化, 否则一重启,监控信息的历史记录都丢失了,肯定不是我们所希望看到的:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: prometheus
  namespace: default
  labels:
    app: prometheus
spec:
  serviceName: prometheus
  replicas: 1
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      dnsPolicy: ClusterFirst
      containers:
      - name: prometheus
        image: prom/prometheus:v2.22.0
        imagePullPolicy: Always
        ports:
        - name: http
          containerPort: 9090
          protocol: TCP
        volumeMounts:
        - name: datadir
          mountPath: /prometheus
        - name: configfile
          mountPath: "/etc/prometheus/prometheus.yml"
          subPath: prometheus.yml
        resources:
          limits:
            cpu: "1"
            memory: 512Mi
          requests:
            cpu: "1"
            memory: 512Mi
      volumes:
      - name: configfile
        configMap:
          name: prometheus
      # securityContext:
      #   runAsNonRoot: true
      #   runAsUser: 65534
      #   runAsGroup: 65534
      #   fsGroup: 65534
  volumeClaimTemplates:
  - metadata:
      name: datadir
    spec:
      storageClassName: ...
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 10Gi

不过当我配置 StatefulSet 的时候,kubenetes 却报错了:

pod has unbound immediate PersistentVolumeClaims

相关描述无法直观看出问题出在哪,好在还可以查日志:

shell> kubectl logs prometheus-0

结果看到了真正的错误原因:

open /prometheus/queries.active: permission denied

以此信息为关键字去 github 上搜索,可以找到相关的 issue,确认是权限问题。网上能查到一些解决方法,比如 GoogleCloudPlatform 是通过在 initContainers 里执行 chmod 解决的,不过更好的方法是通过 securityContext 设置 非 root 权限:

securityContext:
  runAsNonRoot: true
  runAsUser: 65534
  runAsGroup: 65534
  fsGroup: 65534

至于为什么是 65534,可以本地运行 docker 容器后看看使用的是什么账号:

shell> docker exec $(docker ps -qf ancestor=prom/prometheus) id
uid=65534(nobody) gid=65534(nogroup)

其它问题

差点忘了说 grafana,既然说 prometheus,怎么能忘了 grafana 呢!grafana 对 prometheus 的支持很好,使用起来非常简单,按照官问文档的说明配置即可,没有什么可说的,我要说的是关于 Dashboard 的选择,现在最流行的是 Go Metrics(10826),多数时候,它也是最好的,不过它有一个缺点:它是基于 kubenetes 里的 namespace / pod 筛选的,如果你没有使用基于 kubenetes 的服务发现机制,比如本文使用的是基于 dns 的服务发现机制,那么筛选功能就失效了,基于此,我做了一个修改版本的 Go Metrics(13240),它是基于 job / instance 筛选的,效果如下:

Grafana

Grafana

最后,推荐一些资料:「Prometheus book」,「Prometheus监控Kubernetes系列」。

实战Prometheus》上有2个想法

发表评论

电子邮件地址不会被公开。 必填项已用*标注