Net-SNMP似乎已经解决了这个问题,只需操作“AllocationUnits”的值来维持磁盘利用率的32位值(因为总磁盘大小/使用率等于32位空间值乘以分配单元),允许用于计算大于8 / 16TB的体积.假设您对分配单元没有任何报告兴趣,并且可以处于少量不准确状态.这似乎是一个优雅的解决方案.
https://bugzilla.redhat.com/show_bug.cgi?id=654384
然而,Window内置的SNMP服务似乎继续遭受此错误,只是报告使用/分配的磁盘空间的模数,导致磁盘大小报告不准确.
有没有办法让Windows能够正确报告超过16TB的卷的磁盘使用情况？我们试图简单地安装Net-SNMP 5.5 x64并完全禁用Windows SNMP服务,但遗憾的是这并没有解决我们的问题.
使用NetSNMP扩展时,我们为我们感兴趣的特定磁盘收集的信息如下：
无论我们使用的是vanilla Windows SNMP服务还是NetSNMP,这些结果都是相同的.
我见过Cacti社区的人提到只是编写解决方案的脚本.不幸的是,我们使用Observium进行快速和基本的系统监控.如果在Window方面无法解决问题,可以使Observium报告自定义MIB吗？
–Update–
查看错误报告中提到的将“realStorageUnits”添加到snmpd.conf文件中,我们在设置该指令时遇到了以下问题：
– 更新2–
好吧,经过多次修改后,它看起来不像任何Windows版本的Net-SNMP,就像“realStorageUnits”指令一样.包含该指令会在启动SNMP时产生警告.我们尝试了5.5,5.6和5.7版.有没有人在这里想过如何让SNMP在Windows上报告16 TB的卷？
从Redhat Bugreport #748410开始：
To address this issue [negative hrStorageSite values],this update adds a new option to the
/etc/snmp/snmpd.conf configuration file,realStorageUnits. By changing
the value of this option to 0,users can Now enable recalculating all
values in hrStorageTable to ensure that the multiplication of
hrStorageSize and hrStorageAllocationUnits always produces an accurate
device size.
([方括号]中的文字是我的)
因此,将配置指令realStorageUnits 0添加到snmpd.conf可能正在解决您的问题.
但是,这些值在最后一兆字节之前是不正确的;因人而异.
我不知道this patch是否包含在你的Net-SNMP二进制发行版中,但如果你能报告结果以及你正在使用的二进制文件,那将会很棒.此外,我现在没有测试它是否缺乏足够的硬件.