🧙🏻 🤐 👩‍❤️‍💋‍👩 Zabbix 3.4のJavaアプリケーションを監視するための新機能 💅🏿 🏦 ✌🏾

どうした

待望のZabbix 3.4リリースが登場し、多くの有用な改善がもたらされました。その中には、カスタムJMXエンドポイントとMBeanの柔軟な検出がありました。

かっこいいですね

Zabbixを使用し、Javaアプリケーションを監視する必要がある場合、そうです-さまざまなトリックに頼らなければならない前に、それがあなたの人生をはるかに簡単にすることができます。

これらのJMXエンドポイントの何が問題になっていますか？

JMXを介したJavaアプリケーションのネイティブモニタリングは、Zabbixで-バージョン2.0から-ずっと前に登場し、それ以来、この機能はバージョンごとに改善されてきました。しかし、JMXエンドポイントの以前のリリースでは、Zabbix Java Gatewayコードに完全に単純な方法で組み込まれていました。

判明したように、Javaの世界では他のエンドポイントを使用するソフトウェアがたくさんあり、Zabbixの古いバージョンではこのパラメーターを変更できませんでした。多くのユーザーにとって、これは大きな問題になっています。たとえば、人気のあるJBoss EAP 6アプリケーションサーバーは、 RMIとJMXServiceURLの代わりに、JMXへのリモートアクセスにJBoss Remotingプロトコルを使用します。

service:jmx:remoting-jmx://{HOST.CONN}:{HOST.PORT}

また、たとえば、WebSphere 8.5はIIOP （ JRMPではなく）でRMIを使用します。JMXServiceURLは次のようになります。

service:jmx:iiop://{HOST.CONN}:{HOST.PORT}/jndi/JMXConnector

Zabbix 3.4はこの問題を解決するだけです。

何も分かりませんでした JMX、RMI、JNDI？ WTF？

さてさて、それがすべてどのように機能するかを少し理解しましょう。

JMX（Java Management Extensions） -さまざまなオブジェクト（リソース）を監視および管理（リモートを含む）するように設計されたJavaテクノロジー：アプリケーション、デバイス、ネットワーク-このオブジェクトのみがJavaで記述されている場合。

これらのリソースは、 MBean（ManagedBean）と呼ばれます。このような各オブジェクトは、このオブジェクトの属性の値にアクセスし、そのメソッドを呼び出して通知を受け取ることができる特定のインターフェースを実装します（アプリケーションが対応する「リスニング」MBeanを登録する場合）。

MBeanは、オブジェクトレジストリであるMBeanサーバーに登録されます。登録されたオブジェクトはすべてアプリケーションで使用可能になります（より正確には、そのインターフェースが使用可能になります）。

リソースには、 JMXコネクタを使用してアクセスします。これにより、JMXクライアントがMBeanサーバーを利用できるようになります。 JMXコネクタは、クライアントとサーバーで構成されます。 コネクタサーバーはMBeanサーバーに接続し、クライアントからの接続要求をリッスンします。通常、 クライアントコネクタは別のJVMにあり、ほとんどの場合、コネクタサーバーに関しては別のマシンにあります。

JMX APIには、 Remote Method Invocation（RMI）に基づく標準接続プロトコルがあります。このプロトコルにより、JMXクライアントはMBeanサーバー上のMBeanにリモートでアクセスできます。標準のRMIに加えて、JMXMP、JBoss Remoting、Hessian、Burlap、さらにはHTTPおよびSNMPなどのプロトコルがあります。

MBeanインターフェイスを使用すると、クライアントはこのオブジェクトのさまざまなメトリックを受信したり、パブリックメソッドを呼び出したりできます。

概略的に、コンポーネントの相互作用は次のように表すことができます。

Java SEプラットフォームですぐに使用できるアプリケーションには、それを監視する機能があります。RMIコネクタにより、Javaアプリケーションが自動的にリモート管理および監視可能になります。必要なパラメーターを使用してアプリケーションを起動するだけで、JMXクライアント（およびZabbix JavaゲートウェイはJMXクライアント）は既にリモートで接続し、必要なメトリックを受信できます。

接続する特定のアプリケーションをJMXクライアントに示すために、JMXエンドポイント（別名JMXServiceURL ）と呼ばれる特別なアドレスが使用されます。厳密に言えば、これはJMX APIコネクタサーバーのアドレスです。このアドレスの形式は、 RFC 2609およびRFC 3111で定義されています。一般的に、次のようになります。

service:jmx:protocol:sap

ここで、 「service：jmx：」は定数です。

protocolは、コネクタサーバーへの接続に使用されるトランスポートプロトコル（RMI、JMXMPなど）です。

sapは、コネクタサーバーが見つかるアドレスです。この形式で定義されています（これはRFC 2609で定義されている構文のサブセットです）。

//[host[:port]][url-path]

host [：port] -ipv4ホストアドレス（または角括弧で囲まれたipv6）およびオプション（プロトコルに応じて）のポート番号。

url-path-オプションのURL（プロトコルに応じて必要）。

例でこれを理解するのが最善です。多くの場合、そのようなJMXエンドポイントを見つけることができます。

service:jmx:rmi://host:port1/jndi/rmi://host:port2/jmxrmi

しかし、実際には、すべてがそれほど怖いわけではありません。

hostは、アプリケーションが実行されているターゲットホストです。

port1は、接続するRMIサーバーのポートです。

port2はRMIレジストリポート（RMIサーバーが登録されているディレクトリ）です。デフォルト：1099。

RMIレジストリがクライアントの要求でRMIサーバーのアドレスとポートを発行することがわかっている場合、最初の部分が冗長であることが明らかになります。したがって、アドレスはこのタイプに縮小できます。

url-path部分は文字通り次を意味します：/ jndi /の直後のURLの部分を取得し、このアドレスのRMIレジストリへのJNDI要求を実行して、RMIサーバーに関する情報を取得します。レジストリは、応答でホストとポートを返します。

この場合のポートはランダムに生成され、ファイアウォールの設定に問題がある可能性があることに注意してください。このような場合、ポートを明示的に指定できるため、以前のバージョンの JMXエンドポイントを使用します。

JMXをより深く理解したい場合は、オラクルの公式ドキュメントを参照することをお勧めします。

実際にはもっと良いのでしょうか？

これ以上簡単なものはありません:)例としてJBoss EAP 6.4モニタリングを設定してみましょう。

最初に、いくつかの仮定を行います。

Zabbix 3.4とZabbix Java Gatewayはすでにインストールされています。まだない場合は、 Zabbixのドキュメントに従ってこれを行うことができます。
/ usr / local /プレフィックスが付いたZabbixサーバーとJavaゲートウェイ。
JBossはすでに/opt/jboss-eap-6.4/にインストールされており、スタンドアロンモードで起動します。
実験を簡単にするために、これらすべてのコンポーネントが同じマシンで動作すると仮定します。
ファイアウォールとSELinuxは無効になっています（またはそれに応じて構成されていますが、これは記事の範囲外です）。

zabbix_server.confで簡単な設定を行いましょう：

 JavaGateway=127.0.0.1 StartJavaPollers=5

そして、zabbix_java / settings.sh config（またはzabbix_java_gateway.conf）で：

 START_POLLERS=5

JBossが標準管理ポートでリッスンしていることを確認します。

 $ netstat -natp | grep 9999 tcp 0 0 127.0.0.1:9999 0.0.0.0:* LISTEN 10148/java

次に、JMXインターフェース127.0.0.1:9999を使用してZabbixでホストを作成しましょう。

標準テンプレート「テンプレートアプリジェネリックJava JMX」を使用してホストにリンクすると、エラーが発生します。

 $ tail -f /tmp/zabbix_java.log

Java Gatewayは、指定されたエンドポイントがRMIにまったく応答しないことを通知します。さて、このバージョンのJBossはRMIではなくJBoss Remotingプロトコルを使用していることをすでに知っているので、正しいエンドポイントをノックする必要があります。

Template App Generic Java JMXテンプレートのフルクローンを作成し、Template App Generic Java JMX-remotingという名前を付けましょう。このテンプレート内のすべてのデータ要素を選択し、JMXエンドポイントパラメーターの一括更新操作を実行します。次のURLを記述しましょう。

service:jmx:remoting-jmx://{HOST.CONN}:{HOST.PORT}

構成キャッシュを更新します。

 $ /usr/local/sbin/zabbix_server -R config_cache_reload

そしてまた間違い。

今回は何？

「サポートされていないプロトコル：remoting-jmx」は、Java Gatewayが指定されたプロトコルで動作できないことを意味します。さて、彼に教えましょう。「remoting-jmxとZabbixを使用したJBoss EAP 6監視」の記事からのアドバイスは、これに役立ちます。

次の内容の〜/ needed_modules.txtファイルを作成します。

 jboss-as-remoting jboss-logging jboss-logmanager jboss-marshalling jboss-remoting jboss-sasl jcl-over-slf4j jul-to-slf4j-stub log4j-jboss-logmanager remoting-jmx slf4j-api xnio-api xnio-nio

次のコマンドを実行します。

 $ for i in $(cat ~/needed_modules.txt); do find /opt/jboss-eap-6.4 -iname ${i}*.jar -exec cp {} /usr/local/sbin/zabbix_java/lib/ \; ; done

したがって、Java Gatewayにはjmx-remotingを操作するために必要なすべてのモジュールが含まれます。残っているのは、Java Gatewayを再起動し、少し待って、すべてを正しく行った場合、大切なデータがZabbixに流れ始めたことを確認することです。

JMXディスカバリーについてはどうですか？

JMXによるJavaアプリケーションの監視のネイティブサポートが登場すると同時に、JMXディスカバリーがZabbixに登場しました。 jmx.discoveryキーがこの機能を担当します（その時点で）。まだ非常に粗雑な機能であったため、それについてのドキュメントには言葉がありませんでした：

フィルタリングの可能性がないため、このような検出には意味がありません。そして、既存のJMXオブジェクトをすべて発見する必要はほとんどありません。
これは非常に遅いソリューションですここでは、MBeanごとに1つのクエリが実行され、非常に多くのクエリが存在する可能性があります。そのようなチェックは、タイムアウトによって単純に落ちる可能性が非常に高いです。
このフォームでは、ホスト内に1つの検出ルールのみを作成できますが、実際には多くのルールを作成したいので非常に残念です（異なる属性のデータ型は控えめかもしれません）。

Zabbix 3.4ではフィルタリング機能が導入され、多くの問題が即座に解決されます。

新しいチェックは次のようになりますjmx.discovery[< >,< >]

また、MBeanまたはその属性の検出が必要かどうか、およびそれらを検索するパターンによって指定できます。

実際に試してみましょう！たとえば、ガベージコレクターを監視します。 JVMが実行されているパラメーターによって名前が異なる場合があることが知られています。そのため、データ項目に静的な名前とキーを設定することはできません-これはjmx.discoveryのジョブです。

このドキュメントでは、4つのユースケースについて説明しています。

キー	説明
`jmx.discovery`	すべてのJMX MBean属性の取得
`jmx.discovery[beans]`	すべてのJMX MBeanの取得
`jmx.discovery[attributes,":type=GarbageCollector,name="]`	すべてのガベージコレクター属性の取得
`jmx.discovery[beans,":type=GarbageCollector,name="]`	すべてのガベージコレクターの取得

最初の2つのオプションは使用しません。これはパフォーマンスの点ではあまり良くありません。最後の2つが何を返すのか見てみましょう。

この目的のために、必要なキーとテキストデータタイプを持つアイテムを作成するだけです。しかし、それはあまり便利ではありません。まず、出力はフォーマットされておらず、愛されます。第二に、リクエストを変更するために、アイテムキーを変更し、データを更新するためにしばらく待つ必要があります。

これは私たちのやり方ではありません。 Javaゲートウェイにアクセスするエージェントの代わりに、zabbix_getのようなものを実行しましょう。これを行うには、この記事で提案した新しいAPIのスクリプトを少し変更します。jmx_endpointをリクエストに追加し、レスポンスからヘッダーを削除するように修正します。

 #!/usr/bin/env bash if [ $# != 6 ] then echo "Usage: $0 <JAVA_GATEWAY_HOST> <JAVA_GATEWAY_PORT> <JMX_SERVER> <JMX_PORT> <JMX_ENDPOINT> <KEY>" exit; fi # create connection exec 3<>/dev/tcp/$1/$2 # compose message MSG="{\"request\": \"java gateway jmx\", \"conn\": \"$3\", \"port\": $4, \"jmx_endpoint\": \"$5\", \"keys\": [\"$6\"]}" # write message length as zero-padded 16-digit hexadecimal number printf -v LEN '%016x' "${#MSG}" # prepare message length in little endian representation BYTES="" for i in {0..14..2} do BYTES="\\x${LEN:$i:2}$BYTES" done # prepend protocol header and message length printf "ZBXD\\1$BYTES%s" "$MSG" >&3 # output the result skipping 6 bytes of "ZBXD\\1" header and 8 bytes of message length tail -c+14 <&3

これで、リクエストに応答してゲートウェイが返すものを簡単に確認できます。

 $ ./zabbix_get_java.sh 127.0.0.1 10052 127.0.0.1 9999 'service:jmx:remoting-jmx://127.0.0.1:9999' 'jmx.discovery[beans,\"*:type=GarbageCollector,name=*\"]' | jq '.data[0].value | fromjson | .data'