Issue/Introduction

The available memory metric in advanced monitoring depends on node_memory_MemAvailable_bytes exported by the in-guest exporter. The presence of QGA, zwatch, or collectd processes proves only that part of the path is working; it does not prove that node_exporter is listening successfully and exporting this metric.

Symptoms

• Advanced monitoring for CPU, disk, and network works normally, but memory still uses basic monitoring or has no data.
• /proc/meminfo contains MemAvailable, but the exporter endpoint does not expose node_memory_MemAvailable_bytes.
• Key differentiator: only one virtual machine is affected, while other virtual machines in the same environment work normally.

Environment

• Verified with ZSphere 4.10.19.3 and a Linux guest.
• The root cause in this case was a port conflict in the guest, not a characteristic of version 4.10.19.3.

Possible causes

First confirm whether the operating system provides the raw value, and then verify the actual collection endpoint and the process that owns the port. If the raw value exists but the exporter metric does not, focus on the collection process and port instead of changing the memory calculation formula.

Issue classification

• Type: Environment issue (guest port conflict).
• Known issue: Yes. Field case TIC-6076; the TIC was Closed/Done on 2026-07-23.
• Root cause: A Java process in the customer guest occupied *:9100, preventing the node_exporter bundled with VMTools from starting and causing only node_memory_MemAvailable_bytes to be missing.
• Affected version: The field environment used 4.10.19.3. The evidence does not support treating this as an inherent issue in a specific version.
• Confidence: High, provided that the port ownership evidence matches.

Resolution

Check 1: Verify the raw guest memory fields

• Purpose: Distinguish a missing kernel field from a collection-path failure.
• Read-only command:

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

• If MemAvailable is present: The kernel provides available memory. Continue to check the exporter.
• If MemAvailable is absent: TIC-6076 does not apply. Collect the guest OS and kernel versions and escalate.

Check 2: Verify the advanced monitoring metrics

• Purpose: Verify whether the exporter actually exposes the memory metrics.
• Read-only command:

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

• If both metrics are present: Guest-side collection is normal. Continue to check platform scraping, labels, and the time window; do not classify the issue as a port conflict.
• If there is no output or the connection fails: Continue to identify the process listening on port 9100.

Check 3: Verify process and port ownership

• Purpose: Determine whether node_exporter has started and whether its default port is occupied.
• Read-only commands:

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

• If a process other than node_exporter listens on port 9100 and no node_exporter process exists: This matches the root-cause branch in TIC-6076.
• If node_exporter listens on port 9100 but the metric is still absent: Collect the exporter startup parameters and logs, and escalate.
• If there is no process and the port is free: This is the agent/exporter-not-started branch, not a port conflict.

Recommended actions

Ask the customer to confirm whether the application port can be changed. If it cannot, after approval, back up the zwatch-vm-agent configuration, change node_exporter to an unused port, and restart the agent. Record the original configuration before the change. If the change fails, restore the backup and restart the original service. After the change, verify the metrics on the new port, the platform memory graph, and the original application port.

Long-term solution

Include monitoring agent ports in guest image and application port planning. Detect conflicts before deployment and provide a clear alert when the exporter fails to start.

Additional information

When to escalate

• /proc/meminfo does not contain MemAvailable.
• node_exporter exposes the metric normally, but the platform still does not display it.
• node_exporter cannot start even though there is no port conflict.
• Changing a port or restarting a production guest service is required.

Information to collect

ZSphere version, guest OS/kernel version, complete output of the three command groups above, zwatch-vm-agent/node_exporter logs, affected time window, and virtual machine UUID (redact it when submitting a ticket).

Related issues

• TIC-6076, Closed/Done; status verified on 2026-08-06.