Sun Java System Messaging Server 6.3 管理指南

附錄 A SNMP 支援

Messaging Server 支援透過簡易網路管理協定 (SNMP) 進行系統監視。使用 SNMP 用戶端 (有時稱為網路管理員)，如 Sun Net Manager 或 HP OpenView (本產品未隨附)，可以監視 Messaging Server 的某些部分。如需有關監視 Messaging Server 的更多資訊，請參閱第 27 章, 監視 Messaging Server

本章說明如何啟用 Messaging Server SNMP 支援。它還簡要介紹了 SNMP 提供的資訊類型。請注意，本章未說明如何從 SNMP 用戶端檢視此資訊。請參閱您的 SNMP 用戶端說明文件，以取得有關如何使用此用戶端檢視基於 SNMP 之資訊的詳細資訊。本文件還說明可從 Messaging Server SNMP 實作中取得的某些資料，但完整的 MIB 詳細資訊可從 RFC 2788 和 RFC 2789 取得。

本章包含以下各節：

A.1 SNMP 實作

Messaging Server 實作兩種標準化的 MIB，即網路服務監視 MIB (RFC 2788) 和郵件監視 MIB (RFC 2789)。網路服務監視 MIB 提供對網路服務 (例如 POP、IMAP、HTTP 和 SMTP 伺服器) 的監視。郵件監視 MIB 提供對 MTA 的監視。郵件監視 MIB 允許監視每個 MTA 通道的使用中狀態和歷史狀態。使用中資訊主要是指目前排入佇列的郵件和開放式網路連線 (例如，排入佇列的郵件之計數，以及開放式網路連線的源 IP 位址)，而歷史資訊則提供累計的總數 (例如，已處理的郵件總數，以及內送連線總數)。

備註 –

如需 Messaging Server SNMP 監視資訊的完整清單，請參閱 RFC 2788 和 RFC 2789。

SNMP 在執行 Solaris 和 Red Hat Linux 的平台上受到支援。Solaris 9 作業系統上的 Messaging Server 使用 Solstice Enterprise Agents (SEA)。從 Solaris 10 作業系統開始，Messaging Server 支援開放原始碼 Net-SNMP 監視架構，委託 Solaris 9 作業系統的 Solstice Enterprise Agents (SEA) 技術承襲 (支援的存留時間結束時之) 狀態。此外，Linux 平台上廣泛使用 Net-SNMP。Messaging Server 會在 Solaris 10 和更新版本以及 Linux 平台上使用其 Net-SNMP 型 SNMP 子代理程式。

Messaging Server 的 SNMP 子代理程式採用 Net-SNMP 架構，提供新功能：

對 SNMP 2c 和 3 版提供支援。此支援由 Net-SNMP 架構所提供。之前的 SNMP 技術 Solstice Enterprise Agents 僅提供對 SNMP 1 版的支援。增強的安全性功能和存取控制是這兩個 SNMP 版本的主要優點。
子代理程式可配置成執行為「獨立」SNMP 代理程式。這會提供站點其他方式隔離在相同系統上執行的各種 SNMP 代理程式。
在相同系統上執行的多個 Messaging Server「實例」可能同步受到監視。此支援由上述兩版其中之一所提供，或透過使用 SNMP 3 版的「內容名稱 (context names)」所提供。這允許 SNMP 監視容錯移轉叢集中的 Messaging Server 。

Messaging Server SNMP 支援的限制如下：

僅能透過 Solaris 9 作業系統上的 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 指令 (不指定任何參數) 將自動啟動 SNMP 子代理程式程序和其他 Messaging Server 程序。

請注意，Solaris 本機 SNMP 主代理程式必須處於執行狀態，以便 Messaging Server SNMP 子代理程式進行作業。Solaris 本機 SNMP 主代理程式是 snmpdx 常駐程式，通常做為 Solaris 啟動程序的一部分啟動。

SNMP 子代理程式將自動選取在其上偵聽的 UDP 連接埠。如果需要，您可以使用以下指令將固定的 UDP 連接埠指定給子代理程式：

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

之後，您可以透過將連接埠號指定為零來還原此設定。零值 (預設設定) 告訴 Messaging Server 允許子代理程式自動選取任何可用的 UDP 連接埠。

在 /etc/snmp/conf 目錄中，有兩個 SNMP 子代理程式配置檔案：ims.acl (包含 SNMP 存取控制資訊) 和 ims.reg (包含 SNMP MIB OID 註冊資訊)。

通常無需編輯這兩個檔案。Messaging Server 實作的 MIB 是唯讀的，且無需在 ims.reg 檔案中指定連接埠號。如果您指定了連接埠號，則將使用該連接埠號，除非您還使用 configutil 公用程式設定了另一個連接埠號。在這種情況下，使用 configutil 設定的連接埠號是子代理程式將要使用的連接埠號。如果您要編輯這兩個檔案，則需要停止並重新啟動 SNMP 子代理程式，以使您的變更生效：

# stop-msg snmp
# start-msg snmp

備註 –

在 Messaging Server 啟用 SNMP 支援的期間，任何在 Solaris 10 作業系統上透過 SNMP 所進行的查詢，皆須連線至預設的連接埠 16161。例如，如果使用開放原始碼 SNMP 工具 snmpwalk 查詢 Messaging Server 的網路/郵件統計資料，請使用 -p 16161 選項。

A.3 配置 Solaris 10 作業系統的 SNMP 支援

SNMP 監視預設會在 Messaging Server 內停用。選擇此預設值是為了減少預設 Messaging Server 配置所提供的服務數。請勿將此預設值解釋成使用 SNMP 監視會對效能造成不良影響。實際上，Messaging Server 的 SNMP 支援所耗用的資源極微小，對 Messaging Server 的影響並不大。總而言之，您僅需要執行配置步驟一次，便可使用 Messaging Server 的 SNMP 支援。此外，平台的 Net-SNMP 主代理程式 snmpd 之預設配置一般需要變更，才能執行 Messaging Server 等子代理程式。下一節的主題旨在說明此變更。

A.3.1 Net-SNMP 配置

Messaging Server 的 Net-SNMP 型 SNMP 子代理程式使用 AgentX 協定與平台的 SNMP 主代理程式 (RFC 2741) 進行通訊。Net-SNMP 主代理程式 snmpd 必須配置為允許使用 AgentX 協定。若要執行這項作業，請確定平台的 snmpd.conf 檔案包含此行：

master agentx

如果沒有，請增加此行再重新啟動 snmpd 常駐程式。請注意，光是傳送 SIGHUP 訊號至常駐程式並不足夠。一旦重新啟動 snmpd 常駐程式，請尋找 snmpd 為 AgentX 通訊所建立的 UNIX 網域通訊端。在 Solaris 和 Linux 系統上，此通訊端預設會顯示為特殊檔案 /var/agentx/master；但是其位置和名稱可能會透過 snmpd.con 檔案而變更。

Solaris 10 作業系統的 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。若是初始測試，建議執行後者。方法是在名為「systemview」的檢視中包含 OID 子樹 mib-2.27 和 mib-2.28，如下所示。若是實際的部署，各個站點必須考量各自的整體安全性策略。請注意，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 3 版的內容名稱，區分在相同主機電腦上同步執行的不同 Messaging Server 實例之 MIB，則您至少還需要配置一個 SNMP 3 版的使用者名稱和密碼，以搭配 SNMP 3 版的查詢使用。

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 檔案是網路服務和 MTA MIB 的副本。在 Solaris 系統上，這些檔案也可在 /etc/sma/snmp/mibs/ 目錄中依 NETWORK-SERVICES-MIB.txt 和 MTA-MIB.txt 名稱找到。您不一定要提供這些檔案給 snmpwalk 工具；但是這麼做可讓 snmpwalk 列印每個 MIB 變數的名稱，而不只是數值物件識別碼 (Numeric Object Identifier, OID)。

在 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 連接埠。子代理程式預設會在使用 UDP 連接埠 161 的所有可用乙太網路介面上偵聽。在大部分的情況下，會需要變更此連接埠號以避免干擾平台的 SNMP 主代理程式 snmpd。在 HA 容錯移轉等部分情況下，還需要將乙太網路介面從所有可用的介面 INADDR_ANY 變更為由其 IP 位址識別的特定介面。乙太網路介面和 UDP 連接埠這兩個概念透過 local.snmp.listenaddr 和 local.snmp.port 選項所控制。

一旦決定要使用的乙太網路介面和 UPD 連接埠，即應將 local.snmp.standalone 選項的值設定為 1，並接著重新啟動子代理程式。重新啟動之後，子代理程式會以獨立於 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 實例之技術。第一種技術是以獨立模式執行子代理程式，適用於高可用性容錯移轉 (HA) 配置，其中個別的 Messaging Server 實例可能會在主機電腦之間動態移動。第二種技術使用 SNMP 3 版的內容名稱，在單一系統上有多個 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 支援，則不管 Messaging Server 實例執行所在的實體叢集主機，監視工作站皆可透過其容錯移轉 IP 位址或主機名稱監視每個實例。此外，還確保 Messaging Server 的獨立 SNMP 代理程式不會彼此衝突，因為這些代理程式僅會在由實例的唯一容錯移轉 IP 位址識別之各自的虛擬乙太網路介面上偵聽。(這些虛擬乙太網路介面會自動由 HA 容錯移轉架構建立。)由於謹慎選取 UDP 連接埠，代理程式不會與叢集內多部系統上所執行的 snmpd 常駐程式衝突。

A.3.6 透過 SNMP 3 版的內容名稱區分多個實例

雖然如A.3.3 以獨立 SNMP 代理程式執行中所述，以獨立模式使用 Messaging Server 的 SNMP 支援並無不利之處，但是還是有些站台偏好使用較傳統的子代理程式模式，同時仍然保留監視相同系統上同步執行的多個 Messaging Server 實例之功能。例如，SNMP 監視系統的授權模式會限制輪詢的 IP 位址數目。若要達到此目的，請繼續執行 Messaging Server 的 SNMP 子代理程式，並將 local.snmp.standalone 設定為零。此外，為 local.snmp.enablecontextname 選項指定非零值，會配置每個 Messaging Server 實例使用明確的 SNMP 3 版內容名稱。如果需要內容名稱不同於 service.defaultdomain 的值，則請使用 local.snmp.contextname 選項設定所需的名稱。一旦重新啟動每個 Messaging Server 實例的 SNMP 子代理程式，便能接著透過包含適當內容名稱的 SNMP 3 版查詢進行監視。在相同系統上執行的兩個 Messaging Server 實例之 MIB 會由實例的 SNMP 3 版內容名稱區分，因此 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–1 SNMP 子代理程式選項


選項 (預設值)	說明
local.snmp.enable (0)	只有當指定此選項 `1` 或 `true` 值時，才會執行 Messaging Server SNMP 子代理程式，不管指定何值，Messaging Server 皆會自動停止和啟動子代理程式，以做為正常啟動與關閉程序的一部分。依預設，此選項設定為零，表示停用子代理程式的作業。啟用子代理程式之前，請確定已如A.3.3 以獨立 SNMP 代理程式執行中所述，正確配置了平台的主代理程式。
local.snmp.standalone (0)	Messaging Server 的 SNMP 支援一般會以 SNMP 子代理程式執行，並透過平台的 SNMP 主代理程式 `snmpd` 接收 SNMP 請求。此為預設作業模式，並可透過指定此選項 0 或 `false` 值加以選取。但是，如A.3.3 以獨立 SNMP 代理程式執行中所述，此子代理程式可能以「獨立」模式執行，並以獨立於 `snmpd` 的 SNMP 代理程式運作。以獨立模式執行時，子代理程式 (現在為 SNMP 代理程式) 會在由 `local.snmp.listenaddr` 和 `local.snmp.port` 選項分別指定的乙太網路介面和 UDP 連接埠上直接偵聽 SNMP 請求。若要以獨立模式執行，請為此選項指定 1 或 `TRUE` 值。以獨立模式執行不會干擾系統上執行的其他 SNMP 主代理程式或子代理程式。
local.snmp.listenaddr (INADDR_ANY)	以獨立模式執行時，偵聽 SNMP 請求所在的乙太網路介面之主機名稱或 IP 位址。預設會在所有可用的介面上進行偵聽。此對應到指定值 `INADDR_ANY`。指定與該介面相關的 IP 位址或主機名稱可選取特定的介面。此介面可能是實體介面或虛擬介面。當 `local.snmp.standalone` 設定為 0 或 `FALSE` 時，會忽略此選項。
local.snmp.cachettl (30)	快取的監視資料之存留時間 (TTL)，以秒為單位。此選項控制子代理程式以從 Messaging Server 取得的新資訊重新整理資料之前，會報告相同監視資料的時間長度。除了郵件迴圈資訊之外，快取的資料預設不得超過 30 秒。經由掃描 `.HELD` 檔案判定的迴圈資訊，僅會每 10 分鐘更新一次。這是因為此資源需要掃描所有磁碟上的郵件佇列。請注意，子代理程式不會持續更新其監視資料：僅會在接收 SNMP 請求及快取的資料過期 (亦即超過其 TTL) 時更新。如果 TTL 設定為 30 秒且僅每 5 分鐘提出 SNMP 請求，則每則 SNMP 請求會導致子代理程式從 Messaging Server 取得更新的資料。亦即，資料僅會每 5 分鐘從 Messaging Server 取得一次。另一方面，如果每 10 秒提出 SNMP 請求，則子代理程式會以 29 秒前快取的資料來回應部分請求；僅會每 30 秒輪詢 Messaging Server 一次。
local.snmp.servertimeout (5)	子代理程式會實際開啟每個服務的 TCP 連線並進行協定交換，以判定每個受監視的服務之作業狀態。此逾時值 (以秒為單位) 控制子代理程式等候協定交換中各步驟的回應之時間長度。預設會使用 5 秒的逾時值。
local.snmp.directoryscan (1)	使用此選項以控制子代理程式是否掃描磁碟上的郵件佇列，尋找 `.HELD` 郵件檔案及最舊的郵件檔案。此資訊對應 `mtaGroupLoopsDetected`、`mtaGroupOldestMessageStored` 和 `mtaGroupOldestMessageId` MIB 變數。當此選項的值為 1 或 `true` 時，則會視需要維護與更新此資訊的快取記憶體。具有上千封排入佇列的郵件之站台若是對這些特定的 MIB 變數不感興趣，應考慮將此選項值設定為 0 或 `false`。
local.snmp.enablecontextname (0)	這些子代理程式能將其 MIB 註冊在 SNMP 3 版的內容名稱下。完成時，這些 MIB 僅能由在其 SNMP 請求中指定內容名稱的 SNMP 3 版用戶端請求。使用內容名稱允許多個獨立的子代理程式在相同的 OID 樹狀結構下 (亦即在相同的 SNMP 主代理程式下) 註冊網路服務和 MTA MIB。如需進一步資訊，請參閱A.3.4 監視多個 Messaging Server 實例。若要使用 SNMP 3 版的內容名稱，請為此選項指定值 1 或 `true`。完成時，子代理程式預設會為其內容名稱使用 `service.defaultdomain` 選項的值。若要為內容名稱使用不同的值，請使用 `local.snmp.contextname` 選項。
local.snmp.contextname (service.defaultdomain)	以 `local.snmp.enablecontextname` 啟用 SNMP 3 版內容名稱的使用時，可能使用此選項明確設定其 MIB 的子代理程式所使用的內容名稱。為此選項提供的值是字串值，且必須適合用做 SNMP 3 版的內容名稱。當 `local.snmp.enablecontextname` 有 0 或 `false` 值時，會忽略此選項。

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

將您的 SNMP 用戶端指向這兩個 OID 並將其做為「公用」SNMP 社群進行存取。

如果您要將 MIB 的副本載入您的 SNMP 用戶端，則應在 msg-svr-base/lib/config-templates 目錄中的 rfc2788.mib 和 rfc2789.mib 檔案名稱下找出 MIB 的 ASCII 副本。如需有關將這些 MIB 載入您的 SNMP 用戶端軟體的指示，請參閱 SNMP 用戶端軟體說明文件。在這些 MIB 中使用的 SnmpAdminString 資料類型可能無法由某些較舊的 SNMP 用戶端識別。在這種情況下，請使用同一目錄中的等效檔案 rfc2248.mib 和 rfc2249.mib。

A.5 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 總數等) 將被重設為零。

每個網站均有不同的臨界值和重要的監視值。運轉正常的 SNMP 用戶端可讓您進行趨勢分析，並可在歷史趨勢發生突然偏差時發出警示。

A.5.1 applTable

applTable 提供伺服器資訊。它是一維表格，其中一列用於 MTA，其他每一列用於以下每台伺服器 (如果已啟用)：WebMail HTTP、IMAP、POP、SMTP 和 SMTP Submit。此表格提供版本資訊、正常執行時間、目前作業狀態 (up、down 和 congested)、目前連線數目、累計連線總數以及其他相關資料。

以下為 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 主代理程式後以百分之一秒為單位的計數。
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 的作業狀態僅具有 up 值或 down 值。儘管工作控制器有「congested」的概念，但 MTA 狀態中沒有此概念。
對於 HTTP、IMAP 和 POP 伺服器，applRejectedInboundAssociations MIB 變數表示登入嘗試失敗的次數，而不是內送連線嘗試被拒絕的次數。

A.5.1.1 applTable 用法

監視每個列出應用程式的伺服器狀態 (applOperStatus) 是監視每台伺服器的關鍵。

如果自 MTA 最後一次內送活動 (由 applLastInboundActivity 表示) 至今已有很長一段時間，則可能是由於出現故障，從而無法進行連線。如果 applOperStatus=2 (down)，則因為受監視的服務中斷。如果 applOperStatus=1 (up)，則可能因為其他地方出現了問題。

A.5.2 assocTable

此表提供進入 MTA 的網路連線資訊。它是二維表格，提供有關每個使用中網路連線的資訊。不提供其他伺服器的連線資訊。

以下為 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 表示 SMTP 協定透過 TCP 連接埠 25 通訊。
無法瞭解遠端 SMTP 用戶端是使用者代理程式 (UA) 還是其他 MTA。因此，子代理程式一律報告 peer-initiator；而從不報告 ua-initiator。
這是 SNMP TimeInterval，單位為百分之一秒。在此範例中，連線已開啟 4 秒鐘。

A.5.2.1 assocTable 用法

此表格用於診斷目前的問題。例如，如果您突然有 200,000 個內送連線，則此表格可讓您瞭解這些連線的來源。

A.5.3 mtaTable

這是一個一維表格，每一列均對應 applTable 中的每個 MTA。每列為 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 中的資料。

僅對轉換通道使用非零值。
計數目前儲存在 MTA 郵件佇列中的 .HELD 郵件檔案的數目。

A.5.3.1 mtaTable 用法

如果 mtaLoopsDetected 為非零值，則會出現迴圈郵件問題。找到並診斷 MTA 佇列中的 .HELD 檔案以解決該問題。

如果系統對轉換通道進行病毒掃描，並拒絕被感染的郵件，則 mtaSuccessfulConvertedMessages 除了提供其他轉換失敗的計數以外，還提供被感染郵件的計數。

A.5.4 mtaGroupTable

此二維表格提供 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 通道。
僅對轉換通道使用非零值。
計數目前儲存在此通道的郵件佇列中之 .HELD 郵件檔案的數目。

A.5.4.1 mtaGroupTable 用法

對 *Rejected* 和 *Failed* 的趨勢分析，可能有助於確定潛在的通道問題。

mtaGroupStoredVolume 對 mtaGroupStoredMessages 比率的突然增大意味著佇列附近正在退回大型垃圾郵件。

mtaGroupStoredMessages 的突然增大可能表示正在傳送未經請求的垃圾電子郵件，或該傳送由於某些原因而失敗。

如果 mtaGroupOldestMessageStored 的值大於無法遞送的郵件通知次數 (notices 通道關鍵字) 的值，則可能表示即使透過退回處理也無法處理該郵件。請注意，退回在每晚進行，因此您需要使用 mtaGroupOldestMessageStored > (最長存在時間 + 24 小時) 做為測試。

如果 mtaGroupLoopsDetected 大於 0，說明系統已偵測到郵件迴圈。

A.5.5 mtaGroupAssociationTable

這是三維表格，其項目是 assocTable 的索引。對於 applTable 中的每個 MTA，均有一個二維子表格。此二維子表格的每列分別用於相應 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 和此值將分別成為 applIndex 和 assocIndex 在 assocTable 中的索引值。或者，這表示 (忽略 applIndex) assocTable 的第一列說明由 tcp_local 通道控制的網路連線。

A.5.6 mtaGroupErrorTable

這是另一個三維表格，指定在嘗試遞送郵件時，每個 MTA 的每個通道遇到之臨時性錯誤和永久性錯誤計數。索引值為 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，分別表示嘗試遞送郵件時，此通道所遇到的臨時性錯誤和永久性錯誤的計數。

A.5.6.1 mtaGroupErrorTable 用法

錯誤計數的突然增大可能表示出現異常的遞送問題。例如，tcp_ 通道錯誤計數的突然增大可能表示出現 DNS 或網路問題。ims_ms 通道錯誤計數的突然增大可能表示郵件儲存出現傳送問題 (例如，分割區已滿、stored 問題等)。