Grafana 监控界面搭建分析

一、整体框架

在 Prometheus 的架构设计中，Prometheus Server 并不直接服务监控特定的目标，其主要任务负责数据的收集，存储并且对外提供数据查询支持。因此为了能够监控到某些东西，如主机的CPU使用率，需要借助到 Exporter。Prometheus 周期性的从 exporter 暴露的 HTTP 服务地址（通常命名为 /metrics）拉取监控样本数据。

Exporter 是一个相对开放的概念，其可以是一个独立运行的程序（如图 redis_exports），也可以是直接内置在监控目标（如图 kube-apiserver 内部实现）中。

ServiceMonitor 是Prometheus Operator 中的一个 CRD，它定义了 Prometheus 应该如何发现和收集服务的指标。部署 ServiceMonitor 可以让 Prometheus Operator 自动发现符合条件的服务，并为其收集和存储指标数据。

Prometheus Operator（以下简称Operator，操作人员），作为一个控制器负责控制几个主要的 CRD 资源对象，然后一直监控并维持这几个 CRD 资源对象的状态。

二、搭建流程

下面以添加 redis 的监控为例，介绍如何搭建组件的监控界面，一般情况下，首先需要准备 exporter，对于 redis 这种常用的第三方组件，网上已经有比较成熟的 exporter 可以直接借用，如果是公司内部的业务组件，则需要由业务本身增加对外 HTTP 服务接口，或者再单独开发抓取指标的应用作为 exporter.

1、Prometheus 和 Grafana 安装

2、Redis Exporter 安装

Exporter 的安装可以由多种形式，进程或者容器化都可以，只要保证能够正常从业务 redis 中获取数据即可，本次安装采用的是边车容器的方式

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: redis
    tier: database
    version: redis-4.0
  name: redis
  namespace: kubesphere-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
      tier: database
  template:
    metadata:
      labels:
        app: redis
        tier: database
        version: redis-4.0
    spec:
      initContainers:
      - name: init
        …………
      containers:
      - name: redis
        …………
        ports:
        - containerPort: 6379
      - name: redis-exporter
        image: 10.200.0.31:17443/cloud/eastcom.com/oliver006/redis_exporter:v1.55.0
        # 因为需要访问业务 redis，需要在传递 redis 地址（svc）和密码
        args:
          - '-redis.addr'
          - 'redis.kubesphere-system.svc:6379'
          - '-redis.password'
          - $(KUBESPHERE_REDIS_PASSWORD)
        env:
          - name: KUBESPHERE_REDIS_PASSWORD
            valueFrom:
              secretKeyRef:
                name: redis-secret
                key: auth
        securityContext:
          runAsUser: 59000
          runAsGroup: 59000
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        ports:
        - containerPort: 9121
      volumes:
      - name: redis-pvc
        persistentVolumeClaim:
          claimName: redis-pvc
      - name: redis-config
        configMap:
          name: redis-configmap
      affinity:
        …………
      nodeSelector: {}
      tolerations:
        - key: node-role.kubernetes.io/master
          effect: NoSchedule
        - key: CriticalAddonsOnly
          operator: Exists

3、Redis ServiceMonitor 创建

Prometheus 会定期从目标服务中抓取 metrics 数据，并将其存储在本地的时间序列数据库中。但是有时候并不是业务暴露的所有指标都需要被抓取，哪些指标需要被抓取，从哪里抓取，抓取的频率是多少都会影响抓取数据的及时性。借助 ServiceMonitor 可以实现以下几个功能：

1. 自动发现服务：Prometheus Operator 会自动监测 Kubernetes 集群中新创建的 Service 和 Endpoints 对象，并通过 ServiceMonitor CRD 来自动发现并管理它们。
2. 收集指标：一旦 ServiceMonitor 定义了要监测的服务，Prometheus 会自动收集这些服务的指标数据，并将其存储在 Prometheus 的时间序列数据库（TSDB）中。
3. 标准化指标标签：ServiceMonitor 允许在 Service 中定义标准的 Prometheus 标签，这些标签将应用于与该服务关联的所有 Endpoint。这样可以统一管理指标的标签，使得指标查询更加方便和一致。
4. 精确的指标筛选：使用 ServiceMonitor 可以精确地控制 Prometheus 应该收集哪些指标。通过在 ServiceMonitor 中定义合适的规则，可以过滤掉不必要的指标，减少 Prometheus 的负担，提高其性能。

1.   针对 redis 本次使用的 ServiceMonitor 的 yaml 文件如下：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: redis
  namespace: kubesphere-monitoring-system
  labels:
    app.kubernetes.io/component: redis
    app.kubernetes.io/name: redis
    app.kubernetes.io/part-of: kube-prometheus
    app.kubernetes.io/vendor: kubesphere
    app.kubernetes.io/version: 5.0.14-alpine
spec:
  # redis 这个 job 的标签，用于 Prometheus 在做数据删选时选择指标来源于哪个 job
  jobLabel: redis
  # 端点，定义要从哪个端口来抓取数据、频率、协议类型
  endpoints:
    - port: redis-exporter
      interval: 30s
      scheme: http
  # 标签选择器，选择从哪个 svc 来查询
  selector:
    matchLabels:
      app: redis
      tier: database
  # 筛选命名空间
  namespaceSelector:
    matchNames:
      - kubesphere-system

这个例子还比较简单，只是定义了数据的来源抓取频率等基本信息，下面的例子可以简单了解如何过滤指标，如图截取的是 kube-apiserver ServiceMonitor 的一部分信息，红框中就是一条过滤条件

# 基于 regex 匹配到的值进行相关的操作，对应的 action 如下，默认为 replace：
# replace: 如果 regex 匹配到，通过 replacement 中定义的值替换相应的值，并通过 target_label 设置并添加相应的 label 
# keep: 如果 regex 没有匹配到，丢弃
# drop: 如果 regex 匹配到，丢弃
# hashmod: 通过 modulus 指定的值把 source label 对应的 md5 值取模，添加一个新的 label，label name 通过 target_label 指定
# labelmap: 如果 regex 匹配到，使用 replacement 替换对就的 label name
# labeldrop: 如果 regex 匹配到，删除对应的 label
# labelkeep: 如果 regex 没有匹配到，删除对应的 label
[ action: <relabel_action> | default = replace ]

# 需要对 source labels 对应值进行正则匹配的表达式。
[ regex: <regex> | default = (.*) ]

# 从原始 labels 中取哪些 label 的值进行 relabel，取出来的值通过 separator 中的定义进行字符拼接。
[ sourceLabels : '[' <labelname> [, ...] ']' ]

4、Prometheus 配置查询

在 ServiceMonitor 创建完成后，可以通过 Prometheus 的 UI 界面来查看配置是否已经生效，修改访问形式为 NodePort 类型后，直接通过 IP:Port 访问，如：http://10.8.59.174:30909/targets

首先查看 EndPoints 信息，通过查询 redis 的相关资源，确定就是我们要访问的地址，再看 State 是否为 UP 状态，如果不是，则要检查 Redis exporter 的运行情况

接着可以在 Prometheus 的配置页面查看相应的配置是否已经更新，访问 http://10.8.59.174:30909/config，可以看到如下的内容，可以看到相应的信息已经自动的更新到了 Prometheus 的配置文件中

检查 Redis exporter 是否正常提供指标，可以用前面查看的 Endpoints 地址访问，因为 redis 没有设置证书等信息，因此可以直接通过 curl 查看

随便找一条指标信息，通过 Prometheus 的 UI 验证是否能够通过 Prometheus 成功查询，如选择 redis_up，通过 HELP 信息可以得知，该指标指示了目前由多少个 redis 实例在运行

5、Grafana 模板导入

在前面的步骤都已经完成的情况下，现在已经可以成功通过 Prometheus 抓取 Redis 监控信息了，接下来就是用更优雅的形式展示数据。同样的，针对 Redis 这样的第三方组件，网上有很多设计好的模板，如果是我们自己的业务组件，则需要自己创建。需要 Grafana 模板的可以在 https://grafana.com/grafana/dashboards/ 官网查询。Grafana 模板一般都是 json 格式的字符串，一般先借助 Grafana 的页面设计好模板后，再导出为 json 格式文件。

暂时无法在飞书文档外展示此内容

在 Grafana 的界面上导入模板或者导出模板

三、补充说明

进程方式部署 promethues 如何新增 target

本次示例都是在 Kubernetes 集群环境下搭建，且Prometheus 使用的是 operator 模式，因此直接使用的 ServiceMonitor 来设置暴露指标。但是，可能并非所有应用都是运行在集群中，如果 Prometheus 的部署方式是进程方式，可以通过直接修改 Prometheus 的配置文件的形式来暴露。

首先找到 Prometheus 的配置文件保存在哪里，修改 config.yaml，在其结尾追加上新的 exporter 信息

修改保存后，再使用 gzip 压缩并 base64 加密后保存到临时文件中

cat config.yaml | gzip -c | base64 >> temp.txt

读取临时文件的内容并替换

kubectl edit secret -n kubesphere-monitoring-system prometheus-k8s

如何调整为全屏监控

grafana 右上角有个按钮 点两次之后会隐藏所有侧边栏