Prometheus插件平滑迁移实践

由于Prometheus（停止维护）仅支持v1.21及之前的集群版本，若您需要将集群升级至v1.21以上，您需要将停止维护的Prometheus插件迁移至云原生监控插件，以获取后续的技术支持。本文将指导您将已经停止维护的Prometheus插件迁移至云原生监控插件。

云原生监控插件与Prometheus插件的对比如下：

云原生监控插件	Prometheus插件（停止维护）
云原生监控插件是基于Prometheus、VictoriaMetrics及PrometheusOperator社区构建的。配置由Prometheus自定义资源配置，支持ServiceMonitor、PodMonitor、基于Annotations的自动发现机制以及静态配置的方式。静态配置采集目标的方式完全兼容Prometheus插件的采集目标配置方式。基于Annotations的自动发现机制更强，完全兼容与Prometheus插件（为避免不必要的重复采集，自动发现默认忽略kube-system和monitoring命名空间下的Service和Pod）。	Prometheus插件是基于社区原生Prometheus构建的。配置由monitoring命名空间下名为prometheus的ConfigMap统一配置。不支持常见的ServiceMonitor或PodMonitor。自定义配置仅支持手动配置或基于Annotations的自动发现机制。

云原生监控插件

Prometheus插件（停止维护）

云原生监控插件是基于Prometheus、VictoriaMetrics及PrometheusOperator社区构建的。
配置由Prometheus自定义资源配置，支持ServiceMonitor、PodMonitor、基于Annotations的自动发现机制以及静态配置的方式。
静态配置采集目标的方式完全兼容Prometheus插件的采集目标配置方式。
基于Annotations的自动发现机制更强，完全兼容与Prometheus插件（为避免不必要的重复采集，自动发现默认忽略kube-system和monitoring命名空间下的Service和Pod）。

Prometheus插件是基于社区原生Prometheus构建的。
配置由monitoring命名空间下名为prometheus的ConfigMap统一配置。
不支持常见的ServiceMonitor或PodMonitor。
自定义配置仅支持手动配置或基于Annotations的自动发现机制。

迁移方案

Prometheus插件迁移至云原生监控插件有多种方案可供选择，您可根据您的实际诉求，选择最合适的方案进行迁移。

云原生监控插件支持无本地存储的轻量化模式（推荐）和基于本地存储的传统模式。

无本地存储的轻量化模式指标数据存储于AOM，您的Grafana等应用需要对接至AOM。该模式集群内资源占用非常低，可以显著节省您的计算和存储成本，AOM服务按照上报的指标量进行计费，其中，基础指标免费，自定义指标按量计费；自定义指标可以按需废弃，您可以仅保留基础免费指标使用AOM。

该模式暂不支持基于自定义普罗语句的HPA。
基于本地存储的传统模式与Prometheus插件类似，数据存储于集群内，消耗较多的计算和存储成本并无法支撑多于400节点的大规模集群。

我们更推荐您切换为本地存储的轻量化模式，将监控数据对接至AOM并按需废弃自定义指标，从成本和可靠性角度来看，是更优的选择。

前提条件

集群版本为v1.21。
Prometheus插件已升级至可升级的最新版本。
可迁移的云原生监控插件目标版本为3.10.1及以上。

采集数据迁移

迁移至基于本地存储的传统模式时，数据库是自动迁移的，您只需继续执行后续采集配置迁移步骤即可。
迁移至无本地存储的轻量化模式时，由于原本的数据存储于集群内的PVC中，后续新增数据存储于AOM，数据无法直接迁移，但是您仍旧可以利用历史数据老化机制将您的本地数据平滑过渡到AOM，具体步骤如下：
1. 您可以先迁移至基于本地存储的传统模式，并对接AOM普罗实例，作为平滑迁移的过渡。
  历史数据您可以直接查询集群内的Prometheus，而新增数据不仅存在于集群内的Prometheus，也会同时存在于AOM中。
2. 随着历史数据的老化，集群内的Prometheus将会与AOM中数据完全相同（例如：您的Prometheus存储时长设置为7天，7天以后AOM中的数据将会和集群内的Prometheus数据完全相同）。
3. 编辑云原生监控插件，切换为无本地存储的轻量化模式，您可以节省较多的计算和存储资源，将监控数据存储于AOM中。
4. 确定AOM中数据符合预期并将您的Grafana对接至AOM后，删除monitoring命名空间下的PVC（名称中含有prometheus-server的PVC）。

采集配置迁移

迁移prometheus配置

若您从未修改过monitoring命名空间下名为prometheus的ConfigMap，则无需关注本步骤。

执行以下命令，备份prometheus。

kubectl get cm prometheus -nmonitoring -oyaml > prometheus.backup.yaml

在monitoring命名空间下创建additional-scrape-configs的Secret，内容为prometheus中的scrape_configs部分中您自定义的采集配置（即：job_name为kubernetes-cadvisor、kubernetes-nodes、kubernetes-service-endpoints、kubernetes-pods、istio-mesh以外的部分，切勿配置以上几个Job至该Secret中，否则会导致指标采集出现重复，影响监控业务）。

Secret内容示例如下：

kind: Secret
apiVersion: v1
type: Opaque
metadata:
  name: additional-scrape-configs
  namespace: monitoring
stringData:
  prometheus-additional.yaml: |-
    - job_name: custom-job-tes
      metrics_path: /metrics
      relabel_configs:
      - action: keep
        source_labels:
        - __meta_kubernetes_pod_label_app
        - __meta_kubernetes_pod_labelpresent_app
        regex: (prometheus-lightweight);true
      - action: keep
        source_labels:
        - __meta_kubernetes_pod_container_port_name
        regex: web
      kubernetes_sd_configs:
      - role: pod
        namespaces:
          names:
          - monitoring

待云原生监控插件安装完毕后，配置用户持久化参数。

kubectl edit cm persistent-user-config -nmonitoring

在其中operatorConfigOverride下新增一行参数如下：

apiVersion: v1
data:
  lightweight-user-config.yaml: |
    customSettings:
      additionalScrapeConfigs: []
      agentExtraArgs: []
      metricsDeprecated:
        globalDeprecateMetrics: []
      nodeExporterConfigOverride: []
      operatorConfigOverride: 
      - --common.prom.default-additional-scrape-configs-key=prometheus-additional.yaml

点击放大

保存退出后，等待1分钟左右，即可在Grafana或AOM页面处看到您的自定义采集任务。

配置kube-system和monitoring命名空间下的自定义采集任务

若您的自定义指标基于Annotations的自动发现机制采集，且不在kube-system和monitoring命名空间下，无需关注本步骤。

出于防止重复采集并保证只采集基础指标的需要，云原生监控插件默认不会自动发现kube-system和monitoring下的采集任务，需要对应的配置ServiceMonitor或PodMonitor。

例如，以下的PodMonitor采集包含app: test-app标签的Pod的，采集路径是/metrics，采集端口名称是metrics：

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  labels:
    component: controller
    managed-by: prometheus-operator
    metrics: cceaddon-nginx-ingress
  name: nginx-ingress-controller
  namespace: monitoring
spec:
  jobLabel: nginx-ingress
  namespaceSelector:
    matchNames:
    - monitoring
  podMetricsEndpoints:
  - interval: 15s
    path: /metrics
    port: metrics
    relabelings:
    - action: drop
      regex: "true"
      sourceLabels:
      - __meta_kubernetes_pod_container_init
    tlsConfig:
      insecureSkipVerify: true
  selector:
    matchLabels:
      app: test-app

扩充系统预置采集任务的指标

若您只使用了常见的kubelet、cadiviser、node-exporter、kube-state-metrics等指标，且您使用的指标均在云原生监控插件的基础指标范围内，无需关注本步骤。

查看预置的ServiceMonitor：
```
kubectl get servicemonitor -nmonitoring
```
查看预置的PodMonitor：
```
kubectl get podmonitor -nmonitoring
```
- kubelet和cadiviser由ServiceMonitor kubelet控制。
- node-exporter指标由ServiceMonitor node-exporter控制。
- kube-state-metrics指标由ServiceMonitor kube-state-metrics控制。
扩充指标白名单范围直接编辑对应的ServiceMonitor/PodMonitor即可。

此处经过编辑的ServiceMonitor/PodMonitor配置在升级插件时一般不会受影响，但是不排除被覆盖的可能。升级插件前请备份相关修改，并于升级后手动确认。
- 扩充cadiviser指标
  1. 执行如下命令，编辑ServiceMonitor kubelet。
```
kubectl edit servicemonitor kubelet -nmonitoring
```
  2. ServiceMonitor kubelet包含两个endpoints，第一个是kubelet指标，第二个是cadiviser指标，我们找到第二个endpoints中的白名单部分，您可按需添加（不建议删除已有白名单中的指标，已有的指标均为免费指标，删除后可能会影响容器智能分析页面功能），如下图，您添加了一个名为your_metrics1的指标。
  3. 如果您需要采集ServiceMonitor kubelet所有的指标，您可以直接把整个metricRelabelings块完全删除（删除下图中红框的全部内容）。
    
    如果您需要扩充kubelet指标，编辑第一个endpoints即可。
- 扩充kube-state-metrics指标
  1. 执行如下命令，编辑ServiceMonitor kube-state-metrics，具体步骤与“扩充cadiviser指标”中类似，ServiceMonitor kube-state-metrics只有一个endpoints，直接编辑即可。
```
kubectl edit servicemonitor kube-state-metrics -nmonitoring
```
  2. 修改kube-state-metrics负载的启动命令中的指标暴露部分，添加需要的指标，并以英文逗号分隔。
```
kubectl edit deploy kube-state-metrics -nmonitoring
```
  3. 保存退出即可。
- 扩充node-exporter指标
  1. 执行如下命令，编辑ServiceMonitor node-exporter，具体步骤与“扩充cadiviser指标”中类似，ServiceMonitor node-exporter只有一个endpoints，直接编辑即可。
```
kubectl edit servicemonitor node-exporter -nmonitoring
```
    参考社区的collector指标说明，您可以根据需求开启更多的collector。
  2. 执行如下命令，查看当前云原生监控插件自带的node-exporter的collector开启及关闭情况（出于资源消耗角度考虑，云原生监控插件在社区的基础上，额外关闭了几个collector）。
```
kubectl get ds node-exporter -nmonitoring -oyaml
```
  3. 确认清楚您需要额外开启的collector后，执行如下命令编辑持久化配置ConfigMap。
```
kubectl edit cm persistent-user-config -nmonitoring
```
    如果您需要移除云原生监控插件已经配置的某个屏蔽项参数，在nodeExporterConfigOverride下添加条目，配置"drop:<屏蔽项参数>"即可。比如您需要开启arp指标的收集，则配置drop:--no-collector.arp即可。示例如下：
  4. 保存退出，可以发现node-exporter负载正在滚动升级，等待升级完成后查看node-exporter的启动参数，发现--no-collector.arp已经被移除。
```
kubectl get ds node-exporter -nmonitoring -oyaml
```
  5. 如果您需要新增某个采集项，直接在持久化配置ConfigMap中配置开启参数即可，例如您需要开启软中断softirqs采集，执行如下命令编辑ConfigMap：
```
kubectl edit cm persistent-user-config -nmonitoring
```
    在nodeExporterConfigOverride下添加条目--collector.softirqs即可：
  6. 保存退出，可以发现node-exporter负载正在滚动升级，等待升级完成后查看node-exporter的启动参数，发现--collector.softirqs已经被指定，node-exporter开始暴露软中断softirqs指标：
```
kubectl get ds node-exporter -nmonitoring -oyaml
```