このページは 有限会社イハラ Adiscon製品 販売サイト の一部を移設したものです


   WinSyslog   EventReporter   Syslogビューア   Q & A   システム構成例

< 目次 >

EventReporterについて

機能

構成

システム必要条件

ご使用になる前に

インストール

  設定情報のエクスポート

EventReporterの設定

ライセンスの設定

全体オプション

サービス

  イベントログの監視
  イベントログの監視 V2
  ハートビート
  MonitorWare Fcho Reply

フィルタの条件

  全体の条件
  オペレーション
  フィルタ
  一般
  Date/時間

インフォメーションユニット
タイプ

  イベントログの監視
  拡張プロパティ
  ファイル確認
  フィルタ結果の保存

アクション

  ホスト名の解決 オプション
  ファイル オプション
  データベース オプション

OLEDB データベース
オプション

  イベントログ オプション
  メール オプション
  Syslog転送 オプション
  SETPで転送 オプション
  NetSend オプション
  プログラム開始 オプション
  サウンド再生 オプション

コミュニケーションポートに送信する

  ステータスの設定
  プロパティの設定
  ルールセットの呼び出し
  ステータス変数の算出
  破棄

コピーライト(英語)

 

EventReporter 9 マニュアル

日本語版

EventReporterについて

EventReporter は、Windowsのイベントログを収集し、管理するためのソフトウェアです。

マイクロソフトWindows NT™Windows 2000™Windows 2003™WindowsXP™は、非常に有能なオペレーティングシステムです。(以下の文章では、それら全てを[NT]と記します。)
しかし、それらの標準のイベントレポートを作っているメカニズムは、かなり制限されています。
運用しているサーバを確実に管理するには、定期的にサーバのイベントログをチェックする必要があります。

Adiscon EventReporter は、NTシステムのイベントログに記録されるイベントの集中管理を可能にします。収集したイベントログは、電子メールやsyslog転送などのアクションを実行することで、管理者へ通知することができます。

最初の製品(EvntSLog と呼ばれる)は、特にNTUnixが混在している環境を念頭おいて作成されました。EventSLog では、Syslogプロトコルのみに対応していましたが、現在でも世界中の多くの商業団体や大学、政府機関(軍などの)に使用されています。

EventReporter
を利用することで、複数のイベントログを中央のNT(またはUNIXベースの)syslogサーバで集中管理をすることができます。

しかし、小規模な組織であっても、サーバ管理の軽減が求められます。
EventReporter
を利用すると、電子メールを通してイベントログを管理者に届けることが可能になります。また、各サーバのイベントは予め定義されたフィルタにより、必要なイベントのみを選別することもできます。
これらの機能により、1つのサーバのみ管理している小規模な組織であっても、重要なログを見逃さずに安心して運用を行うことができます。

EventReporterは、コンピュータの再販業者やコンサルタント、そのほかサービスプロバイダにとって、まさかの時に彼らの顧客のシステムを監視することができる、優れたツールでもあります。

 この製品は、インストールや設定が簡単で、最小のシステム・リソースで稼動し、信頼できる製品であることが証明されています。その上に、非常に低コストな製品でもあります。

TOPへ

機能

ログの集中管理
これは、EventReporterのキーとなる機能です。
EventReporter
は、複数のイベントログをまとめて、自動的にそれらをシステムプロセスか管理者に転送するようにします。

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

Syslogサポート
イベントログで発生するメッセージは、標準のsyslogプロトコルを使って転送されるます。
NT
の重要度(
severity
は、それに相当するSyslogクラスにマッピングされます。また、Syslogファシリティ コードは、完全にサポートされています。

SETP のサポート
SETP は、MonitorWare用にオリジナルに開発されましたが、現在ではEventReporterプロフェッショナル エディション(6.2バージョン以降)の主要な機能となっています。
イベントメッセージは、このSETPプロトコルを用いて転送できます。

Eメールサポート
ユーザーが設定したルールに基づいて、収集したイベントログをEメールで送ります。
このEメールによる通知は、どんなEメールアドレスにも送る事が出来ます。(携帯電話でも受信できます)

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

ローカルフィルタリング
EventReporter
は、イベントログのタイプ(例えば「システム」や「アプリケーション」)や種類(情報やエラーなど)、その他様々なフィルタを設定し、メッセージを絞り込むことができます。

Windows2000 2003、2008、XPVista完全対応
我々はその出荷当時から、完全にWindows200020032008、XPVistaに対応しています。
全ての拡張されたWindows 2000ログ情報は集められ、完全にデコードされて、ログ対象(Eメールまたはsyslog)の提供を可能にします。

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

リモート管理
クライアントからEventReporterのリモート管理が可能になりました。
リモートで監視するマシンの台数も必要ライセンス数に含まれます。

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

イベントログの完全なデコード
EventReporter
は、イベントログ エントリの全てのタイプを完全にデコードすることができます。
それは、イベントビューアと同じような機能を持ちます。

NTサービス
EventReporter
サービス(ログを転送している「エンジン」のプロセス)は、Windowsのサービスとして実行されます。それは、コントロールパネルやコンピュータの管理からも制御できます。

ダブルバイトの文字のサポート(日本語など)
EventReporterは、ダブルバイトにコード化した文字をサポートします。(DBCS)これは、大部分は日本語または中国人のようなアジアの言語で使用されます。
全てのDBCS文字列は、正確にsyslogデーモンまたはEメール受信者に転送されます。しかし、受信している側は、さらに正確にDBCS処理ができなければなりません。
Windows
版のAdisconsyslogデーモン、EventReporterはそれが可能です。また、出力される文字コードは選択可能です。
日本のユーザーの為にシフト-JISJIS、そしてEUC-JPをサポートしています。

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

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

また、
クローンの機能が追加されました。クリックするだけで、ルールセット、ルール、アクション、サービスそれぞれのクローン(同じ設定内容のもの)を作成できます。

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

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

TOPへ

構成

EventReporter設定クライアント
EventReporterクライアントは、EventReporterで実行するサービスやアクションやフィルタの条件などを含むルールなど全ての設定をするために使用します。

また、クライアントは、設定情報の保存も行えます。複数のシステムで同じ設定を行いたい場合、その設定情報を対象システムへ読み込ませることで、簡単に実現できます。

EventReporterサービス
EventReporter
は、監視を行うシステム(サーバーやワークステーション)でサービスとして動作し、全てのログの処理と転送を調整します。

サービスは、監視を行うシステム上に必ずインストールしなければならないコンポーネントです。EventReporterサービスは、「エンジン」と呼ばれています。
このように、サービスのみインストールされたシステムを「エンジンだけの」インストールと呼びます。

EventReporterは、ユーザー操作の必要なしにバックグラウンドで動作します。
それは、コントロールパネルやコンピュータの管理から制御できます。 サービスは、次のように動作します:

EventReporter サービスは起動後、定期的にNTイベントログを読み込みます。
イベントログの各メッセージは、フォーマットされ、指定した syslog デーモン(サーバ)またはEメール受信者に送 るなどのアクションが実行されます。
全ての処理が終わった後、EventReporterは処理の必要がない場合は休止し、指示された時間だけ待機(スリープタイム)しています。(「スリープタイム」は変更可能です。
スリープタイムから戻ると、再びNTイベントログの読み込みを行い、これを繰り返します。
この過程は、中止されるまで継続します。

その最適化された構造によって、EventReporterは必要最小限のプロセッサ・パワーのみ使用します。プロセッサ・パワーをどれだけ使用するかは、「スリープタイム」の長さに左右されます。
Syslog
の送信には1~5分のスリープタイムを、Eメールの送信には1日多くても数時間のスリープタイムをお勧めします。
けれども、必要に応じてこの時間は自由にカスタマイズしてください。
たとえそれが可能であっても、500ミリセカンド(0.5秒)以下にスリープタイムを設定することは、勧められません。

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

EventReporter 8.0 よりx64プラットフォーム対応版がご利用頂けるようになりました。
主に変更された箇所は、サービスのコアの部分です。
詳細は、以下をご覧下さい:

 

ODBCデータベース・アクションが x64 システム上で動作するようになりました。
但し、x64 に対応した ODBCドライバを使用しなければなりません。

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

 

EventReporter Win32版からx64版へのクロスアップデートについて ~

Win32版からx64版へのクロスアップデートは、通常のバージョンアップでは行えません。

マイナーバージョンアップでは、x64のコンポーネントが全てインストールされるわけではないからです。
従って、クロスアップデートを実行するには、以下の手順で操作して下さい:

1. 設定情報のバックアップを取る (レジストリ、またはxmlファイルとして保存)
2. EventReporter
をアンインストールする
3. EventReporter x64
版をインストール
4. 1
の設定情報をインポートする

TOPへ

システム必要条件

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

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

OS

Windows NT 4.0 SP6 以降のシステム
Windows 2000/XP/2003/2008 Serverを含む)
ワークステーション、サーバーを問わず

メモリ

6MB

ハードディスク

およそ10MBの空き容量が必要

必要ソフトウェア

インターネット・エクスプローラ 5.5 以降のバージョン
(クライアントはXMLを使用します。)

 

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

OS

Windows NT 4.0 SP6 以降のシステム
Windows 2000/XP/2003/2008 Serverを含む)
ワークステーション、サーバーを問わず

メモリ

2MB
その使用環境により
64MBのメモリ追加を推奨

ハードディスク

およそ200KBの空き容量が必要

サービスはより小さな必要条件で稼動します。
最も重要な違いは、サービスはシステム上にインターネット・エクスプローラを必要としないということです。
Windows2000以降の、3つの追加されたイベントログ(「DNSサーバ」、「ファイル複製サービス」と「ディレクトリ・サービス」)もサポートされています。

TOPへ

ご利用になる前に

EventReporter は、簡単にも複雑にもご使用頂けます。
この章では、EventReporter の概要とEventReporter で何ができるかをご説明します。
最も重要なのは、チュートリアルになります。
こちらでは、セットアップや設定を行う際のヒントだけでなく、EventReporter で実行できる多くの基本的なタスクについてご説明しています。この章だけでも目を通すようにして下さい。

インストール

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

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

解凍した後は、「setup.exe」(=セットアップ プログラム)をダブルクリックし、画面上の指示に従っていってください。

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

設定情報のエクスポート

ご質問を頂いた際、その内容により、お客さまの設定情報をサポート担当へお送り頂く場合がございます。
これにより、弊社(内容により開発元 Adiscon社)で原因究明のための検証を行うことが可能となります。

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

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

XML形式による設定情報のエクスポート・インポート
XML形式で設定情報の保存を行うことも可能です。
これは、数多く設定を行う場合や、ソートする場合などに役立ちます。

TOPへ

EventReporter の設定

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

この章においては、EventReporterサービスの設定方法についてご説明します。  
EventReporter
の最も重要な部分であるサービスは、一旦設定されるとバックグランドで動作します。そして、それはユーザーの操作の必要がありません。

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

EventReporter設定クライアントを起動するには、スタートメニューのEventReporterのフォルダにあるアイコンをクリックします。  

EventReporter クライアントは、2つの要素があります。
左側では、ツリー表示よりEventReporter のシステムの色々な要素(サービス、アクションなど)を選択できます。
右側には、その選択した要素のパラメータが表示され、実際の設定を行えます。

上図においては、右側のツリー表示で「サービスのデフォルト」-「ファイル&システムモニターサービス」-「イベントログの監視」サービスを選択しているので、左側にその設定画面が表示されています。

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

<全体/デフォルト >
「全体/デフォルト」では、アクションやサービスのデフォルトだけでなく基本的な操作上のパラメータを設定します。

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

< サービス >
「サービス」のツリー表示には、設定されたサービスとそのパラメーターがあります。
生成されたサービスにつき、1つのサービス項目が存在します。

理論的には、1つのサービス インスタンスに対して数百のサービスを起動させることが可能です。
けれども、システム・リソースを考慮し、また使用方法としても サービスの数は、なるべく最大でも20から30にとどめて置くようにしてください。もちろん、この制限数は目安ですので、アプリケーションが必要とする場合には、30以上になる場合もあります。
EventReporter
は、実際のサービス数の制限はありません。
数多くのサービスを必要とし、ハードウェアがその処理に耐えうる場合は、数の制限は必要ありません。

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

同様に、右側の設定ダイアログの下にある「使用するルールセット」も、サービスの種類に関係なく共通のものです。

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

サービスを削除したい場合は、その対象のサービスを右クリックし、「サービスの削除」を選択します。サービスを削除した場合には、その設定は失われます。
一時的に削除したい場合には、「サービスの無効化」の指示を行って下さい。
 

< ルールセット >
ツリー表示の最後の要素は「ルールセット」です。ここで全てのルールセットの設定を行います。
それぞれのルールセットは、完全にお互いから独立しています。

ルールセットは、サービスで「使用するルールセット」として選択され、保存されます。  

ルールは、ルールセットの下にあります。
ルールに関する詳細でもご説明しますが、ルールは非常に重要な機能です。
ルールは最上位のあるものから順に実行されます。
ルールを上や下に移動するには、移動したいルールを右クリックして「上に移動」または「下に移動」を選択してください。
 

ルールのツリー表示には、ルールの下には、それに関連するアクションとフィルタの条件があります。さらに、実行する全てのアクションは、アクションの下にあります。

TOPへ

ライセンスの設定

ご購入後に弊社よりメール送付させて頂きますライセンス情報をご登録いただくことにより、製品版として登録され、高度な機能が使用できるようになります。

ユーザー登録名  
ユーザー登録名は、お客さま自身でお決め頂けます。
(ユーザー登録名は、ご注文時にオーダーフォームに必要事項としてご記入頂きます。)

会社名(学校名)を登録名にお使い頂いても良いですし、独自の登録名を選択して頂くことも可能です。
ですが、セキュリティを考慮してよく使われる文字列は Adiscon 社により認証されない場合がございます。
 

注意 :登録名は、半角6文字以上で設定してください。登録名には、日本語文字列は使用できません。
アルファベットの大文字・小文字、数字のみご利用できます)
また、登録名は、大文字と小文字の区別をしますので、与えられた通り、正確に入力しなければなりません。
スペースの1文字として認識しますので、余計なスペースが入らないように注意してください。

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

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

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

TOPへ

全体オプション

全体オプション                                                                     


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

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

Customer ID
顧客によってCustomerIDを変更したい場合に、ここで 整数値を入力します。例えば、顧客のサーバを監視する際に、エージェント別に違うIDを設定することが可能です。
サーバABを監視しているとして、5台あるサーバACustomer IDを1、2台あるサーバBCustomer ID2といった具合で設定することが可能です。
サーバABのサーバ名が同じであっても、CustomerIDを設定すれば別の定義を行うことが可能です。

 

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

MIBS の場所
ここでは、MIBsの場所を指定します。

基準時刻
ここでは、ファイルログやデータベースログ、Eメール送信など、EventReporter全体で使用するタイムスタンプの設定を行えます。
UTC
、またはローカルタイムの指定を行えない設定項目に対しても、ここで選択したタイムスタンプが設定されます。

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

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

日本語システムに対する特別なUnicode変換
日本語のシステムにおいては、文字の処理方法が異なります。
日本語のメッセージが正常に処理されない問題(文字化けなど)が発生したときには、ここを有効にして下さい。

エンジンに関して                                                                                  

<アクションのオプション>
アクションの失敗を再試行する
「失敗したアクションの再試行を有効にする」機能を有効にすると、サービスは「再試行の回数」の設定値に達するまで、失敗したアクションを実行します。

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

<ルールエンジン特定>
一つのルールが失敗するとき、ルールの実行を中止する
ここを有効にすると、ルールに定義されているアクションのうちの一つが失敗した場合に、そのルールの実行を中止します。

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

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

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

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

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

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

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

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

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

デバッグ オプション                                                                                  

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

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

重要: デバッグ出力は、かなりのシステム・リソースを必要とします。
ログのレベルが上がるにつれ、より大きなリソースが必要となります。
しかし、最も低いレベルに設定しても、EventReporterの処理はかなり遅くなります。
従って、
普段はこのオプションをオフにしておく事をお勧めします。

ファイルへのデバッグ出力を有効にする
ここを有効にすると、デバッグのログが可能になり、サービスが稼動する際に書き込まれます。
パフォーマンスを考慮して、普段はこのボックスをチェックしないで置くことをお勧めします。

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

<記録される内容>

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

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

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

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

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

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

キュー管理 オプション                                                                            

この機能により、項目(Items)をディスク(指定したファイル)の内部キューに蓄えて置くことが可能となります。
この機能は、確実に必要な場合のみ使用するようにしてください。

ご利用のマシンのハードディスクの速度により、アクションの処理速度が下がる場合があります。最悪の場合には、マシンがIO読み込みを実行できなくなり、キューがいっぱいになってしまいます。ディクスキャッシュは、受信したSyslogメッセージで未処理のものを確実に処理させたい場合の追加機能です。

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

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

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

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

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

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

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

<キュー管理 オプション>

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

TOPへ

サービス

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

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

イベントログの監視

ここでは、イベントログの監視サービスについて設定をおこないます。

これは、EventReporterに最初に導入されたサービスであり、Windows のイベントログを取得するために使用されます。 (Windows Vista をご利用の場合には、イベントログの監視V2 をご利用下さい。)

このサービスでは、前バージョンのEventReporter をご利用の方でもスムーズに使用できるよう、以前のメッセージのフォーマットに対応した項目(高度なオプション - レガシーフォーマットを使用)もあります。

イベントログの監視サービスで最も重要なのは、テーブルの部分です。
ここでは、どの種類のイベントログを監視するのかを指定します。
上図のスクリーンショットでは、以下のの6種類のWindowsで生成されるイベントログが発生した場合に監視できるよう設定されています。

 Application (アプリケーション)
 Directory Service (ディレクトリ サービス)
 DNS Server DNSサーバー)
 File Replication Service
(ファイル レプリケーション サービス)
 
Security
(セキュリティ)
 
System
(システム)

それ以外にもカスタムのイベントログについても監視することが可能です。
そのようなカスタムのイベントログは、アプリケーションによって生成されます。

例えば、「MySuperApp」というアプリケーションから、「MySuperAppLog」という名のイベントログが生成されると仮定します。そのとき、そのアプリケーションのメッセージは、Windowsのイベントログではなく、そのイベントログに記録されます。 

このようなカスタムのイベントログへ対応するために、このテーブルに新たにイベントログを追加できるようになっております。 (追加できるイベントログの数に制限はございません)
カスタムのイベントログを追加するには、「挿入」ボタンをクリックします。すると、新しくイベントログが追加されるので、「イベントログタイプ名」のコンボボックスで追加したイベントログの名前を編集します。(名前の編集は、既存の名前に上書きするようにします。)
 

実際には、テーブル内でチェックされた(有効になっている)イベントログだけが処理されます。
ここで有効になっていないと、設定されていても何の処理もされません。

<全体のオプション>

スリープタイム(ms:ミリ秒)
イベントログの監視
では、定期的にイベントログの発生をチェックします。
「スリープタイム」では、この処理の間隔を指定します。

デフォルト値は、1分となっており、1分毎にイベントログの発生がチェックされるようになっております。
ドロップダウンリストより「カスタム」を選択すると、値を入力するテキストボックスが現れ、数値で指定して入力を行えます。この値は、ミリ秒で入力します。

このカスタムで値を設定する場合は、60000ミリ秒という値を推奨します。
この値では、イベントログの監視60秒ごとに新しいイベントの発生をチェックします。
頻繁にシステムに接続しない場合や、一日届くEメールの数が数通の場合には、60000ミリ秒よりも大きな値で構わないでしょう。

逆に、セキュリティを厳重にする場合は、もっと短い間隔でも良いでしょう。
EventReporter
は、監視するシステムへの負荷を制限するよう設計されています。
従って、イベントログのチェックが頻繁になっても、リソースの使用は低く抑えられております。
しかし、1秒間に1回以上のペースではイベントログの監視を稼動させないよう、設定を考慮するようにしてください。(つまり、1000ミリ秒(1秒)以下の数値は、お勧めできません。

オーバーラン防止遅延(ms)
ここでは、イベントが作成された後の遅延を設定できます。
この時間は、ミリ秒単位で遅らせることが可能です。値は、0から400まで指定できます。

この値がゼロの場合、EventReporter は、マシンのパフォーマンスが許す限り早くイベントを処理します。

もしも、ルータや受信側がこの速度について行けない場合は、結果的にパケットロスしてしまいます。
さらに、レポートしている側のマシンのCPU100% になってしまいます。
EventReporter は、プライオリティが低いので問題ではありませんが)
1
ミリ秒であっても処理を遅らせれば、一気に大量のイベントが転送されても、CPUの稼働率はかなり抑えられます。1ミリ秒の場合、EventReporter 1秒間に1000のイベントを処理することができます。

デフォルトでは、ここは5ミリ秒で設定されています。この場合、1秒間に約200のイベントを処理することが可能です。 この値は、非常に忙しいサーバであっても十分だと思われます。

優先言語
「優先言語」が選択できるようになりました。
ここで選択された言語がインストールされており、メッセージ・ライブラリが使用可能な場合に機能します。

この機能に失敗した場合には、自動的にシステムデフォルトの言語が適用されます。

高度なオプション
ここをクリックすると、下の画面が現れます。

制御文字を圧縮する
このオプションにより、制御文字の削除とスペースの圧縮を行うことができます。
ここを有効にすると、CRLFTABのような印刷できない文字は削除されるようになります。
また、余分に入っているスペースは、一つに圧縮されます。
デフォルトでは、ここは有効になっています。(デフォルト設定のまま使用することをお奨めします。)

サービスの起動時、現存のエントリを処理しない
ここを有効にすると、EventReporterのサービス起動時に、全て(現存)のWindowsイベントログは再処理されなくなります。

イベントログのデータ破損の際、現存のエントリを処理しない
ここを有効にすると、イベントログのデータが破損していたり、切り捨てられたりしている場合に、そのデータを再処理しないようになります。

デフォルトバッファサイズ
デフォルト値は、10KBとなっておりますが、必要に応じて変更してください。NetAppのようなサードパーティー製品に対しては、ここの値を65536バイト以上に設定することをお奨めします。

破損したイベントログの処理方法
ここでは、イベントログの監視サービスが、破損したイベントログファイルをどのように処理するかについて設定を行うことができます。
イベントログがデータ破損する可能性は、それほど高くはありませんが、ないとも限りません。
たいていの場合、データの破損は、ハードやソフトの不調により発生します。
ログが0にリセットされない場合は、イベントログの監視サービスの処理にエラーが発生する可能性があります。

ここでは、以下のオプションを選択できます:

最初から処理を再試行する」
「破壊されたイベントログのエントリを無視する」
「イベントログの全てのイベントを消去する」

パラメーター文字列から制御文字を削除する
パラメーター文字列やイベントログのカテゴリー名(分類)からキャリッジリターンやラインフィードなどの制御文字を削除したい場合には、ここを有効にして下さい。

レガシーフォーマットを使用:このオプションは、以前のバージョンのEventReporter と共に稼動するスクリプトや製品への互換性を高めます。
レガシーフォーマットでは、メッセージ本体の中に全ての Windowsイベントログ プロパティが含まれています。

新しいフォーマットには、プレーンなテキストメッセージのみが含まれています。
追加の情報フィールド(イベントID や イベント・ソースなど)は、XMLフォーマットされたイベントデータの一部になります。新しいフォーマットを使用する場合、情報の送信や保存にはXMLフォーマットを使用するようにしてください。これは、各アクションのプロパティ内のオプションです。(例えば、「データベースログ」アクションについては、別々のフィールドに保存されるので、それを行うための特定のオプションはありません。)

レガシーフォーマットは、従来の構文解析スクリプトをサポートするためのものです。
新しいインプリメンテーションに対しては、新しいXMLに結び付くフォーマットを使用することをお奨めします。
レガシーフォーマットでは、ログ解析の構築や操作を行う際に、問題が生じる場合があります。
それらは、仕様によるものです。ですが、レガシーフォーマットについては、現在、開発は行われていません。したがって、レガシーフォーマットで生じる問題は、新しいフォーマットを使用することがその解決法となります。

以下の機能をオプションとして選択できます:
これらの機能は、「レガシーフォーマットを使用」の項目が有効の場合のみ機能します。)

・ファシリティ文字列の追加:ここを有効にすると、ファシリティの識別(identification)が作成されるメッセージの前に附加されます。
このパラメータは、既存のsyslogプログラムとの互換性を高め、syslogサーバで作成された項目を解析するのを非常に容易にします。この機能を使用することをお勧めします。

・ユーザー名の追加:ここを有効にすると、イベントログ項目を作り出したNTユーザー名が送信されます。無効になっている場合は、この情報は送信されません。

これは、EventReporter の出力データ解析のために書かれたスクリプトがあるお客様に対する、変更可能なオプションです。

・ログタイプの追加:ここを有効にすると、ログタイプ(セキュリティやシステム・・・)が収集されたメッセージに追加されます。

Syslogメッセージ・ナンバー:ここを有効にすると、連続したSyslogメッセージ番号がメッセージに追加されます。これは、リモート環境で、全てのSyslogメッセージが受信されたかどうかを確認するのに役立ちます。

 

リモートによるイベントログの監視を有効にする (プロフェッショナルエディション限定)
ここを有効にすると、リモートマシンのイベントログの読み込みや処理が可能となります。

ここを有効にした場合は、監視するマシンのファイルと印刷サービスが有効になっていること、およびこのマシンによる接続が可能なことを確認してください。イベントログサービスは、デフォルトの管理共有によりリモートマシンのメッセージ・ライブラリを読み込みます。そのため、サービスはローカル、およびリモートのマシンで管理権限を持たせるように設定しなければなりません。

ファイルと印刷サービスが無効になっている場合、ローカルのメッセージ・ライブラリが使用されます。
この場合、メッセージライブラリが見つからないことがあります。

<イベントログタイプ>

ここでは、各チェックボックスを有効にすると、それに応じたイベントログタイプが処理されます。
「高度な設定」をクリックすると、詳細な設定を行うことができます。

「高度な設定」は、全てのログに共通です。

ログの切り捨てを報告する
Windows NT
のイベントログはプログラムから、もしくはイベント・ビューアによって切り捨てることが可能です。 ログが切り捨てられるとき、全ての情報はそこから削除されます。
まだEventReporterが送信していなかった項目も、全て消失します。

EventReporterは、イベントログの切り捨て部分を発見します。
「ログの切り捨てを報告する」をチェックした場合、EventReporterはログが切り捨てられた部分を示すメッセージを個々に生成します。

毎日のオペレーションの一部として定期的にNTイベントログを切り捨てている場合、このオプションをオフにするように提案します。またその場合、EventReporterのスリープ タイムの設定では10,000、(つまり10秒)に設定することを推奨します。

既存のエントリを処理しない
既存の特定のWindowsイベントログのダンプが不要の場合には、ここを有効にして下さい。その場合、EventReporterは再起動された際、最後のエントリを処理し、その前のエントリは検索されません。

セキュリティIDSID)のオブジェクト名への変更を試みる
ここを有効にすると、SIDがオブジェクト名へ変換されます。各イベントログの「高度な設定」でこの機能を有効にすることができます。

注意:「セキュリティのイベントログ」に対してのみ、デフォルトでこの値が有効になっています。その他のイベントログでは、ここは有効になっていません。

Active Directory オブジェクトクラスのコンバートを試みる
この機能を利用することで、スキーマGUIDは内部キャッシュに入り、イベントログの監視サービスの処理速度が高まります。

注意:「セキュリティのイベントログ」に対してのみ、デフォルトでこの値が有効になっています。その他のイベントログでは、ここは有効になっていません。

最後に処理されたイベントを確認するためにチェックサムを利用する
ここを有効にすると、最後に処理されたイベントのチェックサムがイベントログの最終レコードとともに保存されるようになります。
チェックサムは、EventReporter がイベントログのチェックを行う度に確認されます。
この値が合わない場合には、EventReporter はイベントログに何らかの手が加えられたとみなし、最終レコードの続きからではなく、先頭のイベントから再処理を行います。

注意:このオプションは、最終レコードの値の書き換えを防ぐものです。
もし、最終レコードを修正した場合には、既存のイベントが先頭から再処理されるようになります。
このオプションは、最終レコードが有効かどうかを二重チェックしたい場合にのみご利用頂くことをお勧め致します。

Syslog ファシリティ
このログから生じるインフォメーション・ユニットをマップするSyslogファシリティ。
Syslog
デーモンにメッセージを転送する場合に最も役立ちます。

最終レコード
NT
イベントログは、1から順に数えられます。
EventReporter
は、最後に処理されたレコード番号を記録します。
このテキストボックスから、この値を上書きすることが可能ですが、慎重にこの機能を利用してください。

特定のNTイベントログの完全なダンプが欲しい場合は、「最終レコード」を0にセットしてください。いくつかのイベントログを逃してしまった場合は、「最終レコード」の値を現在のものより多少低い値にセットしてください。
現在の値より高く設定することも可能です。この場合、設定値に達するまでイベントの報告を中断します。本当に必要がある場合を除いて、この機能を使用することは勧められません。
 

ファイルからイベントログを読込む
ここを有効にすると、システムからではなく、ファイルからイベントログが読み込まれます。

記録する イベントタイプ
これらのチェックボックスにより、イベントログのローカルフィルタリングが可能になります。
フィルタリングは、NTイベントタイプがベースになっています。各イベントタイプに適用するチェックボックスがあります。イベントタイプがチェックされた場合のみ処理されます。

この時点で不要なログタイプをフィルタにかけると、インフォメーション ユニットが発生せず、さらにルールエンジンにもパスされないので、システム効率が高まります。
したがって、不要なログタイプは取り去るようにすることをお勧めします。

高度なイベントログ処理 >
Windowsで作成されたバックアップのログを確認(KB312571参照)
このバックアップ機能に関する詳細は、KB312571「イベント ログが最大ログサイズに 達する前に、イベントの出力が停止する」をご参照下さい。
もしも、自動バックアップの機能を設定なさっている場合には、「Windowsで作成されたバックアップのログの確認(KB312571参照)」を有効にすると、イベントログの監視サービスはシステム内にこのファイルを検索し、処理を行います。
バックアップのログファイルの最終レコードとEventReporterで処理した最終レコードを比較し、一致する場合には、そのレコードの続きから処理されます。一致しない場合には、バックアップのログファイルのデータが再処理されます。

バックアップログに対するサーチパスをカスタマイズする
この機能を有効にすると、検索を行うバックアップのログファイルのパスを編集できます。

ここでは、以下の値を利用できます;

%SystemRoot%
この値は、システムフォルダの場所を示す環境変数です。

%SystemDrive%
この値は、システムフォルダを含むドライブを示す環境変数です。

%ProgramFiles%
この値は、プログラムがインストールされるディレクトリの場所を示す環境変数です。

以下の変数は、ポストプロセスコマンドとして使用できます;

%backupfile%
この値は、最後に処理されたバックアップログファイルのファイル名を示す変数です。

< イベントログの消去 >

ここでは、イベントログの自動消去に関してご説明します。
以下3つの項目が消去方法として設けられています;

消去しない(デフォルト)
ポーリングサイクル後に毎回消去する
毎日 設定した時間に消去する

また、消去後のオプションとして以下を設定することも可能です;

消去に成功した場合にログを作成する
空であってもイベントログを消去する
イベントログのバックアップを作成する(バックアップファイル名を指定します)
消去するまでの実行回数(ポーリングサイクル後に毎回消去する を選択した場合)
消去する時刻(毎日 設定した時間に消去する を選択した場合)

使用するルールセット
このサービスに使用するルールセットを指定します。
有効なルールセットを選択して下さい。

ルールセット名に日本語文字列が含まれている場合には、ルールセットが認識されない場合がありますので、ルールセット名はASCII 文字列のみをご使用下さい

TOPへ

イベントログの監視 V2(Windows Vistaのみ)

Windows Vista のイベントログ収集のために新たにこのサービスが追加されました。
Windows
NT
20002003XPをご利用の場合には、従来の「イベントログの監視」サービスをご利用下さい。

このサービスは、Windows Vista のイベントログを処理するように設計されています。
イベントログの項目は、分割され、新たにサービスチャンネルとして表示されています(下図参照)

まず、従来のイベントログ(Classic EventLog)があり、これらには アプリケーション、システム、セキュリティなどのイベントログが含まれています。その下に新しいイベントログ(下図;Serviced Channels)があります。 

ここでは、監視できるイベントが表示されます。
カスタムのイベントログを設定した場合、設定画面を再度開いた際に自動的にこのツリーに追加されるようになります。

このツリービューでは、チェックボックスを有効にすることにより選択したイベントログを管理できるようになります。デフォルトでは、全てのイベントが有効になっています。

スリープタイム(ms:ミリ秒)
イベントログの監視
では、定期的にイベントログの発生をチェックします。
「スリープタイム」では、この処理の間隔を指定します。

デフォルト値は、1分となっております。ドロップダウンリストより「カスタム」を選択すると、値を入力するテキストボックスが現れ、数値で指定して入力を行えます。この値は、ミリ秒で入力します。

オーバーラン防止遅延(ms)
ここでは、イベントが作成された後の遅延を設定できます。
この時間は、ミリ秒単位で遅らせることが可能です。値は、0から400まで指定できます。
この値がゼロの場合、EventReporter は、マシンのパフォーマンスが許す限り早くイベントを作成します。

もしも、ルータや受信側がこの速度について行けない場合は、結果的にパケットロスしてしまいます。
さらに、レポートしている側のマシンのCPU100% になってしまいます。
EventReporter は、プライオリティが低いので問題ではありませんが)
1
ミリ秒であっても処理を遅らせれば、一気に大量のイベントが転送されても、CPUの稼働率はかなり抑えられます。1ミリ秒の場合、EventReporter 1秒間に1000のイベントを作成することができます。

デフォルトでは、ここは5ミリ秒で設定されています。
この場合、1秒間に約200のイベントを処理することが可能です。
この値は、非常に忙しいサーバであっても十分でしょう。

メッセージフォーマットを選択
ここでは、イベントのメッセージフォーマット(Raw XML、または定義済みイベントフォーマットのいずれか)を選択できます。Raw XMLフォーマットを選択した場合には、文字通り XML 形式でログが記録されますので、それにはイベントログのデータのみ記録されます(フォーマットされたメッセージは含まれません)。 

定義済みイベントフォーマットは、イベントビューアにあるようなイベントメッセージが記録されます。

TOPへ

ハートビート

ハートビート処理は、EventReporter自体が稼動しているかどうかを断続的にチェックするのに使用されます。
その処理によって、特定の時間ごとにインフォメーション・ユニットが生成されます。
インフォメーション・ユニットは、別のシステムに転送することも出来ます。
指定された時間内に追加のパケットが受信できないときには、エージェントにトラブルが起きているか、動作が停止しているということが疑われます。

ハートビート中に受信するメッセージ  
これは、インフォメーション・ユニット内のテキストとして使用されるメッセージです。
入力する内容は、どんなものでも構いません。
EventReporter
内部には特別な値をチェックする機能はありません。

ハートビート クロック(スリープタイム)  
ハートビート・サービスがインフォメーション・ユニットを生成する時間をミリ秒で指定します。
受信のサイトには耐久力が必要であるという点に注意してください。
ここで指示される間隔(周期)は、パケット間の最小限の時間です。
負荷の大きい場合は、周期は少し長くなる可能性もあります。
システムのモニタによって、エージェントが正しく起動しているか疑わしいと見なすまでに、2回この周期を見込んでおくと良いでしょう。

Syslogファシリティ  
ハートビート・サービスによって生成されるイベントに割り当てられるsyslogファシリティ。
メッセージをsyslogサーバに転送する際に役立ちます。

Syslogプライオリティ  
ハートビート処理によって作成されるイベントに割り当てられるsyslogプライオリティ。
メッセージをsyslogサーバに転送する際に役立ちます。

リソースID  
ハートビート処理によって作成されるイベントに割り当てられるリソースID
メッセージをsyslogサーバに転送する際に役立ちます。
 

Syslog タグ値  
ハートビート処理によって作成されるイベントに割り当てられるsyslogタグ値。
メッセージをsyslogサーバに転送する際に役立ちます。

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

ルールセット名に日本語文字列が含まれている場合には、ルールセットが認識されない場合がありますので、ルールセット名はASCII 文字列のみをご使用下さい

TOPへ

MonitorWare Echo Reply

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

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


 

フィルタの条件

フィルタの条件は、どんなときにルールを稼動させるかを設定します。
フィルタの条件で「真(true)」と評価されると、その条件を含むルールが一致していると処理され、そのルールで指定されたアクションが実行されます。

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

デフォルトでは、フィルタの条件は「AND」のみが設けられています。
この状態では、全てのデータが「真」となります。

デフォルトのフィルタの条件は、この条件を含むルール内のアクションが受信した全てのインフォメーション ユニットに対して実行されるということを意味します。
このようなフィルタの条件は、たいていメッセージを絞り込まず処理するアクション(例えば、データベースやテキストファイルに 入ってくる全てのインフォメーション ユニットを書き込むアクションなど)に対して使用されます。

一方、非常に特殊の条件において(メッセージを絞り込んで)実行されるべきアクションも存在します。
それらは、複数の階層のブール演算を含む、複雑なフィルタの条件が要求されます。

上図のフィルタの条件では、侵入検知を行うことが可能です。

ここでは、IIS で許可されていない exe ファイルが実行された場合に生成されるイベントログを受け取った際にアクションを実行させるよう設定されております。 

具体的には、イベントログの監査サービスのイベントログメッセージであり、そのメッセージ内に以下の値が含まれている場合、

イベントID:「560」、ソース:「Security」、ユーザー:「P15111116\IUSR_ROOTSERVER」、文字列:「exe

さらに、「\usr\bin\perl.exe」または「\PHP\php.exe」の文字列がメッセージに含まれていない場合に「真(True)」と評価され、アクションが実行されます。

頻繁にアラートが発生しないように、さらに「最小の待ち時間」を60秒と設定しました。
したがって、他の全ての条件が「真」であっても、フィルタの条件は 60秒の間隔を置いて「真(True)」と評価し、アクションを実行します。

TOPへ

全体の条件

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

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

例えば、ピング探査について、ピングはあまり確実なプロトコルではありません。
そのため、消失してしまうこともあります。
1
回のピングの消失で、いくらかの処理を再起動させるというのは適切ではありません。再起動させるまでに、ある程度ピング探査を繰り返し実行させた方が効率的です。「発生」のフィルタの条件は、この為に使用されます。
 

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

最小の待ち時間
このフィルタの条件は、ルールが過度に作動するのを防ぐために使用が出来ます。

例えば、ポート探査のイベントのステータスをチェックするためにルールを作成したとします。
ポート探査は、SMTPサーバを徹底的に調べます。そのイベントが発生し、ルールがそれを確認すると、サービスを再起動する処理を実行しようとします。この処理には多少時間がかかります。このような場合、ポート探査は追加のイベントを生成するでしょう。
一度目と二度目のポート探査の間隔が5分以内の場合、最小の待ち時間の設定でルールは照合されないでしょう。
しかし、もし(メールゲートウェイが再び機能せずに)同じイベントが5時間後に発生した場合には、ルールが再び作動し、それに対処するアクションが実行されるでしょう。
そこで、同じイベントのルールの処理中に、そのイベントに対する同じルールが重ねて稼動しないように「最小の待ち時間」の機能を使用します。

検出されないフィルタをTRUEとして処理する
フィルタの条件で問い合わせたプロパティがイベントに存在しない場合、通常は「偽(False)」として処理されます。、上記のイベントを「真(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

デバッグを行う際に役立ちます。結果は「偽」となります。

 

フィルタ

フィルタは、各オペレーションノードの下に追加することが可能です。
全てのサービスに使用できる共通のフィルタは、数種類あります。
また、特別な種類のインフォメーション ユニットに対してのみ適用されるフィルタも存在します。

インフォメーション ユニットで見つからない全てのフィルタは、フィルタリング処理で無視されます。
例えば、「イベントログの監視」と「ハートビート」の2種類のサービスが同じルールセットに関連付けされており、そのルールセットのフィルタ条件でイベントIDのフィルタが作成されていた場合、「ハートビート」にはイベントIDがメッセージ内に含まれていない為、このサービスは無視されます。

このような場合には、サービスごとに別のルールセットを作成し、関連付けするようにして下さい。

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

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

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

番号(Number
「=」、「Not =」、「<」、「>」で別の番号と比較されます。

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

時間(Time
「=」のみで別の時間と比較されます。

一般

これらは、イベントログでない特定の設定です。

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

このフィルタは、文字列で指定します。
ソース・システム名か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を設定することが可能です。
サーバABを監視しているとして、5台あるサーバACustomer IDを1、2台あるサーバBCustomer ID2といった具合で設定することが可能です。
サーバABのサーバ名が同じであっても、CustomerIDを設定すれば別の定義を行うことが可能となります。

タイプ=数字

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

タイプ=数字

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

タイプ=文字列

TOPへ

Date/時間

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

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

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

月曜に実行(タイプ=ブール演算)

火曜に実行(タイプ=ブール演算)

水曜に実行(タイプ=ブール演算)

木曜に実行(タイプ=ブール演算)

金曜に実行(タイプ=ブール演算)

土曜に実行(タイプ=ブール演算)

日曜に実行(タイプ=ブール演算)

インフォメーション ユニット タイプ

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

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

1.       イベントログ監視 (タイプ=ブール演算)

2.       ハートビート (タイプ=ブール演算)

TOPへ

イベントログの監視

イベントログの監視に特有のフィルタは、以下の通りです。

イベントID
これは、NTイベントログで指定されたイベントログIDです。
有効にすると、イベントは設定されたイベントIDを持っていなければ、ルールは照合されません。
これは整数の値を指定して下さい。

タイプ=数字

イベント タイプ
これは、NTイベントログで指定されるイベントタイプです。
ここで設定したイベントタイプがデータに含まれている場合に、アクションが実行されます。
サポートされているイベントタイプの値をリストボックスから選択し、設定します。

タイプ=文字列 

イベント・ソース
これは、NTイベントログで指定されたイベントログ ソースです。
有効にすると、イベントは設定されたイベント・ソースを持っていなければ、ルールは照合されません。
これは、文字列で値を指定します。
ここで指定する値は、正確に一致していなければなりません。
また、値は大文字と小文字の区別が出来るので、ご注意ください。

タイプ=文字列

イベント重要度(Severity
これは、NTイベントログで指定されたイベントログ重要度です。
有効にすると、イベントは設定されたイベント重要度を持っていなければ、ルールは照合されません。
対応する値を「プロパティに値を設定」のリスト・ボックスから選択することが出来ます。

イベントカテゴリ
これは、NTイベントログで指定されるイベントログカテゴリです。このフィルタを有効にすると、イベントがここで定義したイベントカテゴリを含んでいない場合には、ルールが適合されません。


タイプ=数字 

イベントカテゴリ名
この値には、文字列としてのカテゴリ値が含まれています。文字列として解決できない場合には、カテゴリ番号が含まれます。

タイプ=文字列
 

イベントユーザー
これは、NTイベントログで指定されたイベントログのユーザーです。これを有効にすると、イベントが設定されたイベントユーザーを含んでいない場合には、ルールは適合されません。文字列で値を指定するので、値は正確でなければなりません。

タイプ=文字列

拡張プロパティ

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

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

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

TOPへ

ファイル確認

 

  ファイル確認
このフィルタでは、設定したファイルが存在するかどうかを確認できます。
ここでは、直接ファイルパスを入力するか、または「ブラウザ」ボタンから値を指定します。
 

フィルタ結果の保存

 

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

アクション

アクションは、フィルタの条件において、ルールが適合する場合に実行されます。
アクションを設定して頂くことにより、イベントログのメール送信、Syslogサーバへの転送、ファイルやデータベースへの書き込み、その他にも様々な処理を行うことが可能となります。

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

ホスト名解決オプション

このアクションにより、全てのサービスでホスト名の解決を実行させることが可能となりました。

  名前解決するソースプロパティを選択
ここでは、名前解決を実行するプロパティを選択します。
テキストボックスの右にある Insert をクリックし、プロパティ値を選択して下さい。
 

名前解決の保存先プロパティ
ここでも同じようにテキストボックスの右にある Insert をクリックし、名前解決の保存先のプロパティを選択します。
 

既にソースプロパティに名前が入っている場合、完全な名前解決(FQDN)を行なう
ここを有効にすると、(可能な場合)FQDNを実行します。

例えば、ソースプロパティが既に「servername」と表示されている場合に、この機能を有効にすると完全な名前解決が行なわれ、「servername.mydomain.com」などと表示されるようになります。 

解決されたホストエントリをキャッシュに入れる
ここを有効にすると、名前解決されたホストエントリをキャッシュに入れることができます。

TOPへ

ファイルオプション

この機能は、受信したメッセージをテキストファイルに書き込むために使用されます。

デフォルトでは、一日あたりひとつのファイルが記録されます。新しい項目は、そのファイルの最後に付け加えられます。 ファイルのロックは、データの記録がないときは解除されます。
そのため、サービスが動作している間でも、他のアプリケーションはファイルにアクセスすることができます。
しかし、他のアプリケーションが、そのファイルにロックを設定しないことを確認する必要があります。一般に普及しているwordpadは、これにあてはまります。
ファイルが別のアプリケーションによりロックされた場合、サービスは更なるどんなメッセージ(エラー・イベントは、この場合NTイベントログに記録される)も記録することができません。実行時、ファイルにアクセスするときは、ファイルをコピーするか、あるいは、ファイルをロックしないメモ帳(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

これは、ソースのプロパティがパスの中に使用されているので、上記のようなファイル名の作成が可能となります。
ファイルパス名とファイルベース名には、その他にも様々なプロパティを指定することが可能です。

イベントのプロパティにつきましては、マニュアル2の「イベントプロパティ」をご参照ください。

ファイルパス名  
ファイルを保存するフォルダのパス(ディレクトリ)を指定します。
入力については上図を参照してください。デフォルトは「c:\temp」 です。

「ファイル名のプロパティの置換を有効にする」機能を有効にしている場合、「挿入」をクリックすることで、パス名にソースなどのプロパティを入力することが可能です。(ファイルパス名  F:\syslogs\%source%など

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

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

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

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

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

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

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

「カスタム」フォーマットは、サードパーティのアプリケーションに対して、ログファイルに互換性を持たせるためにフォーマットをカスタマイズすることができます。このオプションを選択することにより、その下の「カスタム ライン フォーマット」の機能がオンになります。

Adiscon」フォーマット以外のものは修正されたものですので、一部のフォーマットオプションは適用できません。それらのオプションは有効になります。

カスタム ライン フォーマット
ここで指定することにより、ログファイルの出力を完全にカスタマイズすることが可能になります。
ファイルのフォーマットにおいて、「カスタム」フォーマットを選択した場合のみ、この機能は有効になり、「挿入」をクリックすることで項目を追加できます。
デフォルト値は、「%msg%%$CRLF%」です。

独自のファイル名を作成  
ここをチェックすると、日付を含むファイル名が毎日作成されます。
 
チェックしない場合は、EventReporterは毎日 新しいファイルを作成しません。
全てのデータが一貫して一つのファイルに書かれるので、日付の部分は省略されます。
(これは、ファイル名を見るカスタムスクリプトを持っているユーザーに使用されます。)

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

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

UTCGMT(グリニッジ標準時)とほぼ同じですが、こちらの方がより正確です。
日本の場合、ローカルタイムは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を使用します。
しかし、「日付と時間を含める」はEventReporterがメッセージを受信した時間を表します。

対照的に、「デバイスのレポートに日付と時間を含める」は、実際のメッセージからタイムスタンプを取ります。
従って、報告するデバイスが持っている時間(オフになっている場合もあります)に左右されます。
さらに、Syslogメッセージの場合、デバイスが報告するタイムスタンプにはタイムゾーンの情報がありません。
従って、複数のタイムゾーンで報告するデバイスが存在する場合は、タイムスタンプの情報は、ばらばらになってしまいます。
これは、RFC 3164Syslogの仕様によるものです。
syslog
サーバは、この場合にはRFCを無視して、一貫したタイムスタンプを提供するように設定することができます。
しかし、「デバイスのレポートに日付と時間を含める」オプションは、「日付と時間を含める」と同様に信頼できるとは言い切れません。
どちらが役に立つのかは明白ではないので、両方のタイムスタンプが存在し、選択することができます。

「メッセージを含む」と「RAW メッセージを含む」は、書き込まれるメッセージ自体に対してカスタマイズを行います。
RAWメッセージを含む」を選択すると、EventReporterで受信した、全く変更が加えられていないメッセージが書き込まれます。
これは、他のアプリケーションでRAWメッセージが必要とされている場合に選択します。


「メッセージを含む」を選択した場合は、タグ値(PRI部)、ホストインフォメーションなど(HEADER部)を含まない、Syslogメッセージが書き込まれます。

注意:「メッセージを含む」と「RAW メッセージを含む」のいずれかを選択するようにして下さい。
どちらも有効になっていない場合には、メッセージが全く書き込まれません。
また、両方を選択してしまうと、二重にメッセージが書き込まれますので、ご注意下さい。

TOPへ

データベースオプション

データベースログをご利用頂くことで、メッセージをデータベースへ保存できます。

データベースログは、ODBCに対応したどんなデータベース(実際、WindowsOSで使用可能な、いかなるデータベースシステムでも)にも、受信したSyslogメッセージを記録することができます。
Adiscon
は、Microsoft JET データベース(Microsoft Accessで使用)とMicrosoft SQL サーバとMySQLをサポートします。 オラクルやSybaseなど様々なシステムで正常に稼動している例もあります。

データベースに一旦保存されると、別のメッセージビューアやアプリケーションで簡単にイベントを閲覧することができます。データベースログアクションのデフォルトでは、AdisconMoniorWareコンソールに適した設定になっています。データベースフォーマットは、変更することが可能です。これは、データベースに別の分析ツールを使用したい場合に、特に役立ちます。また、大規模な環境では、必要とされるフィールドを正確にデータベースアクションで設定することで、データベースが最高のパフォーマンスを得ることができるようになります。

データベースログのアクションで最も重要なのは、フィールドの部分です。
デフォルトは、代表的なイベントプロパティの割り当てをデータベース列へ反映します。
ですが、この割り当ては、自由に変更することが可能です。
「フィールド名(Filedname)」は、データベース列の名称です。予め設定されたフィールド名は、Adisconのスキーマが使用するものです。必要ならば、名称は変更することが可能です。

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

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

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

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

データソース
このボタンをクリックすると、
ODBC アドミニストレータが開始され、データソースの追加、編集、削除を行うことができます。

データベースを生成


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

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

DSN  
DSN
とは、データベースに接続するときに使用される、システム・データ・ソース(DSN-データソース名)の名称です。
それは(Windows NTのコントロールパネル内の)ODBCマネージャで生成されます。
ODBC
データソース アドミニストレータを開くには「データソース(ODBC)」ボタンを押してください。
ここでは、データソースの追加や削除をすることが可能です。

重要事項:ユーザーやファイルのDSNでなく、必ずシステムDSNでなければなりません。また、DSNは正しい接続パラメータ(例えば、データベースのタイプや名称、サーバの名称、認証モードなど)で設定されなければなりません。

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

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

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

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

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

出力エンコード
この設定は、アジアの言語にとって最も重要なものです。
確実に別のエンコードが必要と判断できるとき以外は、 “System Default”のままにして置くことをお勧めします。 “System Default” は、アジア(日本など)のWindowsバージョンであっても、多くの場合において完全に機能します。

詳細なプロパティのログを有効にする
このオプションは、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は、イベントプロパティです。
EventReporter
で使用できるプロパティについては、イベントプロパティに関する項目をご覧下さい。
 

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

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

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

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

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

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


出力エンコード
この設定は、アジアの言語にとって最も重要なものです。
確実に別のエンコードが必要と判断できるとき以外は、 System Defaultのままにして置くことをお勧めします。 “System Default は、アジア(日本など)のWindowsバージョンであっても、多くの場合において機能します。
 

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

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

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

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

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

TOPへ

イベントログオプション

ここでは、EventReporterサービスが、Windows のイベントログに記録できるように設定します。

イベントログソースを置換する  
ここをチェックすると、特別なマッピング・メカニズムが起動されます。
このモードでは、Windowsイベント・ソースは、syslogメッセージを送っているシステムのIPアドレスに設定されます。
このモードは、Windowsイベント・ビューアのシステム状態の情報を早く集めるのに役立ちます。

しかし、このモードには欠点があります。
実際、我々はイベントログに無効なイベント・ソース情報を記録しています。
これはどんなアプリケーションにも害はないですが、Windowsイベント・ビューアは、適合するメッセージ・ライブラリを検出しようとします。もちろん、これは不可能です。
このため、イベント・ビューアは、メッセージ・ライブラリを見つけることができないと以下のメッセージをユーザーに警告をします。(Windows 2000の例)

イベント ID (16) (ソース 192.168.1.1 ) に関する説明が見つかりませんでした。
リモート コンピュータからメッセージを表示するために必要なレジストリ情報またはメッセージ DLL ファイルがローカル コンピュータにない可能性があります。次の情報はイベントの一部です
:

しかし、その場合でもログメッセージは全て表示されます。
これは、詳細表示においてのみ起こります。  
ユーザーは、このオプションをオンにする前に、それらの環境に対するマッピング・メカニズムの動作を充分に理解している必要があります。

カスタム イベント・ソース
ここで「挿入」をクリックすることで イベントログソースをカスタマイズすることが出来ます。
デフォルトでは、「%source%」(ソース)のみ設定されています。
この機能は、「イベントログソースを置換する」機能を有効にしている場合のみ、ご利用頂けます。

ここで挿入可能な
イベントのプロパティにつきましては、マニュアル2 「イベントプロパティ」をご参照下さい。

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

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

10,000以下のIDは、EventReporterによって生成されるイベントと衝突する可能性があるので、使用すべきではありません。(デフォルトは、10000です。)

ログメッセージ
Windowsのイベントログに書き込まれるメッセージを設定できます。
「挿入」をクリックし、%msg% (例) などの置換文字を追加することで、イベント・ビューアに書き込まれるイベントログのメッセージをカスタマイズすることが可能となります。

ここで挿入可能な
イベントのプロパティにつきましては、マニュアル2 「イベントプロパティ」をご参照下さい。

TOPへ

メール オプション

ここでは、メール(SMTP)のパラメータの設定を行います。
電子メールの送信に関する基本的なパラメータを設定します。
メッセージを電子メールで送信するには、このオプションで正しく設定を行う必要があります。

メールサーバー  
メッセージの転送の際に使用するメールサーバー名かIPアドレスを指定します。
指定されたサーバでは、必ず受信者に対するメッセージのリレーができる必要があります。
ここでの設定内容が不明な場合には、あなたのメールサーバーの管理者に確認して下さい。

EventReporterは、標準のSMTPメールサーバーとの接続を前提としています。
最終の宛先へのメッセージの接続は、許可されていなければなりません。

バックアップ メールサーバー
この機能を有効にすると、メインのメールサーバーへの接続に失敗した場合に、バックアップとして設定された別のサーバーへの接続されるようになります。
このバックアップのサーバーへの接続にも失敗した場合に、エラーが作成されます。

ポート  
メールサーバーの接続ポートは、通常25です。
けれども、システムによって変更することもできます。その場合は、あなたのメールサーバーが使用しているポートを指定してください。
指定したいポートに確信が持てない場合は、まず、デフォルト値である25で試すか、メールサーバーの管理者に確認してみてください。

送信者  
メッセージの送信者のEメールアドレスを指定します。
SMTP
サーバが受信できる、有効なアドレスを指定して下さい。

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

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

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

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

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

従来の題名の処理を有効にする
ここでは、題名の処理の方法を指定します。
ここを有効にすると、従来の置換文字列を使用する処理が行われます。
有効にしない場合には、上述のイベントプロパティを組み込む題名処理が行われます。
 

ここを有効にした場合には、以下の置換文字列を題名に組み込むことができます:

%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を設定した場合は、各イベントが個別のメッセージとして送信されます。  

出力エンコード
この設定は、アジアの言語にとって最も重要なものです。
確実に別のエンコードが必要と判断できるとき以外は、 “System Default”のままにして置くことをお勧めします。 “System Default” は、アジア(日本など)のWindowsバージョンであっても、多くの場合において機能します。

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

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

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

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

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

メール本体にメッセージ/イベントを含む  
このチェックボックスでは、syslogメッセージがメッセージ本文に含めるかどうかを制御します。
チェックをしない場合は、本文にSyslogメッセージは含まれません。

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

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

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

チェックしない場合は、メールにはプレーンテキスト・メッセージが含まれます。

TOPへ

Syslog転送 オプション

このダイアログは、Syslog転送オプションを制御します。

Syslog サーバ  
Syslogメッセージを送信する相手先システムの名前(DNS)またはIPアドレスを指定します。

Syslog ポート  
Syslog
メッセージを送信する相手先syslogサーバのポートを指定します。
確信がない場合には、一般的に使用されるデフォルトポート:514のままにして置いてください。別のポートは、例えばセキュリティへの配慮が必要な場合などに使用されます。

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

一般的に、syslogメッセージは、デフォルトであるUDPで送信されます。

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

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

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

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

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

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

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

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

データの圧縮にzLib 圧縮を使用する 
ここでは、Syslogメッセージの圧縮のレベルを設定できます。
詳細は、次の頁をご参照下さい。

メールメッセージ フォーマット  
ここでは、メールメッセージ本体のフォーマットを設定します。(「挿入」をクリックして、メッセージに加えたいプロパティを追加します。)
デフォルトでは、オリジナルのメッセージを転送します。

出力エンコード
この設定は、アジアの言語にとって最も重要なものです。
確実に別のエンコードが必要と判断できるとき以外は、 “System Default”のままにして置くことをお勧めします。 “System Default” は、アジア(日本など)のWindowsバージョンであっても、多くの場合において機能します。

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

注意: このオプションは、RFC 3164と互換性がありません。EventReporterインタラクティブサーバーにメッセージを転送することを目的とする場合には、この機能を使用することをお勧めします。

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

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

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

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

Syslogメッセージがキャッシュされている最中に EventReporterサービスが再起動された場合、その間に Syslogサーバーへの接続が確立されても確認されません。その場合、次に Syslog転送 アクションが実行されるまで接続はチェックされません。 

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

  Syslogメッセージの圧縮に関して >

この機能は、フォーマットを十分に理解されている方(受信者)に対してのみご利用下さい。
圧縮を有効にすると、低帯域幅の環境でも帯域幅を節約することができます。ただし、どれだけ節約できるかは、メッセージによります。(全く節約できないケースもありますが、一方半分ほど節約できるケースもあります)
検証では、WindowsイベントログをXMLフォーマットで送信した場合に、50%ほど帯域幅を節約できました。
非常に小さなメッセージは、まったく圧縮されません。また、XMLフォーマットでない場合、Syslog送信はだいたい1025%ほどに圧縮されます。

TCPによる圧縮送信の場合には、特別なモードにする必要があります。このモード(syslog-transport-tls)は、これから公開されるIETFの仕様がベースとなっています。ただ、このモードはまだ完成されたものではないので、実験的な試みとなります。その結果、今後リリースされる製品でこのモードが使用されるかどうかはわかりません。また、別のモードが今後製品に組み込まれた場合、このモードとの互換性は保証できかねます。

ただ、この機能自体はしっかりしています。
実験的な機能であることをご理解頂いた上でご利用下さい。

TOPへ

SETPで転送 オプション(プロフェッショナルエディションのみご利用頂けます)

このダイアログは、転送に関するオプションを設定します。  
SETPで転送」のアクションでは、メッセージを SETP サーバ(WinSyslogエンタープライズで作成可能なサービス)に転送する事が出来ます。

サーバ名  
EventReporterは、ここで設定する名前によってSETPサーバを認識します。

デフォルトのSETPポート  
SETP
サーバは、 このポートで入ってくる要求を待っています。デフォルト値は 5432です。  

注意:ここで設定されるSETPポートは、サーバ(WinSyslog エンタープライズ)で設定されるポートに合わせなければなりません。それらが合わない場合は、SETPセッションを開始する事はできません。ルールエンジンは、NT イベントログにこれを記録するでしょう。

SSLの有効化/TLSの暗号化  
ここを有効にすることで、このアクションは、SSLTLS SETPサーバに接続することができるようになります。ただし、ここを有効にすると、このアクションはSSL非対応のSETPサーバには接続できなくなります。

データの圧縮に zLib圧縮を使用する
ここを有効にすると、zLib圧縮が使用できます。この場合、STEPの受信側がzLib圧縮をサポートしている必要があります。zLib圧縮に対応していない場合には、これは機能しません。
 

圧縮レベル
高いレベルの圧縮が結果的に良いですが、その場合にはパフォーマンスが低下します。
 

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

高度な接続オプション>

接続のタイムアウト
接続されるまで、または接続が切られるまでにかかる最大の待ち時間を設定します。
 

送信/受信 タイムアウト
データの送受信時に、ここで設定したタイムアウトが適用されます。
 

注意このオプションが有効になっている場合、このアクションはSSL SETPに非対応のサーバーには接続することができません。

TOPへ

Net Send オプション

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

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

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

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

TOPへ

プログラム開始 オプション

ここでは、プログラム開始オプションを設定します。

「プログラム開始」のアクションにより、外部のプログラムを起動することが出来ます。
exeファイルやバッチファイル(BAT)、VBスクリプト(.vbs)などの有効なWindows実行可能プログラムであればどんなものでも起動できます。

実行コマンド  
ここでは、実行させたい実際のプログラムファイルを指定します。
有効な実行可能ファイルであればどのようなものでも指定可能です。システムの検索でファイル名を見つけられる場合、関連するファイル名を指定できます。
(上図では、例として WinSyslogクライアントが設定されています。)

以前のパラメータ処理を使用
ここを有効にすると、従来のパラメータの処理が使用されます。ここが無効になっている場合には、プロパティの処理が使用されます。

パラメータ  
これらのパラメータは、実行されるプログラムに渡されます。
そして、それらは、コマンド・ライン・パラメータとして渡されます。それらには特定のフォーマットはありません-それらの解析はスクリプトによって左右されます。

パラメータは、イベントの詳細でカスタマイズするために、置換文字列を設定することも可能です。これにより、イベントデータがスクリプトに渡されます。以下の置換文字列を使用できます: 

%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へ

サウンド再生

このダイアログは、サウンドファイルを再生させるための設定を行います。  

注意:マシンに複数のサウンドカードがインストールされている場合、常に 最初にインストールされたカードのみが使用されます。

サウンドファイルのファイル名
再生させたいサウンドファイルのファイル名を選択します。このファイルは、wav形式以外のフォーマット(MP3など)はサポートされていません。ローカルマシンのサウンドファイルのみを使用することをお奨めします。リモートでのサウンドファイルの使用は、基本的にはサポートしておりません。

存在しないサウンドファイルが指定されていたり、無効なフォーマットのファイルが指定されていたりする場合には、システムビープ音が発せられます。

再生回数(ファイルを何回再生するか)
サウンドファイルを再生する回数を指定します。

注意:再生回数は、1回から101回まで選択できますが、パフォーマンスを考慮して最低限の回数に抑えることをお奨めします。EventReporterは、サウンド再生のアクションの実行時には、他のアクションは行いませんので、その点もご注意下さい。

サウンド再生の間隔(ミリ秒)
サウンドの再生回数が複数回に指定された場合の、各サウンド再生の間隔をここで設定します。
「カスタム」で値を入力する場合には、その単位は「ミリ秒」として指定して下さい。

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へ

ステータスの設定

このダイアログは、ステータスの設定オプションを設定します。  

各々のインフォメーション・ユニットは特定のプロパティ(例えばイベントID、プライオリティ、ファシリティなど)を持っています。そして、これらのプロパティは、いくつかの値を持っています。
イベントIDがプロパティ値01を持つと仮定します。既存のプロパティの中に「新たに自分で選んだプロパティを追加」したい場合には、このステータスの設定アクションでそれを行うことが可能です。

下図のように、新たにプロパティを作成し、有効な(適当な)値を割り当てることができます。
下図では、プロパティ名を「CustomerID」、プロパティに値を設定において「01」と設定しています。このアクションでプロパティを作成すると、それに対するフィルタを定義することができます。
複雑なフィルタを設定するために、製品の中には内部のステータスリストがあります。

注意: プロパティを変更すると、このアクションが実行されるとすぐに値は変更されます。
ステータスの設定のアクション実行前には変更しません。それから、以前の値は、その後は利用できないので、設定後は全てのアクションとフィルタの条件が新しい値を使用します。 
従って、例えば名前の付け直しを行いたいような場合は、ステータスの設定のアクションをルールベースの先頭に持ってくるようにして下さい。

プロパティ名
プロパティ名を入力します。
ここで設定すると、ルールベースの内部(フィルタの条件とアクション)で使用することができるようになります。

プロパティに値を設定
この値は、プロパティに割り当てられます。
有効なプロパティタイプ値であれば、どんな値でも入力できます。

TOPへ

プロパティの設定

ここでは、プロパティの設定を管理します。

「プロパティの設定」アクションにより、入ってくるメッセージのプロパティのいくつかを修正することができます。これは、管理者が二つのデバイスに同じ名前を付け直したい場合などは特に役に立ちます。

注意: プロパティを変更すると、このアクションが実行されるとすぐに値は変更されます。
プロパティの設定のアクション実行前には変更しません。それから、以前の値は、その後は利用できないので、設定後は全てのアクションとフィルタの条件が新しい値を使用します。 
従って、例えば名前の付け直しを行いたいような場合は、プロパティの設定のアクションをルールベースの先頭に持ってくるようにして下さい。

プロパティ タイプの選択
変更したいプロパティのタイプを選択します。
Insert」をクリックすると、プロパティのリストが表示され選択することができます。

プロパティに値を設定
プロパティに割り当てられる新しい値を入力します。
有効なプロパティ値ならば、どんなものでも入力することが可能です。

ルールセットの呼び出し

このダイアログは、ルールセットの呼び出しオプションを設定します。  

このアクションは、存在しているルールセットの中から、特定のルールセットを呼び出すために設定します。このアクションが実行されると、ルールエンジンは、通常の処理を止め、ここで指定したルールセットを呼び出します。(そのルールセットには、ルールが含まれいます。)そして、呼び出されたルールセット内で定義されたルールが全て実行されます。その後、通常の処理に戻ります。(処理を止めた時点に戻ります。)具体的には、下記の例をご参照下さい。

仮に、Rule1 には、アクション1とアクション2が存在するとします。
アクション1には、この「ルールセットの呼び出し」アクションが下図のように設定されています。Rule1のフィルタの条件が真(True)の場合、アクション1が実行されます。アクション1は、「ルールセットの呼び出し」が設定されているので、そこで設定されているルールセット(Default)を呼び出し、そのフィルタの条件が実行されます。そこで真(True)となった場合には、ルールセット(Default)配下のアクションを全て実行し、アクション2に戻ります。もしも、呼び出したルールセットのフィルタの条件で偽(False)となった場合は、ルールセット(Default)配下のアクションは全く実行されず、アクション2に戻ります。

呼び出すルールセット
呼び出しを行うルールセットを選択します。
ルールセットが1つの場合には、このアクションは使用できません。

TOPへ

ステータス変数算出

このアクションは、内部処理に関するものです。
この機能は、カウンタベースで作用するルールセットに対して必要なものです。
ここでは、ステータス変数算出の管理を行います。

  ステータス変数
ステータス変数名を指定します。ここでは、プロパティの置換(「挿入」をクリック)機能が使用できます。
 

<オプションタイプ>

増加値(+
オペレーション値によって、値が増加されます。
 

減少値(+
オペレーション値によって、値が減少されます。
 

オペレーション値
使用するオペレーション値を設定します。

破棄

破棄のアクションは、現在のインフォメーション ユニット、ならびに破棄アクションの後に設定されている全てのアクションを無効にします。

このアクションは、詳細を設定する必要がないため、アクションの追加で選択しても設定のダイアログは表示されません。

TOPへ

コピーライト

This documentation as well as the actual EventReporter 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

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.

 


Copyright (c)2016 Ihara Inc. All Rights Reserved.
Microsoft、MS-DOS、Windows NT、Windowsは米国Microsoft Corporationの米国およびその他の国における登録商標です。
その他、記載されている会社名、製品名は各社の登録商標または商標です。