(cache) Mackerel で heroku の監視ができるって知ってた？！

僕は知らなかった！だって PaaS だから、エージェントのインストールができないじゃん！

そんな思い込みがあったもんだから、Mackerel のヘルプを見ていて Heroku を Mackerel で監視するというページがあって、思わず二度見してしまった...。

えーでもエージェントのインストールどうするの、あーアドオンかな、とか思いながら読んでみたら、ふつーにエージェントをインストールしてるっぽい手順だった。ので、ちょっと実際に試してみながら残したメモを、このブログでも晒しておく。とはいえ、基本的にはヘルプに書いてある通りなんだけど。

対象の heroku アプリ

幸い？なことに、僕には（鳴かず飛ばずの）Rails heroku アプリ・mikanz があるので、今回はそいつを監視してみようと思う。

Mikanz -ミカンズ- | みんなの未完成品が集まるばしょ

Mackerel への下準備

（Mackerel（鯖）への下準備って、なんか料理っぽいな...）現在 mikanz とは関係ないホストの監視を行っているので、オーガニゼーションから分けることにする。

画面左上の現在のオーガニゼーションをクリックすると切り替えメニューと一緒に「作成」リンクがあるので、

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

これを押し、新規オーガニゼーション作成画面でオーガニゼーション名を入力。

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

すると、プラン選択画面が。おお、あたらしいオーガニゼーションでは改めて無料トライアル期間がもらえるんですね！いやぁ、なんかスミマセン。

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

これで何事も無く下準備は完了。

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

あ、オーガニゼーションのページ（ mikanz オーガニゼーションだと https://mackerel.io/orgs/mikanz ）で API key を確認しておくのを忘れずに。

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

API key を heroku の環境変数に登録

環境変数の設定は CLI でもできるけど、今回は heroku のコンソールから。

Settings の Config Variables で Mackerel の API key を登録する。key 名称は「MACKEREL_API_KEY」とでもしておく。

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

start.sh の作成

ここからは基本的にヘルプに沿った作業になる。まずは、Mackerel をセットアップし Rails アプリケーションを起動するためのスクリプトとなる start.sh を作成する。作る場所は、Rails のアプリケーションルート。

以下に載せているのは、公式のヘルプにあるスクリプト例を元に、今回の僕の用途むけに一部書き換えたもの。利用する場合は適宜読み替えて頂ければと。

ただ一点だけ、2016/06/19 現在でヘルプにある上記スクリプトに誤りがあって、それは mackerel-agent-latest.tar.gz を展開してできるディレクトリが mackerel-agent ではなくて mackerel-agent_linux_386 になっているという点。なので、そこは置換する必要がある（公式にもフィードバック済み）。↓のスクリプトは、その点も直したもの。

rails_root=`pwd`
# install mackerel-agent
cd /app/ && curl -O http://file.mackerel.io/agent/tgz/mackerel-agent-latest.tar.gz && tar xvfz mackerel-agent-latest.tar.gz
# create mackerel-agent conf file
sh << SCRIPT
cat >/app/mackerel-agent_linux_386/mackerel-agent.conf <<'EOF';
pidfile = "/app/mackerel-agent_linux_386/mackerel-agent.pid"
root = "/app/mackerel-agent_linux_386"
apikey = "${MACKEREL_API_KEY}"
roles = [ "mikanz:web" ]
[host_status]
on_start = "working"
EOF
SCRIPT
# auto-retirement
trap '/app/mackerel-agent_linux_386/mackerel-agent retire -conf /app/mackerel-agent_linux_386/mackerel-agent.conf -force' TERM
/app/mackerel-agent_linux_386/mackerel-agent -conf /app/mackerel-agent_linux_386/mackerel-agent.conf -v &
# unicorn start
cd ${rails_root}
bundle exec unicorn -p $PORT -c ./config/unicorn_production.rb

このスクリプト内で、さきほど heroku 側に登録した API key を読みだしている。mikanz はアプリケーションサーバとして unicorn を使うようにしていたので、スクリプトの最後でその起動をしてやってる。

start.sh 、としているけど、ファイル名はなんでもいいはず（このあとでてくる Procfile 内の記述と一致していれば）。ただし、このスクリプトの実行権限は与えておいてやる必要がある。僕は忘れてた。

Mackerel にとっての監視対象となる「ホスト」は、Dyno になる。Dyno は自動で起動したりシャットダウンしたりするので、Mackerel 側もオートスケーリングに準じた設定が必要になっている。それが、conf 内の on_start = "working" の部分だったり、 auto-retirement （自動退役）とコメントしているところ。 Mackerel のオートスケーリング設定に関しては Auto Scaling環境で使う - Mackerel ヘルプが詳しい。

（Heroku はそんなに詳しくはないんだけど）Heroku 上で動作するコンテナ的なインスタンス・Dyno が新しく起動するたびにこのスクリプトが動くことになる。つまり、Dyno が立ち上がるたびに mackerel-agent をゼロからセットアップするような動きになる（はず）。これによって、多少は Dyno が起動するスピードが遅くなることはあるかもしれない。

それと、Mackerel は 1ホストあたりの課金体系なんだけど、それはきっと Dyno においても適応されるはず。なので、Dyno 数＝ Mackerel ホスト数、となると思うので、Heroku で比較的ガチにアプリケーションを構築・運用している場合は、注意が必要かもしれない。

start.sh の呼び出しを Procfile に追加

すでに heroku で動かしているのであれば、何らかが記述された Procfile があるんじゃなかろうか。

ぼくは下記のような内容になっていたので、

web: bundle exec unicorn -p $PORT -c ./config/unicorn_production.rb

これを、下記のように書き換えた。

web: ./start.sh

これだけ。

デプロイ（ `git push heroku master` ）

以上の変更をコミットし、heroku にデプロイ（push）する。

$ git push heroku master
（中略）
remote: -----> Launching...
remote:        Released v28
remote:        https://mikanz-prod.herokuapp.com/ deployed to Heroku
remote: 
remote: Verifying deploy... done.
To git@heroku.com:mikanz-prod.git
   782013c..e5bcca0  master -> master

Mackerel を確認

で、おもむろに Mackerel を見に行って見るとー。

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

:tada:

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

イイねぇ！！

今は無料トライアル期間だからフル機能使えるけど、僕の mikanz のような細々と動かしてるようなアプリケーションであれば、トライアル期間が終わって無料プランになってもそのまま使い続けられる（十分有用）なんじゃないかなぁ。「Mackerel 、触ってみたいんだけどエージェントをインストールできるようなサーバーがないよー！」って人にも、オススメかもしれない！