LogicMonitorが他のNetApp監視システムと異なる点のXNUMXつは（ホスト型監視であり、ACユニットから仮想化、OS、MongoDBなどのアプリケーションまで、データセンターにあるシステムの完全な配列を監視できることを除く）、デフォルトで「監視中」。
つまり、常にすべてを監視したいと想定しています。 （もちろん、特定のグループ、ホスト、またはオブジェクトの監視またはアラートをオフにすることもできます。）これはほとんどの場合に役立ちます。作成するとNetAppで新しいボリュームを検出し、読み取りと書き込みの待ち時間の監視を開始します。操作の数や種類など–これは、そのボリュームに問題がある場合（または他のグループが問題のストレージパフォーマンスを非難している場合）、あらゆる種類のメトリックの監視がすでに行われていることを意味します 問題–ストレージに問題があったかどうかを知るためのデータとアラートがあります。
ただし、これがうまく機能しない場合がいくつかあります。 NetAppディスクのパフォーマンスもデフォルトで監視しており、各ディスクの操作数とビジー時間を追跡しています。 ただし、大規模なNetAppを使用しているお客様には、多くの場合、数百のディスクがあり、それぞれをAPIクエリで監視します。 これは、ディスクのリバランスが必要な時期を特定するのに役立ちます（ビジー時間による上位10台と下位10台のディスクが大きく異なる場合）。また、ディスクのパフォーマンスは5分ごとにのみ監視します（ボリュームやPAMカードとは対照的です。より頻繁に監視されるもの）、これは明らかにNetAppデバイスのAPIサブシステムを過負荷にします。
収集プロセスを再開し、APIによる監視がボリュームのパフォーマンスのみであった場合、問題なく機能しました。NetAppからのAPIリクエストへの応答は約100ミリ秒でした。
ディスクリクエストが追加され始めたとき（そして、リクエストをずらして歪めたため、すべてが一度にヒットするわけではありません）–単一のクエリのAPI応答時間は最大40秒増加しました。
これにより、監視のバックログが発生し始め、より重要なボリュームパフォーマンスメトリックでデータが失われていました。
したがって、NetAppでケースを開く間、この問題を回避するために、暫定的に、物理ディスクのパフォーマンスの監視をデフォルトで無効にする可能性があります。