通过 HTTP 代理使用 Jolokia 读取 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 承载的是 Jolokia 的 JSON 请求，并不意味着一项 JMX 写操作。Jolokia 也支持用 GET 请求执行简单操作，而 JSON POST 可以省去复杂 MBean 名称所需的某些 URL 转义。

对于 HTTPS 管理端点，正向代理需要允许相应的隧道目标。TLS 仍应校验 monitor.example.net。代理自身的主机名和证书（如果代理连接本身使用 TLS）描述的是另一跳。

把两个认证决定分开。curl 的代理认证选项提供的是代理账户。端点的认证提供的是管理身份，而 Jolokia 的策略决定它能否访问某些 MBean 和操作。可以使用正向代理并不等于有权管理 JVM。

响应同样有两层：HTTP 传输状态和 Jolokia 的 JSON 操作结果。要检查返回的 status 和 value，而不是把任何响应体都当作成功的指标。代理错误、端点认证失败和 MBean 缺失需要不同的处理。

如果部署只暴露原生 JMX 连接器，请选择与该连接器兼容的路径，或者安排一个已获批的 HTTP 管理端点。SSH 本地转发是另一种传输设计，但它仍然是对原生服务的连接；它不会把该协议变成 Jolokia 的 HTTP API。