22장 Messaging Server 모니터링

일반적으로 제대로 계획 및 구성된 서버는 관리자의 광범위한 개입 없이 작동합니다. 그러나 서버에서 문제의 징후를 모니터하는 것은 관리자가 해야 할 일입니다. 이 장에서는 Messaging Server의 모니터링에 대해 설명합니다. 이 장은 다음 내용으로 구성되어 있습니다.

자동 모니터링 및 재시작

Messaging Server는 서비스를 투명하게 모니터하고 서비스가 실패하거나 응답하지 않을 경우(즉, 서비스가 중지되거나 멈춘 경우) 서비스를 자동으로 다시 시작하는 방법을 제공합니다. Messaging Server는 IMAP, POP, HTTP, Job Controller, 디스패처 및 MMP 서버를 비롯한 모든 메일 저장소, MTA 및 MMP 서비스를 모니터할 수 있지만 ENS, SMS, LMTP 또는 TCP/SNMP 서버와 같은 다른 서비스는 모니터하지 않습니다. LMTP 및 TCP/SNMP는 Job Controller에서 모니터링합니다. 자세한 내용은 실패했거나 응답이 없는 서비스의 자동 재시작을 참조하십시오.

또한 이 기능은 모든 서버 시작과 중지를 기록하는 아래의 msg_svr_base/data/log/watcher 로그 파일을 생성합니다. 이 파일은 시스템 상태를 모니터하기 위한 매우 중요한 파일입니다.

일상적인 모니터링 작업

일상적으로 수행해야 하는 가장 중요한 작업은 포스트마스터 메일 검사, 로그 파일 모니터링 및 stored 유틸리티 설정입니다. 아래에서는 이러한 작업에 대해 설명합니다.

포스트마스터 메일 검사

Messaging Server에는 포스트마스터 전자 메일용으로 설정된 관리 메일링 목록이 미리 정의되어 있습니다. 이 메일링 목록에 속한 모든 사용자는 포스트마스터로 주소 지정된 메일을 자동으로 받게 됩니다.

포스트마스터 메일에 대한 규칙은 RFC822에서 정의됩니다. RFC822에 따르면 모든 전자 메일 사이트에서 postmaster라는 이름의 사용자 또는 메일링 목록으로 주소 지정된 메일을 수락해야 하며 이 주소로 보내진 메일은 실제 당사자에게 전달되어야 합니다. postmaster@host.domain으로 보내진 모든 메일은 포스트마스터 계정 또는 메일링 목록으로 보내집니다.

일반적으로 포스트마스터 주소는 사용자가 메일 서비스에 대한 전자 메일을 보내야 하는 곳입니다. 포스트마스터는 예를 들어, 서버 응답 시간에 대한 메일을 로컬 사용자로부터 받거나 서버로 메일을 보내는 데 문제가 있다는 내용의 메일을 다른 서버 관리자로부터 받을 수 있습니다. 포스트마스터 메일은 매일 확인해야 합니다.

특정 오류 메시지를 포스트마스터 주소로 보내도록 서버를 구성할 수도 있습니다. 예를 들어, MTA가 메일을 라우팅 또는 전달하지 못할 경우 포스트마스터 주소로 보내진 전자 메일을 통해 알림을 받을 수 있습니다. 또한 예외적인 상황에 대한 경고(디스크 공간 부족, 서버 응답 실패 등에 대한)를 포스트마스터에게 보낼 수도 있습니다.

로그 파일 모니터링 및 유지 관리

Messaging Server는 지원되는 각각의 주요 프로토콜이나 서비스(SMTP, IMAP, POP 및 HTTP)에 대한 별도의 로그 파일 집합을 생성합니다. 이러한 로그 파일은 msg_svr_base/data/log에 위치합니다. 로그 파일은 정기적으로 모니터링해야 하며, 특히 서버에 문제가 있는 경우에는 이러한 모니터링이 더욱 필요합니다.

로깅이 서버 성능에 영향을 줄 수 있다는 것을 유의하십시오. 더 자세한 로깅을 지정할수록 일정한 시간 동안 로그 파일이 차지하는 디스크 공간이 더 많아집니다. 따라서 효과적이면서 실제적인 로그 회전, 만료 및 백업 정책을 서버에 정의해야 합니다. 서버의 로깅 정책 정의에 대한 자세한 내용은 20장, "로깅 및 로그 분석"을 참조하십시오.

stored 유틸리티 설정

stored 유틸리티는 서버에 대해 다음과 같은 자동 모니터링 및 유지 관리 작업을 수행합니다.

stored 유틸리티는 매일 자정에 한 번씩 정리 및 만료 작업을 자동으로 수행합니다. 자세한 내용은 stored를 참조하십시오.

시스템 성능 모니터링

이 장에서는 Messaging Server 모니터링에 초점을 맞추고 있지만 서버가 상주하는 시스템도 모니터링해야 합니다. 적절하게 구성된 서버는 잘못 구성된 시스템에서 제대로 작동할 수 없으며 하드웨어가 전자 메일 로드를 감당할 만큼 성능이 충분하지 않다는 서버 오류의 증상이 나타날 수 있습니다. 시스템 성능을 모니터하기 위한 절차가 플랫폼마다 차이가 있고 해당 플랫폼의 시스템 설명서를 참조할 필요가 있다는 점에서 이 장에서 이러한 절차를 자세하게 다루지는 않습니다. 여기에서는 성능 모니터링을 위한 다음 절차에 대해 설명합니다.

종단간 메일 전달 시간 모니터링

전자 메일은 제때에 전달되어야 합니다. 이는 서비스 계약 요구 사항일 뿐 아니라 메일을 가능한 신속하게 전달하는 것은 바람직한 정책입니다. 종단간의 느린 메일 전달은 여러 가지 원인으로 인해 발생할 수 있습니다. 예를 들어, 서버가 제대로 작동하지 않거나, 일정 기간 동안 과도한 메일 로드가 발생했거나, 기존 하드웨어 자원이 용량을 초과했을 수 있습니다.

느린 종단간 메일 전달 시간의 증상

종단간 메일 전달 시간 모니터

디스크 공간 모니터링

부족한 디스크 공간은 메일 서버 문제와 오류의 가장 일반적인 원인 중 하나입니다. MTA 대기열 또는 메일 저장소에 쓰기 위한 공간이 없을 경우 메일 서버에 오류가 발생합니다. 또한 로그 파일이 모니터링 및 정리되지 않을 경우 모든 디스크 공간이 채워질 때까지 로그 파일의 크기가 증가할 수 있습니다.

stored의 정리 기능이 제대로 작동하지 않고 삭제된 메일이 메일 저장소에서 정리되지 않을 경우 디스크 공간이 빠른 속도로 고갈될 수 있습니다. 또한 MTA 메일 대기열이 너무 커지거나, 메일 저장소가 사용 가능한 디스크 공간을 초과하거나, 모니터링되지 않은 로그 파일의 크기가 제한 없이 증가하는 것도 디스크 공간이 부족해지는 원인이 됩니다. LDAP, MTA 및 Message Access와 같은 다양한 로그 파일이 존재하며 이러한 로그 파일은 각각 다른 디스크에 저장될 수 있다는 것을 유의하십시오.

디스크 공간 문제의 증상

공간이 부족해지는 디스크나 분할 영역에 따라 여러 다른 증상이 발생할 수 있습니다. MTA 대기열이 오버플로되고 SMTP 연결을 거부하거나, 메일이 ims_master 대기열에 남아 있으면서 메일 저장소로 전달되지 않거나, 로그 파일이 오버플로될 수 있습니다.

디스크 공간 모니터

시스템 구성에 따라 다양한 디스크와 분할 영역을 모니터링해야 할 수 있습니다. 예를 들어, MTA 대기열, 메일 저장소 및 로그 파일이 각기 다른 디스크/분할 영역에 상주할 수 있습니다. 이 경우 각 공간에 대한 모니터링이 필요하며 각 공간을 모니터하는 방법이 다를 수 있습니다.

메일 저장소 모니터링

메일 저장소의 디스크 사용은 용량의 75%를 초과하지 않도록 하는 것이 좋습니다. configutil 유틸리티로 다음 경보 속성을 구성하여 메일 저장소 디스크 사용을 모니터할 수 있습니다.

이러한 매개 변수를 설정함으로써 시스템이 디스크 공간을 모니터하는 빈도와 경고를 보내야 하는 상황을 지정할 수 있습니다. 예를 들어, 디스크 공간을 600초 간격으로 모니터하려는 경우 다음 명령을 지정합니다.

사용 가능한 디스크 공간이 20% 이하로 내려갈 때마다 경고를 받으려면 다음 명령을 지정합니다.

이러한 매개 변수에 대한 자세한 내용은 표 22-1을 참조하십시오.

MTA 대기열 및 로깅 공간 모니터링

MTA 대기열 디스크 및 로깅 공간 디스크 사용을 모니터링해야 합니다.

CPU 사용 모니터링

CPU 사용량이 많다는 것은 해당 사용 수준에 맞는 CPU 용량이 부족하거나 일부 프로세스가 적절한 한도 이상의 CPU 주기를 사용 중임을 의미합니다.

CPU 사용 문제의 증상

시스템 응답 시간이 저하되고 사용자가 로그인하는 데 시간이 오래 걸리며 전달 속도가 느려집니다.

CPU 사용 모니터

CPU 사용을 모니터하는 작업은 플랫폼별로 차이가 있습니다. 관련된 플랫폼 설명서를 참조하십시오.

MTA 모니터링

메일 대기열 크기 모니터링

메일 대기열이 과도하게 커지는 것은 메일이 전달되지 않거나, 메일의 전달이 지연되거나, 시스템이 전달할 수 있는 것보다 빠른 속도로 메일이 도착하기 때문일 수 있습니다. 이 문제는 시스템을 쇄도하는 막대한 수의 메일로 인한 서비스 거부 공격이나 Job Controller가 실행되지 않는 등의 여러 이유로 발생할 수 있습니다.

메일 대기열 문제의 증상

메일 대기열의 크기 모니터

메일 대기열을 모니터하는 최선의 방법은 imsimta qm을 사용하는 것입니다. imsimta qm counters를 참조하십시오.

또한 대기열 디렉토리(msg_svr_base/data/queue/)의 파일 수를 모니터할 수도 있습니다. 파일 수는 사이트마다 차이가 있으므로 "너무 많다"고 판단하는 데 기준이 되는 내역을 작성해야 합니다. 2주 이상 동안에 대기열 파일의 크기를 기록하여 대략적인 평균을 구하는 방법으로 이러한 기준 내역을 작성할 수 있습니다.

전달 실패 비율 모니터링

전달 실패는 메일을 외부 사이트로 전달하려는 시도가 실패한 것입니다. 전달 실패 비율이 높다는 것은 DNS 서버를 사용할 수 없거나 원격 서버에서 연결 응답 시간이 초과하는 등의 네트워크 문제가 존재한다는 것을 나타낼 수 있습니다.

전달 실패 비율의 증상

외부적인 증상은 없습니다. 다수의 Q 레코드가 mail.log_current에 나타납니다.

전달 실패의 비율 모니터

전달 실패는 로깅 항목 코드 Q로 MTA 로그에 기록됩니다. msg_svr_base/data/log/mail.log_current 파일에서 레코드를 확인합니다.
예를 들면 다음과 같습니다.

mail.log:06-Oct-2003 00:24:03.66 501d.0b.9 ims-ms Q 5 durai.balusamy@Sun.COM rfc822;durai.balusamy@Sun.COM durai@ims-ms-daemon <00ce01c38bda$c7e2b240$6501a8c0@guindy> Mailbox is busy

인바운드 SMTP 연결 모니터링

특정 IP 주소에서 인바운드 SMTP 연결 수가 비정상적으로 증가한다는 것은 다음을 의미할 수 있습니다.

인증되지 않은 SMTP 연결의 증상

인바운드 SMTP 연결 모니터

시스템에서 특정 읽기 작업이 비정상적인지 확인할 수 있으려면 우선 적절한 수의 SMTP 연결과 상태(ESTABLISHED, CLOSE_WAIT 등)를 확인해야 한다는 것을 유의하십시오.

다수의 연결이 SYN_RECEIVED 상태로 있을 경우 네트워크 연결이 끊어졌거나 서비스 거부 공격이 발생한 것일 수 있습니다. 또한 SMTP 서버 프로세스의 수명이 제한됩니다. 이것은 dispatcher.cnf 파일에서 MTA 구성 변수 MAX_LIFE_TIME을 통해 제어합니다. 기본값은 86,400초(1일)입니다. 마찬가지로 MAX_LIFE_CONNS는 서버 프로세스가 수명 한도 내에서 처리할 수 있는 최대 연결 수를 지정합니다. 특정 SMTP 서버가 오래 지속될 경우 이를 조사하는 것이 필요할 수 있습니다.

디스패처 및 Job Controller 프로세스 모니터링

MTA가 작동하려면 디스패처 및 Job Controller 프로세스가 실행 중이어야 합니다. 각 종류의 프로세스는 하나만 존재해야 합니다.

디스패처 및 Job Controller 프로세스가 다운된 경우의 증상

디스패처가 다운되었거나 자원이 부족할 경우 SMTP 연결이 거부됩니다.

디스패처 및 Job Controller 프로세스 모니터

메일 액세스 모니터링

imapd, popd 및 httpd 모니터링

이러한 프로세스는 IMAP, POP 및 웹 메일 서비스에 대한 액세스를 제공합니다. 이러한 프로세스가 실행 중이 아니거나 응답하지 않을 경우 서비스는 제대로 작동하지 않습니다. 서비스가 실행 중이지만 오버로드된 경우 모니터링을 수행하여 문제를 감지하고 더 적절하게 서비스를 구성할 수 있습니다.

imapd, popd 및 httpd 문제의 증상

연결이 거부되며 시스템의 연결 속도가 너무 느려집니다. 예를 들어, IMAP가 실행 중이 아닐 때 IMAP에 직접 연결하려고 시도하면 다음과 같은 메일이 나타납니다.

telnet 0 143
Trying 0.0.0.0...
telnet: Unable to connect to remote host: Connection refused

클라이언트와의 연결을 시도할 경우에는 다음과 같은 메일이 표시됩니다.

Client is unable to connect to the server at the location you have specified. The server may be down or busy.

imapd, popd 및 httpd 모니터

watcher를 사용하여 모니터할 수 있습니다. 실패했거나 응답이 없는 서비스의 자동 재시작을 참조하십시오.

SNMP를 사용하여 모니터할 수 있습니다.

SNMP가 설정된 경우 SNMP는 이러한 프로세스를 모니터하는 매우 적절한 방법이 됩니다. 부록 A, "SNMP 지원"을 참조하십시오. 서버 정보는 네트워크 서비스 모니터링 MIB에 있습니다.

로그 파일을 검사합니다.

msg_svr_base/log/service 디렉토리를 확인합니다. 여기에서 service는 http, IMAP 또는 POP가 될 수 있습니다. 이 디렉토리에는 여러 로그 파일이 존재합니다. 파일 이름 중 하나는 service의 이름(imap, pop, http)이며 나머지는 서비스 이름 외에 일련 번호와 날짜가 서비스 이름에 연결되어 있습니다. 예를 들면 다음과 같습니다.

imap imap.29.1010221593 imap.31.1010394412 imap.33.1010567224

서비스 이름만 가진 파일이 가장 최신 로그입니다. 나머지 파일은 일련 번호(여기에서는 29, 31, 33)로 순서가 정해지며 일련 번호가 가장 높은 파일이 그 다음의 최신 로그입니다. 20장, "로깅 및 로그 분석"을 참조하십시오.

서버가 종료된 경우 다음과 같은 메일이 나타날 수 있습니다.

imap.12.1065431243:[07/Oct/2003:01:15:43 -0700] gotmail-2 imapd[20525]: General Warning: Sun Java System Messaging Server IMAP4 6.1 (built Sep 24 2003) shutting down

counterutil을 사용하여 검사할 수 있습니다. counterutil 및 Sun Java System Messaging Server Administration Reference를 참조하십시오.

플랫폼 특정 명령을 실행하여 imapd, popd 및 httpd 프로세스가 실행 중인지 확인합니다. 예를 들어, Solaris에서는 ps 명령을 사용하여 imapd, popd 및 mshttpd를 찾을 수 있습니다.

권장 stored 매개 변수에 설명된 서버 응답 구성 매개 변수를 설정하여 지정된 서버 성능 임계값에 대한 경보를 설정할 수 있습니다.

immonitor-access를 참조하십시오.

stored 모니터링

stored는 메일 데이터베이스의 교착 상태 및 트랜잭션 작업을 수행하고 에이징 정책을 적용하며 디스크에 저장된 메일을 정리 및 지우는 등의 중요한 여러 작업을 수행합니다. stored의 실행이 중지되면 Messaging Server에서 결과적으로 문제가 발생합니다. start-msg가 실행될 때 stored가 시작되지 않을 경우 다른 프로세스는 시작되지 않습니다. stored에 대한 자세한 내용은 Sun Java System Messaging Server Administration Reference를 참조하십시오.

stored 문제의 증상

stored 모니터

LDAP 디렉토리 서버 모니터링

slapd 모니터링

LDAP 디렉토리 서버(slapd)는 메시징 시스템에 대한 디렉토리 정보를 제공합니다. slapd가 다운될 경우 시스템이 제대로 작동하지 않습니다. slapd 응답 시간이 너무 느릴 경우 로그인 속도나 LDAP 조회가 필요한 다른 트랜잭션에 영향을 줍니다.

slapd 문제의 증상

slapd 모니터

메일 저장소 모니터링

메일은 데이터베이스에 저장됩니다. 디스크상의 사용자 배포, 메일함 크기 및 디스크 요구 사항은 저장소 성능에 영향을 미칩니다. 이 절은 다음과 같은 하위 절로 구성되어 있습니다.

메일 저장소 데이터베이스 잠금의 상태 모니터링

DB 잠금의 상태는 다른 서버 프로세스에 의해 유지됩니다. 이러한 데이터베이스 잠금은 메일 저장소의 성능에 영향을 줄 수 있습니다. 교착 상태의 경우 메일이 적절한 속도로 저장소에 삽입되지 않으며 ims-ms 채널 대기열의 크기가 결과적으로 더 증가합니다. 이는 대기열을 백업해야 할 정당한 이유가 되며, 따라서 문제를 진단하기 위해서는 대기열 길이의 내역을 갖고 있는 것이 유용합니다.

메일 저장소 데이터베이스 잠금 문제의 증상

메일 저장소 데이터베이스 잠금 모니터

mboxlist 디렉토리의 데이터베이스 로그 파일 수 모니터링

데이터베이스 로그 파일이란 sleepycat 트랜잭션 검사점 지정 로그 파일(msg_svr_base/store/mboxlist)을 말합니다. 로그 파일이 작성되는 것은 데이터베이스 검사점 지정이 발생하지 않았기 때문입니다. 또한 로그 파일은 stored 문제로 인해 작성될 수 있습니다.

데이터베이스 로그 파일 문제의 증상

2 또는 3개의 로그 파일이 존재해야 합니다. 로그 파일이 더 많을 경우 잠재적으로 심각한 문제가 존재하는 것입니다. 메일 저장소는 메일과 할당량을 위해 몇 개의 데이터베이스를 사용하며 이와 관련된 문제는 전체 메일 서버에 대한 문제를 일으킬 수 있습니다.

데이터베이스 로그 파일 모니터

msg_svr_base/store/mboxlist 디렉토리에서 파일이 2 또는 3개만 존재하는지 확인합니다.

모니터링을 위한 유틸리티와 도구

immonitor-access

immonitor-access는 메일 전달(SMTP 서버), 메일 액세스 및 저장(POP 및 IMAP 서버), 디렉토리 서비스(LDAP 서버) 및 HTTP 서버와 같은 Messaging Server 구성 요소/프로세스의 상태를 모니터링합니다. 이 유틸리티는 다양한 서비스의 응답 시간과 메일을 전송 및 검색하는 데 걸린 총 왕복 시간을 측정합니다. 디렉토리 서비스는 디렉토리에서 지정된 사용자를 조회하고 응답 시간을 측정하는 방법으로 모니터링합니다. 메일 전달은 메일(SMTP)를 보내는 방법으로 모니터하며 메일 액세스 및 저장은 메일을 검색하는 방법으로 모니터링합니다. HTTP 서버에 대한 모니터링은 HTTP 서버가 작동하여 실행 중인지 확인하는 것으로 제한됩니다.

자세한 지침은 Sun Java System Messaging Server Administration Reference를 참조하십시오.

stored

stored 유틸리티는 서버에서 유지 관리 작업을 수행하지만 또한 모니터링을 수행할 수도 있습니다. 이 유틸리티는 서버 상태, 디스크 공간, 서비스 응답 시간 등을 정기적으로 검사할 수 있으며 따로 지정된 경우 전자 메일의 형태로 경보를 포스트마스터에게 보낼 수 있습니다((해당 페이지) 참조).

경보는 지정된 조건을 경고하기 위해 전자 메일 형태로 stored에서 포스트마스터에게 보내집니다. 다음은 일정한 임계값을 초과할 때 stored에 의해 보내지는 샘플 전자 메일 경보입니다.

Subject: ALARM: server response time in seconds of ldap_siroe.com_389 is 10
Date: Tue, 17 Jul 2001 16:37:08 -0700 (PDT)
From: postmaster@siroe.com
To: postmaster@siroe.com

Server instance: /opt/SUNWmsgsr
Alarmid: serverresponse
Instance: ldap_siroe_europa.com_389
Description: server response time in seconds
Current measured value (17/Jul/2001:16:37:08 -0700): 10
Lowest recorded value: 0
Highest recorded value: 10
Monitoring interval: 600 seconds
Alarm condition is when over threshold of 10
Number of times over threshold: 1

stored가 디스크 및 서버 성능을 모니터하는 빈도와 경보를 보내는 상황을 지정할 수 있습니다. 이렇게 하려면 configutil 명령을 사용하여 경보 매개 변수를 설정합니다. 표 22-1은 유용한 stored 매개 변수와 함께 그 기본 설정을 보여 줍니다.

표 22-1 권장 stored 매개 변수
매개 변수	설명(괄호 안의 값이 기본값임)
alarm.msgalarmnoticehost	(localhost) 경고 메일을 보낼 시스템입니다.
alarm.msgalarmnoticeport	(25) 경보 메일을 보낼 때 연결할 SMTP 포트입니다.
alarm.msgalarmnoticercpt	(Postmaster@localhost) 경보 알림을 받는 사람입니다.
alarm.msgalarmnoticesender	(Postmaster@localhost) 경보를 보낸 사람의 주소입니다.
alarm.diskavail.msgalarmdescription	디스크 가용성 경보에 대한 설명입니다.
alarm.diskavail.msgalarmstatinterval	(3600) 디스크 가용성 검사의 간격(초)입니다. 디스크 사용 검사를 사용하지 않으려면 0으로 설정합니다.
alarm.diskavail.msgalarmthreshold	(10) 디스크 공간 가용성 비율로서 이 비율 아래로 내려가면 경보가 보내집니다.
alarm.diskavail.msgalarmthresholddirection	(-1) 경보가 디스크 공간 가용성이 임계값보다 작을 때 발생하는지(-1) 아니면 임계값보다 클 때 발생하는지(1) 여부를 지정합니다.
alarm.diskavail.msgalarmwarninginterval	(24) 디스크 가용성 경보가 반복되는 간격(시간)입니다.
alarm.serverresponse.msgalarmdescription	서버 응답 경보에 대한 설명입니다.
alarm.serverresponse.msgalarmstatinterval	(600) 서버 응답 검사의 간격(초)입니다. 서버 응답 검사를 사용하지 않으려면 0으로 설정합니다.
alarm.serverresponse.msgalarmthreshold	(10) 서버 응답 시간(초)이 이 값을 초과할 경우 경보가 발생합니다.
alarm.serverresponse.msgalarmthresholddirection	(1) 경보가 서버 응답 시간이 임계값보다 클 때 발생하는지(1) 아니면 임계값보다 작을 때 발생하는지(-1) 여부를 지정합니다.
alarm.serverresponse.msgalarmwarninginterval	(24) 서버 응답 경보가 반복되는 간격(시간)입니다.

counterutil

이 유틸리티는 다른 시스템 카운터에서 얻은 통계를 제공합니다. 사용 가능한 카운터 객체의 최신 목록은 다음과 같습니다.

# /opt/SUNWmsgsr/sbin/counterutil -l
Listing registry (/opt/SUNWmsgsr/data/counter/counter)
numobjects = 11
refcount = 1
created = 25/Sep/2003:02:04:55 -0700
modified = 02/Oct/2003:22:48:55 -0700
       entry = alarm
       entry = diskusage
       entry = serverresponse
       entry = db_lock
       entry = db_log
       entry = db_mpool
       entry = db_txn
       entry = imapstat
       entry = httpstat
       entry = popstat
       entry = cgimsg

각 항목은 카운터 객체를 나타내며 해당 객체에 대해 유용한 여러 카운트를 제공합니다. 이 절에서는 alarm, diskusage, serverresponse, db_lock, popstat, imapstat 및 httpstat 카운터 객체에 대해서만 설명합니다. counterutil 명령 사용에 대한 자세한 내용은 Sun Java System Messaging Server Administration Reference를 참조하십시오.

counterutil 출력

counterutil은 다양한 플래그를 가집니다. 이 유틸리티의 명령 형식은 다음과 같습니다.

# counterutil -o imapstat -i 5 -n 10
Monitor counteroobject (imapstat)
registry /gotmail/iplanet/server5/msg-gotmail/counter/counter opened
counterobject imapstat opened

count = 1 at 972082466 rh = 0xc0990 oh = 0xc0968

global.currentStartTime [4 bytes]: 17/Oct/2000:12:44:23 -0700
global.lastConnectionTime [4 bytes]: 20/Oct/2000:15:53:37 -0700
global.maxConnections [4 bytes]: 69
global.numConnections [4 bytes]: 12480
global.numCurrentConnections [4 bytes]: 48
global.numFailedConnections [4 bytes]: 0
global.numFailedLogins [4 bytes]: 15
global.numGoodLogins [4 bytes]: 10446
...

counterutil을 사용한 경보 통계

이러한 경보 통계는 stored에 의해 보내진 경보를 나타냅니다. 경보 카운터는 다음 통계를 제공합니다.

표 22-2 counterutil alarm 통계
접미어	설명
alarm.countoverthreshold	임계값을 초과한 횟수입니다.
alarm.countwarningsent	보내진 경고 수입니다.
alarm.current	현재 모니터링되는 값입니다.
alarm.high	기록된 값 중에서 가장 높은 값입니다.
alarm.low	기록된 값 중에서 가장 낮은 값입니다.
alarm.timelastset	현재 값이 마지막으로 설정된 시간입니다.
alarm.timelastwarning	경고가 마지막으로 보내진 시간입니다.
alarm.timereset	재설정이 마지막으로 수행된 시간입니다.
alarm.timestatechanged	경보 상태가 마지막으로 변경된 시간입니다.
alarm.warningstate	경보 상태(yes(1) 또는 no(0))입니다.

counterutil을 사용한 IMAP, POP 및 HTTP 연결 통계

현재 IMAP, POP 및 HTTP 연결 수, 실패한 로그인 수, 시작 시점부터의 총 연결 수 등에 대한 정보를 얻으려면 counterutil -o CounterObject -i 5 -n 10 명령을 사용합니다. 여기에서 CounterObject는 카운터 객체 popstat, imapstat 또는 httpstat를 나타냅니다. imapstat 접미어의 의미는 표 22-3에 나와 있습니다. popstat 및 httpstat 객체는 같은 형식과 구조로 동일한 정보를 제공합니다.

표 22-3 counterutil imapstat 통계
접미어	설명
currentStartTime	현재 IMAP 서버 프로세스의 시작 시간입니다.
lastConnectionTime	새 클라이언트가 마지막으로 수락된 시간입니다.
maxConnections	IMAP 서버에 의해 처리되는 최대 동시 연결 수입니다.
numConnections	현재 IMAP 서버에 의해 서비스되는 총 연결 수입니다.
numCurrentConnections	현재 활성 연결의 수입니다.
numFailedConnections	현재 IMAP 서버에 의해 서비스되는 실패한 연결 수입니다.
numFailedLogins	현재 IMAP 서버에 의해 서비스되는 실패한 로그인 수입니다.
numGoodLogins	현재 IMAP 서버에 의해 서비스되는 성공적인 로그인 수입니다.

counterutil을 사용한 디스크 사용 통계

표 22-4 counterutil diskstat 통계
접미어	설명
diskusage.availSpace	디스크 분할 영역에서 사용할 수 있는 총 공간입니다.
diskusage.lastStatTime	마지막으로 통계를 가져온 시간입니다.
diskusage.mailPartitionPath	메일 분할 영역 경로입니다.
diskusage.percentAvail	사용할 수 있는 디스크 분할 영역 공간의 비율입니다.
diskusage.totalSpace	디스크 분할 영역의 총 공간입니다.

서버 응답 통계

counterutil -o serverresponse 명령은 다음 정보를 생성합니다. 이 정보는 서버가 실행 중인지 확인하고 서버가 얼마나 빨리 응답하는지 확인하는 데 유용합니다.

표 22-5 counterutil serverresponse 통계
접미어	설명
http.laststattime	http 서버 응답이 마지막으로 확인된 시간입니다.
http.responsetime	http에 대한 응답 시간입니다.
imap.laststattime	imap 서버 응답이 마지막으로 확인된 시간입니다.
imap.responsetime	imap에 대한 응답 시간입니다.
pop.laststattime	pop 서버 응답이 마지막으로 확인된 시간입니다.
pop.responsetime	pop에 대한 응답 시간입니다.
ldap_host1_389.laststattime	ldap_host1_389 서버 응답이 마지막으로 확인된 시간입니다.
ldap_host1_389.responsetime	ldap_host1_389에 대한 응답 시간입니다.
ugldap_host2_389.laststattime	ugldap_host2_389 서버 응답이 마지막으로 확인된 시간입니다.
ugldap_host2_389.responsetime	ugldap_host2_389에 대한 응답 시간입니다.

로그 파일

Messaging Server는 SMTP, IMAP, POP 및 HTTP에 대한 이벤트 레코드를 기록합니다. Messaging Server 로그 파일을 작성 및 관리하기 위한 정책은 사용자 정의할 수 있습니다.

로깅이 서버 성능에 영향을 주므로 서버에 부담을 주기 전에 로깅을 매우 신중하게 고려해야 합니다. 자세한 내용은 20장, "로깅 및 로그 분석"을 참조하십시오.

imsimta counters

MTA는 메일 모니터링 MIB, RFC 1566에 기초하여 각 활성 채널에 대한 메일 트래픽 카운터를 증가시킵니다. 채널 카운터는 전자 메일 시스템의 추세와 상태를 나타내는 데 도움을 줍니다. 채널 카운터는 메일 트래픽의 정확한 계산을 제공하도록 설계되지는 않았습니다. 정확한 계산을 보려면 20장, "로깅 및 로그 분석"에 설명된 대로 MTA 로깅을 확인합니다.

MTA 채널 카운터는 사용 가능한 최소 경량 기법을 사용하여 구현되므로 가능한 한 실제 작업에 미치는 영향이 최소화됩니다. 채널 카운터는 그 이상을 시도하지 않습니다. 즉, 섹션을 매핑하려는 시도가 실패할 경우 정보가 기록되지 않고 섹션의 잠금 중 하나를 거의 즉각적으로 얻을 수 없을 경우 정보가 기록되지 않으며 시스템이 종료할 경우 메모리 내장 섹션에 포함된 정보가 영원히 손실됩니다.

imsimta counters -show 명령은 MTA 채널 메일 통계(아래 참조)를 제공합니다. 시간이 지나면 최소값에 주의하면서 이러한 카운터를 검사해야 합니다. 일부 채널의 경우 최소값은 실제로 음수일 수 있습니다. 음수 값은 카운터가 0이 되었을 때(클러스터 전반의 카운터 데이터베이스 작성 시) 채널에 대해 대기 중인 메일이 존재했다는 것을 의미합니다. 이러한 메일이 대기열에서 빠지면 채널의 관련 카운터가 감소하므로 결과적으로 음수 최소값이 생성됩니다. 이러한 카운터의 경우 올바른 "절대값"은 초기화 이후부터 카운터가 지니고 있는 최소값이 아니라 현재 값입니다.

Channel          Messages    Recipients    Blocks
-------          --------    ----------    -------
tcp_local
   Received       29379       79714      982252                      (1)
   Stored            61         113       -2004                      (2)
   Delivered      29369       79723      983903 (29369 first time)    (3)
   Submitted      13698       13699       18261                      (4)
   Attempted          0           0           0                      (5)
   Rejected           1          10           0                      (6)
   Failed           104         104        4681                      (7)

   Queue time/count        16425/29440 = 0.56                        (8)
   Queue first time/count  16425/29440 = 0.56                        (9)

   Total In Assocs           297637
   Total Out Assocs           28306

1) Received는 tcp_local이라는 채널의 대기열에 포함된 메일 수입니다. 즉, 다른 채널에 의해 tcp_local의 대기열에 포함된 메일(mail.log* 파일의 E 레코드)입니다.

3) Delivered는 tcp_local 채널에 의해 처리된(대기열에서 제외된) 메일 수입니다. 즉, mail.log* 파일의 D 레코드입니다. 대기열에서 제외하는 작업은 성공적인 전달(즉, 다른 채널의 대기열에 포함)에 해당하거나 보낸 사람에게 반송되는 메일로 인한 작업에 해당할 수 있습니다. 일반적으로 이 값은 Received에서 Stored를 뺀 숫자입니다.

MTA는 또한 처음 시도할 때 대기열에서 제외된 메일 수를 추적하며 이 수는 괄호로 표시됩니다.

4) Submitted는 tcp_local 채널에 의해 다른 채널의 대기열에 포함된 메일 수(mail.log 파일의 E 레코드)입니다.

5) Attempted는 대기열에서 제외시키는 도중에 일시적인 문제를 경험한 메일 수(즉, mail.log* 파일의 Q 또는 Z 레코드)입니다.

6) Rejected는 시도된 대기열에 포함 작업 중에서 거부된 작업 수(즉, mail.log* 파일의 J 레코드)입니다.

7) Failed는 시도된 대기열에서 제외하기 작업 중에서 실패한 작업 수(즉, mail.log* 파일의 R 레코드)입니다.

8) Queue time/count는 전달된 메일이 대기열에 있는 평균 시간입니다. 여기에는 처음 시도에서 전달된 메일((9) 참조)와 추가 전달 시도가 필요했던 메일(대기열에 여유 공간이 생길 때까지 오랜 시간을 기다린 메일)이 모두 포함됩니다.

9) Queue first time/count는 처음 시도에서 전달된 메일이 대기열에 있는 평균 시간입니다.

제출된 메일 수가 전달된 메일 수보다 많을 수 있다는 것을 유의하십시오. 이것은 채널이 대기열에서 제외하는(전달하는) 각 메일이 대기열에 포함되는(제출되는) 최소한 하나 이상의 새 메일이 되기 때문에 흔히 발생하는 일입니다. 예를 들어, 메일에 다른 채널을 통해 도달하는 두 명의 수신자가 있는 경우 대기열에 포함 작업은 두 개가 필요합니다. 또는 메일이 바운스될 경우 복사본 하나가 보낸 사람에게 되돌아가고 다른 복사본 하나가 포스트마스터에게 보내질 수 있습니다. 이 경우 일반적으로 제출 작업은 두 개가 될 것입니다(두 복사본이 동일한 채널을 통해 도달하지 않을 경우).

Submitted 및 Delivered 간의 연결은 채널 유형에 따라 바뀌는 것이 더 일반적입니다. 예를 들어, 변환 채널에서는 메일이 일부 다른 임의 채널에 의해 대기열에 포함되고 나면 변환 채널이 해당 메일을 처리하여 또 다른 채널의 대기열에 포함시킨 다음 자신의 대기열에서 제외되었다는 것을 메일에 표시합니다. 각 개별 메일은 다음 경로를 가집니다.

elsewhere -> conversion   E record   Received
conversion -> elsewhere   E record   Submitted
conversion                 D record   Delivered

그러나 “"pass through"가 아니라 두 개의 개별 부분(슬레이브 및 마스터)을 가지는 tcp_local과 같은 채널의 경우 Submitted 및 Delivered 사이에 연결이 없습니다. Submitted 카운터는 tcp_local 채널의 SMTP 서버 부분과 관련되며 Delivered 카운터는 tcp_local 채널의 SMTP 클라이언트 부분과 관련됩니다. 이들은 완전히 별개인 두 개의 프로그램이며 각각을 통과하는 메일이 완전히 다를 수 있습니다.

채널이 대기열에서 제외하는(전달하는) 메일은 대기열에 포함되는(제출되는) 최소한 하나 이상의 새 메일이 됩니다. 예를 들어, 메일에 다른 채널을 통해 도달하는 두 명의 수신자가 있는 경우 대기열에 포함 작업은 두 개가 필요합니다. 또는 메일이 바운스될 경우 복사본 하나가 보낸 사람에게 되돌아가고 다른 복사본 하나가 포스트마스터에게 보내질 수 있습니다. 이 경우에는 일반적으로 두 복사본이 동일한 채널을 통해 도달할 것입니다.

UNIX 및 NT에서의 구현

성능상의 이유로 인해 MTA를 실행하는 노드는 공유 메모리 섹션(UNIX) 또는 공유 파일 매핑 객체(NT)를 사용하여 채널 카운터 캐시를 메모리에서 유지합니다. 노드의 프로세스가 대기열에서 메일을 포함시키거나 제외시킬 때 이 메모리 내장 캐시의 카운터가 업데이트됩니다. 채널이 실행될 때 내장 메모리 섹션이 존재하지 않을 경우 이 섹션은 자동으로 만들어집니다. (또한 내장 메모리 섹션이 존재하지 않을 경우 imta start 명령은 이 섹션을 만듭니다.)

imta counters -clear 또는 imta qm counters clear 명령을 사용하면 카운터를 0으로 재설정할 수 있습니다.

imsimta qm counters

imsimta qm counters 유틸리티는 MTA 채널 대기열 메일 카운터를 표시합니다. 이 유틸리티를 실행하려면 루트 또는 inetuser여야 합니다. 출력 필드는 imsimta counters에 설명된 것과 동일합니다. 사용 방법에 대한 자세한 내용은 Sun Java System Messaging Server Administration Reference를 참조하십시오.

Channel                 Messages     Recipients    Blocks
----------------------  ----------  ----------    ----------
tcp_intranet
   Received              13077        13859         264616
   Stored                   92           91           -362
   Delivered             12985        13768         264978
   Submitted              2594         2594           3641
...

MTA를 다시 시작할 때마다# imsimta counters -create를 실행해야 합니다.

SNMP를 사용한 MTA 모니터링

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

메일함 할당량 검사를 위한 imquotacheck

imquotacheck 유틸리티를 사용하여 메일함 할당량 사용과 제한을 모니터할 수 있습니다. imquotacheck 유틸리티는 정의된 할당량과 제한을 나열하는 보고서를 생성하며 할당량 사용에 대한 정보를 제공합니다.

예를 들어, 다음 명령은 모든 사용자 할당량 정보를 나열합니다.

다음 예에서는 sorook이라는 사용자의 할당량 사용을 보여 줍니다.

이전 목차 색인 다음
Sun Java System Messaging Server 6 2004Q2 관리 설명서