Jolokia を使って HTTP プロキシ経由で JMX を読む

Java のデプロイがすでに許可された Jolokia エンドポイントを公開しているなら、監視クライアントは通常の HTTP フォワードプロキシ経由で JMX 属性を読めます。クライアントは HTTP で Jolokia と通信し、Jolokia がアプリケーション側で JMX 操作を実行します。

monitor → HTTP proxy → HTTPS Jolokia endpoint → MBean

この経路には HTTP に対応した管理エンドポイントが必要です。変更していないネイティブの JMX クライアントを Web プロキシに向けても、それは作られません。

たとえば、JVM のヒープ使用量の読み取りは POST リクエストとして表せます。

curl --proxy http://proxy.example.net:8080 \
  --header 'Content-Type: application/json' \
  --data '{"type":"read","mbean":"java.lang:type=Memory","attribute":"HeapMemoryUsage","path":"used"}' \
  https://monitor.example.net/jolokia/

エンドポイントとプロキシはプレースホルダーです。これは読み取り操作を使います。HTTP メソッドの POST は JMX の書き込みを意味するのではなく、Jolokia の JSON リクエストを運びます。Jolokia は単純な操作向けに GET リクエストもサポートし、JSON POST は複雑な MBean 名に必要な URL エスケープの一部を避けられます。

HTTPS の管理エンドポイントでは、フォワードプロキシが該当するトンネル宛先を許可する必要があります。TLS は monitor.example.net を引き続き検証すべきです。プロキシ自身のホスト名と証明書は、プロキシ接続自体が TLS を使う場合、別のホップを表します。

2 つの認証判断を分けておきましょう。curl のプロキシ認証オプションはプロキシアカウントを提供します。エンドポイントの認証は管理 ID を提供し、Jolokia のポリシーがアクセスできる MBean と操作を決めます。フォワードプロキシを使える権限は JVM を管理する権限ではありません。

応答にも 2 つの層があります。HTTP トランスポートの状態と、Jolokia の JSON 操作結果です。返された status と value を確認し、本文をそのまま成功したメトリクスと見なさないでください。プロキシのエラー、エンドポイント認証の失敗、MBean の欠如はそれぞれ異なる対処を要します。

デプロイがネイティブの JMX コネクタだけを公開しているなら、そのコネクタと互換の経路を選ぶか、承認済みの HTTP 管理エンドポイントを用意してください。SSH のローカル転送は別のトランスポート設計ですが、ネイティブサービスへの接続のままです。プロトコルが Jolokia の HTTP API に変わるわけではありません。