We are trying to Monitor the above using a third-party monitoring Tool, we have enabled SNMP for monitoring, still we are unable to retrieve data using below OID : File directory - .1.3.6.1.2.1.25.2.3.1.3 StorageSize - .1.3.6.1.2.1.25.2.3.1.5 StorageUse

Question

Hello Team,

We are trying to Monitor the above using a third-party monitoring Tool, we have enabled SNMP for monitoring, still we are unable to retrieve data using below OID :

File directory - .1.3.6.1.2.1.25.2.3.1.3

StorageSize - .1.3.6.1.2.1.25.2.3.1.5

StorageUsed - .1.3.6.1.2.1.25.2.3.1.6

Same goes with CPU and memory

But we can retrieve data for uptime using SNMP using uptime OID.

Can we please check if these OIDs are correct for Debian and Ubuntu, why we are unable to retrieve data.

Answer 1

Hello Nikhil Singh

The OIDs you are querying are correct and standards‑based for Linux systems running Debian or Ubuntu. They belong to the HOST‑RESOURCES‑MIB (RFC 2790) and are supported by the Net‑SNMP agent used on these operating systems.

However, the behavior you are observing is expected and is related to the default SNMP agent configuration, not to an issue with the OIDs themselves.

On Debian and Ubuntu systems, the SNMP daemon (snmpd) is installed with a restricted default configuration. By design, only a limited subset of MIB objects is exposed out‑of‑the‑box. As a result:

• Uptime OIDs (for example, hrSystemUptime) are available by default and can be successfully queried.
• Storage, CPU, and memory metrics—which reside under hrStorageTable, hrProcessorTable, and related objects—are not exposed unless explicitly enabled.
• Storage metrics under .1.3.6.1.2.1.25.2.3 are tabular OIDs, which require proper table access and indexing; they cannot be reliably retrieved using a simple SNMP GET.
• Many third‑party monitoring tools fail to retrieve these values unless the SNMP agent’s view permissions and MIB support are expanded accordingly.

This is a common and documented behavior for Net‑SNMP on Debian‑based distributions and does not indicate a defect in the operating system or SNMP implementation.

The inability to retrieve storage, CPU, and memory metrics is expected behavior on Debian and Ubuntu systems and is not caused by incorrect OIDs. By default, the Net‑SNMP agent restricts access to extended and tabular MIBs for security reasons, exposing only a limited set of scalar objects such as uptime. As a result, HOST‑RESOURCES‑MIB and UCD‑SNMP‑MIB metrics are not returned unless explicitly enabled, which is a documented and standard configuration behavior on these platforms.

---

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.

If these answer your question, click "Upvote" and click "Accept Answer" which may be beneficial to other community members reading this thread.

Answer 2

Hi Nikhil Singh

It looks like you’re trying to pull the standard Host-Resources MIB OIDs for storage, CPU and memory on Debian/Ubuntu via SNMP:

• hrStorageDescr        .1.3.6.1.2.1.25.2.3.1.3  
• hrStorageSize         .1.3.6.1.2.1.25.2.3.1.5  
• hrStorageUsed         .1.3.6.1.2.1.25.2.3.1.6  
• hrProcessorLoad       .1.3.6.1.2.1.25.3.3.1.2  
• hrMemorySize          .1.3.6.1.2.1.25.2.2.0  

Those OIDs are correct and platform-agnostic, but on Debian/Ubuntu you need to explicitly enable them in your Net-SNMP daemon config. By default snmpd only exposes a limited “system” view, so storage and CPU tables aren’t populated until you adjust /etc/snmp/snmpd.conf. Here’s what you can do:

1. Edit /etc/snmp/snmpd.conf
   • Either comment out or expand the “view systemonly” definition so that it includes the Host-Resources MIB subtree (.1.3.6.1.2.1.25).
   • Add disk entries or use “includeAllDisks” to tell snmpd which file systems to report. For example:

          # report anything >10% full  
          includeAllDisks 10%  
     

   • Ensure you have an agentAddress line listening on UDP/161, e.g.:

          agentAddress udp:161  
     

2. Restart snmpd

   
      sudo systemctl restart snmpd
   
   

3. Verify with snmpwalk

   
      snmpwalk -v2c -c <community> <your-server> .1.3.6.1.2.1.25.2.3.1
   
   

   You should see hrStorageType, hrStorageDescr, hrStorageSize and hrStorageUsed entries for each mount.

If you still only get uptime or system tables, the issue is almost always in snmpd.conf or a firewall/NSG blocking UDP/161.

Hope this gets you unblocked!

Follow-up questions

1. Are these Debian/Ubuntu boxes running as Azure Linux VMs or on-prem/other cloud?
2. If they’re Azure VMs, have you installed the Azure Monitor Agent or enabled any SNMP extension?
3. Can you share the output of:

      snmpwalk -v2c -c <community> <host> .1.3.6.1.2.1.25
   

4. Can you paste your /etc/snmp/snmpd.conf (redacting any sensitive info)?
5. Are there NSG rules or host-level firewalls blocking UDP/161?

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.