AD‑Campus SeerAnalyzer 分析器 itoa‑health‑analysis Pod 反复重启

itoa‑health‑analysis 是 SeerAnalyzer 分析器组件，负责设备健康指标计算、告警生成；反复重启一般为：OOM 内存溢出、依赖服务（kafka/elasticsearch/itoa‑db）连接失败、持久卷异常、探针误杀、版本 BUGKubernetes。

登录统一数字底盘 Oasis 节点执行 kubectl，命名空间一般为 itoa。

第一步：定位重启根本原因（必做）

常见现象解读

1. 事件看到 OOMKilled ExitCode:137：内存超限被内核杀死，最常见。分析器指标量大，内存限制不足，采集设备多容易触发。
2. Liveness probe failed：健康检查超时，业务没启动完成就被 kubelet 杀掉。
3. 日志大量connect refused / timeout：连不上 kafka、elasticsearch、itoa‑db，依赖 pod 异常。
4. 日志报文件读写失败：PVC 持久卷挂载异常、磁盘满。

高频根因

1. 采集设备数量多，指标数据量大，pod 内存 limit 配置偏小（现场最高概率）
   itoa‑health‑analysis做健康计算，设备多、指标多，内存会明显上涨，超出 yaml 里 limit，直接 OOMkill，循环重启。
2. 依赖组件异常：itoa‑db、kafka、elasticsearch pod 异常未就绪，本 pod 启动连接失败直接退出。
3. 持久存储 PVC 异常：pv/pvc 挂载失败，无法读写本地缓存文件。
4. 版本已知缺陷：特定 AD‑Campus 版本itoa‑health‑analysis存在内存泄漏 BUG。
5. 磁盘满：分析器节点磁盘 100%，写日志 / 指标文件失败。

排障操作步骤

1）检查整个 itoa 命名空间其他 pod 状态

2）检查磁盘空间

3）临时恢复（业务紧急）

删除 pod，deployment 控制器会自动重建 pod：

如果删除后依旧反复重启，需要定位根因，单纯删除 pod 治标不治本。

4）OOM 内存溢出处理（最常见场景）

1. 查看当前 deployment 资源配置

设备数量多（>100 台），默认内存配额不够，需要调高 limit 内存。

⚠️不要直接手动改 yaml，AD‑Campus 统一数字底盘 Web 界面修改 SeerAnalyzer 实例资源规格，修改后 pod 自动重建生效，直接 kubectl edit 会被底盘覆盖。

Web 路径：统一数字底盘 →应用管理→SeerAnalyzer 实例→编辑实例资源，调高itoa‑health‑analysis内存限制。

5）依赖服务异常场景

• 如果 kafka /elasticsearch/itoa‑db 异常，优先修复对应 pod；依赖恢复后，itoa‑health‑analysis自动恢复。
• 常见：elasticsearch 节点分片异常、磁盘水位触发锁写，导致 health‑analysis 写指标失败退出。

6）健康探针误杀

不要直接 kubectl edit 修改探针，在统一数字底盘 web 修改实例参数，调大存活探针初始延迟、超时时间。

版本规避提示

1. 核对 AD‑Campus 版本，部分版本itoa‑health‑analysis存在内存泄漏已知问题，设备多会持续涨内存 OOM；需要升级到对应版本最新补丁。
2. 如果环境设备规模大，SeerAnalyzer 硬件规格要匹配开局规格，小规格服务器跑大量设备指标极易 OOM。

回退兜底

1. 如果临时需要恢复分析器业务，可在 web 上临时停止 SeerAnalyzer，再重新启动实例。
2. 如果反复故障，导出 pod 日志（kubectl logs xxx --previous > health.log）提交 H3C TAC 分析。

排查输出给 TAC 收集信息清单

1. kubectl describe pod itoa‑health‑analysis‑xxx -n itoa输出
2. kubectl logs podname -n itoa --previous崩溃日志
3. kubectl get pods -n itoa全部 pod 状态
4. df -h磁盘信息
5. AD‑Campus 底盘版本、SeerAnalyzer 版本、纳管设备数量。