ログファイル監視①では静的ファイルの監視方法を、ログファイル監視②ではWindowsイベントログの監視とフィルタリング方法を説明しました。本記事では、ログのキーワードを検知するごとに通知を発報する方法を説明します。
文：ジュピターテクノロジー とぐち
はじめに
ログファイル監視①、ログファイル監視②の記事はお読みいただけましたでしょうか。①では静的ファイルの監視を、②ではWindowsイベントログの監視とチューニング方法をご紹介しました。この２つはCheckmkで監視しているホスト（監視対象）ごとに、サービス（監視項目）として登録し、エラーとなるキーワードなどを設定してログファイルをためることができる機能です。ためたログは、ホストに直接アクセスすることなくCheckmkの画面上から内容を全て確認でき、キーワードごとに色分けして一覧表示したり、キーワードの個数がわかるという機能でした。
今回は、そのログを「イベントコンソール」に転送して検知し、通知を行う方法を説明していきます。
イベントコンソールって何？
今回は、ログの管理に「イベントコンソール」を使用します。イベントコンソールは、SNMPトラップなどをホストから受信し、特定のキーワードが含まれていたら検知→通知をしたり、リアルタイムでイベントを管理している機能です。この機能は、各ホストで監視しているログファイル監視と組み合わせることができます。
では、ログを取得したあと、イベントコンソールにわざわざ転送するメリットとは何でしょう。
転送して監視するメリットは？
- ログ出力ごとにイベントコンソールに転送されるため、出力（行）ごとにアラート発報が可能
- 複数の端末から集めたログファイルに対し、イベントコンソールのルールで一括でアラート条件を設定可能
- イベントコンソール一覧上で、テキストやホスト名などでフィルター検索が可能
ログファイル監視①②でご紹介した方法で監視する場合、そのログだけに特化してフィルターをかけたり、キーワードの個数を数えたり、色分け表示する、など管理には適していますが、発生するごとにアラートをあげることはできません。その点、イベントコンソールであれば、１行発生するごとに通知を行うことはもちろん、複数のホストのログファイルを一気にフィルタリングして確認する、など活用の幅が広がります。
設定方法
それでは、実際に画面を見ながら確認します。
事前準備
過去のシリーズ記事を参考に、任意の静的ファイル監視設定が完了していることとします。
後程重要なポイントとなるため、事前準備で設定した静的ファイル監視設定確認しておきます。図1赤枠が、今回のメッセージ条件キーワードです。
転送ルール「Logwatch イベントコンソール転送」設定
監視したいファイルがサービスとして追加されていることを確認してください。今回はLinuxサーバー上で/var/log/syslogを監視するサービスを追加しました。
セットアップの検索ボックスで「logwatch」と検索し、サービス監視ルール「Logwatchイベントコンソール転送」を選択します。
[ルールを追加]ボタンをクリックし、赤枠の通り新しいルールを作成します。
[メッセージをイベントコンソールに転送する] ・転送されたメッセージのSyslog機能：「local1～7」のいずれかを選択。※後程また使用します。 ・ログファイルの制限：対象のログファイル（サービス名「Log xxxxxxxx」のログ名の部分。複数可） ・ECに転送する前にメッセージを再分類します：ログウォッチパターン適用 チェック有効
・「転送されたメッセージのSyslog機能」はすでに他ルールで設定済のlocalナンバーは避けてください。後程転送設定・通知設定を行う際のフィルタリングに使用します。
・「ECに転送する前にメッセージを再分類します」はチェックを有効にしてください。本記事の図1の画面で設定した、キーワードによる「OK」「WARN」「CRIT」または「無視」、など、イベントコンソールに転送する前に事前に区分の割り当てをしてくれます。
注意：１秒に何行も出力するようなログを全て転送することは避けてください。イベントコンソール上での負荷が高くなり、処理が滞る可能性があります。そのため必ず上記「ECに転送する前にメッセージを再分類します」のチェックを有効にしてください。特に「無視する」キーワードを設定し、不要なログは転送しないようにすることが重要です。
画面下部の条件設定が必要であれば対象フォルダや対象ホストを選択し、保存します。
変更の適用（図5右上X個の変更！をクリック）を実施したら、再度対象ホストに対しサービス取得を行ってください。
元々ログファイルを監視していた「Log /var/log/syslog」というサービスが消失したサービスとなり、「Log Forwarding」というサービスが別途検出されます。このまま[受け入れる]ボタンをクリックするか、それぞれ削除と追加する作業を行ってください。
この後も必ず変更の適用を実施してください。
変更の適用が完了したら、モニター＞”概要”＞全てのホスト から監視対象のホストを選択し、「Log Forwading」が追加されていることを確認します。
これでホスト側の設定は完了です。
イベントコンソールルール設定
セットアップ＞”イベント”＞イベントコンソール でデフォルトのルールパックに新しいルールを追加します。デフォルトルールパックの、アクション右から二番目（図8赤枠）のボタンをクリックしてください。
[ルールを追加]ボタンで新規ルール作成し、ルールIDを入力
「一致するsyslogファシリティ」には、必ず図4で設定した「Local x」と同じ値を入力します。
「アクション」の「監視通知を送信する」のチェックを有効にすると通知を発報することができます。（通知設定は後程実施します）
ここまで入力できたら、[保存]ボタンより保存し、変更の適用を実施してください。試しに、図11のようにloggerコマンドを３回実施してみます。
Checkmkのサービス画面では、図12のようにキーワードに引っ掛かった件数が表示されています。
そしてイベントコンソール画面には、図13の通り7行分の転送されたログが並びました。このOK/CRITの分類は、図1で示した「Text logfiles」のキーワードの状態区分で分類されています。
OKの行を表示させたくない場合は、イベントコンソールのルールにマッチング基準を追加します。（図14）「一致するテキスト」に任意のキーワードを追記すれば完了です。
保存し、変更の適用を実施。
すると、Errorというキーワードのある「CRIT」状態のログだけイベントコンソールに転送するようになります。（図15）
これでイベントコンソールの設定も完了です。
※ルール：「ファイルグループの監視」で、ホストのログファイルをまとめて一つのサービスで監視している場合はイベントコンソール転送の機能は使用できません。
通知ルール設定
最後に通知設定です。イベントコンソールへログが転送されたら状態に合わせて通知が来るように指定します。
セットアップ＞”イベント”＞通知 より[ルールを追加]をクリック。通知方法などは任意でお好きなように指定し、条件指定欄の最下部にある、「イベントコンソールアラート」のチェックを有効にし、図16赤枠の通り設定します。
[イベントコンソールアラート] チェック有効 イベントコンソールアラートのみに一致 ルールID または 一致するsyslogファシリティ ：通知したいルールの値を指定
この条件指定時は、「マッチサービスイベントタイプ」にCRITでチェックを入れるなど、複数条件を組み合わせてしてしても問題ありません。これで通知の設定も完了です。
イベントコンソールに条件にマッチしたイベントが検知されると、通知が発報されるようになります。
実際に通知が発報されたかどうかは、セットアップ＞”イベント”＞通知 の最新の通知欄で確認できます。
転送後のフィルタリング機能
[フィルタ]ボタンで画面右側のフィルタ画面を表示させ（図18）、ホスト名、ルール名、状態、メッセージテキストなどで、過去に受信したイベント含めて一括でフィルターを適用することができます。
過去の類似した事象を検索したり、ホストごとの検知数を確認したり、受信後のイベントに対して様々な分析をする際に便利な機能です。
おわりに
ログファイル監視のシリーズとして３回に渡って便利な機能をご紹介してまいりましたが、いかがでしたでしょうか。
Checkmkではログ発生時、イベントコンソール転送時、転送後、と３回のフィルタリングのタイミングが存在します。豊富なこのフィルターの組み合わせを利用すれば、複雑なログファイル監視や条件の指定に対応することができるのではないでしょうか。ぜひ、本記事を参考にお試しください。
お問い合わせ
Checkmkにご興味のある方は、以下リンクよりいつでも弊社までお問い合わせください。
30日無償でご利用いただける評価版も以下のダウンロードリンクにご用意しております。評価ガイドをもとに簡単に検証ができますので、ぜひお試しください。
