Sun Java System Messaging Server 6 2005Q4 관리 설명서

부록 A SNMP 지원

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

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

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

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는 Java Enterprise System에서 지원하는 모든 Microsoft Windows 버전뿐만 아니라 Solaris 8 및 9를 실행하는 플랫폼에서 지원됩니다. 다른 플랫폼에 대한 지원은 이후 릴리스에서 제공됩니다. Solaris의 SNMP 지원에서는 원시 Solaris SNMP 기술인 SEA(Solstice Enterprise Agents)를 사용합니다. 고객은 Solaris 8 시스템에 SEA를 설치할 필요가 없습니다. 필요한 런타임 라이브러리가 이미 설치되어 있습니다.

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

각 호스트 컴퓨터에서는 SNMP를 통해 Messaging Server 인스턴스를 하나씩만 모니터할 수 있습니다.
SNMP 지원은 모니터링 전용입니다. SNMP 관리는 지원되지 않습니다.
SNMP 트랩이 구현되지 않습니다. RFC 2788은 트랩을 사용하지 않는 유사한 기능을 제공합니다.

Messaging Server에서의 SNMP 작업

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

그림 A–1 SNMP 정보 흐름

Solaris 8에서 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 옵션을 사용합니다.

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 파일을 사용합니다.

Unix 플랫폼에서 다른 Sun Java System 제품과 공존

SNMP 지원을 제공하는 다른 Netscape 또는 Sun Java System 제품에서는 플랫폼의 원시 SNMP 마스터 에이전트를 대체하여 이 작업을 수행할 수 있습니다. Messaging Server와 동일한 호스트에서 Sun Java System 제품을 실행하고 SNMP를 통해 모니터하려면 Managing Servers with iPlanet Console의 11장에 설명된 대로 Sun Java System 프록시 SNMP 에이전트를 구성합니다. 그러면 Messaging Server SNMP 하위 에이전트(원시 SNMP 하위 에이전트)가 다른 Sun Java System 제품의 비원시 Sun Java System SNMP 하위 에이전트와 공존할 수 있습니다.

Messaging Server의 SNMP 정보

이 절에서는 SNMP를 통해 제공되는 Messaging Server 정보를 요약합니다. 자세한 내용은 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 클라이언트에서는 추세 분석을 수행하여 기록된 추세와 편차가 발생할 경우 경고를 보냅니다.

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
    ...

주:

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

등호 뒤에 있는 이름은 모니터할 Messaging Server 인스턴스의 이름입니다. 이 예에서 인스턴스 이름은 mailsrv-1입니다.
이러한 값은 SNMP 타임스탬프 값이고 이벤트 시간의 sysUpTime 값입니다. 즉, sysUpTime은 SNMP 마스터 에이전트가 시작된 후의 시간(1/100초)입니다.
HTTP, IMAP, POP, SMTP 및 SMTP Submit 서버의 작업 상태는 구성된 TCP 포트를 통해 해당 서버에 실제로 연결한 다음 해당 프로토콜(예: HTTP의 경우 HEAD 요청 및 응답, SMTP의 경우 HELO 명령 및 응답 등)을 통해 간단한 작업을 수행하여 확인합니다. 이 연결 시도에서 각 서버의 상태(up(1), down(2) 또는 congested(4))가 결정됩니다.

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

MTA의 경우 작업 상태는 Job Controller의 작업 상태입니다. MTA가 실행 상태로 표시되면 Job Controller가 실행 중인 것입니다. MTA가 중단 상태로 표시되면 Job Controller가 중단된 것입니다. 이 MTA 작업 상태는 MTA의 서비스 디스패처 상태와는 별개입니다. MTA의 작업 상태는 실행 또는 중단 값으로만 나타납니다. Job Controller에 "congested"(정체)라는 개념은 있지만 MTA 상태에 나타나지는 않습니다.
HTTP, IMAP 및 POP 서버의 경우 applRejectedInboundAssociations MIB 변수는 거부된 인바운드 연결 시도 횟수가 아니라 실패한 로그인 시도 횟수를 나타냅니다.

applTable 사용

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

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

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는 보고되는 응용 프로그램에 대한 각 연결을 나열합니다.

원격 SMTP 클라이언트의 소스 IP 주소입니다.
네트워크 연결에 사용되는 프로토콜을 나타내는 OID입니다. aplTCPProtoID는 TCP 프로토콜을 나타냅니다. .n 접미어는 사용 중인 TCP 포트를 나타내고 .25는 TCP 포트 25를 통해 통신하는 프로토콜인 SMTP를 나타냅니다.
원격 SMTP 클라이언트가 사용자 에이전트(UA)인지 다른 MTA인지 알 수 없습니다. 마찬가지로 하위 에이전트는 항상 peer-initiator를 보고하는 반면 ua-initiator는 절대 보고하지 않습니다.
이 값은 SNMP TimeInterval이며 시간 단위(1/100초)를 사용합니다. 이 예에서 연결은 4초 동안 열립니다.

assocTable 사용

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

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에 관한 데이터입니다.

변환 채널의 경우 0이 아닌 값만 가집니다.
현재 MTA의 메일 대기열에 저장된 .HELD 메일 파일 수를 계산합니다.

mtaTable 사용

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

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

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 테이블에도 사용됩니다.

보고되는 채널의 이름이며이는 tcp_intranet 채널입니다.
변환 채널의 경우 0이 아닌 값만 가집니다.
현재 이 채널의 메일 대기열에 저장된 .HELD 메일 파일 수를 계산합니다.

mtaGroupTable 사용

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

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

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

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

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

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는 채널로 또는 채널에서 열린 연결을 나열합니다.

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

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
    ...

주:

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

mtaGroupErrorTable 사용

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