Mackerel に自分の Mac を監視させてみた

先日、弊社のとあるサービスの production 監視に Mackerel が使われるようになった。

それまでは Amazon CloudWatch を利用したり、nagios だとか Zabbix だとかを構築して監視をしていたのだけど、一方でこれらの構築・設定はビミョーに大変だったりした。アプリケーションエンジニアだけではなかなか手を出しづらくなってしまっていて、インフラエンジニアさんへの相談も、

「どんな監視項目を設定したらいいかな？」「閾値はどれくらいにしたらいいだろう？」

といったものにはなかなかならず（できず）、

「このサーバの監視の設定、お願いしてもいいですか？ 普通の監視 で大丈夫なので」

みたいなものになりがちだった。「僕らのミッションは "監視サービスの構築" じゃない よね」、ということでの Mackerel 採用だった。

加えてつい先日、弊社インフラエンジニアから Mackerel をテーマにした社内勉強会が開催されて...、、まぁ、ざっくばらんに言うと、Mackerel イイなー、と惚れてしまった。ｗ　のと、ちょうど監視サービスをどれにしようかなというタイミングでもあったので、まずは手始めに Mackerel に慣れるという意味も込めて、自分の Mac を監視させてみることにした。今回のブログは、その記録である。

ちなみにこちらの記事を大いに参考にさせて頂きました。

sixeight.hatenablog.com

Mackerel の超おおざっぱな "イイところ"

（以下、非インフラエンジニアであるぼくのざっくりとした理解をもとにした記述なので、あしからず...）

Mackerel とそれ以外の監視サービス（それこそ nagios とか Zabbix とか）との一番の大きな違いで且つ大きなメリットとなっているのが、

• nagios とか Zabbix とか
  • SNMP のインストールとかもしとかなきゃいけない（たぶん多くの場合でそう）
  • 自分自身（nagios とか Zabbix とか）が、定期的に対象ホストにリソース情報を取得しにいく（pull型）
  • 監視対象ホストに予め穴を開けておく必要がある
• Mackerel
  • エージェントインストール方式
  • インストールされたエージェントは、そのホストのリソース情報を定期的に取得し、http で Mackerel に送信する（push型）
  • 外部に向けて http 出来さえすれば ok

というところだと思っていて、あ、これは取っ付き易いなと。もちろん、複数のホストを役割でまとめられるとか、Mackerel ダッシュボードのイケてる感とかもあるんだけども。

（2015/05/13 9:54 追記） すみません、Zabbix も Mackerel と同じくエージェントインストール方式だったみたいです＞＜；；

ZabbixとMackerelは両方Agentタイプだしできることに大きな差異はなくてZabbixの方が自由度とテンプレートの量に一日の長があるけどMackerelはUIが良いし監視サービスのインフラ自体を自分自身で面倒見なくて良いってメリットがある。

— そーだい＠初代ALF (@soudai1025) 2015, 5月 13

まずはプランについて

料金 - mackerel.io にもわかりやすく書かれているけど、

• Trial
• Free
• Standard

という3種類のプランがあって、今アカウントを作成すると、Standard と同レベルのサービス内容を1ヶ月無料で利用できる Trial プランを利用することができる。その期間を過ぎると Free プランになり、

• 監視可能対象ホスト数が 5台まで
• グラフの表示期間が直近 1日まで
• etc.

といった制限が加わるようになる。が、今回やろうとしている "自分の Mac の監視" のようなお試し用途にはそれでも十分なので、何も気にせずにアカウント登録をすることにする。

ちなみに Standard プランは ¥2,000 / 月。これを高いと見るか安いと見るかはあなた次第、ってところかなと。

Mackerel に Mac を監視させてみる

アカウント登録・オーガニゼーション作成

トップページ の右上ボタンから行える。

アカウントを作成するか（要メールアドレス。はてなID とは別物）、GitHub アカウントでもサインアップできる。

サインアップしたらイントロ的なスライドが表示されて、最後にオーガニゼーション（組織）作成画面が表示される。てっきり、最初のうちは個人アカウントだけ・必要なタイミングで organization の登録をするんだろうなと思っていたので、ここはちょっと意表を突かれた。

上で 複数のホストを役割でまとめられる と書いたけど、全ての役割（ロール）が属する最も大きな単位になるのが、このオーガニゼーションになるようだ。

（上記のようにイントロはどんどん進められるけど、メールアドレスの verify をするためのメールも飛んできているのでそっちもやっておく）

mackerel-agent のインストール

次にやるのは、監視対象ホストへの mackerel-agent のインストール。今回は Mac なので、下記のようにしてインストールする。なお、Mac へのインストールは 公式にはサポート外 のようなので、そこは自己責任で。

$ brew tap mackerelio/mackerel-agent
$ brew install mackerel-agent

インストール後、

You must append `apikey = {apikey}` configuration variable to /usr/local
/etc/mackerel-agent.conf
in order for mackerel-agent to work.

と表示されているとおり、/usr/local/etc/mackerel-agent.conf にAPI キーの設定をする必要がある。API キーは https://mackerel.io/orgs/{organization_name} で確認可能。

その後、同じくこれもインストール後に表示されているけど、

To have launchd start mackerel-agent at login:
    ln -sfv /usr/local/opt/mackerel-agent/*.plist ~/Library/LaunchAgents
Then to load mackerel-agent now:
    launchctl load ~/Library/LaunchAgents/homebrew.mxcl.mackerel-agent.plist
Or, if you don't want/need launchctl, you can just run:
    mackerel-agent -conf /usr/local/etc/mackerel-agent.conf

mackerel-agent には基本的に自動で起動して欲しいので、このメッセージに従って launchd に登録。

$ ln -sfv /usr/local/opt/mackerel-agent/*.plist ~/Library/LaunchAgents
$ launchctl load ~/Library/LaunchAgents/homebrew.mxcl.mackerel-agent.plist

そして起動。

$ launchctl start homebrew.mxcl.mackerel-agent

ここまでやって Mackerel のダッシュボードを見てみると、"新規ホスト" のところに Mac が追加されているのがわかる。

次にこの "ロールを設定" ボタンを押してロールの設定をしてみる。

ロールの設定

上記ボタンを押すと、↓のようなダイアログが出てくるので、"新規ロールを作成" でまずはロールを作ってみる。

と、思ったら、まずは "サービス" を作成しておかなければならないらしい。

TIPS: サービスとは、オーガニゼーションにおいて複数のホストが協調して所属する概念です。
ある組織内でホスト群を管理・監視する、一番大きな単位です。

TIPS: ロールとは、「app」「db」「proxy」など、あるサービスに所属するホストを機能によって
さらに分類する概念です。
ホストの状況はロール毎にまとめて可視化されます。

なるほど。例えるなら

• サービス：はてなブログ
  • ロール1：Webサーバ
  • ロール2：DBサーバ

みたいな感じか。。

今回は開発機である Mac の監視をしてみたいので色々微妙だけど、

• サービス：a-know
  • ロール1：develop

としてみることにする。

サービスとロールの登録が完了すると、↓のようなページが表示されるので、develop ロールに Mac をホストとして登録してみよう。

うん、さっき登録したサービス・ロールが選択できるようになってる。

ダッシュボードの確認

...おｋ！！

アラートの設定

このまま試しに、"閾値を設定して、それを超えたらアラートを投げる" 設定をしてみる。

"Alerts" の "設定" をクリックして...

右上の "監視ルールを追加" 。

"使用しているディスクサイズが全体の 80% 以上になったら warning "、"90% 以上になったら critical " で設定してみる。

...できた。とても直感的に設定できる。ただ、Amazon CloudWatch とかでは可能な "最大値を監視" とかは、Mackerel ではまだできないっぽい？

ためしに warning の閾値を極端に下げてみて、アラートの様子を見てみた。

in progress 、つまり今もなお warning な状況が続いている、ということか。

このスクショだとちょっとわかりにくいけど、タイムラインのような感じの表示になってる。

...とりあえず今回はこれくらいで終わり。

所感

らくちん！

やっぱ簡単、楽でいい。今回は Mac だったので homebrew で入れたけど、本番で使うとき（ Chef でセットアップする）のことを考えても、

• mackerel の yum repo を登録する recipe
• package 'mackerel-agent' な recipe
• mackerel-agent.conf を作る recipe（API キーの編集を含む）

を用意して、対象のサーバに対して cook するだけでいいし。

カッコイイ！

ダッシュボードとかの UI がカッコ良いというか気持ちいいというか。

いよっ、グラフ、カッコイイね！

この動的なグラフ、これはそのまま埋め込めるらしくて、それもまたイカしてるなと思った。

Free プランでも十分なケースも多い？

あと、上述の通り Trial プランは一ヶ月までで、それを過ぎるとこのカッコ良いグラフも直近1日間のものしか見れなくなる（Free プランになる）んだけど、でもアラートについては特に変わらず行える？ようなので、お遊び用途なのでこれで十分、というケースも多そうだ。

プラグインも書ける！

それとこれは社内勉強会で聞きかじった内容なんだけど、プラグインが書けるし、それによって、エージェントのインストールができない RDS や ELB の監視もできるようになる（要 fluentd ？）みたいなので、あぁそれは良いなと思った次第。"基本 nagios で、RDS に関してだけは Amazon CloudWatch で" ...みたいな状況になりがちだったけど、これが Mackerel に一本化できるとしたら、確かにウレシイなと思った。

伊藤食品 美味しい鯖味噌煮 190g×4缶