ネットワークを安定して運用するためには，ホストや機器類の運用状況を日常的に監視し，トラブルが発生しそうな兆候をとらえたら即座に対処する，という体制がかかせません。この節では複数のホストの運用状況を同時に監視する場合に便利な設定を紹介します。

ホストの時刻を合わせる

ネットワークを管理する際には，正確な時刻情報が重要となることが多々あります。
先述のcronにしてもホストの時計を元に稼動しますし，Kerberosなど時刻情報を認証に用いるものもあります。複数のホストがそれぞれ勝手な時間を刻んでいては混乱の元になることは想像に難くないでしょう。ところが現在のPCに内蔵されている時計はあまり精密なものではありません。放っておくとひと月で1分以上狂ってしまうこともしばしばあります。

複数のホストの時刻を正確に合わせるためには，RFC1305で規定されるNTP(Network Time Protocol)を用いるのが一般的な方法です。NTPは，時刻情報を取得する際に通信経路で発生する遅延を測定するで高い精度での時刻の同期ができるようになっており，図13のように，原子時計，GPSなどから正確な時刻情報を得てそれを配布するホスト(Stratum1サーバ)，Stratum1サーバと同期し時刻情報を配布するStrutum2サーバ， Strutum2サーバに同期するStrutum3サーバ…，という階層構造を持つことで，特定のホストに時刻同期のリクエストが集中しないように設計されています。

LANでは，ISPがNTPサーバを用意している場合にはそこと，なければ表4に示す国内の公開NTPサーバと同期したNTPサーバを1台用意して，残りのホストはntpdateコマンドで1日に数回程度，用意したサーバと時刻を同期するようにすれば良いでしょう。ファイアウォールの関係などで外部のNTPサーバと通信できない場合には，安価なGPSユニットを用などして，自前でStratum1サーバを構築することも可能です。

NTPデーモンntpdやntpdateなどNTP関連ツールは，たいていのOSの配布パッケージか追加パッケージに含まれています。ソースコードが必要な場合にはhttp://www.eecis.udel.edu/.ntp/より入手してください。

リスト5にntpdの設定ファイルntp.confのサンプルを，図14にNTPクライアントntpdateの実行例を示します。

server	ntp1.jst.mfeed.ad.jp   #<- 同期するサーバの指定
server	ntp2.jst.mfeed.ad.jp
server	ntp3.jst.mfeed.ad.jp
server  127.127.1.0            #<- どのサーバとも同期できなかったら
                               #      内蔵クロックを使用する
fudge   127.127.1.0 stratum 10 #<- 内蔵クロックの優先順位を下げる
                               #      ためstratum10とする

driftfile /var/ntp/drift #<- driftファイルを/var/ntp/driftとして
                         #      作成する

# ntpdate ntpserver
 8 Dec 10:25:22 ntpdate[25727]: step time server 192.168.0.1
offset 30.981451 sec

なお，リスト5に出てくる127.127.t.u(t:クロックタイプを表す整数, u:クロックタイプ固有の番号)というアドレスは，参照時間アドレスと呼ばれる時間を取得するデバイスを指定するためのNTP独自の表現で，127.127.1.0を指定すると内蔵クロックから時間を取得することになります。

ログ／管理者宛メールを1ヵ所に集中

あちこちに散らばるホストのログや管理者宛メールを読むために，いちいちそのホストにログインするのはわずらわしいものです。ログや管理者宛メールは1ヵ所でまとめて読めるようにしてしまいましょう。

ログをほかのホストに転送する

ログ記録デーモンsyslogdにはログをほかのホストに転送する機能があり，たとえばリスト6のような内容を/etc/syslog.confに追加してsyslogdを再起動することで，すべてのログがloghostに渡されるようになります。

*.*		 @loghost

syslog.confは
ファシリティ.ログレベル [TAB] 出力先
という書式で記述し，とくに出力先に「@ホスト名」と指定した場合，ホスト名で指定したホストのsyslogdにログが転送されます。

ファシリティ，ログレベルにはそれぞれ出力したいログの種類およびログの重要度を指定します。ログがうるさく感じる場合には，ファシリティおよびログレベルを適度に調整すれば良いでしょう。表5に，Linuxのsyslogで指定可能なファシリティおよびログレベルを示します。

なお，Linuxのsyslogdはデフォルトではリモートからのsyslogを受け取りません。ログを受け取るホストがLinuxの場合には，ネットワーク経由でsyslogを受け取れるよう，syslogdの起動時に-rオプションを指定しておく必要があります。

メールをほかのホストに転送する

転送元ホスト，転送先ホスト共にsendmailなどのsmtpdが稼動している場合には，リスト7のように転送元のホストの/etc/aliasesを設定することでメールの転送で簡単に行うことができます。

postmaster:     root
root:           foo@loghost

どちらかのホストでsmtpdが稼動しておらず，かつ適当なsmtpdをインストールすることもできない事情がある場合には，少々乱暴な方法になりますが，メール転送元ホストでprocmailを用い，リスト8のような設定を用いてメールをMaildir形式でスプールし，そのスプールをrsyncで同期するという手段が考えられます。

DEFAULT=$HOME/Maildir/

また，メールの転送元ホスト，転送先ホスト共にprocmailを使用する場合には，スプールディレクトリをNFSで共有することも可能です。

ホストの状態を1ヵ所で監視する

現在動いているプロセスの数やCPUの負荷，メモリ使用率など，ログだけでは監視しきれないようなホストのさまざまな状態をリモートから取得，管理したい場合もあると思います。

そういった場合には，監視したいホストにNET-SNMPなどのSNMP(Simple Network Management Protocol)エージェントを導入し，監視するホスト側ではMRTGやGxSNMP，hp OpenView network node managerなどの適当なNMSマネージャを用いることを検討してみると良いでしょう。

SNMPはネットワークの構成管理作業を共通のインターフェースで行うためにRFC1157などで定められたプロトコルであり，ホストのみならずルータやスイッチングHUBなど数多くのネットワーク機器がこれに対応しています。

SNMPを使いこなすには，MIB(Management Information Base)についてある程度の知識が必要となり，若干敷居が高く感じられるかもしれません。小規模なLANではあまり必要性を感じないかもしれませんが，ネットワークが大きくなり，監視対象としたい機器類が増えるにつれ，SNMPは欠かすことのできない技術となってきます。ネットワークの状態が把握しきれなくなる前に，一度SNMPによる構成管理を試してみてはいかがでしょうか。