Windows上的16TB卷和SNMP
随着大于16TB的卷变得越来越普遍，人们认识到，用于报告SNMP中的标准“ HOST-RESOURCES” MIB中的磁盘大小和使用情况的32位值不足以报告适当的磁盘大小。 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扩展时，我们为感兴趣的特定磁盘收集的信息如下： 无论我们使用的是原始Windows SNMP服务还是NetSNMP，这些结果都是相同的。 我见过仙人掌社区的人们提到只是编写解决方案的脚本。不幸的是，我们使用Observium进行快速和基本的系统监视。如果无法从Window侧解决此问题，是否可以使Observium报告自定义MIB？ - 更新 - 在错误报告中提到将“ realStorageUnits”添加到snmpd.conf文件中时，在设置该指令时我们遇到了以下问题： - 更新2 - 好吧，经过大量的修改，它看起来不像Net-SNMP的任何Windows版本都像“ realStorageUnits”指令一样。启动SNMP时，包含该指令将导致警告。我们尝试使用5.5、5.6和5.7版本。这里有没有人想出如何让SNMP在Windows上报告16 TB以上的卷？