前へ 目次 索引 DocHome 次へ |
iPlanet Messaging Server 5.2 管理者ガイド |
第 15 章 iPlanet Messaging Server をモニタする
多くの場合、適切に計画され設定されたサーバには、管理者による過度の介入は必要ありません。ただし、管理者は、サーバに問題の兆候がないかモニタする必要があります。この章では、iPlanet Messaging Server のモニタ機能について説明します。この章には、以下の節があります。
「毎日のモニタ作業」
トラブルシューティングの手順については、第 14 章「MTA のトラブルシューティング」 を参照してください。
毎日のモニタ作業
毎日行う必要のあるもっとも重要な作業は、ポストマスターメールのチェック、ログファイルのモニタ、およびstored ユーティリティの設定です。これらの作業について、以降で説明します。
ポストマスターメールをチェックする
Messaging Server には、ポストマスター電子メール用に設定されている定義済み管理メーリングリストがあります。このメーリングリストに含まれているユーザは、ポストマスター宛てに送信されたメールを自動的に受信します。ポストマスターメールの規則は RFC822 に定義されています。RFC822 では、すべての電子メールサイトでポストマスターという名前のユーザまたはメーリングリスト宛てに送信されたメールを受け取り、このアドレスに送信されたメールを実際のユーザに配信することを要求しています。postmaster@host.domain に送られるすべてのメッセージは、ポストマスターアカウントまたはメーリングリストに送られます。
通常、ユーザは、ポストマスターアドレス宛てに自分のメールサービスに関する電子メールを送信します。ポストマスターは、たとえば、ローカルユーザからはサーバ応答時間に関するメールを受信し、ほかのサーバ管理者からはサーバへのメール送信時に発生した問題に関するメールを受信します。ポストマスターメールは毎日チェックする必要があります。
また、ポストマスターアドレスに特定のエラーメッセージを送信するようにサーバを設定することもできます。たとえば、MTA がメッセージをルーティングまたは配信できないときは、ポストマスターアドレスに送信される電子メールによってそのことを知ることができます。また、ポストマスターに例外状態の警告 (ディスク容量の低下やサーバ応答の不良) を送ることもできます。
ログファイルをモニタおよび管理する
iPlanet Messaging Server は、サポートされている主なプロトコル (SMTP、IMAP、POP、HTTP) またはサービスごとに一連のログファイルを作成します。ログファイルは定期的にモニタする必要があり、サーバに問題がある場合は特に必要です。ログ記録はサーバのパフォーマンスに影響することがあります。より詳細なログ記録を指定するほど、一定期間にログファイルが多くのディスク容量を占有することになります。効果的に定義する必要がありますが、現実的なログローテーション、有効期間、サーバのバックアップポリシーなどを考慮する必要があります。サーバのログポリシーの定義の詳細は、第 13 章「ログ記録とログ解析」を参照してください。
stored ユーティリティを設定する
stored ユーティリティは、以下のような、サーバの自動モニタおよび管理を実行します。stored ユーティリティは、毎日深夜 0 時に、クリーンアップと有効期限による失効の操作を自動的に実行します。詳細は、「stored」を参照してください。
システムのパフォーマンスをモニタする
ここでは、特に iPlanet Messaging Server のモニタ機能について説明しますが、サーバがあるシステムもモニタする必要があります。適切に設定されたサーバでも、適切に調整されていないシステム上では正しく作動しないことがあります。また、サーバエラーの兆候は、ハードウェアに電子メールを処理するための十分な機能がないことを示している場合があります。この章では、システムパフォーマンスのモニタの詳細についてすべて説明しているわけではありません。これらの手順の多くはプラットフォーム固有のものであり、プラットフォーム固有のシステムのマニュアルを参照することが必要になる場合もあります。パフォーマンスをモニタする手順を以下に示します。
「終端間メッセージ配信時間をモニタする」
終端間メッセージ配信時間をモニタする
電子メールは時間どおりに配信する必要があります。これがサービス契約の要件になっていることもあります。また、メールをできるだけ速く配信することは良いポリシーでもあります。終端間の時間が遅いことは、多くの事柄を示している可能性があります。たとえば、サーバが正しく作動していない、1 日の特定の時間にメッセージが処理不能になる、既存のハードウェアリソースの容量を超えている、などです。
終端間メッセージ配信時間の不良の兆候
メールの配信に、通常よりも長い時間がかかります。
終端間メッセージ配信時間をモニタするには
メッセージを送信および受信する機能を使用します。サーバのホップ間のヘッダー時間、および始点と取り出しの時間を比較します。
ディスク容量をモニタする
ディスク容量の不足は、メールサーバの問題と障害を発生させる、もっとも一般的な原因です。MTA キューまたはメッセージストアに書き込む領域がないと、メールサーバでエラーが発生します。さらに、ログファイルをモニタおよびクリーンアップしないと、ログファイルが制御できないほど大きくなり、ディスク容量を使い果たすことがあります。stored のクリーンアップ機能が失敗し、削除されたメッセージがメッセージストアから消去されていないと、ディスク容量が急激に不足することがあります。MTA メッセージキューが大きくなりすぎたり、メッセージストアが利用可能なディスク容量より大きくなったり、モニタしていないログファイルが制御できないほど大きくなったりすることも、ディスク容量の低下を招きます (ログファイルには LDAP、MTA、および Message Access など、多数のものがあり、それらの各ログファイルは別のディスクに保存することができます)。
ディスク容量に関する問題の兆候
容量の低下によって発生する兆候は、ディスクやパーティションによって異なります。MTA キューがオーバーフローして SMTP 接続を拒否したり、メッセージが ims_master キューに残されたままでメッセージストアに配信されなくなったり、ログファイルがオーバーフローすることがあります。
ディスク容量をモニタするには
システムの構成に従って、さまざまなディスクやパーティションをモニタする必要があります。たとえば、MTA キューが 1 つのディスクやパーティション上にあり、メッセージストアが別の場所にあり、ログファイルがさらに別の場所にあるとします。この場合、それらの容量のそれぞれをモニタする必要があり、その容量をモニタする方法は異なることがあります。
メッセージストアをモニタする
メッセージストアのディスク容量は、75% を超えないようにすることをお勧めします。メッセージストアのディスク使用量をモニタするには、configutil ユーティリティを使用して以下の警告属性を設定します。これらのパラメータを設定することによって、システムがディスク容量をモニタする頻度と、どのような状況で警告を送信するかを指定することができます。たとえば、システムに 600 秒ごとにディスク容量をモニタさせる場合は、以下のコマンドを指定します。
configutil -o alarm.diskavail.msgalarmstatinterval -v 600
利用可能なディスク容量が 20% より低くなったとき常に警告を受け取る場合は、以下のコマンドを指定します。
configutil -o alarm.diskavail.msgalarmthreshold -v 20
これらのパラメータの詳細については、表 15-1を参照してください。
MTA キューとログ領域をモニタする
MTA キューのディスクおよびログ領域のディスク使用量をモニタする必要があります。
CPU 使用状況をモニタする
CPU 使用状況が高い場合は、使用状況のレベルに対して CPU 容量が不足しているか、または適切なサイクルより多くの CPU サイクルを使用しているプロセスがあることを示しています。
CPU 使用状況に関する問題の兆候
システムの応答が悪く、 ユーザのログインに時間がかかり、 配信速度が遅くなります。
CPU 使用状況をモニタするには
CPU 使用状況のモニタは、プラットフォーム固有のタスクです。関連するプラットフォームのマニュアルを参照してください。
「メッセージキューのサイズをモニタする」
メッセージキューのサイズをモニタする
メッセージキューが過度に大きくなる場合は、メッセージが配信されていない、配信が遅延されている、あるいは入るのが速すぎてシステムがメッセージを配信できないことを示していることがあります。これは、膨大なメッセージがシステムに送られるサービス拒否攻撃に遭っている、ジョブコントローラが実行されていないなど、さまざまな原因によって発生します。メッセージキューの詳細は、「チャネルメッセージキュー」, 「メッセージがキューから取り出されない」および 「MTA メッセージが配信されない」を参照してください。
メッセージキューのサイズをモニタするには
メッセージキューをモニタする最良の方法は、imsimta qm を使用することです。「imsimta qm counters」を参照してください。キューディレクトリ (/ServeRoot/msg-instance/imta/queue/) 内のファイルの数もモニタすることができます。ファイルの数はサイト固有であり、「多すぎる」ものを見つけるための基準を作る必要があります。これは、キューファイルのサイズを 2 週間以上記録して、おおよその平均をとることによって行います。
配信エラーの頻度をモニタする
配信エラーは、外部サイトへのメッセージの配信試行のエラーです。配信エラーの頻度の大幅な増加は、DNS サーバの故障や、接続への応答時のリモートサーバのタイムアウトなど、ネットワークに関する何らかの問題の兆候です。
配信エラーの頻度に関する問題の兆候
表面的な問題の兆候はありません。多数の Q レコードは、mail.log_current に現れます。
配信エラーの頻度をモニタするには
配信エラーは、ログエントリコード Q とともに MTA ログに記録されます。msg-instance/log/imta/mail.log_current ファイル内の Q レコードを確認します。
受信 SMTP 接続をモニタするには
指定した IP アドレスからの受信用 SMTP 接続の数が異常に増加した場合は、以下の状況を示しています。
外部ユーザによるメールのリレー - ログエントリレコード J (拒否されたリレー) を含むレコードの msg-instance/log/imta/mail.log_current を確認します。リモート IP アドレスのログを有効にするには、option.dat ファイルに以下の行を追加します。
サービス拒否攻撃 - SMTP サーバに接続しているユーザとその人数を調べるには、netstat コマンドを実行し、SMTP ポート (デフォルトは 25) の接続を確認します。以下に例を示します。
- log_connection=1
- この機能を有効にすると、わずかながらパフォーマンスが低下します。
- 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 秒 (1 日) です。同様に、MAX_LIFE_CONNS は、サーバプロセスがその有効期間中に処理できる接続の最大数を指定します。特定の SMTP サーバが長時間稼働している場合は、調査することもできます。
ディスパッチャおよびジョブコントローラのプロセスをモニタする
MTA が機能するためには、ディスパッチャおよびジョブコントローラプロセスが動作している必要があります。種類ごとに 1 つのプロセスが必要です。
ディスパッチャおよびジョブコントローラのプロセスダウンの兆候
ディスパッチャがダウンしていたり十分なリソースがない場合、SMTP 接続は拒否されます。ジョブコントローラがダウンしている場合、キューのサイズが大きくなります。
ディスパッチャおよびジョブコントローラのプロセスをモニタするには
dispatcher および job_controller というプロセスが存在しているかどうかチェックします。「ジョブコントローラとディスパッチャが実行中であることをチェックする」を参照してください。
メッセージアクセスをモニタする
この節には、以下の項目があります。
「imapd、popd、および httpd をモニタする」
imapd、popd、および httpd をモニタする
これらのプロセスによって、IMAP、POP、および Web メールサービスにアクセスします。これらのいずれかが実行されていないか応答がない場合、サービスは正しく機能しません。サービスが実行されていても過負荷の場合は、モニタすることでそれを検出し、より適切に設定し直すことができます。
imapd、popd、および httpd に関する問題の兆候
接続が拒否されたり、システムが遅すぎて接続できません。たとえば、IMAP が実行されていないときに IMAP に直接接続しようとすると、以下のようなメッセージが表示されます。telnet 0 143
Trying 0.0.0.0...
telnet: Unable to connect to remote host: Connection refusedクライアントと接続しようとすると、以下のようなメッセージが表示されます。
netscape is unable to connect to the server at the location you have specified. The server may be down or busy.
SNMP によってモニタすることができます。
ログファイルをチェックします。
- SNMP を設定している場合は、これらのプロセスをモニタすることをお勧めします。付録 A「SNMP サポート」を参照してください。サーバ情報は、Network Services Monitoring MIB にあります。
counterutil を使ってチェックできます。「counterutil」および『iPlanet Messaging Server リファレンスマニュアル』を参照してください。
- msg-instance/log/service ディレクトリを確認します。このディレクトリで service を http、IMAP、または POP にすることができます。このディレクトリで、ログファイルの数を確認します。1 つは service (imap、pop、http) というファイル名です。ほかのファイル名には、サービスの名前、シーケンス番号、およびサービス名に連結された日付が使われます。たとえば、以下のようになります。
- imap imap.29.1010221593 imap.31.1010394412 imap.33.1010567224
- サービス名だけを含むファイルは、最新のログです。それ以外のファイルは、シーケンス番号 (ここでは 29、31、33) 順に並べられ、シーケンス番号が一番大きいファイルが次に新しいファイルです (第 13 章「ログ記録とログ解析」を参照)。
- サーバが停止した場合は、以下のように表示されることがあります。
- [05/Jan/2002:08:36:38 -0800] gotmail-a imapd[10275]: General Warning: iPlanet Messaging Server IMAP4 5.2 (built Dec 9 2001) shutting down
プラットフォーム固有のコマンドを実行して、imapd、popd、および httpd プロセスが実行中かどうかを確認します。たとえば、Solaris では、ps コマンドを使用し、imapd、popd、および mshttpd を検索することができます。Windows NT では、タスクマネージャ ウィンドウまたはコマンドラインを使用することができます。
「推奨される stored パラメータ」に記載されているサーバ応答設定パラメータを設定することによって、指定したサーバのパフォーマンスしきい値に対する警告を設定することができます。
stored をモニタする
stored は、存続期間決定ポリシーを実行したり、ディスクに保存されているメッセージを消去して、メッセージデータベースのデッドロック操作やトランザクション操作などの、さまざまな重要なタスクを実行します。stored が実行を停止すると、最終的には Messaging Server に問題が発生します。start-msg が実行されているときに stored が起動していないと、ほかのプロセスも起動しません。stored の詳細は、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。
stored に関する問題の兆候
表面的な問題の兆候はありません。
stored プロセスが実行中かどうかをチェックします。stored は、pidfile.store という、msg-instance/config 内の pid ファイルを作成し、更新します。この pid ファイルは、復元中の init 状態と準備中の ready 状態を示します。たとえば、以下のようになります。
msg-instance/store/mailboxlist 内に作成されたログファイルをチェックします。すべてのログファイルが直接 stored の問題によって作成されるわけではありません。ログファイルは、imapd が壊れている場合やデータベースに問題がある場合にも作成されることがあります。
- 231: cat pidfile.store
28250
ready
- 1 行目の数字は stored のプロセス ID です。
- 232: ps -eaf | grep stored
mailsrv 28250 1 0 Jan 05 ? 8:44 /usr/iplanet/server5/bin/msg/admin/bin/stored -d
msg-instance/config にある以下のファイルのタイムスタンプをチェックします。
デフォルトのログファイル msg-instance/log/default/default 内の stored メッセージをチェックします。
- stored.ckp - チェックポイントで試行が行われたときに押される。1 分ごとにタイムスタンプが付けられる
stored.lcu - データベースログのクリーンアップごとに押される。5 分ごとにタイムスタンプが付けられる
stored.per - ユーザ単位のデータベース書き込み時に押される。60 分ごとにタイムスタンプが付けられる
LDAP Directory Server をモニタする
この節には、以下の項目があります。
「slapd をモニタする」
slapd をモニタする
LDAP ディレクトリサーバ (slapd) は、メッセージングシステムのディレクトリ情報を提供します。slapd がダウンしていると、システムは正しく作動しません。slapd 応答時間が遅すぎると、ログイン速度、および LDAP 検索を必要とするほかのトランザクションに影響を及ぼします。
ns-slapd プロセスが実行中かどうかをチェックします。
slapd-instance/logs/ にある slapd ログファイルの access および errors をチェックします。
メッセージストアをモニタする
メッセージはデータベースに保存されています。ディスク上のユーザの分散、メールボックスのサイズ、ディスクの要件は、ストアのパフォーマンスに影響します。この節には、以下の項目があります。
「メッセージストアデータベースのロック状態をモニタする」
メッセージストアデータベースのロック状態をモニタする
データベースロックの状態は、さまざまなサーバプロセスで保持されます。これらのデータベースロックは、メッセージストアのパフォーマンスに影響することがあります。デッドロックの場合、メッセージが適切な速度でストアに挿入されないため、結果として ims-ms チャネルキューが大きくなります。キューをバックアップするのにはいくつかの正当な理由があります。従って、キューの長さの履歴をとっておくと、問題を診断するのに便利です。
メッセージストアのデータベースロックに関する問題の兆候
多数のトランザクションが蓄積され、解決されません。
メッセージストアのデータベースロックをモニタするには
counterutil -o db_lock コマンドを使用します。
mboxutil ディレクトリ内のデータベースログファイルの数をモニタする
データベースログファイルは、sleepycat トランザクションのチェックポイントログファイル (msg-instance/store/mboxlist) を指します。作成されるログファイルは、データベースのチェックポイントが発生しないという問題の兆候です。また、stored の問題による場合もあります。
データベースログファイルの問題の兆候
通常は、2 つまたは 3 つのログファイルがあります。ログファイルがそれ以上ある場合は、潜在的に重大な問題があることを示しています。メッセージストアはメッセージと制限容量のためにいくつかのデータベースを使用します。それらに問題があるとすべてのメールサーバに問題が発生することがあります。
データベースログファイルをモニタするには
msg-instance/store/mboxlist ディレクトリを見て、ファイルが 2 つか 3 つしかないことを確認します。
モニタ用のユーティリティとツール
モニタには、以下のツールを利用できます。
「stored」
stored
stored ユーティリティはサーバ上で保守タスクを実行しますが、モニタも実行できます。指定されている場合は、サーバの状態、ディスク容量、サービスへの応答時間を定期的にチェックでき、ポストマスターへの電子メールメッセージの形式で警告を発することができます (510を参照)。警告は、電子メールメッセージの形式で、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.comServer instance: /usr/iplanet/server5/msg-europa
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: 1stored でディスクおよびサーバのパフォーマンスをモニタする頻度と、どのような状況下で警告を送るかを指定することができます。これは、configutil コマンドを使用して警告パラメータを設定することによって行います。有用な stored パラメータとそのデフォルト設定を表 15-1 に示します。
表 15-1    推奨される stored パラメータ
パラメータ
説明 (デフォルト)
(-1) 利用可能なディスク容量がしきい値 (-1) より低いか、しきい値 (1) より高いときに警告を発行するかどうかを指定する
(1) サーバ応答時間がしきい値より大きい (1) か、しきい値より小さい (-1) ときに、警告を発行するかどうかを指定する
counterutil
このユーティリティは、さまざまなシステムカウンタから取得した統計情報を提供します。以下は、現在利用できるカウンタオブジェクトのリストです。counterutil -l
entry = alarm
entry = diskusage
entry = serverresponse
entry = db_lock
entry = db_log
entry = db_mpool
entry = db_txn
entry = popstat
entry = imapstat
entry = httpstat
entry = cgimsgそれぞれのエントリはカウンタオブジェクトを表し、このオブジェクトに使用できるさまざまなカウントを提供します。 この節では、alarm、diskusage、serverresponse、db_lock、popstat、imapstat、および httpstat カウンタオブジェクトについてのみ説明します。 counterutil コマンドの使用法の詳細は、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。
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 -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 が送信する警告を指します。警告カウンタは以下の統計を提供します。
表 15-2    counterutil alarm 統計
接尾辞
説明
counterutil を使用した IMAP、POP、および HTTP 接続の統計
現在の IMAP、POP、および HTTP 接続の数、ログインに失敗した回数、開始時間からの接続合計などの情報を得るために、コマンド counterutil -o CounterObject -i 5 -n 10 を使用することができます。ここで、CounterObject は、カウンタオブジェクト popstat、imapstat、または httpstat を表します。imapstat 接尾辞の意味を 表 15-3 に示します。popstat および httpstat オブジェクトは、同じ情報を同じ形式と構造で提供します。
表 15-3    counterutil imapstat 統計
接尾辞
説明
counterutil を使用したディスク使用状況の統計
コマンド counterutil -o diskusage は以下の情報を生成します。
表 15-4    counterutil diskstat 統計
接尾辞
説明
サーバ応答の統計
コマンド counterutil -o serverresponse は、以下の情報を生成します。この情報は、サーバが稼働中かどうかと、サーバの応答速度をチェックする際に便利です。
表 15-5    counterutil serverresponse 統計
接尾辞
説明
ログファイル
Messaging Server は、SMTP、IMAP、POP、および HTTP のイベント記録をログに保存します。Messaging Server ログファイルの作成と管理用のポリシーはカスタマイズ可能です。ログ記録はサーバのパフォーマンスに影響を与えることがあるため、サーバに負担がかからないよう、非常に慎重に検討する必要があります。詳細については、第 13 章「ログ記録とログ解析」を参照してください。
imsimta counters
MTA は、アクティブなチャネルのそれぞれに対して、Mail Monitoring MIB (RFC 1566) に基づいてメッセージトラフィックのカウンタを累積します。チャネルカウンタは、使用している電子メールシステムの傾向や調子を示すためのものです。チャネルカウンタは、メッセージトラフィックを正確に計算するためのものではありません。正確な計算については、第 13 章「ログ記録とログ解析」に記載されている MTA ログを参照してください。MTA チャネルカウンタは、利用可能な最軽量メカニズムを使用して実装されるため、実際の操作での影響はわずかです。チャネルカウンタはさらに処理を行おうとはしません。つまり、セクションのマッピングの試行が失敗した場合やセクション内のロックの 1 つをほぼ即座に取得できない場合は、情報が記録されず、システムが停止している場合は、メモリ内セクションに含まれている情報は永久に失われます。
imsimta counters -show コマンドによって MTA チャネルメッセージの統計が得られます (以下を参照)。最小値が何も示されないときは、これらのカウンタを調べる必要があります。チャネルによっては、実際の最小値は負の値です。負の値は、カウンタがゼロになった (たとえば、カウンタのクラスタレベルのデータベースが作成された) 時点でチャネルのキューに入れられたメッセージがあることを示します。これらのメッセージがキューから取り出されるとき、関連するチャネルのカウンタは減少し、それによって最小値が負になります。このようなカウンタの場合、正確な「絶対」値は、初期化以降にカウンタが保持していた最小値を差し引いた現在の値です。
1) Received は、tcp_local という名前のチャネルのキューに入れられたメッセージの数です。つまり、ほかのチャネルによって directory チャネルのキューに入れられたメッセージ (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 は、最初の試行で配信されたメッセージがキューに入っていた時間の平均時間です。
送信されたメッセージの数が配信されたメッセージの数より大きくなっていることに注意してください。この原因のほとんどは、メッセージがチャネルのキューから取り出される (配信される) たびに少なくとも 1 つ (場合によっては複数) の新しいメッセージがキューに入れられる (送信される) ためです。たとえば、メッセージが異なるチャネル経由で 2 人の受取人に届けられる場合は、2 つのメッセージがキューに入れられる必要があります。すなわち、メッセージがバウンスされる場合は、差出人にコピーが返送され、もう 1 つのコピーがポストマスターに送信されることがあります。通常は 2 件の送信になります (両方とも同じチャネル経由で届けられる場合を除く)。
通常は、Submitted と Delivered の間の接続はチャネルのタイプによって異なります。たとえば、変換チャネルでは、メッセージはほかの任意のチャネルのキューに入れられ、そのあと変換チャネルがそのメッセージを処理し、それを 3 番目のチャネルのキューに入れ、元のチャネルのキューから取り出されたものとしてメッセージをマークします。個々のメッセージのパスは以下のとおりです。
ほかの場所 -> 変換チャネル E レコード Received
変換チャネル -> ほかの場所 E レコード Submitted
変換チャネル D レコード Deliveredただし、tcp_local のように「通過」しなくても 2 つの部分 (スレーブとマスター) があるチャネルの場合は、Submitted と Delivered の間の接続はありません。Submitted カウンタが tcp_local チャネルの SMTP サーバ部分を処理する必要があるのに対し、Delivered は tcp_local チャネルの SMTP クライアント部分を処理する必要があります。これらは 2 つのまったく別のプログラムであり、それぞれから送られるメッセージはまったく別のものになることがあります。
tcp_local -> ほかの場所 E レコード Submitted
SMTP クライアント経由でほかの SMTP ホストに送信されるメッセージ
ほかの場所 -> tcp_local E レコード Received
tcp_local D レコード Deliveredチャネルのキューからの取り出し (配信) により、少なくとも 1 つの新しいメッセージがキューに入れられ (送信され) ます。複数になることもあります。たとえば、メッセージが異なるチャネル経由で 2 人の受取人に届けられる場合は、2 つのメッセージがキューに入れられる必要があります。すなわち、メッセージがバウンスされる場合は、差出人にコピーが返送され、もう 1 つのコピーがポストマスターに送信されることがあります。通常は同じチャネル経由で届けられます。
UNIX および NT での実装
パフォーマンス上の理由から、MTA はメモリ内にチャネルカウンタのキャッシュを保持します。これには、UNIX では共有メモリセクションを使用し、NT では共有ファイルマッピングオブジェクトを使用します。ノード上のプロセスがメッセージをキューに入れたりキューから取り出すときに、このプロセスがそのメモリ内キャッシュ内のカウンタを更新します。チャネルが作動しているときにメモリ内セクションが存在しない場合、メモリ内セクションは自動的に作成されます (imta start コマンドも、存在しない場合はメモリ内キャッシュを作成します)。imta counters -clear コマンドまたは imta qm コマンドの counters clear は、カウンタをゼロにリセットするために使用することもあります。
imsimta qm counters
imsimta qm counters ユーティリティは、MTA チャネルのキューメッセージカウンタを表示します。 このユーティリティは、root または mailsrv として実行する必要があります。出力されるフィールドは 「imsimta counters」に記載されているものと同じです。使用法の詳細は、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。Channel Messages Recipients Blocks
---------------------- ---------- ---------- ----------
autoreply
Received 13077 13859 264616
Stored 92 91 -362
Delivered 12985 13768 264978
Submitted 2594 2594 3641
...4370 messages processed so far today
Your license permits an unlimited number of messages per day.
SNMP を使用した MTA のモニタ
iPlanet Messaging Server では、SNMP (Simple Network Management Protocol) を利用したシステムモニタ機能がサポートされています。Sun Net Manager や HP OpenView などの SNMP クライアント (ネットワークマネージャとも呼ばれる) を使って、iPlanet Messaging Server の特定の部分をモニタすることができます。ただし、SNMP クライアントは本製品に付属していません。詳細については付録 A「SNMP サポート」を参照してください。
メールボックスの制限容量チェックのための mboxutil
mboxutil ユーティリティを使用して、メールボックスの制限容量の使用状況と制限をモニタすることができます。mboxutil ユーティリティは、定義されている制限容量と制限をリストし、制限容量に関する情報を出力する、レポートを生成します。制限容量と使用状況はキロバイトでレポートされます。たとえば、以下のコマンドはすべてのユーザの制限容量情報を一覧表示します。
以下の例では、ユーザ sorook の制限容量の使用状況を示します。
前へ 目次 索引 DocHome 次へ
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
最新更新日 2002 年 2 月 27 日