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拡張機能を使用する場合、関心のある特定のディスクについて収集する情報は次のとおりです。
これらの結果は、Vanilla Windows SNMPサービスとNetSNMPのどちらを使用していても同じです。
サボテンコミュニティの人々が、単にソリューションをスクリプト化することについて言及しているのを見てきました。残念ながら、迅速かつ基本的なシステム監視のためにObserviumを使用しています。 Window側で問題を修正できない場合、ObserviumでカスタムMIBを報告できますか?
-更新-
「realStorageUnits」をsnmpd.confファイルに追加するというバグレポートの記述を調べたところ、そのディレクティブを設定するときに次の問題が発生しました。
-更新2-
まあ、いじくり回した後、「realStorageUnits」ディレクティブのようなWindowsバージョンのNet-SNMPのようには見えません。ディレクティブを含めると、SNMPの起動時に警告が表示されます。バージョン5.5、5.6、5.7を試しました。 Windowsで16+ TBボリュームを報告するためにSNMPを取得する方法をここで見つけた人はいますか?
しばらく前に、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エージェントを拡張して、一部のOIDに対するMicrosoftの制限を回避します。私はそれをZenossと一緒に使用して、より正確なCPU使用率とストレージ数を取得し、これが問題を回避する可能性は十分にありますが、確実には言えません。