Нам не хватило места на томе 5 ТБ на сервере хранения Windows, поэтому мы скопировали данные в новый том 10 ТБ.
Теперь наш мониторинг на основе nagios сообщает данные, которыми я не доволен. Когда я просмотрел данные, я заметил, что они показывают отрицательное значение для общего пространства тома.
Сначала я предположил проблему с кешем, но решил вручную искать значения через snmpwalk. Результаты были:
iso.3.6.1.2.1.25.2.3.1.1.6 = INTEGER: 6
iso.3.6.1.2.1.25.2.3.1.2.6 = OID: iso.3.6.1.2.1.25.2.1.4
iso.3.6.1.2.1.25.2.3.1.3.6 = STRING: "V:\\ Label:VolumeXYZ Serial Number f6435543"
iso.3.6.1.2.1.25.2.3.1.4.6 = INTEGER: 4096
iso.3.6.1.2.1.25.2.3.1.5.6 = INTEGER: -1610614235
iso.3.6.1.2.1.25.2.3.1.6.6 = INTEGER: 1163527892
iso.3.6.1.2.1.25.2.3.1.7.6 = Counter32: 0
Учитывая, что все остальные тома имеют положительное значение в iso.3.6.1.2.1.25.2.3.1.5 ветке, я предполагаю, что отрицательное значение для рассматриваемого объема является индикатором того, почему я вижу отрицательное значение в nagios.
Как я могу исправить эту ситуацию?
Отрицательное число связано с целочисленным переполнением для 32-битное целое число со знаком, используемое для сообщения количества блоков.
У меня была такая же проблема с NAS на базе Linux. Мне удалось подделать больший размер блока в Linux, что предотвратило целочисленное переполнение, и произведение размера блока на количество блоков привело к правильному объему хранилища. В ошибка сообщается для Net-SNMP, и есть патч доступный. Я не уверен, что вы можете настроить таким же образом систему Windows.