运维监控平台（Prometheus + Grafana）部署与维护

Kendra9192026-10-15 15:23

运维监控平台（Prometheus + Grafana）部署与维护

  • 一、监控平台概述
    • [1.1 平台定位与整体架构](#1.1 平台定位与整体架构)
    • [1.2 技术栈说明](#1.2 技术栈说明)
  • 二、平台部署流程
    • [2.1 部署前准备](#2.1 部署前准备)
    • [2.2 Prometheus 部署（以单套为例）](#2.2 Prometheus 部署（以单套为例）)
    • [2.3 Exporter 部署](#2.3 Exporter 部署)
    • [2.4 Grafana 部署与数据源接入](#2.4 Grafana 部署与数据源接入)
    • [2.5 仪表盘导入（六大文件夹）](#2.5 仪表盘导入（六大文件夹）)
    • [2.6 告警链路（建议实装）](#2.6 告警链路（建议实装）)
    • [2.7 部署验证清单](#2.7 部署验证清单)
  • 三、部署完成后：日常监控查看
    • [3.1 Grafana 基础操作](#3.1 Grafana 基础操作)
    • [3.2 六大文件夹分别看什么](#3.2 六大文件夹分别看什么)
    • [3.3 Node Exporter 仪表盘详解（最常用）](#3.3 Node Exporter 仪表盘详解（最常用）)
      • [3.3.1 总表列含义](#3.3.1 总表列含义)
      • [3.3.2 单机详情面板（Resource Details）](#3.3.2 单机详情面板（Resource Details）)
    • [3.4 SSL Certificate Monitor 解读](#3.4 SSL Certificate Monitor 解读)
    • [3.5 JVM / HikariCP 解读](#3.5 JVM / HikariCP 解读)
  • 四、定期巡检流程（SOP）
    • [4.1 每日巡检（3~5 分钟）](#4.1 每日巡检（3~5 分钟）)
    • [4.2 长假/节前专项巡检（以 dev-k8s 三 master 为例）](#4.2 长假/节前专项巡检（以 dev-k8s 三 master 为例）)
    • [4.3 巡检独立命令清单（逐条可跑）](#4.3 巡检独立命令清单（逐条可跑）)
    • [4.4 巡检判定与处置表](#4.4 巡检判定与处置表)
  • 五、常见风险与维护要点
    • [5.1 磁盘写满：头号风险](#5.1 磁盘写满：头号风险)
    • [5.2 内存 vs 磁盘增长机制差异（重要，勿误判）](#5.2 内存 vs 磁盘增长机制差异（重要，勿误判）)
    • [5.3 etcd 健康与时钟同步](#5.3 etcd 健康与时钟同步)
    • [5.4 K8s 组件证书周期](#5.4 K8s 组件证书周期)
    • [5.5 SSL 业务证书续期 SOP](#5.5 SSL 业务证书续期 SOP)
  • 六、回滚与应急
    • [6.1 变更三件套（任何生产写操作前）](#6.1 变更三件套（任何生产写操作前）)
    • [6.2 应急判断表](#6.2 应急判断表)
  • 七、文档沉淀与持续优化

本文基于一套已落地的企业级监控平台（Grafana 统一入口 + 多套 Prometheus + 全量 Exporter）整理，覆盖部署流程、日常监控查看、定期巡检、面板解读、维护与应急五个阶段。所有命令均标注执行位置，可直接复制使用。适合刚接手该平台、或需要补齐 SOP 的运维同学。

一、监控平台概述

1.1 平台定位与整体架构

监控平台解决三件事：看得见（可视化）、报得出（告警）、查得到（排障）。本平台采用业界主流的 Prometheus 生态：

复制代码 
┌────────────── 采集层（Exporter）──────────────┐
│ node_exporter          每台宿主机              │
│ kube-state-metrics     K8s 对象状态            │
│ cAdvisor               容器指标（kubelet 内置） │
│ dcgm-exporter          GPU 节点（DaemonSet）   │
│ blackbox_exporter      HTTP/域名/证书探测       │
│ Micrometer/Jolokia     Java 应用 JVM+连接池    │
│ ModelArts 采集器        华为云 ModelArts         │
└────────────────────┬──────────────────────────┘
                     ↓  Pull（Prometheus 主动抓取）
┌────────────── 存储层（Prometheus）─────────────┐
│ prom-k8s            dev-k8s 集群             │
│ prom-k8s-test       测试集群                  │
│ prom-ucloud         Ucloud 环境              │
│ prom-k8s-ucloud-test Ucloud 测试环境          │
└────────────────────┬──────────────────────────┘
                     ↓  查询
┌────────────── 展示层 ───────────────────────────┐
│ Grafana（统一入口，仪表盘按文件夹分组）          │
└──────────────────────────────────────────────────┘

判读技巧 ：在任意仪表盘顶部的数据源变量下拉里能看到 prom-k8s / prom-k8s-test / prom-ucloud / prom-k8s-ucloud-test，说明后端至少部署了 4 套独立的 Prometheus，分别对应不同集群/云环境，由同一个 Grafana 统一查询。

1.2 技术栈说明

组件 作用 部署形态
Prometheus 指标时序数据库（抓取+存储+查询） 二进制 / 容器，每环境一套
Grafana 可视化与看板 独立服务（本文入口 grafana.example.cn）
node_exporter 宿主机的 CPU/内存/磁盘/网络/TCP systemd 或 DaemonSet
kube-state-metrics K8s 对象状态（Pod/Node/Deploy...） 集群内 Deployment
cAdvisor 容器资源指标 kubelet 内置，无需单独装
dcgm-exporter NVIDIA GPU 指标 GPU 节点 DaemonSet
blackbox_exporter 黑盒探测（HTTP/证书/端口） 独立 Deployment
Micrometer + JMX/Jolokia Java 应用 JVM、HikariCP 连接池 应用内嵌，暴露 /actuator/prometheus
Alertmanager 告警分发（钉钉/飞书/邮件） 可选，建议实装

二、平台部署流程

2.1 部署前准备

  • 规划环境：按「每集群/每云一套 Prometheus」划分（如 dev-k8s、test、ucloud），避免跨云拉取指标。
  • 统一版本（示例）：Prometheus 2.45+，Grafana 10.x，node_exporter 1.6+，kube-state-metrics 2.9+。
  • 网络：Prometheus → 各 Exporter 端口可达；Grafana → 各 Prometheus 9090 可达；对外仅暴露 Grafana（HTTPS + 登录）。
  • 配置全部版本化 ：Prometheus 的 prometheus.yml、rules、Grafana 的 datasource/dashboard 用 Git 管理，禁止手工改线上不存档。

2.2 Prometheus 部署（以单套为例）

bash 复制代码 
# 在哪执行：Prometheus 所在主机
# 1) 下载并解压（示例版本）
wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz
tar xf prometheus-2.45.0.linux-amd64.tar.gz -C /opt/

# 2) 主配置文件 /opt/prometheus/prometheus.yml（节选）
cat > /opt/prometheus/prometheus.yml <<'EOF'
global:
  scrape_interval: 15s
  evaluation_interval: 15s
rule_files:
  - /opt/prometheus/rules/*.yml
scrape_configs:
  - job_name: node-exporter
    static_configs:
      - targets: ['10.0.0.11:9100','10.0.0.12:9100']   # 各宿主机 node_exporter
  - job_name: kubernetes-apiservers
    kubernetes_sd_configs: [{role: endpoints}]
EOF

# 3) 用 systemd 托管（推荐，便于开机自启与回滚）
cat > /etc/systemd/system/prometheus.service <<'EOF'
[Unit]
Description=Prometheus
After=network.target
[Service]
ExecStart=/opt/prometheus/prometheus --config.file=/opt/prometheus/prometheus.yml --storage.tsdb.path=/data/prometheus
Restart=always
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload && systemctl enable --now prometheus

多套 Prometheus 仅 prometheus.yml 的 scrape_configs 与监听端口不同，重复上述步骤即可。

2.3 Exporter 部署

bash 复制代码 
# 在哪执行：每台宿主机（node_exporter）
tar xf node_exporter-*.tar.gz -C /opt/
cat > /etc/systemd/system/node_exporter.service <<'EOF'
[Unit]
Description=node_exporter
[Service]
ExecStart=/opt/node_exporter/node_exporter
Restart=always
[Install]
WantedBy=multi-user.target
EOF
systemctl enable --now node_exporter   # 监听 9100
bash 复制代码 
# 在哪执行：K8s 控制面（集群内组件，kubectl apply）
# kube-state-metrics、dcgm-exporter 用官方 manifests 即可，示例：
kubectl apply -f https://github.com/kubernetes/kube-state-metrics/blob/master/examples/standard/clusterrole.yaml
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/dcgm-exporter/master/deployments/dcgm-exporter.yaml
# blackbox_exporter 同样 apply 到集群，探测目标写在 Grafana 的 Blackbox 仪表盘变量里
bash 复制代码 
# Java 应用侧（代码层，交给开发）：引入 micrometer-registry-prometheus
# 暴露端点后，在 Prometheus 的 scrape_configs 增加 job 指向 Pod 的 metrics 端口

2.4 Grafana 部署与数据源接入

bash 复制代码 
# 在哪执行：Grafana 主机
docker run -d -p 3000:3000 --name grafana grafana/grafana:10.4.0
# 登录后：Configuration → Data Sources → Add Prometheus
#   填 http://<prom-k8s-ip>:9090  → Save
#   重复添加 prom-k8s-test / prom-ucloud / prom-k8s-ucloud-test 四套

数据源命名建议与变量一致（prom-k8s 等），后续仪表盘顶部「数据源变量」才能直接切换环境。

2.5 仪表盘导入（六大文件夹）

在 Grafana → Dashboards → Import，粘贴官方/社区 Dashboard ID（JSON）：

文件夹 仪表盘 来源
服务器资源监控 Node Exporter Dashboard EN（StarsL.cn 版） 社区模板
服务器资源监控 DCGM Exporter Dashboard / Nvidia GPU Metrics NVIDIA 官方
k8s 资源监控 cluster_summary / pod_by_namespace 等 社区 k8s 模板
Web 资源监控 SSL Certificate Monitor 社区证书模板
Web 资源监控 Blackbox Exporter Dashboard 官方 blackbox
EnableAI HikariCP / JVM (Micrometer) 应用侧模板

导入后按业务归类到文件夹（文件夹=团队视图）。

2.6 告警链路（建议实装）

bash 复制代码 
# 在哪执行：告警机
# Prometheus rule 示例（磁盘>85% 告警）
cat > /opt/prometheus/rules/node.yml <<'EOF'
groups:
- name: node
  rules:
  - alert: DiskWillFull
    expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) < 0.15
    for: 10m
    labels: {severity: warning}
    annotations: {summary: "{{ $labels.instance }} 磁盘剩余 <15%"}
EOF
# 配 Alertmanager 把告警推到钉钉/飞书，做到"故障主动找你"

2.7 部署验证清单

  • 每套 Prometheus 的 /targets 页面无 DOWN
  • Grafana 能切换 4 个数据源变量并出图
  • 六大文件夹仪表盘均有数据（非空面板）
  • 告警规则加载成功（promtool check rules）
  • 配置已提交 Git

三、部署完成后：日常监控查看

3.1 Grafana 基础操作

  • 时间范围：右上角选 Last 6h / 24h；排障时改 5m/1h。
  • 自动刷新：右上角，日常 5m，排障 5s/10s。
  • 变量切换：顶部「数据源变量」切集群（prom-k8s ↔ prom-ucloud）；「Instance/Host」变量下钻单机。
  • 星标：常用看板点 ⭐，首页快速进。
  • 下钻：总表点行 → 自动选中该 Instance → 下方详情联动。

3.2 六大文件夹分别看什么

文件夹 看什么 健康信号
服务器资源监控 宿主机 CPU/内存/磁盘/网络/GPU 无红/橙行
k8s 资源监控 cluster_summary 全 Ready、Pod 无大量重启 节点全 Ready
Web 资源监控 SSL 证书到期、HTTP 响应、各阶段耗时 无红色证书、响应全 200
EnableAI HikariCP 连接池、JVM 堆/GC 无连接等待、堆不持续涨
模型平台监控 job_by_namespace、model_connect 任务正常、模型连通
ModelArts 资源监控 Cluster/Node/Task/User 训练集群资源正常

3.3 Node Exporter 仪表盘详解（最常用）

整页分三段：顶部总表（一台一行）→ 中部三个集群汇总图 → 下部单机详情。

3.3.1 总表列含义

列 含义 阈值
Uptime 开机时长 突然变小=重启过
CPU used% CPU 使用率(5m) >80% 橙 / >90% 红
Memory used% 内存使用率 >85% 关注（含缓存，看 Available 为准）
Partition used% 磁盘分区使用率 >80% 橙 / >90% 红（最先爆）
Disk read/write 磁盘读写 对照基线看毛刺
CurEstab 当前 TCP 连接 突降=服务挂；持续涨=连接泄漏
Download/Upload 网络带宽 突增确认是否合法

3.3.2 单机详情面板（Resource Details）

面板 看什么
Disk Space Used Basic 各挂载点使用率，etcd 数据盘最重要
Memory Basic 看 Available，非 used%
CPU iowait >10% = 磁盘瓶颈（etcd 节点最敏感）
System Load 1m 负载 vs CPU cores，current>cores 即过载
Time Spent Doing I/O IO 时间占比，>50% 说明磁盘打满
Disk R/W Time（参考<100ms） 单次 IO 延迟，远低于 100ms 健康
Network Sockstat TCP 连接分布（CurEstab=活连接）
Open File Descriptor 文件句柄，逼近上限才处理

左上 Uptime/CPU cores/RAM 显示 N/A 是仪表盘变量未接好的显示 bug，忽略即可。

3.4 SSL Certificate Monitor 解读

  • 按 Certificate expires in 升序 = 换证优先级队列。
  • 颜色：红≈30 天内、黄≈90~180 天、绿=充裕（以仪表盘实际阈值为准）。
  • HTTP Response 列：非 200 = 探测失败（服务挂/证书过期）。
  • TLS/Connect Time 突高 = 链路或响应劣化。

3.5 JVM / HikariCP 解读

  • JVM：堆内存是否逼近上限、GC 次数/耗时是否陡增。
  • HikariCP：active 逼近 max pool size、出现等待线程 = 数据库连接池瓶颈。

四、定期巡检流程（SOP）

4.1 每日巡检（3~5 分钟）

  1. 服务器资源监控总表：无红/橙行；Partition used% 最高一台 <80%。
  2. SSL Certificate Monitor：无新增红色、HTTP Response 全 200。
  3. k8s cluster_summary：节点全 Ready、Pod 无大量重启。
  4. EnableAI(prod)：JVM 堆无持续攀升、HikariCP 无等待。
  5. 异常项截图留存，按 SOP 跟进。

4.2 长假/节前专项巡检（以 dev-k8s 三 master 为例）

针对 dev-k8s-master-1/2/3（3 master 组成 etcd 集群，quorum=2/3，任意 1 台宕机仍正常；目标是别让 2 台同时出事）。提供只读脚本 dev-k8s-master-inspect.sh，三台各跑一遍：

bash 复制代码 
# 在哪执行：每台 master（root）
bash dev-k8s-master-inspect.sh
# 或批量（有 ssh 互信的跳板机）
for n in dev-k8s-master-1 dev-k8s-master-2 dev-k8s-master-3; do
  echo "## $n"; ssh root@$n 'bash -s' < dev-k8s-master-inspect.sh
done

4.3 巡检独立命令清单（逐条可跑）

bash 复制代码 
# 【OS】在哪执行：每台 master
uptime                      # 负载
df -h; df -i                # 磁盘 + inode
free -h                     # 内存
systemctl --failed          # 失败服务
journalctl -p err -S "2 hour ago" --no-pager | tail -20   # 近 2h 错误
timedatectl show -p NTPSynchronized   # 时钟同步（必须 yes）
cat /var/run/reboot-required 2>/dev/null  # 待重启？

# 【K8s】
kubectl get nodes
kubectl get pods -n kube-system -o wide | grep -E "etcd|apiserver|scheduler|controller"
kubectl get cs
kubectl get events -A --sort-by=.lastTimestamp | grep -iE "warning|error|fail" | tail -15

# 【etcd】（3 台都要 healthy）
ETCDCTL_API=3 etcdctl --cacert /etc/kubernetes/pki/etcd/ca.crt \
  --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key \
  --endpoints https://127.0.0.1:2379 endpoint health
ETCDCTL_API=3 etcdctl --cacert /etc/kubernetes/pki/etcd/ca.crt \
  --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key \
  --endpoints https://127.0.0.1:2379 member list -w table

4.4 巡检判定与处置表

检查项 期望 触发动作
磁盘分区 <80% >90% 清日志/旧镜像；>80% 记录节后跟进
inode <80% 高=海量小日志，清 journal/log
失败服务 无 排查修复
NTP 同步 yes 不同步立即修（timedatectl set-ntp true）
reboot-required 无 有则择机重启
控制面 Pod Running 非 Running 先 describe 定性
etcd health healthy unhealthy 看 etcd 日志 + 磁盘 IO
etcd member 3 个 started 缺成员紧急联系搭建人

五、常见风险与维护要点

5.1 磁盘写满：头号风险

磁盘是持久的，写进去不删就一直占着。即使无人操作，以下进程 7×24 自动写：

  • 容器日志（Pod stdout/stderr）------崩溃循环（CrashLoopBackOff）的 Pod 会疯狂打日志，几天灌满磁盘
  • etcd WAL + 快照（集群状态每 ~10s 变化）
  • systemd journal、kubelet 落盘

所以 Partition used% 会随时间单调上涨，必须节前清理；镜像层不会自己变大。

5.2 内存 vs 磁盘增长机制差异（重要，勿误判）

维度 磁盘 Partition used% 内存 Memory used%
是否可回收 否，除非删除 是，程序退出/缓存自动回收
无人使用时 仍缓慢上涨（日志/etcd） 不涨，在稳定值波动
真危险信号 持续升高至 90%+ Available 持续降低（内存泄漏）

Memory used% 含文件缓存 ，常显示 50~60% 属正常；判断内存够不够看 Available。

5.3 etcd 健康与时钟同步

  • etcd 对磁盘 IO 和时钟漂移极敏感 ：时钟不同步会导致 leader 失联。巡检必查 NTPSynchronized=yes。
  • 3 master 混部 etcd 时，master 节点的 iowait 高会直接拖垮集群写入。

5.4 K8s 组件证书周期

  • v1.22 组件证书默认 1 年。实测核查示例（dev-k8s）：
bash 复制代码 
kubeadm certs check-expiration
# apiserver / admin.conf / ... 均 2027-07-31 到期（剩余 303 天），CA 2123 到期
  • 结论：当前健康，无需操作；但 kubeadm 自动续期仅在控制面重启且剩余<30 天才触发，apiserver 长期不重启不会自动续。
  • 行动项：日历挂提醒 2027-06-30 前复查；到期前主动续签：
bash 复制代码 
cp -r /etc/kubernetes /etc/kubernetes.$(date +%F).bak   # 备份（回滚依据）
kubeadm certs renew all
kubeadm certs check-expiration && kubectl get nodes

5.5 SSL 业务证书续期 SOP

bash 复制代码 
# 1) 核查到期（无需登录服务器）
echo | openssl s_client -connect 域名:443 -servername 域名 2>/dev/null | openssl x509 -noout -dates

# 2) 登录目标服务器备份并更换（生产写操作三件套：备份+回滚+验证）
grep -rn "ssl_certificate" /etc/nginx/                     # 定位证书
sudo cp /etc/nginx/ssl/old.crt /etc/nginx/ssl/old.crt.$(date +%F).bak   # 备份
sudo nginx -t && sudo nginx -s reload                       # 校验并生效

# 3) 验证：Grafana SSL 面板该域名 Certificate expires in 变新周期、HTTP Response=200

注意：同根多子域名（如 *.redata.com 覆盖 api/blog/en/www/cdn）常为泛域名证书，续签一张覆盖全部。

六、回滚与应急

6.1 变更三件套（任何生产写操作前）

  1. 备份 ：改前备份原文件/配置（cp ... .$(date +%F).bak）
  2. 回滚：明确还原命令（还原备份 + reload/重启）
  3. 验证：用 Grafana 指标或命令确认恢复

6.2 应急判断表

现象 紧急度 处置
1 台 master 宕机 不紧急 quorum 仍在，恢复后 etcd 自动加入，节后复盘
2 台 master 同时挂 紧急 控制面不可用，立即联系搭建人，勿盲操作
etcd leader 频繁切换 中 查磁盘 IO + 时钟，先稳时钟
某业务 Pod 异常 视业务 按业务 runbook
Grafana 打不开 低 监控盲区≠集群故障，直接 kubectl 查节点

七、文档沉淀与持续优化

  1. SOP 归档：同类问题第二次出现，即写成 runbook（存本地/语雀/ima 对应分类）。
  2. 配置版本化：Prometheus rules、Grafana dashboard JSON、部署清单全部入 Git。
  3. 告警闭环：优先补齐 Alertmanager，让磁盘>85%、etcd unhealthy、节点 NotReady 主动推送，减少人工盯盘。
  4. 定期复盘：每次故障/误报后做无责复盘，沉淀到本文对应章节。

附：本文配套脚本 dev-k8s-master-inspect.sh（只读巡检）、值班判断表可单独存档复用。平台监控的本质是「一切可观测、一切可回滚、一切可自动化」------先把看板用熟，再把告警补齐。

相关推荐
分布式存储与RustFS1 小时前
指标、日志、链路进同一个桶：GreptimeDB 存算分离解读与 RustFS 接入配置
运维·云原生·开源·对象存储·分布式存储·s3·性能基准
橙色云-智橙协同研发1 小时前
电子高科技行业：机械与电子（MCAD & ECAD）如何协同？
大数据·运维·服务器·人工智能·安全
小此方1 小时前
Linux网络（二十三）：图文详解子网划分、分类划分的本质
linux·运维·网络
zoutao981 小时前
DeepSeek 智能效果实测与能力边界解析
大数据·运维·人工智能
wdfk_prog2 小时前
LWIP教程 16：从 MTU 到 `ip4_frag()` / `ip4_reass()`——IPv4 分片、重组、超时与内存压力
运维·服务器·网络·笔记·学习
wespaul2 小时前
VeapAI 自然语言操作实战｜第 04 篇：系统数据加工——把系统自身的元数据吃成知识
java·大数据·运维·数据库·人工智能
Huangjin007_2 小时前
【Linux 系统篇(二十九)】文件(六)：动静态库制作
linux·运维·服务器
%KT%2 小时前
ubuntu系统部署docker
运维·docker·容器
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02历年考研数学一、数学二、数学三真题试卷及答案PDF03「全语录+省流版」邵艾伦 × 孙宇晨：聊风口、聊个人IP、聊年轻人如何抓住 AI 时代的机会04GitHub 镜像站点05Windows 10/11 如何退出微软账户并改用本地账户登录（含找不到选项的解决方法）06Telegram APK 下载安装完整指南 — 2026年最新07蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接08轻量化AI渗透武器库｜ARTEX自主攻防系统、资产梳理、漏洞挖掘、链路分析全流程智能化落地09微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新10几个好用的ip纯净度检测网站