スキップしてメイン コンテンツに移動

QuarkusとJMX

Quarkusで有効になっているこのポートの正体はなんだろう。

8080/tcp, 8778/tcp, 9779/tcp

Quarkus(Javaの超高速Webアプリフレームワーク)では、コンテナで動かす際に特に気にせずに公式がサンプルで出してくるfabric8のイメージを使っていると、アプリの8080ポートの他に8778、9779のポートも待ち受けている。

パフォーマンスチューニングするのに、ローカルで動かしているものを測定することはもちろんできるのだけど、本番環境でリモート接続して測定できないかなと思い改めてこれらのポートを確認してみた。

まず、8778は Jolokia https://jolokia.org/ だった。
Jolokia is remote JMX with JSON over HTTP.と公式には書いてある。
要するに直接リモートのJMXを繋がせるのではなく、HTTP経由かつJSONによる応答形式でJMXに繋いだときに得られる応答を返す代物。
これがあるとファイアウォールのようなプロトコル等に制約のある環境下でも使いやすいかもね、なんて話も公式サイトに書いてあった。

それから、9779は Prometheusの JMX Exporter https://github.com/prometheus/jmx_exporter だった。
要はPrometheusで見れるようにするエージェントの1つ。
これもJolokiaと同じくHTTP経由でのアクセスをできるようにしてくれる。

どちらを使いたいかは環境次第だと思うけれど(個人的な経験からするとPrometheusからの方が見れるイメージがすぐに思い浮かんだ)、
どちらにせよJMXそのものを公開するのではなくてHTTP且つエージェントを経由して公開しようという流れなのがわかった。

上記の2つのツールはどちらもHTTPSにも対応させることができるし認証の設定をすることもできる様子。


今回はとりあえずPrometheusで見れるようにしてみた。
と言っても、ほとんどPrometheusの経験がないので、とりあえず、という感じだけれど。

普段自分のアプリはdocker composeで動かしているので、次のようにしてPrometheusのイメージをアプリのネットワーク内で動かす。
こうすることで、例えばローカル環境での確認でも難なくネットワーク内で名前解決などできるので楽になる。

docker run -p 9090:9090 --net=myappnetwork_default prom/prometheus

そして下記を参考に、/etc/prometheus/prometheus.yml のtargetsと書いてある箇所にアプリのJMX Exporterのポートが待ち受けているサーバー名(docker composeを使用している場合はラベルでOK)とポートを書く。今回だとwebapiというラベルをつけているので、webapi:9779となる。

PrometheusでJmxモニターを動かす - Qiita https://qiita.com/connvoi_tyou/items/501c8d68ad0aec72bd10

その後、コンテナを再起動する。
すると、http://localhost:9090/targets で追加したアプリも見れるようになる。Graphのページでは実際にメトリクスを取得してグラフを表示することもできた。


どう考えても追加した自分のアプリはPrometheusのエンドポイントではないので、実際に運用するときには設定ファイルを適切に書く必要があると思うが、とりあえずJMX ExporterとPrometheusの組み合わせでJMXの値を取ることができてよかった。
パフォーマンスチューニングという点でいくと、jvisualvmで繋いでサンプリングとか取りたくなると思うんだけど、これ、実務だとどうしているんだろう。