Cisco Prime Performance Manager 1.4 統合開発者ガイド
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年5月29日
章のタイトル： グループ レポートの作成
グループ レポートの作成
次の各トピックでは、グループ レポートの作成方法について説明します。
•
「コンテキスト」
グループ レポートの概要
グループはオブジェクトをフィルタリングするために Prime Performance Manager で使用される構造です。フィルタはオブジェクトのスタティックなリストまたは現在のコンテキストに含まれる属性のリストで機能するアルゴリズムです。グループの構文は次のとおりです。
• id：id は、グループの作成時に Prime Performance Manager によって割り当てられます。これは、必須の sgmid でグループを一意に識別します。
• Editable：（true または false）false の場合グループは変更できません。これは高度な Prime Performance Manager の機能で使用されるためにインストール パッケージで提供されるシステム レベルのグループを対象としています。true に設定した場合、適切な権限を持つユーザはグループを編集してフィルタリングの動作を変更できます。
• Enabled：（true または false）false に設定するとこのグループは発信者にデータを返しません。true に設定した場合、グループは入力データを処理し、適切な値を返します。
• Name：グループの作成者によって割り当てられ、グラフィカル ユーザ インターフェイスに表示される名前です。
• Algorithm：現在の行をグループの処理に含める必要があるかどうかを指定するためにグループが現在のコンテキストで変数を使用する方法を定義します。アルゴリズムでは Prime Performance Manager のレポート構文を使用します。レポートの定義に使用される同じ演算子およびマクロがアルゴリズムでも使用可能です。アルゴリズムの最終的な出力は、true または false の値である必要があります。
• Objects：Objects は、Prime Performance Manager 内のオブジェクトをマップする完全修飾ドメイン名（FQDN）のスタティックなリストです。FQDN は、次の例のように REST API インターフェイスに指定されるのと同じ方法で指定できます。
このリストにオブジェクトが含まれることによってグループがポジティブ応答を渡すため現在の行はグループの処理に含まれます。
Objects と Algorithm の構造は OR 関係にあり、現在の行がアルゴリズムまたはグループのオブジェクト グループに一致する場合にポジティブ応答が生成されます。
• Type：グループに渡されるデータにタイプ タグを追加します。たとえば、ネットワーク レベルでデータをフィルタするグループは Network のタイプを指定しますが、特定のリージョンにデータをフィルタリングするグループは Regional のタイプを指定します。この 2 つの区別はレポート データをレビューする場合に役立ちます。
• Usage：この構造は統計情報を処理する際にどの DBSummaryProcessor または AggregatedDBSummary がこのグループを使用する必要があるかを示します。これは、グループをしきい値の処理にのみ使用する場合は必要のないパラメータです。
• DBSummaryProcessor：このプロセッサは単一のデバイスのコンテキスト内のデータの集約に使用されます。たとえば、単一デバイスの gigabitethernet インターフェイスのすべてのトラフィックを集約できます。
• AggregatedDBSummary：このプロセッサは、複数のデバイスにわたってデータを集約するために使用されます。たとえば、複数のデバイスの 1 つのリージョンの gigabitethernet インターフェイスのすべてのトラフィックを集約できます。
コンテキスト
コンテキストはグループを呼び出すロケーションによって定義されます。グループは、以下のいずれかから呼び出されて実行されます。
• AggregatedDBSummary：グループが AggregatedDBSummary のコンテキストで使用される場合、アルゴリズムに使用可能な属性のリストが AggregatedDBSummary がリッスンしている DBSummaryProcessor で定義された属性で構成されます。
• DBSummaryProcessor：グループが DBSummaryProcessor のコンテキストで使用される場合、属性のリストが DBSummaryProcessor がリッスンしている ProcessPollResult で定義された属性で構成されます。
• ThresholdProcessor：グループが ThresholdProcessor のコンテキストで使用される場合、アルゴリズムに使用可能な属性のリストがしきい値のルートである DBSummaryProcessor または AggregatedDBSummary で定義された属性で構成されます。
グループ レポート
グループ レポートは複数のオブジェクトからの統計情報をグループ名およびグループ タイプで識別される単一行に集約します。グループ レポート タイプは InterDevice および IntraDevice です。
Intradevice レポートでは単一のデバイス内のオブジェクトだけを処理します。これらは DBSummaryProcessor 定義で識別できます。DBSummaryProcessor には、次の定義済みの列があります。
Intradevice 集約では、集約データは単一の DBSummaryProcessor セクションの範囲内で使用できます。DBSummaryProcessor セクションは、単一のデバイスの範囲内で実行されます。データはデータベースへの書き込みが可能で、他のレポート データと同様にタイムリーに記録できます。Intradevice レポート データは、関連するデバイスを処理する装置に保存されます。
InterDevice レポートは複数のデバイスの範囲全体のオブジェクトを処理し、AggregatedDBSummary 定義で識別されます。Interdevice レポートは複数デバイスを対象にできるため、すべてのレポートの処理およびデータ ストレージはゲートウェイで発生します。その装置の DBSummaryProcessors がデータを確定すると、データはゲートウェイに転送されます。ゲートウェイの AggregatedDBSummary はそのゲートウェイに定義されたすべてのグループをデータに適用します。
Interdevice の集約データは単一の DBSummaryProcessor セクション内で利用できないため、データは AggregatedDBSummary セクションによって処理されます。このセクションは DBSummaryProcessor の出力をリッスンします。データが複数のデバイスに集約されるため、AggregatedDBSummary は完全なデータ セットが利用可能になる時期を認識しません。AggregatedDBSummary に関わるデバイスは異なる時間でポーリングされることができます。したがって、Prime Performance Manager は指定された時間待機してすべてのデバイスがポーリングされたと想定します。これにより、データの生成が遅れる可能性があります。AGG_MAX_DELAY システム プロパティを使用して結果を確定し記録するまでに待機する時間の量を調整できます。デフォルトは次のとおりです。
この値を低く設定すると、いくつかのデバイスが指定した時間内にポーリングされていない可能性があり集約から除外されるので集約が不完全になることになる可能性があります。
AggregatedDBSummary レポートに対して、Count 変数が生成されるデータ行に追加されます。この変数は、集計されるデータに関連するオブジェクトの数をカウントします。オブジェクト数がわかっていると、複数のレポート間隔にまたがって集約されたデータを比較する場合に役立ちます。たとえば、ネットワーク内のすべての FastEthernet インターフェイスを集約するグループがあるとします。最初のレポート間隔では 15 台のデバイスで合計 30 の FastEthernet インターフェイスがありました。カウントは最初の間隔では 30 です。2 回目の間隔の間に 2 個の FastEthernet インターフェイスを持つ新しいデバイスが検出されました。2 回目の間隔のカウントは 32 でした。AGG_MAX_DELAY より大きな期間に対して 2 台のデバイスが到達不能になりこれらのデバイスにそれぞれ 2 個の FastEthernet インターフェイスがあった場合、これらのデバイスが到達不能な場合の期間の間隔ではカウントは 28 です。
（注） Count 変数はレポートを集約する DBSummaryProcessor には使用可能ではなく、これはそのカウント数が他の関連レポートを調べて判断することができるためです。
Intradevice レポートの例
interface.xml ファイルから抽出した次の例は、機能の一部とベスト プラクティスを示しています。次は、非集約レポートに対する通常の ProcessDBSummary の定義です。
次は、intradevice 集約 ProcessDBSummary の定義です。
重複した ifIndex、ifDescr、ifType、および txSpeed 値は混乱するおそれがあるため、これらの変数は集約に関係しません。上記の例では、以下の列が定義されました:
これらの列は intradevice 集約としてレポートを定義します。DBSummaryProcessor によってこれらのフィールドが参照される際に、集約として処理され、またキー フィールドとしてグループ名およびグループ タイプが送信されることがわかります。
次に示す CSV 定義は intradevice 集約に関連する next XML 定義です。
例では、CSV プロセッサが定義された GROUP_INTERFACE プロセッサをリッスンします。aggregate=true なので、CSV プロセッサは集約結果に基づいて CSV ファイルを生成します。集約された CSV レポート ファイルでグループ名がキー フィールドであり、そのためデータの一部として自動的に含まれているため、グループ名への参照は提供されません。
WebReport 定義は intradevice 集約内の next xml 定義です。次の例には、関係のある項目が含まれています。
• category：この例では、レポート数が膨大なため IntraDevice がツリー内でそれ自身のレベルに分割されています。より小規模なツリーでは、intradevice レポートおよび interdevice グループ レポートを同じツリー レベルに置くことができます。
• reportId：レポートの起動で問題が発生することがあるため、このパラメータを使用する場合は注意してください。通常のレポートから切り離してグループ レポートを制御し、interdevice レポートを intradevice レポートから指定するために、各レポート タイプの reportId が一義的である必要があります。Prime Performance Manager インターフェイスでは、個々の webreports の適切なエントリを指定するために interface.xml ファイルのポーリング構造内に次の 3 つの reportid が指定されています。
• context：ナビゲーション ツリーの [Grouped Reports] 分岐の下にレポートを置くことを可能にします。「Group」は [Grouped Reports] ツリー内のレポートの位置を決めるインジケータです。
• baseTable="GROUP_INTERFACE"：他のレポートと同様に、webreport が基づく DB テーブルを指定する必要があります。
• Link：webreport 内に表示するためのサマリー テーブル、tableview、および凡例へのハイパーリンクを指定します。
Interdevice レポート
interface.xml ファイルからの次の例は、interdevice 機能とベスト プラクティスを示します。次のセクションは、AggregatedDBSummary セクションのデータの元になる非集約レポートに対する ProcessDBSummary 定義です。
次の例は、interdevice 集約定義に対する AggregatedDBSummary セクションです。AggregatedDBSummary は INTERFACE ProcessDBSummary からデータを入力としてリッスンします。
上記の例で、以下の項目が INTERFACE 定義から削除されました。
重複した ifIndex、ifDescr、ifType、および txSpeed 値は混乱するおそれがあるため、これらの変数は集約に関係しません。AggregatedDBSummary コードによってキー フィールドとしてグループ名とグループ タイプが送信されます。さらに、カウント フィールドが組み入れられます。このフィールドには、集約に関係したオブジェクトの数が含まれます。7 個のインターフェイスがグループのフィルタリングを通過した場合、count 変数は 7. に設定されます。
CSV 定義は next interdevice 集約 xml 定義です。
上の例では、CSV プロセッサが定義された AGG_INTERFACE プロセッサをリッスンします。aggregate="true" 属性によって、CSV プロセッサが集約結果に基づいて CSV ファイルを生成します。
集約されたレポート CSV ファイルでグループ名がキー フィールドであり、データに自動的に含まれているため、グループ名への参照は提供されません。
WebReport 定義は next intradevice 集約 xml 定義です。関係する項目は次のとおりです。
• category：この例では、膨大なレポート数のため InterDevice はそれ自身のツリー レベルに配置されます。より小規模なツリーでは、intradevice および interdevice グループ レポートを同じナビゲーション ツリー レベルに置くことができます。
• reportId：レポートの起動時の問題が発生する可能性があるため、このパラメータの使用には注意が必要です。通常のレポートからグループ レポートを、intradevice レポートから interdevice レポートを切り離して制御するために、各レポート タイプの reportId が一義的である必要があります。インターフェイスの例では、個々の Web レポートの適切なエントリを指定するために interface.xml ファイルにポーリング構造上の次の 3 つの reportid が追加されます。
• context：Prime Performance Manager ナビゲーション ツリーの [Grouped Reports] セクションの下にレポートを置くことを可能にします。「Group」は、この設定を行うインジケータです。
• baseTable="AGG_Interface"：すべてのレポートは webreport が基づく DB テーブルを指定する必要があります。
• Link：webreport 内に表示するためのサマリー テーブル、tableview、および凡例へのハイパーリンクを指定します。
• Count：AggregatedDBSummary ベースの Web レポートに追加する追加フィールドです
interdevice グループ レポートの例を次に示します。
フィードバック