随着大于 16 TB 的卷变得越来越普遍，人们认识到 SNMP 中标准“HOST-RESOURCES”MIB 中用于报告磁盘大小和使用情况的 32 位值不足以报告正确的磁盘大小。
Net-SNMP 似乎已经解决了这个问题，只需操纵“AllocationUnits”的值即可保持 32 位磁盘利用率值（因为总磁盘大小/使用量等于 32 位空间值乘以分配单元），从而允许计算大于 8/16TB 的卷。假设您对分配单元没有任何报告兴趣，并且可以接受少量的不准确性。这似乎是一个优雅的解决方案。
https://bugzilla.redhat.com/show_bug.cgi?id=654384
但是，Windows 内置的 SNMP 服务似乎继续受到此错误的影响，仅报告已使用/分配的磁盘空间的模数，导致磁盘大小报告不准确。
有没有办法让 Windows 正确报告 16TB 以上卷的磁盘使用情况？我们尝试简单地安装 Net-SNMP 5.5 x64 并完全禁用 Windows SNMP 服务，但不幸的是这并没有解决我们的问题。
使用 NetSNMP 扩展时，我们针对感兴趣的特定磁盘收集的信息如下：
无论我们使用的是原始 Windows SNMP 服务还是 NetSNMP，这些结果都是相同的。
我看到 Cacti 社区有人提到只需编写脚本即可解决问题。不幸的是，我们使用 Observium 进行快速和基本的系统监控。如果无法在 Windows 端纠正此问题，是否可以让 Observium 报告自定义 MIB？
--更新--
查看错误报告中提到的将“realStorageUnits”添加到 snmpd.conf 文件，我们在设置该指令时遇到了以下问题：
--更新 2--
好吧，经过多次修改，它看起来不像任何 Windows 版本的 Net-SNMP，例如“realStorageUnits”指令。包括该指令会导致在启动 SNMP 时出现警告。我们尝试了 5.5、5.6 和 5.7 版本。这里有人知道如何让 SNMP 在 Windows 上报告 16+ TB 的卷吗？
答案1
不久前补丁针对 Net-SNMP 5.5，它realStorageUnits为配置文件引入了一个新选项。
为了解决此问题 [hrStorageSite 值为负]，此更新在 /etc/snmp/snmpd.conf 配置文件中添加了一个新选项 realStorageUnits。通过将此选项的值更改为 0，用户现在可以重新计算 hrStorageTable 中的所有值，以确保 hrStorageSize 和 hrStorageAllocationUnits 的乘积始终产生准确的设备大小。
（[括号] 中的文字是我的）
因此，将配置指令添加realStorageUnits 0到您的 snmpd.conf 可能会解决您的问题。
但是，直到最后一兆字节的值都是不正确的；ymmv。
我不知道此补丁包含在 Net-SNMP 二进制发行版中，但如果你能报告结果以及你使用的二进制文件，那就太好了。另外，由于目前缺乏足够的硬件，我没有对其进行测试。
答案2
我知道这不是您问题的直接答案，但也许会有所帮助。我建议您尝试联系制作 SNMP Informant 的团队：http://www.snmp-informant.com/
他们扩展了 Windows SNMP 代理，以解决 Microsoft 对其某些 OID 的限制。我将其与 Zenoss 一起使用，以获得更准确的 CPU 利用率和存储数字，这很有可能解决您的问题，但我不能肯定地说。