こんにちは！システムの安定稼働を守るためのオブザーバビリティ、日々の運用お疲れ様です。
今回は、多くのJavaエンジニアやインフラエンジニアが一度は頭を悩ませる「Javaアプリケーションの内部メトリクス監視」を、Zabbixの秘密兵器であるLLD（Low-Level Discovery：ローレベルディスカバリー）を使って完全に自動化する方法を解説します。
「TomcatやSpring Bootのインスタンスが増えるたびに、監視設定をポチポチ手動で追加している…」
「コネクションプールの数やヒープメモリのusageを監視したいけど、動的に変わるから設定が追いつかない…」
そんな地獄のようなルーチンワークから、あなたを解放します。これをマスターすれば、新しいマイクロサービスが生み出されても、Zabbixが勝手にそれを察知して監視を始めてくれるようになりますよ。
—
1. そもそも「JMX監視」と「LLD」って何をするもの？
まず前提をサクッと整理しておきましょう。
- JMX（Java Management Extensions）とは？
Javaアプリの心臓部（JVMやTomcat、Spring Bootなど）が持つ「今の状態（メモリ使用量、スレッド数、DBコネクション数など）」を外部に公開するための仕組みです。Javaアプリの中身を覗き見るための「共通窓口」だと思ってください。
- LLD（Low-Level Discovery）とは？
Zabbixの超強力な機能です。例えば、「今、このTomcatには何個のデータソース（コネクションプール）があるか」を人間が事前に決め打ちせず、Zabbix自身に自動でスキャンさせ、見つかったものに対して自動で監視アイテムを一発生成させる仕組みです。
この2つを組み合わせると、「Javaアプリが勝手に増減しても、内部の細かいメトリクスまでZabbixが自動で追いかけて監視し続けるエコシステム」が完成します。
—
2. 基礎セットアップ：Java側でJMXを解放する
まずは、監視される側のJavaアプリケーション（TomcatやSpring Bootなど）で、JMXを外部から叩けるようにポートを開け、認証などの設定を行います。
Javaアプリを起動する際のJVMオプションに、以下を追加してください。
外部（ZabbixサーバーやZabbixプロキシ）からJMX接続を許可する設定
java -Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=12345 \ # JMXが待ち受けるポート番号
-Dcom.sun.management.jmxremote.authenticate=false \ # 今回は簡単のため認証なし（本番では必ずtrueに！）
-Dcom.sun.management.jmxremote.ssl=false \ # 暗号化なし（社内網などの前提）
-jar your-awesome-app.jar
> 先輩からのワンポイントアドバイス
> 本番環境では `-Dcom.sun.management.jmxremote.authenticate=true` にして、パスワード認証を必ず有効にしてくださいね。セキュリティの穴になってしまいますからね。
—
3. Zabbixの「JMXエージェント」でHelloWorld（動作確認）
いきなりLLDを組む前に、ZabbixがちゃんとJavaのJMXを叩けるか、基本の「HelloWorld」的な動作確認をしましょう。
1. Zabbixフロントエンドを開き、対象のホスト設定画面を開きます。
2. 「JMXインターフェース」の項目に、Javaアプリが動いているサーバーのIPアドレスと、先ほど指定したポート（`12345`）を設定します。
3. 「アイテム」の作成画面で、以下のように設定してテストしてみます。
- 名前: `JVMヒープメモリ使用量`
- タイプ: `JMXエージェント`
- キー: `jmx[“java.lang:type=Memory”,”HeapMemoryUsage.used”]`
- データ型: `数値 (整数)`
これで「最新データ」画面にヒープメモリの数値がピョコッと表示されたら、ZabbixとJavaの握手は成功です！
—
4. 本丸：LLD（ローレベルディスカバリー）でJMXを自動化する
さて、ここからが本番です。
例えば、Tomcatの上で動く複数の「データソース（HikariCPなど）」のコネクション数を監視したいとします。データソースの数や名前はアプリによってバラバラです。これを自動検出させましょう。
ステップ1：LLD用のJSONフォーマットを理解する
ZabbixのJMX LLDでは、JMXのMBean（オブジェクトの設計図のようなもの）から、リスト構造のデータを取得し、特定のJSON形式で出力させる必要があります。
Zabbixには便利な `jmx.discovery` というJMX発見機能が標準で備わっています。これを使うと、JMXのクエリから自動でJSONを作ってくれます。
ステップ2：ZabbixでLLDルールを作成する
Zabbixのホストまたはテンプレートに、新しい「ディスカバリー規則」を追加します。
- 名前: `HikariCPデータソースの自動検出`
- タイプ: `JMXエージェント`
- キー: `jmx.discovery[endpoints,com.zaxxer.hikari:type=Pool ()]`
- 解説: `com.zaxxer.hikari:type=Pool ()` にマッチするMBeanをすべて探し出せ、という魔法のキーです。
このディスカバリー規則を設定すると、Zabbixは内部で次のようなJSONを自動生成し、動的な変数を抽出します。
(イメージ)
{
“data”: [
{ “{#JMXPOOL_NAME}”: “AppDataSource” },
{ “{#JMXPOOL_NAME}”: “LogDataSource” }
]
}
これで、`{#JMXPOOL_NAME}` というマクロ（変数）の中に、検出されたデータソースの名前が動的に格納されるようになります！
ステップ3：ディスカバリープロトタイプで「監視アイテム」を自動生成する
先ほど作ったディスカバリー規則の中に、「アイテムプロトタイプ」を追加します。ここが自動化のキモです。
- 名前: `HikariCP コネクション数 ({#JMXPOOL_NAME})`
- タイプ: `JMXエージェント`
- キー: `jmx[“com.zaxxer.hikari:type=Pool ({#JMXPOOL_NAME})”,”ActiveConnections”]`
- 解説: 先ほど検出された変数 `{#JMXPOOL_NAME}` が、このキーの中に動的に埋め込まれます。これにより、データソースが2つあれば2つ分の監視アイテムが、10個あれば10個分が自動生成されます。
- データ型: `数値 (整数)`
—
5. 動作確認：魔法のようにアイテムが湧き出る瞬間を見る
設定を保存したら、Zabbixサーバーがディスカバリーを実行するのを少し待ちます（または「今すぐ再チェック」を押します）。
「ホスト」の「アイテム」一覧画面を覗いてみてください。
あなたが手動で一つひとつ設定したわけでもないのに、Javaアプリ側にあるデータソースの数だけ、ピカピカの監視アイテムが自動で生成されているはずです。
「あ、新しいデータソースが追加された！」となっても、もうZabbix側の設定を変更する必要はありません。LLDが勝手に検知し、明日から自動で監視を始めてくれます。
—
おわりに：毎日の作業が劇的に楽になりますよ
今回は、ZabbixのLLDとJMXを組み合わせて、Javaアプリケーションの内部メトリクスを自動収集する極意をお伝えしました。
この構成を一度テンプレートとして組んでしまえば、今後どれだけ大量のマイクロサービスやJavaアプリがデプロイされても、監視漏れにおびえる夜とはおさらばです。
オブザーバビリティの第一歩は、「手動運用の自動化」と「構造化」から始まります。ぜひあなたの現場でも試して、静かで平穏な運用ライフを手に入れてくださいね。それでは、また次の現場でお会いしましょう！