先週くらいから、何の気なしに mackerel-container-agent のソースコードリーディングをしていたら、
「ここがこう書いてあるってことは、ここをああしたらああなる？」みたいな気持ちになり、写経をしはじめ、そして気がついたら、オリジナリティのある動作をする非公式エージェントを作ってしまっていたのでこのブログを書いています。名付けて、 mackerel-remora （マカレル-レモラ）。
remora とは、ナガコバン属に属するコバンザメ......のようです？
この remora 、いつかどこかで使ってみたいと個人的に思っていた名前なので、ここで使えてよかった。
「コバンザメ」的な名前を冠したマカレル関連のソフトウェアをいつか書きたいという野望を持っている、あるのは名前と野望だけでアイデアはノー！
— a-know | Daisuke Inoue (@a_know) 2019年2月6日
mackerel-remora is 何？
mackerel-remora は、Mackerel に対して（APIキーに対応する Mackerel オーガニゼーションに対して）サービスメトリックを投稿するためだけのエージェントです。少なくとも、今のところはこれだけ。
How to use
mackerel-remora の docker イメージを docker hub に登録しました。
例えば docker-compose を使う場合、以下のような YAML を書きます。
remora:
image: aknow/mackerel-remora:latest
volumes:
- .:/app
environment:
MACKEREL_REMORA_CONFIG: /app/_example/sample.yml
sample.yml というのは、mackerel-remora 用の config になります。その中身は↓なかんじ。
apikey: xxxxx
plugin:
servicemetrics:
demo:
sample:
command: sh /app/_example/demo.sh
この YAML の完全な形？は以下。
apibase: <apibase>
apikey: <apikey>
root: <rootdir>
plugin:
servicemetrics:
<servicename>:
<settingname>:
command: <command>
user: <user>
env:
<envkey>: <envvalue>
<apibase>- リクエスト先APIのドメインを指定できる。通常は指定不要。
<apikey>- 投稿先となる Mackerel オーガニゼーションで発行しておいたAPIキー。Write権限が必要。
<root>- mackerel-remora のルートディレクトリ。通常は指定不要。
<servicename>- 投稿先のサービス名。あらかじめ Mackerel サイドでサービスを作成しておく必要がある。
<settingname>- サービスメトリックを投稿するためのプラグイン設定名称。使われることはないが他と重複があってはならない。
<command>- サービスメトリックプラグインとして期待する標準出力をおこなうためのコマンド。
- このコマンドの実行結果として、
{metric name}\t{metric value}\t{epoch seconds}というフォーマットでの標準出力を期待している。
<user>commandの実行ユーザー。
<envkey>commandに渡す環境変数の変数名。
<envvalue>commandに渡す環境変数の値。
例に戻って、ここでは sh /app/_example/demo.sh としているが、このシェルスクリプトの中身は、例えばこんな↓かんじのもの。
#!/bin/sh metric_name="demo.test_metric.number" # metric number to post metric=6 date=`date +%s` echo "${metric_name}\t${metric}\t${date}"
このスクリプトを使った場合、延々と 6 がサービスメトリックとして投稿されるだけなので、すごくつまらないけれど...。。
この状態で docker-compose up -d remora して、しばらく待ってみると。
はい。できました！
先日、サービスメトリックに対する途切れ監視もリリースされたので、これと組み合わせることで remora の死活監視とみなすこともできるかなと思います。便利。
作った動機
「Mackerel にサービスメトリックを投稿するための、いいかんじの仕組みがあればいいなぁ」とは、前々から思ってはいました。mackerel-agentにそういう機能を、みたいなこともなくはないのかなと思うのだけど、個人的に、
- mackerel-agent は監視対象となるサーバーにインストールするもの
- mackerel-agent は、host ID と 1対1 で動く前提
というところが、サービス全体に関する責務を持たせることにあまりしっくり来ていなくて。そういったことが、今回 mackerel-container-agent の写経をしていたらアイデアとして火がついた、というかんじ。
mackerel-agent と違ってホストと紐付かない（host ID を前提としていない）ので、ECSとかfargateなどのコンテナ用プラットフォームでも動かしやすいんじゃないかなと思ってます。試してはないですが。。
作りながら思ったこと
元となる mackerel-conatiner-agent は、すごいしゅっと作られているなぁということがわかって。作ったうちの（はてなの）エンジニアさんたちスゲー、ってなりました。
あと、細かくパッケージを分けていただいているおかげで、再利用性が高かった（最初はコピペでやってたところも、個別パッケージのimportでまかなえたところがあったりした）。
goroutine や context の使い方が見たことのない使い方で使われていて、正直まだよくわかっていないままなので、ここらへんは一度しっかり勉強しなきゃだめだなと思った。Go言語による並行処理 とかを読むといいだろうか。
- 作者:Katherine Cox-Buday
- 発売日: 2018/10/26
- メディア: 単行本（ソフトカバー）
今後の展望
サービスメトリックと同じような位置づけに、ロールメタデータ・サービスメタデータがあると思っていて。
このあたりについても、そのうちサポートしたいなーと思ってます。