SOP — HANDOFF 组三「小尾巴」收口（2026-10-03）¶
覆盖
docs/HANDOFF.md§3.1「组三 · 既有小尾巴」的 #10 / #12 / #13 / #14 / #15 五项。 变更对象跨三个工程：prometheus_deploy（环境外 release）、monitoring-p2-20261001（manifest）、env-inventory（清单）。备份台账见backup/README.md。
1. 背景¶
2026-10-02 的交接快照把日志可观测线的尾部事项收敛为「组三」，其中五项长期挂账、无定论：
| # | 原描述 | 挂账时状态 |
|---|---|---|
| 10 | 黑盒 ldapadmin-web 偶发 502/超时 |
已确认非期望码问题，根因未定 |
| 12 | grafana pod 重启次数偏高 | 未查原因 |
| 13 | .23–.28 SELinux 为 Disabled 是否设计如此 |
待确认后记入 inventory.yaml |
| 14 | lsf-work-01~03 探测到 lim 而非 sbatchd |
待登录核对实际进程 |
| 15 | 内容探针发现历史 oom 类日志 157 条 / 14 天 |
待查时间、主机与进程 |
本轮逐项取证，确认 #15 与 #12 实为同一根因（grafana 容器被 cgroup OOM 击杀）， 其余三项各有明确结论。#13/#14 属清单勘误，#10 属临界抖动缓解。
2. 目标¶
- 消除 grafana 因内存超限被 OOMKilled 的重复重启，并闭环 #15 的 oom 日志溯源；
- 为 ldapadmin 黑盒探针消除「时延逼近超时阈值」的误报隐患；
- 把 #13/#14 的实测事实写回
env-inventory/inventory.yaml，删除与实况不符的推断； - 五项全部从 HANDOFF 的未完成清单移出，并在本文留下结论与证据。
3. 前置条件¶
- 本机可
kubectl（kubeconfig/home/rain/.kube/config）、可helm，monitoring命名空间可写； - 可 root 免密 ssh 至
192.168.31.23–.28（凭据获取见全局规则rainchen-env）； - 查 ES 需
~/.secrets/efk.env（只 source，不 cat）； - 前置检查：
helm list -n monitoring（当时为kube-prometheus-stack / REVISION 11）、kubectl get pods -n monitoring。
已完成的备份（时间戳 20261003-002411）：见第 7 章与 backup/README.md。
4. 影响范围¶
| 变更 | 组件 | 是否停服 | 窗口期与影响 |
|---|---|---|---|
| #12 | monitoring/kube-prometheus-stack（helm release） |
否 | grafana Deployment 滚动重启一次，约 1 分钟不可用；Prometheus / Alertmanager / 采集不受影响 |
| #10 | monitoring/blackbox-exporter-config ConfigMap + Deployment |
否 | 探针 pod 重建一次，约 20 秒探测空档；不影响被探测业务 |
| #13/#14 | env-inventory/inventory.yaml |
否 | 纯文档，无运行时影响 |
无 Slurm / LSF 作业受影响（本轮不触碰计算节点，仅 ssh 只读核对）。
5. 分步操作¶
步骤 1（#12）：上调 grafana 容器内存¶
grafana 容器 limit 为 512Mi，实测稳态用量 584Mi，被内核 cgroup OOM 击杀（见步骤 4 证据）。 本轮把 limit 提到 1Gi、requests 提到 384Mi。
注意事项与坑：prometheus_deploy/values.yaml 不是现场基线——直接 -f values.yaml 或只传
overlay 都会让其余配置回落到 chart 默认值并触发全栈重建（历史 P1 事故）。必须用
--reuse-values -f <overlay>。
cd /home/rain/Documents/k8s_ins/prometheus_deploy
helm upgrade kube-prometheus-stack charts/kube-prometheus-stack-91.4.1.tgz -n monitoring \
--reuse-values -f /home/rain/Documents/k8s_ins/group3-tails-20261003/values-grafana-oom-overlay.yaml \
--timeout 30m --wait
预期：STATUS: deployed、REVISION 由 11 增至 12。
失败判断：超时或 STATUS: failed → 第 7 章回滚（helm rollback kube-prometheus-stack 11）。
步骤 2（#10）：放宽 ldapadmin 探针超时¶
blackbox.yml 的 https_ldapadmin 模块 timeout 由 10s 放宽到 15s（原值下实测峰值时延 9.5s，逼近阈值）。
cd /home/rain/Documents/k8s_ins
kubectl apply -f monitoring-p2-20261001/manifests/20-blackbox-exporter.yaml
kubectl rollout restart deployment/blackbox-exporter -n monitoring
kubectl rollout status deployment/blackbox-exporter -n monitoring --timeout=120s
预期：configmap/blackbox-exporter-config configured、deployment "blackbox-exporter" successfully rolled out。
失败判断：rollout 未在 120s 内完成 → 查 kubectl describe pod -n monitoring -l app=blackbox-exporter；
配置回滚见第 7 章。
步骤 3（#13 / #14）：修正 env-inventory/inventory.yaml¶
- #14：六台（
.23–.28）均同时运行lim与sbatchd，.23/.24另有mbatchd； 原evidence只记lim，且 lsf-work-01~03 的 note「探测到 lim 而非 sbatchd」与实况不符 → 更正 evidence、删除该 note。 - #13：这六台 SELinux 为
disabled（/etc/selinux/config亦为SELINUX=disabled，持久化）， 集群内其余 12 台为Enforcing；本环境从未改动过这些主机的 SELinux，属 LSF/HPC 装机既有基线 → 补selinux: disabled字段留档。
注意事项与坑：evidence: [lim] 与 [lim, lustre-mount] 在文件中多处重复，
不能按行文本盲替换，须按 hostname 定位所属块再改。
cd /home/rain/Documents/k8s_ins
python3 group3-tails-20261003/apply_inventory_fix.py # 幂等：重复执行第二次输出 changed_lines=0
python3 -c "import yaml; yaml.safe_load(open('env-inventory/inventory.yaml'))" # 结构校验
预期：首次 changed_lines=15；复跑 changed_lines=0。
失败判断：脚本报 ERROR 未定位到主机 → 说明清单结构已变，停止并人工核对，勿盲目重跑。
步骤 4（#15）：oom 日志溯源（只读，无变更）¶
内容探针自检发现的 oom 类日志，实为 grafana 容器被 cgroup OOM 击杀的内核记录，
与 #12 同源，无需独立处置。取证命令：
set -a; . "$HOME/.secrets/efk.env"; set +a
kubectl port-forward -n monitoring svc/elasticsearch 19200:9200 &
curl -s -u "elastic:$ELASTIC_PASSWORD" -H 'Content-Type: application/json' \
"http://localhost:19200/filebeat-*/_search?size=3&sort=@timestamp:desc" \
-d '{"query":{"match_phrase":{"message":"out of memory"}}}'
预期样本形如：k8s-node-03 kernel: Memory cgroup out of memory: Killed process 1930840 (gpx_grafana_inf) ... UID:472。
6. 验证¶
| 项 | 命令 | 预期 |
|---|---|---|
| #12 资源生效 | kubectl get deploy -n monitoring kube-prometheus-stack-grafana -o jsonpath='{.spec.template.spec.containers[?(@.name=="grafana")].resources}' |
limits.memory=1Gi、requests.memory=384Mi |
| #12 无回落 | 同上 + kubectl get prometheus -n monitoring -o jsonpath='{.items[0].spec.retention}{.items[0].spec.storage.volumeClaimTemplate.spec.storageClassName}' |
15d / nfs-csi-hdd（保持现场值） |
| #12 pod 就绪 | kubectl get pods -n monitoring -l app.kubernetes.io/name=grafana |
3/3 Running，新 pod RESTARTS 0 |
| #10 配置生效 | kubectl exec -n monitoring deploy/blackbox-exporter -- grep -A2 https_ldapadmin /etc/blackbox_exporter/blackbox.yml |
timeout: 15s |
| #13/#14 清单 | python3 -c "import yaml; d=yaml.safe_load(open('env-inventory/inventory.yaml')); print([(h['hostname'],h.get('selinux'),h['evidence']) for h in d['hosts'] if h['hostname'].startswith(('lsf','hpc'))])" |
六台均 selinux=disabled、evidence 含 sbatchd |
实测结果（2026-10-03）：
- grafana
resources={limits:{cpu:1,memory:1Gi},requests:{cpu:100m,memory:384Mi}}，pod3/3 Running，启动后用量 444Mi（limit 1Gi 内有余量）； - prometheus 仍
4Gi / 100Gi / nfs-csi-hdd、alertmanager 仍512Mi、grafananodeSelector=k8s-node-03保留 →--reuse-values未造成回落； - blackbox-exporter
successfully rolled out，pod 内timeout: 15s已生效； - inventory 六台：
selinux=disabled、evidence 分别为[lim, mbatchd, sbatchd]（主控）/[lim, sbatchd, lustre-mount]（计算与提交），stale note 已删；复跑changed_lines=0。
7. 回滚¶
备份全部存放于 group3-tails-20261003/backup/，逐条见 backup/README.md（时间戳 20261003-002411）。
| 变更 | 回滚动作 |
|---|---|
| #12 | helm rollback kube-prometheus-stack 11 -n monitoring（回到 REVISION 11，资源恢复 512Mi/256Mi） |
| #10 | cp backup/monitoring-p2-20261001/manifests/20-blackbox-exporter.yaml.bak.20261003-002411 monitoring-p2-20261001/manifests/20-blackbox-exporter.yaml && kubectl apply -f monitoring-p2-20261001/manifests/20-blackbox-exporter.yaml && kubectl rollout restart deployment/blackbox-exporter -n monitoring |
| #13/#14 | cp backup/env-inventory/inventory.yaml.bak.20261003-002411 env-inventory/inventory.yaml |
回滚触发条件（任一达标即回滚）：grafana pod 未在 5 分钟内 Ready、探针连续 3 个周期失败、 YAML 解析失败。回滚后复跑第 6 章验证。
8. 风险说明¶
| 风险 | 缓解 |
|---|---|
helm upgrade 回落现场配置 |
严格 --reuse-values -f overlay；变更后逐项核对 prometheus/alertmanager/nodeSelector 未被改动（已实测保留） |
| 放宽探针超时可能掩盖真实慢响应 | 仅放宽到 15s（原 10s），仍能捕获真正不可用；#10 根因仍未定，SOP 保留「再现则抓复现」的后续条件 |
| inventory 为数据源，改错影响面广 | 变更前完整备份 + 幂等脚本 + YAML 结构校验 + 复跑零变更校验 |
| #15 曾被当成独立问题 | 已在本文并入 #12，避免重复处置 |
附录：五项结论对照¶
| # | 结论（2026-10-03） | 处置 |
|---|---|---|
| 12 | 【已确认】grafana memory limit 512Mi < 稳态用量 584Mi → 被 cgroup OOMKilled（Exit 137），重启 9 次 | 已修：limit 1Gi |
| 15 | 【已确认】oom 类日志 244 条（14 天）集中在 10-01/10-02，来源 k8s-node-03 /var/log/messages，进程 gpx_grafana_*（UID 472）→ 与 #12 同源，非宿主内核 OOM、非业务进程 |
无独立变更，并入 #12 |
| 13 | 【已确认】.23–.28（lsf 5 台 + hpc-submit）SELinux 持久化 disabled，其余 12 台 Enforcing；从未被本环境改动，属装机既有基线 |
已记入 inventory selinux 字段 |
| 14 | 【已确认】六台实际 lim 与 sbatchd 并存（.23/.24 另有 mbatchd），原探测口径只记了 lim |
已更正 inventory evidence 并删除错误 note |
| 10 | 【未定根因】近 7 天 probe_success==0 为 0，但 probe_duration_seconds 峰值 9.5s 逼近原 10s 阈值 |
已缓解：timeout 10s→15s；若再现，开 phpLDAPadmin 访问日志抓复现 |
来源：
/home/rain/Documents/k8s_ins/group3-tails-20261003/SOP.md｜ 最后更新：2026-10-03 00:26（由build/sync.py同步，请勿在站点侧修改）