えいのうにっき

誤字脱字・記述の誤りなどはこちら https://github.com/a-know/blog.a-know.me へお願いします

mackerel-container-agent の写経が高じて独自エージェントを作ってしまった

先週くらいから、何の気なしに mackerel-container-agentソースコードリーディングをしていたら、

github.com

「ここがこう書いてあるってことは、ここをああしたらああなる?」みたいな気持ちになり、写経をしはじめ、そして気がついたら、オリジナリティのある動作をする非公式エージェントを作ってしまっていたのでこのブログを書いています。名付けて、 mackerel-remora (マカレル-レモラ)

github.com

remora とは、ナガコバン属に属するコバンザメ......のようです?

ja.wikipedia.org

この remora 、いつかどこかで使ってみたいと個人的に思っていた名前なので、ここで使えてよかった。

mackerel-remora is 何?

mackerel-remora は、Mackerel に対して(APIキーに対応する Mackerel オーガニゼーションに対して)サービスメトリックを投稿するためだけのエージェントです。少なくとも、今のところはこれだけ。

How to use

mackerel-remora の docker イメージを docker hub に登録しました。

aknow/mackerel-remora

例えば 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>
  • <apikey>
    • 投稿先となる Mackerel オーガニゼーションで発行しておいたAPIキー。Write権限が必要。
  • <root>
    • mackerel-remora のルートディレクトリ。通常は指定不要。
  • <servicename>
    • 投稿先のサービス名。あらかじめ Mackerel サイドでサービスを作成しておく必要がある。
  • <settingname>
    • サービスメトリックを投稿するためのプラグイン設定名称。使われることはないが他と重複があってはならない。
  • <command>
    • サービスメトリックプラグインとして期待する標準出力をおこなうためのコマンド。
    • このコマンドの実行結果として、 {metric name}\t{metric value}\t{epoch seconds} というフォーマットでの標準出力を期待している。
  • <user>
    • command の実行ユーザー。
  • <envkey>
  • <envvalue>

例に戻って、ここでは 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 して、しばらく待ってみると。

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

はい。できました!

先日、サービスメトリックに対する途切れ監視もリリースされたので、これと組み合わせることで remora の死活監視とみなすこともできるかなと思います。便利。

mackerel.io

作った動機

「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言語による並行処理 とかを読むといいだろうか。

Go言語による並行処理

Go言語による並行処理

今後の展望

サービスメトリックと同じような位置づけに、ロールメタデータ・サービスメタデータがあると思っていて。

mackerel.io

mackerel.io

このあたりについても、そのうちサポートしたいなーと思ってます。