リノシスでエンジニアしています高科です。
リノシスでは元々サーバー監視はAWSのCloudWatchでゴリゴリとやっていたのですが、 サービスが増え、さすがにカスタムメトリクスをcronで送る、という設定を続けるのはきつくなってきました。 サービス落ちてたら自動で再起動したい、という新しい要件にも対応したいので、そこを作り込むのはしんどい、、、
そこで、専用の監視SaaSを導入したい！と提案したところ、社長から即答でOKいただいたので、早速社内エンジニアと比較検討開始！ 最終的にNewRelicとMackerelかな〜となりましたが、すでに社内の別チームで試験的に使われていたMackerelでやっていく事になりました。 （個人的にも国産SaaSを推していきたいな、という隠れた意図があったのは秘密です。）
ありふれた導入体験記ですが、地味にハマったポイントがあったので、ブログにします。
サーバーへmackerel-agent導入
Mackerelの導入は簡単。公式ドキュメントはこちらです。
注意点はAmazon LinuxのOSバージョンによって方法が変わってくるとこですね。 あと地味にステージング環境だと、インストールでメモリが足りなくて、失敗しました。 swap領域を設定して、回避。（具体的な設定方法はこちら）
リノシス では基本Rails+unicorn+nginxを使ってるので、unicornのメトリクスをチェック。専用のプラグインをインストールします。
yum install -y mackerel-agent-plugins yum install -y mackerel-check-plugins
設定ファイル編集
configファイルを編集します
vim /etc/mackerel-agent/mackerel-agent.conf
以下が設定です。 unicornのプロセス数をチェックして、2以下だった場合はアラートを出します。 ここで地味にハマったのが、ユーザーを指定してもbash_profileを読み込まないで実行されるようで、bundleコマンドがnot foundになっていました。 あと言語設定も必要だったようです。 もっと上手い方法あるのでしょうか？
($USER, $HOME_DIR, $APP_DIRは適宜変換してください)
[plugin.metrics.unicorn]
command = "/usr/bin/mackerel-plugin-unicorn -pidfile=/var/www/cm-dev/shared/tmp/pids/unicorn.pid"
[plugin.checks.check_unicorn]
command = ["check-procs", "--user", "$USER", "--pattern", "unicorn", "--warning-under", "2", "--critical-under", "1"]
action = { command = "bash -c '[ \"$MACKEREL_STATUS\" != \"OK\" ]' && export LC_ALL=en_US.utf-8 && source $HOME_DIR/.bash_profile && source $HOME_DIR/.bashrc && cd $APP_DIR && bundle exec unicorn_rails -c config/unicorn.rb -E production -D", user = "$USER" }
delayed_jobも使ってるので、そちらもチェックして、再起動処理を入れます。
[plugin.checks.delayed_job]
command = ["check-procs", "--user", "$USER", "--pattern", "delayed_job", "--critical-under", "1"]
action = { command = "bash -c '[ \"$MACKEREL_STATUS\" != \"OK\" ]' && export LC_ALL=en_US.utf-8 && source $HOME_DIR/.bash_profile && source $HOME_DIR/.bashrc && cd $APP_DIR && RAILS_ENV=production bin/delayed_job restart", user = "$USER" }
そしてDISK監視はこれ
[plugin.checks.disk] command = ["check-disk", "--path", "/", "--warning", "10%", "--critical", "5%"]
ちなみにうまく動かない時はDEBUGログ出力をONにすればデバッグできます。 verbose = true とすることで、DEBUGログの出力を有効にできます。
（最初は勝手がわからず、DEBUGログがある事すらわからず無為に時間が過ぎていきました。。。）
実際に運用してみて
個別の環境によって違うと思いますが、リノシスのサーバーはこれで無事監視できました。 あとはMackerelのWebコンソールでSlackに通知するように設定したら運用開始できました。
個人的には外形監視（https,httpでアクセスして動作しているかの監視）をとても楽に導入できたのがとても良かったです。 慣れたら１分もかからずに外形監視を導入できます。
リノシスでは提供サービスがすごいスピードで増えてるので、監視環境を整えるのも大変でしたが、Mackerel入れてからはそんなに苦ではないです。
１台当たりの価格なので、ステージングなども監視し始めると、EC2の料金よりも高いのでは？となってしまうあたりがちょっと厳しいですが、安定運用のためには仕方ないのかな、という感じもします。
ベンチャーで運用監視だけするエンジニアを抱える余裕がない会社（そんな余裕ある会社、なかなか無いと思いますが）には必須のツールだと思いました。
宣伝
Renosysではデータ分析基盤からアプリ運用までいろんなインフラ構築機会があります。 興味ある方はこちらまで。
