架构

这是官方的架构图

prometheus job_name分类 prometheus-operator_docker

prometheus-operator的作用主要是用来创建prometheus的相关资源以及监视与管理它创建出来的资源对象。

  • Operator： 根据自定义资源（Custom Resource Definition / CRDs）来部署和管理 Prometheus Server，同时监控这些自定义资源事件的变化来做相应的处理，是整个系统的控制中心。
  • Prometheus：声明 Prometheus deployment 期望的状态，Operator 确保这个 deployment 运行时一直与定义保持一致。
  • Prometheus Server： Operator 根据自定义资源 Prometheus 类型中定义的内容而部署的 Prometheus Server 集群，这些自定义资源可以看作是用来管理 Prometheus Server 集群的 StatefulSets 资源。
  • ServiceMonitor：声明指定监控的服务，描述了一组被 Prometheus 监控的目标列表。该资源通过 Labels 来选取对应的 Service Endpoint，让 Prometheus Server 通过选取的 Service 来获取 Metrics 信息。
  • Service：简单的说就是 Prometheus 监控的对象。
  • Alertmanager：定义 AlertManager deployment 期望的状态，Operator 确保这个 deployment 运行时一直与定义保持一致。

rometheus收集指标，然后根据规则发送警报给到alertmanager,alertmanager收到警报后，根据通知规则发送通知（短信，邮箱等）。

prometheus job_name分类 prometheus-operator_kubernetes_02

自定义资源

Prometheus Operater 定义了如下的四类自定义资源：

  • Prometheus
  • ServiceMonitor
  • Alertmanager
  • PrometheusRule

Prometheus

Prometheus 自定义资源（CRD）声明了在 Kubernetes 集群中运行的 Prometheus 的期望设置。包含了副本数量，持久化存储，以及 Prometheus 实例发送警告到的 Alertmanagers等配置选项。

每一个 Prometheus 资源，Operator 都会在相同 namespace 下部署成一个正确配置的 StatefulSet，Prometheus 的 Pod 都会挂载一个名为 <prometheus-name> 的 Secret，里面包含了 Prometheus 的配置。Operator 根据包含的 ServiceMonitor 生成配置，并且更新含有配置的 Secret。无论是对 ServiceMonitors 或者 Prometheus 的修改，都会持续不断的被按照前面的步骤更新。

kind: Prometheus #资源类型-prometheus
metadata: # 数据标签
spec: #规范
  alerting:
    alertmanagers:
    - name: prometheus-prometheus-oper-alertmanager # 定义该 Prometheus 对接的 Alertmanager 集群的名字, 在 default 这个 namespace 中
      namespace: default
      pathPrefix: /
      port: web 
  baseImage: quay.io/prometheus/prometheus #镜像
  replicas: 2 # 定义该 Proemtheus “集群”有两个副本，说是集群，其实 Prometheus 自身不带集群功能，这里只是起两个完全一样的 Prometheus 来避免单点故障
  ruleSelector: # 定义这个 Prometheus 需要使用带有 prometheus=k8s 且 role=alert-rules 标签的 PrometheusRule
    matchLabels:
      prometheus: k8s
      role: alert-rules
  serviceMonitorNamespaceSelector: {} # 定义这些 Prometheus 在哪些 namespace 里寻找 ServiceMonitor
  serviceMonitorSelector: # 定义这个 Prometheus 需要使用带有 k8s-app=node-exporter 标签的 ServiceMonitor，不声明则会全部选中
    matchLabels:
      k8s-app: node-exporter
  version: v2.10.0

ServiceMonitor

ServiceMonitor 自定义资源(CRD)能够声明如何监控一组动态服务的定义。它使用标签选择定义一组需要被监控的服务。这样就允许组织引入如何暴露 metrics 的规定，只要符合这些规定新服务就会被发现列入监控，而不需要重新配置系统。

要想使用 Prometheus Operator 监控 Kubernetes 集群中的应用，Endpoints 对象必须存在。Endpoints 对象本质是一个 IP 地址列表。通常，Endpoints 对象由 Service 构建。Service 对象通过对象选择器发现 Pod 并将它们添加到 Endpoints 对象中。

一个 Service 可以公开一个或多个服务端口，通常情况下，这些端口由指向一个 Pod 的多个 Endpoints 支持。这也反映在各自的 Endpoints 对象中。

Prometheus Operator 引入 ServiceMonitor 对象，它发现 Endpoints 对象并配置 Prometheus 去监控这些 Pods。

ServiceMonitorSpec 的 endpoints 部分用于配置需要收集 metrics 的 Endpoints 的端口和其他参数。在一些用例中会直接监控不在服务 endpoints 中的 pods 的端口。因此，在 endpoints 部分指定 endpoint 时，请严格使用，不要混淆。

注意：endpoints（小写）是 ServiceMonitor CRD 中的一个字段，而 Endpoints（大写）是 Kubernetes 资源类型。

ServiceMonitor 和发现的目标可能来自任何 namespace。这对于跨 namespace 的监控十分重要，比如 meta-monitoring。使用 PrometheusSpec 下 ServiceMonitorNamespaceSelector, 通过各自 Prometheus server 限制 ServiceMonitors 作用 namespece。使用 ServiceMonitorSpec 下的 namespaceSelector 可以现在允许发现 Endpoints 对象的命名空间。要发现所有命名空间下的目标，namespaceSelector 必须为空。

通过selector匹配service。通过标签选择endpoints，实现动态发现服务。

kind: ServiceMonitor
metadata:
  labels:
    k8s-app: node-exporter # 这个 ServiceMonitor 对象带有 k8s-app=node-exporter 标签，因此会被 Prometheus 选中
  name: node-exporter
  namespace: default
spec:
  selector:
    matchLabels: # 定义需要监控的 Endpoints，带有 app=node-exporter 且 k8s-app=node-exporter标签的 Endpoints 会被选中
      app: node-exporter
      k8s-app: node-exporter
  endpoints:
  - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
    interval: 30s # 定义这些 Endpoints 需要每 30 秒抓取一次
    targetPort: 9100 # 定义这些 Endpoints 的指标端口为 9100
    scheme: https
  jobLabel: k8s-app