サポートセンターホーム


Windowsイベントログの監視

概要

LogicMonitorは、ほとんどのWindowsイベントログに記録されているイベントを検出して警告できます。 アラートをトリガーするには、イベントの特性に一致するようにEventSourceを定義する必要があります。 コレクターがEventSourceに一致するイベントを検出すると、イベントはアラートをトリガーし、定義されたアラートルールに従ってエスカレーションします。

注意: LogicMonitorは現在、Windowsイベントビューアースナップインコンソールの[アプリケーションとサービスのログ]フォルダーの下にあるログの監視をサポートしていません。これらのログはネイティブにWMIに公開されていないためです。 LogicMonitorでアプリケーションとサービスのログを監視する場合は、Microsoftサブスクリプションを使用して、アプリケーションとサービスのフォルダーから別のログフォルダー(「アプリケーション」ログなど)にログを「コピー」できます。 これを実現するためにMicrosoftサブスクリプションとEventSourceの両方を正しく設定する方法については、 サブスクリプションを使用してイベントを別の宛先にコピーするときに必要なフィルター このサポート記事のセクション。

WindowsイベントログEventSourceの作成

新しいWindowsイベントログを定義できます イベントソース from 設定| LogicModules | イベントソース| 新規| イベントソース.

開始するには、 種類 「Windowsイベントログ」へのフィールド。

構成する必要があるその他のフィールドは次のとおりです。

  • に適用されます。 このフィールドは、LogicMonitorのAppliesToスクリプトを入力として受け入れ、このEventSourceに関連付けられるリソースを決定します。 上記の例では、「isWindows()」は、EventSourceがすべてのWindowsデバイスに関連付けられることを示しています。 このフィールドの使用に関する詳細情報(ウィザードおよびテスト機能を含む)、およびAppliesToスクリプト構文の概要については、を参照してください。 AppliesToスクリプティングの概要.
  • グループ。 (オプション)このフィールドでは、複数のEventSourceをフォルダーにグループ化できます。
  • フィルター。 構成ダイアログのこの領域は、アラートをトリガーするためにイベントが持つ必要のある特性を設定します。 アラートイベントID、レベル、ログ名、メッセージ、およびソース名に基づいてフィルタリングできます。 イベントは、[フィルター]セクションのすべての行を満たす必要があります。 上記の例では、イベントIDは7040と等しくなければなりません  そして  文字列 '無効' イベントメッセージに含める必要があります。 
  • アラート設定。 構成ダイアログのこの領域は、このEventSourceのフィルター基準に一致するイベントが検出されたときにトリガーされるアラートの特性を定義します。 ここで構成に使用できる設定は、すべてのEventSourceタイプでほぼ同じであり、 EventSourcesの作成。 ただし、Windowsイベントログに固有のXNUMXつのアラート設定があります。
    • 一致するイベントのアラートレベル。 デフォルトでは、LogicMonitorはWindowsの重大度レベルをLogicMonitorの重大度レベルにマップします(たとえば、エラーからエラー、クリティカルからクリティカル)。 このフィールドを使用して、このデフォルトマッピングを上書きし、特定のWindowsイベントログのEventSourceに対してトリガーされたLogicMonitorアラートに静的アラート重大度が割り当てられるようにすることができます。

      注意: LogicMonitorの構築済みのWindowsイベントログEventSourceには、エラーおよびクリティカルレベルのイベントへのアラートを制限するフィルターがあります。

    • メッセージが異なる場合でも、重複するEventIDを抑制します。 デフォルトでは、LogicMonitorは、で設定された間隔の間、Windowsイベントログイベントを抑制します。 クリアアフター それらの間のメッセージが異なっていても、同一のEventIDを持つフィールド。 このオプションのチェックを外すと、LogicMonitorで、同じEventIDを持つがメッセージが異なるWindowsイベントログイベントを抑制しないようにする必要があります。 同一のメッセージとEventIDを持つイベントは、クリア間隔内で引き続き抑制されます。

      注意: 重複するEventID抑制をオーバーライドするには、Collectorバージョン29.104以降が必要です。

イベントフィルタリング

複数のイベントIDを照合するには、 In 比較操作を行い、パイプ「|」で区切ってイベントIDを一覧表示します。 文字–スペースは無視されます。  

注意:

  • [フィルター]セクションの各行は、論理を使用して結合されます そして 他の行と同じように、行を追加するとフィルターがより制限されます。
  • Windowsイベントログは、WMIを通じて報告されたエラーイベントと重大なイベントの両方に同じイベントレベルを使用します。 ルーティングのアラートレベルを選択するときは、これを考慮に入れてください。 警告よりも何かを選択すると、エラーと重大なイベントの両方がキャッチされます。 クリティカルイベントはエラーイベントと同じようにルーティングされ、LogicMonitorコンソールでエラーレベルのアラートとしても指定されます。
  • Regexmatchは使用しないでください–代わりにIn演算子を使用してください。
  • RegexNotMatchは正規表現をサポートしていません。除外する、バーで区切られたeventIDのリストのみをサポートしています。
  • デフォルトでは、LogicMonitorはレベル情報のすべてのイベントを除外します。 したがって、Logname = Systemのフィルターを指定し、他のフィルターを指定しない場合、情報レベルのイベントを除くすべてのイベントが表示されます。 情報レベルのイベントでアラートを発生させるには、EQUALまたはIN演算子を使用してIDでイベントを明示的に指定する必要があります。
  • 場合によっては、リソースのWindowsイベントログは、データを入力せずにイベントを生成します メッセージのINSERTIONSTRINGS属性。 これにより、LogicMonitorが一致するEventIDを持つイベントをキャプチャしてアラートを生成し、ホスト側から読み取られたnull値を渡す可能性があります。 EventSourceにフィルターを追加して、リソースが誤って生成したメッセージを破棄できます。

## FILTEREDEVENTS ##トークンを使用して、で設定されたFILTEREDEVENTSプロパティの値に基づいてイベントIDをフィルタリングできます。 デバイス, デバイス グループ、またはグローバルレベル。 次のEventSourceフィルターを検討してください。

イベントIDのデバイスまたはグループレベルのフィルタリング

上記の[フィルター]セクションの最初の1111行は、イベントID 10009またはXNUMXのイベントを除き、警告よりも重大度が高いシステムイベントログ内のすべてのイベントを検索します。 XNUMX行目(赤で囲まれている)は、EventIDが## FILTEREDEVENTS ##プロパティに含まれているIDと一致するイベントを除外します。

  • FILTEREDEVENTSプロパティを設定して、イベントを除外できます。 この プロパティを設定できます グローバル、グループ、または デバイス きめ細かい制御のためのレベル。
  • 最初は、FILTEREDEVENTSプロパティがまだ設定されていない場合 デバイス or デバイス グループの場合、これは空の文字列であるため、どのイベントとも一致(または除外)しません。

たとえば、すべてのウィンドウでアラートをトリガーすることからイベントID123を除外するとします。 デバイスs。 これを行うには、プロパティFILTEREDEVENTSをに設定します 123 のトップレベルに デバイス 木。 この設定は、すべての下位ノードに継承されます。

サーバーの123つのグループについて、イベントID 456と、アラートをトリガーする789および123を除外する必要があります。 この場合、filteredeventsプロパティをグループレベルで式456 | 789 | XNUMXに設定できます。 これにより、ルートレベルグループに設定されている、そのグループおよび下位ノード専用の継承プロパティが上書きされます。

このグループ内の特定のサーバーについては、123を含むすべてのイベントでアラートを送信することに関心があるかもしれませんが、456または789ではありません。この特定のサーバーでFILTEREDEVENTSプロパティを再度設定して 456 | 789 上記のすべてのレベルから継承されたプロパティをオーバーライドします。

でフィルタリングしたい場合 構図 上位グループと下位グループに設定された両方のフィルタリングされたイベントのうち、EventSource定義で追加の## FILTEREDEVENTS1 ##、## FILTEREDEVENTS2 ##などのトークン変数を定義し、これらを異なるレベルで個別に定義します。 デバイス グループツリー構造。 それぞれにXNUMXつのトークンを作成します デバイス あなたのグループレベル デバイス 累積的に一致させたいグループツリー構造。

上記の標準フィルターはすべてAND句と組み合わされています。つまり、イベントがアラートを受け取るには、すべてのフィルターで指定されている基準を満たしている必要があります。 これはほとんどの場合に十分ですが、より具体性が必要な場合(たとえば、IISからの場合はeventID 123を無視し、それ以外の場合はアラートを送信する)、またはアラートをトリガーするのに十分な条件がある場合(たとえば、レベルがエラー以上、またはアラートがeventID 123の場合)

複合イベントフィルタリング

複雑なフィルタリングがチェックされている場合、Groovyスクリプトを使用してイベントをフィルタリングできます。 スクリプトは、フィルターの結果としてブール値を返す必要があります。 それ以外の場合、最後の式の値が戻り値になります。

イベントは、戻り値がtrueの場合にのみ検出され、アラートをトリガーします。 戻り値がfalseまたはnullの場合、イベントは検出されません。 他のすべての値は例外をスローし、フィルタリングが失敗する原因になります。

複雑なWindowsイベントフィルターには有効性チェックがありません。 したがって、可能な場合は単純なフィルタリングを使用する必要があります。

たとえば、広範囲のイベントIDに基づいてフィルタリングしている場合、つまり4000から5000の間では、次のGroovyスクリプトを使用します。

(EVENTID> '4000')&&(EVENTID <'5000')

サブスクリプションを使用してイベントを別の宛先にコピーするときに必要なフィルター

LogicMonitorは現在、Windowsイベントビューアースナップインコンソールの[アプリケーションとサービスのログ]フォルダーの下にあるログの監視をサポートしていません。これらのログはネイティブにWMIに公開されていないためです。 LogicMonitorでアプリケーションとサービスのログを監視する場合は、Microsoftサブスクリプションを使用して、アプリケーションとサービスのフォルダーから別のログフォルダー(「アプリケーション」ログなど)にログを「コピー」できます。 ビデオ.

LogicMonitorで使用可能な宛先にログがコピーされたら、次の値に等しい「LOGNAME」のフィルタータイプを追加する必要があります。 。 次に示すように、イベントビューアに表示されるイベントの詳細で、イベントの元のログ名を確認できます。

事前定義された変数

次の事前定義された変数を使用して、処理中のイベントに関するデータにアクセスできます。

お名前
種類
ログ名 文字列
MESSAGE 文字列
ソース名 文字列
LEVEL 整数です。

 

意味
1 エラー
2 警告
3 セキュリティ監査の成功
4 セキュリティ監査の失敗
イベントID 整数

各変数のより完全な定義については、を参照してください。 https://msdn.microsoft.com/en-us/library/aa394226(v=vs.85).aspx。 プロパティの名前は大文字に変換されることに注意してください。

Groovyには多くの演算子がありますが、正規表現演算子を呼び出す価値があります。

演算子
使用法
==〜 「abc」==〜/ a。+ /。 値はtrue 正規表現の一致。 一致する場合、trueを返します。 それ以外の場合はfalse。

スクリプト
意味
(EVENTID == 1000)&&(MESSAGE ==〜/ a。+ / || LEVEL <3) IDが1000のイベントについて、メッセージが「a」で始まる場合、またはイベントのレベルが警告またはエラーの場合にアラートを出します。
(EVENTID == 123)&&(SOURCENAME!=“ IIS”) IISからのものである場合はID123のイベントを無視しますが、それ以外の場合は警告します。
(レベル<2)|| ((EVENTID == 123)&&(LOGNAME ==“システム”)) イベントの重大度がError以上の場合、またはイベントのIDが123であり、システムログに存在する場合にアラートを出します。

記事上で