サポートセンターホーム


NetAppAPIデータ収集

概要

LogicMonitorを使用すると、次のXNUMXつの方法でNetAppデータを収集できます。

  1. パフォーマンスデータ
  2. XMLをリクエストする
  3. API呼び出し

注意: NetAppストレージアレイもSNMPに応答し、一部のデータソースはSNMPを使用してNetAppデータを収集します。 この記事では、NetAppAPIを使用してデータを収集する方法についてのみ説明します。

パフォーマンスデータ

Performance Data Collectionは、指定されたオブジェクトタイプに対してperf-object-get-instances要求を行います(プロセッサ 下の画像)、提供されたインスタンス識別子を使用します(##ワイルドバリュー## 以下の画像では、実行時にActive Discoveryで見つかったインスタンスに置き換えられ、そのオブジェクトのすべてのパフォーマンスカウンターの結果セットを取得します。

UUIDではなくインスタンスフィールドでのみインスタンスを識別できることに注意してください。したがって、このデータ収集方法は、一意のインスタンス名が使用可能な場合にのみ適しています。

たとえば、次の画像で構成されたデータ収集は、プロセッサクラス(processor7、processor1など)の各インスタンスがデバイスごとに一意であるため、2モードのNetAppで正しく機能します。 ただし、クラスターモードでは、クラスター内の異なるノードに、UUIDによって区別される複数の「processor1」オブジェクトが存在する場合があります。 パフォーマンスデータ収集メソッドは、UUIDではなくインスタンス名でのみオブジェクトを要求できるため、それらを区別することはできません。


パフォーマンスデータ

データポイント カウンター フィールドは、要求されたオブジェクトの種類に対してNetAppAPIによって返されるカウンターの名前である必要があります。 パフォーマンス収集メソッドは自動的に集計を使用します。XNUMXつのインスタンスをマスターとして指定し、XNUMX回の呼び出しですべてのインスタンスに関するデータを収集します。 他のインスタンスの個々のインスタンスコレクションは、集約キャッシュをクエリします。

API呼び出し

このメソッドを使用すると、NetApp API呼び出しを指定でき、返されたデータを次のように解釈します。 影響により 属性、または収集可能なデータポイントである値を持つ要素として。 たとえば、NetAppクラスターのボリュームパフォーマンス情報を収集するには、次の構成を使用できます。


API呼び出し

  • API:使用するAPIの名前。 この場合のPerf-object-get-instances、パフォーマンス情報を取得するためのクラスターモードAPI呼び出し
  • インデックスプロパティ: これにより、返されるXMLのどこに実際の結果があるかが識別されます。 上記の例では、返されるXMLには インスタンス 素子。 コレクターはこのオブジェクトのサブ要素をウォークし、 カウンター サブ要素。 これは、コレクターが情報を取得する場所です(  影響により 要素はそのレベル内、またはカウンター要素)
  • 集約属性:これは、返されたXML結果内で特定のインスタンスを見つける方法を識別します。 インスタンスを識別する名前/値のペアを指定します。したがって、同じコンテキスト内のすべての名前/値のペアは同じインスタンスに関連します。 上記の応答のデータには以下が含まれるため:instance_uuid 7c2ff26c-bd32-4993-bcff-581727bbd522 internal_msgs459431指定 instance_uuid コレクターは、その要素の値にインスタンスが含まれることを知ることができます ワイルドバリュー、ActiveDiscoveryによって発見されました。 このフィールドは、コレクション集約を使用する場合に必要です。コレクターがクラスのすべてのインスタンスを一度に収集し、それらをローカルにキャッシュしてから、個々のコレクションがキャッシュにクエリを実行する場合です。
  • パラメーター:これらは、指定されたAPI呼び出しに必要なパラメーターです。 たとえば、パフォーマンスAPI呼び出しには オブジェクト名 パラメータ。パフォーマンス情報が要求されているオブジェクトの種類を識別します。 また、呼び出しでクエリを実行する7つまたは複数のインスタンスの識別子も必要です。 これは、この呼び出しのネストされたオブジェクトです:2c26ff32c-bd4993-581727-bcff-522bbdXNUMX。 これをパラメーターとして追加するには、上記のようにレベルをピリオドで区切ります。 集約コレクションを使用するには、「*」を使用できます。これは、コレクターが既存のすべてのインスタンスIDに置き換えます。

XMLをリクエストする

Request XMLコレクションメソッドを使用すると、NetApp API呼び出しを送信し、結果を解釈できます。 データ収集の集約(一度に複数のオブジェクトを照会する)と、集約されていない収集(各オブジェクトに対して個別にAPI呼び出しを発行する)をサポートします。 最も単純なケースは、非集約コレクションを使用することです。この場合、各収集タスクは単一のインスタンスのデータを収集します。 これには、XML本文で収集するオブジェクトを指定するために## WILDVALUE ##トークンを使用する必要があります。 たとえば、データソースのインスタンスがボリュームUUIDである場合、次のデータソースを使用してそれらのボリュームに関するデータを収集できます。

XMLをリクエストする

Result Locatorは、NetAppXML応答で結果オブジェクトを見つけるために使用されます。 形式は「resultLocator [:: attributeLocator]」です。 resultLocatorフィールドは通常、サブオブジェクトの配列を指し、データポイントのカウンター値はこの配列を基準にしています。 非集約コレクションでは、この配列の最初のオブジェクトにデータが含まれていると見なされます。 たとえば、上記のデータソースからのクエリは、次のような結果を返す場合があります。

53b10a8d-255c-4be9-9078-78b5d9d98e68 server2_root ccb2d972-7d75-11e3-91bb-123478563412 502 566 96 <... snip .....>

Result Locatorを「attributes-list」に設定すると、そこに含まれるリスト要素(volume-attributes)に収集されているデータが含まれていることを示します。 集約された収集を行っていないため、この場所の最初の要素(「ボリューム属性」コンテナー)に関連データが含まれていると想定されます。 したがって、抽出される実際のデータへのパス(「volume-inode-attributes.files-total」など)は、そのオブジェクトを基準にしています。 集計データ収集を行うには、XMLクエリで複数のオブジェクトに関するデータを要求する方法を理解する必要があります。 XMLコレクションメソッドで使用されるAPI呼び出しには、XNUMXつの一般的なクラスがあります。クエリ属性を使用して返すオブジェクトを選択するクラスと、返すオブジェクトを明示的に列挙するクラスです。

クエリパラメータを使用してインスタンスを識別する集約コレクション

クエリパラメータを使用してすべてのオブジェクトを取得するAPI呼び出しを使用するには、通常、オブジェクトのセットを返すAPI呼び出しを作成するのは簡単です(特定の呼び出しの詳細については、NetApp SDKを参照してください)。 たとえば、すべてのボリュームの結果セットを取得するには、セレクターを使用せずにクエリを指定するだけです。

クエリパラメータを使用してインスタンスを特定する

上記のリクエストXMLの集計結果は、次のようになります。

53b10a8d-255c-4be9-9078-78b5d9d98e68 server2_root ccb2d972-7d75-11e3-91bb-123478563412 502 566 96 <... snip .....> 53b10a8d-255c-4be9-9078-1239876123311 server2_data ccb2d972-7d75-11e3-91bb-a5b7c9911111 502 566 96 <... snip .....>

上記のように、 結果ロケーター NetAppXML応答で結果オブジェクトを見つけるために使用されます。 形式は「resultLocator [:: attributeLocator]」です。 resultLocatorフィールドは通常、サブオブジェクトの配列を指し、データポイントのカウンター値はこの配列を基準にしています。 上記のデータソースでは、結果ロケーターは 属性リスト、したがって、後続の参照とクエリはそれに関連しています。 ザ・ インスタンスインデックス 集約されたクエリからインスタンスを分離するために使用されます。 これは、インスタンスを一意に識別するフィールドを指す必要があります– volume-id-attributes.instance-uuid、上記のデータソース。 このインスタンスに対してクエリされたすべてのデータは、一致するインスタンスインデックスを含むオブジェクトから収集されます。 (すなわち、 ボリューム属性 を含むオブジェクト volume-id-attributes.instance-uuid WILDVALUEと一致します。 インスタンス値 インスタンスインデックスを照合するために使用されるフィールドです。これは常に## WILDVALUE ##である必要があります。

API呼び出しがすべてのオブジェクト識別子を列挙せずに複数のオブジェクトの取得をサポートしている場合は、集約データ収集を有効にするために[一括リクエスト]チェックボックスを設定する必要がないことに注意してください。

列挙されたインスタンスを使用してデータを収集する集約コレクション

API呼び出しで、データを収集するインスタンスをリクエストで特定する必要がある場合、集約収集を行うには、LogicMonitorコレクターがすべてのインスタンスを列挙するクエリを作成する必要があります。また、XMLの構築方法を知っている必要があります。特定のAPI呼び出しのリクエスト。 たとえば、集約モードでボリュームパフォーマンスを収集するには、データを収集するすべてのボリュームインスタンスUUIDを一覧表示する必要があります。 次のデータソースはこれを実現します。

データを収集するためのインスタンスの列挙

  • 一括リクエストチェックボックス: これは、集約されたコレクションを有効にするために、可能なすべてのインスタンス値のリストを作成する必要があることをLogicMonitorコレクターに通知します。
  • 一括リクエストロケーター:これは、インスタンスのリストを挿入するリクエストXMLのどこに詳細を示します。 上記の例では、これはに設定されています instance-uuids :: instance-uuid。 これは、「instance-uuidsオブジェクト内のinstance-uuidフィールドにインスタンスを挿入する」ことを意味します。 これにより、次のようなリクエストが発生します。
インスタンスのワイルドバリュー1 インスタンス2のワイルドバリューインスタンス3のワイルドバリューインスタンスNのワイルドバリューボリューム
  • インスタンスインデックス 集約されたクエリからインスタンスを分離するために使用されます。 これは、インスタンスを一意に識別するフィールドを指す必要があります– volume-id-attributes.instance-uuid、上記のデータソース。 このインスタンスに対してクエリされたすべてのデータは、一致するインスタンスインデックスを含むオブジェクトから収集されます。 (すなわち、 ボリューム属性 を含むオブジェクト volume-id-attributes.instance-uuid WILDVALUEと一致します。 Bulk Request Locatorは複数レベルのオブジェクトをサポートし、二重コロン(“ ::”)を使用してインスタンスを囲む必要のある要素と、インスタンスの構築に使用される要素を指定することにより、XMLクエリ全体を構築できることに注意してください。 たとえば、リクエストXMLを次のように設定できます。
level1.level2 :: sub-level1.sub-level2

次に、コレクターは、level2要素内のXML要素level1を探します。 インスタンスごとに、level2要素内にあるsublevel1内にsub-level2のXMLフィールドを挿入します。 例えば

Instance1のWILDVALUE
      Instance1のWILDVALUE

NetAppデータ収集用のデータポイントの追加

ほとんどの場合、データポイントは、収集する値を含む名前でオブジェクトを指定するだけで定義されます。この値は、インスタンスインデックスを使用して結果ロケーターのコンテキスト内で収集されます。 たとえば、ファイルを収集するには、次の結果からプライベート使用値502を使用します。

502

カウンターvolume-inode-attributes.files-private-usedを使用して通常のデータポイントを作成するだけです。 ただし、XMLの結果が、収集する数値データが明確に名前が付けられたフィールドではなく、個別の名前と値のペアにあるオブジェクトを返す場合、このメソッドは機能しません。 たとえば、このクエリの結果は次のとおりです。

 ##ワイルドバリュー## システム

次のようになります。

avg_processor_busy 24045244730 cifs_ops 0

結果が互いに兄弟としての名前カウンターと値カウンターである場合、NetAppカウンターフィールドで値へのパスを直接指定することはできません。 (LogicMonitorは直接のXML応答にアクセスできません。それ以外の場合はXPath構造を使用してこのデータを取得できます。)これを回避するために、「name」と「value」の両方のサブを含むサブXML要素を処理する特別な処理があります。 -結果オブジェクトマップに属性を作成するための要素。 したがって、上記の出力は実際には次のように処理されます。

24045244730 0> / cifs_ops>

通常どおり収集を許可します。

記事上で