目次


IBM Tivoli Monitoringによるデータセンター「グリーン」可視化ソリューションの開発

Agent Builderによる温度・電力監視エージェントの開発

Comments

はじめに

IBM Tivoli Monitoring (ITM) は、データセンターのインフラ全体の消費電力と温度、リソース状況を専用の監視エージェントや組み込みセンサーなどにより監視してエネルギー消費状況をリアルタイムに監視することができます。また、収集した監視データをTivoli Enterprise Portal(TEP - ITMの管理コンソール)に担当者ごとに必要な指標のみをわかりやすく表示したり、Tivoli Data Warehouse(ITMに同梱)を使って収集した監視データを蓄積し、Tivoli Common Reporting(TCR - ITMに同梱されているレポート・ツール)で監視項目の傾向を表示したりすることも可能です。これらの多様な監視、表現能力によりデータセンター全体のエネルギーとリソース使用状況およびその傾向を容易に把握することができ、エネルギー関連の問題の可能性についてデータセンターの管理者に注意を喚起して予防措置を取ることが可能になります。

監視データの収集は、OSやアプリケーション、インテリジェントPDU(intelligent Power Distribution Unit)やIBM BladeCenter(IBM Systems Director Active Energy Manager が必要な場合があります)などの監視対象ごとに用意されたITMの監視エージェントを使って行われますが、市販されている様々なタイプのセンサーや電源ユニットなどに対応するため、ITMは独自の監視エージェントを開発するための開発環境「Agent Builder」を提供しています。Agent BuilderはEclipseベースの開発環境で、ウィザード形式で監視方法や監視データの種類などを指定するだけで容易に監視エージェントを開発することができます。標準の監視エージェントではカバーできないセンサーやデバイスを開発した監視エージェントで補うことで、データセンター全体をきめ細かく監視することが可能となり、結果として、より正確なエネルギー消費状況を把握することが可能になります。

図 1. ITMはさまざまな監視エージェントを使ってデータセンター全体のエネルギー消費状況を可視化します
ITMはさまざまな監視エージェントを使ってデータセンター全体のエネルギー消費状況を可視化します
ITMはさまざまな監視エージェントを使ってデータセンター全体のエネルギー消費状況を可視化します

監視エージェントの開発はAgent Builderにより容易に行うことができますが、監視対象の特性およびTEPやTCRでの表現能力を最大限に活かした監視エージェントの開発を行うためには、いくつか考慮すべき点があります。本稿では、SNMPエージェントを備えたセンサーからデータを収集する監視エージェントを開発する際の考慮点について例を交えて解説します。

SNMPを使ってリモート監視を行うための考慮事項

データセンター内の電力・温度センサー、インテリジェントPDUなどからデータを収集する場合、SNMP(Simple Network Management Protocol)を使うケースが多く見られますが、それらのSNMPをサポートした機器(以降、SNMP機器と記述します)をITMの監視対象とする場合、インレット・アウトレットの形状、サポートされる定格出力や測定可能範囲、1台のコントローラーに接続可能な最大センサー数やセンサーの設置方法などの一般的なハードウェアの観点だけでなく、機器に組み込まれているSNMPエージェントの仕様から生じるソフトウェアの観点からの考慮を行うことが重要になります。ここでは、そのソフトウェアの観点からの考慮点について解説します。

1つ目のポイントとして、監視対象のSNMP機器が監視要件に必要なデータを提供しているか、あるいは収集したデータを再計算することにより監視要件を満たすことができるか、という点です。1つのOIDで監視要件を満たすデータを取得できる場合は、Agent BuilderでそのOIDを指定するだけで監視エージェントを作成することができます。必要な監視データが単一のOIDで提供されない場合、複数のMIB情報を再計算(四則演算)して監視データを生成できるかを確認する必要があります。Agent Builderでは、収集した複数のMIB情報をもとに四則演算を行い、その結果を監視データとして定義することが可能です。従って、収集したデータから必要な監視データを生成できれば、監視対象として選択することができます。しかし、いずれの方法でも必要な監視データを得られない場合、別のSNMP機器を選定するか監視要件の見直しが必要となります。

2つ目のポイントは、監視対象のSNMP機器が期待する監視間隔を維持できるかという点です。従来のITシステムの監視とは異なり、外部センサーによるリモート監視では、実アプリケーションに与える影響が低い(あるいは、まったく影響を与えない)ため、比較的短い間隔での監視が期待されます。一方で、最近のセンサーは、アラートの設定やセンサー名の設定などの管理を独自のWeb管理インターフェースで行えるように設計されていたり、最低限の処理能力しか持たないハードウェアが搭載されていたりする場合があります。これらの理由から、機器に組み込まれているSNMPエージェントのレスポンス性能が必ずしも監視間隔の要件を満たすとは限りません。また、センサーからの情報は、MIB定義の中で配列構造として定義されることが多く、機器がサポートするセンサー数によっては、一度に数百のMIB情報を配列として同時に返すような機器もあります。そのため、1回のデータ取得に数十秒かかるようなSNMPエージェントも存在します。

このSNMP機器のレスポンス性能は、監視エージェントの設計とも強く関連します。一般的に、監視に必要なMIB情報のみを取得するようにし、かつ、SNMP機器への監視の間隔を必要以上に短くしないことが重要となります。また、後述するTEPやTCRで可視化する際に必要となる最低限のOIDのみを取得するように監視エージェントを設計することも重要な考慮点となります。

結論として、監視対象とするSNNP機器のMIB定義およびパフォーマンス性能が監視要件に対して十分かを考慮して機器の選定をすること、あるいは、SNMP機器の性能にあった監視要件を定義することが安定した監視を行う重要な要素となります。

監視エージェントを設計する際の考慮事項

Agent Builderで開発したエージェントの監視データがITMでどのように利用できるかは、そのエージェント開発時に定義する属性(監視項目)や属性グループによって決定されます。例えば、TEPやTCRでどのようなグラフとして表示できるか、監視データがデータ・ウェアハウスにどのように蓄積されるのか、などが決定されます。そのため、エージェントを設計する際には、可視化の要件を明確にしておくことが重要となります。ここでは、エージェントの監視属性の定義と可視化の関係についての考慮点を解説します。

エージェントには1つ以上の「属性グループ(Attribute Group)」を定義することが可能で、それぞれの属性グループは1つ以上の「属性(Attribute)」から構成されます。この属性グループと属性の関係は、プログラミング言語における構造体とメンバーの関係のイメージとなります。各属性には名前やデータ型などが定義されます。

「データ・ソース(Data Source)」は監視データを取得するための手段で、Agent BuilderではSNMP以外に、ログファイル、スクリプト、WMI、JMXなどからデータを取得するデータ・ソースが提供されています。エージェントは、このデータ・ソースから取得したデータを整形して、属性グループの各属性にマップすることで、ITM環境で利用する監視データとします。

これらのマッピングや整形の方法はデータ・ソースのタイプによって異なりますが、Agent Builder ではウィザードにより設定することが可能です。例えば、ログファイルやスクリプトを利用するデータ・ソースでは、取得した文字データを区切り文字を利用して分割し、分割したデータをそれぞれの属性に割り当て、それらの属性を1つの属性グループとすることが可能です。また、SNMPデータ・ソースの場合、1つのOIDを1つの属性として定義し、それら要件に応じてまとめたものを属性グループとすることが可能です。

Agent Builderで提供されるMIBブラウザを利用すると、OIDを指定するだけでMIB定義に基づいた属性の定義を自動的に生成することができます(手動で設定することも可能です)。これを監視要件に基づいて属性グループごとに割り当てることで、エージェントの監視データ構造が定義できます。

図 2. 属性グループ(outletTable)と属性(outletIndex, outletLabel, 以下すべて)
属性グループ(outletTable)と属性(outletIndex, outletLabel, 以下すべて)
属性グループ(outletTable)と属性(outletIndex, outletLabel, 以下すべて)

(この資料では英語の画面イメージを使っていますが、ITMのバージョンによっては日本語で表示されます。説明中の用語は便宜上、日本語と英語の両方を記述しています。)

ITMでは、監視データはこの属性グループという単位で管理されます。監視データをTEP上に表示するために、この属性グループ単位でのクエリーが作成され、そのクエリーをもとに1つのビュー(表、円グラフ、棒グラフ、折れ線グラフなど)を作成することになります。

以下の2つのケースは、属性グループの定義の違いがTEPにどのように影響するかを説明しています。

ケース1:複数の属性を1つの属性グループにまとめて定義した場合

Agent Builderで3つの属性 (sysDescr, sysUpTime, sysName) を1つの属性グループ system として定義します。

図 3. 属性グループの定義(Agent Builder)
属性グループの定義(Agent Builder)

上記のように定義したエージェントの場合、TEPでは属性グループ system というノードが作成されます。パフォーマンス オブジェクト状況(Performance Object Status)は、データ・ソースの健全性を表示するためのもので、エージェントを作成時にAgent Builderによって自動的に生成されます。

図 4. TEPでのナビゲーター・ツリー
TEPでのナビゲーター・ツリー
TEPでのナビゲーター・ツリー

属性グループ system に対するクエリーの結果を表形式で表示すると、定義した各属性がそれぞれのカラムに対応しています。

図 5. TEPに監視グループ system の監視データを表示
TEPに監視グループ system の監視データを表示
TEPに監視グループ system の監視データを表示

ケース2:複数の属性を別の属性グループとして定義した場合

Agent Builderで3つの属性 (sysDescr, sysUpTime, sysName) を別の属性グループとして定義します。

図 6. 属性グループの定義(Agent Builder)
属性グループの定義(Agent Builder)

上記のように定義したエージェントの場合、TEPでは各属性グループが別々のノードとして表示されます。

図 7. TEPでのナビゲーター・ツリー
TEPでのナビゲーター・ツリー
TEPでのナビゲーター・ツリー

ケース1では1つの属性グループにすべての監視データが表示されていましたが、このケースでは、属性グループの定義に従ってそれぞれの別の属性グループ(ノード)に表示されます。

図 8. TEPに属性グループ sysDescr の監視データを表示
TEPに属性グループ sysDescr の監視データを表示
TEPに属性グループ sysDescr の監視データを表示
図 9. TEPに属性グループ sysName の監視データを表示
TEPに属性グループ sysName の監視データを表示
図 10. TEPに属性グループ sysUpTime の監視データを表示
TEPに属性グループ sysUpTime の監視データを表示
TEPに属性グループ sysUpTime の監視データを表示

繰り返しになりますが、ITMのエージェントは属性グループごとにクエリーを生成するため、複数の属性を1つのビュー(表、円グラフ、棒グラフ、折れ線グラフなど)として表示するためには、それらの属性が同じ属性グループに定義されている必要があります。つまり、1つのビューに表示する監視データ(属性)は、Agent Builderでデータ・ソースを定義する際に同じ属性グループに割り当てる必要があります。同様に、監視データをデータ・ウェアハウスのデータベースに蓄積する場合、その制御(履歴データをとる・とらない、収集間隔など)は属性グループ単位で行われます。そのデータは、1つの属性グループがRDB上の1つテーブルとして対応づけられます(属性はテーブル・カラム、監視データはレコードに対応します)。

複数の監視属性のデータを1つのビューに表示させる方法はありますが、ビューを設定する際にいくつかの追加作業が発生します。具体的には、カスタム・クエリー(SQLのSELECT文に相当します)を作成して異なる属性グループのデータを1つにする操作が必要になります。カスタム・クエリーはTEPで複数属性グループの監視データをまとめて表示するだけであり、監視データ自体は引き続き別の属性グループとして管理されます。TCRでカスタム・レポートを作成する場合も同様です。必要なデータが格納されているテーブルをJOINして1つの結果を返すSQLを作成する作業が発生します。実際にはこれらの追加作業が発生するだけでなく、ITMサーバーおよびエージェントに本来必要のない負荷をかけることになります。

Agent Builderには、2つの属性グループをJOINして一つの属性グループにする機能も提供されていますので、監視要件に基づき慎重に属性グループの設計を行うことが監視システムを効率的に構築する重要な要素となります。

次に考慮すべき点として、データ・ソースの対象によって1回のデータ収集操作で複数行のデータが返る場合があることです。各行に含まれるデータが、それぞれ別の監視対象のデータを表す場合には、各行の監視データを区別して取り扱う必要があります。例えば、SNMPデータ・ソースで配列構造をもつMIB情報を取得する場合などがこのケースに当てはまります。監視用スクリプトが複数行からなる定形出力を行う場合も同様です。

このようなケースの場合、属性を定義する際にキー属性(Key Attribute)を設定することでTEPおよびTCRのカストマイズが容易になります。キー属性の定義方法をSNMPデータ・ソースで配列構造を持つMIB情報を収集するケースを例にとって説明します。

最初にAgent Builderで属性グループが複数行を返すことを指定します。この例ではPDUから各アウトレットの状況を収集するMIB情報を属性として定義しています。各アウトレットの状況がアウトレットの数(これがデータの行数になります)だけ返ってくることになります。

図 11. 複数行を返す属性グループであることを指定します(SNMP Data Source Informationから「Can produce more than one data row」を選択します)
複数行を返す属性グループであることを指定します(SNMP Data Source Informationから「Can produce more than one data row」を選択します)
複数行を返す属性グループであることを指定します(SNMP Data Source Informationから「Can produce more than one data row」を選択します)

続いて複数行の監視データを区別するために、1つ以上の属性に対してキー属性を指定します。図12の例では、属性(OutletIndex)をキー属性に設定しています。通常、MIBファイルのインデックスがキー属性として設定されていますので、すでに設定されている場合もあります。

図 12. キー属性の定義(Key Attributeをチェックします)
キー属性の定義(Key Attributeをチェックします)

定義した属性グループ outletTable の監視データをTEPに表示させてみます(TEPにデータを表示させるためにはエージェントのビルド、導入イメージの作成、導入作業が必要です(後述))。ビューのプロパティで複数行を持つ属性であることを指定します。この例ではグラフのタイプに折れ線グラフを選択しています。

図 13. 複数行を持つ属性であることを指定します(Attribute(s) across multiple rowsを選択します)
複数行を持つ属性であることを指定します(Attribute(s) across multiple rowsを選択します)
複数行を持つ属性であることを指定します(Attribute(s) across multiple rowsを選択します)

この結果、アウトレットごとに折れ線(この例ではoutletPowerFactorをプロットしています)がグラフ上に表示されます。

図 14. 複数行を返す属性グループをTEPに表示させた例
複数行を返す属性グループをTEPに表示させた例
複数行を返す属性グループをTEPに表示させた例

このキー属性はTCRのカスタム・レポートを作成する際のSQLでWHERE文節として利用することも可能です。

エージェントを作成する場合には、収集した監視データをどのように利用するかを考慮しながら、エージェントの設計を進めていく必要があります。また、履歴データを利用する場合は、属性グループ単位でデータベースに蓄積されることを考慮した上で属性グループを定義することが求められます。これらの点を考慮することで、収集した監視データを利用しやすくなるだけでなく、監視システム全体の負荷を軽減することが可能になります。

インテリジェントPDUを監視するエージェントの開発

Agent Builderでエージェントを開発する一連の手順を説明します。ここでは、インテリジェントPDUから電力情報を取得するエージェントを開発する例を紹介します。(ここではRaritan社製のPDUを使った例を記述していますが、その会社、製品を推奨するものではありません。)

作成するエージェントの要件

  • アウトレットごとの電流、電圧、消費電力などのMIB情報をSNMPデータ・ソースで取得
  • アウトレットのインデックス番号(outletIndex)をキー属性にする
  • 複数行のMIB情報を返す属性グループとして定義

エージェントの作成

エージェントの作成はAgent Builderのウィザードを使って行います。Agent Builderの導入および起動方法については、「Agent Builderユーザーズ・ガイド」を参照してください。

図 15. Agent Builderからウィザードを起動
Agent Builderからウィザードを起動
Agent Builderからウィザードを起動
図 16. ウィザード初期画面
ウィザード初期画面
ウィザード初期画面

任意のプロジェクト名を指定します。この名前はAgent Builder上での名前(Eclipseのプロジェクト名)で、作成されるエージェントには影響しません。また、必要に応じてディレクトリを指定してください。

図 17. プロジェクト名の指定
プロジェクト名の指定
プロジェクト名の指定

エージェントの基本情報を入力します。ここで指定する情報はITMの内部で使用されます。サービス名(Service Name)、企業ID(Company Identifier)、エージェントID(Agent Identifier)、表示名(Display Name)は、任意のものを指定できます(日本語は使えません)。ただし、企業IDとエージェントIDを合わせた文字数は11文字以下である必要があります。表示名(Display name)はTEPのナビゲーター・ツリーに表示されます(この名前はTEP上で変更することができます)。製品コード(Product Code)は、K00からK99 の間の値を指定します。この製品コードは、ITMがエージェントを識別するコードとして使用され、ITM環境内でユニークである必要があります。言い換えると1つのITM環境に100種類のエージェントを作成することができます。

複数インスタンスのサポート(Support multiple instances of this agent)をチェックすると、導入した1つのエージェントで複数の監視対象を監視することができます(監視対象ごとに別のプロセスが実行されます)。例えば、2台の同じタイプPDUを監視する場合、監視対象ごとにエージェントのインスタンスを作成することで、1つのエージェントで2台のPDUを監視できます。

図 18. エージェントの基本情報の入力
エージェントの基本情報の入力
エージェントの基本情報の入力
図 19. 表示名(Display Name)はTEPにエージェント名として表示されます
表示名(Display Name)はTEPにエージェント名として表示されます
表示名(Display Name)はTEPにエージェント名として表示されます

エージェントが何を監視するかを指定します。SNMPを使って監視データを取得するので、「このエージェントは、外部データ・ソースからデータを収集します(This agent will gather data from an external data source)」を選択します。

図 20. 収集する監視タイプの指定
収集する監視タイプの指定
収集する監視タイプの指定

データ・ソースを定義します。ブランクのデータ・ソースリストが表示されますので「新規データ・ソース(New Data Source)」をクリックします。続いて表示される画面でSNMPを選択します。

図 21. データ・ソースの作成
データ・ソースの作成
データ・ソースの作成
図 22. データ・ソースの選択
データ・ソースの選択
データ・ソースの選択

データ・ソースを選択するとMIBブラウザが起動されます。監視機器のベンダーから提供されているMIBファイルをMIBブラウザに取り込みます。

図 23. MIBファイルの取り込み(Import MIBをクリックします)
MIBファイルの取り込み(Import MIBをクリックします)
MIBファイルの取り込み(Import MIBをクリックします)

MIBファイルを取り込むと、MIBブラウザ上にOID情報が表示されます。監視に必要なOIDを選択すると、データ型や名前、OIDなどを自動的にエージェントの属性として定義してくれます。MIBファイルがない場合や、MIBファイルをうまくインポートできない場合などは、直接 OIDやその属性の情報を入力することも可能です。

今回使用した機器のMIB定義では、監視要件となる各アウトレットでの電力関係の値は配列構造 (SequenceOf) をもつOID 1.2.6.1.4.1.13742.4.1.2.2 (outletTable)として定義されています。この例では、その監視対象となるプライベートMIBを選択しています。

図 24. OID(outletTable)の選択
OID(outletTable)の選択
OID(outletTable)の選択

続いて作成するエージェント(正確にはデータ・ソース)が動作するプラットフォームを指定します。エージェントをビルドして導入イメージを生成するときに、ここで指定したプラットフォームの実行バイナリがパッケージされます。作成したエージェントを導入するプラットフォームのタイプを選択(複数選択可能)してください。

図 25. プラットフォームの選択(この例ではWindowsを実行環境として指定しています)
プラットフォームの選択(この例ではWindowsを実行環境として指定しています)
プラットフォームの選択(この例ではWindowsを実行環境として指定しています)

これでデータ・ソースの作成が完了です。先ほど指定したOID (outletTable)とその子OIDがエージェントの属性として定義されています。表示されている内容を確認したら、完了(Finish)をクリックします。Agent Builderの画面に戻ります。

図 26. 作成されたSNMPデータ・ソース
作成されたSNMPデータ・ソース
作成されたSNMPデータ・ソース
図 27. Agent Builder
Agent Builder
Agent Builder

最後に図11と図12で解説した手順で属性「outletIndex」をキー属性として設定します(使用するMIBファイルによっては、すでにキー属性として設定されている場合もあります)。

もし必要なデータをつくるために四則演算が必要な場合には、Agent Builder(図27)の「データ・ソース(Data Sources)」タブで対象のデータ・ソースを右クリックして、派生属性(New Derived Attribute)を作成します。下記の例では、MIB情報から得られた電圧、電流、力率を掛けることにより電力を計算し、その結果をcalcPowerという新しい属性に割り当てています(図28)。

図 28. 派生属性の定義
派生属性の定義
派生属性の定義

これでエージェントの定義は完了です。定義した内容を保管してください。

エージェントの導入パッケージの生成

作成したエージェントの定義から、エージェントを導入するための導入パッケージの生成方法を解説します。この手順は次の2つのステップから構成されます。

  1. インストーラー定義の作成(Agent Builder上にプロジェクトが生成されます)
  2. 導入パッケージの生成

インストーラー定義の作成

作成したエージェントの定義ファイル(itm_toolkit_agent.xml)を右クリックして、表示されるメニューからエージェントの生成(Generate Agent)をクリックします。

図 29. エージェントの生成
エージェントの生成
エージェントの生成

エージェントの生成方法を選択します。ここではソリューション・インストール・パッケージ(Solution Install Package)と呼ばれるGUIベースの導入パッケージを作成する方法を選択します。開発環境などのようにAgent Builder とITMサーバーが同じマシン上で動作している場合、導入パッケージを生成せず、作成したエージェントを直接ローカルのITM環境へ適用することも可能です。詳細は、Agent Builderユーザーズ・ガイドを参照してください。

図 30. エージェント生成方法の選択
エージェント生成方法の選択
エージェント生成方法の選択

続いて表示される画面でAgent Builder上のプロジェクト名(Project Name)、次の画面でコンポーネントの説明(Component Description)を指定します。いずれも任意の文字列を指定できます。この手順により、エージェントのイメージが含まれたプロジェクトがAgent Builder上に生成されます(図31)。

図 31. インストーラー定義の生成(完了した状態)
インストーラー定義の生成(完了した状態)
インストーラー定義の生成(完了した状態)

導入パッケージの生成

生成したインストーラー定義のプロジェクトを選択し、ソリューション・インストール・イメージ(導入パッケージ)の生成を行います。

図 32. 導入パッケージの生成
導入パッケージの生成
導入パッケージの生成

ウィザードが起動されますので、画面の指示に従って必要な情報を入力します。画面イメージ(Splash screen image)を指定する必要がありますが、これは生成されたインストーラーを起動した時に表示されるスプラッシュ画像になります。ウィザードを完了すると導入パッケージ関連のファイルが、指定したディレクトリの配下に生成されます(図33)。

図 33. 導入パッケージの生成(CD_ROOTというディレクトリ配下にファイルが生成されます)
導入パッケージの生成(CD_ROOTというディレクトリ配下にファイルが生成されます)
導入パッケージの生成(CD_ROOTというディレクトリ配下にファイルが生成されます)

エージェントの導入

作成したエージェントの導入および構成を行います。エージェントの導入は次の4つのステップから構成されます。導入の順序は任意ですが、すべてが完了しないとTEPに収集した監視データが正しく表示されません。ITMのコンポーネントが別々のシステムで動作している場合、それぞれで導入プログラムを起動して必要なコンポーネントを導入する必要があります。

  • エージェントの導入: エージェントを導入します
  • TEMSサポート・ファイルの導入: 監視属性、属性グループの定義をTEMSに導入します
  • TEPSサポート・ファイルの導入: 監視属性、属性グループの定義をTEPSに導入します
  • TEPサポート・ファイルの導入: 監視属性、属性グループの定義をTEPに導入します

注意:TEMS/TEPSのサポート・ファイルの導入は、導入対象のTEMS(Tivoli Enterprise Management Server)またはTEPS(Tivoli Enterprise Portal Server)が起動されている必要があります。

生成した導入パッケージのCD_ROOTディレクトリに導入プログラムがありますので、上記の各システムでエージェント導入プログラムを起動します。例えば、Windowsに導入する場合はsetupwin32.exe を実行します。実行後、導入するためのウィザードが起動されます。導入中にどのコンポーネントを導入するかを指定する画面が表示されます(図34)。導入プログラムを起動したシステムで実行されているITMのコンポーネントを指定してください。必要なコンポーネントが導入されます。なお、「Perform a local install of the solution on this machine」がエージェントの導入を意味します。

図 34. 導入するコンポーネントを選択する画面
導入するコンポーネントを選択する画面
導入するコンポーネントを選択する画面

エージェント導入後は、通常のITMエージェントと同様に構成、起動、停止を行うことが可能です。エージェントの導入および構成の詳細は、「ITMインストールおよび設定ガイド」を参照してください。

エージェントの動作確認

エージェント起動後、しばらくするとTEPに2つの属性グループが表示されます。ひとつは「Performance Object Status」属性グループで、作成したエージェントのデータ・ソースのステータスを表示します。NO ERROR と表示されていれば正常です(図35)。

図 35. 「Performance Object Status」属性グループ

もうひとつは「outletTable」で、作成したエージェントのデータ・ソースに定義した属性グループです。OutletTable OIDの子OIDがテーブルビューでの各カラムとして表示されます(図36)。outletTableというノード名がわかりにくい場合などは任意の表示名に変更することも可能です(ノード名を選択して右クリック)。

図 36. 「outletTable」属性グループ

まとめ

IBM Tivoli Monitoring(ITM)はIBMの代表的なシステム監視製品です。多様な監視エージェントが提供されており、データセンター内の様々なリソースを一元管理することができます。これに2008年8月、IBM Tivoli Monitoring for Energy Managementがリリースされたことにより、従来のリソース監視に加え、「エネルギー」という観点からの監視が可能になりました。

Agent Builderは、この多様性をさらに拡張する強力なツールです。また、高度なスキルなども必要とせず、グラフィカル・インターフェースを使って簡単にエージェントを開発することができます。ぜひこのシンプルで強力な監視エージェント開発環境を体感していただき、ITMの新たな価値と可能性を感じていただければ幸いです。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps, セキュリティ
ArticleID=343499
ArticleTitle=IBM Tivoli Monitoringによるデータセンター「グリーン」可視化ソリューションの開発
publish-date=10102008