本文基于一套已落地的企业级监控平台（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 技术栈说明

二、平台部署流程

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 部署（以单套为例）

# 在哪执行：Prometheus 所在主机# 1) 下载并解压（示例版本）wgethttps://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gztarxf 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 EOFsystemctl daemon-reload&&systemctlenable--nowprometheus

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

2.3 Exporter 部署

# 在哪执行：每台宿主机（node_exporter）tarxf 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 EOFsystemctlenable--nownode_exporter# 监听 9100

# 在哪执行：K8s 控制面（集群内组件，kubectl apply）# kube-state-metrics、dcgm-exporter 用官方 manifests 即可，示例：kubectl apply-fhttps://github.com/kubernetes/kube-state-metrics/blob/master/examples/standard/clusterrole.yaml kubectl apply-fhttps://raw.githubusercontent.com/NVIDIA/dcgm-exporter/master/deployments/dcgm-exporter.yaml# blackbox_exporter 同样 apply 到集群，探测目标写在 Grafana 的 Blackbox 仪表盘变量里

# Java 应用侧（代码层，交给开发）：引入 micrometer-registry-prometheus# 暴露端点后，在 Prometheus 的 scrape_configs 增加 job 指向 Pod 的 metrics 端口

2.4 Grafana 部署与数据源接入

# 在哪执行：Grafana 主机dockerrun-d-p3000:3000--namegrafana 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）：

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

2.6 告警链路（建议实装）

# 在哪执行：告警机# 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 Node Exporter 仪表盘详解（最常用）

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

3.2.1 总表列含义

3.2.2 单机详情面板（Resource Details）

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

3.3 SSL Certificate Monitor 解读

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

3.4 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. 异常项截图留存，按 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，三台各跑一遍：

# 在哪执行：每台 master（root）bashdev-k8s-master-inspect.sh# 或批量（有 ssh 互信的跳板机）fornindev-k8s-master-1 dev-k8s-master-2 dev-k8s-master-3;doecho"##$n";sshroot@$n'bash -s'<dev-k8s-master-inspect.shdone

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

# 【OS】在哪执行：每台 masteruptime# 负载df-h;df-i# 磁盘 + inodefree-h# 内存systemctl--failed# 失败服务journalctl-perr-S"2 hour ago"--no-pager|tail-20# 近 2h 错误timedatectl show-pNTPSynchronized# 时钟同步（必须 yes）cat/var/run/reboot-required2>/dev/null# 待重启？# 【K8s】kubectl get nodes kubectl get pods-nkube-system-owide|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=3etcdctl--cacert/etc/kubernetes/pki/etcd/ca.crt\--cert/etc/kubernetes/pki/etcd/server.crt--key/etc/kubernetes/pki/etcd/server.key\--endpointshttps://127.0.0.1:2379 endpoint healthETCDCTL_API=3etcdctl--cacert/etc/kubernetes/pki/etcd/ca.crt\--cert/etc/kubernetes/pki/etcd/server.crt--key/etc/kubernetes/pki/etcd/server.key\--endpointshttps://127.0.0.1:2379 member list-wtable

4.4 巡检判定与处置表

五、常见风险与维护要点

5.1 磁盘写满：头号风险

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

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

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

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

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）：

kubeadm certs check-expiration# apiserver / admin.conf / ... 均 2027-07-31 到期（剩余 303 天），CA 2123 到期

• 结论：当前健康，无需操作；但 kubeadm 自动续期仅在控制面重启且剩余<30 天才触发，apiserver 长期不重启不会自动续
• 行动项：日历挂提醒 2027-06-30 前复查；到期前主动续签：

cp-r/etc/kubernetes /etc/kubernetes.$(date+%F).bak# 备份（回滚依据）kubeadm certs renew all kubeadm certs check-expiration&&kubectl get nodes

5.5 SSL 业务证书续期 SOP

# 1) 核查到期（无需登录服务器）echo|openssl s_client-connect域名:443-servername域名2>/dev/null|openssl x509-noout-dates# 2) 登录目标服务器备份并更换（生产写操作三件套：备份+回滚+验证）grep-rn"ssl_certificate"/etc/nginx/# 定位证书sudocp/etc/nginx/ssl/old.crt /etc/nginx/ssl/old.crt.$(date+%F).bak# 备份sudonginx-t&&sudonginx-sreload# 校验并生效# 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. SOP 归档：同类问题第二次出现，即写成 runbook（存本地/语雀/ima 对应分类）
2. 配置版本化：Prometheus rules、Grafana dashboard JSON、部署清单全部入 Git
3. 告警闭环：优先补齐 Alertmanager，让磁盘>85%、etcd unhealthy、节点 NotReady 主动推送，减少人工盯盘
4. 定期复盘：每次故障/误报后做无责复盘，沉淀到本文对应章节

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