前へ     目次     索引     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 ユーティリティを使用して以下の警告属性を設定します。

  • alarm.diskavail.msgalarmstatinterval

  • alarm.diskavail.msgalarmthreshold

  • alarm.diskavail.msgalarmwarninginterval

これらのパラメータを設定することによって、システムがディスク容量をモニタする頻度と、どのような状況で警告を送信するかを指定することができます。たとえば、システムに 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 をモニタする



この節には、以下の項目があります。


メッセージキューのサイズをモニタする

メッセージキューが過度に大きくなる場合は、メッセージが配信されていない、配信が遅延されている、あるいは入るのが速すぎてシステムがメッセージを配信できないことを示していることがあります。これは、膨大なメッセージがシステムに送られるサービス拒否攻撃に遭っている、ジョブコントローラが実行されていないなど、さまざまな原因によって発生します。

メッセージキューの詳細は、「チャネルメッセージキュー」, 「メッセージがキューから取り出されない」および 「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 接続の数が異常に増加した場合は、以下の状況を示しています。

  • 外部ユーザがメールをリレーしようとしている

  • 外部ユーザがサービス拒否攻撃を行おうとしている


認証されていない SMTP 接続の兆候

  • 外部ユーザによるメールのリレー - 表面的には問題発生の兆候はない

  • サービス拒否攻撃 - 外部のメッセージ要求により SMTP サーバを過負荷にする試行


受信用 SMTP 接続をモニタするには

  • 外部ユーザによるメールのリレー - ログエントリレコード J (拒否されたリレー) を含むレコードの msg-instance/log/imta/mail.log_current を確認します。リモート 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 接続の適切な数とその状態 (ESTABLISHEDCLOSE_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 をモニタする

これらのプロセスによって、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.


imapd、popd、および httpd をモニタするには

  • SNMP によってモニタすることができます。

    SNMP を設定している場合は、これらのプロセスをモニタすることをお勧めします。付録 A「SNMP サポート」を参照してください。サーバ情報は、Network Services Monitoring MIB にあります。

  • ログファイルをチェックします。

    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

  • counterutil を使ってチェックできます。「counterutil」および『iPlanet Messaging Server リファレンスマニュアル』を参照してください。

  • プラットフォーム固有のコマンドを実行して、imapd、popd、および httpd プロセスが実行中かどうかを確認します。たとえば、Solaris では、ps コマンドを使用し、imapdpopd、および mshttpd を検索することができます。Windows NT では、タスクマネージャ ウィンドウまたはコマンドラインを使用することができます。

  • 「推奨される stored パラメータ」に記載されているサーバ応答設定パラメータを設定することによって、指定したサーバのパフォーマンスしきい値に対する警告を設定することができます。


stored をモニタする

stored は、存続期間決定ポリシーを実行したり、ディスクに保存されているメッセージを消去して、メッセージデータベースのデッドロック操作やトランザクション操作などの、さまざまな重要なタスクを実行します。stored が実行を停止すると、最終的には Messaging Server に問題が発生します。start-msg が実行されているときに stored が起動していないと、ほかのプロセスも起動しません。stored の詳細は、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。


stored に関する問題の兆候

表面的な問題の兆候はありません。


stored をモニタするには

  • stored プロセスが実行中かどうかをチェックします。stored は、pidfile.store という、msg-instance/config 内の pid ファイルを作成し、更新します。この pid ファイルは、復元中の init 状態と準備中の ready 状態を示します。たとえば、以下のようになります。

    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/store/mailboxlist 内に作成されたログファイルをチェックします。すべてのログファイルが直接 stored の問題によって作成されるわけではありません。ログファイルは、imapd が壊れている場合やデータベースに問題がある場合にも作成されることがあります。

  • msg-instance/config にある以下のファイルのタイムスタンプをチェックします。

    stored.ckp - チェックポイントで試行が行われたときに押される。1 分ごとにタイムスタンプが付けられる
    stored.lcu - データベースログのクリーンアップごとに押される。5 分ごとにタイムスタンプが付けられる
    stored.per - ユーザ単位のデータベース書き込み時に押される。60 分ごとにタイムスタンプが付けられる

  • デフォルトのログファイル msg-instance/log/default/default 内の stored メッセージをチェックします。



LDAP Directory Server をモニタする

この節には、以下の項目があります。


slapd をモニタする

LDAP ディレクトリサーバ (slapd) は、メッセージングシステムのディレクトリ情報を提供します。slapd がダウンしていると、システムは正しく作動しません。slapd 応答時間が遅すぎると、ログイン速度、および LDAP 検索を必要とするほかのトランザクションに影響を及ぼします。


slapd に関する問題の兆候

  • クライアント POP、IMAP、または Web メール認証が失敗するか、予定よりも時間がかかる

  • MTA が正しく動作しない


slapd をモニタするには

  • ns-slapd プロセスが実行中かどうかをチェックします。

  • slapd-instance/logs/ にある slapd ログファイルの access および errors をチェックします。

  • ユーザ検索時の ns-slapd 応答時間をチェックします。

  • Admin Console を表示して slapd をモニタします。



メッセージストアをモニタする

メッセージはデータベースに保存されています。ディスク上のユーザの分散、メールボックスのサイズ、ディスクの要件は、ストアのパフォーマンスに影響します。この節には、以下の項目があります。


メッセージストアデータベースのロック状態をモニタする

データベースロックの状態は、さまざまなサーバプロセスで保持されます。これらのデータベースロックは、メッセージストアのパフォーマンスに影響することがあります。デッドロックの場合、メッセージが適切な速度でストアに挿入されないため、結果として ims-ms チャネルキューが大きくなります。キューをバックアップするのにはいくつかの正当な理由があります。従って、キューの長さの履歴をとっておくと、問題を診断するのに便利です。


メッセージストアのデータベースロックに関する問題の兆候

多数のトランザクションが蓄積され、解決されません。


メッセージストアのデータベースロックをモニタするには

counterutil -o db_lock コマンドを使用します。


mboxutil ディレクトリ内のデータベースログファイルの数をモニタする

データベースログファイルは、sleepycat トランザクションのチェックポイントログファイル (msg-instance/store/mboxlist) を指します。作成されるログファイルは、データベースのチェックポイントが発生しないという問題の兆候です。また、stored の問題による場合もあります。


データベースログファイルの問題の兆候

通常は、2 つまたは 3 つのログファイルがあります。ログファイルがそれ以上ある場合は、潜在的に重大な問題があることを示しています。メッセージストアはメッセージと制限容量のためにいくつかのデータベースを使用します。それらに問題があるとすべてのメールサーバに問題が発生することがあります。


データベースログファイルをモニタするには

msg-instance/store/mboxlist ディレクトリを見て、ファイルが 2 つか 3 つしかないことを確認します。



モニタ用のユーティリティとツール



モニタには、以下のツールを利用できます。


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

Server 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: 1

stored でディスクおよびサーバのパフォーマンスをモニタする頻度と、どのような状況下で警告を送るかを指定することができます。これは、configutil コマンドを使用して警告パラメータを設定することによって行います。有用な stored パラメータとそのデフォルト設定を表 15-1 に示します。


表 15-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

このユーティリティは、さまざまなシステムカウンタから取得した統計情報を提供します。以下は、現在利用できるカウンタオブジェクトのリストです。

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 -o CounterObject -i 5 -n 10

ここで、

-o CounterObject は、カウンタオブジェクト alarmdiskusageserverresponsedb_lockpopstatimapstat、および 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 を使用した警告統計

これらの警告統計は、stored が送信する警告を指します。警告カウンタは以下の統計を提供します。


表 15-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 は、カウンタオブジェクト popstatimapstat、または httpstat を表します。imapstat 接尾辞の意味を 表 15-3 に示します。popstat および httpstat オブジェクトは、同じ情報を同じ形式と構造で提供します。

表 15-3    counterutil imapstat 統計 

接尾辞

説明

currentStartTime  

現在の IMAP サーバプロセスの開始時間  

lastConnectionTime  

最後に新しいクライアントが受け入れられた時間  

maxConnections  

IMAP サーバが処理した同時接続の最大数  

numConnections  

現在の IMAP サーバが処理した接続の総数  

numCurrentConnections  

アクティブな接続の現在の数  

numFailedConnections  

現在の IMAP サーバが処理した失敗した接続の数  

numFailedLogins  

現在の IMAP サーバが処理した失敗したログインの数  

numGoodLogins  

現在の IMAP サーバが処理した成功したログインの数  


counterutil を使用したディスク使用状況の統計

コマンド counterutil -o diskusage は以下の情報を生成します。


表 15-4    counterutil diskstat 統計

接尾辞

説明

diskusage.availSpace  

ディスクパーティションで利用できる合計容量  

diskusage.lastStatTime  

最後に統計がとられた時間  

diskusage.mailPartitionPath  

メールパーティションのパス  

diskusage.percentAvail  

利用できるディスクパーティション容量の割合  

diskusage.totalSpace  

ディスクパーティションの合計容量  


サーバ応答の統計

コマンド counterutil -o serverresponse は、以下の情報を生成します。この情報は、サーバが稼働中かどうかと、サーバの応答速度をチェックする際に便利です。


表 15-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 ログファイルの作成と管理用のポリシーはカスタマイズ可能です。

ログ記録はサーバのパフォーマンスに影響を与えることがあるため、サーバに負担がかからないよう、非常に慎重に検討する必要があります。詳細については、第 13 章「ログ記録とログ解析」を参照してください。


imsimta counters

MTA は、アクティブなチャネルのそれぞれに対して、Mail Monitoring MIB (RFC 1566) に基づいてメッセージトラフィックのカウンタを累積します。チャネルカウンタは、使用している電子メールシステムの傾向や調子を示すためのものです。チャネルカウンタは、メッセージトラフィックを正確に計算するためのものではありません。正確な計算については、第 13 章「ログ記録とログ解析」に記載されている MTA ログを参照してください。

MTA チャネルカウンタは、利用可能な最軽量メカニズムを使用して実装されるため、実際の操作での影響はわずかです。チャネルカウンタはさらに処理を行おうとはしません。つまり、セクションのマッピングの試行が失敗した場合やセクション内のロックの 1 つをほぼ即座に取得できない場合は、情報が記録されず、システムが停止している場合は、メモリ内セクションに含まれている情報は永久に失われます。

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 という名前のチャネルのキューに入れられたメッセージの数です。つまり、ほかのチャネルによって 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 件の送信になります (両方とも同じチャネル経由で届けられる場合を除く)。

通常は、SubmittedDelivered の間の接続はチャネルのタイプによって異なります。たとえば、変換チャネルでは、メッセージはほかの任意のチャネルのキューに入れられ、そのあと変換チャネルがそのメッセージを処理し、それを 3 番目のチャネルのキューに入れ、元のチャネルのキューから取り出されたものとしてメッセージをマークします。個々のメッセージのパスは以下のとおりです。

ほかの場所 -> 変換チャネル   E レコード   Received
変換チャネル -> ほかの場所   E レコード   Submitted
変換チャネル                 D レコード   Delivered

ただし、tcp_local のように「通過」しなくても 2 つの部分 (スレーブとマスター) があるチャネルの場合は、SubmittedDelivered の間の接続はありません。Submitted カウンタが tcp_local チャネルの SMTP サーバ部分を処理する必要があるのに対し、Deliveredtcp_local チャネルの SMTP クライアント部分を処理する必要があります。これらは 2 つのまったく別のプログラムであり、それぞれから送られるメッセージはまったく別のものになることがあります。

SMTP サーバ に送信されるメッセージ

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 リファレンスマニュアル』を参照してください。

例 1 :

imsimta qm counters show

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

例 2 :

imsimta qm counters today

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 ユーティリティは、定義されている制限容量と制限をリストし、制限容量に関する情報を出力する、レポートを生成します。制限容量と使用状況はキロバイトでレポートされます。

たとえば、以下のコマンドはすべてのユーザの制限容量情報を一覧表示します。

% mboxutil -a
-------------------------------------------------------------------------
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            ajonkish
no quota         5                  no quota      2               andrewt
no quota         355518             no quota      2500            aniksri
...


以下の例では、ユーザ sorook の制限容量の使用状況を示します。

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

no quota       1487                no quota      305              sorook



前へ     目次     索引     DocHome     次へ     
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

最新更新日 2002 年 2 月 27 日