えいのうにっき

a-knowの日記です

Mackerel のカスタムプラグインを作るのは実は簡単だよという話

この記事は、Mackerel アドベントカレンダー(全部CRE)の7日目の記事です。

全国3000万人(大嘘)のMackerelユーザーのみなさん、プラグイン、使ってますか!? ......もちろん使ってますよね!

Mackerel が公式としてメンテナンスしているプラグインは、以下のように GitHub 上に Public Repository として公開されており、便利なものが取り揃えられております。

github.com

github.com

上記リポジトリの内容をご覧いただければおわかりいただけるように、公式プラグインについては「クロスコンパイルによる様々な環境に向けたバイナリの作りやすさ」「フットプリントの小ささ」といったメリットを考慮して、すべてGo言語で開発しているわけですが、このせいか、「自分でプラグインを作る場合でもGo言語でなければ作れない」と勘違いされている方が意外に多いです。

そんなことないです!! 作れますよ、どんな言語でも!! ......ということを、今日はこのエントリでお伝えできればと思います。

まずは用語と前提知識の整理

今日のこのエントリでは、メトリックプラグインチェックプラグイン の二種類のプラグインの作り方について解説したいと思っていますが、それぞれの違いはみなさん、大丈夫でしょうか?

  • メトリックプラグイン
    • 各ホストに依存するメトリック値を取得、送信するためのもの
      • サーバーリソースの値などがこれに該当する
    • 送信されたメトリックは カスタムメトリック として、対応するホストのグラフとしてその値が描画される
  • チェックプラグイン
    • 各ホスト上の監視対象の状態を OK NG 判定し、その結果を送信するためのもの
      • 特定プロセスの死活状況などがこれに値する
    • 送信された情報はグラフとして描画されることはない
      • 送信された情報をもとに、アラートがオープン or クローズされる

......大丈夫ですね?

そしてプラグインは、それ自身(プラグインの実行バイナリとか)が自動的に動き出すようなものではなく、その実行主体は mackerel-agent になります。そう考えると、mackerel-agent.conf に設定を追記するのも頷けますね。このあたりを踏まえた上で、以降を読み進めてみてください。

メトリックプラグインを作ってみる

mackerel-agent.conf に設定されたメトリックプラグインを、mackerel-agent が起動するわけですが、メトリックプラグインに対して求められるインターフェース仕様としては、{metric name}\t{metric value}\t{epoch seconds} というフォーマットで標準出力されること( \t はタブ文字)だけが期待されています。それだけです!開発言語がGo言語である必要はない、という理由も、これでおわかりいただけたかと思います。

なので、例えば「そのホスト上に存在している全プロセス数を監視するためのメトリックプラグイン」をシェルスクリプトで作るとすると、たとえばこんな↓実装になると思います。

#!/bin/sh

metric_name="adventcallendar.test_metric.number"
metric=`ps aux | wc -l`
date=`date +%s`

echo  -e "${metric_name}\t${metric}\t${date}"

こうしてつくったシェルスクリプトファイルには、実行権限を設定するのを忘れずに。

$ chmod +x test.sh

デバッグとして、手動実行してみましょう。

$ ./test.sh
adventcallendar.test_metric.number  84 1543393478

先ほど解説したとおりのフォーマットになっていますね?

問題なさそうであれば、あとはこれを mackerel-agent に実行してもらうべく、設定の追加&エージェントの再起動を実施しましょう!

$ sudo sh << SCRIPT
> cat >>/etc/mackerel-agent/mackerel-agent.conf <<'EOF';
> [plugin.metrics.adventcallendar_test]
> command = "/home/user/test.sh"
> EOF
> SCRIPT
$ sudo systemctl restart mackerel-agent

で、しばらく待ってみるとー。

f:id:a-know:20181206161621p:plain

👏👏👏

チェックプラグインを作ってみる

ここまでのステップでメトリックプラグインを作ることのできたあなたにとって、チェックプラグインを作ってみることはチョロいです!

mackerel-agent が実行主体、という点はチェックプラグインにおいても変わりません。チェックプラグインに対して求められるのは、監視対象の状況に応じた終了コードを返すこと! 具体的には以下のようなかんじです。

終了ステータス アラートステータス
0 OK
1 WARNING
2 CRITICAL
0,1,2以外 UNKNOWN

https://mackerel.io/ja/docs/entry/custom-checks より。

これを踏まえて、 yes コマンドが稼働していたらアラート、というチェックプラグインスクリプトを書いてみましょう。

#!/bin/sh

count=`ps aux | grep yes | grep -v grep | wc -l`
if test $count -eq 0; then
  exit 0
else
  exit 2
fi

書き方はもちろんこの一通りじゃないにしても、まぁこんなもんでよいでしょう。

このスクリプトを、適当な場所に適当なファイル名で保存、実行権限の付与も忘れずにおこなったあと、設定ファイルへ設定の追記を実行。

$ sudo sh << SCRIPT
> cat >>/etc/mackerel-agent/mackerel-agent.conf <<'EOF';
> [plugin.checks.adventcallendar_test]
> command = "/home/user/check_test.sh"
> EOF
> SCRIPT
$ sudo systemctl restart mackerel-agent

さっきは plugin.metrics. だったのが plugin.checks. になっている点、見落としやすいポイントなのでお気をつけて。

Mackerel のWebコンソールで、対象ホストの画面を確認しておきましょう。

f:id:a-know:20181206161740p:plain

表示されてますね!

このように、チェック監視の場合、「正常に設定ファイルに記述がされていて」「 command で指定したコマンド文字列もちゃんと動いていれば」、自動的に monitors 欄にリストアップされます。(閾値監視ルールについては、ルール設定後、一度でも閾値判定がおこなわれたらリストアップされます。)

それでは動作確認として、サーバー内にておもむろに以下のコマンドを実行してみます。

$ yes >> /dev/null

これで、 yes コマンドが動き続けている状態をつくることができます。これでアラートが( exit 2 としたので、 CRITICAL アラートが)発生すればOK。1,2分待ちます。

f:id:a-know:20181206161828p:plain

おお!

f:id:a-know:20181206161903p:plain

ちゃんとアラート発報してますね! これで、誰かが間違って yes コマンドを暴発させたとしても、気がつくことができそうです! 安心!

まとめ

Mackerel アドベントカレンダー(全部CRE)の7日目の記事となるこの記事では、メトリックプラグイン・チェックプラグインの作成方法について解説しました。

プラグインスクリプトを自作することについて、この記事をきっかけに少しでも身近に感じてもらえたら、嬉しいです!