Mackerel あれこれ

さて、そろそろ本年も終わりに差し掛かった頃ですね。
今回のアドベントカレンダーは、Mackerelの小ネタをお届けしたいと思います。標準実装されてないけども、ちょっとしたスクリプトを書くことで実現できることも多くあって、それがMackerelの魅力かなと感じています。実現方法はいろいろ、ご参考になればと思います。

特定の時間帯だけ checks を有効にしたい

日中だけ起動してるサーバで、mackerel-agentを入れるほどでもない。でも死活監視くらいはしておきたい、そんなときありますよね。
そんなときは、mackerel-agentがインストールされてるサーバーをあたかも監視サーバのようにchecksを仕込みます。

[plugin.checks.db_alive]
command = "if [ $(date +%k) -ge 10 -a $(date +%k) -lt 19 ] ; then /usr/bin/mysqladmin56 --login-path=moniter --host <IPアドレス> status ; else true ; fi"

解説

次の動きをします。

10-19時：mysqladmin56 ping の結果をreturnする
それ以外：0 をreturnする

最初のif文で監視したい時間の条件を指定し、それに該当しない場合は常に true を返すようにしています。
こうすることで指定時間以外はサーバーが落ちていてもアラートは発生しません。
この例では 10時〜19時の間に限り、mysqladmin56 ping で MySQLの死活監視ができます。
外部ホストの監視をしていますが、自ホストの時間指定監視にも使えます。ほんとはplugin側で実装した方がスマートです。

Active/Standby構成のとき、Activeホストだけプロセス監視をしたい

Active/Standby構成のときに、Activeホストだけ監視を有効にしたいときってありますよね。そこでこれです。

[plugin.checks.monit_procs]
command = '(ip a | fgrep -q 192.168.0.1; exit $(( $? ^ 1 )) ) || check-procs -C 1 -p "monit"'

解説

今回はActiveホストのみVIPを持っていることを想定して、以下の動きをします。

Activeホスト：192.168.0.1を持っている時はcheck-procsの結果をreturnする
Standbyホスト：持っていない時は、そのまま0をreturnする

細かく見ていきます。
ip a | fgrep -q 192.168.0.1 でVIPを持っていれば 0 が返ります。
$(( $? ^ 1 )) はビット演算のXORで 0 ^ 1 の結果、1が返ります。つまり exit 1でサブシェルを終了し、|| にマッチして check-procsが実行されます。
VIPを持っていなければip a | fgrep -q 192.168.0.1で1が返り、$(( $? ^ 1 ))は 1 ^ 1で両方1になるためビットが反転して0を返します。つまりexit 0でサブシェルを終了し、check-procsは実行されません。

このように特定条件にマッチしたときのみ check-procs を実行することでActiveホストだけ監視することができます。Active/Standbyが入れ替わったときに設定変更しなくて済むので便利ですね。
checksは返り値が1でWARNING、2でCRITICALで通知してくれるので $(exit 2) のようにサブシェルを終了してあげればCRITICALで通知させることもできます。checksに対応していないコマンドの制御にも使えそうです。

AWSインテグレーションで作成したホストにmetricsを追加したい

シェルの解説になってきたので、Mackerelの話に戻ります。

RDSやELasticCacheのホストをAWSインテグレーションで作成したとき、mackerel-pluginのmackerel-plugin-mysqlやmackerel-plugin-memcachedでミドルウェアのmetricsも取りたくなります。mkr throwを使ってAWSインテグレーションで作成したホストにmetricsを送信することができます。

で、それを書こうとしたところで mackerelのヘルプをみると下の方に・・・

プラグインにより取得したカスタムメトリックの連携ホストへの集約に関して

mackerel-agent の plugin 設定には、custom_identifier を指定することができます。custom_identifier とは、ホストの識別子としてユーザー独自の identifier を付与するための仕組みです。これを利用して、別のマシンにインストールした mackerel-agent から投稿されたメトリックを、AWSインテグレーション連携ホストのメトリックとして集約することができます。custom_identifier は、カスタムメトリックを投稿するためのプラグイン設定に指定します。

2016-5-27のエントリで対応していました..。さすがMackerel。進化が早いのもMackerelの魅力ですね。

Mackerelの登録メアドに送られる「Mackerelニュースレター」を読むことをお勧めます。とはいえ見落としてしまうこともありますので、間が空いたときはヘルプの一覧を見ましょう。欲しかった機能が実装されてるかもしれません。

custom_identifierを試してみる

先程見つけた custom_identifier を利用すれば、1つのmackerel-agentで複数ノードのmetricsを管理できますね。mackerel-agentが入らないネットワーク機器の監視に使えそうです。さっそく試しました。

大まかな流れは次のとおりです。

APIでスイッチ向けの custom_identifier を付加してホスト登録
mackerel-agent.conf に metiricsとcustom_identifierの設定をいれて mackerel-agent をrestart
metricsが投稿されたことを確認する

では詳細です。

ホスト登録

mkr create は custom_identifier はまだ対応してないのでAPIでホスト登録します。
サービスは事前に登録してください。

$ API_KEY='XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
$ DATA='{"name":"switch-01","meta":{"network":{}},"status":"standby","displayName":"検証用","roleFullnames":["network:switch"],"customIdentifier":"switch-01"}'

# Mackerelにホスト登録します（nameとcustomIdentifierは同じにしてます）
$ curl https://mackerel.io/api/v0/hosts -H "X-Api-Key: ${API_KEY}" -H "Content-Type: application/json" -X POST -d "$DATA"
{"id":"2SV7JSvNvGu"}

# customIdentifierが登録されてればOKです
$ $ curl -s https://mackerel.io/api/v0/hosts/2SV7JSvNvGu -H "X-Api-Key: ${API_KEY}" -H "Content-Type: application/json"|jq .host.customIdentifier
"switch-01"

なお、statusは maintenance だと mackerel-agent を有効にしたときにerrorになるのでstandbyかworkingを指定してください。

# mackerel-agent起動時のログ（失敗例）
2016/12/13 11:09:04 WARNING <command> Failed to retrieve the host of custom_identifier: switch-01, No host was found for the custom identifier: switch-01

mackerel-agentにmetrics定義を追加する

今回はmackerel-plugin-snmpでCPU使用率を取得することにしました。
mackerel-agent.confに設定をします。

[plugin.metrics.network]
command = "mackerel-plugin-snmp -unit='percentage' -host='<監視対象のIPアドレス or ホスト名>' -name='cpu' -community='<SNMP Community名>' '.1.3.6.1.4.1.9.2.1.57.0:cpu:0:0'"
custom_identifier = "switch-01"

custom_identifierはホスト登録時と同じ値を入れてください。

グラフが描画されたか見てみる

期待通りグラフが描画されています。いい感じです。

どれくらいの台数を捌けるか未確認ですが、ansibleやchef等の構成管理ツールで設定ファイルを動的に生成させると、すっきりした設定管理ができそうです。

最後に

customIdentifierを使えば mkr throw を使っていた監視を置き換えられそうです。いい準備ができました。

それでは引き続き『Livesense Advent Calendar 2016』をお楽しみください。

Livesense Advent Calendar 2016 その1
Livesense Advent Calendar 2016 その2
Livesense Advent Calendar 2016 その3

この記事に目を引いた人はMackerel Advent Calendar 2016も是非ご覧頂ください。