Windowsイベントログの監視

概要

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

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

WindowsイベントログEventSourceの作成

新しいWindowsイベントログを定義できます イベントソース から 設定| 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 を持つイベントを作成する場合があります。 イベントを除外するために同じイベント ID フィルターが適用された XNUMX つの EventSource があり、 重複するイベントを抑制 オプションを指定すると、XNUMX つのアラートが表示され、それらは抑制されません。 各 EventSource で XNUMX つのアラートを受け取ります。 これが起こらないようにするには、次を選択します。 重複するイベントを抑制. デフォルトでは、このオプションが選択されています。 これは、 クリアアフター 分野。 その結果、LogicMonitor はホストごとに XNUMX つのイベントをキャプチャし、アラートを生成します。
    
    このオプションが選択されていない場合、重複するイベントは抑制されません。 その結果、EventSource ごとに XNUMX つのイベントがキャプチャーされますが、複数の重複イベントがキャプチャーされ、複数のアラートが生成されます。 単一の EventSource によってキャプチャされたイベントは、指定された間隔内で抑制されます。 
    
    ご注意： すべての重複イベントが単一の EventSource にマップされている場合、単一のアラートが生成されます。
    重複するイベントをキャプチャするには、特定のフィルターを使用してさまざまな EventSource を作成する必要があります。
    重複する EventID の抑制を無効にする機能には、Collector バージョン 29.104 以降が必要です。
    
    例
    <span class="notranslate">シナリオ</span>: 725 つの EventSource がデバイスに適用されます。 フィルタは次のとおりです: EVENTID – XNUMX
    LogicMonitor は、EventId 725 の XNUMX つのイベントを取得しますが、メッセージは異なります。 
    
    このシナリオでは、両方のイベントがこの EventSource にマップされます。
    Status 重複するイベントを抑制 オプションが選択されている場合、単一のアラートが生成され、他のイベントは抑制されます。
    Status 重複するイベントを抑制 オプションが選択されていない場合、XNUMX つのイベントがキャプチャされ、他のイベントは抑制されます。 その理由は、EventSource ごとに XNUMX つのアラートしか存在できないからです。
    
    例
    <span class="notranslate">シナリオ</span>: XNUMX つの EventSource がデバイスに適用されます。
    EventSource 1 の場合、フィルターは – EVENTID – 725 および MESSAGE – メッセージ 1 です。
    EventSource 2 の場合、フィルターは – EVENTID – 725 および MESSAGE – メッセージ 2 です。
    LogicMonitor は、EVENTID 725 の XNUMX つのイベントを取得します。各イベントには、フィルター内の独自のメッセージがあります。
    
    このシナリオでは、1 つのイベントが EventSource 2 にマップされ、もう XNUMX つのイベントが EventSource XNUMX にマップされます。
    Status 重複するイベントを抑制 オプションが選択されている場合、単一のアラートが生成され、他のイベントは抑制されます。
    Status 重複するイベントを抑制 オプションが両方の EventSource で選択されていない場合、XNUMX つのアラート (EventSource ごとに XNUMX つのアラート) が生成されます。

イベントフィルタリング

複数のイベント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フィルターを検討してください。

上記の[フィルター]セクションの最初の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: セキュリティ監査の成功 5: セキュリティ監査の失敗
イベントID	整数

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

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

例