WinSyslog 13 マニュアル

日本語版                      

WinSyslog は、Windows 上で稼動する Syslog サーバーです。
（Unix のSyslogデーモンと同じ役目を果たします。）

ネットワーク管理において WinSyslog をご使用頂けば、継続的にシステムを監視することができます。さらに、重要なイベントが発生した場合には、即座に通知を受け取るようにも設定できます。

Syslog は、システム・イベントの集中レポート作成のための標準プロトコルです。そのルーツはUNIX環境にありますが、例えば、Cisco のような最新のデバイスは Syslog プロトコルを使用しています。

それらのデバイスは、重要なイベントやオペレーティングのパラメーター、デバッグのメッセージでさえSyslogでレポートを作成します。残念ながら Microsoft Windows は syslog サーバーを含んでいません。（Syslog サーバーは「Syslogデーモン」や Syslogd などと呼ばれたりしています）
Adiscon の WinSyslog はこのギャップを埋めるものです。

バージョン3.0以前、WinSyslogは「NTSLog」の名で知られていました。最初のバージョンは、Ciscoルータのステータスメッセージを受け取るために1996年に作成されました。

製品は、これまで断続的に開発されています。この製品は、バージョン３で飛躍的に機能性が高まりました。それがバージョン３で製品名を変えるきっかけとなりました。

また WinSyslog は、Adiscon製品の MonitorWare エージェント、EventReporter、ActiveLoggerとともに、Windows のイベントログをトータル的に集中監視するツールとして使うこともできます。WindowsNT/2000/XPの中央モニタリングに関しては、http://www.monitorware.com. （英語）で詳細を確認できます。
（現在のところ、弊社では WinSyslog のほか EventReporter を販売しております。）

ほとんどのユーザーは Syslog のデバイス（例：ルータ、スイッチ、ファイアーウォールやプリンターなど）から発生したイベントログを集め、それらを持続的に Windows のシステムに保存することなどに WinSyslog を利用しています。
WinSyslog は、インタラクティブにスクリーン上で syslog メッセージを表示することができるだけでなく、さらに収集した Syslogメ ッセージをフラットな ascii ファイル、ODBC データベース、または Windows イベントログに保存することもできます。
この製品は、はじめに設定を行いさえすれば、信頼できるサービスとして動作し、オペレーターの操作を介する必要もありません。サービスは、Windows の起動時に自動的に立ち上がります。

バージョン4で改良されたサービス、ルールによって、WinSyslog の設定はより融通性の高いものになりました。
WinSyslog は、入って来るメッセージ内の文字列照合などの状態を発見したり、それに従って能動的に動作を行ったりといったことが可能です。例えば、優先順位の高いメッセージを発見した場合は、Eメールメッセージを送信することなどが可能です。複数の Syslog サーバーで同時にこの動作を行えます。さらにそれぞれ別のポートを使用できます。

TOPへ

■ ログの集中管理
これは WinSyslog のキーとなる機能です。
WinSyslog は、それぞれのソース（デバイス）から送られた全ての Syslog メッセージをまとめて、ローカルのWindows システムに保存します。デバイスが Syslog に対応していれば、WinSyslog でそれらを処理できます。
今日においては、事実上、すべてのデバイスで Syslog を使うことができます。
顕著な実例として、Ciscoルータが挙げられます。

■ 使い易さ
WinSyslog 設定クライアントにより、セットアップやカスタマイズが容易に行えます。
さらに、大規模な環境で利用できるGUIを利用しないインストール方法をについてもサポートしております。

■ 効果的なアクション
受信した各メッセージは、WinSyslog の効果的で柔軟性の高いルールエンジンによって処理されます。
各ルールでは、メッセージがルールの「フィルタの条件」に一致したときに、どのアクションが実行されるのかを設定します。（例えば、Eメールでメッセージを送信するのか、データベースに保存するのかなど）
「フィルタの条件」では、メッセージ内の文字列や Syslog ファシリティ、プライオリティなど、お客様のニーズに合わせた条件設定が可能となっており、不要なメッセージの絞込みが容易に行えます。
なお、利用できるルールの「フィルタの条件」とアクションには数には制限がありません。

■ インタラクティブ Syslog ビューア
受信したメッセージをインタラクティブに表示したい場合は、インタラクティブ Syslog ビューア（インタラクティブ Syslog サーバーの後継ツール）を使用します。（日本語メッセージも処理できます。）
その他、WinSyslog・EventReporterで作成したデータベースを読み込み、確認する機能も追加されました。

■ Syslog テストメッセージの送信
WinSyslog 設定クライアントには、「Syslog テストメッセージを送信」 の機能が実装されております。（ツールメニュー内にあります）
このオプションにより、ルールセットの設定を確認したり、インタラクティブ Syslog ビューアへ送信テストを行なったりすることができます。ただし、このオプションによるメッセージ送信に利用できるプロトコルのは、UDPのみです。（RFC 3195 には対応しておりません）

■ 試用期間に関して
WinSyslog、インタラクティブ Syslog ビューアとも、セットアップ後 30日間 は試用モードとして全ての機能をご利用になれます。

試用期間の終了後、WinSyslog はサービスが開始できなくなります。
インタラクティブ Syslog ビューアは、試用期間終了後も開始させることはできますが、5分後に停止するようになります。

Syslogサーバーサービスやメール送信、データベースログなどの便利な機能をご利用になりたい場合には、ライセンスをご購入頂く必要がございます。

■ 標準の互換性
WinSyslog は、Syslog RFC3164、RFC5424 に対応しています。
WinSyslog は、送信者（デバイス）やサーバーや中継マシンとして稼動します。
全ての仕様のオペレーションモードがサポートされます。

RECに対応していない部分は、ローカルの環境に合うように管理者が設定することが可能です。
（例えば、デバイス時計が信頼できない場合には、タイムスタンプは報告しているデバイスの代わりにローカル・システムから取り出すことができます）

■ Syslog 階層
WinSyslog は大きな組織で必要となるカスケードされた設定をサポートします。
カスケード設定には、重要なイベントを本部の中心となる WinSyslog に報告する、部やサイトレベルで動作するローカルの WinSyslog が例としてあげられます。
カスケードされたシステムには、レベルの数に対する制限がありません。

■ Ｅメールでの通知
ユーザーが設定したルールに基づいて、受信した Syslog メッセージをEメールで送ることができます。
このEメールによる通知は、どんなEメールアドレスにも送る事が出来ます。
（携帯電話でも受信できます）

また、E メールの題名は完全にカスタマイズすることが出来ます。
オリジナルのメッセージをインクルードするように設定する事も出来ます。
従って、携帯電話であっても十分に情報を受信する事が出来ます。  

■ 継続的メッセージの保存
WinSyslog の Syslog サーバーは、継続して全てのメッセージを保存することができます。
したがって、後の監査や重要なシステム･イベントの再調査などが容易にできます。
メッセージは、フラットな ascii ファイル、ODBC データソースと Windows のイベントログ などに書くことができます。

■ 複数のインスタンス
WinSyslog は、同じマシン上で複数の Syslog サーバーサービスを稼動させることができます。
それぞれが違う Syslog  ポートを使用し、TCPまたはUDP を選択できます。
そして、別々のルールセットを作成できます。
ただし、同じ設定内容（ポート・プロトコル）のSyslog サーバーサービスを複数稼動させることはできません。

■ 完全なログ収集
WinSyslog は、受け取った Syslog メッセージに加え、送信者のシステムのIPアドレスや日付だけでなく、そのプライオリティやファシリティコードをも記録します。
それは、さらに正常なフォーマットがされていないパッケージ（無効なプライオリティ/ファシリティがある、またはそれら自体ない）を記録することができるので、メッセージは消失しません。

■ 安定性
WinSyslog は、正常でない環境のもとでも実行できるように作成されています。
その信頼性は、1996年以降、顧客サイトで証明されています。

■ 最小限のリソース使用
WinSyslog には、システムリソースへの顕著な影響がありません。
それは、最小限のリソース使用ということを念頭において、作成されたからです。
これは、負荷の大きなサーバーに対してもインストールできるということを保証しています。

■ ファイアーウォールサポート
セキュリティ・ポリシーなどにより、標準でない Syslog ポートを使う必要にせまられた場合でも、WinSyslog は、Syslog メッセージに対して、いかなるTCP/IPポートでも使用できるように設定できます。

■ NTサービス
WinSyslog サービスは、 マルチスレッドな Windows NT サービスとして実行されます。
それは、コントロールパネルやコンピューターの管理 -MMC (Windows 2000)で制御できます。

■ IPｖ６
ネットワークに関連のある全てのサービスやアクションで IPｖ6 をご利用になれます。
IPv6のアドレスが有効ならば、DNS 名前解決も可能です。［Syslog サーバー］サービスなど、IP アドレスを設定する項目では、IPv4 か IPv6かを選択することができます。（［IPタイプ］の設定）
IPv4とIPv6が混在する環境では、そのIPタイプ別にサービスを設定する必要があります。（RELPサービスだけは、IPタイプが自動検知されますので、サービスを分けて設定する必要はありません。

■ Windows2000 、2003、2008、XP、Vista、Windows 7、8、2012 完全対応
WinSyslogは、その出荷当時から、完全にWindows2000、2003、XP、Vista、2008、7、8、Windows 2012 に対応しています。
そして、WinSyslog はバージョン3.6以降、Windows XP 対応するようデザインされています。
さらに新しい「テーマ」機能や「fast user switching（ 高速ユーザー切り替え）」機能にも対応しています。

■ 複数の言語対応のクライアント
WinSyslog クライアントは、多言語対応になっています。
ボックスから、英語、フランス語、ドイツ語、スペイン語、日本語を選択できます。
言語は、すぐに切り替えることができ、ユーザー自身が自由に選択できます。

■ 親しみやすく、カスタマイズも可能なユーザーインターフェイス
WinSyslog クライアントに新たにスキン機能が加わりました。−デフォルトにより5種類の新しいスキンがインストールされ、選択できます。これらのスキンは、色、彩度とRGBカラーによりカスタマイズすることが可能です。

また、クローンの機能が追加されました。クリックするだけで、ルールセット、ルール、アクション、サービスそれぞれのクローンを作成できます。
「上へ移動」、「下へ移動」の機能がアクションで使用できるようになりました。
アクション、サービス、ルールセット作成のウィザードが改良されました。

■ ローメモリへの対応
WinSyslog は、起動時に非常用のメモリを割り当てます。システムのメモリ制限に達した場合、非常用のメモリが解除され、キューはロックされます。
それにより、それ以上どんな項目もキューに入れられなくなります。
結果として、サービスの停止（crash）を防ぐことができるようになります。

TOPへ

中核となる構成

■ WinSyslog設定クライアント
WinSyslog設定クライアント（クライアントと呼ばれます）は、WinSyslogサービスの全ての要素と機能の設定に使用されます。
また、多数のマシンで同じ設定でWinSyslogを使用したい場合など、ベース・システム上のクライアントで設定ファイルを作成・エクスポートし、対象システムに組み込むこともできます。  

■ WinSyslogサービス
WinSyslogサービス（サービスと呼ばれます）は、Windowsサービスとして稼動し、実際の処理を実行します。
WinSyslog を動作させるためには、サービスがインストールされていなければなりません。
WinSyslogサービスは、製品の「エンジン」と呼ばれています。したがって、サービスのみインストールされたシステムを「エンジンだけの」インストールと呼びます。
サービスは、ユーザーの操作の必要なしにバックグラウンドで動作します。
それは、コントロールパネルやコンピューターの管理 -MMC (Windows 2000)で制御できます。

＜x64対応バージョン の組み込み＞

x64対応版は、セットアップ時に自動的にご利用の OS に合わせてインストールされます。（インストーラが判断します）
主に変更された箇所は、サービスのコアの部分です。
詳細は、以下をご覧下さい：

■ [ODBCデータベース] アクションが x64 システム上で動作するようになりました。
但し、[システムDSN] を設定する際は、[データベースログ] アクションの[データソース]から呼び出す[ODBCデータアドミニストレーター]でなく、下記ディレクトリ内にある32bit用の[ODBC データソースアドミニストレーター]で実行してください； C:\Windows\SysWOW64\odbcad32.exe

■ 設定情報（レジストリ）の保存に関して、DWORD値がQWORD値としてレジストリに保存されるようになりました。けれども、設定クライアントとWin32バージョンのサービスでは、これらのデータタイプを処理でき、必要に応じて自動的に値がDWORD値に変換されます。
x64版であっても設定クライアントは、win32アプリケーションのままとなっております。 

アドオン構成

■ インタラクティブ Syslog ビューア
インタラクティブ Syslog ビューアは、Syslogイベントを受信し、リアルタイムに表示するWindows GUI アプリケーションです。一般的には WinSyslog や EventReporter とともに使用されます。しかし、独立した Syslog サーバーとしても使用することができます。

インタラクティブ Syslog ビューアは、インタラクティブ Syslog サーバーの後継ツールです。
インタラクティブ Syslog ビューアでは、日本語文字列を含むメッセージの処理も可能です。また、WinSyslog や EventReporter で作成したデータベースの内容を読み込み、確認する機能も追加されました。

■　Adiscon LogAnalyzer (旧PhPLogCon）
Adiscon LogAnalyzer  は、収集されたメッセージをにweb上に表示できる便利な機能を持っています。
このツールは、たいていのブラウザに対応しています。

Adiscon LogAnalyzer は、Syslog メッセージ、Windows イベントログデータ、その他のネットワークイベントを簡単に web で閲覧することができます。このツールを使用することにより、システム管理者は、迅速に容易にログをチェックすることが可能となります。

Adiscon LogAnalyzer は、WinSyslog のインストールフォルダに含まれています。現在のところ、日本語マニュアルなどはございません。
詳細は、http://loganalyzer.adiscon.com/doc/ または  「Adiscon LogAnalyzer」フォルダ配下の「doc」フォルダ内の英語マニュアルをご参照下さい。

■ MonitorWare コンソール

＊弊社では、現在のところ、MonitorWare コンソールの販売は行っておりません。
＊詳細は、www.mwconsole.com （英語）にてご覧頂けます。

MonitorWare コンソールは、ネットワークから役に立つ情報を容易に集めることができ、また、その集めた情報に対して、セキュリティ違反を含む無数の問題を調査することが可能です。

MonitorWare コンソールの表示、レポートモジュールを使用することで、能率的に問題を含む範囲をネットワーク上で検出することができます。

これらの構成要素を共に動作させるには

前途の構成要素は、共に密接に動作します。

中核の構成は WinSyslog サービスであり、 これは継続的にバックグラウンドで動作しています。

WinSyslog設定クライアントでは、サービスの設定を行います。

クライアント自体は、サービスの設定を行うことがクライアントの唯一のタスクであり、一旦 WinSyslog の設定を行った後は、継続してクライアントを起動させて置く必要はありません。

一度サービスの設定を行えば、サービスはバックグラウンドで動作し、設定のとおり実行されます。最も重要な処理として、サービスはSyslogメッセージの受信や、ルールベースによるそれらのメッセージの処理、それらをデータベースやテキストファイルに保存すること、アラートを出すことなどがあります。

WinSyslog サービス自体には、インタラクティブな構成はありません。

Syslog メッセージを Windows GUI で表示する場合には、インタラクティブ Syslog ビューアが必要となります。インタラクティブ Syslog ビューアは、インタラクティブにメッセージを表示する以外は、機能が制限された負荷の軽い Syslog サーバーとして実行されます。

インタラクティブ Syslog ビューアは、起動した時のみ処理を実行します。

インタラクティブ に Syslog メッセージを表示させるために WinSyslogサービスはメッセージをインタラクティブ Syslog ビューアへ転送します。デフォルトでは、標準ポートでない UDPのポート10514で処理されます。従って、WinSyslogサービス、およびインタラクティブ Syslogサーバーは、ポートの衝突なしに同一のマシン上で稼動します。

メッセージの流れについては、下図を参照して下さい：

典型的な設定では、ルータやスイッチなどの Syslog デバイスは、WinSyslog サービスへ514ポートを使用して Syslog メッセージを送信します。サービスは、メッセージを受信し、ルールセットでの設定に基づき、それらを処理します。上図の例では、入ってくる全てのメッセージに対して、データベースへの書き込み、テキストファイルへの書き込み、インタラクティブ Syslog ビューアへの転送の3つのアクションが設定されています。

デフォルトでは、メッセージは 10514 ポートを使用して、ローカル（127.0.0.1）のインタラクティブ Syslog ビューアへ転送されます。インタラクティブサーバーは、順次ポートを開き、サーバーから転送されたsyslog メッセージを受け取ります。

UNIX-用語では、WinSyslog Service は syslog リレーと同様に受信機としての機能を果たします。一方、インタラクティブ Syslog ビューアは、ただの受信機としての機能のみで、中継の機能はありません。

従って、実際はカスケードされた syslog サーバーの設定がここではなされています。インタラクティブ Syslog ビューアは、その機能を可能にする Syslog プロトコルに対して共通の機能拡張が守られるので、メッセージソースとして、オリジナルのメッセージアドレスが表示することが可能です。

WinSyslog 設定クライアントは、サービスの設定を行う際にだけ必要とされます。一旦その設定がなされると、クライアントは使用する必要がなく、メッセージの処理に必要な要素にはなりません。

その他、Adiscon LogAnalyzer は、ウェブ上で Syslog メッセージにアクセスしたい場合のみ必要となります。これはオプション機能であり、デフォルトではインストールされません。

Adiscon LogAnalyzerは、WinSyslog のインストールフォルダに含まれています。
現在のところ、日本語マニュアルなどはございません。
インストール方法など 詳細は、「Adiscon LogAnalyzer」フォルダ配下の「doc」フォルダ内の英語マニュアルをご参照下さい。

上図の設定は、WinSyslog構成要素がいかに共に機能するかを示すためのものであり、あくまでサンプルです - WinSyslogの設定は、その必要性に応じて他にも多数の方法があります。

TOPへ

WinSyslog には最小ではありますが、必要条件があります。

WinSyslog クライアント は、以下の環境でご利用いただけます：

WinSyslog サービスは、以下の環境で動作いたします：

サービスはより小さな必要条件で稼動します。
最も重要な違いは、サービスはシステム上にインターネット・エクスプローラを必要としないということです。

＊1
使用にされる実際のリソースは、主に設定されるサービスに左右されます。
サービスが受信するメッセージが1秒間に数件である場合は、パフォーマンスへの影響は顕著ではありません。
もし1秒間に何百件のメッセージをWinSyslogサービスが受信するならば、より大きなリソースを必要とします。それでも、実際の負荷は実行されるアクションに左右されています。

テキストファイルにメッセージを保存することは、データベース・テーブルにそれらを書き込むこと（特にデータベース・エンジンが同じマシンに置かれる場合）よりもパフォーマンスは大きくありません。
このように、システム必要条件はハードウェアのサイズというよりは、処理の大きさに左右されると言えます。

けれども、サービスが（Syslogメッセージなどの）メッセージ・バースト（大量にデータをまとめて伝送する）を含む高度な処理を行う場合は、最も負荷がかかるという点に注意してください。

大量のバーストが予想される場合、それから時間のかかるアクション（例：データベースに書き込む）を実行する場合は、マシンにメモリを追加することをお勧めします。その場合、64MBのメモリの追加を推奨します。典型的に見て一つのメッセージのサイズは約1.5KBあります。 64MB追加した場合は、50, 000 メッセージをバッファリングできます。

また、WinSyslogは、マシンがあまりに時間がかかり過ぎてメッセージの処理を行えない場合、一時的にそのようなバーストをメモリに保存することができます。

TOPへ

WinSyslog のインストールは単純で簡単です。
標準のセットアッププログラムでアプリケーションのインストールができます。

WinSyslog のセットアップファイルは、こちら からダウンロードできます。
インストールセット（ダウンロードしたzipファイル）には、標準のスタートアップ・プログラムとヘルプファイルが含まれています。
アーカイブをどこかのディレクトリ（特に場所は問いません）に解凍してください。解凍先は、ローカルドライブ、リムーバルドライブそれからリモートシェアのファイルサーバーなどでも構いません。なお、Win32 Unzipプログラムは、http://www.winzip.com./ で入手できます。 解凍した後は、「setup.exe」（＝セットアップ プログラム）をダブルクリックし、画面上の指示に従っていってください。

もしも、setup.exeファイルを直接ダウンロードした場合には、解凍の部分の説明は無視してください。（exeファイルかzipファイルかは、どこでダウンロードしたかによります）

＜ Adiscon LogAnalyzerのインストール ＞

Adiscon LogAnalyzer は、 WinSyslog や EventReporter で作成したデータベースをにweb上に表示するため、Adiscon社によって開発されたフリーツールです。このツールは、たいていのブラウザに対応しています。 
Adiscon LogAnalyzerのご利用には、Webサーバー（IIS 4以降、Apache など）、および PHP がインストールされたマシンをご用意頂き、PHP スクリプトが実行可能な環境設定を行って頂く必要がございます。

Adiscon LogAnalyzerは、WinSyslog のインストールフォルダに含まれています。
弊社では、Adiscon LogAnalyzer の直接サポートは行っておりません。
そのため、現在のところ、日本語マニュアルなどはございません。
詳細は、「Adiscon LogAnalyzer」フォルダ配下の「doc」フォルダ内の英語マニュアルをご参照下さい。

WinSyslog のインストール後は、動作設定を行う必要があります。
（インストールされたままの状態では、WinSyslog は何も処理を行いません。）

いくらかの基本的な処理を行うために、以下の作業を行って下さい: 

基本のルールセットの作成
最もベーシックなルールセットには、フィルタの条件が設定されておりません。
それは、メッセージを絞り込まずに、WinSyslog で受信した全てのメッセージを処理することを意味します。
はじめは、「ファイルログ」のアクションだけを使用することをお勧めします。
このアクションは、受信したメッセージをローカルのディスクに書き込みます。

最低でも１つのSyslogサーバーサービスを設定
Syslogメッセージを受信するために、Syslogサーバーサービスを設定し、作成したルールセットをこのSyslogサーバーサービスと関連付けるようにして下さい。
（Syslogサーバーサービスは、デフォルトで作成されておりますので、新たに作成する必要はございません）

WinSyslogサービスの起動
これでメッセージの受信、保存の準備が整いました。
　

詳しくは、手順書 受信した Syslog をファイル保存するには をご参照ください。

■ レジストリファイルに設定をエクスポートする

弊社サポート宛にお問い合わせ頂いた際、その内容によっては、お客様の設定内容を確認させて頂く場合がございます。
（「レジストリファイルに設定をエクスポートする」を実行し、保存して頂いたものをメール送付して頂きます；下図参照）

▲ 従来の設定クライアント― 「コンピュータ」メニュー

▲ 新しい設定クライアント―「ファイル」メニュー

＊ 32bit版OSでWinSyslogをご利用の場合には「レジストリファイルに設定をエクスポートする（Win32）」、64bit版OSでご利用の場合には「レジストリファイルに設定をエクスポートする（x64）」を選択してください。

設定情報のエクスポートは、サポートの場合だけでなく、設定のバックアップを行いたい場合や、複数のマシンで同じ設定をご利用になりたい場合など、様々な状況で役立ちます。

なお、「レジストリファイルの設定をインポート」というオプションはありません。
作成したレジストリファイルをダブルクリックすることで、「レジストリファイルに設定をエクスポート」で保存した設定が読み込まれます。
ダブルクリックすると、「…内の情報をレジストリに追加しますか？」という確認画面が出てきますので、「はい」を選択して下さい。

設定情報のエクスポートの詳細につきましては、簡易マニュアル「設定情報の保存・読み込み」をご参照下さい。

なお、WinSyslog の設定情報は、下記のレジストリキーに保存されております；
32bit版：HKEY_LOCAL_MACHINE\SOFTWARE\Adiscon\WinSyslog
64bit版：HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Adiscon\WinSyslog
レジストリエディタでもエクスポートは可能です。

■ レジストリファイル（バイナリ）に設定をインポート（エクスポート）する
バイナリフォーマットの設定情報エクスポートは、特別な場合（開発元から送付の依頼が来ない限り）使用しないでください。

■ XML形式による設定情報のエクスポート・インポート （従来の設定クライアント）
XML形式で設定情報の保存（エクスポート）・読み込み（インポート）を行うことも可能です。
「コンピュータ」メニューの「XMLファイルへ設定をエクスポート」では、全てのデータ（ライセンス登録を含む）がエクスポートされます。

▲サービスの補助メニュー

もしも、サービスだけ、またはルールセットだけをエクスポートしたい場合には、サービスの補助メニュー（右クリックすると表示される）で「XMLファイルのエクスポート」を実行してください。（上図参照）

ルールセットの場合にも、同様にルールセットの補助メニューから「XMLファイルのエクスポート」を実行してください。

TOPへ

インタラクティブ Syslog ビューアは、Syslog データを簡単に表示させるためのツールです。
EventReporterやWinSyslogから転送された Syslog メッセージを受信し、表示・確認することができるので、監視マシンで起こっていることをリアルタイムに把握することができます。 

＜機能＞

■ 早くて簡単なSyslog表示
Syslogビューアにより、Syslogメッセージの表示・確認が簡単に行えます。従って、監視システムで起こっている問題をより早く発見し、対処することも可能となります。

■ データのエクスポート
受信したデータのうち必要なものだけを選択し、エクスポートすることができます。
データは、テキストファイル、または CSVファイルとして保存できます。

■ データベースの読み込み
データベースビュー機能により、ODBC経由で指定したデータベースの内容を表示させることができます。
このデータベースビュー機能では、フィルタ設定を行えます。
それにより、テキストを指定して対象データのみハイライト表示させたり、ファシリティやプライオリティを指定して、対象データのみを表示させたりすることも可能です。  

＜システム必要条件＞

インタラクティブ Syslog ビューア の必要条件は、以下のとおりです；

・Windows 2000、XP、Vista など Windows NT ベースのOS上で動作します
・インタラクティブ Syslog ビューアを起動するには .NET Framework 2.0（または、それ以降のバージョン） をインストールする必要があります
・32MB RAM 以上のメモリが必要です

＜インタラクティブ Syslog ビューアの役割＞
インタラクティブ Syslog ビューアは、WinSyslog のアドオンツールです。 （インタラクティブ Syslog サーバーの後継ツールです） このツールは、Syslogメッセージのリアルタイム表示を目的として設計されたものなので（継続してシステムを監視するよう設計されたものではありません）、システムの監視には、WinSyslog をご利用ください。

＜インタラクティブ Syslog ビューアの起動＞
インタラクティブ Syslog ビューアを起動するには、スタートメニューのWinSyslog配下のInterActive SyslogViewerアイコンをクリックしてください。

コマンドプロンプトからも起動可能です；

・コマンドプロンプトを起動します
・WinSyslogがインストールされているドライブ・ディレクトリに変更します
・InteractiveSyslogViewer.exe と入力しエンターキーを押します

インタラクティブ Syslog ビューアの概要やマニュアルにつきましては、こちら をご覧ください。
　

WinSyslogは簡単に操作でき、効果的な製品です。

この章においては、WinSyslog の設定方法についてご説明します。

WinSyslogの最も重要な部分であるサービスは、一旦設定されるとバックグランドで動作します。
そして、それはユーザーの操作の必要がありません。

従って、この章では、WinSyslog設定クライアントに焦点を当ててご説明します。
クライアントは、サービスの設定を行うために使用されます。

WinSyslog設定クライアントを起動するには、スタートメニューのWinSyslogのフォルダにあるアイコンをクリックします。すると、下図のようなウィンドウが現れます。:

▲ WinSyslog 設定クライアント（従来のクライアント）

設定クライアント（「クライアント」）には、2つの要素があります。
左側には、WinSyslog システムのそれぞれの要素を選択するツリー表示があります。
右側には、ツリー表示で選択されたパラメーターが表示されます。

ツリー表示には、トップに「全体/デフォルト 」・「テンプレート」・「サービス」・「ルールセット」の4つの要素があります。 

「全体/デフォルト」では、基本的な操作上のパラメーターの設定とライセンス情報の登録を行います。

「テンプレート」では、デフォルト値を設定します。（よく使用する値を入力することをお勧めします）
ここでは、特殊なインスタンス（例）は決定しません。
デフォルト値は、実際の設定で個別のサービスやアクションの変更（上書き）することが出来ます。

「サービス」のツリー表示には、設定されたサービスとそのパラメーターがあります。
WinSyslog には、「Syslogサーバー」、「ハートビート」、「MoniorWare Echo Reply」、「SNMPトラップ受信」、「SETPサーバー（エンタープライズエディションのみ対応）」の5つのサービスを作成できます。
サービスの作成数に制限はありませんが、同じ設定内容のサービスは、複数稼動させることはできません。同じ種類のサービスを複数作成する場合には、ポートの衝突を避けるように設定を行って下さい。

Syslogサーバーサービスならば、同じポート（例：514）を使用しているがプロトコルタイプが違うもの、違うポート（例：10514）を使用しているものを設定すれば、同じ種類のサービスを同一システム上で３つ作成し、稼動させることも可能です。

もしも、同じポートで同じプロトコルを設定したSyslogサービスが存在する場合には、複数のSyslogサービスのインスタンスが実行されているという内容のエラーがWindowsのイベントログに記録されます。

例として、以下のような エラーがイベントログに記録されます。

理論的には、数百ほどのサービスを追加できますが、オペレーティングシステムのリソースや取り扱いについての観点から、最大でも20から30までのサービスに数を制限することをお勧めします。
もちろん、この制限より多くのサービスが有効である場合もあります。
WinSyslog自体は、サービスの作成数に制限はありません。
数多くのサービスを必要とし、ハードウェアがその処理に耐えうる場合は、数の制限は必要ありません。

実際のパラメーターは、サービスの種類に左右されます。
サービスの有効化・無効化は全てのサービスに共通です。
サービスの有効化によって、サービスは機能します。無効化は、サービスの設定がされていても、それを実行しません。それにより、削除をしなくても簡単にサービスを一時的に使用不能にすることができます。

同様に、右側の設定ダイアログの下にある「使用するルールセット」も、サービスの種類に関係なく共通のものです。どのサービスに対して、どのルールを実行するのかをここで指定します。

新しくサービスを作成する場合には、「サービス」を右クリックして下さい。
それから、「サービスの追加」を選択し、さらにポップアップメニューからサービスの種類を選択します。すると、ウィザードが開始されます。

 サービスを削除したい場合は、その対象のサービスを右クリックし、「サービスの削除」を選択します。サービスを削除した場合には、その設定は失われます。

一時的に削除したい場合には、「サービスの無効化」の指示を行って下さい。

 ツリー表示の最後の要素は「ルールセット」です。
ここで全てのルールセットの設定を行います。それぞれのルールセットは、完全にお互いから独立しています。
ルールセットは、サービスと組み合わせて使用します。ルールセットの配下には、ルールを作成します。さらに、ルールの下には、それに関連するアクションとフィルタの条件があります。

別途ご説明しますが、ルールは非常に重要な機能です。ルールは最上位のあるものから順に実行されます。
ルールを上や下に移動するには、移動したいルールを右クリックして「上に移動」または「下に移動」を選択してください。 下図を例に、WinSyslog で Syslog メッセージが処理される流れを大まかにご説明します：

例として、WinSyslog で受信したSyslog メッセージをログファイルに書き込む場合、Syslogメッセージは下記のように処理されます：

1．    SyslogサーバーサービスでSyslogメッセージを受信
（Syslogメッセージ送信側と受信側で通信の設定を合わせてください）

2．    サービスの「使用するルールセット」で指定されたルールセットへメッセージが渡されます

3．    ルールセットのルール（複数ある場合には上にあるものから順に）に渡されます

4．    ルール内のフィルタの条件を適用

5．    フィルタ条件に合致したメッセージに対して、その配下にあるアクションが実行されます
（フィルタが設定されていない場合には、全てのメッセージがログファイルに書き込まれます）

▲ 上記例の設定画面

TOPへ

試用期間（30日間）終了後、WinSyslog を継続して使用するには、ライセンス登録をして頂く必要があります。ライセンス情報は、ご購入後にメール送付させて頂きます。
（図1は EventReporter のライセンス情報でございますが、WinSyslog も同じ形式のものをお届けいたします）

▲図1 ライセンス情報のサンプル（一部抜粋）

 ライセンス情報メールにある「ユーザー登録名」と「ユーザー登録番号」を設定クライアントの「ライセンス」で入力・保存することで製品版として動作するようになります。 （図2、図3 参照）
登録後は、WinSyslog サービスを再起動してください。

▲図２ ライセンス登録画面（従来の設定クライアント）

▲ 図3 ライセンス登録画面（新しい設定クライアント）

正常に登録されると、アプリケーションログにイベントが出力されます。（例 / ID：118、詳細：EventReporter Basic is running in registered mode･･･）

▲ライセンス登録画面 （従来の設定クライアント）

また、「？」にカーソルを合わせると、上図のように登録されたライセンス情報が表示されます。
ただし、こちらは従来のクライアントのみの機能となります。

■ユーザー登録名  
ユーザー登録名は、お客さま自身でお決め頂けます。
（ユーザー登録名は、ご注文時にライセンス申込書《2) ユーザー登録名 の箇所》にご記入頂きます。）

会社名（学校名）を登録名にお使い頂いても良いですし、独自の登録名を選択して頂くことも可能です。
ですが、セキュリティを考慮してよく使われる文字列は Adiscon 社により認証されない場合がございます。 ライセンス発行後は、登録名の変更はできませんので、ご注意ください。

■ユーザー登録番号
この番号は、ご注文後 Adiscon 社によって発行されます。（ユーザー登録名に対して、固有のユーザー登録番号が発行されます。）
ユーザー登録名とユーザー登録番号がライセンスキーとなり、これらをEventReporter クライアントにてご登録頂くことで、製品版として試用期間終了後も継続して動作するようになります。

ライセンス登録では、必ず正しい登録番号を入力するようにしてください。
ご登録内容に間違いがある場合には、製品版として登録されません。

ユーザー登録番号のペースト機能につきましては、以下のURL をご参照下さい：
http://www.port139.co.jp/faq_new_common.htm#Q-25

TOPへ

設定クライアントの「ファイル」内にある「オプション」につきまして、以下 ご説明します。

■全体オプション

■ 言語を選択してください
設定クライアントで表示させる言語をここで指定します。

■ 設定ツールバーの有効化
ここを有効にすると、クライアント右側上部に開いた設定ウィンドウがツールバーとして表示されるようになります。（下図参照）ツールバーで特定の設定を選択すると、それが最前面に表示されます。
この機能は、「設定ウィンドウを自動的に閉じる」が無効の際に役立ちます。

■ 設定ウィンドウを自動的に閉じる
ここを有効にすると、一つの設定が終わり、別の設定に移るときに、前の設定ウィンドウが自動的に閉じるようになります。

■ 他の設定ウィンドウを開いた場合に設定を自動保存する
ここを有効にすると、設定中に別のウィンドウを開いた際、それまで設定していた未保存のデータが自動的に保存されるようになります。

■その他オプション

■ サービスを削除する前に警告する
ここを有効にすると、サービスを削除する際に表示される警告画面が表示されなくなります。

■ 自動保存の警告メッセージを表示
ここを有効にすると、設定ウィンドウを切り替える際、未保存のデータがあることを警告する画面が表示されなくなります。

■ SyslogプロトコルをTCPに変更した場合、自動的にSyslogポートを1468に変更する
ここを有効にすると、WinSyslog の 「Syslogサーバ」サービスで受信プロトコルをTCPに変更した際、ポート番号を1468に変更する警告画面が表示されるようになります。

■ SSLを有効にすると、SETPポートは自動的に4433に変更されます
ここを有効にすると、SETPでSSLを有効にした際にポート番号を変更する警告画面が表示されるようになります。

■ 最終IDまたはファイル名を初期化した際の警告を抑止する
ここを有効にすると、最終IDまたはファイル名を初期化した際の警告画面が表示されなくなります。

■ リモートによるイベントログの監視に関する情報を有効にする
ここを有効にすると、イベントログの監視サービスでリモートのイベントログを設定した際の警告画面が表示されなくなります。

■ テンプレートの編集に関する通知を表示しない
ここを有効にすると、テンプレート（各設定のデフォルト値）を編集する際の警告画面が表示されなくなります。

■レジストリパスオプション

設定を読み込むレジストリのパスを変更することができます。

設定クライアントの「ファイル」内にある「オプション」につきまして、以下 ご説明します。

<全般>

■ 言語を選択
設定クライアントの表示言語をここで指定します。
デフォルトは英語になっています。

■ サービスの削除時に警告を表示させない
サービスを削除する際の確認メッセージを表示させたくない場合には、ここを有効にしてください。
無効の時は、削除時に「サービスを削除してもよろしいでしょうか？」という確認メッセージが表示されます。

■ オートセーブの警告を表示させない
設定変更後、保存せずに別の設定に移るときに表示される確認メッセージを表示させたくない場合には、ここを有効にしてください。

■ 言語変更時にリロード確認の画面を表示させる
設定クライアントの表示言語変更時の確認画面を表示させたくない場合には、ここを無効にしてください。

<設定の読み込み>

■ レジストリから設定を読み込む
ここで指定したレジストリキーから設定を読み込みます。（デフォルト）

■ ファイルから設定を読み込む
ここで指定したファイル（.cfg ファイル）から設定を読み込ませることも可能です。

全体オプション                                                                     

▲新クライアント 「全体」オプション

▲従来のクライアント 「全体」オプション

■処理の優先レベル
ここでは、WinSyslog の処理の優先レベルを設定できます。 

■キューのリミット
ここでは、WinSyslog の処理時における キューの最大値が設定できます。
デフォルトは、200000 です。「0」にすると、無制限になります。 

■Customer ID
顧客によって Customer ID を変更したい場合には、ここで 整数値を入力します。

例えば、顧客のサーバを監視する際に、会社ごとに違うIDを設定することが可能です。
サーバ A と B を監視しているとして、5台あるサーバ A は Customer ID を １ 、2台あるサーバ B の Customer ID を 2 といった具合で設定することが可能です。
サーバ A と B のサーバ名が同じ場合でも、Customer ID を設定すれば別の定義を行うことが可能です。

■System ID
System ID を変更したい場合には、ここで整数値を入力します。 

■MIBS の場所
ここでは、MIBｓ の場所を指定します。
パスを指定するか、またはブラウザより選択してください。

■基準時刻
ここでは、ファイルログやデータベースログ、Eメール送信など、WinSyslog 全体で使用するタイムスタンプの設定を行えます。UTC、またはローカルタイムの指定を行えない設定項目に対しても、ここで選択したタイムスタンプが設定されます。
ただし、プロパティ値（%timegenerated% や %timereported%）の基準時刻には、この設定値は反映されません。

■サービスの停止からエージェントを保護する
サービスは、未処理のイベントをインメモリ キューに保存します。サービスが停止すると、このインメモリ キューは、空になります。この場合、未処理イベントは消失してしまいます。

このオプションを有効にすると、サービスの停止前に全てのイベントが確実に処理されます。
しかし、その処理中は、サービスがハングアップしたかのような状態になります。
このオプションは、大きな インメモリ キューがある場合には、有効なケースとなります。

■アプリケーションのイベントログに警告を書き込む
ここを有効にすると、Windows アプリケーション イベントログへ警告を記録できるようになります。 

■日本語システムに対する特別なUnicode変換
日本語のシステムにおいては、文字の処理方法が異なります。
日本語文字列がメッセージに含まれる場合、以下のように設定してください。
WinSyslog 8をご利用の場合には、ここを有効にしてください。
それ以外のバージョンでは無効のままご利用ください。

エンジンに関して                                                                                  

▲新クライアント 「エンジン」オプション

▲従来のクライアント 「エンジン」オプション

＜アクションのオプション＞
■ 失敗したアクションをリトライする （アクションの失敗を再試行する）
この機能を有効にすると、サービスは「リトライ（再試行 ）の回数」の設定値に達するまで、失敗したアクションを実行します。

なお、エラーログは最後の失敗に対してのみイベントログ（ID114）に記録 されます。
再試行中のエラーは、EventReporter のデバッグログ（エラー＆警告）に記録されます。

＜ルールエンジンのオプション＞
■ アクションの実行に失敗した時、ルール内の別のアクションの実行を停止する
   （一つのルールが失敗するとき、ルールの実行を中止する）
ここを有効にすると、ルールに定義されているアクションのうちの一つが失敗した場合に、そのルールの実行を中止します。

ここが無効になっている場合には、ルール内に複数あるアクションのうち一つが失敗してもルールは停止せず、それ以下に定義されているアクションが実行されます。

■ DNSキャッシュを有効にする （内部のDNSキャッシュを有効にする）
DNSキャッシュは、逆引きDNSの検索に使用します。
逆引き検索は、IPアドレスをコンピュータ名に変換するために使用され、これは「ホスト名解決」アクションで実行されます。検索を実行する際、毎回DNSは照会されるため、比較的システムへの負荷が大きくなってしまいます。それで、検索結果をキャッシュに入れます。検索が行われるたびに、システムは、まずローカルキャッシュに既に検索結果が入っていないかどうかをチェックします。検索結果がない場合、DNSクエリが実行され、その結果がキャッシュに入れられます。それにより、ホスト名の解決を実行する速度が格段に上がります。

しかし、コンピュータ名やIPアドレスは変更される場合もあります。その場合、DNSは更新されます。もし、DNSを常にキャッシュに入れ、そこから検索するようにしていると、変更された情報を得ることができません。これを回避するために、DNS名をキャッシュに入れる時間に制限を設けました。時間切れとなったDNS名は、キャッシュ内にレコードが存在していないと認識され、新たに検索されるようになります。

また、キャッシュレコードは、システムメモリを使います。数多く名前解決をしたい場合には、より多くのメモリを割り当てる必要が出てくるでしょう。これを解決するために、キャッシュに入れるDNSレコード数を設定できるようにしました。この設定値に達すると、それ以降は新しくキャッシュレコードは割り当てられなくなります。

＜DNSキャッシュオプション＞
■ DNS名をキャッシュに入れる時間
ここでは、DNS名をキャッシュに入れる制限時間を設定します。
名前解決に問題が生じる可能性がありますので、ここでは高すぎる値を設定しないようにして下さい。
24時間以上の値を設定することは、お奨めできません。

■ キャッシュに入れるレコード数
ここでは、キャッシュに入れるレコードの最大値を設定します。
名前解決をするレコード数が多くなると、システムが割り当てるメモリも大きくなります。ここで大きな値を設定しても名前解決を実行するホストの数が少ない場合には、キャッシュは大きくなりません。

しかし、数多くのホストの名前解決を行なう場合には、キャッシュに入れるレコード数に上限を設けることをお奨めします。ですが、その場合、頻繁にDNSの問い合わせが行なわれます。

1つのキャッシュレコードにつき およそ1〜2KBとして数値を設定して下さい。

■ インターネットプロトコルタイプ （名前解決プロトコル）
ここでは、名前解決の際に IPv4、IPｖ6 のうちどちらを優先するかを指定します。

＜リソース ライブラリキャッシュ オプション＞
■ ライブラリをキャッシュに入れる時間
このオプションは、EventReporter のイベントログの監視機能において特に役立つ機能です。
同じイベントが何度も処理される状況では、このオプションを使用することで、パフォーマンスが上がることが期待できます。
デフォルトでは、全てのライブラリが 30分間キャッシュに入れられます。

デバッグ オプション                                                                                  

▲新クライアント「デバッグ」オプション

▲従来のクライアント「デバッグ」オプション

ここでは、ルールベースのデバッグを行うことが可能です。
複雑なルールベースの場合は特に、その処理が実行されている間 WinSyslog が内部で何を行っているかを知る必要があります。デバッグのログにより WinSyslog の内部での働きを知る事ができます。

ルールベースのテストとは別に、このデバッグのログは技術的なお問い合わせの際に役に立ちます。
状況によっては、お問い合わせ時に問題を解決するため、特定のレベルに設定を変更していただく場合がございます。

■ デバッグ出力を有効にする（必要時のみ）
（ファイルへのデバッグ出力を有効にする）
ここを有効にすると、デバッグのログが可能になり、サービスが稼動する際に書き込まれます。
＊パフォーマンスを考慮して、普段は ここを無効のままにして置いてください

■ ファイルパス（ファイル・パス名）
書き込みを行うログファイルの完全な名前を設定します。
ドライブを含めた完全なパス名を指定するようにして下さい。
ファイルまたはパス名だけを入力すると、その入力情報はローカルのサービスのデフォルト・ディレクトリを参照します。整合性を考慮して、ドライブを含めた完全で適したファイル名を指定するようにして下さい。

＜記録される内容＞

■ エラー警告を出力（エラー＆警告）
ここを有効にすると、エラーと警告がデバッグログへ出力されます。 

■ ルールフィルタを出力（ルール＆フィルタエンジン）
ここを有効にすると、ルールとフィルタエンジンがデバッグログへ出力されます。 

■ 最小 デバッグ出力
ここを有効にすると、最小のデバッグログが出力されます。 

■ 情報 デバッグ出力
ここを有効にすると、情報のデバッグログが出力されます。 

■ Ultra Verbose デバッグ出力
ここを有効にすると、詳細なデバッグログが出力されます。 

■ 循環ログを使用
デバッグログに循環ログ機能が追加されました。
この機能を有効にすると、指定頂いたログサイズ・ログの本数でログを循環させることが可能です。

キュー管理 オプション                                                                            

▲新クライアント「キュー管理」オプション

▲従来のクライアント「キュー管理」オプション

■ ディスクキャッシュのキュー管理を有効にする
この機能により、項目（Items）をディスク（指定したファイル）の内部キューに蓄えて置くことが可能となります。
この機能は、確実に必要な場合のみ使用するようにしてください。
ご利用のマシンのハードディスクの速度により、アクションの処理速度が下がる場合があります。最悪の場合には、マシンがIO読み込みを実行できなくなり、キューがいっぱいになってしまいます。ディクスキャッシュは、受信した Syslog メッセージで未処理のものを確実に処理させたい場合の追加機能です。

ディスクキャッシュでは、イベントログの監視サービスのようにアクションが成功している間、継続して動作するタイプのサービスのインフォメーションユニットはキャッシュに入れません。Syslog サーバーサービスのような、その他全てのデータがキャッシュに入れられます。もしも、サービスやサーバーがダウンした時、次回のサービス起動時にキューが自動的に読み込まれるようになります。従って、キューにあるメッセージは消失されません。ただし、キャッシュに入れる処理中にダウンした場合には、そのデータは残りません。

■ ファイルパス（ファイル・パス名）
キューファイルの保存場所をここで指定できます。

■ キューファイルサイズ （静的）
キューのサイズをここで指定します。
システムメモリを超えたサイズのキューファイルサイズは設定しないでください。システムメモリの合計よりも小さいサイズ（512MB）でご利用になることをおすすめします。最大値は2048MBに設定されています。
キューファイルのサイズを変更すると、次回のサービス起動時に新たにキューファイルが作成されます。
それまで作成されていたキューファイルの内容は新しいファイルに移行されませんので、サイズ変更後はそれまでのキューがきちんと処理されたかどうかを確認してください。
また、一般的にサービスを停止した際にも同様にそれまでのキューが処理されます。

＜キューのリミット（全体オプション）＞
ディスクキャッシュのキュー管理を有効にした場合、全体オプションの「キューのリミット」が重要になります。キューファイルのサイズがどんなに大きくても、ここでの値がキューに保存されるアイテムの最大値になります。

＜Race conditions＞
サーバーやコンピュータがクラッシュした際、たいていの場合はファイルシステム、またはキューファイルが壊れてしまいます。その場合は、サービスの起動時に壊れたファイルを探し出し、可能であればキャッシュされたキューを初期化し、キューファイルをリセットします。 

■ 処理ポインタ（ポインタの処理）
処理ポインタをここで指定します。（ディスクキャッシュのどの位置にポインタが来るかを指定します） 

■ 保存ポインタ（ポインタの保存）
このポインタは、前回どこの位置で項目が保存されたかを表します。 

＜キュー管理 オプション＞

■ワーカスレッドの数
WinSyslog がキューの処理に使用しているワーカースレッドの数をここで指定します。

TOPへ

サービスについて
WinSyslog サービスは、Syslogメッセージの受信やSNMPトラップの受信などを行います。

サービスの作成数に制限はありませんが、同じ設定内容（使用ポート・プロトコル）のサービスを複数稼動させることはできません。（その場合、正常に動作しません。）

異なった設定内容であれば、同じタイプのサービスを複数稼動させることが可能です。
ただし、サービスを一つも設定しなければ、WinSyslog は全く機能しません。その際には、イベントログに以下のようなエラーが記録されます。

「サービス」と「サービスのデフォルト」が取り違われる場合もありますが、「サービスのデフォルト」は、予めサービスの設定を定義するもので、それ自体は何も実行しません。（従来の設定クライアントのみ）

ここでは、Syslogサーバーサービス の設定を行います。
このサービスを設定することで、Syslog 形式のメッセージを収集できます。

▲新クライアント「Syslogサーバ」サービス

▲従来のクライアント「Syslogサーバ」サービス

■ インターネット プロトコルタイプ（IPタイプ）

受信するSyslog が IPv4 なのか IPv6 なのかを指定します。
IPv4 と IPv6 のデバイスが混在する場合、Syslog サーバサービスをIPv4 用、IPv6用として分けて作成･設定しなければならないので、ご注意ください。

■ プロトコルタイプ  
Syslog メッセージは、UDP または TCP、RFC3195ベースのTCP で受信されます。
一つのサービスで一つのプロトコルを使用できます。
デフォルトは、UDP となっております。
Syslog サーバーは、UDP以外にもTCP、そしてRFC3195 RAWスタンダードを使用したTCP で Syslog メッセージを受信することが可能です。
＊「TCP」、「RFC3195（TCP）」は、プロフェッショナル、エンタープライズエディションの限定機能となります

■ IPアドレス
SyslogサーバのIPアドレスを指定できます。（ここで指定したアドレスを宛先としたSyslogのみ処理されます）
この機能は、マルチホームの環境で別のサービスを別のIPアドレスで設定したい場合に役立ちます。
注）デフォルトとして設定されている「0.0.0.0」はすべて（ANY）のIPアドレスを意味します

■ ポート番号（使用ポート）
syslog サーバーが使用するポート番号を指定します。一般的な値は514です。
変更しなければいけない理由が明確である場合のみ、変更を行って下さい。
そのような必要性は、概してセキュリティに対する懸念から生じます。
＊ポートの変更を行った場合は、報告を行っているデバイス全ての設定をその標準でないポートを使用するように変更しなければなりません。

<全体>
 ■ オリジナルのメッセージ・タイムスタンプを使用  （RFC3164）
ここをチェックすると、WinSyslog はメッセージ受信の時刻の代わりに、Syslog メッセージ内のタイムスタンプを使用します。これは、Syslog RFC3164に対応しています。
チェックしない場合は、ローカルのシステム時刻を使用します。

メッセージ内のタイムスタンプを使用することには、いくらかの欠点もあります。
タイムゾーンの情報を持たないことなどが挙げられます。
もしも、複数のタイムゾーンのデバイスを処理している場合は、WinSyslog の時間の記録は、ぐちゃぐちゃになってしまいます。このような場合は、メッセージ受信時のタイムスタンプを使用することをお勧めします。

■ ホスト名を解決する（ホスト名の解決）
ここをチェックすると、メッセージソースの IPアドレスは（DNSによって）ホスト名の解決が実行されます。
チェックしない場合は、単にIPアドレスが使用されます。
 “Syslog メッセージからソース・システムを取り出す” 設定が有効になっている場合には、この設定は機能しませんので、ご注意ください。この場合には、そのメッセージは常に syslog メッセージから取り出されます。

■ Syslogメッセージからソース・システムを取り出す  
このボックス がチェックされる場合、ソースシステムの名前または IPアドレスは（RFC 3164による） syslog メッセージから取り戻されます。
チェックしない場合は、それはメッセージを受信したアドレスに基づいて生成されます。

■ オリジナルのソースをプロパティに保存（新クライアント）
ここを有効にすると、オリジナル（元）のネットワークソースがプロパティ（デフォルトでは%sourceorig%）に保存されるようになります。

■ 制御文字を変換する（エスケープ制御文字）
Syslog メッセージに制御文字が含まれている場合、ここをクリックするとその文字が5バイトのシーケンスのアスキー文字IDに置換されるようになります。
例えば、ビープ音：BELの場合には、アスキーの文字コードで7となっておりますので、この機能を有効にした場合には <007> と表示されるようになります。
但し、日本語などダブルバイトの文字を使用している場合には、メッセージが壊れてしまう可能性が高いので、この機能は使用しないようにして下さい。

■ RFC3164 の構文解析を有効にする
このチェックボックスを有効にすると、RFC3164に対応した Syslog メッセージの構文解析が可能となります。
無効にすると、従来のメッセージ構文解析（Adiscon仕様）が使用されます。
RFC3164を基準にしていないメッセージを受信する際は、ここを無効にしてください。
（送信ホスト名やタイムスタンプが正常に処理されない場合には、ここを無効にしてみてください）

■ RFC5424 の構文解析を有効にする
このチェックボックスを有効にすると、RFC5424に対応した Syslog メッセージの構文解析が可能となり、RFC5424のヘッダの検出とデコードができるようになります。また、新しい Syslog プロパティが含まれるようになります。
無効にすると、従来のメッセージ構文解析（Adiscon仕様）が使用されます。
＊RFC5424は、2009年3月に発表された新しい Syslog の基準であり、現在（2010年10月）のところ、ほとんどのデバイスで対応していない状況です。
（WinSyslog と EventReporter は、RFC5424に対応しております。）
RFC5424を基準にしていないメッセージを受信する際は、ここを無効にしてください。
（送信ホスト名やタイムスタンプが正常に処理されない場合には、ここを無効にしてみてください）

■ SyslogタグにプロセスIDを追加（可能な場合）
このオプションは、[RFC5424 の構文解析を有効にする] を有効にした際に選択できます。
ここを有効にすると、Syslog タグに、プロセス名だけでなくプロセスID （pid) も追加されるようになります。

＜エンコード＞

▲新クライアント「エンコード」

▲従来のクライアント「エンコード」

■ システム デフォルト エンコード （従来のクライアントのみ）
受信する Syslog をシステムのデフォルトエンコードで処理する場合には、ここを有効にしてください。

■ メッセージのエンコードを自動検出する (UTF8, SHIFT_JIS, EUCJP)
9.1バージョンより設けられた機能です。
マルチバイト文字（日本語文字列など）を含む Syslog メッセージを処理する場合には、ここを有効にしてください。

■ メッセージの文字コードを全てUTF-8として処理する
BOM を含まないUTF-8 の Syslog メッセージを受信する際は、ここを有効にしてください。
ただし、全てのメッセージがUTF-8 として扱われますので、他の文字コードで送信されてきた Syslog は正しく処理されない可能性がありますので、ご注意ください。

＜UDPオプション＞

▲新クライアント「UDPオプション」

▲従来のクライアント「UDPオプション」

■  UDPマルチキャスト グループからの受信を有効にする
 このオプションを有効にすることで、マルチキャストIPアドレス（例；224.0.0.1）からの Syslog メッセージが受信できるようになります。

＜TCPオプション＞

▲新クライアント「TCPオプション」

▲従来のクライアント「TCPオプション」

■ セッションタイムアウト
ここでは、最後のパケットが送信された後、どれだけの時間TCPのセッションをオープンしておくのかを設定します。プルダウンメニューから値（1秒〜1日）を選択するか、「カスタム」を選択し、任意の値（ミリ秒で2147483646が最大値）を入力してください。カスタムで0を入力すると、セッションタイムアウトは無効になります。

■ メッセージを以下のシーケンスによって分ける
ここを有効にすると、受信メッセージは以下の設定で分けることができます；

メッセージ分離のシーケンス：
ここで入力したシーケンスでメッセージを分けます。デフォルトは「\r\n」（改行コード）に設定されております。

メッセージ完了タイムアウト：
ここではメッセージ完了の時間を設定します。ここで設定した時間内に処理されなかったメッセージは、次の（新しい）メッセージとして分けて処理されます。
プルダウンメニューから値（1秒〜1日）を選択するか、「カスタム」を選択し、任意の値（ミリ秒で2147483646が最大値）を入力してください。

＜Syslog TLS＞

▲新クライアント「Syslog TLS」

▲従来のクライアント「Syslog TLS」

■ SSL/TLSを使用
（SSLの有効化／TLSの暗号化：）
ここを有効にすると、SSLに対応していないデバイス（クライアント）からのメッセージを受信できなくなります。

■ TLSモード
次のモードから選択できます；

・匿名認証
デフォルトでは、このモードになっています。
このモードでは、どんな証明書でも（証明書がない場合でも）受信できます。

・ｘ509/name（証明書の確認と名前認証）
このモードを使用すると、「許可されたPeer」でクライアントの証明書の subject がチェックされるようになります。 それによりセキュリティで保護された接続のみ許可されるようになります。

・ｘ509/fingerprint（証明書とフィンガプリント）
このモードは、SHA1フィンガプリント（指紋）を作成し、「許可されたPeer」のフィンガプリントと比較します。
デバッグログを取得すれば、許可されなかったクライアント証明書のフィンガプリントを確認することができます。

・x509/certvalid（証明書の確認のみ）
クライアント証明書が有効でありさえすれば接続が許可されます。

■ 共通の CA PEM の選択
ここでは、CA（Certificate Authority；認証局）を指定します。
Syslog を送信する側・受信する側で同じCAを使用しなければなりません。

■ PEM の証明書を選択
クライアントの証明書（PEM フォーマット）を選択します。

■ PEMの鍵を選択
クライアント証明書の鍵（キーファイル）を選択します。

▲従来のクライアント「許可されたPeer」

■ 許可されたPeer
ここでは、許可されたPeer を入力します。
ｘ509／name を使用する場合、証明書の subject を入力します。
例えば、証明書の subject がCN = secure.syslog.msg である場合、secure.syslog.msg を許可された Peer として入力します。
ｘ509/fingerprint を使用する場合、ここでは許可された SHA1指紋（fingerprint）を入力します。
指紋（fingerprint）は、OpenSSLツールで生成することもできますが、デバッグログファイルから入手することもできます。
以下は、フォーマット（RFC5425参照）のサンプルです；
SHA1:2C:CA:F9:19:B8:F5:6C:37:BF:30:59:64:D5:9A:8A:B2:79:9D:77:A0

■ ルールセットを選択（使用するルールセット）
syslog サーバーのサービスで使用されるルールセット名を選択します。
当然のことながら、そのルールセット名は、有効でなければなりません。

TOPへ

ここでは、SETPサーバーサービスを設定します。
※このサービスは、エンタープライズ エディションのみご利用可能となっております※

SETPサーバーは、他システムからイベントを MonitorWare（弊社では扱っておりません） 製品ライン内で確実に受信するのに用いられます。ここには、SETPが送り主からオリジナルのメッセージを受け取って、送り側で設定した設定を正確に使用するための設定が設けられています。
変更は、SETPサーバー側で発生しません; メッセージ・フォーマットに対して設定すべき値はありません。

▲新クライアント「SETPサーバ」サービス

▲従来のクライアント「SETPサーバ」サービス

■ インターネットプロトコルタイプ（IPタイプ）
受信するSyslog が IPv4 なのか IPv6 なのかを指定します。
IPv4 と IPv6 のデバイスが混在する場合、Syslog サーバサービスをIPv4 用、IPv6用として分けて作成･設定しなければならないので、ご注意ください。

■ リスナーポート（使用ポート ）
SETPサーバーが使用するポートを指定します。デフォルトは、5432です。
変更しなければいけない理由が明確である場合のみ、変更を行って下さい。
そのような必要性は、概してセキュリティに対する懸念から生じます。
SETPサーバーとの通信には、TCPが使用されます。
ポートの変更を行った場合は、送信側の設定を送信側と合わせるように変更しなければなりません。

■ リスナーIPアドレス
SETPサーバーサービスでも、Syslogサーバーサービスと同様に特定のIPアドレスで処理させることが可能となりました。
この機能は、マルチホームの環境で別のサービスを別のIPアドレスで設定したい場合に役立ちます。
注）デフォルトとして設定されている「0.0.0.0」はすべて（ANY）のIPアドレスを意味します

■ セッションタイムアウト
サーバー側のセッションがオープン状態である場合の最大の待ち時間を指定します。

■ SSL/TSLを使用（SSLの有効化／TLSの暗号化）
ここを有効にした場合、SSL、またはTLS、STEPサーバーに接続することが出来ます。
ただし、SSLに対応していないSETPサーバーには接続できなくなります。

 ■ データの圧縮にzＬｉｂ圧縮を使用する
ここを有効にすると、WinSyslogはSETP送信により送信されたｚLib圧縮データを解凍します。今まで通り、通常のデータも受信することが可能です、ｚLib圧縮は、WAN環境において通信量を減少させることに役立ちます。

■ ルールのエラーを送信者に通知する
ここを有効にすると、アクションの結果をSETPメッセージの送信者へ通知されるようになります。

例えば、イベントログの監視を実行していて、これらのイベントをSETPで送信、一方でデータベースへ収集した全てのイベントを書き込むよう設定しているとします。

もしも、データベースがオフラインの場合、イベントの書き込みは実行できないので、SETPサーバーは、アクションの実行に失敗したという内容のメッセージを最後のメッセージとして送信し、イベントログに ID：1005のエラーを作成します。（その後、このアクションが成功した場合には、ID：1012のイベントログが記録されます。）送信者は、それから停止して、再度イベントの送信を試みます。

これは、SETPがTCPと同じようにデータ転送を確実にするためですが、さらに、アクションが成功した場合にも送信者にステータスを返信することもできます。これは、イベントログの監視サービスが再試行可能（restartable）なイベントソースだからです。同じソースでアクションが再試行するかどうかを決定するために、アクションの結果が使用されます。他のイベントソースは、違う動作をします。例えば、Syslogサーバーサービスは、失敗したアクションを再試行しません。これは、Syslogメッセージが消失する可能性があるという性質によるものです。

■ ルールセットを選択（使用するルールセット ）
SETPサーバーのサービスで使用されるルールセット名を選択します。
当然のことながら、そのルールセット名は、有効でなければなりません。

TOPへ

ハートビートサービスを使用することで、WinSyslog サービスが稼動しているかどうかを確認することができます。
ハートビートクロックで設定した時間ごとにハートビートメッセージが作成されます。
ハートビートメッセージは、Syslog メッセージと同様にメール送信やSyslog転送など、お好みのアクションを組み合わせ、通知させることが可能です。
（このサービスの「使用するルールセット」で選択したルールセット内のアクションで処理されます）

＊ハートビートメッセージが指定の時間に届かない場合には、WinSyslogで何かトラブルが起きているか、動作が停止しているということが疑われます。

▲新クライアント「ハートビート」サービス

▲従来のクライアント「ハートビート」サービス

■ハートビートで送信するメッセージ （ハートビート中に受信するメッセージ）
ここで設定したメッセージがハートビートからのログに記録されます。
入力する内容は、どんなものでも構いません。

■ハートビート クロック（スリープタイム）  
ハートビートメッセージを生成する間隔を指定します。（ミリ秒で設定します）
ハートビートメッセージを受信するマシンのスペック等を考慮し、値を設定してください。
重い負荷がかかっている時は、メッセージの生成間隔が設定より遅くなる場合もあります。

＜メッセージに付加する値＞
■Syslogファシリティ  
ハートビートメッセージに割り当てられる syslog ファシリティ。
メッセージを syslog サーバに転送する際に役立ちます。

■Syslogプライオリティ  
ハートビートメッセージに割り当てられる syslog プライオリティ。
メッセージを syslog サーバに転送する際に役立ちます。

■Syslog タグ値  
ハートビートメッセージに割り当てられる syslog タグ値。
メッセージを syslog サーバに転送する際に役立ちます。

■リソースID  
ハートビートメッセージに割り当てられるリソース ID。
メッセージを syslog サーバに転送する際に役立ちます。 

■ルールセットを選択（使用するルールセット）
このサービスのために使用されるルールセット名。
ルールセット名は、有効でなければなりません。

SNMPトラップ受信によって、SNMPメッセージを受信することができます。

トラップは、別のプロトコル（SNMP）においてSyslogメッセージのような役割を果たすものです。
デバイスが送信すべき情報がある場合などにトラップが生成されます。その情報には、バージョンやコミュニティなどの標準的な項目も含まれます。

▲新クライアント「SNMPトラップ受信」サービス

▲従来のクライアント「SNMPトラップ受信」サービス

■ インターネット プロトコルタイプ（IPタイプ）
受信する SNMP トラップが IPv4 なのか IPv6 なのかを指定します。
IPv4 と IPv6 のデバイスが混在する場合、SNMPトラップ受信サービスをIPv4 用、IPv6用として分けて作成･設定しなければならないので、ご注意ください。

■ プロトコルタイプ  
受信する SNMP トラップのプロトコルを指定します。UDP、TCP のどちらかを選択してください。

■ ポート  
SNMPリスナーが使用するポートを指定します。
確信がない場合には、デフォルトのポートである162のままにして置いて下さい。

■ SNMPバージョン  
ここでは、SNMPバージョンを限定します。設定可能な値は、下記のとおりです：

1. SNMP 全てのバージョン
2. SNMPバージョン1のみ
3. SNMPバージョン2cのみ

■ Mib名を完全に解決する（ロングフォーマット）
このオプションを有効にすると、MIBブラウザにあるようにMib名が解決されるようになります。

■ 短いフォーマットを使用（最後の一部分のみ）
完全な名前解決が長く読みづらい場合には、この機能を有効にしてください。
Mib名の最後の部分だけになるようフォーマットが変更されます。
こちらは新クライアントの機能になります。

■ ルールセットを選択（使用するルールセット ）
このサービスのために使用されるルールセット名。ルールセット名は、有効でなければなりません。

この機能は、MonitorWareエージェントに関連するものです。
現在、有限会社イハラでは、MonitorWareの販売は行っておりません。

MonitorWare Echo Replyサービスは、多少変わったサービスです。
これは、単独では何のイベントも生成しません。このサービスは、MonitorWare Echo Requestサービスに受動的に対応する物です。
これらは、同時に失敗しているエージェントを見つけるのに使用されます。設定項目は、使用ポートのみで Echo Request サービスが接続するポートと同じポートである必要があります。

▲新クライアント「MonitorWare エコーリプライ」サービス

▲従来のクライアント「MonitorWare エコーリプライ」サービス

RELP リスナーサービスは、新しいプロトコルである「Reliable Event Logging Protocol」に対応しています。このプロトコルを使用することで、従来のTCP Syslog プロトコルより確実な転送が可能となります。
（このサービスでは、RELPに対応した送信元からのメッセージを受信します）

RELPプロトコルを使用すること以外は、機能的には Syslog サーバーサービスと同じような働きをします。

▲新クライアント「RELPリスナー」サービス

▲従来のクライアント「RELPリスナー」サービス

■ リスナーポート（使用ポート ）
RELP リスナー サービスで使用するポート番号をここで指定します。
デフォルトは、20514です。
この値は変更できますが、その際は、メッセージを送信している機器のポートも合わせて変更するようにしてください。

■ セッションタイムアウト
ここでは、サーバー側のセッションがオープン状態である場合の最大の待ち時間を指定します。

■ ルールセットを選択（使用するルールセット）
このサービスのために使用されるルールセット名。ルールセット名は、有効でなければなりません。

フィルタ（フィルタの条件）は、受信したログの絞込みをしたい（特定の条件に合ったログだけを処理、または破棄したい）場合に設定します。

フィルタ（フィルタの条件）は、ルールの中、アクションの上にあります。
（下図では、Default RuleSet（ルールセット）の下、さらにDefault Rule （ForwardSyslog）の下、アクションの上にあります）

▲新クライアント「フィルタ」

▲従来のクライアント「フィルタの条件」

WinSyslogで受信したログは、 フィルタ（フィルタの条件）で設定した内容（フィルタ）に一致した場合、その下で設定されたアクションにより処理されます。

フィルタ（フィルタの条件）は、必要に応じて複雑にすることが可能です。
ブール演算と条件のネスティングがサポートされています。

デフォルトでは、 上図のように「AND」のみが設けられています。
この状態では、全てのデータが「真（True）」となり、それらに対してアクションが実行されます。
（すなわち、フィルタリングされず、全てのメッセージが処理されます）

メッセージの絞込みを行わない（例えば、データベースやテキストファイルに全てのメッセージを書き込みたい場合）場合には、このデフォルトの設定のままご利用下さい。

一方、特定の条件において（メッセージを絞り込んで）アクションを実行させたい場合には、その条件によって、様々な設定を行うことができます。

TOPへ

オペレーションでは、フィルタの条件がどのように互いにリンクしているかを設定します。
以下のオペレーションを使用することが可能です。

フィルタは、各オペレーションノードの下に追加することが可能です。
全てのサービスに使用できる共通のフィルタは、数種類あります。

また、特別な種類のインフォメーション ユニットに対してのみ適用されるフィルタも存在します。
インフォメーション ユニットでマッチしない全てのフィルタは、フィルタリング処理で無視されます。
このような場合には、サービスごとに別のルールセットを作成し、関連付けするようにして下さい。

フィルタには、色々なタイプのものが存在します。
従って、それらのタイプと値を比較する方法もそれぞれ存在します。
以下のタイプが使用可能です。

以下のタイプが使用可能です。

文字列（String）
「＝」、「Not ＝」、「範囲内の一致」で別の文字列と比較されます。

番号（Number）
「＝」、「Not ＝」、「＜」、「＞」で別の番号と比較されます。

ブール演算子（Boolean）
「＝」、「Not ＝」で「真」か「偽」のいずれかと比較されます。

時間（Time）
「＝」のみで別の時間と比較されます。

全体の条件は、全体としてルールに適用します。
それは、フィルタのツリーの中で条件と共に、理論的な「AND」と組み合わせられます。

▲新クライアント「全体の条件」

▲従来のクライアント「全体の条件」

■ 検出されないフィルタをTRUEとして処理する
フィルタの条件で問い合わせたプロパティがイベントに存在しない場合、通常は「偽（False）」として処理されます。、上記のイベントを「真（True）」として処理したい場合、ここを有効にすることで可能となります。

■ 発生時のみ稼働（イベントが発生した場合のみ稼動）
これは、ある意味「最小の待ち時間」と正反対の機能と言えます。
ここでは、設定した回数だけイベントが発生しないとルールが起動しません。

この機能は、指定した時間内に、指定されただけの回数のイベントが発生しなければルールが稼動しません。これは、以前は「発生」と呼ばれていた機能を改名したものです。

■ 最小の待ち時間
このフィルタの条件は、ルールが過度に作動するのを防ぐために使用が出来ます。
（ここで設定した時間間隔で、ルールが稼動するようになります。）
＜例＞ ここで 60 と入力すれば、60秒毎にルール（アクション）が実行されます。
http://ｗｗｗ.port139.co.jp/eve92_for_web.htm#11-1 をご参照ください。

■ 選択したプロパティに関する全体の条件（プロパティに関する全体の条件）
この機能により、プロパティをベースにして全体の条件を管理することが可能となりました。
例えば、メッセージのソースをプロパティとして処理する場合、それぞれ個々のメッセージソースに対して最小の待ち時間が適用されるようになります。

TOPへ

▲新クライアント「日付の条件」

■ 常にルールを処理
ここが有効になっている時には、条件はなく、常にルールは実行されます。

■ インストール直後のみ処理
ここが有効の場合、インストール直後、処理対象のメッセージがあった際にルールが実行されます。

■ 設定した日にのみ処理
ここが有効の場合、設定した日付で、処理対象のメッセージがあった際にルールが実行されます。

TOPへ

■ソース
このフィルタの条件は、インフォメーション ユニットを作成するシステムをチェックします。
例えば、Syslogサーバの場合、これはsyslogメッセージを送っているsyslogデバイスになります。

このフィルタは、文字列で指定します。
ソース・システム名かIPアドレスを含むように指定します。

■ソース（IPタイプ）
このフィルタは、IPアドレスとホスト名に対してフィルタをかけることができます。
（ホスト名はDNSキャッシュにより名前解決されます）
%source%だけでなく別のプロパティとも組み合わせて使用できます。
ですが、常にこの値を含むと考えられる%source%と組み合わせてご利用になることをおすすめします。

このフィルタは、「＜」や「＞」の比較オペレーションを利用できるので、それによりIPレンジのフィルタを作成することも可能です。
（例）下図では、172.16.0.110 から 172.16.0.130 までのIPをフィルタリングするよう設定しています。

■メッセージ
このフィルタは、処理されるイベントのメッセージに含まれる文字列をもとにフィルタリングしたい場合に使用します。
「プロパティ値を設定」のテキストボックスに検索したい文字列を直接入力し、「オペレーションの比較」（Contains：含む、does not Contain：含まない･･･など）と組み合わせて使用します。
「オペレーションの比較」は、以下の値から選択します；

＊１： 範囲の指示は、「オペレーションの比較」から「Contain within range」を選択します。
すると「範囲開始」「範囲終了」のテキストボックスが現れます。
「範囲開始」と「範囲終了」のボックスにはそれぞれ数値を入力します。
デフォルトでは、「範囲開始」と「範囲終了」ともに0になっています。
10と50の間で文字列の検索を行いたい場合は、開始と終了のボックスに各値を直接入力してください。
範囲指定において、「範囲開始」を0、「範囲終了」を10とした場合、最初の文字を0として数えますので、9文字目までが対象となります。

下記のように設定を行った場合、「192.168.0.」が検索の範囲となります。
このように設定を行うことで、「192.168.0.1」から「192.168.0.9」までのデバイスで作成されるログを検出することも可能です。

プロパティ値 = 192.168.0.0
範囲開始 = 0
範囲終了 = 10

上記の設定で、「範囲終了」を9としてしまうと、例えば「192.168.010」なども検出されてしまうので、ご注意下さい。

タイプ＝文字列

■ＣｕｓｔｏｍｅｒＩＤ
顧客によってCustomerIDを変更したい場合に、ここで 整数値を入力します。例えば、顧客のサーバを監視する際に、エージェント別に違うIDを設定することが可能です。
サーバAとBを監視しているとして、5台あるサーバAはCustomer IDを１、2台あるサーバBのCustomer IDを2といった具合で設定することが可能です。
サーバAとBのサーバ名が同じであっても、CustomerIDを設定すれば別の定義を行うことが可能となります。

タイプ＝数字

■System ID
SystemIDを変更したい場合には、ここで整数値を入力します。

タイプ＝数字

■ステータス名および値
このフィルタのタイプは、「ステータスの設定」アクションに対応しています。

タイプ＝文字列

TOPへ

このフィルタの条件は、時間の枠（イベントが発生した曜日）をチェックするために使用されます。

■時間
このフィルタの条件は、イベントが発生した時間をチェックするのに使用されます。
例えば、営業時間中であれば、ダイヤルアップしたという内容のCiscoルータからメッセージを受信したとしても全く問題ありません。
ですが、それが夜に起こった場合は、警告すべきことなので管理者はこのイベントの通知を受信するでしょう。ここでは、そのような時間を設定できます。

■曜日
このフィルタの条件は、上記の時間のフィルタと良く似ていますが、こちらは日をベースにしています。
例えば、週末にイベントが発生し、不審な動きをしていることなどを見つけ出すのに役立ちます。
具体的には以下のフィルタが利用可能です：

月曜に実行（タイプ＝ブール演算）

火曜に実行（タイプ＝ブール演算）

水曜に実行（タイプ＝ブール演算）

木曜に実行（タイプ＝ブール演算）

金曜に実行（タイプ＝ブール演算）

土曜に実行（タイプ＝ブール演算）

日曜に実行（タイプ＝ブール演算）

いつくかのインフォメーションユニットタイプに対して、１つのルールを処理させたい場合、そのインフォメーションの種類を選択します。
これは、標準でない処理を必要とする特定のタイプにとって、特に役立ちます。
利用可能な各インフォメーションユニットタイプには、以下のフィルタが定義されています。（下図参照）

具体的には以下のフィルタが利用可能です：

Syslog （タイプ＝ブール演算）
ハートビート （タイプ＝ブール演算）
SNMPトラップ （タイプ＝ブール演算）
RELPリスナー（タイプ＝ブール演算）

TOPへ

Syslog 特有のデータでフィルタリングを行う際、以下のフィルタを使用します。

▲新クライアント「Syslog」フィルタ

▲従来のクライアント「Syslog」フィルタ

■ Syslog ファシリティ
Syslog ファシリティによりフィルタリングを行う場合に設定します。
デフォルトは、LOCAL 0 です。（つまり、ファシリティ値 16）

ファシリティ値は、「詳細」の「プロパティ値を設定」タブから選択し、変更することができます。
Syslog 以外のメッセージ（ハートビートなど）は、ベストエフォート型を基礎としてマッピングされた値となります。

タイプ＝数字

■ Syslog プライオリティ
Syslog プライオリティによりフィルタリングを行う場合に設定します。
デフォルトは、INFO（6）です。（つまり、プライオリティ値 6）

プライオリティ値は、「詳細」の「プロパティ値を設定」タブから選択し、変更することができます。
Syslog 以外のメッセージ（ハートビートなど）は、ベストエフォート型を基礎としてマッピングされた値となります。

「詳細」の「オペレーションの比較」では、マッチングモードを選択 することができます。
そこでは、「未満(＜）」、「より大きい（＞）」、「等しい（＝）」、「異なる（Not＝）」が選択可能です。
ここで「＜」と設定すると、「プロパティ値を設定」で入力したプライオリティ値より小さいもの全てがフィルタリングの対象となります。

(注) この場合、（未満なので）「プロパティ値を設定」で入力したプライオリティ値は対象値に含まれません。
もし、その値を含めたい場合は、次に高い値を指定するようにして下さい。

タイプ＝数字

■ Syslog タグ
Syslog タグ（メッセージを生成したプログラムまたはプロセスの名前）によりフィルタリングしたい場合に設定します。
デフォルトでは、「オペレーションの比較」が「cntains」となっているのみで、「プロパティ値を設定」には何も設定されておりません。

タイプ＝文字列

＊Syslog バージョン、Syslog Appname、Syslog ProcID、Syslog MSGID、Syslog Structdata は、RFC5424（新しい規格）に対応したフィルタです。
　

SNMPトラップを使用することで、WinSyslogは、コンピューター、ルータ、配線ハブなどを含む いろいろな装置を管理したり、モニターしたりすることが可能になります。
デバイスが送信すべき情報がある場合などにトラップが生成されます。
SNMPトラップ特有のデータによりフィルタリングを行う際、以下のフィルタを使用します。

■ コミュニティ
それぞれのSNMPエンティティに対応します。
フィルタのタイプ＝文字列

■ エンタープライズ
それぞれのSNMPエンティティに対応します。
フィルタのタイプ＝文字列

■ 属名
それぞれのSNMPエンティティに対応します。
フィルタのタイプ＝文字列

■ バージョン
それぞれのSNMPエンティティに対応します。
フィルタのタイプ＝文字列

■ 稼動時間
それぞれのSNMPエンティティに対応します。
フィルタのタイプ＝文字列

TOPへ

ここでは、プロパティのカスタマイズが行うことが可能です。

▲新クライアント「カスタムプロパティ」フィルタ

▲従来のクライアント「拡張プロパティ」フィルタ

WinSyslog の内部で、全ての値はプロパティに保存されています。
例えば、メインのメッセージは「msg」というプロパティに保存されています。
「拡張プロパティ」で指定することで、直接プロパティにアクセスすることができます。

フィルタのタイプ＝文字列

TOPへ

このフィルタは、ホスト名やIPアドレスで絞込みを行う際に使用します。
プロパティ名には、どんなプロパティでも入力できますが、確実にホスト名やIPアドレスが含まれている %source% を使用することをおすすめします。（ホスト名は、DNSキャッシュにより名前解決されます） 

このフィルタでは下記オペレーションを使用できます；

＞または ＜ のオペレーション使用時は、192.168.0.10、 192.168.0、192.168 や 192 をテキストボックスに入力することができます（どの値を入力するかは、どのようにフィルタをかけるかによります）。

 上図のように設定を行うことで、範囲を指定してフィルタリングすることも可能です。
この場合、ANDで条件設定されておりますので、「172.16.0.110 より大きい」かつ「172.16.0.130より小さい」IPアドレスのメッセージが真（True）となり、処理されます。

▲新クライアント「ファイル確認」フィルタ

▲従来のクライアント「ファイル確認」フィルタ

 ■ ファイル確認
このフィルタでは、設定したファイルが存在するかどうかを確認できます。

TOPへ

 ■フィルタ結果の保存
フィルタがマッチした場合、その結果をカスタムプロパティに保存することが可能です。
さらに、そのカスタムプロパティは、後にアクションで使用することができます。
　

アクションは、そのルール内のフィルタの条件（設定されている場合）が一致したメッセージに対して実行されます。
アクションには、「ファイルログ（受信したログをファイルへ書き込む）」、「メール送信（メールで通知）」、「データベース（データベースへ保存する）」などがあり、お客様のニーズに合わせて設定可能となっております。

アクションは、ルールの配下に作成します。
各ルール内に複数のアクションを作成することもできます。（作成数の制限はありません。）
アクションは、上に表示されているものから順番に処理されてゆきます。
この順番は、「上に移動」、「下に移動」を指示すること（アクションを右クリック）により、変更することも可能です。

この アクションは、受信したメッセージをテキストファイルに書き込む 際に使用します。

▲新クライアント「ファイルログ」

▲従来のクライアント「ファイルログ」

デフォルトでは、ファイル名に日付を出力(独自のファイル名を作成 ）が有効になっておりますので、一日あたりひとつのファイルが記録されます。新しい項目は、そのファイルの最後に付け加えられます。

ログの書き込みを行っていないときには、このログファイルのロックは解除されています。
そのため、WinSyslogサービスが動作している間でも、他のアプリケーションはファイルにアクセスすることができます。
しかし、他のアプリケーションがファイルをロック状態で開いてしまうと、WinSyslog はログの書き込みができなくなり（アクセスできず）、エラーが発生します。
（イベントログに ERROR_SHARING_VIOLATION のエラーが書き込まれます）
もしも、WinSyslog の稼働中に書き込み中のログファイルを開く場合には、ロック状態でオープンしないアプリケーション（notepad.exe など）をご使用ください。

ファイル名は、ダイアログで設定されている括弧の中のパラメータで、次のように生成されます:

<ファイルパス名><ファイルベース名>-年-月-日.<ファイルの拡張子>

■出力エンコード
受信したログをファイルに書き込む際の出力エンコードをここから選択できます。

■設定変更（従来のクライアント）
この機能は、Adiscon社の別の製品であるMoniLog、およびMonitorWareコンソールをご使用になるユーザーのための機能です。

■ファイル名にプロパティ（変数）を使用（ファイル名のプロパティの置換を有効にする ）
ここを有効にすると、ファイルでプロパティを使用したり、%Source% などのファイルパス名を使用したりが可能となります。
例えば、ファイルパス名  ：F:\syslogs\%source%、ファイルベース名：IIS-%source%、ソースが 10.0.0.1 の場合、ファイル名は下記のようになります。

F:\syslogs\10.0.0.1\IIS-10.0.0.1.log

この設定では、ソースのプロパティ値である %source% がパスの中に使用されているので、その値がファイル名に置換され、上記のように表現できるようになります。
ファイルパス名とファイルベース名には、その他にも様々なプロパティを指定することが可能です。
イベントのプロパティにつきましては、マニュアル2「イベントプロパティ」をご参照下さいませ。

このプロパティの置換を利用して、一ヶ月単位でログファイルを作成させることも可能です。
詳しい手順につきましては、FAQ-「その他便利な機能」（ http://www.port139.co.jp/faq_benri.htm ）-「月単位でログファイルを作成する方法」をご参照下さい。

■ファイルパス  
ファイルを保存するフォルダのパス（ディレクトリ）を指定します。
テキストボックスに直接入力するか、「参照」ボタンから保存先のフォルダを選択します。
デフォルトはC:\Program Files (x86)\WinSyslog （c:\temp） です。

「ファイル名にプロパティ（変数）を使用」機能を有効にしている場合、パス名にソースなどのプロパティを入力することが可能です。（ファイルパス名  ：F:\syslogs\%source%など）

■ファイルベース名  
ファイルのベース名を入力します。これは、具体的な日付などの情報以前の部分です。
入力については上図を参照してください。デフォルトは「WinSyslog」 です。

ここでも 「ファイル名にプロパティ（変数）を使用」機能を有効にしている場合は、「挿入」をクリックすることで、パス名にソースなどのプロパティを入力することが可能です 。

■ファイルの拡張子  
拡張子は、ログファイルを書き込むときに使用されます。
入力については上図を参照してください。デフォルトは「log」 です。

■ローテーションを無効にする 
ここが有効である時は、ログファイルはローテーションされません。

■ファイル名に日付を出力（独自のファイル名を作成）  
ここをチェックすると、ファイル名に日付が含まれるようになります。（例：WinSyslog-2009-04-30.log）
（つまり、ログファイルが毎日作成されるようになります。）

チェックしない場合は、ログファイルは切り替わることなく、設定したファイル（デフォルト：winsyslog.log）に出力され続けることになります。
（ファイルサイズ等の制限はありませんので、テキストエディタで読み込み可能なファイルサイズを超えないよう注意してください。）

■ファイル名にソースを出力（ファイル名にソースを含める  ）
ここをチェックすると、ファイル名の中にデバイスのソースが含まれるようになります。
したがって、ログを報告しているデバイス毎にファイルが作成されます。

■ファイル名にUTCを使用  
これは、「独自のファイル名を作成」の設定とともに機能します。
新たに日付を含むファイルを作成する場合に、その日付（時間）をUTC（全世界で時刻を記録する際に使われる公式な時刻）を基準にするか、またはローカルタイムを基準にするかを選択します。

UTCはGMT(グリニッジ標準時)とほぼ同じですが、こちらの方がより正確です。
日本の場合、ローカルタイムはUTCより9時間進んでいます。UTCで正午ならば、日本は午後９時です。

複数のタイムゾーンのログファイルを作成し、後でそれらをまとめるといった場合は、UTCを基準にすることをお勧めします。
時差の問題に無関係の場合には、ローカルタイムを基準（無効のまま）にして下さい。

■設定値（KB）でファイルを分割（ファイルサイズ (KB)が設定値に達した場合にファイルを分割する）
ここを有効にすると、設定したサイズに達したファイルが分割されます。
その場合、ファイル名には連続した番号が追加れます。（例：WinSyslog-2005-04-26_1.log  ファイルの末尾に「_1」から順番に番号が追加されてゆきます）

■ローテーションを有効にする（循環ログを使用）
ここを有効にすると、ファイルサイズの最大値（最大のファイルサイズ（KB） ）で指定したファイルサイズに達する毎にログファイルを作成してゆき、ログファイルの数で指定した本数分作成されるとファイルが循環してゆきます。

■ログファイルのデータを消去（ファイル自体は削除されません）
（ファイル自体を削除せずに、データのみを消去する）
このオプションは、ローテーションを有効にする（循環ログを使用）オプションとともに使用します。
その名のとおり、このオプションを有効にすると、ファイルがローテーションする際、元のファイルは削除されず、その中身（データ）だけが消去されるようになります。
WinSyslog のログファイルを別のアプリケーションで監視している場合などに有効です。

＜ファイルフォーマット＞
ここは、ログファイルを書き込む際のフォーマットを設定します。デフォルトは「Adiscon」です。

■Adiscon
Adisconフォーマットを選択した場合には、以下にある様々な出力オプションを選択することができます。

■メッセージにXMLを出力（レポートに XMLを使用）
有効にすると、ログにXMLフォーマットされた情報の記録が含まれます。
それには、解析が簡単なフォーマットでタイムスタンプやSyslogファシリティ、プライオリティやその他追加の情報も含まれます。
XML出力フォーマットを選択した場合、その他全てのフィールド情報はXMLストリームに既に含まれていますので、それらの機能はオフにしても構いません。しかし、これは必要条件ではありません。

■日付と時間を出力（日付と時間を含める）
有効にすると、ログに日付と時間が出力されます。

■Syslogファシリティを出力（Syslogファシリティを含める）
有効にすると、ログにSyslogファシリティが出力されます。

■Syslogプライオリティを出力（Syslogプライオリティを含める）
有効にすると、ログにSyslogプライオリティが出力されます。

■日付と時間（デバイスのタイムスタンプ）を出力（デバイスからの日付と時間を含める）
有効にすると、ログに日付と時間が出力されます。

注意： 出力オプションの一番上にある日付と時間を出力は、WinSyslogがメッセージを受信した時間を出力するものです。
一方、こちらの日付と時間（デバイスのタイムスタンプ）を出力は、受信したメッセージからタイムスタンプを取ります。
従って、報告するデバイスが持っている時間（オフになっている場合もあります）に左右されます。
さらに、Syslogメッセージの場合、デバイスが報告するタイムスタンプにはタイムゾーンの情報がありません。
従って、複数のタイムゾーンで報告するデバイスが存在する場合は、タイムスタンプの情報は、ばらばらになってしまいます。（これは、RFC 3164のSyslogの仕様によるものです。 ）

■タイムスタンプにUTCを使用  
有効した場合は、ログファイル内のタイムスタンプは全てUTCで書き込まれます。
有効にしない場合には、ローカルタイムでログが書き込まれます。
UTCは複数のタイムゾーンでログを管理したい場合に、特に有効です。

■ソースを出力（ソースを含める）
有効にすると、ログにソースが出力されます。

■メッセージを出力（メッセージを含める）
有効にすると、ログに受信したメッセージが出力されます。
（Syslogメッセージのメッセージ部分：タグ値（PRI部）、ホストインフォメーションなど（HEADER部）を除いたものが出力されます）

■RAWメッセージを出力（RAWメッセージを含める）
有効にすると、ログに受信したRAWメッセージが出力されます。
（RAW：全く変更が加えられていないもの）
これは、他のアプリケーションでRAWメッセージが必要とされている場合に選択します。

その他のフォーマットは、ログファイルの互換性を他のアプリケーションと持たせるために使用されます。

■Raw Syslogメッセージ
ここを有効にすると、ログが Raw Syslog フォーマットで書き込まれます。
Syslogメッセージの各ラインはRFC3164で書かれています。
特別のフィールド処理や情報の追加などは行われません。
他の（互換性を持たせたい）アプリケーションの中にはこのフォーマットが必要なものもあります。

■WebTrends syslog互換
WebTrends アプリケーションが期待するフォーマットを模倣したものです。
このフォーマットは、そのログファイルのフォーマットを模倣しただけに過ぎないということに注意してください。

データベースログをご利用頂くことで、 受信したメッセージをデータベースへ保存できます。
データベースに保存されたログは、メッセージビューアやカスタムアプリケ−ションで簡単に閲覧することができます。 

▲新クライアント「ODBCデータベース」

▲従来のクライアント「ODBCデータベース」

データベースログは、ODBCに対応したデータベース（実際、WindowsのOSで使用可能な、いかなるデータベースシステムでも）へ受信したSyslogメッセージを記録することができます。
Microsoft JET データベース（Microsoft Accessで使用）とMicrosoft SQL サーバーとMySQLは、「データベース生成」でテーブルの作成がサポートされています。 オラクルやSybaseなど様々なシステムで正常に稼動している例もあります。

データベースログのアクションで最も重要なのは、フィールドの部分です。
デフォルトは、代表的なイベントプロパティの割り当てをデータベース列へ反映します。
ですが、この割り当ては、自由に変更することが可能です。

「フィールド名（Filedname）」は、データベース列の名称です。予め設定されたフィールド名は、Adisconのスキーマが使用するものです。必要ならば、名称は変更することが可能です。

「フィールドタイプ（Fieldtype）」は、データベース列のデータタイプです。それは、データベースで選択される列タイプを反映しなければなりません。また、このデータタイプは、保存される実際のプロパティと一致していなければなりません。例えば、syslogpriorityのような整数タイプのプロパティは、varchar列に保存することができます。一方、syslogtagのような文字列データタイプは、整数列に保存することはできません。

「フィールドコンテンツ（Fieldcontent）」は、イベントプロパティです。サポートされたプロパティリストに関しては、マニュアル内「イベントプロパティ」をご参照下さい。 

データベース フィールド内の値を編集は、新クライアントと従来のクライアントで操作が異なります。

新クライアントでは、表の中の値を直接編集することができます。
項目の追加は、一番下の列に直接入力する形となります。
列を選択し、Deleteキーを押すことで項目を削除することも可能です。

一方、従来のクライアントで値を編集するには、列を選択します。
選択した列の値は、フィールドリストの上のテキストボックスで変更できます。
また、「挿入」、「削除」のボタンをクリックすることで、フィールドの作成、削除を行うことが可能です。
「削除」ボタンをクリックすると、選択されているフィールドが削除されます。また、上・下の矢印ボタンをクリックすることで、選択したフィールドを移動させることができますが、この移動は表面的なもので、データベースアクションの処理には、何も影響ありません。

フィールドコンテンツでは、プロパティの置換機能を使用することができます。例えば、メッセージの最初の200文字だけを保存したい場合には、"%msg: 1:200%"と設定することで可能です。 

■DSNの設定
ここをクリックすると ODBCデータソースアドミニストレーターが表示されます。
システムDSNで設定を行います。

■データベースを確認
このボタンをクリックすると、データベースへの接続を確認することができます。

■データベースを作成（新クライアント）
このボタンをクリックすると自動的に SystemEvents と SystemEventsPropertie の2つのデータベースが作成されます。

■データベースを生成（従来のクライアント）

▲従来のクライアント「データベースを生成」

このフォームでは、基礎となるデータベースのDSN、ユーザーID、パスワードを設定します。
設定後は、データベースにテーブルを作成するために 「作成」ボタンをクリックします。実行されるSQLクエリを確認するためには、「SQLを表示」ボタンをクリックします。「閉じる」ボタンにより、このフォームを終了できます。

※ 64bit OS をご利用の場合、「データベースを生成」を実行する際には、下記ディレクトリ内にある32bitアプリケーション用の[ODBC データソースアドミニストレーター]のシステムDSN も設定してください；
 C:\Windows\SysWOW64\odbcad32.exe

■DSN
DSNを入力します。

■ユーザーID  
データベースに接続する際に利用するユーザーIDを入力します。
ユーザーIDの設定をしなければならないか否かは、データベースシステム次第です。
（例えば、マイクロソフトのAccessは設定の必要がなく、一方、マイクロソフトのSQLサーバはユーザーIDを使うように強いられます。）

■テーブル名  
ログを取るテーブルの名前を入力します。
この名前は、SQLのインサート・ステートメントを作成するために使用されるので、データベースの定義と適合しなければなりません。デフォルトは、「SystemEvents」です。

■パスワード  
データベースに接続する際に利用するパスワードを入力します。
それは、「ユーザーID」で指定したアカウントで利用されるパスワードでなければなりません。
ユーザーIDのように、パスワードが必要かどうかは、データベースシステムに左右されます。
パスワードは、暗号化しても、暗号化しなくても保存できます。
ですが、暗号化して保存するようお勧めします。  

■暗号化  
ODBCのパスワードを暗号化して保存する際に、ここをチェックします。
チェックしない場合は、パスワードは暗号化されずに保存されます。
なるべくチェックして、暗号化させることをお勧めします。

もし、何らかの理由で、暗号化せずにパスワードの保存を行う場合は、そのセキュリティに気を付けてください。この場合、限られたアクセス権でアカウントの使用をすることをお勧めします。
暗号化をしない場合であっても、同様に限られたアクセス権でアカウントを使用することをお勧めします。ここでは、強固な暗号を適用することが出来ないからです。

■ SQLステートメントタイプ  
MSSQLのストアドプロシージャ（Stored Procedures）のINSERT、または Call Statement（MSSQLストアドプロシージャ）のいずれかを選択できるようになりました。この機能は、MSSQLをデータベースソフトとしてご利用になる場合のみ有効です。
また、Call Statemantを選択した場合、テーブル名が自動的にプロシージャ名として使用されます。正しくパラメーターがソートされるようにして下さい。そうでないと、アクションが正常に動作しません。また、その場合、この結果はデバッグログで比較しないと分かりません。

■出力エンコード
ここでは、データベースへ書き込みを行う際に使用する文字コードを設定します。

■ SQL接続のタイムアウト
ここでは項目名の通り、接続のタイムアウトを設定します。

■ 何も入植されていない場合に NULL値を挿入（プロパティが空の場合、NULL値を挿入 ）
このオプションを有効にすると、プロパティが空の場合、NULL値が挿入されるようになります。

■詳細なプロパティのログを有効にする
このオプションは、SystemEventPropertiesテーブルに標準のプロパティ以外のイベント・プロパティを記録します。場合によっては、一つのイベントに複数のプロパティがある可能性があるので、このオプションを選択することで、複数のプロパティを書き込むことが可能となります。しかし、Syslogデータでは、追加のプロパティはあまり存在しません。（「Post Propertey」アクションで独自の定義をしている場合を除いては）

追加のプロパティは、概して イベントログの監視からのSETP受信データにあります。例えば、SETPで受信したイベントログのデータには、実際のWindowsのイベントプロパティとイベントデータが含まれています。このオプションは、Syslogで受信したイベントログ メッセージには適用されませんので、注意してください。

このオプションは、有効にする前に、必要がどうかを確認するようにして下さい。
（このオプションのデータは、MoniorWareコンソールでは必要となる場合があります。）

TOPへ

OLEDBデータベースアクションの設定は、ODBCデータベースログアクションと同様に行うことが出来ます。
Win32版では、MS SQL OLEDBプロバイダとJET4.0 OLEDBプロバイダは、問題なく動作することが確認できておりますが、x64版ではJET4.0 OLEDBプロバイダは現在までのところ対応しておりません。
開発元での内部パフォーマンステストの結果、OLEDB のアクションは、ODBCに比べおよそ30%の機能強化が確認できております。従って、大量のデータをデータベースに書き込みをしたい場合には、特に役立つと思われます。 

このアクションにより、収集したイベントをOLEDB対応のデータベースに書き込むことが可能となります。保存されたメッセージは、カスタムアプリケーションと同様に、別のメッセージビューアで簡単に閲覧することができます。データベース・フォーマットは、変更することが可能です。これは、データベース上で更なる分析を行なう場合に非常に役立ちます。

▲新クライアント「OLEDBデータベース」

▲従来のクライアント「OLEDBデータベース」

OLEDB データベースアクションのメイン機能は、フィールドリストです。
デフォルトでは、代表的なイベントプロパティがデータベースの列に割り当てられています。しかし、この値は、必要に応じて変更できます。

フィールド名（Fieldname） は、データベースの列の名称です。
テーブル内には、どんなフィールドでも設定できます。デフォルトとして設定されているフィールド名は、Adisconのデータベース スキーマで使用されるものです。必要ならば、新たにフィールドを追加することもできます。

フィールドタイプ（Fieldtype） は、データベースの列のデータ型です。
それは、データベースで選ばれる列の型を反映しなければなりません。また、この型は、実際に保存されるプロパティとの間に整合性が取れていなければなりません。例えば、syslogpriority のような整数型のプロパティは、varcharの列に保存することができますが、syslogtagのような文字列のデータ型のプロパティは、integer（整数）型の列に保存することはできません。

フィールドコンテンツ（Fieldcontent) は、イベントプロパティです。
WinSyslogで使用できるプロパティについては、イベントプロパティに関する項目をご覧下さい。 

データベースフィールドの編集は、各行をクリックし、テキストボックスに値を入力、およびドロップダウンリストより値を選択することで行なえます。項目の挿入、削除は、それぞれのボタンをクリックすることで行なうことができます。削除の場合には、選択されている行が削除されます。
また、行を選択して、↑・↓のボタンをクリックすると、上・下へ移動することもできますが、この移動は、表面的なものですので、データベースアクションの書き込みには作用しません。 

文字列のデータ型には、プロパティの置換を使用できます。これは、サブストリングを保存したい場合に、特に役立ちます。例えば、各メッセージの先頭から200文字を保存したい場合には、"%msg:1:200%" という値を使用します。 

■ OleDB 接続の設定（データソースの設定）
ここをクリックすると、OS のOLEDBの設定画面が表示され、データソースの追加、削除、編集などを行なうことができます。 

■ データベースを確認（データベースアクセスの確認）
ここでは、指定したデータソースが問題なく動作するかどうかをチェックします。 

■ SQL 接続のタイムアウト
接続のタイムアウトを設定します。 

■ テーブル名（メインテーブル名）
ログを書き込むテーブル名。この名前は、SQLインサート文の作成に使用されます。また、この名前は、データベース定義にマッチしている必要があります。デフォルトは、「SystemEvents」です。 

■ ステートメントタイプ（SQLステートメントタイプ）
MSSQLのストアドプロシージャ（Stored Procedures）のINSERT、または Call Statement（MSSQLストアドプロシージャ）のいずれかを選択できるようになりました。この機能は、MSSQLをデータベースソフトとしてご利用になる場合のみ有効です。
また、Call Statemantを選択した場合、テーブル名が自動的にプロシージャ名として使用されます。正しくパラメーターがソートされるようにして下さい。そうでないと、アクションが正常に動作しません。また、その場合、この結果はデバッグログで比較しないと分かりません。

■ 出力エンコード
ここでは、データベースへ書き込みを行う際に使用する文字コードを設定します。

■ 詳細なプロパティのログを有効にする
このオプションは、SystemEventPropertiesテーブルに標準のプロパティ以外のイベント・プロパティを記録します。場合によっては、一つのイベントに複数のプロパティがある可能性があるので、このオプションを選択することで、複数のプロパティを書き込むことが可能となります。しかし、Syslogデータでは、追加のプロパティはあまり存在しません。（「Post Propertey」アクションで独自の定義をしている場合を除いては） 

追加のプロパティは、概して イベントログの監視からのSETP受信データにあります。例えば、SETPで受信したイベントログのデータには、実際のWindowsのイベントプロパティとイベントデータが含まれています。このオプションは、Syslogで受信したイベントログ メッセージには適用されませんので、注意してください。

このオプションは、有効にする前に、必要がどうかを確認するようにして下さい。
（このオプションのデータは、MoniorWareコンソールでは必要となる場合があります。） 

■ 接続の再試行
接続が切れると、WinSyslog はDB接続をシャットダウンし、次のアクションで接続の再試行を行ないます。

TOPへ

ここでは、WinSyslogサービスで処理されるメッセージを Windowsのイベントログに記録する設定を行います。

▲新クライアント「イベントログ」

▲従来のクライアント「イベントログ」

■ ソースにサービス名を使用（サービスからログソースを使用）
イベントログに書き込む際のログソース名にサービス名を使用したい場合は、ここを有効にします。

■イベントログのソース名を変更（イベントログソースを置換する）
ここを有効にすると、入力したプロパティ値がカスタムイベントソースとして設定されます。
ここで %source% と設定を行うと、Windowsイベントソースは syslogメッセージを送っているシステムのIPアドレスに設定されます。さらに、SyslogファシリティがイベントIDに設定されます。

しかし、このモードには欠点があります。
上記のようにIPアドレスをイベントソースとした場合、それは登録されていないので、イベントビューアは、メッセージ・ライブラリを見つけることができないと以下のメッセージをユーザーに警告をします。

しかし、その場合でもログメッセージは全て表示されます。
これは、詳細表示においてのみ起こります。  
（この問題は、アプリケーションの動作には影響しません。）

■カスタム イベント・ソース
ここで「挿入」をクリックすることで イベントログソースをカスタマイズすることが出来ます。
デフォルトでは、「%source%」（ソース）のみ設定されています。
この機能は、「イベントログソースを置換する」機能を有効にしている場合のみ、ご利用頂けます。
ここで挿入可能なイベントのプロパティにつきましては、マニュアル2 「イベントプロパティ」をご参照下さい。

■EventType
このログと共に書き込まれるタイプ―または重要度を設定します。
Windowsシステムが利用できる値から選択して下さい。

■イベントID（EventID）
このIDはイベントログが書き込まれる際に使用されます。
他のプロセスに特定のメッセージに対して整合性のあるインターフェイスを与えるために、違うIDを使用することが出来ます。WinSyslog は、使用するIDを制限しません。
けれども、 もしもオペレーティングシステムで登録されていないIDが書き込まれると、Windowsイベント・ビューアには、実際のメッセージ・テキストより先に未登録を指摘するエラー・メッセージが出ます。
このエラーを避けるために、OSでは10,000から10,100のIDが設けられています。
ですので、カスタマイズした全てのメッセージにはこれらのIDを使用することをお勧めします。

■出力メッセージ（ログメッセージ）
Windows のイベントログに書き込まれるメッセージを設定できます。
「挿入」をクリックし、%msg% （例） などの置換文字を追加することで、イベント・ビューアに書き込まれるイベントログのメッセージをカスタマイズすることが可能となります。
ここで挿入可能なイベントのプロパティにつきましては、マニュアル2 「イベントプロパティ」をご参照下さい。

TOPへ

WinSyslogで受信したメッセージをメール送信する際の設定を行います。
メッセージを電子メールで送信するには、このオプションで正しく設定を行う必要があります。

▲新クライアント「メール送信」-メールサーバ オプション

▲新クライアント「メール送信」-メールフォーマット オプション

▲従来のクライアント「メール送信」

＜メールサーバ オプション＞
■メールサーバ  
メッセージの転送の際に使用するメールサーバ名かIPアドレスを指定します。
ここでは、受信者にメール配送ができるサーバを設定するようにしてください。
WinSyslog は、標準のSMTPメールサーバとの接続を前提としています。

■ポート番号
メール送信に使用するポート番号を指定します。
デフォルトは25です。

■メインのメールサーバに接続できない時、下記のサーバを使用（バックアップ メールサーバー）
この機能を有効にすると、メインのメールサーバへの接続に失敗した場合に、バックアップとして設定された別のサーバへの接続されるようになります。

バックアップのメールサーバは、そのセッションの間使用されます。
どれくらいのメールがバックアップサーバで処理されるかは、セッションがクローズされるまでに実行された Eメールアクションの数に依存します。
このセッションがクローズされると、その後は、再びメインのサーバへの接続が試みられます。
（ここでも接続が確立できない場合には、再度バックアップのサーバが使用されます）

このバックアップのサーバへの接続にも失敗した場合に、エラーが作成されます。

■SMTP 認証を使用
ここは、サーバでSMTP認証が必要な場合に有効にします。
多くのサーバ管理者は、SPAM対策のために 認証されたユーザー以外の接続は許可していません。 
サーバが匿名の投稿(anonymous posting)を許可しないよう再設定されると、それにより既存のアカウントが使用できなくなる可能性もあります。

サーバがSMTP認証を必要（またはサポート）する場合は、この設定を有効にして、下のテキストボックスにユーザーIDとパスワードを入力して下さい。

メールサーバーが認証をサポートしていない場合は、ここは有効にしないで置いて下さい。

ここ設定は、認証に対応している場合は、有効することをお勧めします。
たとえ、現在のサーバの設定が認証されていない接続を許可していても、(SPAMの問題が拡大すると）将来的には状況が変わってゆく可能性が十分にあります。
もしも、すでに認証を使用している場合は、そのようなサーバの設定変更は何も影響を与えません。ですが、認証を使用していない場合は、メールサービスが止まってしまう恐れがあります。

■セッション（接続のタイムアウト）
このオプションは、どんどん入って来る多数のメッセージを一つのEメールのメッセージとして統合するべきかを制御します。
指示されたタイムアウトに達するまでは、サーバのSMTPセッションは開かれたままになっています。ここでは、秒単位でなくミリ秒単位で値を入力してください。

新しいイベントが設定されたタイムアウトに達するまでに受信された場合は、前のイベントと同じEメールメッセージに含まれます。それからタイムアウトは再起動されます。
このように、接続のタイムアウトの時間内に受信したイベントはいずれも一つのメールにまとめられます。

これは、メッセージの大量なバーストが予想され、それらのメッセージが少数のEメールにまとめられるべきである場合に最も適切です。さもなければ、管理者のメールボックスは多数のメールにより、すぐにオーバーフローしてしまいます。

接続のタイムアウトでは0から4000までの値を入力できます。
4000より大きな値は、SMTPサーバ・パフォーマンスに影響を及ぼしてしまうなど、予測できない結果につながる可能性もあるので、サポートしていません。

接続のタイムアウトにおいて0を設定した場合は、各イベントが個別のメッセージとして送信されます。

■メールサーバにSSLで接続する
SMTP over SSLが利用可能となりました。
この機能を利用する場合には、465番ポートを使用してください。
また、この機能を有効にした状態でSSL非対応のSMTPサーバーへメール送信を行った場 合には、アクションは失敗してしまいます。（メールは届きません） 

■STARTTLS SMTP Extension を使用
STARTTLS SMTP 拡張機能（暗号化）を有効にします。

■ DateヘッダにUTCを使用
WinSyslog が通知するメールのヘッダの基準時刻を設定します。
デフォルトでは、ここは有効になっておりますので、DateヘッダにはUTCタイムの時刻が入ります。
UTCタイムに対応していないメールソフトをご利用の場合には、この機能を無効にしてください。

＜メールフォーマット オプション＞
■メール送信元（送信者）
メッセージの送信者のEメールアドレスを指定します。
SMTPサーバが受信できる、有効なアドレスを指定して下さい。

■メール送信先（受信者）
受信者の電子メールアドレスを指定します。
複数の宛先へメール送信したい場合には、このフィールドにすべての電子メールアドレスを入力して下さい。それぞれのアドレスは、スペース、セミコロンまたはコンマにて区切って下さい。

■メールタイトルにレガシーの変数を使用（従来の題名の処理を有効にする）
ここでは、メールタイトルの処理の方法を指定します。
ここを有効にした場合には、以下の置換文字列を題名に組み込むことができます:
（無効の場合には、%source% 等のプロパティが利用できます。）

上図のような置換文字列の設定がされている場合、以下のような題名が受信できます。
題名のテキストボックスに「Event from %s:%m」と設定した場合には、下記のような題名でメールが送信されます。（これは、“172.16.0.1”から“This is a test” という内容のメッセージを受信したときの題名です）:

上記の置換文字列とは別に、プロパティを組み込み、修正するという方法もございます。
例えば、以下のような題名を指定することが可能です。
「Mesg：’%msg:1:15’From:%fromhost%”」と設定し、「This is a lengthy test message」というメッセージを172.16.0.1から受信すると、下記のような題名になります：

メッセージは、%msg:1:15 にて文字列の1文字目から15文字目までと指定されていますので、１６字目以降（「ｈｙ」の２文字）は切り捨てられます。

■メールタイトル（題名）
送信メールの題名を指定します。この題名は、各メッセージの送信に使用されます。
イベントの詳細を表示するためにプロパティを組み込む事も可能です。
この機能は、題名でメッセージの内容が判断できるので、携帯電話などのモバイル機で受信する際に特に役立ちます。置換文字列の変換後、題名の最大値は255文字です。
それ以上の文字は切り捨てられます。ですが、メールシステムの制限により255文字以下で題名を切り捨てる可能性もあるという点に注意してください。
そのため、モバイル機で受信する場合には、題名は80文字以下になるように設定することをお奨めします。

メール本体には完全な情報（ソース・システム、ファシリティ、プライオリティ、メッセージテキスト）が含まれています。メッセージ本体のサイズには制限がないので、常に完全なメッセージを受信できます。

「挿入」をクリックし、%msg% （例） などの置換文字を追加することで、題名に書き込まれるイベントのメッセージをカスタマイズすることが可能となります。
ここで挿入可能なイベントのプロパティにつきましては、マニュアル2 「イベントプロパティ」をご参照下さい。

受け取ったひとつのメッセージに対して、一通のメールを送信します。
Eメール送信は、重要な通知やアクションにたいして意味を持ちます。（重要なイベントの発生時に携帯メールに送信して、知らせるなど･･･）
Eメールの報告を提供する事自体には、あまり重要な意味はありません。

■ メールの優先度（ メールプライオリティ）
ここでは、送信するメールの優先度を設定することができます。「low」、「normal」、「high」のいずれかを選択できます。

■メール本文（メールメッセージ フォーマット）
ここでは、メールメッセージ本体のフォーマットを設定します。
「挿入」をクリックし、イベントのプロパティを組み込むことができます。

■出力エンコード
ここでは、メール送信を行う際に使用する文字コードを設定します。

■メール本文にメッセージ/イベントを含む  
syslogメッセージをメッセージ本文に 出力するかどうかを設定します。
ここが無効ならば、メール本文にSyslogメッセージは含まれません。

このオプションは携帯などのモバイル機器で（WML対応の場合は特に）、非常に役に立つ機能です。これらのデバイスは、たいてい表示するデータの量に制限があります。
メッセージ自体は表示しないものもあります。
したがって、このオプションはメッセージ本体を送信したときに限って意味をなします。
そのため、必要がない場合は、ここでオプションをオフにできます。
オフにした場合は、題名に適切な置換文字を使用してください。

WMLに対応した機器がメッセージ本体を受信できる場合であっても、このオプションをオフにした方が良い場合もあります。WMLやWAPは比較的コストがかかります。
生成されたメッセージは、長くなってしまう恐れがあります（メッセージソースに左右されますが）。
したがって、このオプションの機能をオフにすることも適当である場合もあります。

■メッセージにXMLを出力（レポートにXMLを使用）
ここを有効にすると、受信したイベントはXMLフォーマットでメールに含まれます。
その場合、オリジナルのタイムスタンプやファシリティ、プライオリティなどの全ての情報が含まれます。メールがメッセージを解析する自動化されたシステムに送られる場合、XMLフォーマットは特に役に立ちます。
チェックしない場合は、メールにはプレーンテキスト・メッセージが含まれます。

TOPへ

ここでは、受信したメッセージを別の Syslog サーバーへ転送するための設定を行います。

▲新クライアント「Syslog転送」

▲従来のクライアント「Syslog 転送」 TCP を選択した際の画面

■プロトコルタイプ  
syslogメッセージの転送方法としては、UDP、TCPまたはRFC 3195 RAWが使用可能です。

デフォルトは、UDPです。
UDPはほとんどすべてのサーバで使用できますが、ネットワークエラーなどによりメッセージが消失してしまう可能性があります。その性質を理解された上、ご利用ください。

TCPとRFC 3195をベースにしたメッセージは、UDPよりも確実に送信されます。

RFC3195は、特殊な通信モードです。しかし、実装例はとても少ないのが現状です。
このモードは必要でない限り利用しないことをお勧めします。 

TCPには、「TCP（1回の接続につき1つのメッセージ）」、「TCP（持続して接続）」、「TCP（オクテットベースのフレーミング）」 の3つのモードがあります。

「TCP（1回の接続につき1つのメッセージ）」は、2006年以前のAdisconサーバーのための互換モードです。(ほかのベンダーでも要求されるモードかもしれません) 

「TCP（持続して接続）」は、1度の接続で複数のメッセージを送信するモードです。（メッセージを送信し終わるまでポートは開いた状態になります）高いパフォーマンス性が期待できますが、Syslogメッセージ内に制御文字などが含まれる場合には、問題が起こる可能性があります。 

「TCP（オクテットベースのフレーミング）」は、やがて公開される（未確定ですが）IETF標準のアルゴリズムを実装しています。このモードも継続的に接続されます。このモードでは、制御文字が含まれるメッセージも処理されます。しかし、このモードに対応したレシーバーは、現在ところ非常に数少ない状況です。そのため、このモードは、最新のAdiscon製品間の通信でご利用になることをお勧め致します。 

「TCP（持続して接続）」、「TCP（オクテットベースのフレーミング）」を選択した場合には、セッションタイムアウトの設定が行えます。デフォルト（３０分）の場合、メッセージが送信されないまま30分経過すると、接続が切られるようになります。もしも、処理するメッセージが少ない場合には、これより低い値を設定しても結構です。

■Syslog サーバ  
Syslogメッセージを送信する相手先システムの名前またはIPアドレスを指定します。
IPv4 と IPv6 のどちらにも対応しております。

■Syslog ポート  
syslog転送する際のポート番号を指定します。
確信がない場合には、一般的に使用されるデフォルトポート：514のままにして置いてください。別のポートは、例えばセキュリティへの配慮が必要な場合などに使用されます。

■ 接続できない時にバックアップサーバに切替える
（Syslog サーバーへの接続が切れた際、バックアップのサーバーに切替える ）
ここを有効にすると、Syslog サーバーへの接続が確立できない時に、設定したバックアップのサーバーのIPアドレス、ポート番号のサーバーに自動的に切替わります。
このオプションは TCP 通信の場合のみ使用可能なので、ご注意ください。

＜Syslogメッセージオプション＞
（転送時の Syslog の処理）
Syslog メッセージの処理方法を下記4つのオプションから選択します。

・RFC3164(従来の処理）
・RFC5424（推奨）
・受信したメッセージを処理せずそのまま送信（加工しない）
・カスタム Syslog ヘッダを使用（ヘッダの内容をカスタマイズ）

カスタム Syslog ヘッダを使用を有効にすると、ヘッダ部分をカスタマイズすることができます。
デフォルトで設定されているのは、RFC5424のヘッダです。
「挿入」をクリックすると、プロパティを入力することができます。

＜カスタム Syslog ヘッダ＞ （従来のクライアント）

■出力エンコード
Syslog メッセージ転送の際に使用する文字コードを設定します。

▲従来のクライアント「メッセージオプション」

■XML送信（レポートにXMLを使用）
ここを有効にすると、転送されたsyslogメッセージは完全なXMLフォーマットされた情報記録となります。その場合、オリジナルのタイムスタンプや発信元システムなどの情報が追加されますが、見た目には読みづらくなります。ですが、この形式は、解析を容易に行うことができるようになります。

受信するシステムがXMLデータの解析が可能である場合は、特にこの機能は役に立ちます。
しかし、それは別な方法で転送されることができない追加の情報を含めるので、同様にマシンだけでなく人の役にも立ちます。

■XMLの表記コードをMWAgentとして転送する
MWAgent（MonitorWareエージェント）は、イベントの特別なXML表記をサポートしています。ここを有効にすると、転送されたsyslogメッセージにXML表記が使用されます。その場合、オリジナルのタイムスタンプや発信元システムなどの情報が追加されますが、見た目には読みづらくなります。ですが、この形式は、解析を容易に行うことができるようになります。しかし、このオプションは、実験的なものであり、正式なものではありません。

■CEE Syslog フォーマットを使用
ここを有効にすると、CEE フォーマットが使用されます。

■送信メッセージ（カスタムフォーマット ）
メッセージフォーマットのボックスで転送するメッセージの編集を行います。
デフォルトは、%msg% のみ設定されています。
「挿入」をクリックして、メッセージに加えたいプロパティを追加します。

■Syslogソースの追加（別のSyslogサーバに転送する場合）
（別のSyslogサーバに転送する場合のSyslogソースの追加）
ここをチェックすると、発信元のシステムの情報がメッセージに追加されます。
これにより、受信者が発信元を追跡する事ができます。

■ データの圧縮にzLib 圧縮を使用する 
ここでは、Syslog メッセージの圧縮のレベルを設定できます。

▲従来のクライアント「圧縮 オプション」

＜SSL/TLS オプション＞

▲新クライアント「SSL/TLSオプション」

▲従来のクライアント「Syslog TLS」

■ SSL/TLSを使用（SSLに対応していないサーバーへはアクセスできなくなります）
（SSLの有効化／TLSの暗号化：）
ここを有効にすると、SSLに対応していないサーバーへはアクセスできなくなります。
暗号化に使用される方法は、RFC5424 （Transport Layer Security (TLS) Transport Mapping for
Syslog） に互換性があります。

■ TLSモード
次のモードから選択できます；

・匿名認証
デフォルトでは、このモードになっています。
選択するとデフォルトの証明書が使用されます。

・証明書を使用
証明書を指定することができます。
OpenSSLなどにより作成した証明書が必要となります。

■ 共通の CA PEM の選択
ここでは、CA（Certificate Authority；認証局）を指定します。
Syslog を送信する側・受信する側で同じCAを使用しなければなりません。

■ PEM の証明書を選択
クライアントの証明書（PEM フォーマット）を選択します。

■ PEMの鍵を選択
クライアント証明書の鍵（キーファイル）を選択します。

＜TCP オプション＞

▲新クライアント「TCPオプション」

▲従来のクライアント「ディスクキューのオプション」

■ サーバに接続できない時にディスクキューを使用する（TCP選択時のみ）
（Syslogサーバーへの接続に失敗した場合、ディスクキューを使用する ）
この機能を利用すると、リモートの Syslog サーバーへの接続が失敗した際に、Syslogメッセージがローカルの ファイルにキャッシュされるようになります。
保存先のフォルダは変更できます。Syslog 転送アクションを複数設定している場合には、そのアクション毎にGUIDにより個別のファイル名が生成されます。接続に失敗した Syslog サーバーへの接続が確立されると、自動的にキャッシュされたメッセージが送信されるようになります。

Syslogメッセージをキャッシュに入れている間に WinSyslog サービスを起動した場合、その起動中にSyslogサーバーが復旧しても確認ができません。（再度、アクションが実行される際に Syslogサーバーとの接続が確認され、接続されている場合にはキャッシュされたメッセージが送信されます。）

キャッシュのサイズは、特に制限はありません（ディスクのサイズに依存します）。
デフォルトにより、ファイルは 10MB ごとに分割されます。
（この値は、変更することが可能です。最大 2GB まで設定可能です） 

＜UDP オプション＞

▲新クライアント「UDPオプション」

■ UDPでIPスプーフィングを使用
ここを有効にすると、IPスプーフィングが可能になります。
ただし、この機能は UDPでIPｖ４でのみ使用できるものとなっております。
また、Windows Server 2003、2008以前のシステム、および Windows XP、Vista、7 以降のシステムではご利用になれません。（OSの制限によるものなので、詳細は Microsoft の資料等をご確認ください。）
さらに、ローカルのネットワークでしか使用できない可能性があります。
（IPアドレスがスプーフィングされた通信は、ルーターやゲートウェイを通過できない可能性があります。）

■ IPまたはプロパティを修正
静的IPアドレス、またはプロパティを指定することができます。
プロパティを設定した場合、プロパティの内容からIPアドレスの名前解決が実行されます。
例えば、デフォルトである %source% の場合、ソース名からIPアドレスへの名前解決が行われますが、もしも、名前解決ができない場合にはデフォルトのローカルIPアドレスが使用されます。

TOPへ

ここでは、Net Send オプションを設定します。

 “Net Send”アクションを使用すると、Windowsの “net send” 機能を使い短い警告メッセージを送信することができます。これらのメッセージはベストエフォートをベースにして送信されます。
受信者にメッセージが届くと、それらは受信者のマシンのポップアップ メッセージボックス内に現れます。
届かない場合は、単にそれらは破棄されます。バッファリングは行われません。
従って、ルールエンジンはメッセージが届けられたかのチェックを行いません。
「net send」でのレポート送信の問題によってアクションにエラーが発生したというフラグを立てることは決してありません。

■ターゲット  
ここでは、受信者として設定を行いたいWindowsユーザー名、NETBIOS マシン名、またはＩＰアドレス（10.1.1.1のような形式で）を指定します。

■送信メッセージ  
設定したターゲットに対して送信するメッセージを指定します。 ここでは、メッセージの内容をプロパティで設定することも可能です。（「挿入」をクリックして、メッセージに加えたいプロパティを追加します。）
すると、下記のようなメッセージウィンドウが現れます：