この記事は、Mackerel アドベントカレンダー(全部CRE)の8日目の記事です。 今回は、Mackerelでサービスの異常に気づくための監視ルールと、チェックプラグインについてまとめます。
2つの設定方法
Mackerelでサービスの異常に気づくための設定方法には大きく2つあります。
一つはMackerel管理画面で設定する方法。もう一つは、サーバー上で設定する方法です。
Mackerel管理画面での設定は「監視ルール」にあたります。サーバー上で設定する方法は「チェックプラグイン」を使う方法です。どちらも、どういった状態を満たしたときに、それを異常とみなすか、という条件を設定するための方法です。それぞれできることが違うので、やりたいことに応じて方法を選びます。合わせて使うこともよくあります。
条件を満たして異常と判断された場合はアラートとして、アラート一覧画面に起票されます。
監視ルールを設定する
監視ルール一覧画面で設定できます。 監視ルールには、以下のような種類があります。
メトリック監視
- ホストメトリック監視
- ホストのシステムメトリックやカスタムメトリックに対して、Warning / Criticalといった閾値を設定する
- サービスメトリック監視
- サービスメトリックに対して、Warning / Criticalといった閾値を設定する
死活監視・外形監視
- ホスト死活監視
- デフォルトでは「connectivity」という名前
- エージェントから一定時間メトリック投稿が途絶えるとアラートとなる
- 外形監視
その他
- 式による監視 (「実験的機能」がオンのときのみ)
- 関数を使ってカスタマイズしたメトリックに対して、Warning / Criticalといった閾値を設定する
チェックプラグインを活用する
チェックプラグインを利用すると、メトリックとして投稿しにくいもの(数値の推移では表わしにくいもの)なども監視することができます。 これは、メトリックを取得するためのプラグイン同様、エージェントがインストールされたサーバー上にインストールして使います。
サーバーの状態を条件に基づいてチェックして、OK、NGをMackerelに送ります。 NGを受け取った場合は、アラートとして起票されます。
こんなときはどれを使う?
こんな監視したいなあ、というときに何を使うとよさそうか、ぱっと思いついたものを例に書いてみます。
- サイトトップページが見えているかどうか確認したい
- 外形監視を使います。そのページに必ず表示される文字列などがあれば、レスポンスボディの文字列チェックをします。
- URLごとのレスポンスタイムの平均が1秒を超えたら検知したい
- メトリック監視を使います。
- mackerel-plugin-accesslog を有効にし Latency のメトリックを取得します。取得できたメトリックに監視ルールで閾値を設定します。
- この場合は、アクセスログにLTSVログフォーマットでレスポンスタイムを出力する必要があるので、ログフォーマットを確認します。
- 500番台のエラーレートを監視したい
- これも mackerel-plugin-accesslog で取得した Access Rate にメトリック監視を使います。
- サーバーのCPUやメモリの使用率に閾値を設定したい
- エージェントが取得したシステムメトリックをもとにメトリック監視を設定します。
- サーバー上で動くプロセスの死活監視がしたい
- チェックプラグイン check-procs を使ってプロセスの個数を監視します。
- 特定のログのエラー文字列が1分間に何回出たか監視したい
- MariaDB(MySQL)への接続状況を確認したい
- チェックプラグイン check-mysql を使います。
- SQSのキューのタスクがさばけているかを監視したい
- AWSインテグレーション SQS を有効にし、sqs.message_state.visible にメトリック監視を設定します。
- AWS CPUクレジットが0になる前に検知したい
- AWSインテグレーション EC2 を有効にし、ec2.cpu_credit.balance にメトリック監視を設定します。
- ファイルのタイムスタンプを監視したい
- チェックプラグイン check-file-age を使います。
というように、システムメトリックや、カスタムメトリック(メトリックプラグイン)、監視ルール、チェックプラグインなどなど使いこなすといろいろな監視ができます。
次回は、アラートをどうやって通知するのか、という「通知」の部分についてまとめます。