まとめ

まとめ

タグ:
(2005.4.25)

小野 雄太郎
慶應義塾大学環境情報学部 学生
Microsoft MVP for Windows Server - Networking, Jan 2004 - Jan 2006



 ネットワークシステムを管理する場合、いま管理しているネットワークで何が起こっているかを把握しておく必要がある。常にネットワークの状態を知っていることで、トラブルが発生した場合にも、迅速で適切な対応ができる。またよく管理されたネットワークは、管理する側にとっても利用者にとっても、安心して使えるインフラとなる。
 しかし、実際にネットワークの状態を把握し続けるには、たいへんな労力が必要だ。WindowsやUNIX、さらにはルータやアプライアンス機器など、多種多様なシステムが混在している。これらの機器がどのような状況なのか、それぞれのシステムでどんなことが起こっているかを知るために、イベント管理という手法を使うことができる。


イベント管理で負荷を軽減する

 イベント管理とは、それぞれのシステムが出力するイベント、動作ログやシステムメッセージなどを集約・管理して運用に役立てる手法である。稼働しているシステムからは、ふだん思っている以上のイベントが生成され、そして記録されている。このイベントを有効活用すれば、ネットワーク全体の状態を把握することができるようになる。しかし、それぞれのイベントを個別に見て回っていては、非常に手間がかかるだけでなく、全体の状況を把握することも困難である。それを解決するためにイベント管理ツールを利用する。

 今回ご紹介するのは筆者が開発したManaged Syslog Server である。IPv6普及・高度化推進協議会が主催した 「IPv6アプリコンテスト 2004」で優秀賞を受賞した。このアプリケーションは、UNIXなどでよく利用されているSyslogをWindows環境で利用できるようにするものだ。SyslogをベースにWindows環境とUNIX環境を統合することで、さまざまな機器が混在するネットワークシステムから生成されるイベントを集約し、統合的にイベントを管理できるようになる。Managed Syslog Serverは筆者のBlog (http://cham-reo.com/blog/archive/2004/11/17/1835.aspx) からダウンロードできるほか、IPv6アプリコンテスト 2004 Webサイト (http://www.v6pc.jp/apc/jp/awards.html) からも入手でき、フリーソフトウェアとして利用できる。


Syslogってそもそも何?

 Managed Syslog Server の紹介に入る前に、このアプリケーションの中核となるSyslogについてお話しする。
 SyslogはもともとBSDをはじめとするUNIX系システムで使われていたイベント配信システムである。Syslogの特徴は、ディスクレスシステムなどでも利用できるよう、特定のシステムで発生したイベントをネットワーク経由でほかのマシンに送り、そこでイベントを蓄積できるようにしていたことにある。そのためローカルにストレージを持たない機器のイベント報告方法として、UNIXシステムに限らずルータやスイッチなどのデバイスにも実装されるようになった。これを活用することで、複数のシステムからイベントを集め、一括してイベントを蓄積・運用することが可能だ。
 Syslog について詳しく知りたい読者は、Syslogプロトコルを解説している RFC 3164などを参照 してほしい。
[RFC 3164] The BSD syslog Protocol - http://www.ietf.org/rfc/rfc3164.txt
日本語訳 - http://www.amris.co.jp/netdocs/rfc3164_j.html


Managed Syslog Serverの基本コンセプト

 それでは Managed Syslog Serverについて詳しくご紹介する。Managed Syslog Serverは、UNIXで広く使われているSyslogをWindows環境でも利用できるようするために開発した。Syslogには、イベントをネットワークに送信するデバイス、Syslogを受信・転送するリレー、そしてSyslogを受信してイベントを蓄積するコレクタという3つの機能単位が存在する。Managed Syslog Serverの構成ファイルを書き換えることで、これら3つの機能をすべて実現できるほか、それぞれの機能を組み合わせて運用することが可能になっている。
 このManaged Syslog Serverは、Windowsサービスとして動作する。開発時に動作を確認しているのは、.NET Framework version 1.1 Service Pack 1 をインストールした、Windows XP Service Pack 2または Windows Server 2003 の環境である。この環境以外でも、.NET Framework v1.1 がインストールされていれば、Windows 2000 Serverなどでも利用が可能だと思う。
 また、Managed Syslog Serverは、モジュール式アーキテクチャを採用している(図1を参照)。 この、柔軟に構成を変更できるモジュール式アーキテクチャのおかげで、内部処理プロセスをさまざまな環境に合わせて変更することが可能になり、従来のSyslogアプリケーションが対応できなかったヘテロジニアスな(異機種混在の)環境でも利用することが可能になっている。さらにオリジナルのモジュールを自由に開発して利用することも可能である。そのためきわめて特殊な環境でも、.NET Frameworkのさまざまな言語から好きな言語を選択し、オブジェクト指向の高い開発効率でオリジナルモジュールを開発できる。

Managed Syslog Server
Managed Syslog Server


Managed Syslog Serverが実現すること

 先に紹介したとおり、Managed Syslog Serverはモジュール式アーキテクチャを採用している。標準で用意されているモジュールには、次のようなものがある。
  • Syslog Listener
    • UDPプロトコルリスナ
    • Windowsイベントログ to Syslogリスナ
  • Syslog Collector
    • テキストログライタ
    • RDBMS OLEDBライタ
    • Windows イベントログライタ
    • Syslog 転送ライタ
  • Syslog Processing Filters and Plug-ins
    • 文字エンコーディング変換フィルタ
    • ソースアドレスフィルタ
    • イベント重大度フィルタ
次に、それぞれのモジュールを紹介していく。

Syslog Listener
 Syslog ListenerはManaged Syslog Serverで処理させるイベントを受け取るためのモジュールである。ここで用意されているモジュールは UDPプロトコルリスナと Windowsイベントログ to Syslogリスナである。
 UDPプロトコル リスナは名前のとおり、UDPプロトコルを使ってデバイスから送信されたSyslogパケットを受信する。このリスナはIPv4とIPv6双方に対応しており、また同一ホスト上で複数のIPアドレスおよびポートで待ち受けが可能である。
 Windowsイベントログ to Syslogリスナは、Windowsイベントログを監視して、構成ファイルで指定されたパターン条件にマッチするイベントが発生した場合、自動的にそのイベントをSyslogに変換して Managed Syslog Serverに取り込むことができる。このリスナを利用することで、Windowsイベントログのイベントを Syslogメッセージ と統合して運用することが可能になる。

Syslog Collector
 テキストログライタは、Syslogメッセージを、構成ファイルによって指定された形式で、テキストファイルとして記録する。
 データベースライタは、SyslogメッセージをRDBMSなどのOLEDBプロバイダ対応ストレージに保存する。イベントをデータベースに格納することによって、イベントを集中管理し、再利用しやすくすることが可能となる。
 Windowsイベントログライタは、Syslogメッセージを Windowsイベントログ に記録する。UNIXシステムやルータなどのデバイスで生成されたSyslogメッセージを、Windowsイベントログに記録して一覧することができるようになる。
 Syslog転送ライタは、Syslogメッセージをほかのリレー/コレクタに向かって転送する。このSyslog転送ライタを利用することで、Managed Syslog Serverをリレーおよびコレクタとして、同時に利用することが可能になっている。

Syslog Processingフィルタとプラグイン
 Syslog フィルタ/プラグインは、Managed Syslog ServerでSyslogメッセージを処理するフローの間で、Syslogメッセージのフィルタリングや変換を行う。フィルタでSyslogメッセージに処理を施すことで、1つのモジュールをさまざまな環境で再利用可能にしている。
 代表的なフィルタとして、文字エンコーディング変換フィルタを用意している。このフィルタはSyslogメッセージの送信元によって文字コードを識別し、内部で利用されているUnicodeへの変換処理が実行されるようにする。このフィルタを利用することで、これまでほかのアプリケーションで実現できなかった、多言語混在環境でのSyslogメッセージ統合が可能になる。
 ソースアドレスフィルタは、Syslogメッセージを送信元によって選別します。このフィルタによって必要なデバイスからのSyslogメッセージのみを受け取ることができるようになる。
 イベント重大度フィルタは、Syslogメッセージに含まれるイベントの重大度を基準にフィルタリングを行う。また、重大度に応じて処理を行う Syslog Collectorを選択することができるため、フィルタをうまく組み合わせることによって、イベントの重大度によるイベントのルーティングが可能になっている。


Managed Syslog Server を使う

 では、実際に Managed Syslog Server の構成を解説していく。今回は比較的シンプルな構成を3種類紹介したいと思う。
 最初は一番シンプルな構成である。ルータなどのデバイスからSyslogメッセージを受け取り、それをテキストログファイルに記録する。この構成は、UDPプロトコルリスナによってSyslogメッセージを受け取り、テキストログライタでそのSyslogメッセージをテキストログファイルに保存するというシンプルな構成である。この場合は構成ファイルを次のように構成する。
‹!-- Syslogメッセージをテキストログファイルに保存 --›
‹syslogConfig›
‹settings›
    ‹defaultEncoding name="euc-jp" /›
    ‹errorPacket rule="Reject" /›
‹/settings›
‹listener›
    ‹modules›
      ‹assembly id="udp-listener" type="Syslog.Listener.UDPListener" name="mlog_listen"›
       ‹!-- ローカルネットワークインターフェイスに割り当てられているすべてのアドレスでSyslogメッセージを待ち受ける --›
        ‹allow address="0.0.0.0" port="514" /›
        ‹allow address="::1" port="514" /›
      ‹/assembly› 
    ‹/modules›
    ‹filters /›
‹/listener›
‹relay›
    ‹plugin /›
    ‹filters /›
‹/relay›
‹collector›
    ‹modules›
      ‹assembly id="logfile-writer" type="Syslog.Collector.Writer.SimpleFileWriter" name="mlog_coll"›
        ‹!-- ログファイルを 1日ごとにファイルを分けUTF-16で [日時] [受信インターフェイス][Syslogメッセージ] 形式で記録 --› 
        ‹simpleFileWriter rotation="daily" outputPath="%SystemRoot%\System32\Logfiles\Syslog" encoding="utf-16"›{DateTime} 
{DestAddress:host} {Syslog:PRI}{Syslog:HEADER} {Syslog:MSG}‹/simpleFileWriter› ‹/assembly› ‹/modules› ‹/collector› ‹/syslogConfig›
 次に、最初の構成を発展させ、送信元デバイスごとに違う文字コードのSyslogパケットを受信しても正しく処理できるように構成してみる。文字エンコーディング変換フィルタを追加し、送信元デバイスごとに文字コードを指定する。これによって受信したSyslogパケットの文字コードを認識し、正しくUnicodeに変換して処理できるようになる。
‹syslogConfig›
‹settings›
    ‹defaultEncoding name="euc-jp" /›
    ‹errorPacket rule="Reject" /›
‹/settings›
‹listener›
    ‹modules›
      ‹assembly id="udp-listener" type="Syslog.Listener.UDPListener" name="mlog_listen"›
        ‹allow address="0.0.0.0" port="514" /›
        ‹allow address="::1" port="514" /›
      ‹/assembly›
    ‹/modules›
    ‹filters›
      ‹assembly id= "encoding-selector"type="Syslog.Listener.Filter.EncodingSelector" name="mlog_listen"›
        ‹!-- 特定のソースアドレスに該当するSyslogメッセージの読み取り文字エンコーディングを変更する --›
        ‹select source="127.0.0.1" encoding="shift_jis" /›
        ‹select source="192.168.0.1" encoding="utf-8" /›
        ‹select source="192.168.0.2" encoding="utf-8" /›
        ‹select source="::1" encoding="shift_jis" /›
      ‹/assembly›
    ‹/filters› 
‹/listener›
‹relay›
    ‹plugin /›
    ‹filters /›
‹/relay›
‹collector›
    ‹modules›
      ‹assembly id="logfile-writer" type="Syslog.Collector.Writer.SimpleFileWriter" name="mlog_coll"›
        ‹simpleFileWriter rotation="daily" outputPath="%SystemRoot%\System32\Logfiles\Syslog" encoding="utf-16"›{DateTime} 
{DestAddress:host} {Syslog:PRI}{Syslog:HEADER} {Syslog:MSG}‹/simpleFileWriter› ‹/assembly› ‹/modules› ‹/collector› ‹/syslogConfig›
 最後に、イベントログからイベントを取り込み、それらのイベントをテキストログファイルに保存すると同時に、Windows イベントログへも保存するように構成してみる。まずWindowsイベントログリスナを追加する。Windowsイベントログリスナでは、Microsoft SQL Serverに関係するイベントを中心的に扱うよう構成し、イベントの種類によってSyslogメッセージの重大度を変更するようにした。そしてWindowsイベントログライタも追加し、テキストログファイルに保存すると同時に Windows イベントログへSyslogメッセージを記録するようにした。このように構成することによって、テキストログファイルにイベントを記録するとともに、Windows イベントログへも同じ内容が記録されるので、Windows イベントビューアを利用してSyslogメッセージを含めたイベントを集中的に管理することが可能になる。
‹syslogConfig›
‹settings›
    ‹defaultEncoding name="euc-jp" /›
    ‹errorPacket rule="Reject" /›
‹/settings›
‹listener›
    ‹modules›
      ‹assembly id="udp-listener" type="Syslog.Listener.UDPListener" name="mlog_listen"›
        ‹allow address="0.0.0.0" port="514" /›
        ‹allow address="::1" port="514" /›
      ‹/assembly›
      ‹assembly id="eventlog-listener" type="Syslog.Listener.SimpleEventLogListener" name="mlog_listen"›
         ‹!-- ローカルマシンのシステム イベントログを15秒間隔で監視 --›
         ‹eventlog target="System" machine="." interval="15000"›
         ‹!-- MSSQLServer が記録したエラーイベントログをファシリティをDaemonに変更して取り込む --›
         ‹priorityfacility="Daemon" severity="Error"›
            ‹regex source="Source"›MSSQLServer‹/regex›
            ‹regex source="EntryType"›Error‹/regex›
          ‹/priority›
         ‹priorityfacility="Daemon" severity="Warning"›
            ‹regex source="Source"›MSSQLServer‹/regex›
            ‹regex source="EntryType"›Warning‹/regex›
          ‹/priority›
         ‹priorityfacility="Daemon" severity="Notice"›
            ‹regex source="Source"›MSSQLServer‹/regex›
            ‹regex source="EntryType"›Information‹/regex›
          ‹/priority›
          ‹!-- 他のイベントログはすべて重要度をNoticeに下げて取り込む--› 
         ‹priorityfacility="User" severity="Notice" /›
        ‹/eventlog›
      ‹/assembly› 
    ‹/modules›
    ‹filters /›
‹/listener›
‹relay›
    ‹plugin /›
    ‹filters /›
‹/relay›
‹collector›
    ‹modules›
      ‹assembly id="logfile-writer" type="Syslog.Collector.Writer.SimpleFileWriter" name="mlog_coll"›
        ‹simpleFileWriter rotation="daily" outputPath="%SystemRoot%\System32\Logfiles\Syslog" encoding="utf-16"›{DateTime} 
{DestAddress:host} {Syslog:PRI}{Syslog:HEADER} {Syslog:MSG}‹/simpleFileWriter› ‹/assembly› ‹assembly id="eventlog-writer" type="Syslog.Collector.Writer.SimpleEventLogWriter" name="mlog_coll"› ‹eventlog machine="." format="xml" /› ‹/assembly› ‹/modules› ‹/collector› ‹/syslogConfig›
まとめ

 これまでManaged Syslog Server によるSyslogメッセージを利用したイベント管理について解説してきた。Managed Syslog Severは、IPv6でもIPv4でも、どちらにも違いはなく、同等に扱うことができる。プロトコルの違いを気にすることなく、ネットワークシステムの運用管理に専念できる環境を提供する。IPv6ネットワークが普及するにつれ、このようなプロトコルに依存しない統合的なアプリケーションへのニーズが高まると考えている。IPv6ネットワークが実運用されていくこの時代に、Managed Syslog Serverがお役に立てることを期待している。

この記事のトラックバックURL

http://www.ipv6style.jp/trackback/289
Ads by Google

IPv6ブログ