ログファイルの監視

Checkmk Raw の Windows エージェント用インストールパッケージには、Python 環境は含まれていません。 ただし、対応するキャビネットファイルは、Checkmk サーバーにすでに用意されています。 このファイルは、~/share/check_mk/agents/windows ディレクトリ、または Checkmk のSetup > Agents > Windows > Windows Agent に、python-3.cab という名前で保存されています。 このファイルを、Windows ホストのC:\Program Files (x86)\checkmk\service\install ディレクトリにコピーします。 この名前で、ファイルサイズが 0 バイトのファイルがすでに存在します。 このファイルを、Checkmk サーバーのバージョンで上書きする必要があります。 その後、Checkmk エージェントサービスを再起動してください。 管理者権限のある Windows パワーシェルでは、次のコマンドでこれを行うことができます。

Windows サービスが再起動すると、仮想 Python 環境が自動的にインストールされます。

または、python.org から最新の Python パッケージをダウンロードしてインストールすることもできます。 インストール中に、以下のオプションを必ず有効にしてください。

Python のインストール後にすぐにテストを開始したい場合は、Windows タスクマネージャーまたは上記のコマンドを使用して、checkmkservice を再起動する必要があります。そうしないと、サービスは新しい環境変数を認識しません。

商業版では、まず エージェントプラグインのルールSetup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Text logfiles (Linux, Solaris, Windows) を呼び出します。 デフォルト設定Deploy the Logwatch plugin and its configuration は通常、そのままにしておきます。 ただし、設定ファイルlogwatch.cfg を別の方法でホストに転送したい場合や、その必要がある場合は、ここでDeploy the Logwatch plugin without configuration オプションを使用できます。

Retention period オプションで続けます。 ここでのデフォルト設定は 1 分で、これは Checkmk の事前設定のチェック間隔とも一致しています。 この値は、常にチェック間隔以上にしてください。 このオプションは、主に、サービス検出またはcmk -d myhost の手動実行によってログメッセージが失われることを防止する役割を果たします。 詳細については、このオプションのインラインヘルプおよびこのオプションが導入されたWerk #14451をご覧ください。

いよいよ、ルールが実際に機能するセクション、Configure a logfile section に進みます。 まず、ここ数年の最大の難関から始めましょう。Patterns for logfiles to monitor フィールドには、監視するログファイルを指定する必要があります。 これは、個別に明示的に指定することも、いわゆるグロブパターン（略してグロブ）を使用して指定することもできます。 ここでは、Python モジュールglob を使用しています。このモジュールについては、docs.python.orgに詳細なドキュメントがあります。 ただし、ここでは、いくつかの役立つ例を紹介しておきます。

たとえば、ここに「/var/log/my.log 」と入力すると、logwatch はこの 1 つのログファイルのみを監視します。 代わりに「/var/log/*log 」と入力すると、logwatch は、文字列「log 」で終わり、/var/log ディレクトリに直接あるすべてのファイルを監視します。 /var/ のすべての直接サブディレクトリにあるログファイルを監視したい場合は、たとえば、/var/*/*log というグロブを使用します。 ここでは、ディレクトリ構造を再帰的に検索するためのグロブ** は明示的に提供していません。これは、ヒットリストがすぐに膨大になり、logwatch の本来の目的が失われてしまうためです。

次の表は、ファイル名を個別に指定することなく、監視が必要なファイルを実際に監視するためにグロブを使用する方法の、さらに役立つ例をいくつか示しています。

したがって、最初のステップで「一致」するファイルを決定する際には、正規表現は使用しません。この方法で、必要なファイルすべてを抽出できる場合が多いでしょう。

ただし、さらにフィルタリングが必要な場合は、Regular expression for logfile filtering オプションを使用して、ステップ1で一致したファイルに正規表現を適用する2段階目の処理を行うことができます。

すべてのファイル /var/log/と、その直接のサブディレクトリを収集したら、/var/log/ と/var/log/*/* を使用して、正規表現error.log$|err$ を使用して、ヒットリストをerr.log またはerr で終わるすべてのファイルに絞り込むことができます。 注意: 「ドット」 (.) は、ここでも任意の文字です。 これにより、たとえば、/var/log/apache2/error.log 、/var/log/mail.err 、および/var/log/cups/error_log ファイルは除外されます。

ご覧のとおり、監視するファイルを選択するための 2 つの優れた強力なツールがすでに用意されています。これにより、logwatch は、次のステップで、管理しやすいファイルリストを使用して、他のパラメータやコンテンツも非常に迅速にチェックすることができます。 後者については、「Checkmk の正規表現」の記事で詳しく説明しています。

Restrict the length of the lines オプションを使用すると、指定した文字数を超えた行をログウォッチで切り捨てることができます。

次のオプションWatch the total size of the log file は、ログのローテーションに問題があることを認識するのに役立ちます。 ここで 100 MiB を設定すると、特定のログファイルが指定したサイズを超えたたびに警告が表示されます。

logwatch が 1 回の実行でチェックする行の最大数は、Restrict number of processed messages per cycle で制限できます。また、Restrict runtime of logfile parsing を使用すると、前回のチェック以降、何千もの新しいエントリが殺到した可能性のある 1 つのファイルに logwatch が過大な時間を費やすことを防ぐことができます。

後者の 2 つのオプションのいずれかを有効にする場合は、指定した制限を超えた場合にどうするかも指定する必要があります。 デフォルトの設定では、関連するサービスがクリティカルになり、行がスキップされたか、最大ランタイムを超えたことを示すメッセージが表示されます。

Handling of context messages は、転送データ量が非常に早く膨大になる可能性のあるオプションです。 したがって、 または を生成すべきログメッセージだけが重要なのか、それとも logwatch の前回実行以降に追加CRIT WARN されたすべての行を Checkmk サーバーに転送すべきかを慎重に検討してください。 1 分間に数行しか増えない小さなログファイルの場合は、 の設定で問題はありません。 しかし、ホストで 50 個のログファイルが監視されており、そのファイルに 500 文字の長さの 100,000 行が突然追加された場合、その容量はすでにギガバイト単位になります。 このような場合、前回のチェック以降、多数の新しいメッセージが追加されたことを確認するだけで、該当するホストを直接チェックすれば十分でしょう。Do transfer context

コンテキスト、つまり、重要なログメッセージの前後の行も必要な場合は、Limit the amount of context data sent to the monitoring server オプションを使用して、前後の行数を一定数に制限することができます。

Limit the amount of data sent to the monitoring server を使用すると、転送されるデータのサイズを一般に制限できます。

Process new logfiles from the beginning はデフォルトでオフになっています。 これにより、logwatch はログファイル内の問題を「認識」せず、Checkmk サーバーにそれらを転送するため、驚くことがあるかもしれません。 私たちの考えでは、昨日の新聞ほど古いものはないのと同様に、logwatchを初めて実行する前にログファイルにすでに存在していたログメッセージも古いものです。 この最初の実行では、logwatch は、それぞれのログにすでに何行が含まれているかを記録するだけです。 2 回目の実行で初めて、ファイルの内容、つまり新しく追加された行がチェックされます。

ログウォッチは、ログファイルを実際に読み込めることを前提としています。 内部では、ログウォッチは各ログファイルのエンコーディングを認識するために多大な努力を払っています。 ただし、あまり一般的ではない文字エンコーディングでは問題が発生する可能性があります。 監視するログファイルの文字エンコーディングを指定できる場合は、UTF-8 を選択することをお勧めします。 それが不可能な場合、ログウォッチがエンコーディングを認識できない場合は、Codec that should be used to decode the matching files で明示的に指定することができます。

Duplicated messages management を有効にすると、再び帯域幅を少し節約でき、Checkmk での出力もより読みやすくなります。Filter out consecutive duplicated messages in the agent output を有効にすると、logwatch は行が繰り返された回数をカウントし、行を繰り返す代わりに、その回数を出力に書き出します。

最後に、ログファイル内の関心のある行は、正規表現を使用して記述され、状態が割り当てられます。panic という単語を含むすべての行を Checkmk でCRIT にしたい場合は、Regular expressions for message classification の下にあるAdd message pattern をクリックし、Pattern(Regex) フィールドにpanic と入力するだけで十分です。 その他のオプションの機能については、この時点でのインラインヘルプで詳しく説明されていますので、ここでは繰り返しません。

注意すべき点：OK 状態は、一見するとわかりにくいかもしれません。 これは、最終的な分類を行うために、まずログファイルから Checkmk サーバーにラインを転送するために使用されます。 ここで、logwatch を正しく使用すると、その柔軟性がわかる重要なポイントがあります。

このセクションで説明したすべてのオプションは、すでに述べた、それぞれのホストに保存されている設定ファイルへのエントリになります。 特定のメッセージの分類を変更したい場合は、まずルールを編集し、エージェントをベイクしてインストールする必要があります。

あるいは、まず、すべての興味深いメッセージを Checkmk サーバーに転送し（たとえば、OK ステータスを使用）、Checkmk サーバーでLogfile patterns ルールを使用して（再）分類することもできます。 こうすることで、新しいエージェントのベイクとロールアウトの手間を省くことができ、上記のルールを適宜カスタマイズした後、変更を 1 回だけ、すばやくアクティブにするだけで済みます。 その方法の詳細については、以下の「ログファイルパターンによる再分類」の章をご覧ください。

Checkmk Rawでは、テキストファイルを使用して、通常どおりエージェントプラグインを設定します。 通常、ログウォッチは、/etc/check_mk （Linux）またはc:\ProgramData\checkmk\agent\config\ （Windows）ディレクトリで、logwatch.cfg というファイルを探します。 （ほぼ）最小限の設定は、次のようになります。

まず、常にグロブパターンを入力し、その後に適用するすべてのオプションを入力します。 その後に、1 スペースのインデントを入れて、希望の状態または機能を表す文字、そして最後にログファイルの各行と比較される正規表現を入力します。 上記の設定では、logwatch の前回実行以降、ファイル/var/log/my.log に追加されたすべての新しい行が、a critical message およびsomething that should only trigger a warning の 2 つのパターンについてチェックされます。

サイトユーザーに適用できる非常に包括的な設定例は、~/share/check_mk/agents/cfg_examples/logwatch.cfg ファイルにあります。

このような設定ファイルで指定できるオプションは、すべて「エージェントベーカリーによる設定」セクションで説明していますので、ここではリストと簡単な説明のみを記載します。 詳細については、上記のセクションを参照してください。