[펌] 블랙박스에서 엔터프라이즈 까지, Part 3 : JMX 통합

출처 : http://www-903.ibm.com/developerworks/kr/java/library/j-jmx3.html

JMX Agent를 네트워크 관리 시스템에 연결하기

Level: Intermediate

Sing Li
작가, Wrox Press
2002년 12월 17일

실제 Network Management System (NMS)를 사용하여 JMX로 만들어진 자바 애플리케이션을 모니터링한다. NMS/JMX 통합에 사용된 일반적인 기술은 물론 JMX를 전개할 때 발생하는 일반적인 어려움들을 설명한다.

JMX는 자바 플랫폼의 새로운 표준 확장으로서 현대적 Network Management Systems (NMS)를 통해 장치, 애플리케이션, 서비스들을 관리 및 제어, 감시할 수 있다. JMX가 소프트웨어 애플리케이션/서비스를 어떻게 활용하는지를 확실히 알고 싶다면 실제 오픈 소스 NMS(OpenNMS)를 사용하여 ClickMeter 애플리케이션을 모니터링한다. 광범위한 가용성과 단순한 디자인 때문에 OpenNMS를 선택했다. 여러분들도 다른 NMS 제품에 설명된 통합 기술을 적용할 수 있다. OpenNMS 스팩으로 작업하기 전에 일반적인 디자인 엘리먼트와 대부분의 NMS 제품이 공유하는 작동 모델을 보도록 하자.

네트워크 관리 시스템- 그 근본적인 복잡성
네트워크 관리 사용자 인구가 다양해진 덕택에 지금의 NMS 제품은 가장 광범위하고 복잡한 소프트웨어 시스템이 되었다. 예를 들어 분산 작동 센터를 통해 통신 네트워크 장비를 관리 및 감시하는 다국적 조직은 가상 프라이빗 네트워크(VPN), PC 자산, 데이터 통신 자산, 애플리케이션 서버 관리에 필요한 지역 비지니스의 다양한 요구를 안게 될 것이다.

전형적인 NMS는 수천, 수만, 심지어 수백만 엔드포인트(노드)를 관리해야 한다. NMS의 목표 고객들은 중간 규모 이상의 조직들이다. 이러한 고객들은 다양한 비지니스를 하기 때문에 NMS는 채택성이 높은 설정 메커니즘과 고객의 다양한 요구를 만족시킬 사용자 인터페이스를 갖춰야 한다. 전형적인 NMS 솔루션의 고비용을 정당화 할 수 있어야 한다.

관련 기술자료 Part 1, "Management, JMX 1.1 style" (2002년 9월) Part 2, "Beans, JMX 1.1 style" (2002년 10월)

OpenNMS: 오픈 소스 NMS
OpenNMS는 오픈 소스 분야에서는 하나의 소프트웨어 시스템이다. 이것은 개발 커뮤니티에 복잡하지만 채택가능한 NMS 솔루션의 실행파일과 소스 코드를 무료로 제공하려는 시도이다.

OpenNMS는 레거시 없이 탄생했기 때문에 보다 새로운 접근방식이 필요했다. OpenNMS는 사용자 중심의 NMS이며 전형적인 네트워크 관리자를 싱글 포인트 포커스로 두어 필요한 기능을 결정하게한다. 몇몇 안되는 구성원으로 이루어진 초기 팀은 네트워크 관리 컨설턴트이며 그들의 지식을 총동원하여 객체, 태스크, 워크플로우 관련 작동 모델을 규명했다. 이것은 상용 NMS 제품에 대비되며 디바이스 중심, 네트워크 중심, 소프트웨어 서비스 중심 성격이된다.

NMS 분석
많은 NMS 제품들은 애플리케이션의 특정 도메인, 코드 유산, 벤더와 상관 없이 유사한 개념적 구성을 갖고있다. 그림 1은 이러한 일반적 구성을 설명하고 있다.

그림 1. NMS의 개념적 구성

구성은 일반적으로 3-TIER 이다. 프론트(front) 티어는 관리되고 있는 디바이스와 서비스의 네트워크, 시스템 사용자, 외부 시스템과 인터페이싱한다. 미들 (middle) 티어에는 NMS의 기능 세트를 제공하는 많은 로직이 포함되어 있다. 백엔드(back-end) 티어는 데이터를 유지하고 조작한다.

광범위한 정보와 동적이지만 강력한 기반에서 트래킹되어야 할 복잡한 상호관계 때문에 NMS는 상용 관계형 데이터베이스 관리 시스템(RDBMS)을 백엔드 티어에 전개했다.

첫 번째 티어에서 모니터링, 관리, 제어 컴포넌트는 NMS 작동을 실행해야 하는 많은 동시 태스크들로 구성되어 있다. 액티브 네트워크 발견, 디바이스 정지 및 서비스 등록하기, 디바이스, 서비스, 고급 분산 에이전트에서 비동기식 이벤트 개입 및 프로세싱을 맡고 있다. 이 컴포넌트는 설정 로직, 제공 로직, 워크플로우 실행자, 미들 티어의 커스텀 로직에서 온 작동들 역시 수행한다.

OpenNMS의 역사 2002년 봄, OpenNMS 1.0이 탄생했다. 오픈 소스로 사용할 수 있는 최초의 엔터프리이즈급 네트워크 관리 플랫폼이 탄생한 것이다. 2002년 5월, 프로젝트의 담당자들은 OpenNMS에 지원과 컨설팅 서비스를 제공하는 Sortova Consulting Group으로 옮겼지만 개발 진화는 계속되고 있다. 1999년, 시스템 프로그래머들과 네트워크 관리 컨설턴트들은 관리 제품의 현황에 실망하고 해결책을 모색할 것을 결정했다. 상용 NMS 제품의 천문학적 비용을 감지한 팀은 오픈 소스 개발 모델을 사용하여 보다 나은 것을 개발하기로 결정했다.

또한, 프론트 티어는 사용자 인터페이스 컴포넌트이다. NMS는 "fat client GUI" 인터페이스는 물론 쉽게 커스터마이징 할 수 있는 웹 기반 사용자 인터페이스도 가지고 있다. 리포팅 장치가 이 레이어에 있으며 UI와 인터랙팅하여 실시간 소프트 카피 리포트는 물론 배치 하드 카피 리포트도 제공한다.

첫 번째 티어의 외부 인터페이싱 컴포넌트는 사용자와 외부 시스템에 공지 프로세스를 할 수 있다. 페이저호출, 이메일, 전호 호출, 특정 이벤트를 외부 관리 시스템에 전한다. API와 확장 플러그인 기반구조로 인해 NMS는 커스터마이징 될 수 있고 다른 시스템과 인터페이싱 및 통합될 수 있다.

미들 티어는 NMS의 로직이 존재하고 있는 곳이다. NMS에 구별된 기능과 특성을 부여한다. 재고 또는 자산 관리, 데이터 수집과 분석, 사용자 또는 역할 관리, 워크 플로우 관리/실행 등이 알려진 기능들이다.

재고(또는 자산) 관리는 대부분의 NMS 제품의 주요 기능이다. 트래킹되는 아이템들은 NMS에서 장비, 서킷, 서버, 설치된 소프트웨어 서비스와 애플리케이션에 이르기까지 다양하다. 이 컴포넌트의 사용자 인터페이스와 애플리케이션 로직은 관리되는 다른 아이템들에게도 유연하게 적용될 수 있다.

데이터 수집과 분석 기능은 관리되고 있는 디바이스와 서비스에 대한 현재와 기존의 통계를 제공한다. 네트워크와 서브 네트워크, 디바이스/서비스 가용성을 드러내는 통계적 분석을 제공한다. 이 컴포넌트는 커스텀 워크플로우를 핸들하기 위해 워크플로우 실행 로직과 인터랙팅 할 수 있다.

사용자와 역할 관리 컴포넌트는 NMS에 다양한 레벨의 접근을 제공한다. 가장 넓은 네트워크는 하나 이상의 팀이 관리한다. 사용자들에게 할당된 역할은 디자인과 커스텀 보안 정책의 구현 뿐만 아니라 커스텀 워크플로우와 이벤트 증대 플로우에 사용될 수 있다.

워크플로우 관리 및 실행은 장단기 관리 태스크의 관리 및 자동 실행을 제공한다. 자동화된 커스텀 워크플로우는 다양한 조직의 다양한 비지니스 요구사항에 NMS가 채택되는데 필수적인 요소이다.

NMS 모든 NMS가 이 모든 컴포넌트들을 갖고 있는 것은 아니고 어떤 것은 보다 구체화된 변이를 갖고 있을 수도 있다. 이 글에서 검토되는 것들은 NMS를 구성하고 있는 것들에 대한 일반적 개요라 할 수 있다.

OpenNMS 아키텍쳐
그림 1을 레퍼런스로 사용하여 레퍼런스 구성과 OpenNMS의 아키텍쳐 사이의 구체적 구성도를 그릴 수 있다. 그림 2는 OpenNMS를 구성하고 있는 컴포넌트이다.

그림 2. OpenNMS의 컴포넌트

백엔드 티어에서 OpenNMS는 RDBMS로서 PostgreSQL (참고자료)을 사용한다. 프론트 티어에서 Apache Jakarta Tomcat (참고자료)의 JSP와 서블릿 기술을 사용하여 유연하게 커스터마이징 할 수 있는 사용자 인터페이스를 제공한다. 기존 Perl 기반의 사용자 인터페이스 역시 사용할 수 있다. 여러 관리 유틸리티들은 UNIX 쉘 스크립트와 Perl로 작성된다. OpenNMS는 그림 1의 모니터링, 관리, 제어 컴포넌트에 상응하는 컨커런트 자바 태스크를 사용하여 이 기능을 제공한다. 이러한 동시 태스크들은 그림 2에 원으로 표현되었다.

OpenNMS 데몬: 컨커런트(concurrent) 관리 태스크
OpenNMS의 모니터링, 제어, 데이터 수집 기능들은 데몬(daemon) 이라고 하는 컨커런트 태스크에 의해 핸들된다. (BSD UNIX 규약). 표 1은 컨커런트 관리 태스크들 이다.

표 1. OpenNMS의 컨커런트 관리 태스크

Concurrent Task	daemon 이름	Description
Action daemon	actiond	자동 액션 실행 장치. 인커밍 이벤트에 근거한 자동화된 액션.
Collection daemon	collectd	관리되는 노드에서 데이터 수집.
Capability daemon	capsd	발견된 노드 상에서 기능 검사 수행. 알려진 서비스 프로토콜 지원을 위한 인터페이스 포트 점검.
DHCP daemon	dhcpd	OpenNMS에 DHCP 클라이언트 기능 제공.
Discovery daemon	discovery	관리되는 네트워크 노드의 초기 및 지속적인 발견.
Events manager daemon	eventd	다른 컨커런트 태스크에서 나온 이벤트의 관리 및 (RDBMS에) 저장
Notification daemon	notifd	외부 공지 수행.
Outage manager daemon	outaged	이벤트를 결합하여 각 관리되는 노드/서비스에 outage 뷰 제공.
Poller daemon	pollerd	관리되는 노드/서비스를 정기적으로 등록하여 작동 상태 결정.
RTC manager daemon	rtcd	실시간으로 데이터를 수집하여 관리되는 노드/서비스의 사용자 정의 카테코리에 가용성 정보 제공.
SNMP trap daemon	trapd	SNMP 트랩(이벤트) 핸들.
Threshold service daemon	threshd	특정 임계값에 도달한 애트리뷰트 값에 근거하여 노드/서비스 감시.

OpenNMS 확장하기
OpenNMS의 프론트 티어에서 특정 수직 애플리케이션 도메인에 시스템을 적용하는 것은 매우 단순하다. JSP 기술의 유연성 덕택에 OpenNMS의 사용자 인터페이스는 자바 개발자들이 쉽게 커스터마이징할 수 있다. 새로운 NMS 애플리케이션 로직은 JSP 파일과 서블릿 코딩의 결합을 통해 빠르게 추가될 수 있다.

OpenNMS는 관리되는 디바이스/서비스용 SNMP 지원이 됨으로서 표준이 되었다. SNMP는 관리가 편리한 디바이스/서비스용 산업 표준이다. 이 표준은 OpenNMS가 TCP/IP 네트워크 상에서 다양하고 광범위한 기존 디바이스를 관리 할 수 있도록 한다.

SNMP 밖에서, OpenNMS는 대중적인 소프트웨어 서비스(FTP, 파일 서버, 데이터베이스 서버)를 탐지하고 관리할 수 있다. 서비스 스팩의 플러그인을 제공하고 이를 수행하는지를 감시한다. 새로운 플러그인과 모니터를 만듦으로서 OpenNMS는 새로운 디바이스 또는 서비스를 탐지하고 감시할 정도로 확장될 수 있다.

커스텀 기능의 플러그인 만들기
OpenNMS의 디스커버리 데몬(discovery)은 관리되는 네트워크의 초기 및 지속적인 발견을 맡고있다. 일단 discovery가 노드를 발견하면 기능 데몬에게 노드가 지원하는 서비스가 무엇인지를 요청한다. 기능 데몬은 특정 프로토콜 플러그인을 통해 반복하여 서비스가 지원하는 것을 검사한다. 커스텀 프로토콜 플러그인을 작성하는 것은 단순하다. 단계는 다음과 같다:

1. org.opennms.netmgt.capsd.Plugin 인터페이스를 구현하는 클래스를 만든다. 특히 이 인터페이스는 플러그인이 구현해야 하는 세 개의 메소드를 갖고있다. (표 2):
   
   

   표 2. org.opennms.netmgt.capsd.Plugin 인터페이스의 메소드

   메소드 이름과 사인	Description
   String getProtocolName();	이 플러그인의 프로토콜 이름을 리턴한다.
   Boolean isProtocolSupported(java.nnet.InetAddress address); boolean isProtocolSupported(java.nnet.InetAddress address, java.util.Map properties);	필요할 경우 인커밍 매개변수용 프로퍼티 맵을 사용하여 이 프로토콜이 구체적인 InetAddress의 지원을 받는지를 결정한다.

   
   
   
2. /etc/capsd-configuration.xml 파일에 프로토콜-플러그인 정의를 만든다. 이것은 capsd가 시작하는 동안 사용할 프로토콜 플러그인을 결정하기 위해 읽게된다.

커스텀 폴러(poller) 모니터 만들기
OpenNMS가 관리 노드상의 서비스를 결정한 후에 폴러 데몬(pollerd)을 사용하여 관리되는 디바이스/서비스를 정기적으로 등록한다. 그들이 작동하고 있다는 것을 확인하기 위해서이다. pollerd는 지정된 폴러 모니터 "플러그인"을 통해 반복하면서 개별 서비스 폴들을 수행한다:

1. org.opennms.netmgt.poller.ServiceMonitor 인터페이스를 구현하는 클래스를 만든다. 특히 이 인터페이스는 모니터가 구현해야 하는 다섯 개의 메소드를 갖고있다. (표 3):
   
   

   표 3. org.opennms.netmgt.poller.ServiceMonitor 인터페이스의 메소드

   메소드 이름과 사인	Description
   void initialize(java.util.Map parameters); void initialize(org.opennms.netmgt.poller.NetworkInterface iface);	첫 번째 형식은 시작하는 동안 호출되어 플러그인이 초기화 중에 실행할 수 없도록 할 기회를 제공한다. 두 번째 형식은 새로운 노드가 발견될 때마다 서비스를 지원하기 위해, 그리고 첫 번째 poll()이 호출되기 전에 호출된다.
   void release(); void release(java.net.NetworkInterface iface);	첫 번째 형식은 OpenNMS 정지 시 호출된다. 두 번째 형식은 서비스를 지원하기 위해 발견된 노드가 더이상의 폴링 스케쥴에서 제거될 때 마다 호출된다.
   int poll(java.net.NetworkInterface iface, org.opennms.netmgt.utils.EventProxy eproxy, java.util.Map parameters);	감시되고 있는 서비스를 여전히 사용할 수 있는지를 결정할 때 사용되는 메소드이다. 서비스가 실행 중일 경우에는 ServiceMonitor. SERVICE_AVAILABLE을그렇지 않으면 ServiceMonitor. SERVICE_UNAVAILABLE을 리턴해야 한다.

2. /etc/poller-configuration.xml 파일에 서비스 정의와 모니터 정의를 만든다.

OpenNMS 다운로드 및 설치 리눅스 배포판과 OpenNMS의 시스템 요구사항을 숙지해야 한다. 자세한 설치 및 업데이트 절차는 이 글에서 다루지는 않는다. 참고자료 섹션에서 OpenNMS의 최신 버전 다운로드 정보를 검색할 수 있다. OpenNMS의 최신 안정 버전은 1.0.2이다. 이 글의 모든 코드는 이 안정 버전으로 테스트를 한 것이다. OpenNMS1.0.2는 세 가지 리눅스 스팩(Red Hat Linux 7 & 8, Mandrake 8)에서 테스트되었다. 복잡한 시스템으로 초기 실험 시 이 세 배포판 중 하나를 사용하기 바란다.

OpenNMS를 사용하여 JMX 가능한 ClickMeter 감시하기
capsd 플러그인과 pollerd 모니터를 만듦으로서 OpenNMS와 JMX 구동의 ClickMeter를 통합할 수 있다는 것을 알고 있다. 하지만 한가지 질문이 남아있다. OpenNMS는 JMX를 지원하지 않는가?

심지어 유명한 상용 NMS 오퍼링에서도 같은 경향을 엿볼 수 있다. JMX가 기본적으로 지원되지 않는다. JMX 구동의 디바이스와 서비스는 진행중에 있기 때문이기도하고 SNMP 호환이 제 3의 디바이스와 서비스의 관리에 제공되었기 때문이기도 하다.

JMX의 통합 과정이 NMS 벤더들 사이에서 비교적 느리게 진행되는 중요한 이유가 있다. JMX 사용 레벨과 에이전트 레벨이 1.1 스팩에는 적절히 정의되어있더라도 네트워크를 통해 JMX 에이전트에 액세스 하는 방법은 아직까지는 모호하다.

JMX Remoting 딜레마
JMX 에이전트가 네트워크 관리 애플리케이션이나 분산 서비스에 의해 네트워크를 통해 액세스되는 방법은 JMX Remoting이라고 알려져있고 이것이 JSR 160의 핵심 사안이다.(참고자료).

JSR 160은 JMX 에이전트의 발견이 네트워크를 통해서나 에이전트의 기능에 원격으로 액세스하는 구체적인 방법을 통해 어떻게 수행되는지를 정한다. 여기에는 사용될 프로토콜 어댑터 관련 스팩들이 포함될 것이다. JMX Remoting 1.2 스팩이 마감될 때까지 OpenNMS와 ClickMeter MBean을 관리하는 JMX 에이전트 사이의 통신 대안을 찾아야 한다.

JMX remoting 솔루션
물론, JMX 에이전트의 주요 목적은 이것이 관리하는 JMX MBeans로의 원격 액세스를 제공하는 것이다. 에이전트들은 커넥터와 프로토콜 어댑터를 사용하여 NMS 애플리케이션 또는 분산 서비스들과 통신한다.

ClickMeter의 경우 JMX 레퍼런스 구현의 간단한 에이전트를 사용했다. 여기에는 HTTP 프로토콜 어댑터가 포함되어 있다. 이 간단한 에이전트는 HTTP 프로토콜 어댑터를 통해 모든 MBeans의 애트리뷰트와 작동을 노출한다.

HTTP 어댑터를 사용하여 작업을 최소화하기
OpenNMS와 ClickMeter MBean 사이의 통신을 위해 JMX 레퍼런스 구현에서 간단한 에이전트와 HTTP 프로토콜을 쉽게 사용할 수 있다. 그림 3은 통신 방식을 제안한 것이다. 작동중에 OpenNMS의 capsd는 탐지된 노드를 검사하여 "CLICKMETER" 서비스가 지원되는지의 여부를 본다. pollerd는 탐지된 서비스를 정기적으로 등록하여 이들이 작동중임을 확인한다. 이러한 탐침들을 수용하기 위해서 incPanelValue 호출 작동을 사용할 수 있다. 탐침 메커니즘으로서 incPanelValue 작동을 사용하는 것의 이점은 OpenNMS의 탐지 및 등록 액션을 시각적으로 볼 수 있다는 것이다. ClickMeter의 값은 탐침 때마다 증가한다.

그림 3. HTTP 어댑터로 ClickMeter에 액세스하기

이제 남은 일은 ClickMeter MBean 에서 incPanelValue 작동에 액세스 하기 위해 HTTP 프로토콜 어댑터를 사용하는 방법을 결정하는 일이다. 브라우저를 사용하여 다음 URL에서 JMX 에이전트에 액세스할 수 있다:

http://<host of agent>:8082/

물론 이를 수행하기 전에 에이전트가 실행되는지 확인해야 한다. 그런 다음 버튼을 클릭하여 노출된 incPanelValue 작동을 실행한다. (그림 4).

그림 4. 탐침 URL 결정하기

그림 4 에서, 이 작동에 액세스하기 위해 사용된 URL은 다음과 같다:

http://<host of agent>:8082/InvokeAction//MBean:name=ClickMeter/action=incPanelValue?action=incPanelValue

ClickMeter 애플리케이션이 올바르게 기능을 발휘하고 있다면 결과페이지에는 incPanelValue Successful 이라는 문장이 뜬다. 이 정보를 사용하여 OpenNMS에서 원격으로 MBean에 액세스하겠다.

OpenNMS 통합
이제 새로운 "CLICKMETER" 서비스를 OpenNMS에 통합할 준비가 되었다. 이를 위해 capability 데몬(capsd)용 플러그인과 poller 데몬(pollerd)용 모니터를 만들것이다.

OpenNMS 디스커버리용 ClickMeterPlugin
capability 데몬 플러그인 코드는 org.opennms.netmgt.capsd.ClickMeterPlugin 클래스에 있다. 이 플러그인은 org.opennms.netmgt.capsd.Plugin 인터페이스를 구현해야 한다는 것을 알고있다. Listing 1은 AbstractPlugin 의 클래스이다. OpenNMS가 제공되는 클래스는 두 개의 매개변수 추출 메소드(getKeyedInteger() & getKeyedString())를 제공한다.

Listing 1. ClickMeterPlugin 관리 클래스

public final class ClickMeterPlugin extends AbstractPlugin { private static final String PROTOCOL_NAME = "CLICKMETER"; private static final int DEFAULT_PORT = 8082; private final static int DEFAULT_RETRY = 0; private final static int DEFAULT_TIMEOUT = 5000; // in milliseconds

getProtocolName() 메소드는 Listing 2의 코드로 간단히 구현된다:

Listing 2. getProtocolName() 메소드

public String getProtocolName() { return PROTOCOL_NAME; }

Listing 3은 isProtocolSupported() 메소드가 구현되는 방법이다:

Listing 3. isProtocolSupported() 메소드

public boolean isProtocolSupported(InetAddress address) { return isClickMeter(address, DEFAULT_PORT, DEFAULT_RETRY, DEFAULT_TIMEOUT); }

보다 긴 버전의 isProtocolSupported() 메소드에서는, 원격 JMX 에이전트에 액세스하는 URL을 만드는데 사용되는 인커밍 매개변수를 처리한다. 일단, IP와 포트가 매개변수에서 얻어지면, isProtocolSupported()는 isClickMeter() 메소드를 호출하여 ClickMeter가 이 노드에서 활성인지를 결정한다. Listing 4는 isClickMeter()에 대한 코드이다. URL용으로 정의된 두 개의 상수가 ClickMeter의 incPanelValue 작동을 위한 HTTP 프로토콜 어댑터 액세스 URL과 상응한다는 것에 주목하라.

Listing 4. isClickMeter() 메소드

private final static String CLICK_METER_BEAN_LOCATOR_URL = "/InvokeAction//MBean:name=ClickMeter/action=incPanelValue? action=incPanelValue"; private final static String CLICK_METER_ID = "incPanelValue Successful"; private boolean isClickMeter(InetAddress host, int port, int retries, int timeout) { Category log = ThreadCategory.getInstance(getClass()); boolean foundClickMeter = false; for (int attempts=0; attempts <= retries && !foundClickMeter; attempts++) { URL jmxLink = null; InputStream iStream = null; try { String hostIP = host.getHostAddress(); jmxLink = new URL("http", hostIP, port, CLICK_METER_BEAN_LOCATOR_URL); if (scanURL(jmxLink, CLICK_METER_ID, log)) { foundClickMeter = true; break; // get out of the for loop } } catch(IOException e) { log.info("ClickMeterPlugin: Error communicating with host " + host.getHostAddress(), e); foundClickMeter = false; } } return foundClickMeter; }

scanURL() 메소드(Listing 5)는 인자로서 URL과 스트링을 취하는 헬퍼 메소드이다. 이것은 URL에 액세스하고 결과 페이지에서 지정된 스트링을 찾는다. 스트링이 발견되면 true를 리턴한다. 그렇지 않을 경우 false를 리턴한다. 이 경우, ClickMeter의 incPanelValue 작동용 URL에 액세스한 후에 incPanelValue Successful 스트링을 찾고있다.

Listing 5. scanURL() 메소드

private boolean scanURL(URL inURL, String toSearch, Category log) { InputStream iStream = null; try { iStream = inURL.openStream(); BufferedReader urlReader = new BufferedReader(new InputStreamReader(iStream)); String curLine = urlReader.readLine(); do { if (curLine.indexOf(toSearch) != -1) { return true; } curLine = urlReader.readLine(); } while (curLine != null); } catch (IOException e) { e.fillInStackTrace(); log.debug("ClickMeterMonitor.poll: Error reading from URL:" + inURL, e); } finally { try { if(iStream != null) iStream.close(); } catch(IOException e) { e.fillInStackTrace(); log.debug("ClickMeterMonitor.poll: Error closing stream to URL.", e); } } return false; }}

플러그인 통합에 필요한 두 번째 단계는 <OpenNMS installation directory>/etc/capsd-configuration.xml 파일을 편집하고 프로토콜-플러그인 정의를 추가하는 것이다.(Listing 6):

Listing 6. 프로토콜-플러그인 정의

<protocol-plugin protocol="CLICKMETER" class-name="org.opennms.netmgt.capsd.ClickMeterPlugin" scan="on" > <property key="port" value="8082"/> <property key="timeout" value="2000"/> <property key="retry" value="1"/> </protocol-plugin>

OpenNMS가 관리되는 노드를 검사해야할 IP 범위를 제한하기 위해 discovery-configuration.xml 파일을 편집하고 싶을 것이다. Listing 7에서는 두 개의 IP로 제한하여 ClickMeter 애플리케이션이 빨리 위치할 수 있도록 한다:

Listing 7. 디스커버리 범위 제한

<include-range retries="2" timeout="3000"> <begin>192.168.23.75</begin> <end>192.168.23.76</end> </include-range>

OpenNMS용 ClickMeterMonitor
다음에는, poller 데몬(pollerd) 모니터 플러그인, org.opennms.netmgt.poller.ClickMeterMonitor 클래스를 만든다: 이 클래스는 org.opennms.netmgt.poller.ServiceMonitor 인터페이스를 구현해야 한다. OpenNMS는 이 인터페이스의 모든 메소드용 디폴트 구현을 갖고있는 기본 클래스(org.opennms.netmgt.poller.IPv4Monitor)를 제공한다. 특별한 초기화나 릴리스가 필요없기 때문에 poll() 메소드를 오버라이딩 하면된다.(Listing 8):

Listing 8. poll() 메소드

public int poll(NetworkInterface iface, Map parameters) { if(iface.getType() != NetworkInterface.TYPE_IPV4) throw new NetworkInterfaceNotSupportedException("Unsupported interface type, only TYPE_IPV4 currently supported"); Category log = ThreadCategory.getInstance(getClass()); int retry = getKeyedInteger(parameters, "retry", DEFAULT_RETRY); int port = getKeyedInteger(parameters, "port", DEFAULT_PORT); int timeout = getKeyedInteger(parameters, "timeout", DEFAULT_TIMEOUT); InetAddress ipv4Addr = (InetAddress)iface.getAddress(); String hostIP = ipv4Addr.getHostAddress(); if (log.isDebugEnabled()) log.debug("ClickMeterMonitor.poll: Polling interface: " + hostIP + " timeout: " + timeout + " retry: " + retry); int serviceStatus = ServiceMonitor.SERVICE_UNAVAILABLE; for (int attempts=0; attempts <= retry && serviceStatus != ServiceMonitor.SERVICE_AVAILABLE; attempts++) { URL jmxLink = null; InputStream iStream = null; try { jmxLink = new URL("http", hostIP, port, CLICK_METER_BEAN_LOCATOR_URL); if (scanURL(jmxLink, CLICK_METER_ID, log)) { serviceStatus = ServiceMonitor.SERVICE_AVAILABLE; break; } } catch(IOException e) { e.fillInStackTrace(); log.debug("ClickMeterMonitor.poll: IOException while polling address: " + ipv4Addr, e); } } // of for return serviceStatus; }

scanURL() 헬퍼 메소드(Listing 8)를 사용하여 ClickMeter MBean에 액세스한다는 것에 주목하라.

<OpenNMS installation directory>/etc/poller-configuration.xml 파일에서, 서비스 정의 엔트리를 추가해야 한다. Listing 9에서 폴링 간격을 10,000 밀리초로 정했다:

Listing 9. poller 데몬 서비스 정의

<service name="CLICKMETER" interval="10000" user-defined="false" status="on"> <parameter key="timeout" value="3000"/> <parameter key="port" value="8082"/> </service>

같은 poller-configuration.xml 파일에 모니터 정의를 삽입해야 한다. (Listing 10):

Listing 10. poller 데몬 모니터 정의

<monitor service="CLICKMETER" class-name="org.opennms.netmgt.poller.ClickMeterMonitor" />

ClickMeter 서비스로 OpenNMS 테스트하기
소스에서 두 개의 플러그인을 구현하려면 compile.bat 파일을 사용한다. 몇몇 OpenNMS 라이브러리 파일을 <article code distribution>/lib 디렉토리에 복사해야 할 것이다. compile.bat 파일은 dwClickMeterJMX.jar를 만든다. 이 결과 JAR 파일을 <OpenNMS installation directory>/lib 디렉토리에 놓으면 OpenNMS는 시작할 때 자동적으로 새로운 플러그인을 로딩하게 된다.

반드시 OpenNMS의 웹 기반 GUI에 액세스하여 시스템을 시작하라. 일반적인 URL은 다음과 같다:

http://<host of OpenNMS>:8080/opennms/

프롬프트되면 userid에는 admin을 패스워드에는 admin을 사용한다. (그림 5):

그림 5. OpenNMS 시작 스크린

OpenNMS가 시작하는 동안 두번이나 빠르게 증가하는 ClickMeter 카운트를 보게된다. ClickMeter는 pollerd가 작동할 때 보통 10초 간격으로 증가한다.

일단 capsd가 ClickMeter 애플리케이션을 탐지하면 이를 관리 서비스로서 RDBMS에 추가 할 것이다. 제품의 경우 OpenNMS의 자산 관리 기능들은 이 서비스를 보다 자세히 범주화 해 놓을 수 있다. 우리 실험에서는 OpenNMS GUI를 사용하여 ClickMeter 서비스를 연구하고 이에 개입된 자세한 이벤트를 볼 수 있다.(그림 6):

그림 6. ClickMeter 서비스를 관리하는 OpenNMS

참고자료

• 소스코드& 스크립트 파일 다운로드.
  
  
• OpenNMS 웹 사이트.
  
  
• 미러 사이트.
  
  
• 공식 Tomcat 사이트.
  
  
• Java Management Extensions (JMX).
  
  
• MX4J 프로젝트.
  
  
• IETF RFC 1157 & SNMP Version 3.
  
  
• Distributed Management Task Force 웹 사이트.
  
  
• Apache Jakarta Project.
  
  
• JSR 160 JMX Remoting 1.2, JSR 146 WBEM Services, JSR 70 IIOP Protocol Adapter for JMX.
  
  
• J2EE Connector architecture.
  
  
• J2EE 1.4 specification.
  
  
• Tivoli.
  
  
• Tivoli Developer Domain.
  
  
• TMX4J.
  
  
• developerWorks Java technology zone.