RUNBOOK — Dell R620 硬件温度/风扇监控（接入 K8s monitoring）¶

面向值班人：凌晨被叫起来、不熟悉本服务时，照着本文即可完成定位与恢复。服务对象：集群外主机 dell-R620（192.168.31.250）的 IPMI 温度/风扇指标 → 本机 K8s（v1.36.4） monitoring 命名空间 kube-prometheus-stack（release kube-prometheus-stack）。首次交付：2026-09-29（变更档案见 SOP.md）。

目录¶

服务概览　2. 接入与凭据　3. 日常速查表　4. 日常操作
配置管理　6. 备份与恢复　7. 监控与告警　8. 故障处置
安全与权限　10. 容量与性能　11. 附录

全文命令约定：除特别说明外，命令在本机 dell-R620 上以 root 执行；涉及 kubectl/helm 的命令先执行一次 export KUBECONFIG=/home/rain/.kube/config（工程以 root 运行，必须显式指定管理账号的 kubeconfig）。

1. 服务概览¶

用途：采集这台 Dell R620 机架服务器的进风口/出风口/CPU 温度与14 个风扇转速，送入集群 Prometheus，触发阈值告警并邮件通知，同时在 Grafana 看板展示趋势。解决的是「服务器硬件过热、风扇停转无人知晓」的监控盲区。

组件构成（两段链路）：

位置	组件	作用
主机侧	`prometheus-node-exporter.service`（apt 包 1.7.0-1ubuntu0.3）	监听 `9100`，暴露 `/metrics`；开 `textfile`/`hwmon`/`thermal_zone` 采集器
主机侧	`ipmi-collector.timer`（30s）+ `ipmi-collector.service`（oneshot）	周期性调用 `/opt/node-exporter/ipmi_metrics.sh` 生成 IPMI 指标
主机侧	`/opt/node-exporter/ipmi_metrics.sh`	`ipmitool sensor -c` 解析 → 原子写 `/opt/node-exporter/textfile/ipmi_metrics.prom`
集群侧	`Service`/`Endpoints`/`ServiceMonitor` 同名 `external-node-exporter`	把集群外 `192.168.31.250:9100` 静态接入 Prometheus
集群侧	`PrometheusRule/hp-r620-hardware-alerts`	8 条硬件告警规则
集群侧	`ConfigMap/hp-r620-temp-dashboard`	Grafana 看板（uid `hp-r620-temp`，8 面板，sidecar 自动导入）
集群侧	Alertmanager `alertmanager.config`	邮件接收器 `hp-r620-email`，按 `category="hardware"` 路由

依赖谁：主机 ipmitool 与 /dev/ipmi0（IPMI 内核模块）；集群 monitoring 的 kube-prometheus-stack；外部 SMTP（smtp.163.com:25）。

异常时的业务影响：只影响监控，不影响被监控主机与集群业务。但异常期间该服务器硬件故障（CPU 过热、风扇停转）将无告警，属监控盲区。

重要性等级：中（监控组件，非业务关键；但失效即失去该主机的硬件预警能力）。

2. 接入与凭据¶

地址与端口

对象	地址	说明
主机 node-exporter	`http://192.168.31.250:9100/metrics`	物理网卡 `eno2` IP，Prometheus 抓取地址
主机管理 IP	`192.168.31.249`（`br0`）	本机管理地址
Prometheus	`svc/kube-prometheus-stack-prometheus:9090`（`monitoring`）	集群内，经 port-forward 访问
Alertmanager	`svc/kube-prometheus-stack-alertmanager:9093`（`monitoring`）	同上
Grafana	`svc/kube-prometheus-stack-grafana:80`（`monitoring`）	同上，看板 uid `hp-r620-temp`

账号与凭据存放位置（文档只写「从哪取」，命令内取值，绝不写值）

凭据	用途	存放位置	取用命令
Grafana 管理账号	登录 / 调用看板 API	Secret `grafana-admin`（键 `admin-user` / `admin-password`）	见下方片段
SMTP 授权码	Alertmanager 发信	`0600` 文件 `/home/rain/.secrets/dell-r620-monitor.env` 变量 `DELL_R620_SMTP_AUTH_PASSWORD`	见下方片段
K8s 访问	kubectl/helm	`/home/rain/.kube/config`	`export KUBECONFIG=/home/rain/.kube/config`

export KUBECONFIG=/home/rain/.kube/config
# Grafana 账号（值只在命令内使用，不打印）
GU=$(kubectl -n monitoring get secret grafana-admin -o jsonpath='{.data.admin-user}' | base64 -d)
GP=$(kubectl -n monitoring get secret grafana-admin -o jsonpath='{.data.admin-password}' | base64 -d)

# SMTP 授权码（非交互 shell 需显式 source；禁止 echo 该变量）
set -a; . /home/rain/.secrets/dell-r620-monitor.env; set +a

客户端接入示例（Prometheus 抓取，集群内配置）：见 manifests/01-external-node-exporter.yaml（无 selector 的 Service + 手工 Endpoints + ServiceMonitor）。

3. 日常速查表¶

export KUBECONFIG=/home/rain/.kube/config

# 1. 主机侧单元状态
systemctl is-active ipmi-collector.timer prometheus-node-exporter.service   # 期望 active active
# 2. 指标是否可抓
curl -s http://192.168.31.250:9100/metrics | grep -c '^ipmi_temperature_celsius'   # 期望 4
# 3. 采集产物新鲜度（应 < 30s）
ls -l --time-style=+%H:%M:%S /opt/node-exporter/textfile/ipmi_metrics.prom
# 4. 集群侧资源是否齐备
kubectl -n monitoring get servicemonitor,service,endpoints external-node-exporter
kubectl -n monitoring get prometheusrule hp-r620-hardware-alerts configmap hp-r620-temp-dashboard
# 5. 抓取目标是否 up
kubectl -n monitoring port-forward svc/kube-prometheus-stack-prometheus 9090:9090 & sleep 3
curl -s 'http://127.0.0.1:9090/api/v1/targets' | grep -o '"job":"external-node-exporter"[^}]*"health":"[a-z]*"'
# 6. 告警规则是否加载（期望 8）
curl -s 'http://127.0.0.1:9090/api/v1/rules' | grep -c 'HPR620'
# 7. 告警邮件通道计数
kubectl -n monitoring port-forward svc/kube-prometheus-stack-alertmanager 9093:9093 & sleep 3
curl -s http://127.0.0.1:9093/metrics | grep 'alertmanager_notification_requests_.*integration="email"'
# 8. 看板是否存在
kubectl -n monitoring port-forward svc/kube-prometheus-stack-grafana 3000:80 & sleep 3
curl -s -u "$GU:$GP" http://127.0.0.1:3000/api/dashboards/uid/hp-r620-temp | grep -o '"uid":"hp-r620-temp"'
# 9. 漂移检测（只读；0 无漂移 / 1 有漂移 / 2 探测失败）
sudo -n .venv/bin/python main.py drift
# 10. 日志尾
tail -n 30 logs/dell-r620-monitor.log

4. 日常操作¶

4.1 状态检查¶

systemctl status ipmi-collector.timer --no-pager
systemctl list-timers ipmi-collector.timer            # 看 NEXT / LAST 是否在 30s 周期内
systemctl status prometheus-node-exporter.service --no-pager
systemctl is-enabled ipmi-collector.timer              # 期望 enabled（保证重启后自启）

预期：timer 的 NEXT 在 30s 内、LAST 有近期记录；node-exporter active (running)。不符：见第 8 章对应场景。

4.2 启动 / 停止 / 重启¶

# 重启 node-exporter（参数文件变更后必须重启才生效）
systemctl restart prometheus-node-exporter.service
# 重启采集定时器
systemctl restart ipmi-collector.timer
# 手工触发一次采集（排查用，立即产出 textfile）
systemctl start ipmi-collector.service
# 临时停止采集（排障用；高危：会中断指标更新，会触发 HPR620IPMICollectorDown）
systemctl stop ipmi-collector.timer
systemctl start ipmi-collector.timer      # 排障后务必恢复

4.3 查看日志¶

journalctl -u ipmi-collector.service -n 50 --no-pager          # 采集脚本输出（失败会打印并保留上一份）
journalctl -u prometheus-node-exporter.service -n 50 --no-pager
tail -n 50 logs/dell-r620-monitor.log                          # 工程侧运行日志

4.4 进入排障（主机 / 集群）¶

# 主机侧：直接本机 shell（root）
bash -x /opt/node-exporter/ipmi_metrics.sh; echo "rc=$?"        # 逐行跟踪采集脚本
ipmitool sensor -c | head                                        # 原始 CSV（需 root，/dev/ipmi0 权限 600）
# 集群侧：查看相关 Pod
kubectl -n monitoring get pod | grep -E 'prometheus|alertmanager|grafana'
kubectl -n monitoring logs deploy/kube-prometheus-stack-operator --tail=50

4.5 扩缩容¶

本服务为单主机单实例，无横向扩缩容概念。若需新增同类主机，按 SOP.md 第 5 章复制流程，在 config/monitor.yaml 中改 host.name/address、资源名后缀与告警规则名，重新 precheck → deploy。变更被监控主机 IP 时同步改 manifests/01 的 Endpoints.subsets.addresses.ip。

5. 配置管理¶

配置项	位置	修改生效方式
node-exporter 参数文件	主机 `/etc/default/prometheus-node-exporter`	改后 `systemctl restart prometheus-node-exporter.service`
采集脚本	主机 `/opt/node-exporter/ipmi_metrics.sh`	直接生效（下次 timer 触发）；工程侧改 `artifacts/` 同名制品
采集单元 / 定时器	主机 `/etc/systemd/system/ipmi-collector.{service,timer}`	改后 `systemctl daemon-reload && systemctl restart ipmi-collector.timer`
抓取接入	集群 `manifests/01-external-node-exporter.yaml`	`kubectl apply -f`
告警规则	集群 `manifests/02-hp-r620-hardware-alerts.yaml`	`kubectl apply -f`（Prometheus 自动重载规则）
Grafana 看板	集群 `manifests/03-hp-r620-temp-dashboard.yaml`	`kubectl apply -f`（sidecar 自动导入，约 10s）
邮件路由	集群 `manifests/04-alertmanager-email-values.yaml`（模板）	渲染后经 `helm upgrade` 注入（见 SOP 步骤 5）
工程总配置	工程 `config/monitor.yaml`	工程实现的唯一真源

易错点：

不要直接改集群里的 Alertmanager Secret——它由 prometheus-operator 从 alertmanager.config 重新生成，手改会被覆盖。正确做法是改模板并经 helm upgrade 注入。
改告警规则不要只改集群对象：集群对象会被下次 apply 的清单覆盖；改清单 manifests/02 为准。
改主机侧文件不要只改落盘文件：工程以 artifacts/ 制品为真源，重跑 deploy 会按制品覆盖；制品内容变更应视为新版本，改制品后重跑工程。
改 helm_extra_args（如去掉 --no-hooks）前，先确认集群侧 ghcr.io 可达，否则 upgrade 会卡到超时。

6. 备份与恢复¶

策略与位置：变更前的备份统一放工程内 backup/，台账见 ../backup/README.md。本次两类备份：

backup/monitoring/helm-live-values.yaml.bak.<时间戳>：helm 现场 values（helm upgrade 的 -f 基线）。
backup/monitoring/alertmanager-变更前配置.yaml.bak.<时间戳>（0600）：Alertmanager 变更前配置。

手工备份（变更前必做）

export KUBECONFIG=/home/rain/.kube/config
STAMP=$(date +%Y%m%d-%H%M%S)
install -d -m 755 backup/monitoring
helm --kubeconfig "$KUBECONFIG" get values kube-prometheus-stack -n monitoring -o yaml \
  > "backup/monitoring/helm-live-values.yaml.bak.$STAMP"
kubectl -n monitoring get secret alertmanager-kube-prometheus-stack-alertmanager \
  -o jsonpath='{.data.alertmanager\.yaml}' | base64 -d \
  > "backup/monitoring/alertmanager-变更前配置.yaml.bak.$STAMP"
chmod 600 "backup/monitoring/alertmanager-变更前配置.yaml.bak.$STAMP"

恢复 Alertmanager 配置

AMBAK="$(ls -1t backup/monitoring/alertmanager-变更前配置.yaml.bak.* | head -1)"
kubectl --kubeconfig "$KUBECONFIG" create secret generic alertmanager-kube-prometheus-stack-alertmanager \
  -n monitoring --from-file=alertmanager.yaml="$AMBAK" --dry-run=client -o yaml \
  | kubectl --kubeconfig "$KUBECONFIG" apply -f -

恢复后验证：kubectl -n monitoring get secret alertmanager-kube-prometheus-stack-alertmanager -o jsonpath='{.data.alertmanager\.yaml}' | base64 -d 内容与备份一致。 演练记录：2026-09-29 变更中 rollback 路径已实现并经代码走查；生产回滚尚未实际演练，首次真实回滚前建议先在非业务窗口执行 main.py rollback --dry-run 核对动作清单。

7. 监控与告警¶

关键指标（Prometheus 中查询）

指标	含义
`ipmi_temperature_celsius{sensor,type,id}`	温度读数（`id`：inlet / exhaust / cpu1 / cpu2）
`ipmi_temperature_threshold_celsius{sensor,type,id,threshold}`	各传感器阈值（供参考）
`ipmi_fan_rpm{sensor,fan_id}`	风扇转速（14 个）
`node_hwmon_temp_celsius`	CPU 核心温度（node-exporter 自带）
`up{job="external-node-exporter"}`	抓取是否成功（1 up / 0 down）

查看入口：Prometheus svc/kube-prometheus-stack-prometheus:9090、Grafana svc/kube-prometheus-stack-grafana:80（看板 hp-r620-temp）、Alertmanager svc/kube-prometheus-stack-alertmanager:9093——均经 kubectl port-forward 访问（见第 2、3 章）。

日志位置：主机 journalctl -u ipmi-collector.service；工程 logs/dell-r620-monitor.log。

需要重点盯的告警（共 8 条，全部带 category=hardware，走邮件）

告警名	触发条件	级别
`HPR620CPUTemperatureWarning`	CPU 温度 > 85°C 持续 2m	warning
`HPR620CPUTemperatureCritical`	CPU 温度 > 90°C 持续 1m	critical
`HPR620InletTemperatureWarning`	进风口 > 42°C 持续 5m	warning
`HPR620ExhaustTemperatureWarning`	出风口 > 70°C 持续 5m	warning
`HPR620FanSpeedLow`	任一风扇 < 1500 RPM 持续 2m	critical
`HPR620FanStopped`	任一风扇 < 720 RPM 持续 1m	critical
`HPR620IPMICollectorDown`	指标缺失或 > 180s 未更新持续 2m	warning
`HPR620NodeExporterDown`	`up{job="external-node-exporter"} == 0` 持续 1m	critical

告警规则清单来源：manifests/02-hp-r620-hardware-alerts.yaml（阈值取自 Dell R620 IPMI 官方阈值）。

8. 故障处置¶

每场景按「症状 → 诊断 → 处置 → 验证」四段。诊断命令一律先 export KUBECONFIG=/home/rain/.kube/config。

场景 A：抓取目标 down（`HPR620NodeExporterDown` 邮件到达）¶

症状：收到 [DELL-R620硬件 FIRING] HPR620NodeExporterDown 邮件；Prometheus 中 up{job="external-node-exporter"} == 0；Grafana 看板所有曲线断裂。

诊断

# A1 主机侧端口是否在听（在 192.168.31.250 本机）
ss -ltnH | awk '{print $4}' | grep -c ':9100$'                       # 期望 ≥1；为 0 即 node-exporter 未监听
systemctl is-active prometheus-node-exporter.service                # 期望 active
# A2 集群侧从 Pod 看能否连通该地址（网络是否可达）
kubectl -n monitoring get endpoints external-node-exporter -o jsonpath='{.subsets[0].addresses[0].ip}{"\n"}'
#   期望 192.168.31.250；若为空，说明 Endpoints 丢失地址
# A3 抓取目标详情（health 与错误信息）
kubectl -n monitoring port-forward svc/kube-prometheus-stack-prometheus 9090:9090 & sleep 3
curl -s 'http://127.0.0.1:9090/api/v1/targets' | grep -o '"health":"[a-z]*","lastError":"[^"]*"'

判读：A1 为 0 → 主机侧服务问题（走 A4）；A1 正常但 A3 health=down → 网络/Endpoints 问题。

# A4 主机侧服务为何未起
systemctl status prometheus-node-exporter.service --no-pager
journalctl -u prometheus-node-exporter.service -n 50 --no-pager     # 看端口占用 / 参数错误
ss -ltnp | grep ':9100 '                                            # 谁在占用 9100

处置

若 A1 为 0 且 A4 显示服务 failed：先修参数再起服务 bash systemctl restart prometheus-node-exporter.service 若因 9100 被其他进程占用：定位占用进程并释放端口后重试。
若 Endpoints 地址为空/错：修正并重放清单 bash kubectl -n monitoring apply -f manifests/01-external-node-exporter.yaml
若网络不通：确认 192.168.31.250（eno2）网卡 up、与集群同网段可达。
兜底：若主机侧已无法恢复，按 SOP.md 第 7 章回滚（回滚是止血，会移除接入，属高危）。

验证

curl -s http://192.168.31.250:9100/metrics | grep -c '^ipmi_temperature_celsius'   # 期望 4
kubectl -n monitoring port-forward svc/kube-prometheus-stack-prometheus 9090:9090 & sleep 3
curl -s 'http://127.0.0.1:9090/api/v1/targets' | grep -o '"job":"external-node-exporter"[^}]*"health":"up"'   # 出现 health":"up"

约 1~2 分钟后 HPR620NodeExporterDown 应转为 RESOLVED（send_resolved: true 会再发一封恢复邮件）。

场景 B：IPMI 指标缺失或陈旧（`HPR620IPMICollectorDown` 邮件到达）¶

症状：收到 HPR620IPMICollectorDown 邮件；Prometheus 查不到 ipmi_temperature_celsius，或该指标时间戳超过 180s 未更新；看板硬件温度面板空白。

诊断

# B1 timer 与产物新鲜度
systemctl is-active ipmi-collector.timer
systemctl list-timers ipmi-collector.timer --no-pager            # NEXT/LAST 是否在 30s 周期
ls -l --time-style=+%H:%M:%S /opt/node-exporter/textfile/ipmi_metrics.prom
# B2 产物内容是否有效（必须含温度指标）
grep -c ipmi_temperature_celsius /opt/node-exporter/textfile/ipmi_metrics.prom   # 期望 ≥1
# B3 手工执行采集脚本看真实报错
bash -x /opt/node-exporter/ipmi_metrics.sh; echo "rc=$?"          # rc=0 且无 stderr 报错为正常
# B4 IPMI 设备与工具
ls -l /dev/ipmi0; ipmitool sensor -c | head                        # 均需 root

判读：B1 产物时间很旧且 timer active → 采集任务在失败（看 B3）；B3 报 ipmitool 执行失败/无输出 → B4 设备或工具问题；B4 缺 /dev/ipmi0 → IPMI 内核模块未加载。

处置

# 若 timer 停了：恢复
systemctl start ipmi-collector.timer
# 若 /dev/ipmi0 缺失：加载内核模块
modprobe ipmi_devintf; modprobe ipmi_si; ls -l /dev/ipmi0
# 若 ipmitool 缺失：apt-get install -y ipmitool
# 若产物为空/脚本报错：手工触发一次并复查
systemctl start ipmi-collector.service

说明：脚本设计为「失败即保留上一份 textfile 并不覆盖为空」，因此产物存在但陈旧即代表采集持续失败，必须按 B3/B4 定位根因，不能只重启 timer 了事。

验证

systemctl list-timers ipmi-collector.timer --no-pager | grep ipmi-collector
sleep 35; ls -l --time-style=+%H:%M:%S /opt/node-exporter/textfile/ipmi_metrics.prom   # 时间应已更新
curl -s http://192.168.31.250:9100/metrics | grep -c '^ipmi_temperature_celsius'        # 期望 4
curl -s http://192.168.31.250:9100/metrics | grep -c '^ipmi_fan_rpm'                    # 期望 14

场景 C：告警邮件收不到¶

症状：Prometheus 中告警已 firing，但邮箱（saier_cy@163.com）无对应邮件；或发信时 alertmanager_notification_requests_failed_total{integration="email"} > 0。

诊断

kubectl -n monitoring port-forward svc/kube-prometheus-stack-alertmanager 9093:9093 & sleep 3
# C1 运行配置是否含接收器与硬件路由
curl -s http://127.0.0.1:9093/api/v2/status | python3 -c 'import json,sys;t=json.load(sys.stdin)["config"]["original"];print("hp-r620-email" in t, "hardware" in t)'
#   期望 True True
# C2 投递计数（requests 是否增长、failed 是否为 0）
curl -s http://127.0.0.1:9093/metrics | grep 'alertmanager_notification_.*integration="email"'
# C3 当前是否有告警
curl -s http://127.0.0.1:9093/api/v2/alerts | python3 -c 'import json,sys;[print(a["labels"].get("alertname"),a["status"]["state"]) for a in json.load(sys.stdin)]'
# C4 规则是否带 category=hardware（决定是否路由到邮件）
curl -s 'http://127.0.0.1:9090/api/v1/rules' 2>/dev/null | grep -o 'HPR620[A-Za-z]*' | sort -u

判读：C1 为 False → 配置未生效（走 C5）；C1 为 True 但 C2 failed_total 增长 → SMTP 侧问题（走 C6）。

# C5 配置未生效：确认 helm release 与 Secret
helm --kubeconfig "$KUBECONFIG" -n monitoring history kube-prometheus-stack | tail -3    # 最新应为 deployed
kubectl -n monitoring get secret alertmanager-kube-prometheus-stack-alertmanager \
  -o jsonpath='{.data.alertmanager\.yaml}' | base64 -d | grep -E 'hp-r620-email|smtp_smarthost'
# C6 SMTP 连通性（从本机测试到 smtp.163.com:25）
timeout 6 bash -c 'cat < /dev/null > /dev/tcp/smtp.163.com/25' && echo 'SMTP:25 可达' || echo 'SMTP:25 不可达'
#   并核对授权码变量存在（只看变量名，不打印值）
grep -c '^DELL_R620_SMTP_AUTH_PASSWORD=' /home/rain/.secrets/dell-r620-monitor.env   # 期望 1

处置

C5 显示 release failed → 按 SOP.md 步骤 5 重跑渲染 + helm upgrade（带 --no-hooks）；或按第 6 章用备份恢复 Secret。注意 reload 有 ~1~2 分钟延迟，勿立即判失败。
C6 不可达 → 检查出网策略/防火墙对 smtp.163.com:25 的放行。
授权码失效（163 邮箱改授权码后）→ 更新 /home/rain/.secrets/dell-r620-monitor.env 中 DELL_R620_SMTP_AUTH_PASSWORD，再重跑渲染 + helm upgrade（工程幂等）。
规则缺 category=hardware → 改 manifests/02 后 kubectl apply -f。

验证：注入一封测试告警并核对计数

curl -s -XPOST http://127.0.0.1:9093/api/v2/alerts -H 'Content-Type: application/json' \
  -d '[{"labels":{"alertname":"HPR620TestAlert","category":"hardware","severity":"warning"},"annotations":{"summary":"邮件通道测试"}}]'
sleep 20
curl -s http://127.0.0.1:9093/metrics | grep -E 'alertmanager_notification_requests_(total|failed_total)\{integration="email"\}'
# 期望：requests_total 数值 ≥1 且较此前递增；failed_total = 0；同时邮箱收到测试邮件

场景 D：Grafana 看板无数据 / 看不到看板¶

症状：登录 Grafana 后找不到 DELL R620 看板，或看板存在但面板显示 No data。

诊断

kubectl -n monitoring port-forward svc/kube-prometheus-stack-grafana 3000:80 & sleep 3
GU=$(kubectl -n monitoring get secret grafana-admin -o jsonpath='{.data.admin-user}' | base64 -d)
GP=$(kubectl -n monitoring get secret grafana-admin -o jsonpath='{.data.admin-password}' | base64 -d)
# D1 Grafana 健康 + sidecar 是否在跑
curl -s http://127.0.0.1:3000/api/health
kubectl -n monitoring get deploy kube-prometheus-stack-grafana -o jsonpath='{.spec.template.spec.containers[*].name}'
#   期望包含 grafana-sc-dashboard
# D2 看板对象是否存在
curl -s -u "$GU:$GP" http://127.0.0.1:3000/api/dashboards/uid/hp-r620-temp | grep -o '"uid":"hp-r620-temp"'
kubectl -n monitoring get configmap hp-r620-temp-dashboard --show-labels
#   期望标签含 grafana_dashboard=1
# D3 数据源是否为 Prometheus（看板依赖）
curl -s -u "$GU:$GP" http://127.0.0.1:3000/api/datasources | grep -o '"type":"prometheus"'

判读：D1 无 grafana-sc-dashboard → sidecar 缺失，ConfigMap 不会被导入；D2 无 uid → 看板未导入； D3 无 prometheus → 数据源问题（则看板必然 No data）；以上均正常但仍 No data → 走 D4（回到场景 A/B 查数据本身）。

处置

看板未导入：重放清单 kubectl -n monitoring apply -f manifests/03-hp-r620-temp-dashboard.yaml，等约 10s（sidecar 轮询）后复查 D2；确认 ConfigMap 有 grafana_dashboard=1 标签。
sidecar 缺失：属 kube-prometheus-stack 部署问题，检查 Grafana Deployment 是否被裁剪；必要时按 SOP.md 步骤 5 以现场 values 重新 helm upgrade（幂等）。
数据源缺失：在 Grafana 中确认默认数据源指向 Prometheus（sidecar grafana-sc-datasources 管理）。
数据源与看板都正常但无数据：说明是采集/抓取问题，转场景 A / B。

验证

curl -s -u "$GU:$GP" http://127.0.0.1:3000/api/dashboards/uid/hp-r620-temp | grep -o '"uid":"hp-r620-temp"'
# 浏览器打开看板，CPU/进风口/出风口 与 风扇转速 面板应出现曲线

9. 安全与权限¶

主机侧：采集与 node-exporter 以 root 运行（访问 /dev/ipmi0 与写 systemd 单元所需）。制品权限固定：ipmi_metrics.sh root:root 0755；单元与参数文件 root:root 0644。
集群侧：kubectl/helm 使用 /home/rain/.kube/config；Alertmanager Secret alertmanager-kube-prometheus-stack-alertmanager 由 prometheus-operator 管理，勿手改。
凭据：SMTP 授权码仅存于 0600 文件 /home/rain/.secrets/dell-r620-monitor.env，变量 DELL_R620_SMTP_AUTH_PASSWORD；工程运行时读取并渲染到 0600 临时文件交 helm， 值不落日志、不进版本管理。
轮换步骤（授权码/邮箱变更）： 1) 更新凭据文件：chmod 600 /home/rain/.secrets/dell-r620-monitor.env 后修改该变量值； 2) 重跑工程 deploy（幂等）或按 SOP.md 步骤 5 渲染 + helm upgrade； 3) 按场景 C 的「验证」注入测试告警确认通道可用。
访问控制：Grafana 管理账号在 Secret grafana-admin；Prometheus/Alertmanager/Grafana 均为 ClusterIP，仅集群内可达，外部访问需显式 port-forward（本环境 monitoring 未见 Ingress）。

10. 容量与性能¶

指标量级：本主机约 4 条温度 + 14 条风扇 + 每条温度 6 个阈值（na 的不产出）+ node-exporter 自带指标，单机规模，可忽略。
抓取频率：ServiceMonitor interval: 30s，与采集 timer 30s 对齐（刻意避免两者错拍导致读数抖动）。
采集开销：ipmi-collector.service 为 oneshot、Nice=10，每次执行秒级。
当前水位基线（2026-09-29 实测）：inlet 24°C、exhaust 39°C、CPU 64°C/58°C，14 风扇转速正常。
扩容触发条件：接入同类主机数量增长时，仅需按 SOP.md 流程复制；单主机指标量小，无容量压力。若未来改为高频率（< 10s）采集，需重新评估 IPMI 总线与 ipmitool 的调用开销。
已知瓶颈：ipmitool 依赖 /dev/ipmi0 串行访问，若并发大量采集命令会互相排队；当前单机 30s 周期无此问题。

11. 附录¶

11.1 术语表¶

术语	说明
IPMI	服务器带外管理接口，提供温度/风扇等传感器读数
textfile collector	node-exporter 的一种采集器，读取指定目录下的 `.prom` 文本文件作为指标来源
ServiceMonitor	Prometheus Operator 的 CRD，声明如何抓取某个 Service
oneshot / timer	systemd 一次性服务与定时器，timer 周期触发 oneshot 服务
硬件阈值	Dell R620 IPMI 官方阈值（CPU 非关键 85/关键 90，进风口 42，出风口 70，风扇低位 1500/停转 720）

11.2 相关文档与交付物¶

路径	说明
`docs/SOP.md`	本次变更档案（背景/步骤/验证/回滚）
`backup/README.md`	备份台账
`manifests/01~04*.yaml`	集群侧清单与邮件路由模板
`artifacts/`	主机侧不可变制品
`config/monitor.yaml`	工程唯一真源配置
`reports/drift-*.md`	漂移检测报告（含「已达标 13 项」清单）

11.3 修订记录¶

日期	修改人	变更内容
2026-09-29	—	首版：随 Dell R620 硬件监控接入交付

来源：/home/rain/Documents/k8s_ins/dell-r620-monitor-20260929/docs/RUNBOOK.md ｜最后更新：2026-09-29 22:21（由 build/sync.py 同步，请勿在站点侧修改）