JMX監視は、JavaアプリケーションのJMXカウンタの監視に使用できます。
Zabbix 1.8では、JavaアプリケーションのJMXカウンタを監視したい場合の最善の選択は、the Zapcat JMX Zabbix Bridge でした。Zapcat JAR ファイルを参照しているアプリケーションのソースコード監視し、Zabbix エージェントをプログラムで開始するか、Jetty またはTomcatのようなアプリケーションに既製の Zapcat プラグインをインストールするかのどちらかでした。
Zabbix 2.0では、「Zabbix Java ゲートウェイ」と呼ばれる新しいZabbixデーモンを導入したことによって、JMX監視のネイティブサポートが追加されました。
Zabbix サーバがホスト上の特定のJMXカウンタの値を知りたいとき、サーバが Zabbix Java ゲートウェイに問い合わせます。Zabbix Java ゲートウェイは、リモートで、対象のプリケーションに問合せを行うためにJMX management APIを順番に使用します。
Zabbix Java ゲートウェイに関する詳細、入手できる場所やセットアップ方法については、マニュアルのこのセクションを参照してください。
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を使用したい場合は、キーストアとトラストストアが見つかる場所をJava ゲートウェイが知るために、startup.sh スクリプトを編集して、 -Djavax.net.ssl.* オプションをJava ゲートウェイに追加しなければなりません。
詳細な説明は、JMXを使用した監視と管理を参照してください。
Java ゲートウェイが動作していて、サーバが場所を知っていて、JavaアプリケーションがリモートのJMX監視のサポートで開始したら、次はZabbix GUIでインターフェースとアイテムを設定します。
監視対象とするホスト上で、JMXタイプのインターフェースを作成することから始めます:
監視対象の各JMXカウンタについて、インターフェースに付属のタイプJMX エージェントのアイテムを追加します。Java アプリケーションに認証を設定した場合は、ユーザー名とパスワードを指定します。
以下のスクリーンショットの中では、キーは jmx["java.lang:type=Memory","HeapMemoryUsage.used"] と指定されています。JMXアイテムキーの記述方法は、引数を分割するのに ][ ではなくカンマが使用されること以外は、Zapcat アイテムに似ています。キーは以下の2つのパラメータで構成されています:
JMXアイテムキーに関する詳細は以下を参照してください。
「ture」または「false」のどちらかのブール型のカウンタを監視したい場合は、データ型を「数値 (整数)」、データの形式を「ブール型」と指定します。サーバは、1または0のブール型の値をそれぞれに保存します。
シンプルな属性
MBean の object name は、Javaアプリケーションで定義した文字列にほかありません。一方、attribute name は複雑になる場合があります。属性が原始的なデータの形式(整数や文字列など)を返した場合は心配ありません。キーはこのように見えます:
この例では、object name は「com.example:Type=Hello」、attribute name は「weight」で、おそらく「数値 (浮動小数)」タイプの値を返します。
混合データを返す属性
属性が混合データを返す場合は、より複雑になります。例えば:attribute name が「apple」で、「weight」や「color」といった、そのパラメータを表すハッシュを返す場合です。キーは以下のように見えます:
この例で、attribute name とハッシュキーがドットで分割されているのがわかります。同様に、属性がネストされた混合データをを返す場合も、各パートをドットで区切ります:
ドットに関する問題
いまのところは順調です。しかし、attribute name または ハッシュキーがドットを含んでいる場合はどうでしょうか。ここに例があります:
これは問題です。Zabbixにattribute nameが単なる「all」ではなくて「all.fruits」だと知らせるにはどうしたらいいでしょうか?名前の一部であるドットと、attribute nameとハッシュキーを分割するドットを、識別する方法は?
2.0.4より前は、Zabbix Java ゲートウェイは、そのような状況を扱えず、ユーザーに「取得不可の」アイテムと残していました。2.0.4以降は、これが可能になり、名前の一部であるドットをバックスラッシュでエスケープするだけでよくなりました:
同様に、ハッシュキーにドットが含まれる場合も、それをエスケープします:
その他の問題
バックスラッシュの文字もエスケープします:
object name または attribute name が空白またはカンマを含む場合は、それを二重引用符で囲みます:
jmx["java.lang:name=ConcurrentMarkSweep,type=GarbageCollector","LastGcInfo.memoryUsageAfterGc.CMS Old Gen.committed"]
これだけです。よいJMX監視を!
本ページは2013/05/03時点の原文を基にしておりますので、内容は必ずしも最新のものとは限りません。
最新の情報は右上の「Translations of this page」から英語版を参照してください。