インストールと設定手順

至れり尽くせりなので公式ドキュメントに手順が書いてあるのじゃ！！

https://mackerel.io/ja/docs/entry/howto/mackerel-check-plugins

使い方

至れり尽くせりなので公式ドキュメントに使い方が書いてあるのじゃ！！

mackerel.io

オプション一覧

公式ドキュメントに無いので追加しました。

# check-log -h
Usage:
  check-log [OPTIONS]

Application Options:
  -f, --file=FILE                                Path to log file
  -p, --pattern=PAT                              Pattern to search for. If specified multiple, they will be treated together with the AND operator
  -E, --exclude=PAT                              Pattern to exclude from matching
  -w, --warning-over=                            Trigger a warning if matched lines is over a number
  -c, --critical-over=                           Trigger a critical if matched lines is over a number
      --warning-level=N                          Warning level if pattern has a group
      --critical-level=N                         Critical level if pattern has a group
  -r, --return                                   Return matched line
  -F, --file-pattern=FILE                        Check a pattern of files, instead of one file
  -i, --icase                                    Run a case insensitive match
  -s, --state-dir=DIR                            Dir to keep state files under
      --no-state                                 Don't use state file and read whole logs
      --encoding=                                Encoding of log file
      --missing=(CRITICAL|WARNING|OK|UNKNOWN)    Exit status when log files missing (default: UNKNOWN)
      --check-first                              Check the log on the first run

Help Options:
  -h, --help                                     Show this help message

`--encoding` で指定出来る文字コード

指定出来る文字コードはSJIS, CP932, EUC-JPはもちろん、様々なエンコーディングのログに対応しています。詳しくは README.md に書いてあります。

ホストで監視出来るメリット

Mackerelのcheckの仕組みはホスト側でログをチェックし、その結果をMackerel側にエージェント経由で送っています。ログを一極集中監視ではなく、ホスト側でチェックスルにはいくつかのメリットがあります。

ネットワークの負荷が軽い
ログを全てMackerel本体に送る場合、自社側のネットワークを通ってMackerelに送る必要があります。これが100台あるApacheのアクセスログの場合はどうでしょうか？自社システム内のネットワーク機器が悲鳴を上げる姿が容易に想像できますね。例えばこれがVLANを切って一つのNICで処理してた場合、悲惨なことが起こります（大丈夫だと思ってた時期が僕にもありました) ではクラウド環境であればネットワーク負荷は気にしなくて良いのでしょうか？そんな事はありません。 AWSでもGCPでもネットワーク代はかかります。ログの転送はそこに直撃するコストですので毎分のチェックのために送信することはコスト増の原因となります。そういったネットワークの観点から見て、ログをホスト側でチェックし、その結果だけを送ることは非常に効率が良いと言えるのです。
セキュリティ面
check-logはログのチェック結果のみを通知するのでログが漏れる心配がありません。アプリケーションのログの中に登録ユーザのメールアドレスが含まれている場合、扱いは慎重になるでしょう。勿論その場合に CRITICAL の文字のみをチェックして結果を送る事ができるため、セキュアにログを監視することができます。
シンプルな設計
ログを一極集中するメリットは詳細な分析を行えることでしょう。勿論そちらのメリットのほうが大きい場合もありますがホスト監視の面で言えば多くはチェック監視（OK or NG)で十分な監視をすることができます。またホスト毎に細かい設定の違いも当然ありえます。例えばDBのマスターとスレーブでは出力されるログが当然違いますし、OSが違えば内容も変わる事があるでしょう。そのためログ 監視 ではホスト毎に細かく調整でき、かつその設定がシンプルなcheck-logがマッチするのです。

`--return` を使って検出した該当の行を一緒に通知する

ログ監視のアラートに気付いたら皆さんはまず何をしますか？まずホストにログインして該当のログを確認するでしょう。その時、「どうせならアラートと同時に該当の行も送ってくれたら良いのに」と思うと思います。安心してください、check-logは出来ます！ --return を引数につけるとErrorの該当の行も通知されるため、Slackやメールでの通知の時点で内容を把握することもできます。また check-log --file /var/log/*.log --pattern FATAL のようにワイルドカードで指定した場合、アラートの対象のファイルも気になると思います。勿論 --return を付けるとファイル名も送ってくれます。これでわざわざsshをしなくても初動対応できますね。

ただし注意点として前述のセキュリティ面のメリットとトレードオフの部分もあります。ご利用の際には秘匿情報などが意図せず送信されないようにご注意下さい。また、送信内容のサイズが大きい場合、表示が切り詰められることがあります

特定の文字列を抽出した場合にアラートを閉じたくない場合

MackerelはステータスがOK変わるとアラートはクローズされ、通知がきます。この自動クローズは便利な反面、ログ監視の場合はこれでは困るケースがあります。ログ監視は1分単位でチェックしているので、例えばめったに出ない文字列を検出していた場合、せっかく検出してアラートが上がっても、次の1分でエラー文字列が出ないと自動復旧してしまいます。例えば夜間バッチで 課金失敗 をチェックしたい場合にアラートが自動的にクローズされると気付くことが出来ない無いわけです。そこでmackerel-agentのチェック監視機能のオプションである prevent_alert_auto_close を使うことで対策することができます。使い方の例は公式ドキュメントに書いてありますので是非使ってみてください。またこの他にも便利なオプションが沢山ありますのでご一読ください。

mackerel.io

さてログの監視は如何でしたでしょうか。シンプルでいて奥が深いcheck-logですが公式ドキュメントを読めば気軽につかえるのもcheck-logです。色んなシーンで活躍できる事間違い無しですのでこの機会に是非使ってみてください。

それでは明日はみんな監視がしたいプロセス監視です！！

8日目 check-procs