ログファイルの監視
最終更新日: 20 年 2023 月 XNUMX 日概要
LogicMonitorを使用すると、OSまたはMySQL、Tomcatなどのアプリケーションによって生成されたログファイルを監視できます。 たとえば、MySQLの低速クエリログを監視して、低速クエリがログファイルに記録されるたびにアラートがトリガーされるようにすることができます。
注： LogicMonitorコレクターは、監視するすべてのログファイルに直接ファイルアクセスできる必要があります。
コレクターは、監視対象のファイルを読み取れる必要があります。ほとんどの場合、これは、コレクターがログファイルとともにサーバーにインストールされている必要があることを意味します（ネットワークマウントを介したアクセス– NFS、CIFSなど–もちろん正常に機能します）。 ）ログファイルの監視は、 Syslogモニタリング 施設。 （多くの場合、Syslog経由でLogicMonitorコレクターに送信されるようにログファイルを構成できます。これにより、サーバーにローカルにコレクターをインストールする必要がなくなります。）ログファイルEventSourceを編集することにより、監視するログファイルを制御できます。 、検索するパターン、およびトリガーするアラートメッセージの種類。 コレクターは、監視対象のログファイルに追加されたすべての行をチェックします。 新しい行が構成されたパターンに一致すると、アラートイベントがトリガーされ、コレクターがそれをLogicMonitorサーバーに報告するため、ユーザーは電子メール/ SMSを介して通知を受け取り、レポートを生成できます。
注： チェックは毎秒実行され、監視対象ファイルへの変更を検出します。
設定方法
このセクションでは、具体的な例を使用して、ログファイルを監視する方法を示します。 たとえば、TomcatWebサーバーを実行するLinuxデバイスdev1.iad.logicmonitor.comがあります。 Tomcatのログファイルcatalina.outを監視して、何らかの理由（JVMがクラッシュしたり誰かがTomcatを強制終了したりするなど）でTomcatがシャットダウンされるたびにアラートが送信されるようにします。 そのための手順は次のとおりです。
- このサーバーにローカルにコレクターをインストールします。 見る コレクターのインストール.
- 設定| LogicModules | EventSources | 追加| EventSource Create NewEventSourceフォームを開きます。
- こちらのページにある「異議申立てフォーム」に必要事項を全てご記入ください： 一般情報 セクションでは、「ログファイル」のEventSourceタイプを必ず選択してください。 フィールドのドロップダウンメニュー。
- 監視するログファイルを ログファイルコレクターの属性 セクション。 少なくともXNUMXつのログファイルを指定する必要がありますが、次に示すように、複数のログファイルを追加できます。
上記の例では、XNUMXつのログファイルが監視されます。最初のログファイルは、glob（つまりワイルドカード）式を使用した動的パス名です。 XNUMXつ目は、コレクターが実行されているデバイスのファイルシステム内のファイルを一意に識別する固定パス名です。 指定されたログファイルごとに、ログファイルに追加された各行が指定されたものと照合されます 行が一致した場合にアラートをトリガーする および 行が一致する場合はアラートをトリガーしません 基準。 クリックすると、ダイアログで基準を変更または定義できます。 管理 （歯車）アイコンまたは +追加 ボタン。 このダイアログでは、ログファイルのパスとイベント基準を定義します。
マッチング基準
アラートをトリガーするかどうかを制御する基準を指定するためのXNUMXつのセクションがあります。 どちらの場合も、基準は正規表現またはプレーンテキストとして指定できます。 一致基準 アラートをトリガーする条件を指定します。 複数の基準は、一致するものが見つかるまで、表示される順序で個別に評価されます。 これは、ログファイルの行が複数の基準に一致する場合、最初に一致する基準によって定義されたアラートレベルのイベントが生成されることを意味します。 前のスクリーンショットに示した例を使用すると、次のようになります。
- 「無効なHTTP応答ヘッダー」のみを含む行が監視対象のログファイルに表示される場合、 WARN イベントは、行全体をイベントメッセージとして生成されます。
- 「StartingCoyoteHTTP」だけを含む行の場合 監視対象のログファイルに表示されます。 エラー イベントが生成されます。
- 両方を含む行の場合 「無効なHTTP応答ヘッダー」と 監視対象のログファイルに「StartingCoyoteHTTP」が表示され、「Starting Coyote HTTP」の前に「無効なHTTP応答ヘッダー」が定義されているため、 WARN イベントが生成されますが、 エラー レベルイベントが生成されます。
基準に一致しない 前に評価されます 一致基準、したがって、ログファイルの行にで定義されたパターンが含まれている場合 基準に一致しない、イベントは生成されません。 一致しない基準は個別に評価されます。 ログファイルの行が一致しない基準のいずれかに一致する場合、イベントは生成されません。
注： 行の一部を、を使用して生成されたイベントのメッセージとして使用することができます。 正規表現 定義するキャプチャグループ。 キャプチャされたコンテンツは、生成されたイベントのメッセージとして使用されます。
デバイスにコレクターがインストールされていないが、このデバイスが、最近アラートを生成した別のデバイスにも適用されるログファイル監視EventSourceの[適用先]に含まれている場合、このアラートは誤って表示されることに注意してください。コレクターがインストールされていないデバイスで複製されました。
Globファイルパスの監視
上記のLinuxファイルパスの例では、 グロブ チェックボックスがオンになっている場合、ログファイルのパス名はglob式として解釈されます。 これにより、可変ファイルパスを監視できます。 グローブを監視する際に考慮すべき特別な考慮事項 Windows ファイルパスはそれです バックスラッシュはエスケープする必要があります 次の例に示すように、別の円記号を使用します。
ログファイルパス
ログファイルへのフルパス。 このパスでは大文字と小文字が区別されることに注意してください。
グロブ
このオプションを選択すると、ログファイルパスでglob式を使用できるようになります。 Globが有効になっている場合、Globパスに一致するファイルのバッチを監視します。 監視は、最後に変更されたファイルに追加された新しい行/変更を探します。
ファイル区切り文字が二重スラッシュでエスケープされていることを確認する必要があります。 C：\\ Program Files（x86）\\ LogicMonitor \\ Agent \\ logs \\ w * .log
この例では、globパスは、「w」で始まるすべてのログファイルと一致します。 ウォッチドッグログ および ラッパー.ログ。 一度に監視できるのは、これらのログファイルのXNUMXつだけであることに注意してください。 そのため、監視はポーリングサイクルごとにwatchdog.logとwrapper.logの間でローテーションします。 これらの両方のログを同時に監視する場合は、XNUMXつの異なるログファイルパスを作成する必要があります（つまり、 wa * .log および wr * .log）またはXNUMXつの別々のログファイルEventSourcesを作成します。
注： グロブ式を使用している場合 UNCパス。UNCパスはXNUMXつの円記号（「\\\\」）で始まる必要があります。
イベントの収集–まとめ
上記のように、 デバイス 監視するログファイルには、コレクターがインストールされている必要があります。 コレクターが起動すると、次のようになります。
- 動的ログファイル（つまり、glob式として指定されたログファイル）のファイル名を監視して、監視する最新のログファイルを見つけます。 ザ・ 最新の ログファイルは、ログファイルの最終アクセス時刻によって決定されます。
- 監視対象のログファイルをテールして、新しい行を読み取ります。
- 読み取られた新しい各行を定義基準と照合します。
- イベントをフィルタリングしてサーバーに報告し、アラートを生成します。
例：アプリケーションの応答時間に関するログファイルの監視
これは、アプリケーションの応答時間についてアプリケーションログファイルを監視する方法を示しています。 Perlを使用する小さなデーモンをシステムにインストールします File :: Tail 指定されたログファイルを監視するモジュール、および処理されたリクエストの数と合計経過時間を追跡するBerkeleyDB。
注： このページで説明されているスクリプトと手順は多くの状況で機能しますが、それらは例としてのみ提示されており、カスタマイズが必要な場合があります。 Linuxのさまざまなバージョンをカバーするように簡単に変更できます。 さまざまなファイルの場所、最大で最後の100サンプルを超える数など。これらの問題についてサポートが必要な場合は、LogicMonitorサポートにお問い合わせください。
手順は次のとおりです。
- Perlモジュールを確認します File :: Tail 監視対象のログファイルとともにホストにインストールされます。 （このドキュメントではカバーされていません。）
- Download AppResponseStats-updater.pl / usr / local / logicmonitor / utils /に移動し、モード755にchmodします。このファイルはデーモンとして実行され、指定されたログファイルを追跡し、「0.34秒で完了」（Rubyで通常使用される形式）の形式の行を監視します。 -on-Railsアプリケーション）。 このような行ごとに、カウンターがインクリメントされ、BerkeleyDBの合計時間レコードも増加します。
- install AppResponseStats-reporter.pl / usr / local / logicmonitor / utils /に移動し、モード755にchmodします。このファイルは、デーモンによってログに記録されたデータを報告するためにsnmpdによって呼び出されます。
- 起動スクリプトをダウンロードする AppResponseStats.init /etc/init.d/に。 それをモード775に変更し、システムの起動時に開始するようにスクリプトを設定します
- snmpd構成を変更して、ポーリング時にレポートスクリプトを実行し、snmpdを再起動します。
- ActiveDiscoveryを待機（またはトリガー）して、レポートされたデータを監視するデータソースがアクティブになるようにします
クイックスタートスクリプト
このスクリプトをホストで使用して、ほとんどのセットアップを完了することができます。 スクリプトの下の手順を確認する必要があります。
必要に応じて、監視対象のログファイルの場所を変更します
次の行を編集して、ファイルAppResponseStats-updater.plを変更し、アプリケーションログを指すようにします。
「Completedin」以外の行と一致させる場合は、コードの次のセクションで正規表現を変更します。
デーモンを起動します
システム起動時にデーモンを自動起動するように設定します。
Debianで：
SuSeまたはRedhatの場合：
データソースをアクティブ化する
DataSourcesAppResponseStats-およびAppResponseStatsProcessはデフォルトのデータソースの一部である必要があります。 そうでない場合は、core.logicmonitor.comからインポートできます。 データソースは、ホストがアプリケーションのログ時間を報告するように設定されているかどうかを自動的に検出しますが、これには数時間かかる場合があります。 これらのプロセスを設定したホストでActiveDiscoveryを実行すると、これを高速化できます。 次に、95つの新しいデータソースグラフのセットが表示されます。95つはデーモンのステータスを監視し、もうXNUMXつは応答時間、XNUMXパーセンタイル応答時間、およびアプリケーションのDBコンポーネント時間と要求数を監視します。 （XNUMXパーセンタイルは、最大応答時間よりも有用な測定値です。最大応答時間は、外れ値の影響を大きく受けます。）
応答時間警告をトリガーするためのデフォルトのしきい値は4秒です。これは、他のすべてのしきい値と同様に、グローバルに、またはグループまたはデバイスごとに調整できます。
ログファイルのエンコーディングのサポートタイプ
デフォルトでは、LogicMonitorはでエンコードされたファイルをサポートします Wウィンドウズ-1252 Windowsおよび UTF-8 Linuxの場合。 デフォルトのエンコーディングは、オペレーティングシステムによって異なる場合があることに注意してください。