Тома 16 ТБ и SNMP в Windows
Поскольку тома размером более 16 ТБ стали более распространенными, было обнаружено, что 32-битное значение, используемое для отчета о размере и использовании диска в стандартной MIB «HOST-RESOURCES» в SNMP, было недостаточно большим, чтобы сообщить правильный размер диска.
Net-SNMP, похоже, решил эту проблему, просто изменив значение "AllocationUnits", чтобы поддерживать 32-битное значение для использования диска (поскольку общий размер / использование диска равно 32-битному значению пространства, умноженному на единицу распределения), чтобы разрешить для расчета объема более 8/16 ТБ. Предполагая, что у вас нет интереса к отчетности по блоку распределения, и вы согласны с небольшой степенью неточности. это кажется элегантным решением.
https://bugzilla.redhat.com/show_bug.cgi?id=654384
Однако встроенная служба SNMP Window, похоже, по-прежнему страдает от этой ошибки, просто сообщая по модулю использованного / назначенного дискового пространства, что приводит к неточным отчетам о размере диска.
Есть ли способ разрешить 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?
Некоторое время назад было патч для Net-SNMP 5.5, который представил новую опцию realStorageUnits для файла конфигурации.
Чтобы решить эту проблему [отрицательные значения hrStorageSite], это обновление добавляет новый параметр в файл конфигурации /etc/snmp/snmpd.conf, realStorageUnits. Изменив значение этого параметра на 0, пользователи теперь могут включить пересчет всех значений в hrStorageTable, чтобы гарантировать, что умножение hrStorageSize и hrStorageAllocationUnits всегда дает точный размер устройства.
(текст в [скобках] мой)
Итак, добавляем директиву конфигурации realStorageUnits 0 к вашему snmpd.conf может решить вашу проблему.
Однако значения не будут правильными вплоть до последнего мегабайта; ymmv.
Я не могу сказать этот патч был включен в ваш двоичный дистрибутив Net-SNMP, но было бы здорово, если бы вы могли сообщить о результатах и о том, какой двоичный файл вы используете. Кроме того, я не тестировал его на отсутствие подходящего оборудования прямо сейчас.
Я знаю, что это не прямой ответ на ваш вопрос, но, возможно, он поможет. Я предлагаю вам попробовать связаться с командой, которая делает SNMP Informant: http://www.snmp-informant.com/
Они расширяют возможности агента Windows SNMP, чтобы обойти ограничения Microsoft для некоторых из их OID. Я использую его с Zenoss, чтобы получить более точные данные об использовании ЦП и хранилище, и есть большая вероятность, что это поможет обойти вашу проблему, но я не могу сказать наверняка.