こんにちは。Mackerel歴がブランクあり2年弱くらいの@karupaneruraです。
Mackerelのプラグインとエージェントのリポジトリのpull-reqとissueを眺めるのが趣味です。(他にも気になっているリポジトリはだいたいWatchして眺めています。)
そういうわけで、MackerelのAgentまわりのコードはある程度は読んでいるので実装で使われているライブラリの紹介をしてみようかと思っていたのですが、どちらかというとMackerelの導入/運用に関する話のほうが喜ばれるかなと思ったのでそっちの話を書いてみます。
なお、この情報はあくまでも利用者の立場のひとによって書かれたものですので最新情報に追従していないものもあるかもしれません。基本的には公式情報を参照してください。
導入検証用インスタンスを立てる
いきなり本番にぶっこむ人はまず居ないとおもいますが、かといってまっさら過ぎる環境に入れても最低限のメトリクス/チェックプラグインしか設定できないでしょう。
最低でもアプリケーションやミドルウェアをデプロイできる程度にはセットアップしたインスタンスを立てておくと検証がしやすいのでおすすめです。
できれば、アプリケーションやミドルウェアをデプロイしてある程度動くようなクラスタを作っておけるとベストでしょう。
service/roleの決定方針を決める
Mackerelのservice/roleはインスタンスがどのサービスにおいてどの役割を持つのかを管理するためのものになります。
この分類はMackerelのWeb UI上でインスタンスをまとめるために利用できるほか、メトリクス監視設定の対象を絞るためにも利用できます。たとえば、バッチ処理用のインスタンスはCPU利用率監視の対象から外す。といった使い方ができます。
そのため、service/roleは基本的にはインスタンスが実際どのような役割で利用されるものなのかを本質的に示すものになります。
余談ですが、基本的にはservice/roleが変わる場合はゼロから構築しなおす形にするのがおすすめです。
余計なファイルやデーモンが残ってしまうと誤動作やオペレーションミスを誘発する要因になり、かつ不要なものだからといって消すことは簡単ではないからです。動くものをつくることは簡単ですが、動くものを壊さずに不要なものを消すのは難しいことは感覚的に分かりやすいかと思います。ジェンガは積むより抜くほうが難しいのです。
EC2やGCEなどのIaaSを利用している場合はAMIやDisk Imageを作っておくことでゼロからの構築を簡略化できます。（オンプレの場合はこの点は工夫が必要かと思いますが趣旨から大きくハズレてしまうので今回は省きます。）
構築後にservice/roleが変わらない前提が確立できれば、あとはChefやAnsibleなどの構成管理ツールやpackerなどでエージェントの設定ファイルを管理できるようになります。
オーガニゼーションをつくる
なにはなくともオーガニゼーションがないと可視化されたグラフが見れません。
ここにあるとおりですね:
https://mackerel.io/ja/docs/entry/getting-started
とっても簡単です！
エージェントをインストールする
Mackerelを使うためには監視対象のマシンにエージェントをインストールする必要があります。
ここにあるとおりですね:
https://mackerel.io/ja/docs/entry/howto/install-agent
とっても簡単です！
エージェントを設定する
デフォルトでは /etc/mackerel-agent/mackerel-agent.conf が設定ファイルになります。
ドキュメントはこちら: https://mackerel.io/ja/docs/entry/spec/agent
現時点ではエージェントの(rpm/deb/Windows Installerによる)インストールでこのサンプルファイルがコピーされることになります:
https://github.com/mackerelio/mackerel-agent/blob/master/mackerel-agent.sample.conf
基本的にはこのサンプルの設定のコメントアウトを外して設定を入れて動かしてみることになるかとおもいます。
プラグインは単なる外部コマンド実行なので単体で動作確認が可能です。プラグインは特に指定しなければagentと同じユーザー(インストール時のデフォルトはroot)で実行されるので、同じユーザーで動作確認をしましょう。
また、プラグインによってはユーザー名などの設定が必要なものもありますので注意しましょう。
プラグインは公式ヘルプにもありますが、僕はリポジトリを見て探すほうが好きです:
https://github.com/mackerelio/mackerel-agent-plugins
https://github.com/mackerelio/go-check-plugins
また、3rd Partyプラグインのインストーラーもmkrコマンドに搭載されているのでこれも利用することができそうです:
https://mackerel.io/ja/docs/entry/advanced/install-plugin-by-mkr
名前から、「おっ！これは？」と思うものがあればそれについて詳しく調べてみましょう。
設定ファイルの管理方針を決める
基本的には先述の通り構成管理ツールでミドルウェアなどのインストールと一緒に構築することが理想ではないでしょうか。
Chefのrecipeで設定するなど、いろいろやり方がありそうです:
https://mackerel.io/ja/docs/entry/howto/chef
いろいろ流儀はあるかと思いますが、ぼくは設定ファイルのインクルード機能を利用して監視対象となるミドルウェアやアプリケーション毎にファイルを分けるのが好みです。
たとえば、nginxを監視する場合は /etc/mackerel-agent/conf.d/nginx.conf にnginx向けの基本的なプラグイン設定を記述します。
ただ、たとえば環境や案件によってミドルウェアが違うポートで複数台立っていたりするなど、これがマッチしない場合もあるかと思います。
どういう単位で整理するとスッキリ管理できるかは運用担当者の腕の見せ所にひとつだと思います。がんばりましょう！
メトリクス監視と通知チャンネルを設定する
メトリクスが正常に取得できるようになったらそれらにも監視を設定しましょう。
できれば設定値の妥当性を検証するために負荷試験も兼ねてそれを行えるとベストでしょう。
通知チャンネルは必ず通知グループを経由するポリシーでつくるとすっきりします。
たとえばチーム毎、サービスxアラートレベル毎に通知グループを設定して、サービスxアラートレベルの通知グループから対応チームの通知グループに飛ばし、対応チーム毎に具体的な通知チャンネルはある程度自由に設定する。などなど。といった使い方がおすすめです。
ブラッシュアップ
あとは実運用に載せて設定をブラッシュしていくだけです。
Mackerel Users Group(http://mackerel-ug.hatenablog.com/ )のSlackで相談してみるのも良いとおもいます。
この先は君の目で確かめてみてくれッ☆
明日は @nashiox さんです！