第 23 章 監視 Messaging Server

在大多數情況下，規劃與配置完善的伺服器無需管理員的大量介入即可執行。但是，作為管理員，監視伺服器以發現問題徵兆是您的工作。本章說明 Messaging Server 的監視功能。包含以下各節：

• 日常監視作業

• 監視系統效能

• 監視 MTA

• 監視郵件存取

• 監視 LDAP 目錄伺服器

• 監視郵件儲存

• 用於監視的公用程式和工具

疑難排解程序位於第 22 章, MTA 疑難排解中。

自動監視和重新啟動

Messaging Server 提供的方法，可透明地監視服務並在這些服務失敗或無回應 (服務掛起或凍結) 時重新啟動它們。它可監視所有的郵件儲存、MTA 和 MMP 服務，包括 IMAP、POP、HTTP、工作控制器、派送程式和 MMP 伺服器；但無法監視其他服務，如 SMS 或 TCP/SNMP 伺服器。(TCP/SNMP 由工作控制器監視。)請參閱自動重新啟動失敗或無回應的服務和使用 msprobe 和 watcher 功能進行監視。

日常監視作業

應在每天執行的最重要作業是檢查 Postmaster 郵件、監視記錄檔以及設定 stored 公用程式。這些作業描述如下。

檢查 Postmaster 郵件

Messaging Server 為 Postmaster 電子郵件設定了預先定義的管理郵件收件人清單。此郵件收件人清單中的所有使用者均將自動接收傳送至 Postmaster 的郵件。

Postmaster 郵件的規則在 RFC822 中定義，RFC822 要求每個電子郵件站點均接受傳送給名為 Postmaster 的使用者或郵件收件人清單的郵件，並要求將傳送至該位址的郵件遞送給實際人員。傳送至 postmaster@host.domain 的所有郵件均被傳送至 Postmaster 帳號或郵件收件人清單。

通常，Postmaster 位址是使用者應傳送有關郵件服務的電子郵件的位址。作為 Postmaster，您可能會收到來自本機使用者的關於伺服器回應時間的郵件，以及來自其他伺服器管理員 (他們在向您的伺服器傳送郵件時遇到問題) 的郵件等。您應每天檢查 Postmaster 郵件。

您還可以配置伺服器以向 Postmaster 位址傳送某些錯誤訊息。例如，當 MTA 無法路由或遞送郵件時，您可以經由傳送至 Postmaster 位址的電子郵件獲得通知。您還可以向 Postmaster 傳送異常狀況警告 (磁碟空間偏低以及伺服器回應緩慢)。

監視和維護記錄檔

Messaging Server 為其支援的每個主要協定或服務 (包括 SMTP、IMAP、POP 以及 HTTP) 建立一組單獨的記錄檔。這些記錄檔位於 msg_svr_base/data/log 中。您應定期監視記錄檔 - 特別是在您的伺服器出現問題時。

請注意記錄會影響伺服器效能。您指定的記錄詳細度越高，您的記錄檔在給定時間內佔用的磁碟空間就越大。您應為伺服器定義有效可行的記錄旋轉策略、過期策略和備份策略。如需有關定義伺服器記錄策略的資訊，請參閱第 21 章, 管理記錄。

設定 msprobe 公用程式

msprobe 公用程式自動執行監視及重新啟動功能。如需詳細資訊，請參閱使用 msprobe 和 watcher 功能進行監視

監視系統效能

本章重點說明 Messaging Server 監視。但是，您還需要監視伺服器所在的系統。配置完善的伺服器無法在未調校好的系統上正常執行，並且伺服器故障徵兆可能表示硬體不足以為電子郵件負載提供服務。本章不提供有關監視系統效能的所有詳細資訊，因為許多這些程序都是針對特定平台的，並可能要求您參閱平台特定的系統說明文件。此處描述以下效能監視程序：

• 監視端對端郵件遞送時間

• 監視磁碟空間

• 監視 CPU 使用率

監視端對端郵件遞送時間

電子郵件需要準時遞送。這可能是服務合約要求，同時也是可以讓郵件儘快遞送的一個良好策略。端對端速度緩慢可以說明很多問題。可能是伺服器運作不正常，或者是一天中的某些時間內遇到過大的郵件負載，或者是超出現有硬體資源的能力範圍。

端對端郵件遞送速度緩慢的徵兆

與正常情況相比，遞送郵件需要更長的時間。

監視端對端郵件遞送時間

• 使用收發郵件的任一功能區。比較伺服器資料傳送路徑點之間的標頭時間，以及原點和擷取點之間的時間。請參閱 immonitor-access。

監視磁碟空間

磁碟空間不足是導致郵件伺服器問題與故障的最常見原因之一。如果沒有空間用於寫入 MTA 佇列或郵件儲存，郵件伺服器將失敗。此外，除非您監視並清除記錄檔，否則它們會無限增長，從而佔用所有磁碟空間。

當新的郵件遞送至電子信箱時，郵件儲存分割區會增加；例如，若不限制郵件儲存配額，則郵件儲存可能會超出分割區可用的磁碟空間。磁碟空間耗盡的另一個原因是 MTA 郵件佇列變得過大。第三種可能的原因是記錄檔監視設備出現問題時記錄檔無限制地增長。(請注意，這些記錄檔包括 LDAP、MTA 和郵件存取等，並且每個記錄檔均可儲存在不同磁碟上。)

磁碟空間問題的徵兆

根據空間耗盡的磁碟或分割區的不同可能出現不同的徵兆。MTA 佇列可能溢位並拒絕 SMTP 連線，郵件可能仍保留在 ims_master 佇列中而不會遞送到郵件儲存，並且記錄檔可能溢位。

如果郵件儲存分割區填滿，郵件存取常駐程式將失敗，郵件儲存資料也會損毀。郵件儲存維護公用程式 (例如 imexpire 和 reconstruct) 可以修復損壞並降低磁碟使用率。但是，這些公用程式需要附加的磁碟空間，並且修復已填滿整個磁碟的分割區可能會導致當機。

監視磁碟空間

根據系統配置的不同，您可能需要監視不同的磁碟和分割區。例如，MTA 佇列可能位於一個磁碟/分割區上，郵件儲存可能位於另一個磁碟/分割區上，並且記錄檔可能又位於其他磁碟/分割區上。每個空間均需要監視，並且監視它們的方法可能不同。

Messaging Server 提供了監視郵件儲存磁碟使用率和防止分割區填滿所有可用磁碟空間的特定方法。

可以執行以下步驟來監視郵件儲存磁碟空間使用率︰

• 設定參數以監視郵件儲存磁碟使用率

• 當達到磁碟使用率的臨界值時，鎖定郵件儲存分割區

如需詳細資訊，請參閱以下小節：監視郵件儲存和監視郵件儲存分割區。

監視郵件儲存

建議郵件儲存磁碟的使用率不超過容量的 75%。可以使用 configutil 公用程式配置以下警示屬性，來監視郵件儲存磁碟使用率：

• alarm.diskavail.msgalarmstatinterval

• alarm.diskavail.msgalarmthreshold

• alarm.diskavail.msgalarmwarninginterval

• alarm.diskavail.msgalarmdescription

透過設定這些參數，您可以指定系統監視磁碟空間的頻率以及在何種情況下傳送警告。例如，如果您希望系統每 600 秒監視一次磁碟空間，請指定以下指令：

configutil -o alarm.diskavail.msgalarmstatinterval -v 600

如果您希望在可用磁碟空間低於 20% 時收到警告，請指定以下指令：

configutil -o alarm.diskavail.msgalarmthreshold -v 20

請參閱表 23–6，以取得有關這些參數的更多資訊。

監視郵件儲存分割區

當郵件儲存分割區填充的磁碟空間比率大於指定的可用磁碟空間百分比時，您可以停止向分割區遞送郵件。執行方法是：設定兩個 configutil 參數以啟用此功能，並指定磁碟使用率的臨界值。

透過此功能，郵件儲存常駐程式可監視分割區的磁碟使用率。當磁碟使用率增加時，儲存常駐程式將更加頻繁地 (從每 100 分鐘檢查一次到每一分鐘檢查一次) 對分割區進行動態檢查。

如果磁碟使用率高於指定的臨界值，則儲存常駐程式將︰

• 鎖定分割區。內送郵件將保留在 MTA 郵件佇列中，而未遞送至郵件儲存分割區中的電子信箱。

• 將郵件記錄至預設記錄檔。

• 向 Postmaster 傳送電子郵件通知。(可以透過設定 configutil 參數 alarm.msgalarmnoticercpt 來變更電子郵件收件者。)

當磁碟使用率低於臨界值時，則解除鎖定分割區並且再將郵件遞送至該儲存。

configutil 參數如下︰

• local.store.checkdiskusage 可啟用分割區監視功能。

  允許的值：yes、no

  預設值：yes

• local.store.diskusagethreshold 可指定磁碟使用率臨界值。local.store.diskusagethreshold 的值為一個百分比，其百分值介於 1 到 99 之間。

  預設值：99

您應該將磁碟使用率的臨界值設定為足夠低的百分比，以便有時間重新分割或指定更多的磁碟空間給本機郵件儲存。

例如，假設分割區以每小時 2% 的速率填充磁碟空間，而為本機郵件儲存配置其他磁碟空間需要花費一小時。在此情況下，您應該將磁碟使用率的臨界值設定為一個低於 98% 的值。

監視 MTA 佇列和記錄空間

您將需要監視 MTA 佇列磁碟並記錄磁碟空間使用率。

如需有關管理記錄空間的資訊，請參閱第 21 章, 管理記錄。例如，若要瞭解如何監視 mail.log 檔案，請參閱管理 MTA 郵件和連線記錄

監視 CPU 使用率

高 CPU 使用率表示沒有足夠的 CPU 容量可用，或表示某些程序使用過多的 CPU 循環。

CPU 使用率問題的徵兆

系統回應時間長。使用者登入緩慢。遞送速度緩慢。

監視 CPU 使用率

監視 CPU 使用率是平台特定的作業。請參閱相關的平台說明文件。

監視 MTA

本節包含以下小節：

• 監視郵件佇列的大小

• 監視遞送失敗率

• 監視內送 SMTP 連線

• 監視派送者程序和工作主控台程序

監視郵件佇列的大小

郵件佇列的過度增長可能表示郵件未被傳送、傳送延遲或進入速度高於系統傳送速度。導致出現該問題的原因有很多，如由大量郵件湧入系統而導致的拒絕服務攻擊，或者是工作控制器未執行。

請參閱通道郵件佇列、郵件未移出佇列以及 MTA 郵件未遞送，以取得有關郵件佇列的更多資訊。

郵件佇列問題的徵兆

• 磁碟空間使用率增大。

• 使用者未在合理時間內收到郵件。

• 郵件佇列大小過大。

監視郵件佇列的大小

監視郵件佇列的最佳方法可能是使用 imsimta qm。請參閱 imsimta qm 計數器。

還可以監視佇列目錄 (msg_svr_base/data/queue/) 中的檔案數目。檔案數目將是站點特定的，並且您需要建立基線歷程記錄以找出何為「太多」。您可以記錄兩週內佇列檔案的大小，以取得近似平均數。

監視遞送失敗率

傳送失敗是指嘗試將郵件傳送至外部站點時失敗。傳送失敗率大幅度增長可能表示出現網路問題，例如 DNS 伺服器或遠端伺服器停用，從而導致回應連線逾時。

遞送失敗率的徵兆

沒有明顯徵兆。mail.log_current 中會出現許多 Q 記錄。

監視遞送失敗率

傳送失敗以記錄項目代碼 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 連線

• 外部使用者在轉送郵件︰查看 msg_svr_base/log/mail.log_current，以查找帶有記錄項目代碼 J 的記錄 (被拒絕的轉送)。若要啟動遠端 IP 位址記錄，請將以下行增加至 option.dat 檔案：

  log_connection=1

  請注意，啟用此功能時效能可能會略微降低。

• 拒絕服務攻擊︰若要找出連線 SMTP 伺服器的使用者以及使用者數量，可以執行指令 netstat，並檢查 SMTP 連接埠 (預設值：25) 上的連線。範例：

Local address       Remote address                                 State
192.18.79.44.25     192.18.78.44.56035    32768   0  32768   0   CLOSE_WAIT
192.18.79.44.25     192.18.136.54.57390    8760   0  24820   0   ESTABLISHED
192.18.79.44.25     192.18.26.165.48508   33580   0  24820   0   TIME_WAIT

請注意，首先需要確定適當的系統 SMTP 連線數目及其狀態 (ESTABLISHED、CLOSE_WAIT 等)，以確定特定讀取是否不正常。

如果發現許多連線處於 SYN_RECEIVED 狀態，則這可能是由網路中斷或拒絕服務攻擊導致的。此外，SMTP 伺服器程序的存在時間是受限制的。該時間由 dispatcher.cnf 檔案中的 MTA 配置變數 MAX_LIFE_TIME 控制。預設為 86,400 秒 (一天)。同樣地，MAX_LIFE_CONNS 指定伺服器程序可在其使用期限內處理的連線之最大數目。如果您發現特定 SMTP 伺服器使用了很長一段時間，則可能希望調查一下。

監視派送者程序和工作主控台程序

必須執行派送程式和工作控制器程序，MTA 才能運作。每種類型您均應擁有一個程序。

派送程式和工作控制器程序當機的徵兆

如果派送程式當機或者沒有足夠的資源，則 SMTP 連線會被拒絕。

如果工作控制器當機，則佇列大小將增加。

監視派送程式和工作控制器程序

查看名為 dispatcher 和 job_controller 的程序是否存在。請參閱檢查工作控制器和派送程式是否正在執行。

監視 LDAP 目錄伺服器

本節包含以下小節：

• 監視 slapd

監視 slapd

LDAP 目錄伺服器 (slapd) 為郵件傳送系統提供目錄資訊。如果 slapd 當機，則系統將無法正常工作。如果 slapd 的回應時間太長，將影響登入速度和需要 LDAP 查詢的任何其他作業事件。

slapd 問題的徵兆

• 用戶端 POP、IMAP 或 Webmail 認證失敗或比預期速度慢。

• MTA 沒有正常運作

監視 slapd

• 檢查 ns-slapd 程序是否正在執行。

• 檢查slapd-instance/logs/ 中的 slapd 記錄檔 access 和 errors

• 搜尋使用者時，檢查 ns-slapd 回應時間。

• 檢視主控台以監視 slapd。

• 另請參閱 immonitor-access

監視郵件存取

本節包含以下小節：

• 監視 imapd、popd 和 httpd

• 監視 stored

監視 imapd、popd 和 httpd

這些程序提供 IMAP，POP 以及 Webmail 服務存取權限。如果這些程序中有任何程序未執行或未回應，則服務將無法正確運作。如果服務在執行，但是超出負載，監視將允許您偵測到此情況並更適當地配置該服務。

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 和 msprobe 進行監視。請參閱自動重新啟動失敗或無回應的服務和使用 msprobe 和 watcher 功能進行監視

• 可以使用 SNMP 進行監視。

  如果您已設定 SNMP，這是監視這些程序的好方法。請參閱附錄 ASNMP 支援。伺服器資訊位於網路服務監視 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) 排序，具有最高序列號的檔案是第二新的檔案。(請參閱第 21 章, 管理記錄。)

  如果伺服器關閉，您可能會看到如下訊息：

  imap.12.1065431243:[07/Oct/2003:01:15:43 -0700] gotmail-2 imapd[20525]: 一般警告：Sun Java System Messaging Server IMAP4 6.1 (2003 年 9 月 24 日建置) 已關閉

• 可以使用 counterutil 檢查。請參閱「Sun Java System Messaging Server 6 2005Q4 Administration Reference」中的「counterutil」中的counterutil 和 「counterutil」。

• 執行平台特定的指令，以驗證 imapd、popd 和 httpd 程序在執行。例如，在 Solaris 中，可以使用 ps 指令，以及搜尋 imapd、popd 和 mshttpd。

• 可以透過設定警報郵件中說明的伺服器回應配置參數，為指定的伺服器效能臨界值設定警示。

• 請參閱 immonitor-access。

監視 stored

stored 執行各項重要作業，例如郵件資料庫的死結和作業事件作業、強制執行時效策略以及刪除磁碟上儲存的郵件。如果 stored 停止執行，郵件傳送伺服器最終會遇到問題。如果 stored 未在 start-msg 執行時啟動，則其他程序均不會啟動。如需有關 stored 的更多資訊，請參閱「Sun Java System Messaging Server 6 2005Q4 Administration Reference」中的「stored」。

stored 問題的徵兆

沒有明顯徵兆。

監視 stored

• 檢查 stored 程序是否正在執行。stored 在名為 pidfile.store 的 msg_svr_base/config 中建立並更新 pid 檔案。pid 檔案在回復時顯示 init 狀態，在準備就緒時顯示 ready 狀態。例如：

  231: cat pidfile.store 28250 ready

  第一行的數字是 stored 的程序 ID。

  232: ps -eaf | grep stored inetuser 28250 1 0 Jan 05 ? 8:44 /opt/SUNWmsgsr/lib/stored -d

• 檢查 msg_svr_base/store/mboxlist 中建立的記錄檔。請注意，並非每個記錄檔的建立都是由直接的 stored 問題導致的。如果 imapd 停止或者出現資料庫問題，也會建立記錄檔。

• 檢查 msg_svr_base/config 中以下檔案的時間戳記：

  stored.ckp - 在檢查點進行嘗試時涉及。應該每 1 分鐘戳記一次時間 stored.lcu - 每次清除資料庫記錄檔時涉及。應該每 5 分鐘戳記一次時間 stored.per - 每次進行每個使用者的資料庫寫出時涉及。應該每 60 分鐘標記一次時間

• 檢查預設記錄檔 msg_svr_base/log/default/default 中的 stored 郵件。

• 可以使用 watcher 和 msprobe 進行監視。請參閱自動重新啟動失敗或無回應的服務和使用 msprobe 和 watcher 功能進行監視。

監視郵件儲存

郵件儲存在資料庫中。磁碟上使用者的分布、使用者電子信箱的大小以及磁碟需求均會影響儲存效能。以下各節會描述這些情況︰

• 監視磁碟空間

• 監視郵件儲存資料庫鎖定的狀態

• 監視 mboxlist 目錄中資料庫記錄檔的數目

• 監視配額限制

監視郵件儲存資料庫鎖定的狀態

資料庫鎖定的狀態由不同的伺服器程序控制。這些資料庫鎖定會影響郵件儲存的效能。如果出現死結，郵件將無法以正常速度插入儲存，結果將導致 ims-ms 通道佇列增大。備份佇列有合理的原因，因此保留佇列長度歷程對於診斷問題非常有用。

郵件儲存資料庫鎖定問題的徵兆

大量異動累積未解決。

監視郵件儲存資料庫鎖定

使用指令 counterutil -o db_lock

監視 mboxlist 目錄中資料庫記錄檔的數目

資料庫記錄檔參照不活躍的作業事件檢查點記錄檔 (msg_svr_base/store/mboxlist)。記錄檔的建立是未執行資料庫檢查點的徵兆。記錄檔的建立也可能是由於 stored 問題的原因。

資料庫記錄檔問題的徵兆

應該有 2 或 3 個記錄檔。如果有多於此數目的記錄檔，則表示可能發生嚴重問題。郵件儲存將少數資料庫用於郵件和配額，但這些資料庫的問題會導致所有郵件伺服器發生問題。

監視資料庫記錄檔

查看 msg_svr_base/store/mboxlist 目錄並確定僅有 2 或 3 個檔案。

用於監視的公用程式和工具

以下工具可用於進行監視：

• immonitor-access

• stored

• counterutil

• 記錄檔

• imsimta 計數器

• imsimta qm 計數器

• 使用 SNMP 進行 MTA 監視

• 用於電子信箱配額檢查的 imquotacheck

• 使用 msprobe 和 watcher 功能進行監視

immonitor-access

immonitor-access 監視以下 Messaging Server 元件/程序的狀態︰郵件傳送 (SMTP 伺服器)、郵件存取和儲存 (POP 和 IMAP 伺服器)、目錄服務 (LDAP 伺服器) 和 HTTP 伺服器。此公用程式可測量各項服務的回應時間，以及傳送和擷取郵件所佔用的往返總時間。此公用程式可透過在目錄中查詢指定使用者並測量回應時間來監視目錄服務；還可透過傳送郵件 (SMTP) 來監視郵件遞送，以及透過擷取郵件來監視郵件存取和儲存。監視 HTTP 伺服器僅限於確定該伺服器是否連線良好以及是否在執行中。

如需完整說明，請參閱 「Sun Java System Messaging Server 6 2005Q4 Administration Reference」中的「immonitor-access」。

stored

stored 公用程式在伺服器上執行維護作業，還可執行監視作業。但是，現在 msprobe 將監視作業處理得更好。請參閱使用 msprobe 和 watcher 功能進行監視。

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 6 2005Q4 Administration Reference」中的「counterutil」。

counterutil 輸出

counterutil 擁有多種旗標。此公用程式的指令格式可能如下所示：

counterutil -o CounterObject -i 5 -n 10

其中

-o CounterObject 表示計數器物件 alarm、diskusage、serverresponse、db_lock、popstat、imapstat 以及 httpstat。

-i 5 指定 5 秒的間隔時間。

-n 10 表示反覆運算次數 (預設為︰無限)。

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 提供警報統計資料

這些 alarm 統計參照由 stored 傳送的警示。該警示計數器提供以下統計︰

使用 counterutil 提供 IMAP、POP 和 HTTP 連線統計

可以使用指令 counterutil -oCounterObject -i 5 -n 10 取得目前 IMAP、POP 以及 HTTP 連線數、失敗登入數、自啟動時間以來的總連線數等的資訊。其中，CounterObject 表示計數器物件 popstat，imapstat 或 httpstat。imapstat 字尾的涵義顯示在表 23–2 中。popstat 和 httpstat 物件可以使用相同的格式和結構提供相同的資訊。

使用 counterutil 提供磁碟使用率統計資料

指令：counterutil -o diskusage 產生以下資訊︰

伺服器回應統計資料

指令：counterutil -o serverresponse 產生以下資訊：此資訊對於檢查伺服器是否正在執行以及伺服器的回應速度非常有用。

記錄檔

郵件傳送伺服器記錄 SMTP、IMAP、POP 和 HTTP 的事件記錄。您可以自訂建立和管理 Messaging Server 記錄檔的策略。

由於記錄可影響伺服器效能，因此在要求伺服器承擔這項重任以前應仔細考量是否需要記錄。請參閱第 21 章, 管理記錄，以取得更多資訊。

imsimta 計數器

MTA 根據郵件監視 MIB 和 RFC 1566 為每個使用中的通道累積郵件通訊量計數器。通道計數器旨在為您指示電子郵件系統的趨勢和運作狀況。通道計數器並不用於提供精確的郵件通訊量計數。如需精確計數，請參閱 MTA 記錄 (第 21 章, 管理記錄中有說明)。

MTA 通道計數器使用最輕的可用機制實作，因此它們在實際作業中產生的影響非常小。通道計數器不難嘗試：如果嘗試對映區段失敗，則不會記錄任何資訊；如果區段中的其中一個鎖定無法立即獲得，則不會記錄任何資訊；系統關閉時，內部記憶體區段中包含的資訊將永遠遺失。

imsimta counters -show 指令提供 MTA 通道郵件統計 (參閱以下內容)。需要不斷檢查這些計數器，同時請注意顯示的最小值。某些通道的最小值實際上可能為負數。負值表示在通道計數器設定為零時 (例如，建立了計數器的叢集寬度資料庫) 為該通道形成了郵件佇列。當這些郵件被移出佇列時，該通道的相關計數器便會減少，因而導致出現負的最小值。對於此類計數器，正確的「絕對」值是目前值減去計數器自初始化以來所具有的最小值。

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 記錄)。

2) Stored 是儲存在通道佇列中要傳送的郵件數。

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 是初次嘗試時傳送的郵件在佇列中花費的平均時間。

請注意，所提交的郵件數目可能大於遞送的郵件數目。這是通常情況，因為由通道移出佇列 (遞送) 的每個郵件將導致至少一個新郵件形成佇列 (提交)，但也可能是多個。例如，如果郵件有兩個分別經由不同通道到達的收件者，則將需要形成兩個佇列。或者，如果郵件被退回，系統會將一個副本傳回給寄件者，將另一個副本傳送給 Postmaster。通常，這將是兩次提交 (除非兩者都透過同一個通道到達)。

一般來說，Submitted 和 Delivered 之間的連線視通道的類型而有所不同。例如，在轉換通道中，郵件將由其他任意通道形成佇列，然後轉換通道將處理該郵件並使其在第三個通道中形成佇列，並在該郵件的自身佇列中將其標記為移出佇列。每個單獨的郵件均佔用一個路徑：

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

但是，對於 tcp_local 之類的通道，它不是「通道」，而是具有兩個單獨的部分 (從屬部分與主要部分)，並且 Submitted 與 Delivered 之間沒有連線。Submitted 計數器與 tcp_local 通道的 SMTP 伺服器部分有關，而 Delivered 計數器與 tcp_local 通道的 SMTP 用戶端部分有關。這是兩個完全獨立的程式，通過它們的郵件可以是完全獨立的。

提交給 SMTP 伺服器的郵件︰

tcp_local -> elsewhere E record Submitted

經由 SMTP 用戶端傳送給其他 SMTP 主機的郵件︰

elsewhere -> tcp_local E record Received
tcp_local              D record Delivered

通道移出佇列 (遞送) 將導致至少一個新郵件形成佇列 (提交)，但也可能是多個。例如，如果郵件有兩個分別經由不同通道到達的收件者，則將需要形成兩個佇列。或者，如果郵件被退回，系統會將一個副本傳回給寄件者，將另一個副本傳送給 Postmaster。通常將透過同一個通道到達。

在 UNIX 和 NT 上實作

由於效能原因，執行 MTA 的節點使用共用記憶體區段 (UNIX) 或共用檔案對映物件 (NT) 將通道計數器的快取保留在記憶體中。當節點上的程序將郵件形成佇列和移出佇列時，它們將更新此內部記憶體快取中的計數器。如果在通道執行時內部記憶體區段不存在，則系統將自動建立此區段。(如果內部記憶體區段不存在，imta start 指令亦可建立此區段)。

指令 imta counters -clear 或 imta qm 指令 counters clear 可用於將計數器重設為零。

imsimta qm 計數器

imsimta qm counters 公用程式顯示 MTA 通道佇列郵件計數器。必須是超級使用者或 inetuser 才能執行此公用程式。輸出欄位與 imsimta 計數器 中所述之欄位相同。另請參閱 「Sun Java System Messaging Server 6 2005Q4 Administration Reference」中的「imsimta counters」。

範例：

# imsimta counters -create
# imsimta qm counters show
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) 進行系統監視。使用 SNMP 用戶端 (有時稱為網路管理員)，例如 Sun Net Manager 或 HP OpenView (未隨附此產品提供)，可以監視 Messaging Server 的某些部分。請參閱附錄 ASNMP 支援，以取得詳細資訊。

用於電子信箱配額檢查的 imquotacheck

可以使用 imquotacheck 公用程式監視電子信箱配額的使用率和限制。imquotacheck 公用程式會產生一個報告，該報告列示定義的配額與限制，並提供有關配額使用率的資訊。

例如，以下指令將列出所有使用者配額資訊：

% imquotacheck 
-------------------------------------------------------------------------
Domain red.siroe.com (diskquota = not set msgquota = not set) quota usage
-------------------------------------------------------------------------
diskquota         size(K)    %use    msgquota      msgs    %use    user
# of domains = 1
# of users = 705

no quota          50418             no quota      4392             ajonk
no quota              5             no quota      2                andrt
no quota         355518             no quota      2500             ansri
 ...

以下範例將顯示使用者的配額使用率：

% imquotacheck -u sorook
-------------------------------------------------------------------------
quota usage for user sorook
-------------------------------------------------------------------------
diskquota      size(K)    %use    msgquota      msgs     %use    user

no quota       1487               no quota      305              sorook

使用 msprobe 和 watcher 功能進行監視

Messaging Server 提供兩個程序 watcher 和 msprobe，以監視多種系統服務。watcher 監視伺服器當機並在需要時重新啟動伺服器。msprobe 監視伺服器掛機 (未回應)。具體來說，msprobe 監視以下內容︰

• 伺服器回應時間。msprobe 使用協定指令連線啟用的伺服器，並測量其回應時間。如果回應時間超出警示警告臨界值，則會傳送警示郵件 (請參閱警報郵件 至伺服器，或伺服器回應時間超出指定的逾時時間，則會重新啟動伺服器。 伺服器回應時間記錄在計數器資料庫中，並被記錄至預設記錄檔中。counterutil 可用於顯示伺服器回應時間統計 (counterutil)。

  以下伺服器由 msprobe 監視︰imap、pop、http、cert、job_controller、smtp、lmtp、mmp 以及 ens。smtp 或 lmtp 不回應時，派送程式會重新啟動。ens 無法自動重新啟動。

• 磁碟使用率。msprobe 檢查每個郵件儲存分割區的磁碟可用性和使用率。具體來說，它檢查郵件儲存 mboxlist 資料庫目錄和 MTA 佇列目錄。如果磁碟使用率超過配置的臨界值，則將傳送警報郵件。磁碟大小和使用率將記錄在計數器資料庫中並被記錄到預設記錄檔中。管理員可以使用 counterutil 公用程式 (請參閱 counterutil) 以顯示磁碟使用率統計。

• 郵件儲存 mboxlist 資料庫記錄檔累積。記錄檔累積表明出現 mboxlist 資料庫錯誤。msprobe 計算使用中記錄檔數，並且如果使用中記錄檔數大於臨界值，msprobe 會將嚴重錯誤訊息記錄至 default 記錄檔，以告知管理員重新啟動伺服器。如果已啟用 autorestart (local.autorestart 設定為 yes)，則儲存常駐程式會重新啟動。

watcher 和 msprobe 由 configutil 選項控制 (顯示在表 23–5 中)。詳細資訊可以在自動重新啟動失敗或無回應的服務中找到

警報郵件

msprobe 可以採用電子郵件形式向 Postmaster (請參閱監視 imapd、popd 和 httpd) 發出警示，以警告指定狀況。以下是超出特定臨界值時傳送的電子郵件警報之範例：

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

            

可以指定 msprobe 監視磁碟和伺服器效能的頻率，以及在何種情況下傳送警示。此作業可透過使用 configutil 指令設定警示參數來完成。表 23–6 顯示有用的警示參數以及其預設設定。請參閱「Sun Java System Messaging Server 6 2005Q4 Administration Reference」中的「configutil Parameters」。