本文是向大家介绍Prometheus监控的相关基本概念、部署和配置方法，能够帮助大家了解并使用Prometheus监控平台。
1、背景
公司技术全面建设容器化和Kubernetes化，需要有一定的工具和手段针对容器和Kubernetes进行监控，而Prometheus为容器、Kubernetes提供了监控采集、存储、计算、数据展示、报警等能力。
2、组件介绍
2.1、概述
Prometheus是一套开源的监控、报警、时间序列数据库的组合，起始是由SoundCloud公司开发的。从2016年加入CNCF，2016年6月正式发布1.0版本，2017年底发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合，到2018年8月毕业，现在已经成为Kubernetes的官方监控方案，社区活跃，第三方集成非常丰富。
2.2、特点
Prometheus是一个开源的完整监控解决方案，其对传统监控系统的测试和告警模型进行了彻底的颠覆，形成了基于中央化的规则计算、统一分析和告警的新模型。 相比于传统监控系统Prometheus具有以下优点：
易于管理：只有一个单独的二进制文件，不存在任何的第三方依赖，采用Pull的方式拉取数据
强大的数据模型：每一条时间序列由指标名称(Metrics Name)以及一组标签(Labels)唯一标识
强大的查询语言PromQL：内置了一个强大的数据查询语言PromQL，可以实现多种查询、聚合
高性能：单实例可以处理数以百万的监控指标、每秒处理数十万的数据点
易扩展：支持sharding和联邦集群，实现多数据中心
易集成：支持多种语言的SDK进行应用程序数据埋点，社区有丰富插件
可视化：自带Prometheus UI，可以进行查询与展示，Grafana也完整支持Prometheus。
开放性：使用sdk采集的数据可以被其他监控系统使用，不一定非要用Prometheus
2.3、Prometheus架构
Prometheus Server负责从 Exporter 拉取和存储监控数据,并提供一套灵活的查询语言（PromQL）
Retrieval: 采样模块
TSDB: 存储模块默认本地存储为tsdb
HTTP Server: 提供http接口查询和面板，默认端口为9090
Exporters/Jobs负责收集目标对象（host, container…）的性能数据，并通过 HTTP 接口供 Prometheus Server 获取。支持数据库、硬件、消息中间件、存储系统、http服务器、jmx等。只要符合接口格式，就可以被采集。
Short-lived jobs瞬时任务的场景，无法通过pull方式拉取，需要使用push方式，与PushGateway搭配使用
PushGateway可选组件，主要用于短期的 jobs。由于这类 jobs 存在时间较短，可能在 Prometheus 来 pull 之前就消失了。为此，这次 jobs 可以直接向 Prometheus server 端推送它们的 metrics。这种方式主要用于服务层面的 metrics，对于机器层面的 metrices，需要使用 node exporter。
客户端sdk 官方提供的客户端类库有go、java、scala、python、ruby，其他还有很多第三方开发的类库，支持nodejs、php、erlang等
Alertmanager从 Prometheus server 端接收到 alerts 后，会进行去除重复数据，分组，并路由到对收的接受方式，发出报警。常见的接收方式有：电子邮件，pagerduty，OpsGenie, webhook 等。
Service Discovery
服务发现，Prometheus支持多种服务发现机制：文件，DNS，Consul,Kubernetes,OpenStack,EC2等等。基于服务发现的过程并不复杂，通过第三方提供的接口，Prometheus查询到需要监控的Target列表，然后轮训这些Target获取监控数据。
其大概的工作流程是：
Prometheus server 定期从配置好的 jobs 或者 exporters 中拉 metrics，或者接收来自 Pushgateway 发过来的 metrics，或者从其他的 Prometheus server 中拉 metrics。
Prometheus server 在本地存储收集到的 metrics，并运行已定义好的 alert.rules，记录新的时间序列或者向 Alertmanager 推送警报。
Alertmanager 根据配置文件，对接收到的警报进行处理，发出告警。
在Grafana图形界面中，可视化展示数据。
3、部署Prometheus监控
3.1、Kubernetes集群部署
3.1.1、环境要求
Kubernetes 1.9.6以上
PV dynamic provisioning support on the underlying infrastructure (StorageClass)或已部署外部
Helm 2或3
3.1.2、配置Pormetheus
3.1.2.1、部署清单
prometheus
.
├── alertmanager
│ ├── alertmanager.yaml
│ ├── prometheus-webhook
│ ├── prometheus-webhook-dingtalk
│ ├── prometheus-webhook-dingtalk-order
│ ├── reload_alertmanager.sh
│ └── rules
├── exporter
│ ├── blackbox
│ ├── clickhouse
│ ├── ingress-nginx
│ ├── nacos
│ ├── nginx
│ ├── node
│ ├── redis
│ └── zookeeper
├── install.sh
├── kube-prometheus-stack
│ ├── Chart.lock
│ ├── charts
│ ├── Chart.yaml
│ ├── CONTRIBUTING.md
│ ├── crds
│ ├── README.md
│ ├── templates
│ └── values.yaml
├── persistent-volume
│ ├── grafana-local-pv.yaml
│ └── prometheus-local-pv.yaml
└── uninstall.sh
3.1.2.2、修改install.sh配置
3.1.3、安装Prometheus
3.1.3.1、执行安装脚本
bash install.sh
3.1.3.2、查看是否安装成功
kubectl get pod -n monitoring
4、可视化管理
4.1、开启grafana访问
4.1.1、设置grafana的svc为NodePort
kubectl edit svc -n monitoring monitor-grafana
4.1.2、查看grafana访问端口
$ kubectl get svc -n monitoring monitor-grafana
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
monitor-grafana NodePort 192.168.111.108 <none> 80:32749/TCP 75d
4.2、登陆grafana控制台
4.3、导入Grafana Dashboard
可通过三种方式导入Dashboard
从本地json文件导入
从grafana官网导入
手动输入json内容
4.3.1、导入本地json文件
4.3.2、从grafana官网导入dashboard
4.3.3、手动输入json内容
4.4、查看Grafana Dashboard
4.5、管理Grafana Dashboard
可通过编辑修改查询语句等
5、告警管理
5.1、配置alertmanager
5.1.1、alertmanager配置清单
.
├── alertmanager.yaml
├── prometheus-webhook
│ ├── deployment.yaml
│ └── service.yaml
├── prometheus-webhook-dingtalk
│ ├── config
│ │ ├── config.yaml
│ │ └── template.tmpl
│ ├── configmap.yaml
│ ├── configmap.yaml_20220303
│ ├── deployment.yaml
│ └── service.yaml
├── prometheus-webhook-dingtalk-order
│ ├── config
│ │ └── config.ini
│ ├── configmap.yaml
│ ├── deployment.yaml
│ └── service.yaml
├── reload_alertmanager.sh
└── rules
├── bigdata.rules.yaml
├── dns.rules.yaml
├── node.rules.yaml
├── pod.rules.yaml
├── redis.rules.yaml
├── website.rules.yaml
└── zookeeper.rules.yaml
5.1.2、修改alertmanager.yaml
配置说明：
全局配置（global）：用于定义一些全局的公共参数，如全局的SMTP配置，Slack配置等内容；
模板（templates）：用于定义告警通知时的模板，如HTML模板，邮件模板等；
告警路由（route）：根据标签匹配，确定当前告警应该如何处理；
接收人（receivers）：接收人是一个抽象的概念，它可以是一个邮箱也可以是微信，Slack或者Webhook等，接收人一般配合告警路由使用；
抑制规则（inhibit_rules）：合理设置抑制规则可以减少垃圾告警的产生
5.1.3、重新加载alertmanager配置
bash reload_alertmanager.sh
5.2、配置Prometheus告警规则
5.2.1、 创建PrometheusRule的yaml文件
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
labels:
app: kube-prometheus-stack
release: monitor
name: monitor-prometheus-node-rules
namespace: monitoring
spec:
groups:
- name: node.rules
rules:
- alert: CPU使用率告警
expr: (1 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[1m])))) * 100 >= 85
for: 5m
labels:
severity: warning
annotations:
summary: 'CPU使用率过高'
description: '服务器 {{ $labels.instance }}, 当前CPU使用率为 {{ $value | printf "%.2f%%" }}, 已持续5分钟超过设定阈值80%, 请检查服务是否正常'
- alert: 服务器负载告警(load average 5min)
expr: node_load5 / (count without(cpu, mode) (node_cpu_seconds_total{job="node-exporter", mode="idle"})) > 16
for: 5m
labels:
severity: warning
annotations:
summary: '服务器负载过高'
description: '服务器 {{ $labels.instance }}, 当前CPU平均负载为 {{ $value | printf "%.2f" }}, 大于CPU核数, 请尽快处理，以免影响服务器正常运行'
- alert: 内存使用率告警
expr: (1 - (node_memory_MemAvailable_bytes / (node_memory_MemTotal_bytes))) * 100 >= 85
for: 5m
labels:
severity: warning
annotations:
summary: '服务器可用内存不足'
description: '服务器 {{ $labels.instance }}, 当前内存使用率为 {{ $value | printf "%.2f%%" }}, 已持续5分钟超过设定阈值85%, 请检查服务是否正常'
- alert: 磁盘使用率告警
expr: max by (instance, device, mountpoint) ((node_filesystem_size_bytes{fstype=~"ext[234]|btrfs|xfs|zfs"} - node_filesystem_free_bytes{fstype=~"ext[234]|btrfs|xfs|zfs"}) / node_filesystem_size_bytes{fstype=~"ext[234]|btrfs|xfs|zfs"}) * 100 >= 80
for: 5m
labels:
severity: warning
annotations:
summary: '服务器磁盘剩余不足'
description: '服务器 {{ $labels.instance }}，当前磁盘目录【{{ $labels.mountpoint }}】,块设备【{{ $labels.device }}】使用率为 {{ $value | printf "%.2f%%" }}, 已持续5分钟超过80%, 容器有被驱逐的风险，请及时清理'
5.2.2、 执行创建Prometheus告警规则
kubectl apply -f node.rules.yaml
告警示例：
