16 ТБ томов и SNMP в Windows

Поскольку тома размером более 16 ТБ стали более распространенными, было признано, что 32-разрядное значение, используемое для отчета о размере диска и использовании в стандартной MIB "HOST-RESOURCES" в SNMP, было недостаточно большим, чтобы сообщить правильный размер диска.

Net-SNMP, по-видимому, решил эту проблему, просто манипулируя значением "AllocationUnits", чтобы поддерживать 32-битное значение для использования диска (поскольку общий размер / использование диска равно 32-битному значению пространства, умноженному на единицу выделения), чтобы для расчета объема больше 8/16TB. Предполагая, что у вас нет отчетного интереса к единице распределения, и все в порядке с небольшой степенью неточности. это похоже на элегантное решение.

https://bugzilla.redhat.com/show_bug.cgi?id=654384

Однако встроенная в Windows служба SNMP, похоже, продолжает страдать от этой ошибки, просто сообщая по модулю занятого / назначенного дискового пространства, что приводит к неточным отчетам о размере диска.

Есть ли способ, позволяющий Windows правильно сообщать об использовании диска для томов свыше 16 ТБ? Мы попытались просто установить Net-SNMP 5.5 x64 и полностью отключить службу Windows SNMP, однако, к сожалению, это не помогло решить проблему.

При использовании расширений NetSNMP информация, которую мы собираем для конкретного интересующего нас диска, выглядит следующим образом:

введите описание здесь

Эти результаты одинаковы, независимо от того, используем ли мы стандартную службу SNMP для Windows или NetSNMP.

Я видел, как люди в сообществе Cacti упоминают просто написание решения. К сожалению, мы используем Observium для быстрого и простого мониторинга системы. Если проблема не может быть исправлена ​​на стороне окна, можно ли сделать Observium для отчета о пользовательских MIB?

-Обновление-

Изучив упоминание в отчете об ошибке о добавлении "realStorageUnits" в файл snmpd.conf, мы столкнулись со следующей проблемой при установке этой директивы:

realStorageUnits помогает нам

-Обновление 2-

Что ж, после долгих переделок он не похож ни на одну из версий Net-SNMP для Windows, как на директиву realStorageUnits. Включение директивы приводит к предупреждению при запуске SNMP. Мы пробовали версии 5.5, 5.6 и 5.7. Кто-нибудь здесь когда-нибудь выяснил, как заставить SNMP сообщать о томах объемом более 16 ТБ в Windows?

2 ответа

Решение

Некоторое время назад был патч для Net-SNMP 5.5, который представил новую опцию realStorageUnits для файла конфигурации.

Из багрепорта Redhat # 748410:

Чтобы устранить эту проблему [отрицательные значения hrStorageSite], это обновление добавляет новую опцию в файл конфигурации /etc/snmp/snmpd.conf, realStorageUnits. Изменив значение этого параметра на 0, пользователи теперь могут включить пересчет всех значений в hrStorageTable, чтобы гарантировать, что умножение hrStorageSize и hrStorageAllocationUnits всегда дает точный размер устройства.

(текст в [скобках] мой)

Поэтому добавление директивы конфигурации realStorageUnits 0 к вашему snmpd.conf может решить вашу проблему.

Однако значения не будут правильными до самого последнего мегабайта; YMMV.

Я не могу сказать, был ли этот патч включен в ваш бинарный дистрибутив Net-SNMP, но было бы здорово, если бы вы могли сообщить о результатах и ​​том, какой бинарный файл вы используете. Кроме того, я не проверял это на отсутствие адекватного оборудования прямо сейчас.

Я знаю, что это не прямой ответ на ваш вопрос, но, возможно, это поможет. Я предлагаю вам попробовать связаться с командой, которая делает SNMP Informant: http://www.snmp-informant.com/

Они расширяют агент SNMP для Windows, чтобы обойти ограничения Microsoft для некоторых из своих OID. Я использую его с Zenoss, чтобы получить более точные данные об использовании ЦП и хранилище, и есть большая вероятность, что это обойдет вашу проблему, но я не могу сказать наверняка.

Другие вопросы по тегам