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


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

< 目次 >

EventReporter
ついて

機能

構成

システム必要条件

インストール

設定のエクスポート

EventReporter
の設定

ライセンスの設定

クライアントオプション

全体オプション

サービス

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

フィルタの条件

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

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

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

アクション

ファイルログ
データベース

OLEDB データベース

イベントログ
メール送信
Syslog転送
NetSend
コミュニケーションポートに送信する
SETPで転送
プロパティの設定
ルールセットの呼び出し
ステータスの設定
ステータス変数の算出
ホスト名の解決
プログラム開始

サウンド再生

破棄

コピーライト(英語)

 

EventReporter 14 マニュアル

日本語版

EventReporterについて

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

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

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

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

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

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

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

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

TOPへ

機能

ログの集中管理
これは、EventReporterのキーとなる機能です。
EventReporter
を使用することで、複数のイベントログを整理統合させ、自動的にそれらを管理者等に転送することができるようになります。

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

Syslogサポート
収集した
イベントログ は、syslog 転送することができます。
NT
の重要度(
severity
は、それに相当する Syslog 重要度にマッピングされます。また、Syslog ファシリティ値は、イベントログの種類ごとに変更することも可能です。
デフォルトでは、全てのイベントログタイプのファシリティ値は LOCAL_0 に設定されております。)

SETP のサポート
SETP は、
MoniorWare エージェントのために Adiscon社により開発されたプロトコルです。
Adiscon
製品(MoniorWareWinSyslogEventReporterなど)間の通信をより確実にするよう設計されております。(6.2以降のバージョンで使用できます)

収集したイベントログは、このSETPプロトコルを用いて転送することもできます。

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

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

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

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

Windows2000 2003、2008、XPVista、Windows 7、8、2012 完全対応
EventReporterは、その出荷当時から、完全にWindows20002003XPVista20087、8、Windows 2012 に対応しています。それぞれのイベントログ、さらにはカスタムのイベントログを収集、処理を行うことができます。

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

リモート管理
設定クライアントからリモートによる管理を行うことができます。(プロフェッショナルエディションのみ)
* リモートでイベントログを監視するマシンの台数も必要ライセンス数に含まれます。

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

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

NTサービス
EventReporterサービスは、Windowsのサービスとして実行されます。
サービス名は Adiscon EvntSLog です。
サービスの開始・停止は、設定クライアントのほか、コントロールパネルやコンピュータの管理からも制御できます。

ダブルバイトの文字のサポート(日本語など)
EventReporterは、ダブルバイトにコード化した文字をサポートします。(DBCS
これは、主に日本語または中国人のようなアジアの言語で使用されます。
全てのDBCS文字列は、syslog 転送やEメール送信することができます。
ただし、、受信側もDBCS処理が可能でなければなりません。

Windows版のAdisconsyslogデーモンであるWinSyslog はそれが可能です。
また、出力される文字コードを選択することもできます。
日本のユーザーの為に、シフト-JISJISEUC-JPUTF-8がサポートされてい
ます。

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

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

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

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

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

TOPへ

構成

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

また、多数のマシンで同じ設定でEventReporterを使用したい場合など、ベース・システム上のクライアントで設定ファイルを作成・エクスポートし、対象システムに組み込むこともできます。  
設定情報の保存方法
については、こちら をご参照ください。

EventReporterサービス
EventReporter
は、監視を行うシステム(サーバーやワークステーション)で Windowsサービスとして動作し、実際の処理を行います。

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

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

1) EventReporter サービスは起動後、イベントログを読み込みます。
 

2) 収集されたイベントログは、設定されたルールに従い(ファイル保存やSyslog転送、メール通知など)処理を行います。

3) 上記の処理の終了後、EventReporter は定義された時間だけ休止します。
(休止時間:スリープタイムのデフォルト値は1分です。こちらの値は変更可能です)

4) スリープタイムの終了後、1に戻り、上記の動作を(EventReporterサービスが停止するまで)繰り返します。

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

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

EventReporter 8.0 よりx64プラットフォーム対応版がご利用いただけるようになりました。
8.
x バージョンでは、プラットフォーム別にセットアップが用意されておりましたが、9.0以降のバージョンでは、Win32版とx64版のセットアップファイルは共通となっております。

x64対応版は、セットアップ時に自動的にご利用の OS に合わせてインストールされます。
(インストーラが判断します)

x64版のために変更された主な箇所は、サービスのコアの部分です。
詳細は、以下をご覧下さい:
 

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

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

 

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

Win32版からx64版へのクロスアップデートは、通常のバージョンアップ方法(上書きインストール)では行うことができません。

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

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

x64版の設定情報をレジストリファイルとしてエクスポートする際は、「レジストリファイルに設定をエクスポートする(x64)」を選択してください。詳しくは、後述「設定情報のエクスポート」をご参照ください。

TOPへ

システム必要条件

EventReporter のシステム必要条件は、下記の通りです;

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

OS

Windows 2000 SP3 以降のシステム
Windows XP/2003/2008 Server/7/
8/Server 2012を含む)
ワークステーション、サーバーを問わず
32ビット版、64ビット版の両方に対応

メモリ

6MB

ハードディスク

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

必要ソフトウェア

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

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

OS

Windows 2000 SP3 以降のシステム
WindowsXP/2003/2008 Server/7/
8/Server 2012を含む)
ワークステーション、サーバーを問わず
32ビット版、64ビット版の両方に対応

メモリ

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

ハードディスク

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

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

TOPへ

インストール

まずはじめに、EventReporter はパッケージ化された製品ではありませんので、インストールCDなどはありません。
セットアップファイルは、弊社ホームページ;https://www.jtc-i.co.jp/support/download/ (または Adiscon社のホームページ;http://www.eventreporter.com/en/download/ )よりダウンロードしてください。

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

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

EventReporter は、セットアップ後30日間は、試用版として全てのエディションの機能をお試し いただけ るようになっております。
(試用期間の終了後は、ライセンス登録をしないと EventReporter サービスが起動しなくなります)
 

設定情報のエクスポート

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


EventReporter 設定クライアント-「コンピュータ」メニュー

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

32bitOSEventReporter をご利用の場合には「レジストリファイルに設定をエクスポートする(Win32)」64bitOSでご利用の場合には「レジストリファイルに設定をエクスポートする(x64)」を選択してください。

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

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

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

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

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

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


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

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

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

TOPへ

EventReporter の設定

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

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

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

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

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


▲ EventReporter 設定クライアント(従来のクライアント)

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

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

<全体/デフォルト >
「全体/デフォルト」では、ライセンスキーの登録や基本的な操作上のパラメータを設定します。

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

< サービス >
「イベントログの監視」(Windows のイベントを収集するためのサービス)などのサービスをここで設定します。

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

設定項目は、サービスの種類により異なります。
サービスの有効化・無効化は全てのサービスに共通です。
サービスの有効化によって、サービスは機能します。無効化は、サービスの設定がされていても、それを実行しません。それにより、削除をしなくても簡単にサービスを一時的に使用不能にすることができます。
同様に、右側の設定ダイアログの下にある「使用するルールセット」も、サービスの種類に関係なく共通のものです。

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

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

< ルールセット >
ツリー表示の最後の要素は「ルールセット」です。
サービス(「イベントログの監視」など)で選択したルールセットで定義された処理が実行されるようになります。
(ルールセット
の配下にはルールを作成し、そのルールの配下にフィルタリング《フィルタの条件》などやテキストファイルへの保存《ファイルログ》やメール通知《Eメール送信》、Syslog サーバーへの転送(Syslog 転送)などのアクションを設定します。)

それぞれのルールセットは、完全にお互いから独立しています。
ルールセットは、サービスで「使用するルールセット」として選択され、保存されます。
 

ルールはツリー表示の上にあるものから順に実行されます。
ルールを上や下に移動するには、移動したいルールを右クリックして「上に移動」または「下に移動」を選択してください。
 

TOPへ

ライセンスの設定

試用期間(30日間)終了後、EventReporter を継続して使用するには、ライセンス登録をしていただく必要があります。ライセンス情報は、ご購入後にメール送付させていただきます。(図1参照)


▲図1ライセンス情報のサンプル(抜粋)

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


▲図2 ライセンス登録画面(従来の設定クライアント)

正常に登録されると、アプリケーションログにイベントが出力されます。
ID118、詳細:EventReporter Basic is running in registered mode・・・)


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

また、「?」にカーソルを合わせると、登録されたライセンス情報が表示されます。(従来のクライアントのみ)

ユーザー登録名  
ユーザー登録名は、お好きなものをご指定になれます。
(ご注文時にライセンス申込書 《ユーザー登録名 の箇所》 にご記入ください。)

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

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

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

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

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

TOPへ

クライアントオプション(従来のクライアント)

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

全体オプション

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

設定ツールバーの有効化
ここを有効にすると、クライアント右側上部に開いた設定ウィンドウがツールバーとして表示されるようになります。(下図参照)ツールバーで特定の設定を選択すると、それが最前面に表示されます。

この機能は、「設定ウィンドウを自動的に閉じる」が無効と時に役立ちます。

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

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

その他オプション

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

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

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

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

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

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

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

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

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

クライアントオプション(新しいクライアント)

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

<全般>

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

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

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

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

<設定の読み込み>

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

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

全体オプション

全体オプション                                                                     


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


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


処理の優先レベル
ここでは、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
、またはローカルタイムの指定を行えない設定項目に対しても、ここで選択したタイムスタンプが設定されます。
ただし、プロパティ値(%timegenerated% %timereported%)の基準時刻には、この設定値は反映されません。

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

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

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

エンジンに関して                                                                                  


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

デバッグ オプション                                                                                  


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


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

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

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

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

デバッグ出力を有効にする(必要時のみ)
(ファイルへのデバッグ出力を有効にする)

ここを有効にすると、デバッグのログが可能になり、サービスが稼動する際に書き込まれます。
*パフォーマンスを考慮して、普段は ここを無効のままにして置いてください

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

<記録される内容>

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

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

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

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

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

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

キュー管理 オプション                                                                            


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


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

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

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

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

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

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

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

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

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

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

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

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

TOPへ

サービス

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


▲EventReporter から出力されたエラーのイベントログ

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

イベントログの監視

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

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

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


▲イベントログの監視 サービス(従来のクライアント)

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

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

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

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

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

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

<全体のオプション>


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


▲全体のオプション(新クライアント)

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

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

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

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

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

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

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

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

優先言語
「優先言語」が選択できるようになりました。
(MUI などがインストールされた多言語環境において、特定の言語による処理を優先的に行わせたい場合に設定します)

ここで選択された言語がインストールされており、メッセージ・ライブラリが使用可能な場合のみ機能します。
選択された言語のイベントが見つからない場合には、システムのデフォルト言語を常に使用します。

高度なオプション
従来のクライアントでは、
「高度なオプション」をクリックすると、下の画面が現れます。


▲高度なオプション(従来のクライアント)

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

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

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

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

Syslogタグ値
収集したイベントログを Syslog 転送する際に書き込むSyslogタグ値をここで設定することができます。
どのようなSyslogメッセージなのか判断できるタグ値にしておくと便利です。
(デバイスから送信された Syslog とEventReporter から送信された Syslog がログに混在しているような環境では、どちらのタイプのメッセージなのかこのタグ値で容易に判別することができます)

破損したイベントログの処理方法
ここでは、イベントログの監視サービスが、破損したイベントログファイルをどのように処理するかについて設定を行うことができます。ここでは、以下(図)のオプションを選択できます:


▲高度なオプション-破損したログの処理方法

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

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

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

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

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

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

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

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

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

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

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

 

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

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

「ローカルマシンからイベントログソースを読み込む」オプションを有効にすると、ローカルマシンのメッセージライブラリが使用され、イベントログソースが読み込まれます。

<イベントログタイプ>

ここでは、各チェックボックスを有効にすると、それに応じたイベントログタイプが処理されます。


▲イベントログチャンネル タブ(新クライアント)


▲ 従来のクライアント テーブルの部分

従来のクライアントでは、「高度な設定」をクリックすると、選択したイベントログタイプの詳細な設定を行うことができます。 (「高度な設定」は、全てのログに共通です。)


▲アプリケーションログの高度な設定画面(従来のクライアント)

 

ログの切り捨てを報告する
Windows
のイベントログはプログラムから、またはイベント・ビューアで消去ことが可能です。
消去時、EventReporter が処理していないイベントがあった場合、それらは全て消失します。

EventReporterは、 内部にカウンター(最終レコード)を持っているため、イベントログが消去されれば、それを検知することができます。
「ログの切り捨てを報告する」をチェックした場合、EventReporter はイベントが消去されたことを示すメッセージをイベントに書き込み、最終レコードをゼロに戻します。


▲イベントが消去された事を知らせるイベント

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

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

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

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

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

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

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

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


▲イベントチャンネル(新クライアント)

チェックサムを使用し、最後に処理されたイベントから検索
通常は、EventReporter は「最終レコード」から最後に処理されたイベントを判断します。

ここを有効にすると、チェックサムにより最後に処理されたイベントが検索されるようになります。
したがって、最後に処理されたイベントには、「最終レコード」の値ではなく、チェックサムの結果が反映されます。

Syslog ファシリティ
収集したイベントログをSyslog転送する際に付加する Syslog ファシリティを設定します。

最終レコード
EventReporter は、イベントビューア内のイベントログを先頭から順に数え、最後に処理 したレコード番号を記録します。(スリープタイム明け、最新のイベントをチェックする際、EventReporter はこの番号の続きから読み込みを行います)

このテキストボックスから、この値を上書きすることが可能ですが、慎重にこの機能を利用してください。

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

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

ファイルパス名
ここでは、読み込むイベントログのパスを指定します。

イベントログのタイプ
ここでは、ファイルから読み込んだイベントログをどのタイプのイベントとして処理するのかを指定します。(正しいメッセージライブラリを参照させるために、ここを設定・確認してください)

日付の変数を使用する
ファイルからイベントログを読み込む際、そのイベントログファイルのパスに日付の変数(下表を参照)を指定することができます。例えば、ファイル&パス名に
C:\temp\evt_%Y%m%d.evt と設定した場合はC:\temp\evt_20130101.evt. に置き換えられます。

変数

説明

%y

西暦をで表したもの(例;2002 は02 となります)

%Y

西暦を4桁で表したもの

%m

月を2桁で表したもの(例;3月は03 となります)

%M

分を2桁で表したもの

%d

日にちを2桁で表したもの

%h

時刻を2桁で表したもの

%S

秒を2桁で表したもの
(実際には使用する必要がない変数だと思いますが...)

%w

曜日を1桁で表したもの(例;0が日曜、1が月曜...となります)

%W

曜日を3文字で表したもの
Sun、Mon、Tue、Wed、Thu、Fri、Sat となります

オフセット:秒単位
日付の変数を使用した際、その置き換えられる時間を調整したい場合に設定します。
ここでは、秒単位で値を設定します。例えば、-84600 と設定した場合、一日前の日付に置き換わります。

記録する イベントタイプ
ここでは、処理したいイベントログの種類とその重要度を設定します。
チェックが入ったタイプのイベントを処理します。(デフォルトでは、全てにチェックが入っています)

ここで不要なタイプを無効にすれば、無駄な処理が行われずに済みます。
(例えば、情報のタイプが不要な場合、ここを無効にすれば、ファイル保存やSysぉg転送などの処理でそのタイプのイベントだけ除外されます。)

高度なイベントログ処理 (従来のクライアント)>

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

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

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

%SystemRoot%
この値は、システムフォルダの場所を示す環境変数です。
%SystemDrive%
この値は、システムフォルダを含むドライブを示す環境変数です。
%ProgramFiles%
この値は、プログラムがインストールされるディレクトリの場所を示す環境変数です。
以下の変数は、ポストプロセスコマンドとして使用できます;
%backupfile%
この値は、最後に処理されたバックアップログファイルのファイル名を示す変数です。

< イベントログの消去 >

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

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

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

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

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

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

TOPへ

イベントログの監視 V2(Windows Vista、2008、7、8、2012のイベントログ用)

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

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

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


▲イベントログの監視V2(従来のクライアント)

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

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


▲イベントログの監視V2(新クライアント)

<全体オプション>
スリープタイム(ms:ミリ秒)
イベントログの監視
では、定期的にイベントログの発生をチェックします。
「スリープタイム」では、EventReporter が休止する間隔を指定します。

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

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

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

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

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

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

Syslogタグ値
収集したイベントログを Syslog 転送する際に書き込むSyslogタグ値をここで設定することができます。
どのようなSyslogメッセージなのか判断できるタグ値にしておくと便利です。
(デバイスから送信された Syslog とEventReporter から送信された Syslog がログに混在しているような環境では、どちらのタイプのメッセージなのかこのタグ値で容易に判別することができます)

従来のイベントログ監視から%Param%をエミュレートする
ここを有効にすると、%Param%プロパティが「イベントログの監視 V2」でも使用できるようになります。

プロパティにオプションのイベントパラメータを含める
ここを有効にすると、変数がXML(イベントログ)の<EventData>から参照されるようになります。

イベントログの監視V1対応のイベントに変換する
ここを有効にすると、セキュリティのイベントログのIDがV1(Windows 2000/2003.)にマッピングされるようになります。(InforUnitIDもV1に変換されます)


▲ アプリケーションログの設定(従来のクライアント)


▲イベントログチャンネル タブ(新クライアント)

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

Syslog ファシリティ
収集したイベントログをSyslog転送する際に付加する Syslog ファシリティを設定します。

最終レコード
EventReporter は、イベントビューア内のイベントログを先頭から順に数え、最後に処理 したレコード番号を記録します。(スリープタイム明け、最新のイベントをチェックする際、EventReporter はこの番号の続きから読み込みを行います)

このテキストボックスから、この値を上書きすることが可能ですが、慎重にこの機能を利用してください。

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

処理モード
イベントログをリアルタイムに処理する[サブスクリプションモード](デフォルト)と[ポーリング モード]の2つの処理モードのどちらかを指定します。
[サブスクリプション モード]は、イベントログの生成後すぐにEventReporterに渡されるので、処理の遅れはありません。
[ポーリング モード]は、従来の[イベントログの監視]サービスのような動作をします。スリープタイムで設定した間隔を置いて、イベントログが処理されます。
従来のクライアントでは、このモードを選択すると、[ファイルからイベントログを読み込む]オプションを使用することもできます。


ポーリンクモード選択時(従来のクライアント)

ファイルからイベントログを読み込む
ここを有効にすると、バックアップのEVTXファイルを読み込めるようになります。(ポーリングモード選択時のみご利用になれます)

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

記録する イベントタイプ
ここでは、処理したいイベントログの種類とその重要度を設定します。
チェックが入ったタイプのイベントを処理します。(デフォルトでは、全てにチェックが入っています)

ここで不要なタイプを無効にすれば、無駄な処理が行われずに済みます。
(例えば、情報のタイプが不要な場合、ここを無効にすれば、ファイル保存や Syslog 転送などの処理でそのタイプのイベントだけ除外されます。)


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

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

TOPへ

ハートビート

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

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


▲ハートビート(新クライアント)


▲ハートビート(従来のクライアント)

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

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

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

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

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

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

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

TOPへ

MonitorWare Echo Reply

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

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


▲MonitorWare エコーリプライ(新クライアント)


▲MonitorWare エコーリプライ(従来のクライアント)

 

フィルタの条件

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

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




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




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

図のデフォルトのフィルタの条件は、「AND」のみが設けられています。
この状態では、収集した全てのイベントが真(True)となり
収集した全てのイベント ログに対してアクションが実行されます。
このようなフィルタの条件は、イベントを絞り込まず処理するアクション(例えば、収集した全ての イベントログをデータベースやテキストファイルに書き込む場合など)に使用されます。

一方、特定の条件において(イベントログを絞り込んで)アクションを実行させたい場合には、その条件によって、様々な設定を行うことができます。

下図は、侵入検知を行うための 「フィルタ条件」設定例です。

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

具体的には、 下記の条件を満たすイベントが「真(True)」と評価され、アクションが実行されます。

・イベントログの監視サービスで処理したもので、イベントID:「560」、ソース:「Security」、ユーザー:「P15111116\IUSR_ROOTSERVER」、文字列:「exe」 を含む
\usr\bin\perl.exe」または「\PHP\php.exe」の文字列が含まれていない

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

TOPへ

全体の条件

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


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


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

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

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

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

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

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

TOPへ

日付の条件 (新クライアントのみ)



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

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

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

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

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

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

 

フィルタ

フィルタは、ANDやORなどのオペレーション配下に作成します。
全てのサービス(
「イベントログの監視」や「ハートビート」など)に使用できる共通のフィルタは、数種類あります。また、特定のサービスに対してのみ適用されるフィルタも存在します。

もしも、
設定したフィルタが処理されるイベントやメッセージ内に存在しない場合、それらはフィルタの条件の処理では無視されます (つまり、アクションが実行されません)。
例えば、「イベントログの監視」と「ハートビート」の2種類のサービスが同じルールセットに関連付けされており、そのルールセットのフィルタ条件でイベントIDのフィルタが作成されていた場合、「イベントログの監視」で処理されるイベントにはイベントIDが含まれていますが、「ハートビート」 で処理されるメッセージにはイベントIDが含まれていない為、フィルタの条件ではそのメッセージを無視します。

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

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

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

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

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

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

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

一般

 

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

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

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

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


▲フィルタの条件 ソース(IPタイプ)フィルタの設定例

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

Contains 「プロパティ値を設定」に入力した文字列がイベントのメッセージに含まれる
does not Contain 「プロパティ値を設定」に入力した文字列がイベントのメッセージに含まれない
Contains within range 「プロパティ値を設定」に入力した文字列がイベントのメッセージの指定した範囲内にある *1
is equal イベントのメッセージが「プロパティ値を設定」に入力した文字列と全く同じ内容である
is not equal イベントのメッセージが「プロパティ値を設定」に入力した文字列と異なる

*1範囲の指示は、「オペレーションの比較」から「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つのルールを処理させたい場合、そのインフォメーション (サービス)の種類を選択します。
これは、標準でない処理を必要とする特定のタイプにとって、特に役立ちます。
利用可能な各インフォメーションユニットタイプには、以下のフィルタが定義されています。(下記参照)

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

ハートビート (タイプ=ブール演算)
イベントログ監視 (タイプ=ブール演算)
イベントログ監視V2 (タイプ=ブール演算)

TOPへ

イベントログの監視

ここでは、イベントログに関するフィルタを設定します。
これらのフィルタは「イベントログの監視」サービスで使用します。

イベントID
このフィルタでは、Windows イベントログ のイベントIDを指定します。
このフィルタを設定すると、特定のイベントIDを持って るイベントに対してのみアクションが実行されるようになります。ここでは整数の値を指定して下さい。

タイプ=数字

イベント タイプ
このフィルタでは、Windows イベントログのイベントタイプ(アプリケーションやセキュリティなど)を指定します。
ここで設定したイベントタイプのイベントに対して、アクションが実行されます。
サポートされているイベントタイプの値をリストボックスから選択し、設定します。

タイプ=文字列 

イベント・ソース
このフィルタでは、Windows イベントログ のソースを指定します。
ここで設定したソースのイベントに対して、アクションが実行されます。
ここでは、文字列で値を指定します。
ここで指定する値は、正確に一致していなければなりません。
また、値は大文字と小文字が区別されますので、ご注意ください。

タイプ=文字列

イベント重要度(Severity
このフィルタでは、Windows イベントログ の種類(INF:情報、ERR:エラーなど)を指定します。
ここで設定した種類のイベントに対して、アクションが実行されます。
イベントの種類は、「プロパティに値を設定」のリストボックスから
選択し、設定します。

イベントカテゴリ
このフィルタでは、Windows イベントログ のカテゴリ(分類)を指定します。
ここで設定した分類のイベントに対して、アクションが実行されます。
ここでは、数値を指定します。


タイプ=数字 

イベントカテゴリ名
ここのフィルタでは、Windows イベントログのカテゴリ(分類)を文字列で指定します。
文字列として解決できない場合には、カテゴリ番号が含まれます。

タイプ=文字列
 

イベントレコードナンバー
ここのフィルタでは、EventReporter のレコード番号(内部カウンターの処理番号)を指定します。
イベントログが消去された場合、この番号が狂ってしまう可能性がありますので、ご注意ください。

タイプ=数字 

イベントユーザー
ここのフィルタでは、Windows イベントログのユーザーを文字列で指定します。
ここで設定したユーザーのイベントに対して、アクションが実行されます。
文字列で値を指定するので、値は正確でなければなりません。

タイプ=文字列
 

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

ここでは、イベントログに関するフィルタを設定します。
これらのフィルタは「イベントログの監視 V2」サービスで使用します。

イベントID
このフィルタでは、Windows イベントログ のイベントIDを指定します。
このフィルタを設定すると、特定のイベントIDを持って るイベントに対してのみアクションが実行されるようになります。ここでは整数の値を指定して下さい。

タイプ=数字

イベント チャンネル
このフィルタでは、Windows イベントログのチャンネル(従来のイベントタイプ;アプリケーションやセキュリティなどにあたる)を指定します。
ここで設定したイベントタイプのイベントに対して、アクションが実行されます。
ここでは、文字列で値を指定します。
ここで指定する値は、正確に一致していなければなりません。
また、値は大文字と小文字が区別されますので、ご注意ください。


タイプ=文字列
 

イベント ソース
このフィルタでは、Windows イベントログ のソースを指定します。
ここで設定したソースのイベントに対して、アクションが実行されます。
ここでは、文字列で値を指定します。
ここで指定する値は、正確に一致していなければなりません。
また、値は大文字と小文字が区別されますので、ご注意ください。

タイプ=文字列

イベントRawソース
このフィルタでは、Windows イベントログ のソースを指定します。
ここで設定したソースのイベントに対して、アクションが実行されます。
ここでは、文字列で値を指定します。
ここで指定する値は、正確に一致していなければなりません。
また、値は大文字と小文字が区別されますので、ご注意ください。

タイプ=文字列

イベント重要度(Severity
このフィルタでは、Windows イベントログ の種類(INF:情報、ERR:エラーなど)を指定します。
ここで設定した種類のイベントに対して、アクションが実行されます。
イベントの種類は、「プロパティに値を設定」のリストボックスから
選択し、設定します。

イベント重要度ID
このフィルタでは、Windows イベントログ の種類(INF:情報、ERR:エラーなど)のIDを指定します。
ここで設定した重要度IDのイベントに対して、アクションが実行されます。
ここでは整数の値を指定して下さい。

タイプ=数字

イベントカテゴリ
このフィルタでは、Windows イベントログ のカテゴリ(分類)を指定します。
ここで設定した分類のイベントに対して、アクションが実行されます。
ここでは、数値を指定します。


タイプ=数字 

イベントカテゴリ名
ここのフィルタでは、Windows イベントログのカテゴリ(分類)を文字列で指定します。
文字列として解決できない場合には、カテゴリ番号が含まれます。

タイプ=文字列
 

イベント レベル
ここのフィルタでは、
このフィルタでは、Windows イベントログ のレベルを指定します。
ここで設定したレベルのイベントに対して、アクションが実行されます。
ここでは、文字列で値を指定します。
ここで指定する値は、正確に一致していなければなりません。
また、値は大文字と小文字が区別されますので、ご注意ください。

タイプ=文字列

イベント キーワード
ここのフィルタでは、
このフィルタでは、Windows イベントログ のキーワードを指定します。
ここで設定したキーワードのイベントに対して、アクションが実行されます。
ここでは、文字列で値を指定します。
ここで指定する値は、正確に一致していなければなりません。
また、値は大文字と小文字が区別されますので、ご注意ください。

タイプ=文字列

イベント キーワードID
ここのフィルタでは、
このフィルタでは、Windows イベントログ のキーワードIDを指定します。
ここで設定したキーワードIDのイベントに対して、アクションが実行されます。
ここでは、文字列で値を指定します。
ここで指定する値は、正確に一致していなければなりません。
また、値は大文字と小文字が区別されますので、ご注意ください。

タイプ=文字列

イベントユーザー
ここのフィルタでは、Windows イベントログのユーザーを文字列で指定します。
ここで設定したユーザーのイベントに対して、アクションが実行されます。
文字列で値を指定するので、値は正確でなければなりません。

タイプ=文字列
 

カスタムプロパティ(拡張プロパティ)

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


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


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

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

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

TOPへ

拡張IPプロパティ

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

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

     プロパティ値のテキストボックスで入力したIPアドレスに一致すると真(True)になります
Not プロパティ値のテキストボックスで入力したIPアドレス以外のものが真(True)になります
プロパティ値のテキストボックスで入力したIPアドレスより大きいものが真(True)になります
プロパティ値のテキストボックスで入力したIPアドレスより小さいものが真(True)になります

>または < のオペレーション使用時は、192.168.0.10 192.168.0192.168 192 をテキストボックスに入力することができます(どの値を入力するかは、どのようにフィルタをかけるかによります)。

 

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

 

ファイル確認

 


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


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

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

フィルタ結果の保存

 

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

アクション

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

デフォルトでは、Default RuleSet というルールセットが設定されており、その中に ForwardSyslog というルールがあり、さらにその下に同名のアクションが設定されております(下図参照)
デフォルトの設定では、「フィルタの条件」は未設定の状態、つまりフィルタがないので受信した全てのメッセージを 127.0.0.1 へ(UDP 514番ポートを使用し)Syslog 転送するようになっております。


▲設定クライアント-デフォルトで設定されているアクション

アクションは、ルールの配下に作成します。
ツリー内のアクションを右クリックすると、下図のような補助メニューが表示されますので、「アクションの追加」を選択し、そこから作成したいアクションを選択します。

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

 

ファイルログ

ファイルログ アクションは、収集したイベントログをテキストファイルに保存する場合に使用します。


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


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

デフォルト (上図の設定)では、ファイル名に日付を出力(独自のファイル名を作成 )が有効になっておりますので、一日あたりひとつのファイルが記録されます。
イベントはファイルの上から順に書き込まれます。(新しいイベントは、そのファイルの最後に付け加えられます。)

ファイルのロックは、イベントの書き込みがないときは解除されます。
そのため、サービスが動作している間でも、ログファイルにアクセスすることができます。
別のアプリケーションがロック状態でログファイルを開いたり、ログファイルのコピーや移動のタイミングがイベントの書き込みと重なった場合には、エラーとなり、その間はイベントの書き込みができなくなりますので、ご注意ください。

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

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

「・・・に設定」(従来のクライアント)
この機能は、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:\Program Files (x86)\EventReporter (c:\temp) です。

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

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

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

ファイルの拡張子  
拡張子は、ログファイルを書き込むときに使用されます。
入力については上図を参照してください。デフォルトは「log」 です。
(この値を 「csv」として、エクセルで保存したイベントを確認することもできます)

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

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

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

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

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

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

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

注意: これは、ログファイルの作成の切り替わり時刻について設定するものです。ログファイル内で記録される日付に関しては、別の設定になります。

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

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

ログファイルのデータを消去(ファイル自体は削除されません)
(ファイル
自体を削除せずに、データのみを消去する)

このオプションは、ローテーションを有効にする(循環ログを使用)オプションとともに使用します。
(EventReporter 12.2以降でご利用になれます)
その名のとおり、このオプションを有効にすると、ファイルがローテーションする際、元のファイルは削除されず、その中身(データ)だけが消去されるようになります。
EventReporter のログファイルを別のアプリケーションで監視している場合などに有効です。

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

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

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

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

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

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

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

注意: 出力オプションの一番上にある日付と時間を出力は、EventReporterイベントを収集した時間を出力するものです。
一方、こちらの日付と時間(デバイスのタイムスタンプ)を出力
EventReporter では イベントログが生成された時間を指します。

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

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

メッセージを出力(メッセージを含める)
有効にすると、
ログにメッセージが出力されます。

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

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

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

Raw Syslogメッセージ
ここを有効にすると、ログが Raw Syslog フォーマットで書き込まれます。

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

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

<表示される時刻につきまして>
作成時刻(%timegenerated%)、および報告時刻(timereported%)のプロパティをご利用になる場合、そのままではUTCタイム-9時間)で記録されます。
ローカルタイムで記録したい場合には、それぞれの値の代わりに下記の値(:::localtimeが挿入されています)をご利用下さい:

%timegenerated:::localtime%   %timereported:::localtime%

データベース

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

データベースを生成(従来のクライアント)


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

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

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

DSN
DSNを入力します。

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

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

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

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

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

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

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

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

何も入植されていない場合に NULL値を挿入(プロパティが空の場合、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データベース」


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

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

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

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

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

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

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

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

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

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

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

ステートメントタイプ(SQLステートメントタイプ)
MSSQLのストアドプロシージャ(Stored Procedures)のINSERT、または Call StatementMSSQLストアドプロシージャ)のいずれかを選択できるようになりました。この機能は、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
システムが利用できる値から選択して下さい。

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

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

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

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

TOPへ

メール送信

ここでは、収集したイベントをメール通知する設定を行います。
フィルタの条件(イベントの絞込み)を設定していない場合には、全てのイベントがメール通知されるようになります。フィルタの条件を設定し、必要なイベントのみ送信することをおすすめします。


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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DateヘッダにUTCを使用
WinSyslog が通知するメールのヘッダの基準時刻を設定します。
デフォルトでは、ここは有効になっておりますので、DateヘッダにはUTCタイムの時刻が入ります。

UTCタイムに対応していないメールソフトをご利用の場合には、この機能を無効にしてください。

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

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

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

%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文字)は切り捨てられます。

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

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

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

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

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

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

このオプションは、「メール本体にメッセージ/イベントを含む」を有効にした場合のみ、使用することが可能です。

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

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

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

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

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

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

TOPへ

Syslog 転送

ここでは、収集したイベントログを Syslog サーバーへ転送するための設定を行います。


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


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

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

デフォルトは、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分経過すると、接続が切られるようになります。もしも、処理するメッセージが少ない場合には、これより低い値を設定しても結構です。

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

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

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

<Syslogメッセージオプション>
(転送時の Syslog の処理)

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

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

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

<カスタム Syslog ヘッダ> (従来のクライアント)

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


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

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

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

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

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

送信メッセージカスタムフォーマット )
メッセージフォーマットのボックスで転送するメッセージの編集を行います。
デフォルトは、%msg% のみ設定されています。

「挿入」をクリックして、メッセージに加えたいプロパティを追加します。

Syslogソースの追加(別のSyslogサーバに転送する場合)
(別のSyslogサーバに転送する場合のSyslogソースの追加)

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

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

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

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

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

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

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


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

<SSL/TLS オプション>


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


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

SSL/TLSを使用(SSLに対応していないサーバーへはアクセスできなくなります)
(SSL
の有効化/TLSの暗号化:)

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

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

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

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

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

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

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

<TCP オプション>


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


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

サーバに接続できない時にディスクキューを使用するTCP選択時のみ)
(Syslog
サーバーへの接続に失敗した場合、ディスクキューを使用する )

※ こちらの機能は WinSyslog 用でございます。
 EventReporter は、イベントログファイルを連続データとして処理しておりますので、サーバ接続に失敗した場合でも、復旧後その続きから処理を行います。
(こちらの機能を設定しなくとも、正常な動作においてはログの未処理は発生しません。)

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

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

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

<UDP オプション>


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

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

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

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 エンタープライズで作成可能なサービス)に転送する事が出来ます。


▲新クライアント「SETP送信」


▲従来のクライアント「SETP送信」

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

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

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

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

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

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

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

高度な接続オプション>

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

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

< SETPについて >
SETPは、Simple Event Transfer Protocolの略です。

SETP は、MoniorWare エージェントのために Adiscon社により開発されたプロトコルです。
Adiscon
製品(MoniorWareWinSyslogEventReporterなど)間の通信をより確実にするよう設計されております。
特に、MoniorWare コンソールへデータを転送する際に、このプロトコルを使用した通信が役立ちます。
MoniorWare エージェント、MoniorWare コンソールとも弊社では扱っておりません*

EventReporter プロフェッショナルではSETP転送」アクションが設定できます。
WinSyslog
エンタープライズでは、SETP転送」アクション、およびSETPサーバー」サービスを設定すること が可能です。
SETP転送」アクションと「SETPサーバー」サービスを組み合わせることで、SETPを利用したメッセージ送受信が実行できます。

SETP通信では、クライントとサーバーの間で同期通信がなされます。
SETP
では、イベントは、イベントログの生成元のシステムと同じ状態で転送することができます。
また、SETPTCPをベースにした通信プロトコルですので、より確実な通信を行えます。
SETPは、先に送信したメッセージが受信・処理に成功してから、次のメッセージを送信します。)

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へ

プログラム開始

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

「プログラム開始」のアクションにより、外部のプログラムを起動することが出来ます。
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へ

サウンド再生 Windows Vista 以降のシステムでは利用できません*

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

注意:Microsoft社により実施された仕様変更により、サービスとデスクトップとの対話(サウンドカードへのアクセスも含む)が Windows Vista 以降の OS で実行できなくなったため、それらの OS 上では「サウンド再生」のアクションは利用できません。


▲新クライアント「サウンド再生」


▲従来のクライアント「サウンド再生」

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

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

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

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

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

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

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-1.0.1h: http://www.openssl.org/source/openssl-1.0.1h.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の米国およびその他の国における登録商標です。
その他、記載されている会社名、製品名は各社の登録商標または商標です。