![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
JMXは、Javaプラットフォームに対して行われた人気の高い標準拡張であり、最新のNetwork Management Systems (NMS) を使用して装置、アプリケーション、およびサービスの管理、制御、およびモニターを行えるようにしてくれます。JMXによってソフトウェア・アプリケーション/サービスの管理が行いやすくなる様子を良く理解するために、(このシリーズの第2回で開発した) ClickMeterアプリケーションを、OpenNMS という実在のオープン・ソースNMSを使用してモニターすることにします。私がOpenNMSを選んだのは、誰にでも入手しやすく、また設計が単純になっているためです。しかも、他のNMS製品によって記述されている統合技法を適用することもできます。OpenNMSの詳細を探る前に、ほとんどのNMS製品に共通する設計要素および操作モデルを調べることにしましょう。
私たちはこのシリーズの第1回で、現代のネットワーキングの歴史を通観して、NMSの進化をたどりました。ネットワーク管理ユーザーにはさまざまな人たちがいますので (また、ソリューション・ベンダーの遺産もさまざまです)、現代のNMS製品は、ソフトウェア・システムの中で最も大規模で複雑なものになりがちです。例えば、分散したオペレーション・センターを介して通信ネットワーク装置を管理およびモニターする多国籍組織の場合、その要件は、同じ国または地方内の各地でvirtual private network (VPN)、PC資産、データ通信資産、およびアプリケーション・サーバーを管理する必要のある地域企業とは、著しく異なるはずです。
典型的なNMSは、数千、数万、あるいは数十万ものエンドポイント (ノード) を管理しなければなりません。NMSがターゲットとしている顧客は、中規模または大規模の組織となる傾向があります。これらの顧客のそれぞれが異なるやり方でビジネスを行っている可能性があるため、NMSは、顧客の多様な要求を満たすために、非常に柔軟な構成メカニズムおよびユーザー・インターフェースを備えていなければなりません。さらに、多くのNMSソリューションが、初めのうちは、プロプラエタリーなブラック・ボックス制御コンセントレーター・コンソールとして具体化されていたため (それが、過去のある時点におけるIBM、HP、Sunなどのベンダーのコア・コンピタンス事業となっていました)、そうしたシステムは複雑なものであると考えられがちです。そう考えると、典型的なNMSソリューションが高コストであることを正当化したくなるのも分かります。
OpenNMSはオープン・ソースの世界におけるユニークなソフトウェア・システムです。これは、複雑ではあっても柔軟性の高いNMSソリューションのための実行可能コードとソース・コードを、開発コミュニティーに無料で提供しようとする試みです。OpenNMSの最新バージョンのダウンロード・サイトなど、詳しい情報へのリンクは参考文献を参照してください。また、このシステムの起源については、補足記事「OpenNMSの歩み」を参照してください。
OpenNMSは、受け継ぐべき遺産なしに生まれたため (つまり、その生みの親は「ブラック・ボックス」ベンダーではないため)、かなり斬新な設計方法をとっています。OpenNMSは「ユーザー中心」のNMSであり、必要な機能を割り出すために単一の中心点として、標準的なネットワーク・マネージャー (あるいは、ネットワーク管理チーム) を設置しています。初期のチームの数人のメンバーはネットワーク管理コンサルタントであり、彼らは自分たちの知識を基に標準的な使用法を想定しました (つまり、典型的なネットワーク・マネージャーが管理するオブジェクト、タスク、およびワークフローに基づいて運用モデルを定義しました)。これに対し、いくつかの商用NMS製品は、多くの場合、ベンダーの遺産の影響から、装置、ネットワーク、あるいはソフトウェア・サービス中心になっています。
多くのNMS製品は、その適用分野、コード遺産、またはベンダーが異なっていても、概念レベルでは似た構成になっています。図1は、この共通構成を表すものです。
図1. NMSの概念的な構成
この構成は、一般的には3層構造になっています。前方の層は、管理される装置およびサービス、そのシステムを使用するユーザー、および外部システムからなるネットワークとインターフェースします。中間層には、NMSの機能セットを提供するロジックの多くが含まれています。後部の層は、データの持続および操作を担当します。
大量のデータと複雑な相互関係を、動的でしかも堅固な方法で追跡する必要があるため、NMSの後方層には、商用レベルで通用するリレーショナル・データベース管理システム (RDBMS) を配備せざるを得ません。
前面の層にあるモニター、管理、および制御用コンポーネントは、典型的には、NMSの運用中に実行しなければならない多くの並行タスクからなります。このコンポーネントは、アクティブなネットワーク・ディスカバリー、装置障害やサービスのポーリング、および装置、サービス、またはより上位レベルの分散エージェントからの非同期イベントのインターセプトまたは処理を担当します。このコンポーネントは、構成ロジックによって駆動される操作を実行し、NMSの中間層にロジック、ワークフロー実行プログラム、またはその他のカスタム・ロジックを保存します。
前面の層には、ユーザー・インターフェース・コンポーネントも含まれています。NMSには「ファット・クライアントGUI」インターフェース、およびカスタマイズしやすいWebベースのユーザー・インターフェースが含まれることがあります。この層にはレポート機能が含まれていて、ユーザー・インターフェースと対話し、リアルタイムのソフトコピー・レポートやバッチ式のハードコピー・レポートを作成します。
最初の層の外部インターフェース・コンポーネントは、ユーザーおよび/または外部システムへの通知を処理することができます。これはポケットベル呼び出し、Eメール、電話呼び出し、または外部管理システムに対する特定のイベントの形で行われます。APIおよび拡張プラグイン・インフラストラクチャーを利用すると、NMSをカスタマイズして他のシステムとインターフェースしたり統合したりすることができます。
中間層には、NMSのロジックが含まれています。これは、別個の機能セットと特性をNMSに与えます。よく見られる機能としては、在庫または資産管理、データの収集および分析、ユーザーまたは役割の管理、およびワークフローの管理/実行などがあります。
資産管理は、ほとんどのNMS製品の主要機能です。追跡対象となる項目は、NMSごとにかなり異なりますが、機器、回路、サーバー、インストール済みソフトウェア・サービスおよびアプリケーションなどがあります。このコンポーネントのユーザー・インターフェースおよびアプリケーション・ロジックは、管理対象となるさまざまな項目に柔軟に適応できるものでなければなりません。
データ収集および分析機能は、管理される装置およびサービスに関する現行統計および履歴統計を提供することができます。また、ネットワークおよびサブネットワークのパフォーマンス、装置/サービスの可用性などを明らかにする統計分析を提供することもあります。このコンポーネントはまた、カスタム・ワークフローを処理するためのワークフロー実行ロジックと情報のやり取りをすることもできます。
ユーザーおよび役割管理コンポーネントは、NMSへのさまざまなアクセス・レベルを設定できるようにします。多くの大規模ネットワークは、1つまたは複数のチームによって管理されます。ユーザーに割り当てられた役割は、カスタム・セキュリティー・ポリシー、カスタム・ワークフロー、およびイベント・エスカレーション・フローの設計と実装に使用することができます。
ワークフローの管理および実行機能は、持続時間の短い管理タスクと持続時間の長い管理タスクの両方を管理し、自動的に実行することができます。カスタム自動化ワークフローは、さまざまな組織の多様なビジネス要件にNMSを適用するために不可欠です。
すべてのNMSがこれらのコンポーネントのすべてを備えているわけではありませんし、NMSの中には、このほかに特殊なバリエーションを備えているものもありますが、NMSを構成する要素を概観するには、以上で十分であると思います。
図1 を参考にすることにより、参照構成とOpenNMSのアーキテクチャーとの間の具体的な対応を理解することができます。図2は、OpenNMSを構成するコンポーネントを表しています。
図2. OpenNMSのコンポーネント
後方層では、OpenNMSはPostgreSQL (参考文献を参照) をRDBMSとして使用します。前面の層では、Apache Jakarta TomcatのJSPおよびサーブレット・テクノロジー (参考文献を参照) を使用して、柔軟にカスタマイズできるユーザー・インターフェースを提供します。Perlベースのレガシー・ユーザー・インターフェースも使用することができます。いくつかの管理ユーティリティーは、UNIXシェル・スクリプトおよびPerlで書かれています。OpenNMSは、図1 のモニター、管理、および制御コンポーネントに対応する並行Javaタスクの組を使用して、この機能を提供します。図2では、これらの並行タスクを円で示してあります。
OpenNMSのモニター、制御、およびデータ収集機能は、デーモンと呼ばれる並行タスクのセットによって処理されます (BSD UNIX規約)。表1は、これらの並行管理タスクのコンパイルを表しています。これらのタスクは図2でも示されています。
表1. OpenNMSの並行管理タスク
| 並行タスク | デーモンの名前 | 説明 |
|---|---|---|
| アクション・デーモン |
actiond
| 発生したイベントに基づいて自動化されたアクション (ワークフロー) を実行する、自動アクション実行機能。 |
| コレクション・デーモン |
collectd
| 管理対象ノードからデータを収集します。 |
| 機能デーモン |
capsd
| 発見されたノードで機能検査を実行します。一般的には、既知のサービス・プロトコルをサポートするために、インターフェースのポートを検査します。 |
| DHCPデーモン |
dhcpd
| OpenNMSのためのDHCPクライアント機能を提供します。 |
| ディスカバリー・デーモン |
discovery
| 管理対象ネットワーク・ノードの初期ディスカバリーおよび実行中の通常ディスカバリーを行います。 |
| イベント・マネージャー・デーモン |
eventd
| 他の並行タスクから発信されたイベントを管理し、(RDBMSに) 保管します。 |
| 通知デーモン |
notifd
| ユーザーへの外部通知を実行します。 |
| 障害マネージャー・デーモン |
outaged
| それぞれの管理対象ノード/サービスに実行中の障害履歴ビューを提供するために、イベントを整理します。 |
| ポーラー・デーモン |
pollerd
| 運用状況を判別するために、管理対象ノード/サービスをポーリングします。 |
| RTCマネージャー・デーモン |
rtcd
| 管理対象ノード/サービスのユーザー定義カテゴリーに関する可用性情報を提供するために、リアルタイムでデータを収集します。 |
| SNMPトラップ・デーモン |
trapd
| SNMPトラップ (イベント) を処理します。 |
| しきい値サービス・デーモン |
threshd
| 指定のしきい値に達した属性値に基づいて管理対象ノード/サービスをモニターします。 |
OpenNMSの前面層では、特定の垂直アプリケーション・ドメインに関するシステムの適用は非常に単純明快です。JSPテクノロジーの柔軟性のおかげで、OpenNMSへのユーザー・インターフェースはJava開発者によって簡単にカスタマイズすることができます。また、JSPファイルおよび/またはサーブレット・コーディングを組み合わせることにより、新しいNMSアプリケーション・ロジックを容易に追加することができます。
OpenNMSは、管理対象装置/サービスのための堅固なSNMPサポートとして標準になりつつあります。SNMPは、管理可能装置/サービスに関する現行の業界標準です。この標準により、OpenNMSはTCP/IPネットワーク上のきわめて多様な既存装置を管理することができます。
SNMPの外部でも、OpenNMSは一般的に使用されるソフトウェア・サービス (FTP、ファイル・サーバー、データベース・サーバーなど) を検出および管理することができます。OpenNMSには、これを行うための (プロトコル・スキャン用の) サービスに特化したプラグインおよび (ポーリング用の) モニターの組が備わっています。新規プラグインおよびモニターを作成することにより、OpenNMSを拡張して、新規装置または (私たちのJMX対応ClickMeterアプリケーションを含む) サービスの検出およびモニターを行えるようにすることができます。
OpenNMSのディスカバリー・デーモン (discovery) は、管理対象ネットワークの初期および実行中のディスカバリーを行います。discovery は、ノードを発見すると (一般には、ICMP PINGを使用して行います)、そのノードがどのようなサービスをサポートするのかを機能デーモン (capsd) に問い合わせます。機能デーモンは、指定されたプロトコル・プラグインのセットを繰り返してサービスのサポートを検査します。新しいサービスをOpenNMSに適用させるためのカスタム・プロトコルは、簡単に書くことができます。そのためのステップは以下のとおりです。
-
org.opennms.netmgt.capsd.Pluginインターフェースを実装するクラスを作成します。このインターフェースは、特に、表2に示すように、プラグインが実装しなければならない3つのメソッドを備えています。
表2. org.opennms.netmgt.capsd.Pluginインターフェースのメソッド
| メソッド名およびシグニチャー | 説明 |
|---|---|
String getProtocolName();
| このプラグインの作成対象となっているプロトコルの名前を戻します。 |
Boolean isProtocolSupported(java.nnet.InetAddress address);
boolean isProtocolSupported(java.nnet.InetAddress address, java.util.Map properties);
| 必要に応じて与えられたパラメーターのプロパティー提供マップを使用して、そのプロトコルが指定されたInetAddress によってサポートされるかどうかを判別します。 |
- /etc/capsd-configuration.xmlファイル内にプロトコル・プラグイン定義を作成します。このファイルは、使用するプロトコル・プラグインを判別するために、始動時に
capsdによって読み取られるファイルです。
OpenNMSプロトコル・プラグインをコーディングおよび構成する方法については、この後すぐに詳しく説明します。
OpenNMSは、管理対象ノードにあるサービスを判別した後で、ポーラー・デーモン (pollerd) を使用して管理対象装置/サービスに対して定期的にポーリングを行って、それらが作動可能になっていることを確認します。pollerd は、指定されたポーラー・モニター「プラグイン」のセットを繰り返すことにより、個々のサービス・ポーリングを行います。新規プロトコルのためのポーラー・モニターを作成するためには、次のようにする必要があります。
-
org.opennms.netmgt.poller.ServiceMonitorインターフェースを実装するクラスを作成します。このインターフェースは、特に、表3に示すように、モニターが実装しなければならない5つのメソッドを備えています。
表3. org.opennms.netmgt.poller.ServiceMonitorインターフェースのメソッド
| メソッド名およびシグニチャー | 説明 |
|---|---|
void initialize(java.util.Map parameters);
void initialize(org.opennms.netmgt.poller.NetworkInterface iface);
| 最初の形式は、プラグインが初期化時に (例外をスローして) それ自体を使用不可にできるようにする機会を提供するために、始動時に呼び出されます。2番目の形式は、サービスをサポートする新規ノードが発見され、さらに、最初のpoll() が呼び出される前に呼び出されます。 |
void release();
void release(java.net.NetworkInterface iface);
| 最初の形式は、OpenNMSのシャットダウン時に呼び出されます。2番目の形式は、サービスをサポートするノードを、それ以降のポーリング・スケジュールから除去するときに、呼び出されます。 |
int poll(java.net.NetworkInterface iface, org.opennms.netmgt.utils.EventProxy eproxy, java.util.Map parameters);
| これは、モニター対象のサービスがまだ使用可能であるかどうかを判別するために使用されるメソッドです。このメソッドは、サービスが実行中である場合にはServiceMonitor. SERVICE_AVAILABLE を戻し、そうでない場合にはServiceMonitor. SERVICE_UNAVAILABLE を戻します。 |
-
/etc/poller-configuration.xmlファイル内にサービス定義とモニター定義を作成します。このファイルは、各サービスのポーリング間隔および運用中に使用するモニター「プラグイン」を決定するために、pollerdによって始動時に読み取られるファイルです。
ClickMeterのためのポーラー・モニターの作成は、この後でまもなく行います。
OpenNMSを使用してJMX対応ClickMeterをモニターする
以上で、capsd プラグインとpollerd モニターを作成することにより、OpenNMSを私たちのJMX対応ClickMeterと統合できるようになることが分かりました。しかし、なぜOpenNMSがネイティブでJMXをサポートしないのか、という疑問が残ります。
人気のある市販のNMSオファリングの間にも、JMXがまだネイティブではサポートされていないという、同じ一般的な傾向が見られます。この理由の一部として、JMX対応の装置およびサービスが使用可能になり始めて間がないこと、およびほとんどの「サード・パーティー製装置およびサービス」(NMSベンダーによって作られたものではない装置およびサービス) を管理するために、SNMP互換性が十分に備わっているということがあります。
NMSベンダーによるJMXの組み込みがあまり進展しないのには、ほかにも重要な理由があります。JMXの計測機能レベルおよびエージェント・レベルでの詳細は1.1の仕様で十分に定義されていますが、ネットワーク内でJMXエージェントにアクセスするための詳しい方法については、(現時点では) まだ決まっていないのです。
ネットワーク内のネットワーク管理アプリケーションまたは分散サービスがJMXエージェントにアクセスする方法は、JMXリモーティング と呼ばれ、JSR 160の主要な関心事となっています (参考文献を参照)。JMXリモーティングは、近く発表されるJMX 1.2参照実装リリースの主要な新規機能です。
JSR 160は、ネットワークでJMXエージェントのディスカバリーを行う方法、およびエージェントの機能にリモート側からアクセスするための特定の方法を指定する予定です。これには、使用されるプロトコル・アダプターに関する何らかの仕様も含まれるはずです。JMX Remoting 1.2仕様はおそらく2003年中に完成すると思われますが、それまでの間は、私たちのClickMeter MBeanを管理するJMXエージェントとOpenNMSとの間で通信を行うための、代替機能手段を探さなければなりません。
もちろん、JMXエージェントの主な目的の1つは、その管理対象となるJMX MBeansにリモート・アクセスできるようにすることです (ただし、JMXエージェントの中には、値を追加するように設計されていて、管理対象のMBeansを必ずしもすべて開示しないものもあります)。このシリーズの第2回で述べたように、エージェントは、コネクターおよびプロトコル・アダプターを使用してNMSアプリケーションまたは分散サービスと通信します。
ClickMeterの場合には、JMX参照実装に入っている、HTTPプロトコル・アダプターを含む単純なエージェントを使用しました。この単純なエージェントは、HTTPプロトコル・アダプターを介して管理する、すべてのMBeansの、属性および操作を開示します。
JMX参照実装では、OpenNMSとClickMeter MBeanの通信を行うために、この単純なエージェントおよびHTTPプロトコル・アダプターを簡単に使用することができます。図3は、提案されている通信方法を示しています。運用中は、OpenNMSのcapsd が検出されたノードをスキャンし、「CLICKMETER」サービスがサポートされるかどうかを調べます。ポーラー・デーモンpollerd は、検出されたサービスに対して定期的にポーリングを行い、それらが操作可能になっていることを確認します。これらの両方のプローブに適応できるように、ClickMeter MBeanによって開示されたincPanelValue という操作を使用することができます。プローブ・メカニズムとしてincPanelValue 操作を使用することの利点は、OpenNMSの検出またはポーリング・アクションを視覚的に見ることができることです。ClickMeterの値は、プローブを行うたびに増分されます。
図3. HTTPアダプターによるClickMeterへのアクセス
そうなると、残っているのは、ClickMeter MBeanでincPanelValue 操作にアクセスするために、HTTPプロトコル・アダプターをどのように使用するのかを決めることだけです。ブラウザーを使用して、下記のURLにあるJMXエージェントにアクセスすることができます。
http://<host of agent>:8082/ |
もちろん、これを行う前に、エージェントが実行されていることを確認する必要があります。(そのための方法を再確認したい場合には、このシリーズの第2回を参照してください。)その後で、ボタンをクリックして、開示されたincPanelValue 操作を実行してみてください。図4に似たページが表示されるはずです。
図4. プローブURLの判別
図4で、この操作にアクセスするために使用されたURLが以下のものであることに注意してください。
http://<host of agent>:8082/InvokeAction//MBean:name=ClickMeter/ action=incPanelValue?action=incPanelValue |
また、ClickMeterアプリケーションが正しく機能している場合、表示されるページにincPanelValue Successful というフレーズが含まれていることに注意してください。OpenNMSからリモートでMBeanにアクセスするには、この情報を使用します。
これで、新しい「CLICKMETER」サービスをOpenNMSに統合する準備が整いました。統合を行うためには、機能デーモン (capsd) のためのプラグインと、ポーラー・デーモン (pollerd) のモニターを作成します。
OpenNMSディスカバリーのためのClickMeterPlugin
機能デーモン・プラグインのためのコードは、配布されたソースのorg.opennms.netmgt.capsd.ClickMeterPlugin クラスで提供されています。このプラグインは、org.opennms.netmgt.capsd.Plugin インターフェースを実装しなければなりません。リスト1は、このクラスがAbstractPlugin から得られることを示しています。このOpenNMS提供の抽象クラスは、私たちのコーディングに役立つ2つのパラメーター抽出メソッド (getKeyedInteger() およびgetKeyedString()) を備えています。
リスト1. ClickMeterPlugin管理クラス
public final class ClickMeterPlugin extends AbstractPlugin {
private static final String PROTOCOL_NAME = "CLICKMETER";
private static final int DEFAULT_PORT = 8082;
private final static int DEFAULT_RETRY = 0;
private final static int DEFAULT_TIMEOUT = 5000; // in milliseconds
|
getProtocolName() メソッドは、リスト2のコードで簡単に実装されます。
リスト2. getProtocolName() メソッド
public String getProtocolName() {
return PROTOCOL_NAME;
}
|
リスト3は、短いほうのisProtocolSupported() メソッドの実装方法を示しています。
リスト3. isProtocolSupported() メソッド
public boolean isProtocolSupported(InetAddress address) {
return isClickMeter(address, DEFAULT_PORT, DEFAULT_RETRY, DEFAULT_TIMEOUT);
}
|
長いほうのisProtocolSupported() メソッドでは、リモートJMXエージェントにアクセスするためのURLを作成するのに使用される、与えられたパラメーターを処理します。このパラメーターからIPとポートが入手されると、isProtocolSupported() はisClickMeter() メソッドを呼び出して、このノードでClickMeterがアクティブになっているかどうかを判別します。リスト4はisClickMeter() のコードを示しています。私たちのURLのために定数された2つの定数が、ClickMeterのincPanelValue 操作にアクセスするのに必要な、HTTPプロトコル・アダプター・アクセスURLに対応していることに注意してください。
リスト4. isClickMeter() メソッド
private final static String CLICK_METER_BEAN_LOCATOR_URL =
"/InvokeAction//MBean:name=ClickMeter/action=incPanelValue?
action=incPanelValue";
private final static String CLICK_METER_ID = "incPanelValue Successful";
private boolean isClickMeter(InetAddress host, int port,
int retries, int timeout) {
Category log = ThreadCategory.getInstance(getClass());
boolean foundClickMeter = false;
for (int attempts=0; attempts <= retries && !foundClickMeter;
attempts++)
{
URL jmxLink = null;
InputStream iStream = null;
try
{
String hostIP = host.getHostAddress();
jmxLink = new URL("http", hostIP, port,
CLICK_METER_BEAN_LOCATOR_URL);
if (scanURL(jmxLink, CLICK_METER_ID, log)) {
foundClickMeter = true;
break; // get out of the for loop
}
}
catch(IOException e) {
log.info("ClickMeterPlugin: Error communicating
with host " + host.getHostAddress(), e);
foundClickMeter = false;
}
}
return foundClickMeter;
}
|
リスト5に示すscanURL() メソッドは、URLとストリングを引き数として受け入れるヘルパー・メソッドです。このメソッドは、その後でURLにアクセスし、表示されたページをサーチして、指定のストリングがあるかどうかを調べます。そして、そのストリングが見付かった場合にはtrue を戻します。そうでない場合にはfalse を戻します。私たちの例では、ClickMeterのincPanelValue 操作のためのURLにアクセスした後で、incPanelValue Successful ストリングを探します。
リスト5. scanURL() メソッド
private boolean scanURL(URL inURL, String toSearch, Category log) {
InputStream iStream = null;
try {
iStream = inURL.openStream();
BufferedReader urlReader =
new BufferedReader(new InputStreamReader(iStream));
String curLine = urlReader.readLine();
do {
if (curLine.indexOf(toSearch) != -1) {
return true;
}
curLine = urlReader.readLine();
} while (curLine != null);
}
catch (IOException e) {
e.fillInStackTrace();
log.debug("ClickMeterMonitor.poll:
Error reading from URL:"
+ inURL, e);
}
finally {
try {
if(iStream != null)
iStream.close();
}
catch(IOException e) {
e.fillInStackTrace();
log.debug("ClickMeterMonitor.poll:
Error closing stream to URL.", e);
}
}
return false;
}
}
|
プラグインを組み込むために必要な2番目のステップは、<OpenNMS installation directory>/etc/capsd-configuration.xmlファイルを編集して、リスト6に示すプロトコル・プラグイン定義を追加することです。
リスト6. プロトコル・プラグイン定義
<protocol-plugin
protocol="CLICKMETER"
class-name="org.opennms.netmgt.capsd.ClickMeterPlugin"
scan="on" >
<property key="port" value="8082"/>
<property key="timeout" value="2000"/>
<property key="retry" value="1"/>
</protocol-plugin>
|
また、OpenNMSがスキャンするIPの範囲を管理対象ノードに限定するために、discovery-configuration.xml ファイルを編集しなければならない場合もあります。リスト7では、ClickMeterアプリケーションを速く見付けるために、2つのIPに範囲を限定しています。
リスト7. ディスカバリーの範囲の限定
<include-range retries="2" timeout="3000">
<begin>192.168.23.75</begin>
<end>192.168.23.76</end>
</include-range>
|
次に、ポーラー・デーモン (pollerd) モニター・プラグイン、つまりorg.opennms.netmgt.poller.ClickMeterMonitor クラスを作成します。このクラスは、org.opennms.netmgt.poller.ServiceMonitor インターフェースを実装しなければなりません。OpenNMSでは、このインターフェース内のすべてのメソッドのためのデフォルト実装を提供する基本クラス (org.opennms.netmgt.poller.IPv4Monitor) が用意されています。私たちには特別な初期化またはリリースは必要がありませんので、リスト8に示すようにpoll() メソッドを指定変更するだけで済みます。
リスト8. poll() メソッド
public int poll(NetworkInterface iface, Map parameters) {
if(iface.getType() != NetworkInterface.TYPE_IPV4)
throw new NetworkInterfaceNotSupportedException("Unsupported
interface type, only TYPE_IPV4 currently supported");
Category log = ThreadCategory.getInstance(getClass());
int retry =
getKeyedInteger(parameters, "retry", DEFAULT_RETRY);
int port =
getKeyedInteger(parameters, "port", DEFAULT_PORT);
int timeout =
getKeyedInteger(parameters, "timeout", DEFAULT_TIMEOUT);
InetAddress ipv4Addr = (InetAddress)iface.getAddress();
String hostIP = ipv4Addr.getHostAddress();
if (log.isDebugEnabled())
log.debug("ClickMeterMonitor.poll: Polling interface: "
+ hostIP + " timeout: " + timeout + " retry: " + retry);
int serviceStatus = ServiceMonitor.SERVICE_UNAVAILABLE;
for (int attempts=0; attempts <= retry && serviceStatus !=
ServiceMonitor.SERVICE_AVAILABLE; attempts++) {
URL jmxLink = null;
InputStream iStream = null;
try {
jmxLink = new URL("http", hostIP, port,
CLICK_METER_BEAN_LOCATOR_URL);
if (scanURL(jmxLink, CLICK_METER_ID, log)) {
serviceStatus = ServiceMonitor.SERVICE_AVAILABLE;
break; }
}
catch(IOException e) {
e.fillInStackTrace();
log.debug("ClickMeterMonitor.poll:
IOException while polling address: "
+ ipv4Addr, e);
}
} // of for
return serviceStatus;
}
|
リスト8における、ClickMeter MBeanにアクセスするためのscanURL() ヘルパー・メソッドの使い方に注意してください。
<OpenNMS installation directory>/etc/poller-configuration.xml ファイルには、サービス定義項目を追加しなければなりません。リスト9で、ポーリング間隔として10,000ミリ秒 (つまり、10秒) を指定することにします。
リスト9. ポーラー・デーモンのサービス定義
<service name="CLICKMETER" interval="10000" user-defined="false" status="on">
<parameter key="timeout" value="3000"/>
<parameter key="port" value="8082"/>
</service>
|
リスト10に示すように、同じpoller-configuration.xml ファイルにモニター定義も挿入する必要があります。
リスト10. ポーラー・デーモンのモニター定義
<monitor service="CLICKMETER" class-name="org.opennms.netmgt.poller.ClickMeterMonitor" />
|
ソースから2つのプラグインをビルドするためには、提供されたcompile.batファイルを使用してください。いくつかのOpenNMSライブラリー・ファイルを <article code distribution>/libディレクトリーにコピーする必要があります (詳細については、README.txt を参照してください)。compile.batファイルにより、dwClickMeterJMX.jar が作成されます。これによって得られたJARファイルを <OpenNMS installation directory>/libディレクトリーに入れてください。OpenNMSが始動時に新規プラグインを自動的にロードするようになります。
私たちのClickMeter MBeanを使用してOpenNMSをテストするには、最初に、この記事の第2回で紹介したClickMeter実装 (標準、動的、またはモデルMBean) のうちの1つを管理対象ノードで始動させてください。次に、OpenNMSを再始動します。これは一般には、システムをリブートすることにより、あるいは <OpenNMS installation directory>/bin/opennms.shスクリプトを使用することにより行われます。
OpenNMSのWebベースGUIにアクセスして、システムが始動していることを確認してください。典型的なURLは、次のようになります。
http://<host of OpenNMS>:8080/opennms/ |
プロンプトが出されたときに、ユーザーIDとしてadmin を、パスワードとしてadmin を使用してください。図5は、正常に始動した場合のGUIを示しています。
図5. OpenNMSの始動画面
OpenNMSの始動時に、ClickMeterのカウントが2回 (capsd スキャンによって1回、初期pollerd ポーリングによってもう1回) 高速に増えるのを目にするでしょう。その後は、pollerd の働きにより、ClickMeterが通常の10秒間隔で増加するようになります。
capsd は、ClickMeterアプリケーションを検出すると、それを管理対象サービスとしてRDBMSに追加します。実動環境では、OpenNMSの資産管理機能を使用して、さらにこのサービスを分類し、ラベルを付けることができます。私たちの実験の場合には、図6に示すように、OpenNMSのGUIを使用してClickMeterサービスに入り、関連する詳細なイベントを調べることができます。
図6. ClickMeterを管理するOpenNMS
このシリーズでは、「ブラック・ボックス」装置制御端末エミュレーターとしてのつつましい出発点からスタートして、今日における、現代的なITサポート態勢の典型的な土台としての役割にいたるまでの、ネットワーク管理の進化の道筋をたどりました。現代のNMSは、装置、コンピューター機器、通信回線、およびソフトウェア・サービスからなる巨大ネットワークを制御、管理、供給、およびモニターするための、多層構造からなる、エンタープライズ・レベルの管理システムとなっています。
私たちは、JMXが成熟したテクノロジーであって、これを使用することにより、アプリケーション・プログラマーおよび装置設計者が、ソフトウェア・アプリケーションまたはサービスに計測機能を迅速に追加できることを見てきました。ここで得られた計測機能は、管理プロトコルやNMSに対して中立です。一度計測機能を配置すると、プロトコル・アダプターおよびコネクターを使用することにより、JMX装置を、ほとんどすべてのNMSで管理およびモニターできるようになります。
JMX仕様は、現在作業が進行中です。JMXリモーティング、および分散サービス・レベルのJMXアーキテクチャーが十分に定義されるようになると、JMXは、分散管理のための最高の基礎となる可能性があります。特に、Javaプラットフォームの持つGUIおよびWebアプリケーション開発のサポート能力、堅固なRDBMSサポート能力、および「一度書けばどこでも実行できる」能力を利用できる、将来のNMS製品では、複雑なシステムのために計測機能をいくつも維持する必要がなくなることでしょう。
- この記事に関連したソース・コードおよびスクリプト・ファイルをダウンロードしてください。
- JMXに関するこのシリーズの、これまでの2つの記事をお読みください。
- OpenNMSの最新バージョンをダウンロードしたり、OpenNMSに関する詳しい情報を調べたりするには、OpenNMSの公式Webサイトを訪問してください。
- OpenNMSで使用したRDBMS、PostgreSQLに関する詳細は、ミラー・サイトのうちの1つからダウンロードして調べることができます。
- OpenNMSは、カスタマイズ可能なJSPベースのユーザー・インターフェースを提供するために、Apache Jakarta Tomcatを使用しています。このサーバーに関する詳しい情報は、Tomcatの公式サイトから入手することができます。
- 最新のJMX仕様、参照実装、および互換性テスト・スイートは、Java Management Extensions (JMX) からダウンロードすることができます。
- 完全なオープン・ソースのJMX 1.1実装、およびJakarta Tomcatによって使用されている現行のJMXについては、MX4J プロジェクトを調べてください。この実装には、JMXリモーティングのためのRMIベースのコネクターが組み込まれていますので、試してみてください。
- SNMPの詳細については、IETF RFC 1157 を
参照してください。
- CIM/WBEMに興味のある方は、Distributed Management Task Force Webサイトに詳しい情報と最新の開発が掲載されていますので、参照してください。
- JMX 1.1を使用して計測が行われた最新バージョンのTomcat 4.1.xサーバーをApache Jakarta Project からダウンロードすることができます。ソース・コードの配布も行われています。
- JMX分散サービス、プロトコル・アダプター、およびコネクターに関して行われている作業については、JSR 160 JMX Remoting 1.2、JSR 146 WBEM Services、およびJSR 70 IIOP Protocol Adapter for JMX を参照してください。
- JMXは、J2EEコネクター・アーキテクチャーに似たエージェント・コネクター/アダプター・アーキテクチャーを備えています。
- J2EE 1.4では、コンテナーが完全にJMXで計測されるようになります。新しく生まれたJ2EE 1.4仕様の最新バージョンをダウンロードしてください。
- IBMのTivoli ソフトウェアは、TMX4J (alphaWorksから入手できるJMX互換実装) を含む既存および新興の広範囲のネットワーク管理標準をサポートする、セキュアなエンタープライズ管理ソリューションを備えています。
- Tivoliソフトウェアおよびセキュリティー製品に関する技術的な情報については、最新IBM製品ドメインTivoli Developer Domain を訪問してください。
- JMX互換の実装、TMX4J をalphaWorksから入手することができます。
-
developerWorks Javaテクノロジー・ゾーン には、Javaテクノロジーに関連する記事が多数掲載されています。
Sing LiはWrox Pressから出版されている多数の本の著者で、Professional Apache Tomcat 、Early Adopter JXTA 、Professional Jini などを執筆しています。技術雑誌に頻繁に寄稿しており、P2P発展に関する熱心なエバンジェリスト（伝道者）でもあります。コンサルタント兼ライターであるSingの連絡先はwestmakaha@yahoo.comです。
目次
タグ
スライダーバーを使用することで、より多く（少なく）タグを表示します。
人気のタグは、この特定のコンテンツ・ゾーン（例えば、Java テクノロジー、Linux や WebSphere など）に対するトップのタグを表示します。
マイ・タグは、この特定のコンテンツ・ゾーン（例えば、Java テクノロジー、Linux や WebSphere など）に対するお客様ご自身のタグを表示します。
記事の人気タグ |
記事のマイ・タグタグ・リストへスキップ
記事の人気タグ |
記事のマイ・タグ