SMBIOS Memory

Plugin: go.d.plugin Module: smbios_memory

Overview

Monitor physical memory inventory and detect missing or smaller memory devices relative to an accepted baseline. The Memory Inventory live table exposes slot locations, capacities, device identifiers, rank counts, and rated and configured speeds for local inspection or retrieval through the Functions API.

Reads /sys/firmware/dmi/tables/smbios_entry_point and /sys/firmware/dmi/tables/DMI every 60 seconds by default, respecting NETDATA_HOST_PREFIX. No external command or EDAC support is required.

These are boot-time firmware tables: a recent read does not establish current usable memory, operating frequency, or hardware health. Only physical devices in system-memory arrays contribute to inventory totals.

info

The collector keeps a private baseline: smbios-memory.json in the Agent's library directory (/var/lib/netdata by default). The first complete inventory it saves becomes the configuration every later read is compared with, and a confirmed loss stays recorded there across restarts and reboots. To accept a smaller configuration as the new baseline, stop Netdata, move the file aside, and start Netdata again; Troubleshooting has the exact steps. This is the only file the collector writes; it never changes firmware, kernel settings, or device permissions.

This collector is only supported on the following platforms:

• Linux

This collector only supports collecting metrics from a single instance of this integration.

A standard installation needs nothing extra: the installer grants go.d.plugin the CAP_DAC_READ_SEARCH capability that reads the root-only firmware files, and the Agent's library directory is already writable.

Access	Needed when
Read /sys/firmware/dmi/tables/smbios_entry_point and /sys/firmware/dmi/tables/DMI (root-only files, so CAP_DAC_READ_SEARCH or equivalent)	Always. Restore the plugin's file capabilities if a hardened install or a container drops them.
Write to the Agent's library directory (/var/lib/netdata by default)	To save the baseline and any confirmed loss. Without it the inventory is still read, but comparison reports state_error.

Default Behavior

Auto-Detection

The stock configuration starts the single smbios_memory job when the host exposes a readable SMBIOS table with a system-memory array. A host that already has a saved baseline also starts when the table cannot be read, so an unresolved loss stays visible.

The baseline is learned automatically: the first complete inventory with unique slot locators and known capacities is saved as the accepted configuration. It is the first configuration observed, not an independently verified healthy one. Added devices and capacity increases are accepted automatically only while every previously accepted slot still has at least its accepted capacity; a missing or smaller slot is reported as loss until it is restored or the baseline is reset (see Troubleshooting).

Limits

Comparison depends on firmware quality. Blank or repeated slot locators, unknown device capacities or array use, malformed records, and inconsistent array counts leave the inventory readable but not comparable: the comparison status chart reports uncomparable and the smbios_memory_comparison_unavailable alert raises a warning.

Slot locators must stay stable across boots; a firmware update that renames slots is not matched automatically and shows every old slot as missing and every new slot as not in the baseline. Replacing a device with one of equal or larger capacity in the same slot is not loss.

Inventory does not attribute EDAC errors to physical devices: the evidence needed to join platform-specific EDAC ranks to SMBIOS slots is not available.

Performance Impact

Reads two local firmware files per collection. Baseline and loss-state changes write one private state file; unchanged observations do not rewrite it.

Setup

The smbios_memory collector runs as a single instance: it does not take user-defined jobs, and the Netdata web interface offers no + to add one. Adjust its settings in go.d/smbios_memory.conf.

Prerequisites

Expose the host firmware tables to a containerized Agent

Applies only to Agents running in a container. The collector reads the host's firmware through NETDATA_HOST_PREFIX, so the host's /sys must be mounted there read-only. The documented docker run and Compose examples already include this mount:

-v /sys:/host/sys:ro

Verify: the Memory Inventory Live Data table lists the host's memory slots and the comparison status chart reports comparable after the first collection.

Configuration

Options

Options apply to the host's single smbios_memory job. This collector has no remote target and cannot be attached to a virtual node.

Option	Description	Default	Required
update_every	Interval in seconds between reads of the boot-time firmware inventory. Reading more frequently does not refresh the firmware's hardware information.	60	no

via File

The configuration file name for this integration is go.d/smbios_memory.conf.

The file format is YAML. A single-instance collector takes exactly one job, whose name is fixed:

jobs:
  - name: smbios_memory

Any other job name is rejected. Set the collector's own options alongside name. You can edit the configuration file using the edit-config script from the Netdata config directory.

cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata
sudo ./edit-config go.d/smbios_memory.conf

Examples

Basic

The stock configuration. The single job monitors the local host's memory inventory with the default interval.

jobs:
  - name: smbios_memory

Read the firmware table less often

The table changes only at boot, so a longer interval loses nothing except how quickly a change after a reboot is reported.

jobs:
  - name: smbios_memory
    update_every: 300

Alerts

The following alerts are available:

Alert name	On metric	Description
Alert name smbios_memory_confirmed_loss	On metricsmbios_memory.confirmed_loss_status	DescriptionPhysical memory is missing or smaller than the accepted firmware inventory baseline
Alert name smbios_memory_comparison_unavailable	On metricsmbios_memory.comparison_status	DescriptionThe current firmware inventory cannot be compared with a durable memory baseline

Metrics

Metrics grouped by scope.

The scope defines the instance that the metric belongs to. An instance is uniquely identified by a set of labels.

All charts belong to the local host. Unavailable measurements leave gaps rather than zeroes. The confirmed-loss status retains a previously observed loss through source failures and restarts; it does not claim a fresh hardware measurement. Missing-device and capacity-deficit quantities appear only after a successful comparable observation.

Per SMBIOS Memory instance

The host's physical system-memory inventory and accepted baseline comparison.

This scope has no labels.

Metrics:

Metric	Description	Dimensions	Unit
smbios_memory.installed_capacity	Firmware-Reported Installed Memory	installed	bytes
smbios_memory.slots	Firmware-Reported Memory Slots	populated, empty	slots
smbios_memory.inventory_status	Memory Inventory Availability	available, unavailable	state
smbios_memory.comparison_status	Memory Baseline Comparison Status	comparable, unavailable, uncomparable, unbaselined, state_error	state
smbios_memory.confirmed_loss_status	Confirmed Memory Loss	present, absent, unknown	state
smbios_memory.missing_devices	Missing Memory Devices Relative to Baseline	missing	devices
smbios_memory.capacity_deficit	Memory Capacity Deficit Relative to Baseline Slots	deficit	bytes

Live Data

Inspect the latest completed inventory read through Live Data or the Functions API. Opening the table performs no firmware read and does not change the baseline.

Memory Inventory

Inspect populated and empty physical system-memory slots alongside their accepted capacities and comparison status.

Aspect	Description
Name	Smbios-memory-inventory
Require Cloud	no
Performance	Reads the completed collection snapshot; response size grows with the number of memory slots.
Security	Read-only. Exposes firmware identifiers, including device serials, to authorized Function callers. The local baseline file is private to its owner.
Availability	Published while the canonical collector is running. Before the first collection it returns HTTP 503; source failures retain baseline rows with unavailable status.

Prerequisites

No additional configuration is required.

Parameters

This function has no parameters.

Returns

One row per current physical system-memory device, plus accepted populated slots absent from the current table. Baseline-only rows identify their metadata as historical; unknown readings are null.

Column	Type	Unit	Visibility	Description
Key	string		hidden	Identity within this snapshot; not a persistent hardware identity.
Slot	string			Firmware device locator.
Bank	string		hidden	Firmware bank locator.
Population	string			Populated, empty, or unknown.
Capacity	integer	bytes		Current firmware-reported physical capacity.
Accepted capacity	integer	bytes		Capacity in the accepted baseline.
Comparison	string			Slot comparison or reason comparison is unavailable.
Data availability	string		hidden	Current firmware data or baseline-only evidence.
Memory type	string			Firmware memory technology.
Form factor	string		hidden	Firmware form factor.
Manufacturer	string			Current or baseline-only device manufacturer.
Part number	string			Current or baseline-only device part.
Serial number	string		hidden	Current or baseline-only device serial.
Ranks	integer	ranks	hidden	Number of device ranks.
Rated speed	integer	MT/s		Maximum capable firmware transfer rate.
Configured speed	integer	MT/s		Configured boot-time transfer rate.
ECC association	string		hidden	Unavailable: no verified physical EDAC join.
Read attempt	timestamp		hidden	Last attempt to read the boot-time firmware table.
Inventory status	string		hidden	Availability of the current firmware table.
Loss recorded	timestamp		hidden	When the retained loss evidence last changed; null when no loss is retained.

Troubleshooting

Diagnostics

Debug Mode

Important: Debug mode is not supported for data collection jobs created via the UI using the Dyncfg feature.

To troubleshoot issues with the smbios_memory collector, run the go.d.plugin with the debug option enabled. The output should give you clues as to why the collector isn't working.

• Navigate to the plugins.d directory, usually at /usr/libexec/netdata/plugins.d/. If that's not the case on your system, open netdata.conf and look for the plugins setting under [directories].

  cd /usr/libexec/netdata/plugins.d/

• Switch to the netdata user.

  sudo -u netdata -s

• Run the go.d.plugin to debug the collector:

  ./go.d.plugin -d -m smbios_memory

  To debug a specific job:

  ./go.d.plugin -d -m smbios_memory -j jobName

Getting Logs

If you're encountering problems with the smbios_memory collector, follow these steps to retrieve logs and identify potential issues:

• Run the command specific to your system (systemd, non-systemd, or Docker container).
• Examine the output for any warnings or error messages that might indicate issues. These messages should provide clues about the root cause of the problem.

System with systemd

Use the following command to view logs generated since the last Netdata service restart:

journalctl _SYSTEMD_INVOCATION_ID="$(systemctl show --value --property=InvocationID netdata)" --namespace=netdata --grep smbios_memory

System without systemd

Locate the collector log file, typically at /var/log/netdata/collector.log, and use grep to filter for collector's name:

grep smbios_memory /var/log/netdata/collector.log

Note: This method shows logs from all restarts. Focus on the latest entries for troubleshooting current issues.

Docker Container

If your Netdata runs in a Docker container named "netdata" (replace if different), use this command:

docker logs netdata 2>&1 | grep smbios_memory

Known Errors

Intentionally accepting a smaller memory configuration

Cause

A planned removal or downsizing is still a loss relative to the previously accepted baseline, and acknowledging or silencing the alert does not replace the baseline.

Fix

Reset the baseline while the collector is stopped. Stop Netdata, move the state file aside as a backup, then start Netdata; the next valid, comparable inventory becomes the new baseline:

sudo systemctl stop netdata
sudo mv -i /var/lib/netdata/smbios-memory.json /var/lib/netdata/smbios-memory.json.backup
sudo systemctl start netdata

Use the Agent's configured library directory if it differs (static installations commonly use /opt/netdata/var/lib/netdata). Alternatively, disable the collector through Dynamic Configuration, wait for it to stop, move the file, then re-enable it.

caution

Only the running Agent's collector writes this file. A go.d.plugin debug run from a terminal reads and compares against it but never saves, so debugging is safe; do not run a second Agent against the same library directory.

Verify that the comparison status returns to comparable. If reading or saving fails, no replacement baseline is accepted and the status stays unbaselined or state_error. Keep the backup if the old evidence is needed.

read SMBIOS entry point: open path: permission denied

Cause

go.d.plugin lost read access to the root-only firmware files, usually because its CAP_DAC_READ_SEARCH file capability was dropped by a hardened install or is not available inside the container.

Fix

Re-run the Netdata installer, which restores the plugin's file capabilities, or grant CAP_DAC_READ_SEARCH to the container. Existing charts and any saved baseline are kept while the source is unreadable.

read SMBIOS entry point: open path: no such file or directory

When

The host or container does not expose /sys/firmware/dmi/tables.

Cause

The kernel exposes no SMBIOS tables on this platform, or the container was started without the host's /sys mounted under NETDATA_HOST_PREFIX.

Fix

In a container, add the -v /sys:/host/sys:ro mount from the prerequisites. A host without SMBIOS tables cannot use this collector; disable it to silence the message.

no system memory array

Cause

The firmware table contains no physical memory array marked as system memory, which happens on some virtual machines and boards.

Fix

Nothing to configure. This host cannot be inventoried through SMBIOS; disable the collector.

Unknown device capacity

Cause

Firmware reports at least one memory device with an unknown size, so totals and a per-slot baseline cannot be trusted.

Fix

The inventory table remains available; comparison stays uncomparable until firmware reports every capacity. Check the vendor's firmware updates.

Physical memory array use is unknown or unsupported

Cause

Firmware does not state whether a memory array holds system memory, so the collector cannot tell which devices are host RAM.

Fix

The inventory table remains available with totals withheld; comparison stays uncomparable. Check the vendor's firmware updates.

Slot locators are missing or duplicated

Cause

Firmware does not give every memory device a unique slot locator, so devices cannot be matched across observations.

Fix

The inventory table remains available; comparison stays uncomparable for this firmware. Check the vendor's firmware updates.

physical array device count disagrees with table

Cause

The firmware table is inconsistent; it declares more or fewer memory devices than it lists.

Fix

Check the table with the hardware vendor's tools and firmware updates. A missing record in an inconsistent table is not proof of a lost memory device, so nothing is reported as loss.

memory baseline has unsupported version, owner or content

Cause

The state file belongs to another Agent, is damaged, or uses an unsupported format.

Fix

Restore the matching state file from a backup, or start a new baseline with the stopped-collector reset above; do not edit the file in place. Restart the collector afterwards, because a failed state load is reported until restart.

memory baseline contains an invalid slot

Cause

The state file was edited or truncated and no longer describes valid accepted slots.

Fix

Restore the state file from a backup, or start a new baseline with the stopped-collector reset above, then restart the collector.

memory baseline contains invalid loss evidence

Cause

The state file was edited or truncated and its recorded loss no longer matches its accepted slots.

Fix

Restore the state file from a backup, or start a new baseline with the stopped-collector reset above, then restart the collector.

create baseline temporary file: error

Cause

The Agent's library directory is missing, not writable, or on a full filesystem, so a new baseline or a newly observed loss cannot be saved.

Fix

Restore the directory, its permissions and free space; saving is retried on every collection. A loss observed while saving fails is kept in memory but does not survive a restart until it has been saved.

publish baseline: error

Cause

The temporary file was written but could not replace smbios-memory.json, usually because the directory permissions changed.

Fix

Restore write permission on the Agent's library directory; saving is retried on every collection.

Agent registry identity is unavailable; baseline persistence disabled

Cause

The collector cannot read the Agent's registry identity, which every saved baseline is bound to.

Fix

Restore the Agent's registry directory and its permissions, then restart the collector. Inventory is still read, but no baseline is accepted without an Agent identity.