부록 A SNMP 지원

Messaging Server는 SNMP(Simple Network Management Protocol)를 통한 시스템 모니터링을 지원합니다. Sun Net Manager 또는 HP OpenView(이 제품에서 제공되지 않음)와 같은 SNMP 클라이언트(경우에 따라 네트워크 관리자라고 부름)를 사용하면 Messaging Server의 일정 부분을 모니터할 수 있습니다. Messaging Server 모니터링에 대한 자세한 내용은 27 장, Messaging Server 모니터링을 참조하십시오.

이 장에서는 Messaging Server에서 SNMP 지원을 사용하는 방법에 대해 설명합니다. 또한, SNMP에 의해 제공되는 정보 유형에 대한 개요를 제공합니다. 하지만 SNMP 클라이언트에서 이 정보를 보는 방법에 대해서는 설명하지 않습니다. SNMP 클라이언트를 사용하여 SNMP 기반 정보를 보는 방법에대한 자세한 내용은 SNMP 클라이언트 설명서를 참조하십시오. 또한, 이 문서에는 Messaging Server SNMP 구현에서 사용 가능한 일부 데이터에 대해 설명되어 있지만 전체 MIB 정보는 RFC 2788 및 RFC 2789에서 이용할 수 있습니다.

이 장은 다음 내용으로 구성되어 있습니다.

• A.1 SNMP 구현

• A.2 Solaris 9에서 Messaging Server에 대한 SNMP 지원 구성

• A.3 Solaris 10 OS에 대한 SNMP 지원 구성

• A.4 SNMP 클라이언트로부터 모니터링

• A.5 Messaging Server의 SNMP 정보

A.1 SNMP 구현

Messaging Server는 Network Services Monitoring MIB(RFC 2788)와 Mail Monitoring MIB(RFC 2789)의 두 표준화된 MIB를 구현합니다. Network Services Monitoring MIB는 POP, IMAP, HTTP 및 SMTP 서버와 같은 네트워크 서비스 모니터링을 위해 제공됩니다. Mail Monitoring MIB는 MTA 모니터링을 위해 제공됩니다. Mail Monitoring MIB를사용하면 각 MTA 채널의 활성 상태와 비활성 상태를 모두 모니터할 수 있습니다. 활성 정보에는 주로 현재 대기열에 포함된 메시지와 열린 네트워크 연결(예: 대기열에 있는 메시지 개수, 열린 네트워크 연결의 소스 IP 주소)에 대한 정보가 있고, 비활성 정보에는 누적 합계(예: 처리된 총 메시지 수, 총 인바운드 연결)가 제공됩니다.

전체 Messaging Server SNMP 모니터링 정보 목록은 RFC 2788 및 RFC 2789를 참조하십시오.

SNMP는 Solaris 및 Red Hat Linux를 실행하는 플랫폼에서 지원됩니다. Solaris 9 운영 체제의 Messaging Server는 SEA(Solstice Enterprise Agents)를 사용합니다. Solaris 10 운영 체제부터 Messaging Server는 오픈 소스 Net-SNMP 모니터링 프레임워크를 지원하며 Solaris 9 OS SEA(Solstice Enterprise Agents) 기술을 레거시(단종 조치) 상태로 분류합니다. 또한 Net-SNMP는 Linux 플랫폼에서 널리 사용됩니다. Messaging Server는 Solaris 10 이상과 Linux 플랫폼에서 Net-SNMP 기반 SNMP 하위 에이전트를 사용합니다.

Net-SNMP 프레임워크를 채택하여 Messaging Server의 SNMP 하위 에이전트는 다음과 같은 새로운 기능을 제공합니다.

• SNMP 버전 2c 및 3을 지원합니다. 이 지원은 Net-SNMP 프레임워크에서 제공합니다. 이전 SNMP 기술인 Solstice Enterprise Agents는 SNMP 버전 1만 지원했습니다. 향상된 보안 기능과 액세스 제어는 이 두 SNMP 버전의 주요 이점입니다.

• 하위 에이전트를 "독립형" SNMP 에이전트로 실행되도록 구성할 수 있습니다. 그러면 사이트에서 동일한 시스템에서 실행 중인 다양한 SNMP 에이전트를 격리시킬 수 있습니다.

• 동일한 시스템에서 실행 중인 여러 Messaging Server "인스턴스"를 동시에 모니터링할 수 있습니다. 이 지원은 위 두 항목 중 하나 또는 SNMP 버전 3 "컨텍스트 이름"을 사용하여 제공됩니다. 이 지원을 사용하면 페일오버 클러스터에서 Messaging Server의 SNMP 모니터링이 가능합니다.

Messaging Server SNMP 지원 제한은 다음과 같습니다.

• 각 호스트 컴퓨터에서는 Solaris 9 OS의 SNMP를 통해 Messaging Server 인스턴스를 하나씩만 모니터링할 수 있습니다.

• SNMP 지원은 모니터링 전용입니다. SNMP 관리는 지원되지 않습니다.

• SNMP 트랩이 구현되지 않습니다. RFC 2788은 트랩을 사용하지 않는 유사한 기능을 제공합니다.

A.1.1 Messaging Server에서의 SNMP 작업

Messaging Server SNMP 프로세스는 시작할 때 플랫폼의 원시 SNMP 마스터 에이전트를 사용하여 자체 등록되는 SNMP 하위 에이전트입니다. 클라이언트의 SNMP 요청은 마스터 에이전트로 전달됩니다. 마스터 에이전트는 Messaging Server가 대상인 모든 요청을 Messaging Server 하위 에이전트 프로세스에 전달합니다. Messaging Server 하위 에이전트 프로세스에서는 해당 요청을 처리하고 마스터 에이전트를 통해 클라이언트에게 응답을 릴레이합니다. 이 프로세스는 그림 A–1에 표시되어 있습니다.

그림 A–1 SNMP 정보 흐름

A.2 Solaris 9에서 Messaging Server에 대한 SNMP 지원 구성

SNMP 모니터링으로 인한 오버헤드는 매우 작지만 Messaging Server는 SNMP 지원을 비활성화한 상태로 제공됩니다. SNMP 지원을 사용하려면 다음 명령을 실행합니다.

# su user-id-for-ims
# configutil -o local.snmp.enable -v 1
# start-msg snmp

SNMP를 활성화하면 매개 변수를 지정하지 않더라도 start-msg 명령이 다른 Messaging Server 프로세스와 함께 SNMP 하위 에이전트 프로세스를 자동으로 시작합니다.

Messaging Server SNMP 하위 에이전트를 작동하려면 Solaris 원시 SNMP 마스터 에이전트를 실행해야 합니다. Solaris 원시 SNMP 마스터 에이전트는 일반적으로 Solaris 부트 절차의 일부로 시작되는 snmpdx 데몬입니다.

SNMP 하위 에이전트는 수신할 UDP 포트를 자동으로 선택합니다. 필요한 경우 다음 명령을 사용하여 하위 에이전트에 고정 UDP 포트를 지정할 수 있습니다.

# configutil -o local.snmp.port -v port-number

나중에 포트 번호로 값 0을 지정하여 이 설정을 취소할 수 있습니다. 기본 설정인 값 0은 Messaging Server에서 하위 에이전트가 사용 가능한 UDP 포트를 자동으로 선택할 수 있도록 합니다.

/etc/snmp/conf 디렉토리에는 두 개의 SNMP 하위 에이전트 구성 파일인 SNMP 액세스 제어 정보를 포함하는 ims.acl과 SNMP MIB OID 등록 정보를 포함하는 ims.reg가 있습니다.

일반적으로 이러한 파일은 편집할 필요가 없습니다. Messaging Server에서 제공하는 MIB는 읽기 전용이며 ims.reg 파일에서 포트 번호를 지정할 필요가 없습니다. 포트 번호를 지정하는 경우 configutil 유틸리티를 사용하여 다른 포트를 설정할 때까지는 해당 포트가 적용됩니다. 그럴 경우 하위 에이전트에서는 configutil을 사용하여 설정한 포트 번호를 사용합니다. 파일을 편집하는 경우 변경 내용을 적용하려면 SNMP 하위 에이전트를 중지하고 다시 시작해야 합니다.

# stop-msg snmp
# start-msg snmp

Messaging Server에서 SNMP 지원을 활성화한 상태에서 Solaris 10 OS에서 생성한 SNMP 쿼리는 기본 포트 16161에 연결되어야 합니다. 예를 들어, 오픈 소스 SNMP 도구 snmpwalk를 사용하여 Messaging Server에 대한 네트워크/메일 통계를 쿼리하는 경우 -p 16161 옵션을 사용합니다.

A.3 Solaris 10 OS에 대한 SNMP 지원 구성

기본적으로 SNMP 모니터링은 Messaging Server에서 비활성화됩니다. 기본 Messaging Server 구성에서 제공되는 서비스 수를 최소화하려면 이 기본값을 선택합니다. 이 기본값을 SNMP 모니터링을 사용하여 성능 감소가 발생한다는 의미로 해석하지 마십시오. 실제로 Messaging Server의 SNMP 지원은 매우 적은 자원을 사용하며 메시징 서버에 가장 적은 영향을 줍니다. 결론적으로 Messaging Server의 SNMP 지원을 사용하려면 구성 단계를 한 번 수행해야 합니다. 또한 Messaging Server와 같은 하위 에이전트를 실행하려면 플랫폼 Net-SNMP 마스터 에이전트 snmpd의 기본 구성을 변경해야 합니다. 이러한 변경에 대해서는 다음 절에서 설명합니다.

A.3.1 Net-SNMP 구성

Messaging Server의 Net-SNMP 기반 SNMP 하위 에이전트는 AgentX 프로토콜을 사용하여 플랫폼의 SNMP 마스터 에이전트(RFC 2741)와 통신합니다. AgentX 프로토콜을 사용하도록 Net-SNMP 마스터 에이전트 snmpd를 구성해야 합니다. 그렇게 하려면 플랫폼의 snmpd.conf 파일에 다음과 같은 행이 있어야 합니다.

master agentx

이 행이 없으면 해당 행을 추가한 다음 snmpd 데몬을 다시 시작합니다. 데몬에 SIGHUP 신호를 보내는 것으로는 충분하지 않습니다. snmpd 데몬을 다시 시작한 후 snmpd가 AgentX 통신을 위해 만드는 UNIX 도메인 소켓을 찾습니다. Solaris 및 Linux 시스템에서 이 소켓은 기본적으로 /var/agentx/master라는 특수 파일로 표시됩니다. 해당 위치와 이름은 snmpd.con 파일을 통해 변경할 수 있습니다.

Solaris 10 OS snmpd 구성은 아래와 같이 표시됩니다.

%cp /etc/sma/snmp/snmpd.conf /etc/sma/snmp/snmpd.conf.save
% cat >> /etc/sma/snmp/snmpd.conf
# Messaging Server's subagent requires the AgentX protocol
master agentx
^D
% cat >> /etc/sma/snmp/snmpd.conf
% ls -al /var/agentx/
srwxrwxrwx 1 root root 0 Aug 9 13:58 /var/agentx/master

또한 Red Hat Enterprise Linux AS 3 시스템에서 기본 snmpd.conf 파일은 "공개" SNMP 커뮤니티에서 볼 수 있는 정보를 제한합니다. 따라서 해당 제한을 제거하거나 Messaging Server의 하위 에이전트에서 제공하는 MIB를 포함하도록 확장해야 합니다. 최초 테스트를 위해 확장할 것을 권장합니다. 그렇게 하려면 아래 표시된 대로 OID 하위 트리 mib-2.27 및 mib-2.28를 "systemview"라는 보기에 포함시킵니다. 실제 배포를 위해 각 사이트에서 전체 보안 정책을 고려해야 합니다. SNMP 하위 에이전트에서 제공하는 정보는 "읽기 전용"입니다.

% cp /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.save
% cat >>/etc/snmp/snmpd.conf
# Messaging Server's subagent requires the AgentX protocol
master agentx
# Messaging Server's subagent exports mib-2.27 and .28
# Add the mib-2.27 and .28 OID subtrees to the systemview
view systemview included .1.3.6.1.2.1.27
view systemview included .1.3.6.1.2.1.28
^D
% /sbin/service snmpd restart
% ls -al /var/agentx/master
srwxr-xr-x 1 root root 0 Aug 8 21:20 /var/agentx/master

SNMP v3 컨텍스트 이름을 사용하여 동일한 호스트 컴퓨터에서 동시에 실행 중인 다양한 Messaging Server 인스턴스의 MIB를 구별할 경우 SNMP v3 쿼리에 사용할 하나 이상의 SNMP v3 사용자 아이디와 비밀번호를 구성해야 합니다.

A.3.2 Messaging Server 하위 에이전트 구성

Messaging Server SNMP 하위 에이전트의 기본 작업을 위해서는 하위 에이전트를 활성화한 다음 수동 시작 명령을 한 번만 실행하면 됩니다. 그 이후에는 Messaging Server가 시작되거나 중지될 때마다 하위 에이전트도 함께 시작되거나 중지됩니다. Solaris와 Linux 모두에서 이 구성을 적용하는 데 필요한 명령은 다음과 같습니다.

% configutil -o local.snmp.enable -v 1
% start-msg snmp

이 명령을 실행한 후 명령줄에서 snmpwalk 명령을 사용하여 하위 에이전트를 테스트할 수 있습니다. Solaris 및 Linux에 해당하는 예제 아래의 스크린 샷을 참조하십시오. rfc2248.txt 및 rfc2249.txt 파일은 Network Services 및 MTA MIB의 복사본입니다. Solaris 시스템에서는 이러한 파일이 /etc/sma/snmp/mibs/ 디렉토리에 NETWORK-SERVICES-MIB.txt 및 MTA-MIB.txt 이름으로 존재할 수도 있습니다. 이러한 파일을 snmpwalk 도구에 제공할 필요는 없지만, 그렇게 하면 snmpwalk에서 숫자 객체 식별자(OID) 대신 각 MIB 변수의 이름을 인쇄할 수 있습니다.

Solaris에서의 기본 테스트:

% D=/opt/SUNWmsgsr/examples/mibs /usr/sfw/bin/snmpwalk -v 1 -c public \
    -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.27
NETWORK-SERVICES-MIB::applName.1 = STRING: /opt/SUNWmsgsr MTA on mail.siroe.com
...
% D=/opt/SUNWmsgsr/examples/mibs /usr/sfw/bin/snmpwalk -v 1 -c public \
     -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.28
MTA-MIB::mtaReceivedMessages.1 = Counter32: 1452
MTA-MIB::mtaStoredMessages.1 = Gauge32: 21
...

Linux에서의 기본 테스트:

% export D=/opt/sun/messaging/examples/mibs
% /usr/bin/snmpwalk -v 1 -c public \
     -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.27
NETWORK-SERVICES-MIB::applName.1 = STRING: /opt/sun/messaging MTA on mail.siroe.com
...
% /usr/bin/snmpwalk -v 1 -c public \
     -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.28
MTA-MIB::mtaReceivedMessages.1 = Counter32: 21278
MTA-MIB::mtaStoredMessages.1 = Gauge32: 7
...

A.3.3 독립형 SNMP 에이전트로 실행

Messaging Server의 SNMP 하위 에이전트를 독립형 SNMP 에이전트로 실행되도록 구성하기 전에 SNMP 요청을 수신하는 데 사용할 이더넷 인터페이스와 UDP 포트를 결정해야 합니다. 기본적으로 SNMP 하위 에이전트는 UDP 포트 161을 사용하여 사용 가능한 모든 이더넷 인터페이스를 수신합니다. 대부분의 경우 플랫폼의 SNMP 마스터 에이전트인 snmpd를 방해하지 않도록 포트 번호를 변경할 수 있습니다. HA 페일오버와 같은 일부 환경에서는 이더넷 인터페이스를 사용 가능한 모든 인터페이스(INADDR_ANY)에서 IP 주소로 식별되는 특정 인터페이스로 변경할 수도 있습니다. 이더넷 인터페이스 및 UDP 포트의 두 개념은 local.snmp.listenaddr 및 local.snmp.port 옵션을 통해 제어됩니다.

이더넷 인터페이스와 UPD 포트를 선택하면 local.snmp.standalone 옵션의 값이 설정되고 하위 에이전트가 다시 시작됩니다. 그러면 하위 에이전트가 snmpd 및 모든 하위 에이전트에 독립적으로 SNMP 에이전트로 작동합니다.

예를 들어, IP 주소 10.53.1.37를 사용하여 이더넷 인터페이스의 UDP 포트 9161을 수신하는 독립형 에이전트로 실행하려면 다음과 같은 명령을 실행합니다.

독립형 에이전트로 실행하도록 구성:

% configutil -o local.snmp.port -v 9161
% configutil -o local.snmp.listenaddr -v 10.53.1.37
% configutil -o local.snmp.standalone -v 1
% stop-msg snmp
% start-msg snmp
% snmpwalk -v 1 -c public 10.53.1.37:9161 .
SNMPv2-SMI::mib-2.27.1.1.2.1 = STRING: "/opt/SUNWmsgsr MTA on mail.siroe.com"
...

A.3.4 여러 Messaging Server 인스턴스 모니터링

여기서는 동일한 호스트 컴퓨터에서 실행 중인 여러 Messaging Server 인스턴스를 모니터링하는 두 가지 기술에 대해 설명합니다. 독립형 모드에서 하위 에이전트를 실행하는 첫 번째 기술은 Messaging Server의 개별 인스턴스가 호스트 컴퓨터 사이에서 동적으로 이동할 수 있는 고가용성(HA) 페일오버 구성에 적합합니다. SNMP v3 컨텍스트 이름을 사용하는 두 번째 기술은 Messaging Server의 여러 인스턴스가 단일 시스템으로 한정되고 SNMP 모니터링 소프트웨어에 의해 폴링되는 IP 주소 수를 제한하려는 경우(예: 모니터링 소프트웨어 라이센스 비용이 IP 주소 단위로 부과되는 경우)에 몇 가지 제한된 이점을 제공합니다. 이 두 번째 기술은 HA 페일오버 설정에서도 사용될 수 있지만 독립형 모드 기술과 같은 수의 IP 주소만큼만 폴링해야 합니다.

A.3.5 고가용성 페일오버를 위해 독립형 에이전트 사용

Messaging Server의 SNMP 모니터링이 요구되는 고가용성 페일오버 설정에서는 A.3.3 독립형 SNMP 에이전트로 실행에서 설명한 것처럼 Messaging Server의 SNMP 하위 에이전트를 독립형 에이전트로 실행하는 것이 좋습니다. 하위 에이전트가 독립형 모드로 실행되는 경우 Messaging Server의 각 HA 인스턴스는 local.snmp.listenaddr 옵션이 해당 인스턴스의 페일오버 IP 주소 값으로 설정되어야 합니다. 관리를 간소화하기 위해 각 인스턴스는 동일한 UDP 포트를 사용하지만 각 물리적 클러스터 호스트에서 실행 중인 snmpd 데몬에서 사용되는 포트와 구별되어야 합니다. 일반적으로 이러한 데몬은 UDP 포트 161을 사용하므로 local.snmp.port 옵션을 통해 다른 포트 번호를 명시적으로 지정합니다.

Messaging Server의 SNMP 지원을 여기에 권장된 대로 구성한 경우 모니터링 스테이션은 인스턴스가 실행 중인 물리적 클러스터 호스트에 상관없이 페일오버 IP 주소 또는 호스트 이름을 통해 Messaging Server의 각 인스턴스를 모니터링할 수 있습니다. 또한 Messaging Server의 독립형 SNMP 에이전트는 각각 인스턴스의 고유한 페일오버 IP 주소로 식별되는 해당 가상 이더넷 인터페이스만 수신하기 때문에 서로 충돌하지 않습니다. 이러한 가상 이더넷 인터페이스는 HA 페일오버 프레임워크에서 자동으로 생성됩니다. UDP 포트를 신중하게 선택했기 때문에 에이전트가 클러스터 내의 시스템에서 실행 중인 snmpd 데몬과 충돌하지 않습니다.

A.3.6 SNMP v3 컨텍스트 이름을 통해 여러 인스턴스 구별

A.3.3 독립형 SNMP 에이전트로 실행에서 설명한 것처럼 Messaging Server의 SNMP 지원을 독립형 모드로 사용할 때의 단점은 없지만, 일부 사이트에서는 동일한 시스템에서 동시에 실행 중인 여러 Messaging Server 인스턴스를 모니터링하는 기능을 유지하면서 많은 기존의 하위 에이전트 모드를 사용하는 것이 더 좋을 수도 있습니다. 예를 들어, 라이센스 모델에 의해 폴링될 수 있는 IP 주소 수가 제한되는 SNMP 모니터링 시스템이 있습니다. 이렇게 하려면 local.snmp.standalone을 0으로 설정한 상태에서 Messaging Server의 SNMP 하위 에이전트를 계속 실행합니다. 또는 local.snmp.enablecontextname 옵션을 0이 아닌 값으로 지정하여 각 Messaging Server 인스턴스가 고유한 SNMP v3 컨텍스트 이름을 사용하도록 구성합니다. service.defaultdomain 값과 다른 컨텍스트 이름을 지정하려면 local.snmp.contextname 옵션을 사용하여 원하는 이름을 설정합니다. Messaging Server의 각 SNMP 하위 에이전트 인스턴스가 다시 시작되면 SNMP v3 쿼리를 통해 해당 컨텍스트 이름을 포함하는 인스턴스를 모니터링할 수 있습니다. 동일한 시스템에서 실행되는 두 Messaging Server 인스턴스의 MIB는 인스턴스의 SNMP v3 컨텍스트 이름을 통해 구별되므로 MIB 객체 식별자(OID) 충돌이 발생하지 않습니다.

A.3.7 Messaging Server의 Net-SNMP 기반 SNMP 하위 에이전트 옵션

다음은 Messaging Server의 Net-SNMP 기반 SNMP 하위 에이전트에만 적용되는 옵션입니다. 이 하위 에이전트는 Solaris 10 이상을 실행하는 Solaris 플랫폼과 Linux 플랫폼에서 사용됩니다. 아래 설명된 옵션은 Solaris 9 이하의 운영 체제를 실행하는 Solaris 플랫폼용으로 제공된 레거시 SNMP 하위 에이전트에는 적용되지 않습니다.

아래 설명하는 옵션은 configutil 옵션입니다. 따라서 다음과 같은 형식의 명령을 사용하여 해당 값을 검사합니다.

% configutil -o option-name

여기서 option-name은 값을 표시할 옵션의 이름입니다. 옵션의 값을 설정하거나 변경하려면 다음과 같은 형식의 명령을 사용합니다.

% configutil -o option-name -v option-value

여기서 option-value는 설정할 값입니다. 이 옵션에 대한 변경 사항을 적용하려면 다시 시작해야 합니다.

% stop-msg snmp
% start-msg snmp

다음은 각 옵션에 대한 설명과 해당 옵션의 기본값입니다.

A.4 SNMP 클라이언트로부터 모니터링

RFC 2788 및 RFC 2789의 기본 OID는 다음과 같습니다.

mib-2.27 = 1.3.6.1.2.1.27

mib-2.28 = 1.3.6.1.2.1.28

이러한 두 OID에서 SNMP 클라이언트를 가리키고 “공개” SNMP 커뮤니티로 액세스합니다.

MIB 복사본을 SNMP 클라이언트에 로드하려는 경우 MIB의 ASCII 복사본은 msg-svr-base/lib/config-templates 디렉토리에 rfc2788.mib 및 rfc2789.mib 파일 이름으로 존재합니다. 이러한 MIB을 SNMP 클라이언트 소프트웨어에 로드하는 것과 관련된 지침은 SNMP 클라이언트 소프트웨어 설명서를 참조하십시오. 일부 이전 SNMP 클라이언트에서는 이러한 MIB에 사용되는 SnmpAdminString 데이터 유형을 인식하지 못할 수 있습니다. 그럴 경우 동일한 디렉토리에 있는 rfc2248.mib 및 rfc2249.mib 파일을 사용합니다.

A.5 Messaging Server의 SNMP 정보

이 절에서는 SNMP를 통해 제공되는 Messaging Server 정보를 요약합니다. 이 절은 다음 내용으로 구성되어 있습니다.

• A.5.1 applTable

• A.5.2 assocTable

• A.5.3 mtaTable

• A.5.4 mtaGroupTable

• A.5.5 mtaGroupAssociationTable

• A.5.6 mtaGroupErrorTable

자세한 내용은 RFC 2788 및 RFC 2789의 개별 MIB 테이블을 참조하십시오. RFC/MIB 용어로 메시징 서비스(MTA, HTTP 등)는 응용 프로그램(appl), Messaging Server 네트워크 연결은 연결(assoc), MTA 채널은 MTA 그룹(mtaGroups)입니다.

두개 이상의 Messaging Server 인스턴스를 동시에 모니터할 수 있는 플랫폼의 경우 applTable에 여러 MTA 및 서버 집합이 있고 다른 테이블에 여러 MTA가 있을 수 있습니다.

MIB에 보고되는 누적 값(예: 전달된 총 메시지 수, 총 IMAP 연결 수 등)은 재부트 후에 다시 0으로 설정됩니다.

사이트별로 임계값과 중요 모니터링 값이 다릅니다. 정상적인 SNMP 클라이언트에서는 추세 분석을 수행하여 기록된 추세와 편차가 발생할 경우 경고를 보냅니다.

A.5.1 applTable

applTable은 서버 정보를 제공합니다. MTA 행 하나와 각각의 서버(WebMail HTTP, IMAP, POP, SMTP 및 SMTP Submit, 활성화된 경우)에 대한 추가적인 행이 제공되는 1차원적 테이블입니다. 이 테이블에서는 버전 정보, 가동 시간, 현재 작업 상태(실행, 중단, 정체), 현재 연결 수, 총 누적 연결 수 및 기타 관련 데이터를 제공합니다.

다음은 applTable(mib-2.27.1.1)의 데이터 예입니다.

            
applTable:

    applName.1  = mailsrv-1  MTA on mailsrv-1.west.sesta.com      (1)
    applVersion.1 = 5.1
    applUptime.1 = 7322                         (2)
    applOperStatus.1 = up                       (3)
    applLastChange.1 = 7422                     (2)
    applInboundAssociations.1 =                 (5)
    applOutboundAssociations.1 =                (2)
    applAccumulatedInboundAssociations.1 = 873
    applAccumulatedOutboundAssociations.1 = 234
    applLastInboundActivity.1 = 1054822          (2)
    applLastOutboundActivity.1 = 1054222         (2)
    applRejectedInboundAssociations.1 = 0        (4)
    applFailedOutboundAssociations.1 = 17
    applDescription.1 = Sun Java System Messaging Server 6.1
    applName.2 1 = mailsrv-1 HTTP WebMail svr. mailsrv-1.sesta.com (1)
    ...
    applName.3 = mailsrv-1 IMAP server on mailsrv-1.west.sesta.com
    ...
    applName.4 = mailsrv-1 POP server on mailsrv-1.west.sesta.com
    ...
    applName.5 = mailsrv-1 SMTP server on mailsrv-1.west.sesta.com
    ...
    applName.6 = mailsrv-1 SMTP Submit server on mailsrv-1.west.sesta.com
    ...

주:

1. 응용 프로그램(.appl*) 접미어(.1, .2 등)는 행 번호 applIndex입니다. applIndex에서 값 1은 MTA, 값 2는 HTTP 서버 등을 나타냅니다. 따라서 이 예에서 테이블의 첫 번째 행에는 MTA에 관한 데이터가 제공되고 두 번째 행에는 POP 서버에 관한 데이터가 제공됩니다.

   등호 뒤에 있는 이름은 모니터할 Messaging Server 인스턴스의 이름입니다. 이 예에서 인스턴스 이름은 mailsrv-1입니다.

2. 이러한 값은 SNMP 타임스탬프 값이고 이벤트 시간의 sysUpTime 값입니다. 즉, sysUpTime은 SNMP 마스터 에이전트가 시작된 후의 시간(1/100초)입니다.

3. HTTP, IMAP, POP, SMTP 및 SMTP Submit 서버의 작업 상태는 구성된 TCP 포트를 통해 해당 서버에 실제로 연결한 다음 해당 프로토콜(예: HTTP의 경우 HEAD 요청 및 응답, SMTP의 경우 HELO 명령 및 응답 등)을 통해 간단한 작업을 수행하여 확인합니다. 이 연결 시도에서 각 서버의 상태(up(1), down(2) 또는 congested(4))가 결정됩니다.

   이러한 검사는 서버에 일반 인바운드 연결로 표시되고 각 서버에 대한 applAccumulatedInboundAssociations MIB 변수 값에 포함됩니다.

   MTA의 경우 작업 상태는 작업 제어기의 작업 상태입니다. MTA가 실행 상태로 표시되면 작업 제어기가 실행 중인 것입니다. MTA가 중단 상태로 표시되면 작업 제어기가 중단된 것입니다. 이 MTA 작업 상태는 MTA의 서비스 디스패처 상태와는 별개입니다. MTA의 작업 상태는 실행 또는 중단 값으로만 나타납니다. 작업 제어기에 "congested"(정체)라는 개념은 있지만 MTA 상태에 나타나지는 않습니다.

4. HTTP, IMAP 및 POP 서버의 경우 applRejectedInboundAssociations MIB 변수는 거부된 인바운드 연결 시도 횟수가 아니라 실패한 로그인 시도 횟수를 나타냅니다.

A.5.1.1 applTable 사용

나열된 각 응용 프로그램에 대한 서버 상태(applOperStatus) 모니터링은 각 서버 모니터링의 핵심입니다.

applLastInboundActivity가 마지막 MTA 인바운드 작업을 표시한 이후 많은 시간이 경과하면 일부 연결이 끊어져 연결되지 않을 수 있습니다. applOperStatus=2(중단)인 경우 모니터되는 서비스가 중단 상태입니다. applOperStatus=1(실행)인 경우 다른 곳에 문제가 있을 수 있습니다.

A.5.2 assocTable

이 테이블은 MTA에 네트워크 연결 정보를 제공합니다. 이 테이블은 각 활성 네트워크 연결에 대한 정보를 제공하는 2차원 테이블입니다. 다른 서버에 대한 연결 정보는 제공되지 않습니다.

다음은 applTable(mib-2.27.2.1)의 데이터 예입니다.

assocTable:

    assocRemoteApplication.1.1  = 129.146.198.167        (1)
    assocApplicationProtocol.1.1 = applTCPProtoID.25     (2)
    assocApplicationType.1.1 = peerinitiator(3)          (3)
    assocDuration.1.1 = 400                              (4)
...

         

주:

.x.y 접미어(1.1)에서 x는 응용 프로그램 색인인 applIndex이며 보고되는 applTable의 응용 프로그램을 나타냅니다. 이 경우에는 MTA입니다. y는 보고되는 응용 프로그램에 대한 각 연결을 나열합니다.

1. 원격 SMTP 클라이언트의 소스 IP 주소입니다.

2. 네트워크 연결에 사용되는 프로토콜을 나타내는 OID입니다. aplTCPProtoID는 TCP 프로토콜을 나타냅니다. .n 접미어는 사용 중인 TCP 포트를 나타내고 .25는 TCP 포트 25를 통해 통신하는 프로토콜인 SMTP를 나타냅니다.

3. 원격 SMTP 클라이언트가 사용자 에이전트(UA)인지 다른 MTA인지 알 수 없습니다. 마찬가지로 하위 에이전트는 항상 peer-initiator를 보고하는 반면 ua-initiator는 절대 보고하지 않습니다.

4. 이 값은 SNMP TimeInterval이며 시간 단위(1/100초)를 사용합니다. 이 예에서 연결은 4초 동안 열립니다.

A.5.2.1 assocTable 사용

이 테이블은 활성 문제를 진단하는 데 사용됩니다. 예를 들어, 갑자기 200,000 인바운드 연결이 발생하는 경우 이 테이블을 사용하여 해당 연결의 시작 위치를 알 수 있습니다.

A.5.3 mtaTable

applTable의 각 MTA마다 하나의 행을 갖는 1차원 테이블입니다. 각 행에는 mtaGroupTable의 선택 변수에 대한 해당 MTA 내의 모든 채널(그룹이라고 함)의 합계가 제공됩니다.

다음은 applTable(mib-2.28.1.1)의 데이터 예입니다.

mtaTable:

    mtaReceivedMessages.1 = 172778        
    mtaStoredMessages.1 = 19
    mtaTransmittedMessages.1 = 172815
    mtaReceivedVolume.1 = 3817744
    mtaStoredVolume.1 = 34
    mtaTransmittedVolume.1 = 3791155
    mtaReceivedRecipients.1 = 190055
    mtaStoredRecipients.1 = 21
    mtaTransmittedRecipients.1 = 3791134
    mtaSuccessfulConvertedMessages.1 = 0 (1)
    mtaFailedConvertedMessages.1 = 0
    mtaLoopsDetected.1 = 0               (2)

         

주:

.x 접미어(.1)는 applTable에서 이 응용 프로그램에 대한 행 번호를 제공합니다. 이 예에서 .1은 이 데이터가 applTable에 있는 첫 번째 응용 프로그램에 대한 데이터임을 나타냅니다. 따라서, 이 데이터는 MTA에 관한 데이터입니다.

1. 변환 채널의 경우 0이 아닌 값만 가집니다.

2. 현재 MTA의 메시지 대기열에 저장된 .HELD 메시지 파일 수를 계산합니다.

A.5.3.1 mtaTable 사용

mtaLoopsDetected가 0이 아니면 루핑 메일 문제가 있는 것입니다. 이럴 경우 MTA 대기열에서 .HELD 파일을 찾아 진단하여 문제를 해결합니다.

시스템에서 변환 채널을 사용하여 바이러스 스캔을 수행하고 감염된 메시지를 거부하는 경우 mtaSuccessfulConvertedMessages는 다른 변환 오류와 함께 감염된 메시지 수를 제공합니다.

A.5.4 mtaGroupTable

이 2차원 테이블은 applTable의 각 MTA에 대한 채널 정보를 제공합니다. 이 정보는 저장(대기열에 포함된) 및 전달된 메일 메시지의 수와 같은 데이터를 포함합니다. 각 채널에 대한 저장된 메시지 수 mtaGroupStoredMessages 모니터링은 값이 비정상적으로 커서 메일이 대기열에 백업되고 있는 경우에 중요합니다.

다음은 mtaGroupTable(mib-2.28.2.1)의 데이터 예입니다.

mtaGroupTable:

mtaGroupName.1.1 = tcp_intranet                1
        ...
mtaGroupName.1.2 = ims-ms
        ...
mtaGroupName.1.3 = tcp_local
    mtaGroupDescription.1.3 = mailsrv-1 MTA tcp_local channel
    mtaGroupReceivedMessages.1.3 = 12154
    mtaGroupRejectedMessages.1.3 = 0
    mtaGroupStoredMessages.1.3 = 2
    mtaGroupTransmittedMessages.1.3 = 12148
    mtaGroupReceivedVolume.1.3 = 622135
    mtaGroupStoredVolume.1.3 = 7
    mtaGroupTransmittedVolume.1.3 = 619853
    mtaGroupReceivedRecipients.1.3 = 33087
    mtaGroupStoredRecipients.1.3 = 2
    mtaGroupTransmittedRecipients.1.3 = 32817
    mtaGroupOldestMessageStored.1.3 = 1103
    mtaGroupInboundAssociations.1.3 = 5
    mtaGroupOutboundAssociations.1.3 = 2
    mtaGroupAccumulatedInboundAssociations.1.3 = 150262
    mtaGroupAccumulatedOutboundAssociations.1.3 = 10970
    mtaGroupLastInboundActivity.1.3 = 1054822
    mtaGroupLastOutboundActivity.1.3 = 1054222
    mtaGroupRejectedInboundAssociations.1.3 = 0
    mtaGroupFailedOutboundAssociations.1.3 = 0
    mtaGroupInboundRejectionReason.1.3 =
    mtaGroupOutboundConnectFailureReason.1.3 =
    mtaGroupScheduledRetry.1.3 = 0
    mtaGroupMailProtocol.1.3 = applTCPProtoID.25
    mtaGroupSuccessfulConvertedMessages.1.3 = 03     2
    mtaGroupFailedConvertedMessages.1.3 = 0
    mtaGroupCreationTime.1.3 = 0
    mtaGroupHierarchy.1.3 = 0
    mtaGroupOldestMessageId.1.3 = <01IFBV8AT8HYB4T6UA@red.iplanet.com>
    mtaGroupLoopsDetected.1.3 = 0                    3
    mtaGroupLastOutboundAssociationAttempt.1.3 = 1054222

         

주:

.x.y 접미어(예: 1.1, 1.2. 1.3)에서 x는 응용 프로그램 색인인 applIndex이며 보고되는 applTable의 응용 프로그램을 나타냅니다. 이 경우에는 MTA입니다. y는 MTA의 각 채널을 나열합니다. 이 열거 색인 mtaGroupIndex는 mtaGroupAssociationTable 및 mtaGroupErrorTable 테이블에도 사용됩니다.

1. 보고되는 채널의 이름이며이는 tcp_intranet 채널입니다.

2. 변환 채널의 경우 0이 아닌 값만 가집니다.

3. 현재 이 채널의 메시지 대기열에 저장된 .HELD 메시지 파일 수를 계산합니다.

A.5.4.1 mtaGroupTable 사용

*Rejected* 및 *Failed*에 대한 추세 분석은 잠정적인 채널 문제를 확인하는 데 유용할 수 있습니다.

mtaGroupStoredVolume의 비율이 mtaGroupStoredMessages로 갑자기 증가하면 대용량 정크 메일이 해당 대기열 주위로 바운스되는 것을 의미할 수 있습니다.

mtaGroupStoredMessages로 갑자기 증가하는 것은 요청하지 않은 대량 전자 메일을 받거나 어떤 이유로 인해 전달이 실패함을 나타낼 수 있습니다.

mtaGroupOldestMessageStored 값이 전달할 수 없는 메시지 알림(notices 채널 키워드)에 사용된 값보다 몇 배 이상 큰 경우 이는 바운스 처리를 통해 처리할 수 없는 메시지를 나타낼 수 있습니다. 바운스는 mtaGroupOldestMessageStored > (최대 기간 + 24시간)를 테스트로 사용할 수 있도록 밤에 수행됩니다.

mtaGroupLoopsDetected가 0보다 큰 경우 메일 루프가 감지됩니다.

A.5.5 mtaGroupAssociationTable

해당 항목이 assocTable에 대한 색인이 되는 3차원 테이블입니다. applTable의 각 MTA에는 2차원 하위 테이블이 있습니다. 이 2차원 하위 테이블에는 해당 MTA의 각 채널에 대한 행이 하나씩 있습니다. 각 채널에는 해당 채널이 현재 진행 중인 각 활성 네트워크 연결에 대한 항목이 있습니다. 해당 항목 값은 assocTable(항목 값에 의해 색인화되고 MTA의 applIndex 색인이 참조된)에 대한 색인입니다. assocTable에 표시된 항목은 채널에 보관된 네트워크 연결입니다.

즉, mtaGroupAssociationTable 테이블은 assocTable에 표시된 네트워크 연결을 mtaGroupTable의 해당 채널에 연결합니다.

다음은 mtaGroupAssociationTable(mib-2.28.3.1)의 데이터 예입니다.

mtaGroupAssociationTable:

    mtaGroupAssociationIndex.1.3.1 = 1 1
    mtaGroupAssociationIndex.1.3.2 = 2
    mtaGroupAssociationIndex.1.3.3 = 3
    mtaGroupAssociationIndex.1.3.4 = 4
    mtaGroupAssociationIndex.1.3.5 = 5
    mtaGroupAssociationIndex.1.3.6 = 6
    mtaGroupAssociationIndex.1.3.7 = 7

         

주:

.x.y.z 접미어에서 x는 응용 프로그램 색인인 applIndex이며 보고되는 applTable의 응용 프로그램을 나타냅니다. 이 경우에는 MTA입니다. y는 보고되는 mtaGroupTable의 채널을 나타냅니다. 이 예에서 3은 tcp_local 채널을 나타냅니다. z는 채널로 또는 채널에서 열린 연결을 나열합니다.

1. 여기서 값은 assocTable에 대한 색인입니다. 특히 x와 이 값은 각각 assocTable의 applIndex 및 assocIndex 색인 값이 됩니다. 또는 assocTable(applIndex 무시)의 첫 번째 행은 tcp_local 채널에 의해 제어되는 네트워크 연결을 설명합니다.

A.5.6 mtaGroupErrorTable

메시지 전달을 시도하는 동안 각 MTA의 각 채널에서 발생된 임시 및 영구 오류의 개수를 제공하는 다른 3차원 테이블입니다. 색인 값이 4000000인 항목은 임시 오류이고 색인 값이 5000000인 항목은 영구 오류입니다. 임시 오류가 발생하면 나중에 전달 시도할 수 있도록 대기열에 메시지를 다시 포함하고, 영구 오류가 발생하면 메시지는 거부되거나 전달할 수 없는 메시지로 반환됩니다.

다음은 mtaGroupErrorTable(mib-2.28.5.1)의 데이터 예입니다.

mtaGroupErrorTable:

    mtaGroupInboundErrorCount.1.1.4000000 1 = 0
    mtaGroupInboundErrorCount.1.1.5000000 = 0
    mtaGroupInternalErrorCount.1.1.4000000 = 0
    mtaGroupInternalErrorCount.1.1.5000000 = 0
    mtaGroupOutboundErrorCount.1.1.4000000 = 0
    mtaGroupOutboundErrorCount.1.1.5000000 = 0

    mtaGroupInboundErrorCount.1.2.4000000 1 = 0
    ...

    mtaGroupInboundErrorCount.1.3.4000000 1 = 0
    ...         

주:

1. .x.y.z 접미어에서 x는 응용 프로그램 색인인 applIndex이며 보고되는 applTable의 응용 프로그램을 나타냅니다. 이 경우에는 MTA입니다. y는 보고되는 mtaGroupTable의 채널을 나타냅니다. 이 예에서 1은 tcp_intranet 채널을 지정하고 2는 ims-ms 채널을, 3은 tcp_local 채널을 지정합니다. 마지막으로 z는 4000000 또는 5000000이며 각각 해당 채널에 대한 메시지 전달 시도 중에 발생한 임시 오류 및 영구 오류의 개수를 나타냅니다.

A.5.6.1 mtaGroupErrorTable 사용

오류 개수가 크게 증가하면 비정상적인 전달 문제를 나타낼 수 있습니다. 예를 들어, tcp_ channel이 크게 증가하면 DNS 또는 네트워크 문제를 나타낼 수 있습니다. ims_ms 채널이 크게 증가할 경우 메시지를 메시지 저장소로 전달하는 데 문제(예: 분할 영역이 꽉 참, stored 문제 등)가 있을 수 있습니다.