一文读懂如何在Kubernetes上轻松实现自动化部署Prometheus

然后删除 kube-proxy 的 Pod，让它重启即可看到已正常抓取。

应用

至此，Prometheus 的服务端就全部部署完成了。接下来就是根据实际业务部署相应的 Exporter，ServiceMonitor 和 PrometheusRule 了。官方和社区有大量现成的 Exporters 可供使用，如果有特殊需求的也可以参考这里自行开发。

接下来我们讲讲如何快速集成 Prometheus 监控和报警。

我们之前提到过 Operator 通过 CRD 的方式提供了很多部署方面的自动化，Prometheus-Operator 就提供了四个 CRD，分别是

•  Prometheus，定义了 Prometheus 服务端，用来生成服务端控制器，保证了服务端的正常运行，我们只需要一个此 CRD 的实例
•  Alertmanager，定义了 AlertManager 服务，用来生成服务端控制器，保证了服务的正常运行，我们也只需要一个此 CRD 的实例
•  ServiceMonitor，定义了 Prometheus 抓取指标的目标，就是 Prometheus 界面 targets 页面看到的内容，此 CRD 帮助我们创建目标的配置
•  PrometheusRule，定义了 Prometheus 规则，就是 Prometheus 界面 Rules 页面看到的内容，此 CRD 帮助我们创建规则的配置

Prometheus 和 Alertmanager CRD 主要是之前部署阶段关注的，在服务应用阶段，我们主要是创建各个 ServiceMonitor 和 PrometheusRule 来配置服务端。

Prometheus-Operator 默认会帮我们注册相关组件的抓取目标，如下图所示

我们要定义其他的抓取目标，首先来创建了一个 ServiceMonitor 抓取我们部署的 InfluxDB 的指标

apiVersion: monitoring.coreos.com/v1  
kind: ServiceMonitor  
metadata:  
  name: influxdb-scrape-targets  
  labels:  
    app.kubernetes.io/name: scrape-targets  
    app.kubernetes.io/instance: influxdb-target  
    release: prometheus  
spec:  
  # 用标签选择器来选择相应的 Pod  
  selector:  
    matchLabels:  
      app: influxdb  
      release: influxdb  
  # 选择命名空间  
  namespaceSelector:  
    matchNames:  
    - monitoring  
  # 定义抓取的配置，如端口、频率等  
  endpoints:  
    - interval: 15s  
      port: api 

我们在项目中创建了一个 Chart 模版（在 charts/scrape-targets/ 目录），能够快速的创建 ServiceMonitor，提供下面的配置文件

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!