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


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

< 目次 >

WinSyslogについて

機能

構成

システム必要条件

ご使用になる前に

インストール

 設定のエクスポート

WinSyslog の設定

ライセンスの設定

全体オプション

サービス

  Syslogサーバー
  SETP サーバー
  ハートビート
  SNMP トラップ受信
  MonitorWare
  Fcho Reply

フィルタの条件

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

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

Syslog
SNMPトラップ
拡張プロパティ
ファイル確認
フィルタ結果の保存

アクション

ホスト名の解決

ファイル ログ

データベース

OLEDB データベース

イベントログ

メール 送信

Syslog転送

SETPで転送

NetSend

プログラム開始

サウンド再生

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

ステータスの設定

プロパティの設定

ルールセットの呼び出し

ステータス変数の算出

SNMPトラップの送信

コピーライト(英語)

 

WinSyslog 8.2 マニュアル

日本語版

WinSyslogについて

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

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

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

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

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

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

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

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

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

TOPへ

機能

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

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

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

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

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

フリーウェアー・モード
WinSyslog は「フリーウェア・モード」と呼ばれるモードで、有効なライセンスがなくとも、フリーウェアーとして動作します。
このモードは、使用できる機能が制限されますが、使用期間に制限はありません。
インタラクティブ Syslog ビューアで、最新の60のメッセージをインタラクティブに表示(スクロールする)する機能のみがフリーウェア・モードとしてサポートしています。
この機能は、自宅でご使用いただく場合に最も要求されます。 但し、フリーモードでご利用いただけるのは、インタラクティブ Syslog ビューアのみとなります。
Syslog サーバーサービスやメール送信、データベースログなどの便利な機能をご利用になりたい場合には、ライセンスをご購入頂く必要がございます。

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

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

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

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

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

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

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

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

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

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

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

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

Windows 20002003XPへの完全対応
Adiscon 社は、Windows 2000 出荷当時から、完全に対応しています。
そして、WinSyslog はバージョン3.6以降、Windows XP 対応するようデザインされています。
さらに新しい「テーマ」機能や「fast user switching( 高速ユーザー切り替え)」機能にも対応しています。

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

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

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

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

TOPへ

構成

中核となる構成

WinSyslog設定クライアント
WinSyslog設定クライアント(クライアントと呼ばれます)は、WinSyslogサービスの全ての要素と機能の設定に使用されます。
クライアントは、さらにベース・システム上で設定プロファイルを作成するために使用できます。
そのプロファイルは、後に多数の対象システムに割り当てできます。

WinSyslogサービス
WinSyslogサービス(サービスと呼ばれます)は、Windowsサービスとして稼動し、実際の処理を実行します。
サービスは、モニタされるシステムにインストールされる必要がある、唯一の構成要素です。WinSyslogサービスは、製品の「エンジン」と呼ばれています。したがって、サービスのみインストールされたシステムを「エンジンだけの」インストールと呼びます。
サービスは、ユーザーの操作の必要なしにバックグラウンドで動作します。
それは、コントロールパネルやコンピューターの管理 -MMC (Windows 2000)で制御できます。
また、クライアントもサービスの設定するために使用することが可能です。

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

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

 

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

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

 

アドオン構成

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

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

 

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

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

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

 

MonitorWare コンソール

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

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

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

 

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

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

 

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

 

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

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

 

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

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

 

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

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

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

 

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

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

 

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


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


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


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

 

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

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


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

TOPへ

システム必要条件

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

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

OS

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

メモリ

6MB

ハードディスク

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

必要ソフトウェア

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

 

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

OS

Windows 2000 SP3 以降のシステム
Windows 2000/XP/2003/2008 Server/Vistaを含む)

ワークステーション、サーバーを問わず

メモリ

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

ハードディスク

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

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

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

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

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

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

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

TOPへ

ご利用になる前に

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

インストール

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

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

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

< PHPLogConのインストール >

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

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

初期設定を行う

WinSyslog のインストール後は、動作設定を行う必要があります。
なぜなら、指示を行わないと全く処理を実行しないからです。

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

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

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

WinSyslogサービスの起動
これでメッセージの受信、保存の準備が整いました。
WinSyslog
の機能を十分に活かすには、「WinSyslog コンセプト」をお読みください。

 

詳しい設定手順につきましては、以下 URL をご参照ください;
https://www.jtc-i.co.jp/port139/WinSyslog_easy_manual.htm

 

設定情報のエクスポート

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

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

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

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

TOPへ

WinSyslog の設定

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

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

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

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

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

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


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

「全体」では、アクションやサービスのデフォルトだけでなく基本的な操作上のパラメーターを設定とライセンス情報の登録を行います。

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

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

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

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

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

イベントの種類

警告

イベント ソース

AdisconWinSyslog

イベント カテゴリ

なし

イベント ID

1001

説明

A configured syslog server service can not be started. Most often, this happens when more than one syslog server service is configured to use the same port and protocol, e.g. 514/UDP. Please make sure that only a single syslog server is defined to listen on the same port and protocol. If you would like to do multiple actions, this can be done within a single rule set that is bound to a single syslog server service. The socket subsystem reported the following reason: "Can't bind to socket - will keep retrying..." Additional help might be available at http://www.adiscon.com/EventHelp.asp
(設定した Syslogサーバーサービスは、実行できません。これは、同じポートやプロトコルを使用するよう(例:514/UDP)設定されたSyslogサーバーサービスが複数存在する場合に、起こりえます。もし、複数のアクションを実行したい場合には、一つのルールセットを一つのサービスに関連付けるように設定を行ってください ・・・)

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

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


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

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

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

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

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

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

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

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

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

3.    2のルールセットのルール(複数ある場合には上にあるものから順に)に渡されます

4.    3のルール内のフィルタの条件を適用
(設定されていない場合には、全てのメッセージがログファイルに書き込まれます)

5.    4のフィルタ条件に合致したメッセージに対して、その配下にあるアクション(上図の場合「ファイルログ」アクション)が実行されます

上のスクリーンショットは、前頁のサンプルの設定画面です

TOPへ

ライセンスの設定

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

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

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

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

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

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

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

TOPへ

全体オプション

全体オプション                                                                     

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

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

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

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

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

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

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

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

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

エンジンに関して                                                                                  

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

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

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

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

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

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

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

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

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

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

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

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

デバッグ オプション                                                                                  

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

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

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

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

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

<記録される内容>

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

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

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

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

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

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

キュー管理 オプション                                                                            

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

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

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

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

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

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

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

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

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

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

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

TOPへ

サービス

サービスについて
WinSyslog サービスは、Syslogメッセージの受信やSNMPトラップの受信などを行います。
サービスの作成数に制限はありませんが、同じ設定内容(使用ポート・プロトコル)のサービスを複数稼動させることはできません。(その場合、正常に動作しません。)異なった設定内容であれば、同じタイプのサービスを複数稼動させることが可能です。
ただし、サービスを一つも設定しなければ、WinSyslog は全く機能しません。その際には、イベントログに以下のようなエラーが記録されます。

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

Syslogサーバー

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

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

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

使用ポート  
syslog サーバーが使用するポートを指定します。一般的な値は514です。
変更しなければいけない理由が明確である場合のみ、変更を行って下さい。
そのような必要性は、概してセキュリティに対する懸念から生じます。

*ポートの変更を行った場合は、報告を行っているデバイス全ての設定をその標準でないポートを使用するように変更しなければなりません。

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

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

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

注意RFC 3164のメッセージを生成しないデバイスも存在します。
その場合には、このオプションを使用した際に、無効な値がイベントソースに含まれる可能性があります。

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

RFC3164 の構文分析を有効にする
ここを有効にすると、RFC3164の構文分析が有効になります。
ここが無効になっている時には、Adiscon の従来の構文分析が選択されます。
ただし、RFC3164に対応していないデバイスが環境に含まれている場合には、送信側のホスト名やタイムスタンプに問題が生じる場合もありますので、そのような場合には、ここを無効のままにして置くことをお奨めします。

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

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

TOPへ

SETPサーバー

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

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

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

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

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

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

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

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

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

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

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

注意:この機能をご利用になる場合、それ以前のバージョン(7.2.x以前)の WinSyslog へは、このデータが正常に送信できない可能性がございます。従って、この機能をご利用の際は、全ての WinSyslog を最新版にバージョンアップするようにして下さい。

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

TOPへ

ハートビート

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

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

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

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

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

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

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

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

SNMP トラップ受信

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

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

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

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

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

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

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

 

MonitorWare Echo Reply

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

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


フィルタの条件

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

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

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

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

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

TOPへ

全体の条件

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

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

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

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

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

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

TOPへ

オペレーション

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

AND

全ての演算数が「真」でなければなりません。

OR  

ひとつでも「真」のものがあるならば、結果が「真」となります。

NOT  

NOT演算には、ひとつの演算数しかありません。
フィルタが「真」と評価される場合、「NOT」は「偽」となります。

XOR

XOR演算には、1つから2つのフィルタのみ使用可能です。

TRUE

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

FAULSE

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

 

フィルタ

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

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

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

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

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

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

Syslog (タイプ=ブール演算)
ハートビート (タイプ=ブール演算)
SNMP
トラップ (タイプ=ブール演算)

TOPへ

Syslog

ここではフィルタに関連するSyslogが集められています。

全てのインフォメーションユニットは、Syslog プライオリティとSyslog ファシリティを割り当てます。
したがって、これらのフィルタが、全てのインフォメーションユニットと共に使用することが可能です。

Syslog ファシリティ
インフォメーションユニットは、指定されたSyslog ファシリティ値を持っていなければなりません。
Syslog
型のインフォメーション ユニットでは、それは実際のSyslog ファシリティコードとなります。
その他すべては、ベストエフォート型を基礎としてマッピングされた値になります。

Syslog プライオリティ
インフォメーションユニットは、指定されたSyslog プライオリティ値を持っていなければなりません。
Syslog
型のインフォメーション ユニットでは、それは実際のSyslog プライオリティコードとなります。その他すべては、ベストエフォート型を基礎としてマッピングされた値になります。

最初のリストボックスでは、照合のモードを選択できます。
オペレーションは、「未満(<)」、「より大きい(>)」、「等しい(=)」が選択可能です。
照合は、これらのオペレーションに左右されます。
「未満」のオペレーションは、入力したプライオリティ値より小さい 全てのプライオリティを意味します。
この場合、指定(入力)した値は、照合の対象値に含まれません。
もし、その値を含めたい場合は、次に高い値を指定するようにして下さい。

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

SNMPトラップ

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

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

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

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

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

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

 

拡張プロパティ

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

WinSyslog の内部で、全ての値はプロパティに保存されています。
例えば、メインのメッセージは「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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

独自のファイル名を作成  
ここをチェックすると、日付を含むファイル名が毎日作成されます。
 
チェックしない場合は、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を使用します。
しかし、「日付と時間を含める」は WinSyslog がメッセージを受信した時間を表します。

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

「メッセージを含む」と「RAW メッセージを含む」は、書き込まれるメッセージ自体に対してカスタマイズを行います。
RAWメッセージを含む」を選択すると、WinSyslog で受信した、全く変更が加えられていないメッセージが書き込まれます。
これは、他のアプリケーションで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を表示」ボタンをクリックします。「閉じる」ボタンにより、このフォームを終了できます。

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へ

イベントログオプション

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

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

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

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

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

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

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

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

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

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

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

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

TOPへ

メール オプション

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

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

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

サーバ名  
WinSyslog は、ここで設定する名前によって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へ

Post-Processイベント

Post-Processイベントアクションにより、一旦処理されたメッセージの再解析が可能となります。

このような再解析は、標準でないSyslogフォーマットを使用している場合や、メッセージから特定のプロパティを取り出したい場合に、非常に役に立ちます。

Post-Processアクションは、受信したメッセージを取り出し、解析マップにより解析を行います。解析マップには、メッセージのどの位置に、どのタイプのどのプロパティが存在するかが示されています。

メッセージが実際に解析マップに適合する場合、全てのプロパティが引き出され、イベントの一部としてセットされます。
メッセージが解析マップに適合しない場合は、最初に適合しなかったエントリで 解析は停止します。

テンプレート  
解析マップは、非常に複雑です。
解析マップとのやり取りを簡単にするために、それらはXMLファイルで処理されます。

解析マップ エディタ  
ここでは、上図のデータグリッドにおいて、テキストボックスの編集のみ行うことができます。グリッドのエントリを選択すると、その値はテキストボックスで更新されます。そこで行われるどんな編集も自動的にグリッドに反映されます。「挿入」をクリックすると新たに項目が追加され、「削除」をクリックすると選択されている項目が消去されます。

Property  
解析されるプロパティ名です。プロパティのリストボックスには、予め実装された標準とイベントプロパティが含まれています。しかし、ここには新たにプロパティを追加することができます。新たにプロパティを追加する際には、プロパティ名の頭に「u-」を付けることをお奨めします。そうすることにより、既存のプロパティと重複することを避けられます。
例えば、「MyProperty」という名のプロパティを追加したい場合には、「u-MyProperty」とするようお奨めします。

Filler」という名のプロパティは、既に固定されています。このプロパティに振り分けられる全ての値は、破棄されてしまいます。このプロパティは、不要な充填文字などを取り除きたい場合に有効です。

Type  
メッセージから解析されるタイプです。
例えば、「Integer」タイプは、メッセージから1つの整数を解析します。また、「Word」タイプは、次の語を解析します。(ただし、次の語がスペースの場合を除く)

Value 
タイプの中には、値を追加する必要がある場合もあります。その際には、ここで値を追加します。

ルールのメッセージ・プレビュー  
ここは、読み込み専用のボックスです。
設定された構文解析ルールにマッチする仮定のメッセージを表示します。

 

ステータス変数算出

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

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

<オプションタイプ>

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

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

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

SNMPトラップの送信

ここでは、SNMPトラップの送信に関する設定を行います。

 

SNMPバージョン
ここでは、SNMPのバージョンを指定します。
 

エージェント受信機
SNMPトラップを受信するエージェントを指定します。

ここでは、IPアドレスを指定します。 

SNMPポート
ここでは、探査するポートを指定します。

実際に使用する値については、サーバーリファレンスを参照下さい。

たとえば、概して、メールサーバーは25ポート、Webサーバーは80ポートを使用します。 

■ コミュニティ
メッセージの属するSNMPコミュニティを指定します。

SNMP V1特定パラメータ
このグループボックスでは、SNMPバージョン1に関するパラメータを確認できます。

■ エンタープライズOID
ここでは、エンタープライズOIDを指定します。

OIDの選択には、「ブラウザ」オプションを使用できます。ここをクリックすると下記画面が現れます。

 

■ 一般名
coldStart(0), warmStart(1), linkDown(2), linkUp(3), authenticationFailure(4), egpNeighborLoss(5) enterpriseSpecific(6) のようなトラップのGeneric Name を指定することができます。
 

■ 特定タイプ
トラップの追加コードを定義できます。こちらも同様に整数値です。

SNMP変数

SNMPトラップに送信する変数。

トラップコードをご存知の場合、それらを入力することも可能です。そうでない場合は、SNMP MIBブラウザをご利用下さい。 

■ 変更可能なOID
SNMPトラップのOID

利用できるOIDについては、MIBブラウザのリストをご利用下さい。 

■ 変更可能なタイプ
OCTETSTRINGINTEGERなどのタイプ。

このタイプによっては、変数を正確にフォーマットする必要があります。(IPADDRなど )

■ 変更可能な値
タイプによってフォーマットされる必要があります。

 

コピーライト

This documentation as well as the actual WinSyslog product is copyrighted by Adiscon GmbH, Germany. To learn more about other Adiscon products, please visit http://www.adiscon.com/en/products. To obtain information on the complete MonitorWare product line, please visit www.monitorware.com.

We acknowledge using these following third party tools. Here are the download links:

Openssl-0.9.8a:   http://www.adiscon.org/3rdparty/openssl-0.9.8a.tar.gz
Net-SNMP-5.2.1:   http://www.adiscon.org/3rdparty/net-snmp-5.2.1.tar.gz
Liblogging:      http://www.adiscon.org/3rdparty/liblogging.zip
VB6 NeoCaption:   http://www.adiscon.org/3rdparty/VB6_NeoCaption_Full_Source.zip

Note: Microsoft, Windows, and the Windows logo are trademarks, or registered trademarks of Microsoft Corporation in the United States and/or other countries.

Other mentioned trademarks are for reference only. They belong to their respective owners.
 


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