JMX監視を使用して、JavaアプリケーションのJMXカウンターを監視できます。
Zabbix 1.8では、JavaアプリケーションのJMXカウンターを監視する場合は、Zapcat JMX Zabbix Bridgeが最善の選択でした。アプリケーションのソースコードをZapcat JARファイルを参照するよう修正し、Zabbixエージェントをプログラムで開始するか、それをサポートするアプリケーション(Jetty、Tomcat等)用の既製のZapcatプラグインをインストールする必要がありました。
Zabbix 2.0以降は、「Zabbix Java gateway」という新しいZabbixデーモンを導入して、JMX監視のネイティブサポートを追加しています。
Zabbixサーバがホスト上の特定のJMXカウンターの値を知りたいときは、Zabbix** Java gateway**に問い合わせます。続いてZabbix Java gatewayは、JMX管理APIを使用して対象のアプリケーションにリモートでクエリーを行います。
Zabbix Java gatewayの入手場所やセットアップ方法を含む詳細については、本マニュアルのこのセクションを参照してください。
Javaアプリケーションは、さらにソフトウェアをインストールする必要はありませんが、リモートJMX監視をサポートするために以下のコマンドラインオプションを指定して起動します。
最低限として、セキュリティを実施していないホスト上でシンプルなJavaアプリケーションの監視から始めたい場合は、次のオプションで開始します。
java \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=12345 \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false \
-jar /usr/share/doc/openjdk-6-jre-headless/demo/jfc/Notepad/Notepad.jar
これにより、Javaに12345番ポートで入ってくるJMX接続を待ち受けさせ、認証またはSSLを要求しないようにします。
セキュリティをもっと厳しくしたい場合は、その他多くのJavaオプションが利用できます。例えば、次の例では、より多目的なオプション一式を付加してアプリケーションを開始し、ローカルホストだけでなく、より幅広いネットワークに向けて開放します。
java \
-Djava.rmi.server.hostname=192.168.3.14 \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=12345 \
-Dcom.sun.management.jmxremote.authenticate=true \
-Dcom.sun.management.jmxremote.password.file=/etc/java-6-openjdk/management/jmxremote.password \
-Dcom.sun.management.jmxremote.access.file=/etc/java-6-openjdk/management/jmxremote.access \
-Dcom.sun.management.jmxremote.ssl=true \
-Djavax.net.ssl.keyStore=$YOUR_KEY_STORE \
-Djavax.net.ssl.keyStorePassword=$YOUR_KEY_STORE_PASSWORD \
-Djavax.net.ssl.trustStore=$YOUR_TRUST_STORE \
-Djavax.net.ssl.trustStorePassword=$YOUR_TRUST_STORE_PASSWORD \
-Dcom.sun.management.jmxremote.ssl.need.client.auth=true \
-jar /usr/share/doc/openjdk-6-jre-headless/demo/jfc/Notepad/Notepad.jar
こうした設定の(すべてでなくとも)ほとんどは、/etc/java-6-openjdk/management/management.properties(または、そのファイルがシステム上のどこにあっても)で指定できます。
SSLを使用したい場合は、-Djavax.net.ssl.*オプションをJava gatewayに追加してstartup.shスクリプトを修正し、キーとトラストストアの場所がわかるようにする必要があります。
詳細な説明については、 JMXを使用した監視と管理 を参照してください。
Java gatewayを実行し、サーバにその場所を把握させ、リモートJMX監視をサポートするJavaアプリケーションを始動したら、Zabbix GUIでインターフェースとアイテムの設定を行います。
対象とするホスト上で、JMXタイプのインターフェースを作成することから始めます。
対象とする各JMXカウンターについて、そのインターフェースに付属のJMXエージェントタイプのアイテムを追加します。Javaアプリケーションで認証を設定した場合は、ユーザー名とパスワードも指定します。
以下のスクリーンショット内のキーは、jmx["java.lang:type=Memory","HeapMemoryUsage.used"]となっています。 JMXアイテムキーの構文は、Zapcatアイテムと同様ですが、引数を分割するのに「][」ではなくカンマを使用するところが異なります。キーは、次の2つのパラメータで構成されています。
JMXアイテムキーに関する詳細については、以下を参照してください。
「ture」または「false」どちらかのブール型カウンターを監視したい場合は、データ型を「数値(整数)」、データの形式を「ブール型」と指定します。サーバは、ブール型の値をそれぞれ1または0として保存します。
シンプルな属性
MBeanのオブジェクト名は、Javaアプリケーションで定義した文字列にすぎません。逆に属性名は、より複雑な場合があります。属性が単純なデータの形式(整数や文字列など)を返す場合は、何も心配することはなく、キーは次のようになります。
この例では、オブジェクト名は「com.example:Type=Hello」、属性名は「weight」、そしておそらく、戻り値のタイプは「数値(浮動小数)」となるはずです。
複合データを返す属性
属性が複合データを返す場合、より複雑になります。例えば、属性名が「apple」で、「weight」や「color」などといった、そのパラメータを表すハッシュを返す場合です。キーは次のように見える場合があります。
これにより、ドット記号を使用して属性名とハッシュキーが区切られている状態がわかります。同様に、属性がネストされた複合データを返す場合、次のように各部はドットで区切られます。
ドットに関する問題
ここまでは順調です。しかし、属性名またはハッシュキーがドット記号を含んでいる場合はどうでしょうか?ここに例があります。
これが問題です。属性名が単に「all」ではなく「all.fruits」であることをZabbixに伝えるにはどうしたらいいでしょうか?どうすれば、名前の一部であるドットを属性名とハッシュキーを区切るドットから区別できるでしょうか?
2.0.4よりも前のバージョンでは、Zabbix Java gatewayはこうした状況を処理できず、ユーザーに対して「取得不可」アイテムと示されていました。2.0.4以降は、名前の一部であるドットをバックスラッシュで回避するだけで、区別できるようになりました。
同様に、ハッシュキーにドットが含まれる場合は、次のようにエスケープします。
その他の問題
バックスラッシュ文字についても、次のようにエスケープします。
オブジェクト名または属性名にスペースまたはカンマが含まれる場合は、次のように二重引用符で囲みます。
実際にすることはこれだけです。JMX監視をお役立てください!
本ページは2014/08/05時点の原文を基にしておりますので、内容は必ずしも最新のものとは限りません。
最新の情報は、英語版のZabbix2.2マニュアルを参照してください。