Java 배포가 이미 권한이 부여된 Jolokia 엔드포인트를 노출하고 있다면, 모니터링 클라이언트는 일반 HTTP 전방 프록시를 통해 JMX 속성을 읽을 수 있습니다. 클라이언트는 HTTP로 Jolokia와 통신하고, Jolokia는 애플리케이션 측에서 JMX 작업을 수행합니다.

monitor → HTTP proxy → HTTPS Jolokia endpoint → MBean

이 경로에는 HTTP를 지원하는 관리 엔드포인트가 필요합니다. 변경하지 않은 네이티브 JMX 클라이언트를 웹 프록시로 향하게 해도 그것이 생기지 않습니다.

예를 들어 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를 사용한다면 프록시의 호스트 이름과 인증서는 별도의 홉을 설명합니다.

두 인증 결정을 분리하세요. curl의 프록시 인증 옵션은 프록시 계정을 제공합니다. 엔드포인트의 인증은 관리 ID를 제공하고, Jolokia의 정책이 접근할 수 있는 MBean과 작업을 결정합니다. 전방 프록시 사용 권한은 JVM 관리 권한이 아닙니다.

응답에도 두 계층이 있습니다. HTTP 전송 상태와 Jolokia의 JSON 작업 결과입니다. 반환된 status과 value을 확인하고, 어떤 본문이든 성공한 메트릭으로 받아들이지 마세요. 프록시 오류, 엔드포인트 인증 실패, 없는 MBean은 각각 다른 조치를 요구합니다.

배포가 네이티브 JMX 커넥터만 노출한다면 그 커넥터와 호환되는 경로를 선택하거나 승인된 HTTP 관리 엔드포인트를 마련하세요. SSH 로컬 전달은 다른 전송 설계이지만 네이티브 서비스에 대한 연결로 남습니다. 프로토콜이 Jolokia의 HTTP API로 바뀌지는 않습니다.

관련 글