问题说明

高级监控的内存可用量依赖 Guest 内 exporter 输出 node_memory_MemAvailable_bytes。QGA、zwatch 或 collectd 进程存在，只能证明部分链路工作，不能证明 node_exporter 已成功监听并输出该指标。

现象

• CPU、磁盘、网络等高级监控正常，内存仍显示基础监控或数据缺失。
• /proc/meminfo 中存在 MemAvailable，但 exporter 接口没有 node_memory_MemAvailable_bytes。
• 关键区分点：只有单台云主机异常，同环境其他云主机正常。

适用环境

• 已在 ZSphere 4.10.19.3、Linux Guest 验证。
• 该现场根因是 Guest 端口冲突，不是 4.10.19.3 的版本特性。

可能原因

先确认操作系统是否提供原始值，再确认实际采集端点和端口占用者。若原始值存在但 exporter 指标不存在，应聚焦采集进程/端口，不应修改内存计算公式。

问题定性

• 类型：环境问题（Guest 端口冲突）。
• 已知问题：是，现场案例 TIC-6076；TIC 于 2026-07-23 Closed/Done。
• 根因：客户 Guest 中 Java 进程占用 *:9100，VMTools 自带 node_exporter 无法启动，导致 node_memory_MemAvailable_bytes 单项缺失。
• 影响版本：现场为 4.10.19.3；证据不支持扩大为某一版本固有问题。
• 置信度：高，前提是端口归属证据一致。

排查步骤

检查一：确认 Guest 原始内存字段

• 检查目的：区分内核字段缺失与采集链路故障。
• 只读命令：

  grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|Cached):' /proc/meminfo

• 有 MemAvailable：内核已提供可用内存，继续检查 exporter。
• 无 MemAvailable：不能套用 TIC-6076，需收集 Guest OS/内核版本并升级人工。

检查二：确认高级监控指标

• 检查目的：验证 exporter 是否真正输出内存指标。
• 只读命令：

  curl -s http://127.0.0.1:9100/metrics | grep -E '^node_memory_(MemAvailable|MemTotal)_bytes'

• 同时出现两个指标：Guest 采集端正常，继续检查平台抓取、标签和时间窗；不能定性为端口冲突。
• 无输出或连接失败：继续检查 9100 监听者。

检查三：确认进程和端口归属

• 检查目的：判断 node_exporter 是否启动以及默认端口是否被抢占。
• 只读命令：

  ps -ef | grep -E 'node_exporter|collectd|zwatch-vm-agent' | grep -v grep
  ss -lntp | grep ':9100'

• 9100 被非 node_exporter 进程监听且无 node_exporter：命中 TIC-6076 的根因分支。
• 9100 由 node_exporter 监听但指标仍缺失：收集 exporter 启动参数和日志，升级人工。
• 无进程且端口空闲：属于 agent/exporter 未启动分支，不等同于端口冲突。

处理建议

由客户确认业务端口可否调整；若不能调整，审批后备份 zwatch-vm-agent 配置，将 node_exporter 改到空闲端口并重启 agent。操作前记录原配置，失败时恢复备份并重启原服务。变更后必须同时验证新端口指标、平台内存曲线和原业务端口。

长期方案

将监控 agent 端口纳入 Guest 镜像和应用端口规划；部署前检测冲突，并为 exporter 启动失败提供清晰告警。

补充信息

升级人工条件

• /proc/meminfo 无 MemAvailable。
• node_exporter 正常输出指标但平台仍不展示。
• 端口未冲突但 node_exporter 无法启动。
• 需要修改端口或重启生产 Guest 服务。

需要收集的信息

ZSphere 版本、Guest OS/内核版本、上述三组命令完整输出、zwatch-vm-agent/node_exporter 日志、异常时间窗和云主机 UUID（提交工单时脱敏）。

相关问题

• TIC-6076，Closed/Done，状态核验日期 2026-08-06。