|
WinSyslog 10
マニュアル
日本語版 |
WinSyslogについて |
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年に作成されました。
製品は、これまで断続的に開発されています。この製品は、バージョン3で飛躍的に機能性が高まりました。それがバージョン3で製品名を変えるきっかけとなりました。
また 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、TCPには対応しておりません)
■ フリーウェアー・モード
インタラクティブ Syslog
ビューアには「フリーウェア・モード」と呼ばれるモードがあり、有効なライセンスがなくとも、フリーウェアーとして動作します。
このモードでは、最新の60のメッセージをインタラクティブに表示(スクロールする)する機能のみがサポートされています。
この機能は、自宅でご使用いただく場合に最も要求されます。 但し、フリーモードでご利用いただけるのは、インタラクティブ Syslogサーバーのみとなります。
Syslogサーバーサービスやメール送信、データベースログなどの便利な機能をご利用になりたい場合には、ライセンスをご購入頂く必要がございます。
■
標準の互換性
WinSyslog
は、Syslog RFC3164に互換性があります。
WinSyslog は、送信者(デバイス)やサーバーや中継マシンとして稼動します。
全ての仕様のオペレーションモードがサポートされます。
RECに対応していない部分は、ローカルの環境に合うように管理者が設定することが可能です。
(例えば、デバイス時計が信頼できない場合には、タイムスタンプは報告しているデバイスの代わりにローカル・システムから取り出すことができます)
■
Syslog
階層
WinSyslog は大きな組織で必要となるカスケードされた設定をサポートします。
カスケード設定には、重要なイベントを本部の中心となる WinSyslog に報告する、部やサイトレベルで動作するローカルの WinSyslog が例としてあげられます。
カスケードされたシステムには、レベルの数に対する制限がありません。
■ Eメールでの通知
ユーザーが設定したルールに基づいて、受信した 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)で制御できます。
■
Windows 2000、2003、XP、Vista、2008、Windows
7への完全対応
Adiscon 社は、Windows
2000 出荷当時から、完全に対応しています。
そして、WinSyslog はバージョン3.6以降、Windows
XP 対応するようデザインされています。
さらに新しい「テーマ」機能や「fast user switching(
高速ユーザー切り替え)」機能にも対応しています。
■
複数の言語対応のクライアント
WinSyslog
クライアントは、多言語対応になっています。
ボックスから、英語、フランス語、ドイツ語、スペイン語、日本語を選択できます。
言語は、すぐに切り替えることができ、ユーザー自身が自由に選択できます。
■
親しみやすく、カスタマイズも可能なユーザーインターフェイス
WinSyslog
クライアントに新たにスキン機能が加わりました。-デフォルトにより5種類の新しいスキンがインストールされ、選択できます。これらのスキンは、色、彩度とRGBカラーによりカスタマイズすることが可能です。
また、クローンの機能が追加されました。クリックするだけで、ルールセット、ルール、アクション、サービスそれぞれのクローンを作成できます。
「上へ移動」、「下へ移動」の機能がアクションで使用できるようになりました。
アクション、サービス、ルールセット作成のウィザードが改良されました。
■
ローメモリへの対応
WinSyslog
は、起動時に非常用のメモリを割り当てます。システムのメモリ制限に達した場合、非常用のメモリが解除され、キューはロックされます。
それにより、それ以上どんな項目もキューに入れられなくなります。
結果として、サービスの停止(crash)を防ぐことができるようになります。
|
構成 |
中核となる構成
■
WinSyslog設定クライアント
WinSyslog設定クライアント(クライアントと呼ばれます)は、WinSyslogサービスの全ての要素と機能の設定に使用されます。
また、多数のマシンで同じ設定でWinSyslogを使用したい場合など、ベース・システム上のクライアントで設定ファイルを作成・エクスポートし、対象システムに組み込むこともできます。
■
WinSyslogサービス
WinSyslogサービス(サービスと呼ばれます)は、Windowsサービスとして稼動し、実際の処理を実行します。
WinSyslog を動作させるためには、サービスがインストールされていなければなりません。
WinSyslogサービスは、製品の「エンジン」と呼ばれています。したがって、サービスのみインストールされたシステムを「エンジンだけの」インストールと呼びます。
サービスは、ユーザーの操作の必要なしにバックグラウンドで動作します。
それは、コントロールパネルやコンピューターの管理 -MMC (Windows 2000)で制御できます。
<x64対応バージョン の組み込み>
x64対応版は、セットアップ時に自動的にご利用の OS に合わせてインストールされます。(インストーラが判断します)
主に変更された箇所は、サービスのコアの部分です。
詳細は、以下をご覧下さい:
■ ODBCデータベース・アクションが x64 システム上で動作するようになりました。
但し、x64 に対応した ODBCドライバを使用しなければなりません。
■ 設定情報(レジストリ)の保存に関して、DWORD値がQWORD値としてレジストリに保存されるようになりました。けれども、設定クライアントとWin32バージョンのサービスでは、これらのデータタイプを処理でき、必要に応じて自動的に値がDWORD値に変換されます。
x64版であっても設定クライアントは、win32アプリケーションのままとなっております。
アドオン構成
■
インタラクティブ Syslog ビューア
インタラクティブ Syslog ビューアは、Syslogイベントを受信し、リアルタイムに表示するWindows
GUI アプリケーションです。一般的には WinSyslog や EventReporter
とともに使用されます。しかし、独立した Syslog サーバーとしても使用することができます。
インタラクティブ Syslog ビューアは、インタラクティブ
Syslog サーバーの後継ツールです。
インタラクティブ Syslog ビューアでは、日本語文字列を含むメッセージの処理も可能です。また、WinSyslog や
EventReporter で作成したデータベースの内容を読み込み、確認する機能も追加されました。
■ PhPLogCon
PHPLogCon
は、収集されたメッセージをにweb上に表示できる便利な機能を持っています。
このツールは、たいていのブラウザに対応しています。
PHPLogCon は、Syslog
メッセージ、Windows イベントログデータ、その他のネットワークイベントを簡単に
web で閲覧することができます。このツールを使用することにより、システム管理者は、迅速に容易にログをチェックすることが可能となります。
phpLogCon は、WinSyslog
のインストールフォルダに含まれています。現在のところ、日本語マニュアルなどはございません。
詳細は、http://www.phplogcon.org/doc
または 「phplogcon」フォルダ配下の「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
設定クライアントは、サービスの設定を行う際にだけ必要とされます。一旦その設定がなされると、クライアントは使用する必要がなく、メッセージの処理に必要な要素にはなりません。
その他、PHPLogCon
は、ウェブ上で Syslog メッセージにアクセスしたい場合のみ必要となります。これはオプション機能であり、デフォルトではインストールされません。
phpLogConは、WinSyslog
のインストールフォルダに含まれています。
現在のところ、日本語マニュアルなどはございません。
インストール方法など 詳細は、「phplogcon」フォルダ配下の「doc」フォルダ内の英語マニュアルをご参照下さい。
上図の設定は、WinSyslog構成要素がいかに共に機能するかを示すためのものであり、あくまでサンプルです
- WinSyslogの設定は、その必要性に応じて他にも多数の方法があります。
TOPへ |
システム必要条件 |
WinSyslog
には最小ではありますが、必要条件があります。
WinSyslog
クライアント は、以下の環境でご利用いただけます:
OS |
Windows
2000 SP3 以降のシステム
(Windows 2000/XP/2003/2008
Server/Vista/7を含む)
ワークステーション、サーバーを問わず
32ビット版、64ビット版の両方に対応 |
メモリ
|
6MB
|
ハードディスク
|
およそ10MBの空き容量が必要
|
必要ソフトウェア
|
インターネット・エクスプローラ
5.5 以降のバージョン
(クライアントはXMLを使用します。)
|
WinSyslog サービスは、以下の環境で動作いたします:
OS
|
Windows
2000 SP3 以降のシステム
(Windows 2000/XP/2003/2008
Server/Vista/7を含む)
ワークステーション、サーバーを問わず
32ビット版、64ビット版の両方に対応 |
メモリ
|
4MB
その使用環境により64MBのメモリ追加を推奨
*1 |
ハードディスク
|
およそ1MBの空き容量が必要
*1 |
サービスはより小さな必要条件で稼動します。
最も重要な違いは、サービスはシステム上にインターネット・エクスプローラを必要としないということです。
*1
使用にされる実際のリソースは、主に設定されるサービスに左右されます。
サービスが受信するメッセージが1秒間に数件である場合は、パフォーマンスへの影響は顕著ではありません。
もし1秒間に何百件のメッセージをWinSyslogサービスが受信するならば、より大きなリソースを必要とします。それでも、実際の負荷は実行されるアクションに左右されています。
テキストファイルにメッセージを保存することは、データベース・テーブルにそれらを書き込むこと(特にデータベース・エンジンが同じマシンに置かれる場合)よりもパフォーマンスは大きくありません。
このように、システム必要条件はハードウェアのサイズというよりは、処理の大きさに左右されると言えます。
けれども、サービスが(Syslogメッセージなどの)メッセージ・バースト(大量にデータをまとめて伝送する)を含む高度な処理を行う場合は、最も負荷がかかるという点に注意してください。
大量のバーストが予想される場合、それから時間のかかるアクション(例:データベースに書き込む)を実行する場合は、マシンにメモリを追加することをお勧めします。その場合、64MBのメモリの追加を推奨します。典型的に見て一つのメッセージのサイズは約1.5KBあります。
64MB追加した場合は、50, 000 メッセージをバッファリングできます。
また、WinSyslogは、マシンがあまりに時間がかかり過ぎてメッセージの処理を行えない場合、一時的にそのようなバーストをメモリに保存することができます。
PHPLogConは、Microsoft Internet Information Server (IIS)バージョン4以降のマシンにインストールする必要があります。 |
TOPへ |
インストール |
WinSyslog
のインストールは単純で簡単です。
標準のセットアッププログラムでアプリケーションのインストールができます。
WinSyslog のセットアップファイルは、こちら
からダウンロードできます。
インストールセット(ダウンロードしたzipファイル)には、標準のスタートアップ・プログラムとヘルプファイルが含まれています。
アーカイブをどこかのディレクトリ(特に場所は問いません)に解凍してください。解凍先は、ローカルドライブ、リムーバルドライブそれからリモートシェアのファイルサーバーなどでも構いません。なお、Win32
Unzipプログラムは、http://www.winzip.com./
で入手できます。
解凍した後は、「setup.exe」(=セットアップ
プログラム)をダブルクリックし、画面上の指示に従っていってください。
もしも、setup.exeファイルを直接ダウンロードした場合には、解凍の部分の説明は無視してください。(exeファイルかzipファイルかは、どこでダウンロードしたかによります)
< PHPLogConのインストール >
PHPLogCon は、
WinSyslog や EventReporter で作成したデータベースをにweb上に表示するため、Adiscon社によって開発されたフリーツールです。このツールは、たいていのブラウザに対応しています。
PHPLogConのご利用には、Webサーバー(IIS
4以降、Apache
など)、および PHP がインストールされたマシンをご用意頂き、PHP スクリプトが実行可能な環境設定を行って頂く必要がございます。
phpLogConは、WinSyslog
のインストールフォルダに含まれています。
現在のところ、日本語マニュアルなどはございません。
詳細は、「phplogcon」フォルダ配下の「doc」フォルダ内の英語マニュアルをご参照下さい。
|
初期設定を行う |
|
設定情報のエクスポート |
ご質問を頂いた際、その内容により、お客さまの設定情報をサポート担当へお送り頂く場合がございます。
これにより、弊社や開発元 Adiscon社で原因究明のための検証を行うことが可能となります。
設定情報のエクスポートは、サポートの場合だけでなく、設定情報のバックアップを行いたい場合や、複数のマシンで同じ設定をご利用になりたい場合など、様々な状況で役立ちます。
設定情報のエクスポートの詳細につきましては、簡易マニュアル「設定情報の保存・読み込み」をご参照下さい。
■ XML形式による設定情報のエクスポート・インポート
XML形式で設定情報の保存を行うことも可能です。
これは、数多く設定を行う場合や、ソートする場合などに役立ちます。
TOPへ |
インタラクティブ
Syslog ビューアについて |
インタラクティブ 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)を使用しているものを設定すれば、同じ種類のサービスを同一システム上で3つ作成し、稼動させることも可能です。
もしも、同じポートで同じプロトコルを設定したSyslogサービスが存在する場合には、複数のSyslogサービスのインスタンスが実行されているという内容のエラーがWindowsのイベントログに記録されます。
例として、以下のような エラーがイベントログに記録されます。
イベントの種類 |
警告 |
イベント ソース |
AdisconWinSyslog |
イベント カテゴリ |
なし |
イベント ID |
1001 |
説明 |
A configured syslog server service can not be started. Most often,
this happens when more than one syslog server service is configured
to use the same port and protocol, e.g. 514/UDP. Please make sure
that only a single syslog server is defined to listen on the same
port and protocol. If you would like to do multiple actions, this
can be done within a single rule set that is bound to a single
syslog server service. The socket subsystem reported the following
reason: "Can't bind to socket - will keep retrying..." Additional
help might be available at
http://www.adiscon.com/EventHelp.asp
(設定した Syslogサーバーサービスは、実行できません。これは、同じポートやプロトコルを使用するよう(例:514/UDP)設定されたSyslogサーバーサービスが複数存在する場合に、起こりえます。もし、複数のアクションを実行したい場合には、一つのルールセットを一つのサービスに関連付けるように設定を行ってください
・・・) |
理論的には、数百ほどのサービスを追加できますが、オペレーティングシステムのリソースや取り扱いについての観点から、最大でも20から30までのサービスに数を制限することをお勧めします。
もちろん、この制限より多くのサービスが有効である場合もあります。
WinSyslog自体は、サービスの作成数に制限はありません。
数多くのサービスを必要とし、ハードウェアがその処理に耐えうる場合は、数の制限は必要ありません。
実際のパラメーターは、サービスの種類に左右されます。
サービスの有効化・無効化は全てのサービスに共通です。
サービスの有効化によって、サービスは機能します。無効化は、サービスの設定がされていても、それを実行しません。それにより、削除をしなくても簡単にサービスを一時的に使用不能にすることができます。
同様に、右側の設定ダイアログの下にある「使用するルールセット」も、サービスの種類に関係なく共通のものです。どのサービスに対して、どのルールを実行するのかをここで指定します。
新しくサービスを作成する場合には、「サービス」を右クリックして下さい。
それから、「サービスの追加」を選択し、さらにポップアップメニューからサービスの種類を選択します。すると、ウィザードが開始されます。
サービスを削除したい場合は、その対象のサービスを右クリックし、「サービスの削除」を選択します。サービスを削除した場合には、その設定は失われます。
一時的に削除したい場合には、「サービスの無効化」の指示を行って下さい。
ツリー表示の最後の要素は「ルールセット」です。
ここで全てのルールセットの設定を行います。それぞれのルールセットは、完全にお互いから独立しています。
ルールセットは、サービスと組み合わせて使用します。ルールセットの配下には、ルールを作成します。さらに、ルールの下には、それに関連するアクションとフィルタの条件があります。
別途ご説明しますが、ルールは非常に重要な機能です。ルールは最上位のあるものから順に実行されます。
ルールを上や下に移動するには、移動したいルールを右クリックして「上に移動」または「下に移動」を選択してください。 下図を例に、WinSyslog
で Syslog メッセージが処理される流れを大まかにご説明します:
例として、WinSyslog
で受信したSyslog メッセージをログファイルに書き込む場合、Syslogメッセージは下記のように処理されます:
1.
SyslogサーバーサービスでSyslogメッセージを受信
(Syslogメッセージ送信側と受信側で通信の設定を合わせてください)
2.
1のサービスの「使用するルールセット」で指定されたルールセットへメッセージが渡されます
3.
2のルールセットのルール(複数ある場合には上にあるものから順に)に渡されます
4.
3のルール内のフィルタの条件を適用
(設定されていない場合には、全てのメッセージがログファイルに書き込まれます)
5.
4のフィルタ条件に合致したメッセージに対して、その配下にあるアクション(上図の場合「ファイルログ」アクション)が実行されます
|
上のスクリーンショットは、前頁のサンプルの設定画面です
TOPへ |
ライセンスの設定 |
ご購入後に弊社よりメール送付させて頂きますライセンス情報をご登録いただくことにより、製品版として登録され、高度な機能が使用できるようになります。
■ユーザー登録名
ユーザー登録名は、お客さま自身でお決め頂けます。
(ユーザー登録名は、ご注文時にオーダーフォーム《2) ユーザー登録名 の箇所》にご記入頂きます。)
会社名(学校名)を登録名にお使い頂いても良いですし、独自の登録名を選択して頂くことも可能です。
ですが、セキュリティを考慮してよく使われる文字列は Adiscon 社により認証されない場合がございます。
ライセンス発行後は、登録名の変更はできませんので、ご注意ください。
注意 :登録名は、半角6文字以上で設定してください。
登録名には、日本語文字列は使用できません。
(アルファベットの大文字・小文字、数字のみご利用できます)
また、登録名は、大文字と小文字の区別をしますので、正確に入力しなければなりません。
スペースの1文字として認識しますので、余計なスペースが入らないように注意してください。
|
■ユーザー登録番号
この番号は、ご注文後 Adiscon 社によって発行されます。
(上記のユーザー登録名に対して、固有のユーザー登録番号が発行されます。)
ユーザー登録名とユーザー登録番号がライセンスキーとなり、これらを WinSyslog クライアントにてご登録頂くことで、製品版として試用期間終了後も継続して動作するようになります。
ライセンス登録では、必ず正しい登録番号を入力するようにしてください。
ご登録内容に間違いがある場合には、製品版として登録されません。
ユーザー登録番号のペースト機能につきましては、以下のURL をご参照下さい:
https://www.jtc-i.co.jp/port139/faq_new_common.htm#Q-25
TOPへ |
全体オプション |
全体オプション
■処理の優先レベル
ここでは、WinSyslog の処理の優先レベルを設定できます。
■キューのリミット
ここでは、WinSyslog の処理時における キューの最大値が設定できます。
デフォルトは、200000 です。「0」にすると、無制限になります。
■Customer ID
顧客によって Customer ID を変更したい場合には、ここで 整数値を入力します。
例えば、顧客のサーバを監視する際に、会社ごとに違うIDを設定することが可能です。
サーバ A と B を監視しているとして、5台あるサーバ A は Customer ID を 1 、2台あるサーバ B の Customer ID を 2 といった具合で設定することが可能です。
サーバ A と B のサーバ名が同じ場合でも、Customer ID を設定すれば別の定義を行うことが可能です。
■System ID
System ID を変更したい場合には、ここで整数値を入力します。
■MIBS の場所
ここでは、MIBs の場所を指定します。
パスを指定するか、またはブラウザより選択してください。
■基準時刻
ここでは、ファイルログやデータベースログ、Eメール送信など、WinSyslog
全体で使用するタイムスタンプの設定を行えます。UTC、またはローカルタイムの指定を行えない設定項目に対しても、ここで選択したタイムスタンプが設定されます。
ただし、プロパティ値(%timegenerated%
や %timereported%)の基準時刻には、この設定値は反映されません。
■サービスの停止からエージェントを保護する
サービスは、未処理のイベントをインメモリ キューに保存します。サービスが停止すると、このインメモリ キューは、空になります。この場合、未処理イベントは消失してしまいます。
このオプションを有効にすると、サービスの停止前に全てのイベントが確実に処理されます。
しかし、その処理中は、サービスがハングアップしたかのような状態になります。
このオプションは、大きな インメモリ キューがある場合には、有効なケースとなります。
■アプリケーションのイベントログに警告を書き込む
ここを有効にすると、Windows アプリケーション イベントログへ警告を記録できるようになります。
■日本語システムに対する特別なUnicode変換
日本語のシステムにおいては、文字の処理方法が異なります。
日本語文字列がメッセージに含まれる場合、以下のように設定してください。
WinSyslog 8をご利用の場合には、ここを有効にしてください。
WinSyslog 10 など、それ以外のバージョンでは無効のままご利用ください。
エンジンに関して
<アクションのオプション>
■
アクションの失敗を再試行する
「失敗したアクションの再試行を有効にする」機能を有効にすると、サービスは「再試行の回数」の設定値に達するまで、
「再試行の周期」で設定した時間間隔で失敗したアクションを実行します。
なお、エラーログは最後の失敗に対してのみイベントログ(ID 114)に記録 されます。
再試行中のエラーは、WinSyslog のデバッグログ(エラー&警告)に記録されます。
<ルールエンジン特定>
■ 一つのルールが失敗するとき、ルールの実行を中止する
ここを有効にすると、ルールに定義されているアクションのうちの一つが失敗した場合に、そのルールの実行を中止します。
ここが無効になっている場合には、ルール内に複数あるアクションのうち一つが失敗してもルールは停止せず、それ以下に定義されているアクションが実行されます。
■ 内部のDNSキャッシュを有効にする
DNSキャッシュは、逆引きDNSの検索に使用します。
逆引き検索は、IPアドレスをコンピュータ名に変換するために使用され、これは「ホスト名解決」アクションで実行されます。検索を実行する際、毎回DNSは照会されるため、比較的システムへの負荷が大きくなってしまいます。それで、検索結果をキャッシュに入れます。検索が行われるたびに、システムは、まずローカルキャッシュに既に検索結果が入っていないかどうかをチェックします。検索結果がない場合、DNSクエリが実行され、その結果がキャッシュに入れられます。それにより、ホスト名の解決を実行する速度が格段に上がります。
しかし、コンピュータ名やIPアドレスは変更される場合もあります。その場合、DNSは更新されます。もし、DNSを常にキャッシュに入れ、そこから検索するようにしていると、変更された情報を得ることができません。これを回避するために、DNS名をキャッシュに入れる時間に制限を設けました。時間切れとなったDNS名は、キャッシュ内にレコードが存在していないと認識され、新たに検索されるようになります。
また、キャッシュレコードは、システムメモリを使います。数多く名前解決をしたい場合には、より多くのメモリを割り当てる必要が出てくるでしょう。これを解決するために、キャッシュに入れるDNSレコード数を設定できるようにしました。この設定値に達すると、それ以降は新しくキャッシュレコードは割り当てられなくなります。
<DNSキャッシュオプション>
■
DNS名をキャッシュに入れる時間
ここでは、DNS名をキャッシュに入れる制限時間を設定します。
名前解決に問題が生じる可能性がありますので、ここでは高すぎる値を設定しないようにして下さい。
24時間以上の値を設定することは、お奨めできません。
■
キャッシュに入れるレコード数
ここでは、キャッシュに入れるレコードの最大値を設定します。
名前解決をするレコード数が多くなると、システムが割り当てるメモリも大きくなります。ここで大きな値を設定しても名前解決を実行するホストの数が少ない場合には、キャッシュは大きくなりません。
しかし、数多くのホストの名前解決を行なう場合には、キャッシュに入れるレコード数に上限を設けることをお奨めします。ですが、その場合、頻繁にDNSの問い合わせが行なわれます。
1つのキャッシュレコードにつき およそ1~2KBとして数値を設定して下さい。
<リソース ライブラリキャッシュ オプション>
■ ライブラリをキャッシュに入れる時間
このオプションは、EventReporter
のイベントログの監視機能において特に役立つ機能です。
同じイベントが何度も処理される状況では、このオプションを使用することで、パフォーマンスが上がることが期待できます。
デフォルトでは、全てのライブラリが 30分間キャッシュに入れられます。
デバッグ オプション
ここでは、ルールベースのデバッグを行うことが可能です。
複雑なルールベースの場合は特に、その処理が実行されている間 WinSyslog が内部で何を行っているかを知る必要があります。デバッグのログにより WinSyslog の内部での働きを知る事ができます。
ルールベースのテストとは別に、このデバッグのログは技術的なお問い合わせの際に役に立ちます。
状況によっては、お問い合わせ時に問題を解決するため、特定のレベルに設定を変更していただく場合がございます。
重要:
デバッグ出力は、かなりのシステム・リソースを必要とします。
ログのレベルが上がるにつれ、より大きなリソースが必要となります。
しかし、最も低いレベルに設定しても、WinSyslog の処理はかなり遅くなります。
従って、必要な時以外は、このオプションは使用しないでください
|
■
ファイルへのデバッグ出力を有効にする
ここを有効にすると、デバッグのログが可能になり、サービスが稼動する際に書き込まれます。
*パフォーマンスを考慮して、普段は
ここを無効のままにして置いてください
■
ファイル・パス名
書き込みを行うログファイルの完全な名前を設定します。
ドライブを含めた完全なパス名を指定するようにして下さい。
ファイルまたはパス名だけを入力すると、その入力情報はローカルのサービスのデフォルト・ディレクトリを参照します。整合性を考慮して、ドライブを含めた完全で適したファイル名を指定するようにして下さい。
<記録される内容>
■
エラー&警告
ここを有効にすると、エラーと警告がデバッグログへ出力されます。
■
ルール&フィルタエンジン
ここを有効にすると、ルールとフィルタエンジンがデバッグログへ出力されます。
■
最小のデバッグ出力
ここを有効にすると、最小のデバッグログが出力されます。
■
情報のデバッグ出力
ここを有効にすると、情報のデバッグログが出力されます。
■
Ultra Verbose出力
ここを有効にすると、詳細なデバッグログが出力されます。
■ 循環ログを使用
デバッグログに循環ログ機能が追加されました。
この機能を有効にすると、指定頂いたログサイズ・ログの本数でログを循環させることが可能です。
キュー管理 オプション
この機能により、項目(Items)をディスク(指定したファイル)の内部キューに蓄えて置くことが可能となります。
この機能は、確実に必要な場合のみ使用するようにしてください。
ご利用のマシンのハードディスクの速度により、アクションの処理速度が下がる場合があります。最悪の場合には、マシンがIO読み込みを実行できなくなり、キューがいっぱいになってしまいます。ディクスキャッシュは、受信した Syslog メッセージで未処理のものを確実に処理させたい場合の追加機能です。
ディスクキャッシュでは、イベントログの監視サービスのようにアクションが成功している間、継続して動作するタイプのサービスのインフォメーションユニットはキャッシュに入れません。Syslog サーバーサービスのような、その他全てのデータがキャッシュに入れられます。もしも、サービスやサーバーがダウンした時、次回のサービス起動時にキューが自動的に読み込まれるようになります。従って、キューにあるメッセージは消失されません。ただし、キャッシュに入れる処理中にダウンした場合には、そのデータは残りません。
■
ファイル・パス名
キューファイルの保存場所をここで指定できます。
■
キューファイルサイズ
キューのサイズをここで指定します。
システムメモリを超えたサイズのキューファイルサイズは設定しないでください。システムメモリの合計よりも小さいサイズ(512MB)でご利用になることをおすすめします。最大値は2048MBに設定されています。
キューファイルのサイズを変更すると、次回のサービス起動時に新たにキューファイルが作成されます。
それまで作成されていたキューファイルの内容は新しいファイルに移行されませんので、サイズ変更後はそれまでのキューがきちんと処理されたかどうかを確認してください。
また、一般的にサービスを停止した際にも同様にそれまでのキューが処理されます。
<キューのリミット(全体オプション)>
ディスクキャッシュのキュー管理を有効にした場合、全体オプションの「キューのリミット」が重要になります。キューファイルのサイズがどんなに大きくても、ここでの値がキューに保存されるアイテムの最大値になります。
<Race
conditions>
サーバーやコンピュータがクラッシュした際、たいていの場合はファイルシステム、またはキューファイルが壊れてしまいます。その場合は、サービスの起動時に壊れたファイルを探し出し、可能であればキャッシュされたキューを初期化し、キューファイルをリセットします。
■
ポインタの処理
処理ポインタをここで指定します。(ディスクキャッシュのどの位置にポインタが来るかを指定します)
■
ポインタの保存
このポインタは、前回どこの位置で項目が保存されたかを表します。
<キュー管理
オプション>
■ワーカスレッドの数
WinSyslog
がキューの処理に使用しているワーカースレッドの数をここで指定します。
TOPへ |
サービス |
サービスについて
WinSyslog
サービスは、Syslogメッセージの受信やSNMPトラップの受信などを行います。
サービスの作成数に制限はありませんが、同じ設定内容(使用ポート・プロトコル)のサービスを複数稼動させることはできません。(その場合、正常に動作しません。)
異なった設定内容であれば、同じタイプのサービスを複数稼動させることが可能です。
ただし、サービスを一つも設定しなければ、WinSyslog
は全く機能しません。その際には、イベントログに以下のようなエラーが記録されます。
「サービス」と「サービスのデフォルト」が取り違われる場合もありますが、「サービスのデフォルト」は、予めサービスの設定を定義するもので、それ自体は何も実行しません。
|
Syslogサーバー |
ここでは、Syslogサーバーサービス
の設定を行います。
このサービスを設定することで、Syslog 形式のメッセージを収集できます。
■
プロトコルタイプ
Syslog
メッセージは、UDP または TCP、RFC3195ベースのTCP
で受信されます。
一つのサービスで一つのプロトコルを使用できます。
デフォルトは、UDP となっております。
Syslog サーバーは、UDP以外にもTCP、そしてRFC3195
RAWスタンダードを使用したTCP で Syslog
メッセージを受信することが可能です。
*「TCP」、「RFC3195(TCP)」は、プロフェッショナル、エンタープライズエディションの限定機能となります
■
IPアドレス
UDP・TCPともにここで設定した
IP アドレスで処理させることが可能となりました。
この機能は、マルチホームの環境で別のサービスを別のIPアドレスで設定したい場合に役立ちます。
注)デフォルトとして設定されている「0.0.0.0」はすべて(ANY)のIPアドレスを意味します
■
使用ポート
syslog
サーバーが使用するポート番号を指定します。一般的な値は514です。
変更しなければいけない理由が明確である場合のみ、変更を行って下さい。
そのような必要性は、概してセキュリティに対する懸念から生じます。
*ポートの変更を行った場合は、報告を行っているデバイス全ての設定をその標準でないポートを使用するように変更しなければなりません。
■
オリジナルのメッセージ・タイムスタンプを使用 (RFC3164)
ここをチェックすると、WinSyslog はメッセージ受信の時刻の代わりに、Syslog
メッセージ内のタイムスタンプを使用します。これは、Syslog RFC3164に対応しています。
チェックしない場合は、ローカルのシステム時刻を使用します。
メッセージ内のタイムスタンプを使用することには、いくらかの欠点もあります。
タイムゾーンの情報を持たないことなどが挙げられます。
もしも、複数のタイムゾーンのデバイスを処理している場合は、WinSyslog
の時間の記録は、ぐちゃぐちゃになってしまいます。このような場合は、メッセージ受信時のタイムスタンプを使用することをお勧めします。
■
Syslogメッセージからソース・システムを取り出す
このボックス がチェックされる場合、ソースシステムの名前または IPアドレスは(RFC
3164による) syslog メッセージから取り戻されます。
チェックしない場合は、それはメッセージを受信したアドレスに基づいて生成されます。
■
ホスト名の解決
ここをチェックすると、メッセージソースの IPアドレスは(DNSによって)ホスト名の解決が実行されます。
チェックしない場合は、単にIPアドレスが使用されます。
“Syslog
メッセージからソース・システムを取り出す”
設定が有効になっている場合には、この設定は機能しませんので、ご注意ください。この場合には、そのメッセージは常に
syslog メッセージから取り出されます。
■
エスケープ制御文字
Syslog メッセージに制御文字が含まれている場合、ここをクリックするとその文字が5バイトのシーケンスのアスキー文字IDに置換されるようになります。
例えば、ビープ音:BELの場合には、アスキーの文字コードで7となっておりますので、この機能を有効にした場合には
<007> と表示されるようになります。
但し、日本語などダブルバイトの文字を使用している場合には、メッセージが壊れてしまう可能性が高いので、この機能は使用しないようにして下さい。
■
メッセージの
エンコードを自動検出する(UTF8, SHIFT_JIS, EUCJP)
9.1バージョンより設けられた機能です。
マルチバイト文字(日本語文字列など)を含む Syslog
メッセージを処理する場合には、ここを有効にしてください。
■
RFC3164 の構文解析を有効にする
このチェックボックスを有効にすると、RFC3164に対応した Syslog メッセージの構文解析が可能となります。
無効にすると、従来のメッセージ構文解析(Adiscon仕様)が使用されます。
RFC3164を基準にしていないメッセージを受信する際は、ここを無効にしてください。
(送信ホスト名やタイムスタンプが正常に処理されない場合には、ここを無効にしてみてください)
■
RFC5424 の構文解析を有効にする
このチェックボックスを有効にすると、RFC5424に対応した Syslog
メッセージの構文解析が可能となり、RFC5424のヘッダの検出とデコードができるようになります。また、新しい Syslog プロパティが含まれるようになります。
無効にすると、従来のメッセージ構文解析(Adiscon仕様)が使用されます。
*RFC5424は、2009年3月に発表された新しい Syslog
の基準であり、現在(2010年10月)のところ、ほとんどのデバイスで対応していない状況です。
(WinSyslog と EventReporter は、RFC5424に対応しております。)
RFC5424を基準にしていないメッセージを受信する際は、ここを無効にしてください。
(送信ホスト名やタイムスタンプが正常に処理されない場合には、ここを無効にしてみてください)
■
UDPオプション-UDPマルチキャスト グループからの受信を有効にする
このオプションを有効にすることで、マルチキャストIPアドレス(例;224.0.0.1)からの Syslog
メッセージが受信できるようになります。
<TCPオプション>
■
セッションタイムアウト
ここでは、最後のパケットが送信された後、どれだけの時間TCPのセッションをオープンしておくのかを設定します。プルダウンメニューから値(1秒~1日)を選択するか、「カスタム」を選択し、任意の値(ミリ秒で2147483646が最大値)を入力してください。
カスタムで0を入力すると、セッションタイムアウトは無効になります。
■
メッセージを以下のシーケンスによって分ける
ここを有効にすると、受信メッセージは以下の設定で分けることができます;
メッセージ分離のシーケンス:
ここで入力したシーケンスでメッセージを分けます。デフォルトは「\r\n」(改行コード)に設定されております。
メッセージ完了タイムアウト:
ここではメッセージ完了の時間を設定します。ここで設定した時間内に処理されなかったメッセージは、次の(新しい)メッセージとして分けて処理されます。
プルダウンメニューから値(1秒~1日)を選択するか、「カスタム」を選択し、任意の値(ミリ秒で2147483646が最大値)を入力してください。
<Syslog
TLS>
■
SSLの有効化/TLSの暗号化:
ここを有効にすると、SSLに対応していないデバイス(クライアント)からのメッセージを受信できなくなります。
■
TLSモード
次のモードから選択できます;
・匿名認証
デフォルトでは、このモードになっています。
このモードでは、どんな証明書でも(証明書がない場合でも)受信できます。
・x509/name(証明書の確認と名前認証)
このモードを使用すると、「許可されたPeer」でクライアントの証明書の subject がチェックされるようになります。
それによりセキュリティで保護された接続のみ許可されるようになります。
・x509/fingerprint(証明書とフィンガプリント)
このモードは、SHA1フィンガプリント(指紋)を作成し、「許可されたPeer」のフィンガプリントと比較します。
デバッグログを取得すれば、許可されなかったクライアント証明書のフィンガプリントを確認することができます。
・x509/certvalid(証明書の確認のみ)
クライアント証明書が有効でありさえすれば接続が許可されます。
■
共通の CA PEM の選択
ここでは、CA(Certificate
Authority;認証局)を指定します。
Syslog
を送信する側・受信する側で同じCAを使用しなければなりません。
■
PEM の証明書を選択
クライアントの証明書(PEM フォーマット)を選択します。
■
PEMの鍵を選択
クライアント証明書の鍵(キーファイル)を選択します。
■ 許可された
Peer
ここでは、許可されたPeer を入力します。
x509/name
を使用する場合、証明書の subject を入力します。
例えば、証明書の subject がCN =
secure.syslog.msg である場合、secure.syslog.msg
を許可された Peer として入力します。
x509/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サーバーサービスを設定します。
※このサービスは、エンタープライズ エディションのみご利用可能となっております※
SETPサーバーは、他システムからイベントを MonitorWare(弊社では扱っておりません)
製品ライン内で確実に受信するのに用いられます。ここには、SETPが送り主からオリジナルのメッセージを受け取って、送り側で設定した設定を正確に使用するための設定が設けられています。
変更は、SETPサーバー側で発生しません;
メッセージ・フォーマットに対して設定すべき値はありません。
■ 使用ポート
SETPサーバーが使用するポートを指定します。デフォルトは、5432です。
変更しなければいけない理由が明確である場合のみ、変更を行って下さい。
そのような必要性は、概してセキュリティに対する懸念から生じます。
SETPサーバーとの通信には、TCPが使用されます。
ポートの変更を行った場合は、送信側の設定を送信側と合わせるように変更しなければなりません。
■
IPアドレス
SETPサーバーサービスでも、Syslogサーバーサービスと同様に特定のIPアドレスで処理させることが可能となりました。
この機能は、マルチホームの環境で別のサービスを別のIPアドレスで設定したい場合に役立ちます。
注)デフォルトとして設定されている「0.0.0.0」はすべて(ANY)のIPアドレスを意味します
■
SSLの有効化/TLSの暗号化
ここを有効にした場合、SSL、またはTLS、STEPサーバーに接続することが出来ます。
ただし、SSLに対応していないSETPサーバーには接続できなくなります。
■
データの圧縮にzLib圧縮を使用する
ここを有効にすると、WinSyslogはSETP送信により送信されたzLib圧縮データを解凍します。今まで通り、通常のデータも受信することが可能です、zLib圧縮は、WAN環境において通信量を減少させることに役立ちます。
■ セッションタイムアウト
サーバー側のセッションがオープン状態である場合の最大の待ち時間を指定します。
■
ルールのエラーを送信者に通知しますか?
ここを有効にすると、アクションの結果をSETPメッセージの送信者へ通知されるようになります。
例えば、イベントログの監視を実行していて、これらのイベントをSETPで送信、一方でデータベースへ収集した全てのイベントを書き込むよう設定しているとします。
もしも、データベースがオフラインの場合、イベントの書き込みは実行できないので、SETPサーバーは、アクションの実行に失敗したという内容のメッセージを最後のメッセージとして送信し、イベントログに
ID:1005のエラーを作成します。(その後、このアクションが成功した場合には、ID:1012のイベントログが記録されます。)送信者は、それから停止して、再度イベントの送信を試みます。
これは、SETPがTCPと同じようにデータ転送を確実にするためですが、さらに、アクションが成功した場合にも送信者にステータスを返信することもできます。これは、イベントログの監視サービスが再試行可能(restartable)なイベントソースだからです。同じソースでアクションが再試行するかどうかを決定するために、アクションの結果が使用されます。他のイベントソースは、違う動作をします。例えば、Syslogサーバーサービスは、失敗したアクションを再試行しません。これは、Syslogメッセージが消失する可能性があるという性質によるものです。
注意:この機能をご利用になる場合、それ以前のバージョン(7.2.x以前)の
WinSyslog へは、このデータが正常に送信できない可能性がございます。従って、この機能をご利用の際は、全ての
WinSyslog を最新版にバージョンアップするようにして下さい。 |
■ 使用するルールセット
SETPサーバーのサービスで使用されるルールセット名を選択します。
当然のことながら、そのルールセット名は、有効でなければなりません。
TOPへ |
ハートビート |
ハートビートサービスを使用することで、WinSyslog
サービスが稼動しているかどうかを確認することができます。
ハートビートクロックで設定した時間ごとにハートビートメッセージが作成されます。
ハートビートメッセージは、Syslog メッセージと同様にメール送信やSyslog転送など、お好みのアクションを組み合わせ、通知させることが可能です。
(このサービスの「使用するルールセット」で選択したルールセット内のアクションで処理されます)
*ハートビートメッセージが指定の時間に届かない場合には、WinSyslogで何かトラブルが起きているか、動作が停止しているということが疑われます。
■ハートビート中に受信するメッセージ
ここで設定したメッセージがハートビートからのログに記録されます。
入力する内容は、どんなものでも構いません。
■ハートビート クロック(スリープタイム)
ハートビートメッセージを生成する間隔を指定します。(ミリ秒で設定します)
ハートビートメッセージを受信するマシンのスペック等を考慮し、値を設定してください。
重い負荷がかかっている時は、メッセージの生成間隔が設定より遅くなる場合もあります。
<メッセージに付加する値>
■Syslogファシリティ
ハートビートメッセージに割り当てられる syslog ファシリティ。
メッセージを syslog サーバに転送する際に役立ちます。
■Syslogプライオリティ
ハートビートメッセージに割り当てられる syslog プライオリティ。
メッセージを syslog サーバに転送する際に役立ちます。
■リソースID
ハートビートメッセージに割り当てられるリソース ID。
メッセージを syslog サーバに転送する際に役立ちます。
■Syslog
タグ値
ハートビートメッセージに割り当てられる syslog タグ値。
メッセージを syslog サーバに転送する際に役立ちます。
■使用するルールセット
このサービスのために使用されるルールセット名。
ルールセット名は、有効でなければなりません。
|
SNMP トラップ受信 |
SNMPトラップ受信によって、SNMPメッセージを受信することができます。
トラップは、別のプロトコル(SNMP)においてSyslogメッセージのような役割を果たすものです。
デバイスが送信すべき情報がある場合などにトラップが生成されます。その情報には、バージョンやコミュニティなどの標準的な項目も含まれます。
■
使用ポート
SNMPリスナーが使用するポートを指定します。
確信がない場合には、デフォルトのポートである162のままにして置いて下さい。
■
SNMPバージョン
ここでは、SNMPバージョンを限定します。設定可能な値は、下記のとおりです:
1. SNMP
全てのバージョン
2. SNMPバージョン1のみ
3. SNMPバージョン2cのみ
■
Mib名を完全に解決する(ロングフォーマット)
このオプションを有効にすると、MIBブラウザにあるようにMib名が解決されるようになります。
■
使用するルールセット
このサービスのために使用されるルールセット名。ルールセット名は、有効でなければなりません。
|
MonitorWare Echo Reply |
この機能は、MonitorWareエージェントに関連するものです。
現在、有限会社イハラでは、MonitorWareの販売は行っておりません。
MonitorWare
Echo Replyサービスは、多少変わったサービスです。
これは、単独では何のイベントも生成しません。このサービスは、MonitorWare Echo Requestサービスに受動的に対応する物です。
これらは、同時に失敗しているエージェントを見つけるのに使用されます。設定項目は、使用ポートのみで Echo Request サービスが接続するポートと同じポートである必要があります。
|
RELP リスナー (WinSyslog 10.1 で追加された機能) |
RELP リスナーサービスは、新しいプロトコルである「Reliable
Event Logging Protocol」に対応しています。このプロトコルを使用することで、従来のTCP Syslog
プロトコルより確実な転送が可能となります。
(このサービスでは、RELPに対応した送信元からのメッセージを受信します)
RELPプロトコルを使用すること以外は、機能的には Syslog サーバーサービスと同じような働きをします。
■
使用ポート
RELP リスナー サービスで使用するポート番号をここで指定します。
デフォルトは、20514です。
この値は変更できますが、その際は、メッセージを送信している機器のポートも合わせて変更するようにしてください。
■
セッションタイムアウト
ここでは、サーバー側のセッションがオープン状態である場合の最大の待ち時間を指定します。
■
使用するルールセット
このサービスのために使用されるルールセット名。ルールセット名は、有効でなければなりません。
RELP とは
Reliable Event Logging Protocol
の略であり、転送中のメッセージがロストしないよう設計されたプロトコルです。現行バージョンのPELPプロトコルは、接続が切れた場合でも、メッセージを複製できる可能性があります。
|
|
フィルタの条件 |
フィルタの条件は、受信したログの絞込みをしたい(特定の条件に合ったログだけを処理、または破棄したい)場合に設定します。
フィルタの条件は、ルールの中、アクションの上にあります。
(下図では、Default RuleSet(ルールセット)の下、さらに
ForwardSyslog(ルール)の下、アクションの上にあります)
WinSyslogで受信したログは、フィルタの条件で設定した内容(フィルタ)に一致した場合、その下で設定されたアクションにより処理されます。
フィルタの条件は、必要に応じて複雑にすることが可能です。
ブール演算と条件のネスティングがサポートされています。
デフォルトでは、
上図のように「AND」のみが設けられています。
この状態では、全てのデータが「真(True)」となり、それらに対してアクションが実行されます。
(すなわち、フィルタリングされず、全てのメッセージが処理されます)
メッセージの絞込みを行わない(例えば、データベースやテキストファイルに全てのメッセージを書き込みたい場合)場合には、このデフォルトの設定のままご利用下さい。
一方、特定の条件において(メッセージを絞り込んで)アクションを実行させたい場合には、その条件によって、様々な設定を行うことができます。
TOPへ |
オペレーション |
オペレーションでは、フィルタの条件がどのように互いにリンクしているかを設定します。
以下のオペレーションを使用することが可能です。
AND
|
全てのフィルタが一致した場合のみ、結果が「真(True)」になります。
<例> フィルタ a、 b、 c を設定した場合
a、かつ b かつ c のいずれも満たす場合に真(True)となり、アクションが実行される
|
OR
|
ひとつでも一致するフィルタがあるならば、結果が「真(True)」となります。
<例> フィルタ a、 b、 c を設定した場合
a、または b または c のいずれか1つでもを満たす場合に真(True)となり、アクションが実行される
|
NOT
|
NOT演算には、ひとつのフィルタしか作成できません。
フィルタが一致した場合、「NOT」は「偽(False)」となります。
<例> フィルタ a を設定した場合
a を満たす場合、アクションが実行されない
|
XOR
|
XOR演算は、2つのフィルタのうち一方が一致した場合のみ、「真(True)」となります。
<例> フィルタ a、 b を設定した場合
a と b のどちらか一方のみ満たす場合に真(True)となり、アクションが実行される
a と b の両方を満たす、両方を満たさない場合は、偽(False)となる。
|
TRUE
|
デバッグを行う際に役立ちます。結果は「真」となります。
|
FAULSE
|
デバッグを行う際に役立ちます。結果は「偽」となります。
|
|
フィルタ |
フィルタは、各オペレーションノードの下に追加することが可能です。
全てのサービスに使用できる共通のフィルタは、数種類あります。
また、特別な種類のインフォメーション ユニットに対してのみ適用されるフィルタも存在します。
インフォメーション ユニットでマッチしない全てのフィルタは、フィルタリング処理で無視されます。
このような場合には、サービスごとに別のルールセットを作成し、関連付けするようにして下さい。
フィルタには、色々なタイプのものが存在します。
従って、それらのタイプと値を比較する方法もそれぞれ存在します。
以下のタイプが使用可能です。
以下のタイプが使用可能です。
文字列(String)
「=」、「Not =」、「範囲内の一致」で別の文字列と比較されます。
番号(Number)
「=」、「Not =」、「<」、「>」で別の番号と比較されます。
ブール演算子(Boolean)
「=」、「Not =」で「真」か「偽」のいずれかと比較されます。
時間(Time)
「=」のみで別の時間と比較されます。
|
全体の条件 |
全体の条件は、全体としてルールに適用します。
それは、フィルタのツリーの中で条件と共に、理論的な「AND」と組み合わせられます。
■検出されないフィルタをTRUEとして処理する
フィルタの条件で問い合わせたプロパティがイベントに存在しない場合、通常は「偽(False)」として処理されます。、上記のイベントを「真(True)」として処理したい場合、ここを有効にすることで可能となります。
■イベントが発生した場合のみ稼動
これは、ある意味「最小の待ち時間」と正反対の機能と言えます。
ここでは、設定した回数だけイベントが発生しないとルールが起動しません。
この機能は、指定した時間内に、指定されただけの回数のイベントが発生しなければルールが稼動しません。これは、以前は「発生」と呼ばれていた機能を改名したものです。
■最小の待ち時間
このフィルタの条件は、ルールが過度に作動するのを防ぐために使用が出来ます。
(ここで設定した時間間隔で、ルールが稼動するようになります。)
<例> ここで 60 と入力すれば、60秒毎にルール(アクション)が実行されます。
https://www.jtc-i.co.jp/port139/eve92_for_web.htm#11-1 をご参照ください。
■プロパティに関する全体の条件
この機能により、プロパティをベースにして全体の条件を管理することが可能となりました。
例えば、メッセージのソースをプロパティとして処理する場合、それぞれ個々のメッセージソースに対して最小の待ち時間が適用されるようになります。
TOPへ |
一般 |
■ソース
このフィルタの条件は、インフォメーション ユニットを作成するシステムをチェックします。
例えば、Syslogサーバの場合、これはsyslogメッセージを送っているsyslogデバイスになります。
このフィルタは、文字列で指定します。 ソース・システム名かIPアドレスを含むように指定します。
■ソース(IPタイプ)
このフィルタは、IPアドレスとホスト名に対してフィルタをかけることができます。
(ホスト名はDNSキャッシュにより名前解決されます)
%source%だけでなく別のプロパティとも組み合わせて使用できます。
ですが、常にこの値を含むと考えられる%source%と組み合わせてご利用になることをおすすめします。
このフィルタは、「<」や「>」の比較オペレーションを利用できるので、それによりIPレンジのフィルタを作成することも可能です。
(例)下図では、172.16.0.110 から 172.16.0.130 までのIPをフィルタリングするよう設定しています。
■メッセージ
「メッセージの内容」の機能は非常に役に立ちます。 「プロパティ値を設定」のテキストボックスに検索したい文字列を直接入力します。
指定された値がメッセージの範囲内で発見された場合、真(True)として処理されます。 暗黙のうちにワイルドカード化することはあるので、特別なワールドカードを指示する必要がありません。
内容検索は、メッセージ内で範囲を限定することができます。
範囲の指示は、「オペレーションの比較」から「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
顧客によってCustomerIDを変更したい場合に、ここで 整数値を入力します。例えば、顧客のサーバを監視する際に、エージェント別に違うIDを設定することが可能です。 サーバAとBを監視しているとして、5台あるサーバAはCustomer IDを1、2台あるサーバBのCustomer IDを2といった具合で設定することが可能です。 サーバAとBのサーバ名が同じであっても、CustomerIDを設定すれば別の定義を行うことが可能となります。
タイプ=数字
■System
ID SystemIDを変更したい場合には、ここで整数値を入力します。
タイプ=数字
■ステータス名および値
このフィルタのタイプは、「ステータスの設定」アクションに対応しています。
タイプ=文字列
TOPへ |
Date/時間 |
このフィルタの条件は、時間の枠(イベントが発生した曜日)をチェックするために使用されます。
■時間
このフィルタの条件は、イベントが発生した時間をチェックするのに使用されます。 例えば、営業時間中であれば、ダイヤルアップしたという内容のCiscoルータからメッセージを受信したとしても全く問題ありません。
ですが、それが夜に起こった場合は、警告すべきことなので管理者はこのイベントの通知を受信するでしょう。ここでは、そのような時間を設定できます。
■曜日
このフィルタの条件は、上記の時間のフィルタと良く似ていますが、こちらは日をベースにしています。
例えば、週末にイベントが発生し、不審な動きをしていることなどを見つけ出すのに役立ちます。 具体的には以下のフィルタが利用可能です:
月曜に実行(タイプ=ブール演算)
火曜に実行(タイプ=ブール演算)
水曜に実行(タイプ=ブール演算)
木曜に実行(タイプ=ブール演算)
金曜に実行(タイプ=ブール演算)
土曜に実行(タイプ=ブール演算)
日曜に実行(タイプ=ブール演算)
|
インフォメーション ユニット タイプ |
いつくかのインフォメーションユニットタイプに対して、1つのルールを処理させたい場合、そのインフォメーションの種類を選択します。 これは、標準でない処理を必要とする特定のタイプにとって、特に役立ちます。
利用可能な各インフォメーションユニットタイプには、以下のフィルタが定義されています。(下図参照)
具体的には以下のフィルタが利用可能です:
Syslog
(タイプ=ブール演算)
ハートビート (タイプ=ブール演算)
SNMPトラップ (タイプ=ブール演算)
イベントログの監視V2(タイプ=ブール演算)
SMTPリスナー(タイプ=ブール演算)
SNMPモニター(タイプ=ブール演算)
RELPリスナー(タイプ=ブール演算)
TOPへ |
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トラップ |
SNMPトラップを使用することで、WinSyslogは、コンピューター、ルータ、配線ハブなどを含む
いろいろな装置を管理したり、モニターしたりすることが可能になります。
デバイスが送信すべき情報がある場合などにトラップが生成されます。
SNMPトラップ特有のデータによりフィルタリングを行う際、以下のフィルタを使用します。
■
コミュニティ
それぞれのSNMPエンティティに対応します。
フィルタのタイプ=文字列
■
エンタープライズ
それぞれのSNMPエンティティに対応します。
フィルタのタイプ=文字列
■
属名
それぞれのSNMPエンティティに対応します。
フィルタのタイプ=文字列
■
バージョン
それぞれのSNMPエンティティに対応します。
フィルタのタイプ=文字列
■
稼動時間
それぞれのSNMPエンティティに対応します。
フィルタのタイプ=文字列
|
拡張プロパティ |
ここでは、プロパティのカスタマイズが行うことが可能です。
WinSyslog
の内部で、全ての値はプロパティに保存されています。
例えば、メインのメッセージは「msg」というプロパティに保存されています。
「拡張プロパティ」で指定することで、直接プロパティにアクセスすることができます。
フィルタのタイプ=文字列
TOPへ |
拡張IPプロパティ |
このフィルタは、ホスト名やIPアドレスで絞込みを行う際に使用します。
プロパティ名には、どんなプロパティでも入力できますが、確実にホスト名やIPアドレスが含まれている
%source%
を使用することをおすすめします。(ホスト名は、DNSキャッシュにより名前解決されます)
このフィルタでは下記オペレーションを使用できます;
= |
プロパティ値のテキストボックスで入力したIPアドレスに一致すると真(True)になります |
Not = |
プロパティ値のテキストボックスで入力したIPアドレス以外のものが真(True)になります |
> |
プロパティ値のテキストボックスで入力したIPアドレスより大きいものが真(True)になります |
< |
プロパティ値のテキストボックスで入力したIPアドレスより小さいものが真(True)になります |
>または < のオペレーション使用時は、192.168.0.10、
192.168.0、192.168 や 192
をテキストボックスに入力することができます(どの値を入力するかは、どのようにフィルタをかけるかによります)。
上図のように設定を行うことで、範囲を指定してフィルタリングすることも可能です。
この場合、ANDで条件設定されておりますので、「172.16.0.110
より大きい」かつ「172.16.0.130より小さい」IPアドレスのメッセージが真(True)となり、処理されます。
|
ファイル確認 |
■ ファイル確認
このフィルタでは、設定したファイルが存在するかどうかを確認できます。
ここでは、直接ファイルパスを入力するか、または「ブラウザ」ボタンから値を指定します。
|
フィルタ結果の保存 |
■フィルタ結果の保存
フィルタがマッチした場合、その結果をカスタムプロパティに保存することが可能です。
さらに、そのカスタムプロパティは、後にアクションで使用することができます。
|
アクション |
アクションは、そのルール内のフィルタの条件(設定されている場合)が一致したメッセージに対して実行されます。
アクションには、「ファイルログ(受信したログをファイルへ書き込む)」、「メール送信(メールで通知)」、「データベース(データベースへ保存する)」などがあり、お客様のニーズに合わせて設定可能となっております。
アクションは、ルールの配下に作成します。
各ルール内に複数のアクションを作成することもできます。
アクションは、上に表示されているものから順番に処理されてゆきます。
この順番は、「上に移動」、「下に移動」を指示すること(アクションを右クリック)により、変更することも可能です。
|
ファイルログ |
この
アクションは、受信したメッセージをテキストファイルに書き込む 際に使用します。
デフォルトでは、「独自のファイル名を作成」が有効になっておりますので、一日あたりひとつのファイルが記録されます。新しい項目は、そのファイルの最後に付け加えられます。
ファイルのロックは、データの記録がないときは解除されます。
そのため、サービスが動作している間でも、他のアプリケーションはファイルにアクセスすることができます。
ログの書き込みを行っていないときには、このログファイルのロックは解除されています。
そのため、WinSyslogサービスが動作している間でも、他のアプリケーションはファイルにアクセスすることができます。
しかし、他のアプリケーションがファイルをロック状態で開いてしまうと、WinSyslog
はログの書き込みができなくなり(アクセスできず)、エラーが発生します。(イベントログにエラーが書き込まれます)
もしも、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-「その他便利な機能」(
https://www.jtc-i.co.jp/faq/faq_winsyslog.html )-「月単位でログファイルを作成する方法」をご参照下さい。
■ファイルパス名
ファイルを保存するフォルダのパス(ディレクトリ)を指定します。
入力については上図を参照してください。デフォルトは「c:\temp」 です。
「ファイル名のプロパティの置換を有効にする」機能を有効にしている場合、「挿入」をクリックすることで、パス名にソースなどのプロパティを入力することが可能です。(ファイルパス名
:F:\syslogs\%source%など)
■ファイルベース名
ファイルのベース名を入力します。これは、具体的な日付などの情報以前の部分です。
入力については上図を参照してください。デフォルトは「WinSyslog」 です。
ここでも
「ファイル名のプロパティの置換を有効にする」機能を有効にしている場合は、「挿入」をクリックすることで、パス名にソースなどのプロパティを入力することが可能です
。
■ファイルの拡張子
拡張子は、ログファイルを書き込むときに使用されます。
入力については上図を参照してください。デフォルトは「log」 です。
■ファイルのフォーマット
ここは、ログファイルを書き込む際のフォーマットを設定します。デフォルトは「Adiscon」です。
これは、ほとんどのオプションを提供します。
その他のフォーマットは、ログファイルの互換性を他のアプリケーションと持たせるために使用されます。
「Raw Syslogメッセージ」は、ログファイルにRaw Syslogフォーマットで書き込みます。
つまり、Syslogメッセージの各ラインはRFC3164で書かれています。
特別のフィールド処理や情報の追加などは行われません。
他の(互換性を持たせたい)アプリケーションの中にはこのフォーマットが必要なものもあります。
「WebTrends syslog互換」は、WebTrends アプリケーションが期待するフォーマットを模倣したものです。このフォーマットは、そのログファイルのフォーマットを模倣しただけに過ぎないということに注意してください。
|
「カスタム」フォーマットは、サードパーティのアプリケーションに対して、ログファイルに互換性を持たせるためにフォーマットをカスタマイズすることができます。このオプションを選択することにより、その下の「カスタム
ライン フォーマット」の機能がオンになります。
「Adiscon」フォーマット以外のものは修正されたものですので、一部のフォーマットオプションは適用できません。それらのオプションは有効になります。
■カスタム ライン フォーマット
ここで指定することにより、ログファイルの出力を完全にカスタマイズすることが可能になります。
ファイルのフォーマットにおいて、「カスタム」フォーマットを選択した場合のみ、この機能は有効になり、「挿入」をクリックすることで項目を追加できます。
デフォルト値は、「%msg%%$CRLF%」です。(%msg%:メッセージ、%$CRLF%:改行コード)
<表示される時刻につきまして>
作成時刻(%timegenerated%)、および報告時刻(timereported%)のプロパティをご利用になる場合、そのままではUTCタイム(-9時間)で記録されます。
ローカルタイムで記録したい場合には、それぞれの値の代わりに下記の値(:::localtimeが挿入されています)をご利用下さい:
%timegenerated:::localtime%
%timereported:::localtime% |
■独自のファイル名を作成
ここをチェックすると、ファイル名に日付が含まれるようになります。
(つまり、ログファイルが毎日作成されるようになります。)
ここをチェックすると、ファイル名に日付が含まれるようになります。(例:WinSyslog-2009-04-30.log)
つまり、ログファイルが毎日作成されるようになります。
チェックしない場合は、ログファイルは切り替わることなく、設定したファイル(デフォルト:winsyslog.log)に全てのログが書き込まれるようになります。
■ファイル名にソースを含める
ここをチェックすると、ファイル名の中にデバイスのソースが含まれるようになります。
したがって、ログを報告しているデバイス毎にファイルが作成されます。
■ファイル名にUTCを使用
これは、「独自のファイル名を作成」の設定とともに機能します。
新たに日付を含むファイルを作成する場合に、その日付(時間)をUTC(全世界で時刻を記録する際に使われる公式な時刻)を基準にするか、またはローカルタイムを基準にするかを選択します。
UTCはGMT(グリニッジ標準時)とほぼ同じですが、こちらの方がより正確です。
日本の場合、ローカルタイムはUTCより9時間進んでいます。UTCで正午ならば、日本は午後9時です。
複数のタイムゾーンのログファイルを作成し、後でそれらをまとめるといった場合は、UTCを基準にすることをお勧めします。
時差の問題に無関係の場合には、ローカルタイムを基準(無効のまま)にして下さい。
注意:
これは、ログファイルの作成の切り替わり時刻について設定するものです。ログファイル内で記録される日付に関しては、別の設定になります。 |
■循環ログを使用
ここを有効にすると、「最大のファイルサイズ(KB)」で指定したファイルサイズに達する毎にログファイルを作成してゆき、「ログファイルの数」で指定した本数分作成されるとファイルが循環してゆきます。
■レポートに XMLを使用
有効にすると、メッセージ部分にはXMLフォーマットされた情報の記録が含まれます。
それには、解析が簡単なフォーマットでタイムスタンプやSyslogファシリティ、プライオリティやその他追加の情報も含まれます。
XML出力フォーマットを選択した場合、その他全てのフィールド情報はXMLストリームに既に含まれていますので、それらの機能はオフにしても構いません。しかし、これは必要条件ではありません。
■タイムスタンプにUTCを使用
有効した場合は、ログファイル内のタイムスタンプは全てUTCで書き込まれます。
有効にしない場合には、ローカルタイムでログが書き込まれます。
UTCは複数のタイムゾーンでログを管理したい場合に、特に有効です。
■ファイルサイズ (KB)が設定値に達した場合にファイルを分割する
ここを有効にすると、設定したサイズに達したファイルが分割されます。
その場合、ファイル名には連続した番号が追加れます。(例:EventReporter-2005-04-26_1.log
ファイルの末尾に「_1」から順番に番号が追加されてゆきます)
■Include―フィールド名を含める
「…を含める(Include)」オプションは、どのフィールドをログファイルに書き込むかを設定します。
メッセージ本体以外の全てのフィールドについて、それを含めるかどうかをこのオプションで選択できます。有効にされたフィールドがログファイルに書き込まれます。
各フィールドはコンマで区切られます。
注意:
「日付と時間を含める」は、「デバイスのレポートに日付と時間を含める」とは異なります。
両方ともタイムスタンプであり、「タイムスタンプにUTCを使用」の設定に従って、ローカルタイムまたはUTCを使用します。
しかし、「日付と時間を含める」は WinSyslog がメッセージを受信した時間を表します。
対照的に、「デバイスのレポートに日付と時間を含める」は、実際のメッセージからタイムスタンプを取ります。
従って、報告するデバイスが持っている時間(オフになっている場合もあります)に左右されます。
さらに、Syslogメッセージの場合、デバイスが報告するタイムスタンプにはタイムゾーンの情報がありません。
従って、複数のタイムゾーンで報告するデバイスが存在する場合は、タイムスタンプの情報は、ばらばらになってしまいます。
これは、RFC 3164のSyslogの仕様によるものです。
syslogサーバは、この場合にはRFCを無視して、一貫したタイムスタンプを提供するように設定することができます。
しかし、「デバイスのレポートに日付と時間を含める」オプションは、「日付と時間を含める」と同様に信頼できるとは言い切れません。
どちらが役に立つのかは明白ではないので、両方のタイムスタンプが存在し、選択することができます。
「メッセージを含む」と「RAW メッセージを含む」は、書き込まれるメッセージ自体に対してカスタマイズを行います。
「RAWメッセージを含む」を選択すると、WinSyslog
で受信した、全く変更が加えられていないメッセージが書き込まれます。
これは、他のアプリケーションでRAWメッセージが必要とされている場合に選択します。
「メッセージを含む」を選択した場合は、タグ値(PRI部)、ホストインフォメーションなど(HEADER部)を含まない、Syslogメッセージが書き込まれます。
注意:「メッセージを含む」と「RAW メッセージを含む」のいずれかを選択するようにして下さい。
どちらも有効になっていない場合には、メッセージが全く書き込まれません。
また、両方を選択してしまうと、二重にメッセージが書き込まれますので、ご注意下さい。
|
TOPへ
|
データベースオプション |
データベースログをご利用頂くことで、
受信したメッセージをデータベースへ保存できます。
データベースに保存されたログは、メッセージビューアやカスタムアプリケ-ションで簡単に閲覧することができます。
データベースログは、ODBCに対応したデータベース(実際、WindowsのOSで使用可能な、いかなるデータベースシステムでも)へ受信したSyslogメッセージを記録することができます。
Microsoft JET
データベース(Microsoft Accessで使用)とMicrosoft
SQL サーバーとMySQLは、「データベース生成」でテーブルの作成がサポートされています。 オラクルやSybaseなど様々なシステムで正常に稼動している例もあります。
データベースログのアクションで最も重要なのは、フィールドの部分です。
デフォルトは、代表的なイベントプロパティの割り当てをデータベース列へ反映します。
ですが、この割り当ては、自由に変更することが可能です。
「フィールド名(Filedname)」は、データベース列の名称です。予め設定されたフィールド名は、Adisconのスキーマが使用するものです。必要ならば、名称は変更することが可能です。
「フィールドタイプ(Fieldtype)」は、データベース列のデータタイプです。それは、データベースで選択される列タイプを反映しなければなりません。また、このデータタイプは、保存される実際のプロパティと一致していなければなりません。例えば、syslogpriorityのような整数タイプのプロパティは、varchar列に保存することができます。一方、syslogtagのような文字列データタイプは、整数列に保存することはできません。
「フィールドコンテンツ(Fieldcontent)」は、イベントプロパティです。サポートされたプロパティリストに関しては、マニュアル内「イベントプロパティ」をご参照下さい。
データベース フィールド内の値を編集するには、列を選択して下さい。選択した列の値は、フィールドリストの上のテキストボックスで変更できます。また、「挿入」、「削除」のボタンをクリックすることで、フィールドの作成、削除を行うことが可能です。「削除」ボタンをクリックすると、選択されているフィールドが削除されます。また、上・下の矢印ボタンをクリックすることで、選択したフィールドを移動させることができますが、この移動は表面的なもので、データベースアクションの処理には、何も影響ありません。
フィールドコンテンツでは、プロパティの置換機能を使用することができます。例えば、メッセージの最初の200文字だけを保存したい場合には、"%msg: 1:200%"と設定することで可能です。
■DSN
DSNとは、データベースに接続するときに使用される、システム・データ・ソース(DSN-データソース名)の名称です。
それは(Windows NTのコントロールパネル内の)ODBCマネージャで生成されます。
ODBCデータソース アドミニストレータを開くには「データソース(ODBC)」ボタンを押してください。
ここでは、データソースの追加や削除をすることが可能です。
重要事項:ここで設定するDSNは、ユーザーやファイルのDSNでなく、必ずシステムDSNでなければなりません。また、DSNは正しい接続パラメータ(例えば、データベースのタイプや名称、サーバの名称、認証モードなど)で設定されなければなりません。
|
■データソース
このボタンをクリックすると、ODBC
アドミニストレータが開始され、データソースの追加、編集、削除を行うことができます。
■データベースを生成
このフォームでは、基礎となるデータベースのDSN、ユーザーID、パスワードを設定します。
設定後は、データベースにテーブルを作成するために 「作成」ボタンをクリックします。実行されるSQLクエリを確認するためには、「SQLを表示」ボタンをクリックします。「閉じる」ボタンにより、このフォームを終了できます。
※ 64bit OS
をご利用の場合、「データベースを生成」を実行する際には、下記ディレクトリ内にある32bitアプリケーション用の[ODBC
データソースアドミニストレーター]のシステムDSN も設定してください;
C:\Windows\SysWOW64\odbcad32.exe
■ユーザーID
データベースに接続する際に利用するユーザーIDを入力します。
ユーザーIDの設定をしなければならないか否かは、データベースシステム次第です。
(例えば、マイクロソフトのAccessは設定の必要がなく、一方、マイクロソフトのSQLサーバはユーザーIDを使うように強いられます。)
■テーブル名
ログを取るテーブルの名前を入力します。
この名前は、SQLのインサート・ステートメントを作成するために使用されるので、データベースの定義と適合しなければなりません。デフォルトは、「SystemEvents」です。
■パスワード
データベースに接続する際に利用するパスワードを入力します。
それは、「ユーザーID」で指定したアカウントで利用されるパスワードでなければなりません。
ユーザーIDのように、パスワードが必要かどうかは、データベースシステムに左右されます。
パスワードは、暗号化しても、暗号化しなくても保存できます。
ですが、暗号化して保存するようお勧めします。
■暗号化
ODBCのパスワードを暗号化して保存する際に、ここをチェックします。
チェックしない場合は、パスワードは暗号化されずに保存されます。
なるべくチェックして、暗号化させることをお勧めします。
もし、何らかの理由で、暗号化せずにパスワードの保存を行う場合は、そのセキュリティに気を付けてください。この場合、限られたアクセス権でアカウントの使用をすることをお勧めします。
暗号化をしない場合であっても、同様に限られたアクセス権でアカウントを使用することをお勧めします。ここでは、強固な暗号を適用することが出来ないからです。
■
SQLステートメントタイプ
MSSQLのストアドプロシージャ(Stored
Procedures)のINSERT、または Call
Statement(MSSQLストアドプロシージャ)のいずれかを選択できるようになりました。この機能は、MSSQLをデータベースソフトとしてご利用になる場合のみ有効です。
また、Call Statemantを選択した場合、テーブル名が自動的にプロシージャ名として使用されます。正しくパラメーターがソートされるようにして下さい。そうでないと、アクションが正常に動作しません。また、その場合、この結果はデバッグログで比較しないと分かりません。
■出力エンコード
ここでは、データベースへ書き込みを行う際に使用する文字コードを設定します。
■
接続のタイムアウト
ここでは項目名の通り、接続のタイムアウトを設定します。
■ プロパティが空の場合、NULL値を挿入
このオプションを有効にすると、プロパティが空の場合、NULL値が挿入されるようになります。
■詳細なプロパティのログを有効にする
このオプションは、SystemEventPropertiesテーブルに標準のプロパティ以外のイベント・プロパティを記録します。場合によっては、一つのイベントに複数のプロパティがある可能性があるので、このオプションを選択することで、複数のプロパティを書き込むことが可能となります。しかし、Syslogデータでは、追加のプロパティはあまり存在しません。(「Post
Propertey」アクションで独自の定義をしている場合を除いては)
追加のプロパティは、概して イベントログの監視からのSETP受信データにあります。例えば、SETPで受信したイベントログのデータには、実際のWindowsのイベントプロパティとイベントデータが含まれています。このオプションは、Syslogで受信したイベントログ メッセージには適用されませんので、注意してください。
このオプションは、有効にする前に、必要がどうかを確認するようにして下さい。
(このオプションのデータは、MoniorWareコンソールでは必要となる場合があります。)
TOPへ |
OLEDBデータベースオプション |
OLEDBデータベースアクションの設定は、ODBCデータベースログアクションと同様に行うことが出来ます。
Win32版では、MS SQL OLEDBプロバイダとJET4.0
OLEDBプロバイダは、問題なく動作することが確認できておりますが、x64版ではJET4.0 OLEDBプロバイダは現在までのところ対応しておりません。
開発元での内部パフォーマンステストの結果、OLEDB のアクションは、ODBCに比べおよそ30%の機能強化が確認できております。従って、大量のデータをデータベースに書き込みをしたい場合には、特に役立つと思われます。
このアクションにより、収集したイベントをOLEDB対応のデータベースに書き込むことが可能となります。保存されたメッセージは、カスタムアプリケーションと同様に、別のメッセージビューアで簡単に閲覧することができます。データベース・フォーマットは、変更することが可能です。これは、データベース上で更なる分析を行なう場合に非常に役立ちます。
OLEDB
データベースアクションのメイン機能は、フィールドリストです。
デフォルトでは、代表的なイベントプロパティがデータベースの列に割り当てられています。しかし、この値は、必要に応じて変更できます。
フィールド名(Fieldname)
は、データベースの列の名称です。
テーブル内には、どんなフィールドでも設定できます。デフォルトとして設定されているフィールド名は、Adisconのデータベース
スキーマで使用されるものです。必要ならば、新たにフィールドを追加することもできます。
フィールドタイプ(Fieldtype) は、データベースの列のデータ型です。
それは、データベースで選ばれる列の型を反映しなければなりません。また、この型は、実際に保存されるプロパティとの間に整合性が取れていなければなりません。例えば、syslogpriority のような整数型のプロパティは、varcharの列に保存することができますが、syslogtagのような文字列のデータ型のプロパティは、integer(整数)型の列に保存することはできません。
フィールドコンテンツ(Fieldcontent) は、イベントプロパティです。
WinSyslogで使用できるプロパティについては、イベントプロパティに関する項目をご覧下さい。
データベースフィールドの編集は、各行をクリックし、テキストボックスに値を入力、およびドロップダウンリストより値を選択することで行なえます。項目の挿入、削除は、それぞれのボタンをクリックすることで行なうことができます。削除の場合には、選択されている行が削除されます。
また、行を選択して、↑・↓のボタンをクリックすると、上・下へ移動することもできますが、この移動は、表面的なものですので、データベースアクションの書き込みには作用しません。
文字列のデータ型には、プロパティの置換を使用できます。これは、サブストリングを保存したい場合に、特に役立ちます。例えば、各メッセージの先頭から200文字を保存したい場合には、"%msg:1:200%" という値を使用します。
■ データソースの設定
ここをクリックすると、OS のOLEDBの設定画面が表示され、データソースの追加、削除、編集などを行なうことができます。
■ データベースアクセスの確認
ここでは、指定したデータソースが問題なく動作するかどうかをチェックします。
■ メインテーブル名
ログを書き込むテーブル名。この名前は、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アドレスをイベントソースとした場合、それは登録されていないので、イベントビューアは、メッセージ・ライブラリを見つけることができないと以下のメッセージをユーザーに警告をします。
(Windows
2000の例)
イベント ID (16) (ソース 192.168.1.1 内) に関する説明が見つかりませんでした。
リモート コンピュータからメッセージを表示するために必要なレジストリ情報またはメッセージ DLL ファイルがローカル
コンピュータにない可能性があります。次の情報はイベントの一部です:
|
しかし、その場合でもログメッセージは全て表示されます。
これは、詳細表示においてのみ起こります。
(この問題は、アプリケーションの動作には影響しません。)
■カスタム イベント・ソース
ここで「挿入」をクリックすることで イベントログソースをカスタマイズすることが出来ます。
デフォルトでは、「%source%」(ソース)のみ設定されています。
この機能は、「イベントログソースを置換する」機能を有効にしている場合のみ、ご利用頂けます。
ここで挿入可能なイベントのプロパティにつきましては、マニュアル2 「イベントプロパティ」をご参照下さい。
■EventType
このログと共に書き込まれるタイプ―または重要度を設定します。
Windowsシステムが利用できる値から選択して下さい。
■EventID
このIDはイベントログが書き込まれる際に使用されます。
他のプロセスに特定のメッセージに対して整合性のあるインターフェイスを与えるために、違うIDを使用することが出来ます。WinSyslog
は、使用するIDを制限しません。
けれども、 もしもオペレーティングシステムで登録されていないIDが書き込まれると、Windowsイベント・ビューアには、実際のメッセージ・テキストより先に未登録を指摘するエラー・メッセージが出ます。
このエラーを避けるために、OSでは10,000から10,100のIDが設けられています。
ですので、カスタマイズした全てのメッセージにはこれらのIDを使用することをお勧めします。
10,000以下のIDは、WinSyslog
によって生成されるイベントと衝突する可能性があるので、使用すべきではありません。(デフォルトは、10000です。)
|
■ログメッセージ
Windows のイベントログに書き込まれるメッセージを設定できます。
「挿入」をクリックし、%msg% (例) などの置換文字を追加することで、イベント・ビューアに書き込まれるイベントログのメッセージをカスタマイズすることが可能となります。
ここで挿入可能なイベントのプロパティにつきましては、マニュアル2 「イベントプロパティ」をご参照下さい。
TOPへ |
Eメール送信 |
WinSyslogで受信したメッセージをメール送信する際の設定を行います。
メッセージを電子メールで送信するには、このオプションで正しく設定を行う必要があります。
■メールサーバー
メッセージの転送の際に使用するメールサーバー名かIPアドレスを指定します。
ここでは、受信者にメール配送ができるサーバーを設定するようにしてください。
WinSyslog は、標準のSMTPメールサーバーとの接続を前提としています。
■バックアップ メールサーバー
この機能を有効にすると、メインのメールサーバーへの接続に失敗した場合に、バックアップとして設定された別のサーバーへの接続されるようになります。
バックアップのメールサーバーは、そのセッションの間使用されます。
どれくらいのメールがバックアップサーバーで処理されるかは、セッションがクローズされるまでに実行された Eメールアクションの数に依存します。
このセッションがクローズされると、その後は、再びメインのサーバーへの接続が試みられます。
(ここでも接続が確立できない場合には、再度バックアップのサーバーが使用されます)
このバックアップのサーバーへの接続にも失敗した場合に、エラーが作成されます。
■ポート
メールサーバーの接続ポートは、通常25です。こちらは変更することもできます。
その場合は、あなたのメールサーバーが使用しているポートを指定してください。
■送信者
メッセージの送信者のEメールアドレスを指定します。
SMTPサーバが受信できる、有効なアドレスを指定して下さい。
■受信者
受信者の電子メールアドレスを指定します。
複数の宛先へメール送信したい場合には、このフィールドにすべての電子メールアドレスを入力して下さい。それぞれのアドレスは、スペース、セミコロンまたはコンマにて区切って下さい。
■題名
送信メールの題名を指定します。この題名は、各メッセージの送信に使用されます。
イベントの詳細を表示するためにイベントプロパティを組み込む事も可能です。
この機能は、題名でメッセージの内容が判断できるので、携帯電話などのモバイル機で受信する際に特に役立ちます。置換文字列の変換後、題名の最大値は255文字です。
それ以上の文字は切り捨てられます。ですが、メールシステムの制限により255文字以下で題名を切り捨てる可能性もあるという点に注意してください。
そのため、モバイル機で受信する場合には、題名は80文字以下になるように設定することをお奨めします。
メール本体には完全なイベント情報(ソース・システム、ファシリティ、プライオリティ、メッセージテキスト)が含まれています。
メッセージ本体のサイズには制限がないので、常に完全なメッセージを受信できます。
「挿入」をクリックし、%msg% (例) などの置換文字を追加することで、題名に書き込まれるイベントのメッセージをカスタマイズすることが可能となります。
ここで挿入可能なイベントのプロパティにつきましては、マニュアル2 「イベントプロパティ」をご参照下さい。
受け取ったひとつのメッセージに対して、一通のメールを送信します。
Eメール送信は、重要な通知やアクションにたいして意味を持ちます。(重要なイベントの発生時に携帯メールに送信して、知らせるなど・・・)
Eメールの報告を提供する事自体には、あまり重要な意味はありません。
■
メールプライオリティ
ここでは、送信するメールの優先度を設定することができます。「low」、「normal」、「high」のいずれかを選択できます。
■
DateヘッダにUTCを使用
WinSyslog が通知するメールのヘッダの基準時刻を設定します。
デフォルトでは、ここは有効になっておりますので、DateヘッダにはUTCタイムの時刻が入ります。
UTCタイムに対応していないメールソフトをご利用の場合には、この機能を無効にしてください。
■従来の題名の処理を有効にする
ここでは、題名の処理の方法を指定します。
ここを有効にすると、従来の置換文字列を使用する処理が行われます。
有効にしない場合には、上述のイベントプロパティを組み込む題名処理が行われます。
ここを有効にした場合には、以下の置換文字列を題名に組み込むことができます:
%s
|
メッセージを送信したソース・システムのIPアドレス、もしくはホスト名 (「ホスト名の解決」の設定に左右されます)
|
%f
|
受信したメッセージのファシリティコードの数値
|
%p
|
受信したメッセージのプライオリティコードの数値
|
%m
|
メッセージ本体
注意: これは完全なメッセージのテキストなので、かなりの長さになる場合もあります。
従って、255文字を超えた場合には以下が切り捨てられます。このような場合、%m 以降の情報が省略されてしまいます。
このような理由から、私達は%m という置換文字列を題名の最後で使用することをお勧めします。
|
%%
|
ひとつの%文字列へ変換されます。
|
上図のような置換文字列の設定がされている場合、以下のような題名が受信できます。
題名のテキストボックスに「Event from %s:%m」と設定した場合には、下記のような題名でメールが送信されます。(これは、“172.16.0.1”から“This is a test” という内容のメッセージを受信したときの題名です):
Syslog from 172.16.0.1: This is a test
|
一方、プロパティモードでは、イベントプロパティからのプロパティを組み込み、修正することが可能です。詳細は、「イベントプロパティ」についての箇所をご参照下さい。
プロパティモードでは、例えば、以下のような題名を指定することが可能です。
「Mesg:’%msg:1:15’From:%fromhost%”」と設定し、「This is a lengthy test message」というメッセージを172.16.0.1から受信すると、下記のような題名になります:
Mesg:’This is a lengt’ From:”172.16.0.1”
|
メッセージは、%msg:1:15
にて文字列の1文字目から15文字目までと指定されていますので、16字目以降(「hy」の2文字)は切り捨てられます。
■メールメッセージ フォーマット
ここでは、メールメッセージ本体のフォーマットを設定します。
「挿入」をクリックし、イベントのプロパティを組み込むことができます。
このオプションは、「メール本体にメッセージ/イベントを含む」を有効にした場合のみ、使用することが可能です。
|
■接続のタイムアウト
このオプションは、どんどん入って来る多数のメッセージを一つのEメールのメッセージとして統合するべきかを制御します。
指示されたタイムアウトに達するまでは、サーバのSMTPセッションは開かれたままになっています。ここでは、秒単位でなくミリ秒単位で値を入力してください。
新しいイベントが設定されたタイムアウトに達するまでに受信された場合は、前のイベントと同じEメールメッセージに含まれます。それからタイムアウトは再起動されます。
このように、接続のタイムアウトの時間内に受信したイベントはいずれも一つのメールにまとめられます。
これは、メッセージの大量なバーストが予想され、それらのメッセージが少数のEメールにまとめられるべきである場合に最も適切です。さもなければ、管理者のメールボックスは多数のメールにより、すぐにオーバーフローしてしまいます。
接続のタイムアウトでは0から4000までの値を入力できます。
4000より大きな値は、SMTPサーバ・パフォーマンスに影響を及ぼしてしまうなど、予測できない結果につながる可能性もあるので、サポートしていません。
接続のタイムアウトにおいて0を設定した場合は、各イベントが個別のメッセージとして送信されます。
■出力エンコード
ここでは、メール送信を行う際に使用する文字コードを設定します。
■メールサーバにSSLで接続する
SMTP over SSLが利用可能となりました。
この機能を利用する場合には、465番ポートを使用してください。
また、この機能を有効にした状態でSSL非対応のSMTPサーバーへメール送信を行った場
合には、アクションは失敗してしまいます。(メールは届きません)
■SMTP
認証を使用
ここは、サーバでSMTP認証が必要な場合に有効にします。
多くのサーバ管理者は、SPAM対策のために 認証されたユーザー以外の接続は許可していません。
サーバが匿名の投稿(anonymous posting)を許可しないよう再設定されると、それにより既存のアカウントが使用できなくなる可能性もあります。
サーバがSMTP認証を必要(またはサポート)する場合は、この設定を有効にして、下のテキストボックスにユーザーIDとパスワードを入力して下さい。
メールサーバーが認証をサポートしていない場合は、ここは有効にしないで置いて下さい。
ここ設定は、認証に対応している場合は、有効することをお勧めします。
たとえ、現在のサーバの設定が認証されていない接続を許可していても、(SPAMの問題が拡大すると)将来的には状況が変わってゆく可能性が十分にあります。
もしも、すでに認証を使用している場合は、そのようなサーバの設定変更は何も影響を与えません。ですが、認証を使用していない場合は、メールサービスが止まってしまう恐れがあります。
■メール本体にメッセージ/イベントを含む
このチェックボックスでは、syslogメッセージがメッセージ本文に含めるかどうかを制御します。
チェックをしない場合は、本文にSyslogメッセージは含まれません。
このオプションは携帯などのモバイル機器で(WML対応の場合は特に)、非常に役に立つ機能です。これらのデバイスは、たいてい表示するデータの量に制限があります。
メッセージ自体は表示しないものもあります。
したがって、このオプションはメッセージ本体を送信したときに限って意味をなします。
そのため、必要がない場合は、ここでオプションをオフにできます。
オフにした場合は、題名に適切な置換文字を使用してください。
WMLに対応した機器がメッセージ本体を受信できる場合であっても、このオプションをオフにした方が良い場合もあります。WMLやWAPは比較的コストがかかります。
生成されたメッセージは、長くなってしまう恐れがあります(メッセージソースに左右されますが)。
したがって、このオプションの機能をオフにすることも適当である場合もあります。
■レポートにXMLを使用
ここを有効にすると、受信したイベントはXMLフォーマットでメールに含まれます。
その場合、オリジナルのタイムスタンプやファシリティ、プライオリティなどの全ての情報が含まれます。メールがメッセージを解析する自動化されたシステムに送られる場合、XMLフォーマットは特に役に立ちます。
チェックしない場合は、メールにはプレーンテキスト・メッセージが含まれます。
TOPへ |
Syslog 転送 |
ここでは、受信したメッセージを別の
Syslog サーバーへ転送するための設定を行います。
▲Syslog
転送アクションで TCP を選択した際の画面
■Syslog
サーバ
Syslogメッセージを送信する相手先システムの名前(DNS名)またはIPアドレスを指定します。
■Syslog
ポート
syslog転送する際のポート番号を指定します。
確信がない場合には、一般的に使用されるデフォルトポート:514のままにして置いてください。別のポートは、例えばセキュリティへの配慮が必要な場合などに使用されます。
■
Syslog サーバーへの接続が切れた際、バックアップのサーバーに切替える
ここを有効にすると、Syslog
サーバーへの接続が確立できない時に、設定したバックアップのサーバーのIPアドレス、ポート番号のサーバーに自動的に切替わります。
このオプションは
TCP 通信の場合のみ使用可能なので、ご注意ください。
■プロトコルタイプ
syslogメッセージの転送方法としては、UDP、TCPまたはRFC 3195 RAWが使用可能です。
一般的に、syslogメッセージは、デフォルトである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分)の場合、メッセージが送信されないまま30分経過すると、接続が切られるようになります。もしも、処理するメッセージが少ない場合には、これより低い値を設定しても結構です。
■
転送時の Syslog の処理
ここでは、Syslog メッセージの処理方法を下記4つのオプションから選択します。
・RFC3164(従来の処理)
・RFC5424(最新の Syslog 基準;今のところ未対応デバイスが多い)
・加工しない(受信したメッセージを処理せずそのまま転送)
・カスタム Syslog ヘッダ(ヘッダの内容をカスタマイズ)
<メッセージ オプション>
■出力エンコード
Syslog
メッセージ転送の際に使用する文字コードを設定します。
■メールメッセージ フォーマット
オプション
ここでは、メールメッセージ本体のフォーマットを設定します。
-
カスタムフォーマット
メッセージフォーマットのボックスで転送するメッセージの編集を行います。
デフォルトは、%msg% のみ設定されています。
「挿入」をクリックして、メッセージに加えたいプロパティを追加します。
-
レポートにXMLを使用
ここを有効にすると、転送されたsyslogメッセージは完全なXMLフォーマットされた情報記録となります。その場合、オリジナルのタイムスタンプや発信元システムなどの情報が追加されますが、見た目には読みづらくなります。ですが、この形式は、解析を容易に行うことができるようになります。
受信するシステムがXMLデータの解析が可能である場合は、特にこの機能は役に立ちます。
しかし、それは別な方法で転送されることができない追加の情報を含めるので、同様にマシンだけでなく人の役にも立ちます。
- XMLの表記コードをMWAgentとして転送する
MWAgent(MonitorWareエージェント)は、イベントの特別なXML表記をサポートしています。ここを有効にすると、転送されたsyslogメッセージにXML表記が使用されます。その場合、オリジナルのタイムスタンプや発信元システムなどの情報が追加されますが、見た目には読みづらくなります。ですが、この形式は、解析を容易に行うことができるようになります。しかし、このオプションは、実験的なものであり、正式なものではありません。
■別のSyslogサーバに転送する場合のSyslogソースの追加
ここをチェックすると、発信元のシステムの情報がメッセージに追加されます。
これにより、受信者が発信元を追跡する事ができます。
注意:
このオプションは、RFC 3164と互換性がありません。
インタラクティブ Syslog ビューアにメッセージを転送することを目的とする場合には、この機能を使用することをお勧めします。
|
<圧縮 オプション>
■ データの圧縮にzLib 圧縮を使用する
ここでは、Syslog メッセージの圧縮のレベルを設定できます。
< Syslogメッセージの圧縮に関して >
この機能は、フォーマットを十分に理解されている方(受信者)に対してのみご利用下さい。
圧縮を有効にすると、低帯域幅の環境でも帯域幅を節約することができます。ただし、どれだけ節約できるかは、メッセージによります。(全く節約できないケースもありますが、一方半分ほど節約できるケースもあります)
検証では、WindowsイベントログをXMLフォーマットで送信した場合に、50%ほど帯域幅を節約できました。
非常に小さなメッセージは、まったく圧縮されません。また、XMLフォーマットでない場合、Syslog送信はだいたい10~25%ほどに圧縮されます。
TCPによる圧縮送信の場合には、特別なモードにする必要があります。このモード(syslog-transport-tls)は、これから公開されるIETFの仕様がベースとなっています。ただ、このモードはまだ完成されたものではないので、実験的な試みとなります。その結果、今後リリースされる製品でこのモードが使用されるかどうかはわかりません。また、別のモードが今後製品に組み込まれた場合、このモードとの互換性は保証できかねます。
ただ、この機能自体はしっかりしていますが、実験的な機能であることをご理解頂いた上でご利用下さい。
|
<カスタム Syslog ヘッダ>
転送時の Syslog の処理で「カスタム Syslog
ヘッダ」を選択した際、ここで設定することができるようになります。「Insert」をクリックし、書き込むプロパティを指定します。
<Syslog TLS>
■
SSLの有効化/TLSの暗号化:
ここを有効にすると、SSLに対応していないサーバーへはアクセスできなくなります。
暗号化に使用される方法は、RFC5424 (Transport
Layer Security (TLS) Transport Mapping for
Syslog) に互換性があります。
■
TLSモード
次のモードから選択できます;
・匿名認証
デフォルトでは、このモードになっています。
選択するとデフォルトの証明書が使用されます。
・証明書を使用
証明書を指定することができます。
OpenSSLなどにより作成した証明書が必要となります。
■
共通の CA PEM の選択
ここでは、CA(Certificate
Authority;認証局)を指定します。
Syslog
を送信する側・受信する側で同じCAを使用しなければなりません。
■
PEM の証明書を選択
クライアントの証明書(PEM フォーマット)を選択します。
■
PEMの鍵を選択
クライアント証明書の鍵(キーファイル)を選択します。
■
Syslogサーバーへの接続に失敗した場合、ディスクキューを使用する
(TCP選択時のみ)
この機能を利用すると、リモートの Syslog サーバーへの接続が失敗した際に、Syslogメッセージがローカルの Temp ファイルにキャッシュされるようになります。保存先のフォルダは変更できます。Syslog 転送アクションを複数設定している場合には、そのアクション毎にGUIDにより個別のファイル名が生成されます。接続に失敗した Syslog サーバーへの接続が確立されると、自動的にキャッシュされたメッセージが送信されるようになります。
Syslogメッセージをキャッシュに入れている間に
WinSyslog サービスを起動した場合、その起動中にSyslogサーバーが復旧しても確認ができません。(再度、アクションが実行される際に
Syslogサーバーとの接続が確認され、接続されている場合にはキャッシュされたメッセージが送信されます。)
キャッシュのサイズは、特に制限はありません(ディスクのサイズに依存します)。
デフォルトにより、ファイルは 10MB ごとに分割されます。
(この値は、変更することが可能です。最大 2GB まで設定可能です)
TOPへ |
Net
Send |
ここでは、Net Send オプションを設定します。
“Net Send”アクションを使用すると、Windowsの “net send” 機能を使い短い警告メッセージを送信することができます。これらのメッセージはベストエフォートをベースにして送信されます。
受信者にメッセージが届くと、それらは受信者のマシンのポップアップ メッセージボックス内に現れます。
届かない場合は、単にそれらは破棄されます。バッファリングは行われません。
従って、ルールエンジンはメッセージが届けられたかのチェックを行いません。
「net send」でのレポート送信の問題によってアクションにエラーが発生したというフラグを立てることは決してありません。
■ターゲット
ここでは、受信者として設定を行いたいWindowsユーザー名、NETBIOS マシン名、またはIPアドレス(10.1.1.1のような形式で)を指定します。
■送信メッセージ
設定したターゲットに対して送信するメッセージを指定します。 ここでは、メッセージの内容をプロパティで設定することも可能です。(「挿入」をクリックして、メッセージに加えたいプロパティを追加します。)
すると、下記のようなメッセージウィンドウが現れます:
TOPへ |
コミュニケーションポートに送信する |
このアクションにより、コミュニケーションデバイスに文字列を送信することが可能となります。
つまり、シリアルポートでメッセージの送信を行うことができます。
■タイムアウト制限
ここでは、 メッセージ送信の処理のタイムアウトを設定します。
ここで設定した時間内にメッセージ送信を行えなかった場合、アクションは途中で停止されます。デバイスによっては、不安定な状態になるかもしれません。
■メッセージの送信ポート
ここでは、実装されているデバイスのポートを指定します。
一般的には、COMxポートのうちの一つです。リスト・ボックスには、ローカルマシンで検出された全てのポートが表示されます。
リモートマシンを設定している場合には、この値を別の値に合わせる必要がある場合もあります。
■ポート設定
デバイスのポート設定に合うように設定を行って下さい。詳細は、各デバイスのマニュアルをご覧下さい。
■1秒当たりのビット数
1秒当たりのビット数は、110から256000まで設定可能です。デフォルトは57600に設定されています。
■データビット
データ ビットでは、送受信の1文字に含まれるビット数を指定します。
■パリティ
ここでは、以下の値からパリティを設定します。
1.
|
Even
Parity
(偶数)
|
2.
|
Mark
Parity
(マーク)
|
3.
|
No Parity
(なし)
|
4.
|
Odd Parity
(奇数)
|
5.
|
Space
Parity
(スペース)
|
■ストップビット
ここでは、以下の値からストップビットを設定します。
1.
|
1
stop bit
|
2.
|
1.5 stop bits
|
3.
|
2 stop bits
|
■DTRフロー制御
DTR (data-terminal-ready)を設定します。以下の値から設定することができます。
1.
|
DTR_CONTROL_DISABLE –
デバイスが開いていて、使用不能な際、DTRラインを使用不能にします
|
2.
|
DTR_CONTROL_ENABLE -
デバイスが開いていて、使用可能な際、DTR ラインを使用可能にします
|
3.
|
DTR_CONTROL_HANDSHAKE – DTRのハンドシェイクを可能にします
|
■RTSフロー制御
RTS (request-to-send)を設定します。以下の値から設定することができます。
1.
|
RTS_CONTROL_DISABLE -
デバイスが開いていて、使用不能な際、RTSラインを使用不能にします
|
2.
|
RTS_CONTROL_ENABLE -
デバイスが開いていて、使用可能な際、RTSラインを使用可能にします
|
3.
|
RTS_CONTROL_HANDSHAKE - RTSのハンドシェイクを可能にします。 ドライバーは、「タイプアヘッド(入力)」バッファが1/2 未満の場合、RTSラインを上げて、バッファが3/4以上の場合は、RTSラインを下げます。
|
4.
|
RTS_CONTROL_TOGGLE –
バイトが通信に利用可能な状態では、RTSラインが高くなり、バッファリングされた全てのバイトが送信を完了すると、RTSラインが低くなります。
|
■送信メッセージ
ここでは、デバイスに送信されるメッセージを送信します。
直接テキストを入力したり、現在のイベントから全てのプロパティを組み込んだりできます。
ここで挿入可能なイベントのプロパティにつきましては、マニュアル2 「イベントプロパティ」をご参照下さい。
TOPへ |
SETPで転送 (ベーシックエディションは対応していません) |
このダイアログは、転送に関するオプションを設定します。
「SETPで転送」のアクションでは、メッセージを SETP サーバ(WinSyslog エンタープライズで作成可能なサービス)に転送する事が出来ます。
■サーバ名
WinSyslog は、ここで設定する名前によってSETPサーバを認識します。
■デフォルトのSETPポート
SETPサーバは、 このポートで入ってくる要求を待っています。デフォルト値は 5432です。
注意:ここで設定されるSETPポートは、サーバ(WinSyslog
エンタープライズ)で設定されるポートに合わせなければなりません。それらが合わない場合は、SETPセッションを開始する事はできません。ルールエンジンは、NT イベントログにこれを記録するでしょう。
|
■SSLの有効化/TLSの暗号化
ここを有効にすることで、このアクションは、SSL、TLS SETPサーバに接続することができるようになります。ただし、ここを有効にすると、このアクションはSSL非対応のSETPサーバには接続できなくなります。
■データの圧縮に
zLib圧縮を使用する
ここを有効にすると、zLib圧縮が使用できます。この場合、STEPの受信側がzLib圧縮をサポートしている必要があります。zLib圧縮に対応していない場合には、これは機能しません。
■圧縮レベル
高いレベルの圧縮が結果的に良いですが、その場合にはパフォーマンスが低下します。
■セッションタイムアウト
SETPサーバーへのセッションがオープン状態である場合の最大の待ち時間を指定します。
<高度な接続オプション>
■接続のタイムアウト
接続されるまで、または接続が切られるまでにかかる最大の待ち時間を設定します。
■送信/受信 タイムアウト
データの送受信時に、ここで設定したタイムアウトが適用されます。
注意:このオプションが有効になっている場合、このアクションはSSL SETPに非対応のサーバーには接続することができません。
|
<
SETPについて
>
SETPは、“Simple
Event Transfer Protocol” の略です。
SETP
は、MoniorWare
エージェントのために Adiscon社により開発されたプロトコルです。
Adiscon製品(MoniorWare、WinSyslog、EventReporterなど)間の通信をより確実にするよう設計されております。
特に、MoniorWare
コンソールへデータを転送する際に、このプロトコルを使用した通信が役立ちます。*MoniorWare
エージェント、MoniorWare コンソールとも弊社では扱っておりません*
EventReporter
プロフェッショナルでは「SETP転送」アクションが設定できます。
WinSyslog エンタープライズでは、「SETP転送」アクション、および「SETPサーバー」サービスを設定すること
が可能です。
「SETP転送」アクションと「SETPサーバー」サービスを組み合わせることで、SETPを利用したメッセージ送受信が実行できます。
SETP通信では、クライントとサーバーの間で同期通信がなされます。
SETPでは、イベントは、イベントログの生成元のシステムと同じ状態で転送することができます。
また、SETPはTCPをベースにした通信プロトコルですので、より確実な通信を行えます。
(SETPは、先に送信したメッセージが受信・処理に成功してから、次のメッセージを送信します。)
TOPへ
|
SNMPトラップの送信 |
ここでは、SNMPトラップの送信に関する設定を行います。
■
SNMPバージョン
ここでは、SNMPのバージョンを指定します。
■
エージェント受信機
SNMPトラップを受信するエージェントを指定します。
ここでは、IPアドレスを指定します。
■
SNMPポート
ここでは、探査するポートを指定します。
実際に使用する値については、サーバーリファレンスを参照下さい。
たとえば、概して、メールサーバーは25ポート、Webサーバーは80ポートを使用します。
■ コミュニティ
メッセージの属するSNMPコミュニティを指定します。
SNMP V1特定パラメータ
このグループボックスでは、SNMPバージョン1に関するパラメータを確認できます。
■ エンタープライズOID
ここでは、エンタープライズOIDを指定します。
OIDの選択には、「ブラウザ」オプションを使用できます。ここをクリックすると下記画面が現れます。
■ 一般名
coldStart(0), warmStart(1), linkDown(2),
linkUp(3), authenticationFailure(4), egpNeighborLoss(5) や
enterpriseSpecific(6) のようなトラップのGeneric Name を指定することができます。
■ 特定タイプ
トラップの追加コードを定義できます。こちらも同様に整数値です。
SNMP変数
SNMPトラップに送信する変数。
トラップコードをご存知の場合、それらを入力することも可能です。そうでない場合は、SNMP MIBブラウザをご利用下さい。
■ 変更可能なOID
SNMPトラップのOID。
利用できるOIDについては、MIBブラウザのリストをご利用下さい。
■ 変更可能なタイプ
OCTETSTRINGやINTEGERなどのタイプ。
このタイプによっては、変数を正確にフォーマットする必要があります。(IPADDRなど )
■ 変更可能な値
タイプによってフォーマットされる必要があります。
TOPへ
|
RELP
送信 (WinSyslog 10.1 で追加されたアクション)
|
このアクションは、Syslog
転送アクションと似ていますが、新しいプロトコル(RELP;The
Reliable Event Logging Protocol)を使用するという点が異なります。
*受信側も RELP プロトコルに対応していなければなりません。
RELP 対応のサーバーと使用することで、今まで以上に信頼できる通信を行うことが可能になります。
ただし、RELP
はネットワーク経路の信頼性を高めたプロトコルですので、サービスのダウンなどローカルで発生した問題からメッセージを守ることはできませんので、ディスクキャッシュ・キューのオプションを併用するようにしてください。
■
RELPサーバー名
RELPメッセージの送信先のサーバー名、または
IPアドレスを入力します。
■
RELP ポート
RELPサーバーと通信する際に使用するポート番号を指定します。
不明な場合には、デフォルト(20514)のまま使用してください。
別のポートは、例えばセキュリティへの配慮が必要な場合などに使用されます。
ポート番号の代わりにサービス名を指定することもできます。
その場合、サービス名は、ソケットサービス データベースから検索されます。
■
セッションタイムアウト
RELPサーバーへのセッションがオープン状態である場合の最大の待ち時間を指定します。
■
送信/受信
タイムアウト
ここには、リモートサーバーの応答の最大の待ち時間を入力します。
応答がないまま設定した時間が経過すると、接続は切られ、(ルールの設定により)再試行されます。
このオプションは、なんらかの原因により、リモートのシステムとの接続が切れ、そのことを送信側が検知できない場合などに役立ちます。(例えば、ファイアーウォールの設定などにより接続できなかった場合など・・・)
■
メッセージフォーマット
ここでは、送信したいメッセージを入力します。デフォルトは、%msg%
となっています。
ここで挿入可能なイベントのプロパティにつきましては、マニュアル2 「イベントプロパティ」をご参照下さい。
TOPへ
|
プロパティの設定 |
ここでは、プロパティの設定を管理します。
「プロパティの設定」アクションにより、入ってくるメッセージのプロパティのいくつかを修正することができます。これは、管理者が二つのデバイスに同じ名前を付け直したい場合などは特に役に立ちます。
注意: プロパティを変更すると、このアクションが実行されるとすぐに値は変更されます。
プロパティの設定のアクション実行前には変更しません。それから、以前の値は、その後は利用できないので、設定後は全てのアクションとフィルタの条件が新しい値を使用します。
従って、例えば名前の付け直しを行いたいような場合は、プロパティの設定のアクションをルールベースの先頭に持ってくるようにして下さい。
|
■プロパティ タイプの選択
変更したいプロパティのタイプを選択します。
「Insert」をクリックすると、プロパティのリストが表示され選択することができます。
■プロパティに値を設定
プロパティに割り当てられる新しい値を入力します。
有効なプロパティ値ならば、どんなものでも入力することが可能です。
|
ルールセットの呼び出し |
このダイアログは、ルールセットの呼び出しオプションを設定します。
このアクションは、存在しているルールセットの中から、特定のルールセットを呼び出すために設定します。このアクションが実行されると、ルールエンジンは、通常の処理を止め、ここで指定したルールセットを呼び出します。(そのルールセットには、ルールが含まれいます。)そして、呼び出されたルールセット内で定義されたルールが全て実行されます。その後、通常の処理に戻ります。(処理を止めた時点に戻ります。)具体的には、下記の例をご参照下さい。
仮に、Rule1 には、アクション1とアクション2が存在するとします。 アクション1には、この「ルールセットの呼び出し」アクションが下図のように設定されています。Rule1のフィルタの条件が真(True)の場合、アクション1が実行されます。アクション1は、「ルールセットの呼び出し」が設定されているので、そこで設定されているルールセット(Default)を呼び出し、そのフィルタの条件が実行されます。そこで真(True)となった場合には、ルールセット(Default)配下のアクションを全て実行し、アクション2に戻ります。もしも、呼び出したルールセットのフィルタの条件で偽(False)となった場合は、ルールセット(Default)配下のアクションは全く実行されず、アクション2に戻ります。
■呼び出すルールセット
呼び出しを行うルールセットを選択します。 ルールセットが1つの場合には、このアクションは使用できません。
TOPへ |
ステータスの設定 |
このダイアログは、ステータスの設定オプションを設定します。
各々のインフォメーション・ユニットは特定のプロパティ(例えばイベントID、プライオリティ、ファシリティなど)を持っています。そして、これらのプロパティは、いくつかの値を持っています。
イベントIDがプロパティ値01を持つと仮定します。既存のプロパティの中に「新たに自分で選んだプロパティを追加」したい場合には、このステータスの設定アクションでそれを行うことが可能です。
下図のように、新たにプロパティを作成し、有効な(適当な)値を割り当てることができます。
下図では、プロパティ名を「CustomerID」、プロパティに値を設定において「01」と設定しています。このアクションでプロパティを作成すると、それに対するフィルタを定義することができます。
複雑なフィルタを設定するために、製品の中には内部のステータスリストがあります。
注意: プロパティを変更すると、このアクションが実行されるとすぐに値は変更されます。
ステータスの設定のアクション実行前には変更しません。それから、以前の値は、その後は利用できないので、設定後は全てのアクションとフィルタの条件が新しい値を使用します。
従って、例えば名前の付け直しを行いたいような場合は、ステータスの設定のアクションをルールベースの先頭に持ってくるようにして下さい。
|
■プロパティ名
プロパティ名を入力します。
ここで設定すると、ルールベースの内部(フィルタの条件とアクション)で使用することができるようになります。
■プロパティに値を設定
この値は、プロパティに割り当てられます。
有効なプロパティタイプ値であれば、どんな値でも入力できます。
TOPへ |
ステータス変数算出 |
このアクションは、内部処理に関するものです。
この機能は、カウンタベースで作用するルールセットに対して必要なものです。
ここでは、ステータス変数算出の管理を行います。
■
ステータス変数
ステータス変数名を指定します。ここでは、プロパティの置換(「挿入」をクリック)機能が使用できます。
<オプションタイプ>
■
増加値(+)
オペレーション値によって、値が増加されます。
■
減少値(+)
オペレーション値によって、値が減少されます。
■
オペレーション値
使用するオペレーション値を設定します。
|
ホスト名解決オプション |
このアクションにより、全てのサービスでホスト名の解決を実行させることが可能となりました。
■
名前解決するソースプロパティを選択
ここでは、名前解決を実行するプロパティを選択します。
テキストボックスの右にある Insert をクリックし、プロパティ値を選択して下さい。
■
名前解決の保存先プロパティ
ここでも同じようにテキストボックスの右にある Insert をクリックし、名前解決の保存先のプロパティを選択します。
■
既にソースプロパティに名前が入っている場合、完全な名前解決(FQDN)を行なう
ここを有効にすると、(可能な場合)FQDNを実行します。
例えば、ソースプロパティが既に「servername」と表示されている場合に、この機能を有効にすると完全な名前解決が行なわれ、「servername.mydomain.com」などと表示されるようになります。
■解決されたホストエントリをキャッシュに入れる
ここを有効にすると、名前解決されたホストエントリをキャッシュに入れることができます。
TOPへ |
Post-Processイベント |
Post-Processイベントアクションにより、一旦処理されたメッセージの再解析が可能となります。
このような再解析は、標準でないSyslogフォーマットを使用している場合や、メッセージから特定のプロパティを取り出したい場合に、非常に役に立ちます。
Post-Processアクションは、受信したメッセージを取り出し、解析マップにより解析を行います。解析マップには、メッセージのどの位置に、どのタイプのどのプロパティが存在するかが示されています。
メッセージが実際に解析マップに適合する場合、全てのプロパティが引き出され、イベントの一部としてセットされます。
メッセージが解析マップに適合しない場合は、最初に適合しなかったエントリで 解析は停止します。
■
テンプレート
解析マップは、非常に複雑です。
解析マップとのやり取りを簡単にするために、それらはXMLファイルで処理されます。
■
解析マップ エディタ
ここでは、上図のデータグリッドにおいて、テキストボックスの編集のみ行うことができます。グリッドのエントリを選択すると、その値はテキストボックスで更新されます。そこで行われるどんな編集も自動的にグリッドに反映されます。「挿入」をクリックすると新たに項目が追加され、「削除」をクリックすると選択されている項目が消去されます。
■
Property
解析されるプロパティ名です。プロパティのリストボックスには、予め実装された標準とイベントプロパティが含まれています。しかし、ここには新たにプロパティを追加することができます。新たにプロパティを追加する際には、プロパティ名の頭に「u-」を付けることをお奨めします。そうすることにより、既存のプロパティと重複することを避けられます。
例えば、「MyProperty」という名のプロパティを追加したい場合には、「u-MyProperty」とするようお奨めします。
「Filler」という名のプロパティは、既に固定されています。このプロパティに振り分けられる全ての値は、破棄されてしまいます。このプロパティは、不要な充填文字などを取り除きたい場合に有効です。
■
Type
メッセージから解析されるタイプです。
例えば、「Integer」タイプは、メッセージから1つの整数を解析します。また、「Word」タイプは、次の語を解析します。(ただし、次の語がスペースの場合を除く)
■
Value
タイプの中には、値を追加する必要がある場合もあります。その際には、ここで値を追加します。
■
ルールのメッセージ・プレビュー
ここは、読み込み専用のボックスです。
設定された構文解析ルールにマッチする仮定のメッセージを表示します。
TOPへ |
プログラム開始 オプション |
ここでは、プログラム開始オプションを設定します。
「プログラム開始」のアクションにより、外部のプログラムを起動することが出来ます。
exeファイルやバッチファイル(BAT)、VBスクリプト(.vbs)などの有効なWindowsの実行可能プログラムであればどんなものでも起動できます。
■実行コマンド
ここでは、実行させたい実際のプログラムファイルを指定します。
有効な実行可能ファイルであればどのようなものでも指定可能です。システムの検索でファイル名を見つけられる場合、関連するファイル名を指定できます。
■以前のパラメータ処理を使用
ここを有効にすると、従来のパラメータの処理が使用されます。ここが無効になっている場合には、プロパティの処理が使用されます。
■パラメータ
これらのパラメータは、実行されるプログラムに渡されます。
そして、それらは、コマンド・ライン・パラメータとして渡されます。それらには特定のフォーマットはありません-それらの解析はスクリプトによって左右されます。
パラメータは、イベントの詳細でカスタマイズするために、置換文字列を設定することも可能です。これにより、イベントデータがスクリプトに渡されます。以下の置換文字列を使用できます:
%d |
日付と時間(ローカルタイム) |
%s
|
メッセージを送信したソース・システムのIPアドレス、もしくはホスト名 (「ホスト名の解決」の設定に左右されます)
|
%f
|
受信したメッセージのファシリティコードの数値 |
%p |
受信したメッセージのプライオリティコードの数値 |
%m |
メッセージ本体 |
%% |
ひとつの%文字列へ変換されます。
|
例として、「e1”%s””%m”」と設定し、172.16.0.1から「This is a test.」と受信した場合は、スクリプトは3つのパラメータで開始されます。
1つ目のパラメータは「e1」で、スクリプトに何らかの意味を持つと仮定します。2つ目は、「%s」なので IPアドレス(172.16.0.1)に変換され、3つ目は、「%m」なので メッセージ本体(「This is a test.」)になります。
二つの引用符(“)で置換文字列を挟むことによって、1つのパラメータとして処理されます。引用符が抜けてしまうと、メッセージなどはバラバラになってしまいます。
置換文字列を使用する場合には、この引用符を入力することを忘れないで下さい。
|
■タイムアウト
プログラムが実行されるとき、サービスは次のアクションを行うまで、そのプログラムの終了を待ちます。この処理は、正しい順番ですべてのアクションを確実に実行するために必要になります。
外部のプログラムは、限られた時間内にのみ動作すべきです。
もし、何らかの理由でそれが妨害された場合は、それ以降の処理は実行されないでしょう。
したがって、タイムアウトの設定は必ず行わなければなりません。設定したタイムアウトの時間を過ぎてもプログラムが終了しない場合は、ルールエンジンはそれをキャンセルします。さらにアクションが失敗したというフラグが立てられ、それ以降の処理が続けられます。
重要:
タイムアウトの値は最高で30秒まで設定はできますが、外部プログラムの実行時は、5秒以下に制限することをお勧めします。
そうしないと、全体的なパフォーマンスに多大な影響を及ぼしてしまう可能性があります。
平均の実行時が5秒である場合、デフォルトの設定値10秒という値は、システム活動が激しいときでも、そのプログラムの終了を待つことができることを保証します。
|
パフォーマンスを考慮して、「プログラム開始」のアクションは、頻繁に適用されないルールに対してのみ使用することをお勧めします。
TOPへ |
サウンド再生 |
このダイアログは、WinSyslog
でメッセージが処理された際にサウンドファイルを再生させるための設定を行います。
注意:マシンに複数のサウンドカードがインストールされている場合、常に
最初にインストールされたカードのみが使用されます。
|
■サウンドファイルのファイル名
再生させたいサウンドファイルのファイル名を選択します。このファイルは、wav形式以外のフォーマット(MP3など)はサポートされていません。ローカルマシンのサウンドファイルのみを使用することをお奨めします。リモートでのサウンドファイルの使用は、基本的にはサポートしておりません。
存在しないサウンドファイルが指定されていたり、無効なフォーマットのファイルが指定されていたりする場合には、システムビープ音が発せられます。
■再生回数(ファイルを何回再生するか)
サウンドファイルを再生する回数を指定します。
注意:再生回数は、1回から101回まで選択できますが、パフォーマンスを考慮して最低限の回数に抑えることをお奨めします。EventReporterは、サウンド再生のアクションの実行時には、他のアクションは行いませんので、その点もご注意下さい。
|
■サウンド再生の間隔(ミリ秒)
サウンドの再生回数が複数回に指定された場合の、各サウンド再生の間隔をここで設定します。
「カスタム」で値を入力する場合には、その単位は「ミリ秒」として指定して下さい。
TOPへ |
破棄 |
(重要でないものなど)無視したいイベントがある場合には、この破棄アクションを設定することで実行できます。破棄のアクションが含まれるルール内のフィルタの条件で、破棄する条件(フィルタ)の設定を行ってください。
このアクションは、詳細を設定する必要がないため、アクションの追加で選択しても設定のダイアログは表示されません。
TOPへ |
コピーライト |
This
documentation as well as the actual WinSyslog product is copyrighted by
Adiscon GmbH, Germany. To learn more about other Adiscon products,
please visit
http://www.adiscon.com/en/products. To obtain
information on the complete
MonitorWare product
line, please visit
www.monitorware.com.
We acknowledge using these following third party tools. Here are the
download links:
Openssl-0.9.8a: http://www.adiscon.org/3rdparty/openssl-0.9.8a.tar.gz
Net-SNMP-5.2.1: http://www.adiscon.org/3rdparty/net-snmp-5.2.1.tar.gz
Liblogging: http://www.adiscon.org/3rdparty/liblogging.zip
VB6 NeoCaption: http://www.adiscon.org/3rdparty/VB6_NeoCaption_Full_Source.zip
Note: Microsoft, Windows, and the Windows logo are trademarks, or
registered trademarks of Microsoft Corporation in the United States
and/or other countries.
Other mentioned trademarks are for reference only. They belong to their
respective owners.
|