社内のQiita:Teamに書いた記事の転載です.

Mackerelを事業の中で使っていて気付いた事とかをまとめていますが, 後述の通り, 基本的にMackerelのヘルプに書いてある情報がほとんどです. その辺りはご了承下さい.

mackerel-agentと設定ファイル

Mackerelは, 監視対象とする各ホストに｢mackerel-agent｣を設置することで, 各ホストのメトリックの取得と監視を実現しています. このエージェントの設定は, Mackerelのエージェントに関するヘルプにある通り, デフォルトでは/etc/mackerel-agent/mackerel-agent.confを参照します.

この辺りの設定のコツというか, Tipsをいくつか紹介します. といっても, ほとんどはヘルプを見れば書いてあることですが...

サービス/ロールの初期設定

ホスト上でmackerel-agentを動かすと, API Keyに紐付いたアカウントに自動的に登録され, WebサービスとしてのMackerel上から確認することができます. このとき, 各ホストは｢サービス｣と｢ロール｣という単位で管理することが出来るのですが, これを手動で設定するのは少し手間です.

また, 手動で設定するような運用にしていると, ｢登録を忘れてしまう｣という事態も起こりうると思います. Mackerelの場合は適切にサービスやロールを設定しておけば, こんな感じで複数のホストのリソースをサービス/ロール単位でまとめて見ることが出来てとても便利なので, サービスやロールは適切に設定したいものです.

f:id:papix:20150727140724p:plain

サービスやロールの設定漏れを防ぐ方法の1つが, mackerel-agent.confで予め設定しておく方法で,

roles = [ "My-Service:app", "Another-Service:db" ]

例えばこのように書いておけば, この設定ファイルがあるホストは｢My-Service｣というサービスの｢app｣というロールと, ｢Another-Service｣というサービスの｢db｣というロールを持っているホストとしてMackerelに登録されます.

AnsibleやPackerでプロビジョニングをする際に, mackerel-agent.confも自動的に生成するようにしておけば, サービスやロールの設定漏れを防ぐことが出来て良いと思います.

設定のinclude

Mackerelの設定ファイルには, サービス内で共通な設定の他に, ロールごとに異なる設定があります. まさに｢ロール｣の設定がそれで, 例えばAPI Keyはどのロールでも同じものを使いますが, アプリケーションサーバではロールをMy-Service:appにして, データベースサーバではロールをMy-Service:dbにしてあげるなどの工夫が必要です.

この際に便利なのが設定のinclude機能で, 例えばmackerel-agent.confに

include = "/etc/mackerel-agent/conf.d/role.conf"

のように書いておけば, /etc/mackerel-agent/conf.d/role.confに記載された設定をincludeすることができます. なおこの際, include元とincludeしたファイルの双方で設定されるパラメータがあった場合, 基本的にincludeしたファイル側にある内容で上書きされていきます. また, 複数の設定ファイルをincludeできる場合, その読み込み順序は不定という仕様になっています.

Reactioの場合, API Keyなど全サービス共通の設定は/etc/mackerel-agent/mackerel-agent.confに記載し, ホストやロールごとに異なる設定は/etc/mackerel-agent/conf.d/role.confに記載して, これをincludeするようにしています.

Ansibleのtemplateなどで頑張る場合, テンプレートでの変数の展開などを利用して, /etc/mackerel-agent/mackerel-agent.confに全て書いてあげるやり方でも十分いけますが, ReactioのようにPackerで設定ファイルを生成する場合, こちらの方が都合が良かったです.

ホストの起動/終了時のステータス変更

ホスト(正確にはmackerel-agent)が起動したタイミングと, 終了したタイミングでmackerel-agentが動いているホストのステータスを変更することができます.

[host_status]
on_start = "working"
on_stop  = "poweroff"

例えば, mackerel-agent.confに上記のように記載しておけば,

ホスト起動時: working
ホスト終了時: poweroff

にステータスを変更することが出来ます. 設定できるステータスはworking, standby, maintenance, poweroffで, このhost_statusの設定によってホスト終了時に自動的に退役(retire)することは出来ません.

~~Mackerelでは, ホストをretireさせないと, ステータスに関わらず課金対象になってしまいます.~~ Mackerelでは, ｢アクティブなホスト(mackerel-agentが動いているホスト)｣が課金対象になります. そのため, ホストを課金対象から外す方法としては, ホストを退役させる以外にも, mackerel-agentを停止するという方法もあるようです(コメント欄で id:songmu さんにご指摘頂きました. ありがとうございます!).

ホスト終了時にホストをMackerelから退役させたい場合, 後述の｢外部からのMackerel操作｣で紹介するAPIを利用して, ホスト終了時に自分自身を退役させるようにAPIを叩いてやる必要があります.

外部からのMackerel操作

Mackerelを操作する場合, APIを利用するのが便利です. シェルスクリプトならwgetやcurlで良いですし, Perlから叩きたいのであればWebService::Mackerelを利用することができます.

ちなみにWebService::Mackerelのco-maint(いわゆる副管理者的な権限)を頂いているので, 要望等あればお寄せ下さい.

なお, ｢ホストの起動/終了時のステータス変更｣で紹介した｢ホストの退役｣ですが, シェルスクリプトから実行する場合次のようなコマンドで実現できます.

host_id=$(cat /var/lib/mackerel-agent/id)
curl -H "X-Api-Key: YOUR_ORGANIZATION_API_KEY" \
     -H "Content-Type: application/json" \
     -X POST \
     -d '{}' \
     https://mackerel.io/api/v0/hosts/$host_id/retire

Mackerelでは, ホストごとにIDを割り振って管理しているのですが, そのIDは/var/lib/mackerel-agent/idに格納されています. catでこれを読み取って, あとはcurlを利用してAPIを叩いているだけです.

MackerelのWebhookを受ける

CPANizeされていませんが, songmuさんが｢Mackerel::Webhook::Receiver｣というモジュールを開発されています. これを利用すれば, MackerelからのWebhookを受け取って, そこから任意の処理を実行する, という機能を実現することができます.

利用例としては, (自社サービスとの連携ですが...)このモジュールとWebService::Reactioを組み合わせて, ｢Mackerelのアラートが発火したら, Reactioに通知が飛ぶ｣といった仕組みを実現することが出来ます.

まとめ

このテキストは, 社内のいくつかの事業がMackerelの導入を検討しているようだったので, 導入時のアドバイスとして書いたテキストだったりします. 今回の内容はTips寄りですが, 実際にMackerelを社内で/事業でどのように使っているのか? という所についても, いずれ紹介していきたいと思っています.