prometheus原理2_prometheus aggragate 多个pod-优快云博客

prometheus的定义的metrics格式规范，缺省是在http(s)的url的/metrics输出。而metrics要么程序定义输出(模块或者自定义开发)，要么用官方的各种exporter(node-exporter，mysqld-exporter，memcached_exporter…)采集要监控的信息占用一个web端口然后输出成metrics格式的信息，prometheus server去收集各个target的metrics存储起来(tsdb)。用户可以在prometheus的http页面上用promQL(prometheus的查询语言)或者(grafana数据来源就是用)api去查询一些信息，也可以利用pushgateway去统一采集然后prometheus从pushgateway采集(所以pushgateway类似于zabbix的proxy)，prometheus的工作架构如下图：
在这里插入图片描述

为什么需要prometheus-operator
因为是prometheus主动去拉取的，所以在k8s里pod因为调度的原因导致pod的ip会发生变化，人工不可能去维持，自动发现有基于DNS的，但是新增还是有点麻烦。

Prometheus-operator的本职就是一组用户自定义的CRD资源以及Controller的实现，Prometheus Operator这个controller有BRAC权限下去负责监听这些自定义资源的变化，并且根据这些资源的定义自动化的完成如Prometheus Server自身以及配置的自动化管理工作。

在Kubernetes中我们使用Deployment、DamenSet、StatefulSet来管理应用Workload，使用Service、Ingress来管理应用的访问方式，使用ConfigMap和Secret来管理应用配置。我们在集群中对这些资源的创建，更新，删除的动作都会被转换为事件(Event)，Kubernetes的Controller Manager负责监听这些事件并触发相应的任务来满足用户的期望。这种方式我们成为声明式，用户只需要关心应用程序的最终状态，其它的都通过Kubernetes来帮助我们完成，通过这种方式可以大大简化应用的配置管理复杂度。

而除了这些原生的Resource资源以外，Kubernetes还允许用户添加自己的自定义资源(Custom Resource)。并且通过实现自定义Controller来实现对Kubernetes的扩展，不需要用户去二开k8s也能达到给k8s添加功能和对象。

因为svc的负载均衡，所以在K8S里监控metrics基本最小单位都是一个svc背后的pod为target，所以prometheus-operator创建了对应的CRD: kind: ServiceMonitor ，创建的ServiceMonitor里声明需要监控选中的svc的label以及metrics的url路径的和namespaces即可。

Prometheus Operator 通过监听上面的自定义资源（CR）的变动，并执行后续管理逻辑，入下
在这里插入图片描述

基本概念
Prometheus Operator 将会托管 Prometheus 的部署、管理工作，而且基于 K8s 中的 CRD，Prometheus Operator 新引入了若干 CR（自定义资源）：

Prometheus：描述将要部署的 Prometheus Server 集群
ServiceMonitor/PodMonitor：描述了 Prometheus Server 的 Target 列表
Alertmanager：描述 Alertmanager 集群
PrometheusRule：描述 Prometheus 的告警规则

工作原理
Prometheus Operator 通过监听上面的自定义资源（CR）的变动，并执行后续管理逻辑，入下图：

在这里插入图片描述
通过创建类型为 Prometheus 的资源（此处的 Prometheus 指的是 Prometheus Operator 定义的自定义资源），该 Prometheus 会通过 label selector 选择相关的 ServiceMonitor，而 ServiceMonitor 通过定义选择 Service 的 label selector 来选定需要监控的 Service ，并通过该 Service 对应的 Endpoints 获得需要监控的 Pod ip 列表。

部署被监控对象
通过 Deployment 部署有 3 个副本的应用：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      containers:
      - name: example-app
        image: fabxc/instrumented_app
        ports:
        - name: web
          containerPort: 8080

然后创建 Service 使得该服务可以提供稳定访问入口：

kind: Service
apiVersion: v1
metadata:
  name: example-app
  labels:
    app: example-app
spec:
  selector:
    app: example-app
  ports:
  - name: web
    port: 8080

注意 Service 中定义了 app=example-app 的 label，这是 ServiceMonitor 的选择依据。

部署监控
根据 Service 中定义的 Label，我们可以定义 ServiceMonitor：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: example-app
  labels:
    team: frontend
spec:
  selector:
    matchLabels:
      app: example-app
  endpoints:
  - port: web

ServiceMonitor 定义了 team=frontend 的 label，这也是 Prometheus 选择 ServiceMonitor 的依据。因此可以创建 Prometheus：

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus
spec:
  serviceAccountName: prometheus
  serviceMonitorSelector:
    matchLabels:
      team: frontend
  resources:
    requests:
      memory: 400Mi
  enableAdminAPI: false

这时就发现，已经有 prometheus 实例被启动了

原文

原文2