Поскольку объемы больше 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, мы столкнулись со следующей проблемой при установке этой директивы:
- Обновление 2 -
Что ж, после долгих попыток он не похож ни на одну из версий Net-SNMP для Windows, как на директиву realStorageUnits. Включение директивы приводит к предупреждению при запуске SNMP. Мы пробовали версии 5.5, 5.6 и 5.7. Кто-нибудь здесь когда-нибудь выяснил, как заставить SNMP сообщать о томах объемом более 16 ТБ в Windows?
источник
.1.3.6.1.4.1.2021.100.2.0чтобы проверить, действительно ли отвечает Net-SNMP. На моих (Linux) хостах с Net-SNMP это даетSNMPv2-SMI::enterprises.2021.100.2.0 = STRING: "5.4.1"Ответы:
Некоторое время назад был патч для Net-SNMP 5.5, который представил новую опцию
realStorageUnitsдля файла конфигурации.Из багрепорта Redhat # 748410 :
(текст в [скобках] мой)
Поэтому добавление директивы конфигурации
realStorageUnits 0в ваш snmpd.conf может решить вашу проблему.Однако значения не будут правильными до самого последнего мегабайта; YMMV.
Я не могу сказать, был ли этот патч включен в ваш бинарный дистрибутив Net-SNMP, но было бы здорово, если бы вы могли сообщить о результатах и какой бинарный файл вы используете. Кроме того, я не проверял это из-за отсутствия адекватного оборудования прямо сейчас.
источник
realStorageUnitsдирективой. Если это все еще не работает для вас, у меня есть отчетливое ощущение, что эта функция почему-то не включена в двоичный файл NetSNMP, который вы используете.Я знаю, что это не прямой ответ на ваш вопрос, но, возможно, это поможет. Я предлагаю вам попробовать связаться с командой, которая делает SNMP Informant: http://www.snmp-informant.com/
Они расширяют агент Windows SNMP, чтобы обойти ограничения Microsoft для некоторых из своих OID. Я использую его с Zenoss, чтобы получить более точные данные об использовании процессора и хранилище, и есть большая вероятность, что это обойдет вашу проблему, но я не могу сказать наверняка.
источник