Advent Calendar最終回ってことで(実はもう2015年なんですがwww)、
Future of Blackbirdと題し今後どういう実装をしていくかとか、機能実装だけじゃなくてdebパッケージとかRPMとかどうするかみたいなそんな話もできればなーと思っております。
About pip
実は今各種pluginの中でpipに上げてるものあれば、上げてないものもあるのが現状でして、、、
その辺のintegrationをもうちょっとちゃんとやらないといけませんねと思っております。
最終的にはすべてのpluginをpip install blackbird-*で入れられるようにしとけば、もろもろ楽かなという気がしています。
About blackbird Documentation
今、一応公式のドキュメンテーションはここになっているんですが、
正直ちょっと頑張って書いたREADME.mdをGitHub Pagesで表示しただけのものになっています。
なのでDocumentationちゃんとしないとまずいなーって感じている次第でございます。
今回qiitaのAdvent Calendarで書かせていただ内容くらいをサマった感じのとかのDocumentationを書ければいんだがなーって感じです。
Documentationちゃんと書きます。
About blackbird
ではblackbird自体についていろいろです。
Using embedded Python
RPMパッケージもそうだし、debパッケージもそうなんですが、sys.pathの問題とかモジュールのimportとかもろもろの
conflictをさけるために、Pythonをembeddedにしちゃおうぜって話が出てまして...
(それどこのfluentdって言われそうですが)
実は下のようなちょっと経緯があったりしてましてですね、
- AWSのECS(EC2 Container Sercice)のagent(ecs-agent)はdockerで起動するようになってるんですが、ecs-agentはgolangで書かれておりまして、、、
- ビルド済みバイナリの配布だけでいいならgolangは監視エージェント向きなんじゃね??
- いや、さすがにgolangはやり過ぎ、既存のpluginどうする?? forkして取得するしかないなら、きついですな
- embedded Pythonにしてパッケージに同梱しちゃえば幸せじゃね??
- そうですね、それが落としどころですね
ってわけでembedded Pythonすることになりました。ちなみにembedded Pythonするバージョンは2.7.Xということにしようかなと思っています。
Implementing blackbird client mode
クライアントモードを実装したいですねってお話です。
embeddedにしちゃうと正直pluginの管理とかもpipのフルパスを指定するだけでembeddedなsite-packagesの下に入っちゃうんですが、
githubにある最新版が欲しいとかって話もあると思いますし、そもそもオレオレpluginがいるんだがみたいなときとかは、
必ずしもpipだけでいいってわけではないかと思ってます。
そこで例えば
blackbird-plugin install dynamodb
みたいなことをやればpip installして、
blackbird-plugin install Vagrants/blackbird-dynamodb
みたいなことをやればgit clone https://github.com/Vagrants/blackbird-dynamodb.gitするみたいな
そういう実装を目指そうと思ってます。そのほかにも
- 現在installされているpluginのversionと一覧を取得(
blackbird-plugin list) - 現在installされているpluginでどんな値を取得できるのかを一発で取ってくる_one shot mode_
- これは実際に値が取れるかどうかの確認にも使えますし、debuggingにも使えるかと
About logging
今はLTSV形式(っていってもlog_levelとtime, Process名, Thread名, messageだけなんですが)なんですが、
LTSV形式ってそもそもdomesticすぎじゃないってことで、
"%(time) [%(log_level)] %(threadName) %(contents)"
くらいの感じで、よりシンプルにいきましょうかって話をしてます。
あとは今ってファイルに直接吐いてるんですが、syslogにも吐けるようにしてあとはお好きな様にスタイルがとれればいいなと思うわけです。
Implementing Multiple Queue and Importing Multiple Sender Plugin
今の状態がすごく残念で申し訳ないんですが、ひとつのblackbirdプロセスに対してひとつのQueueしかもってないので、
一回送信しちゃったらそこで終わりなんですが、これはいくつか以下のような問題点がありまして(みなさんおわかりだとは思いますが)
- 複数のZabbix Serverにアイテムを送れない
- ひとつのsender系pluginがアイテムを取り出したらメッセージがなくなるので、Zabbix ServerとGrafanaに送りたいみたいなのできない
そこでなんとかしたいですねって話をしておりまして、複数Queueの実装して、その上でさらにどのQueueはどのsender plugin用のものなのかっていうroutingを
実装しないといけないですねっていう話をしていて未来のタスクに+1されたわけであります。
Tasks
ここからは新機能っていうよりは、どっちかっていうと僕達自身のTaskってかんじですが、細かいレベルのものも合わせますと、
- ConfigOBJの撤廃
- シグナルハンドリング
- --configtestの実装
- /usr/bin/blackbird --test or --configtest
- テスト！(Unit)テスト！(Integration)テスト！
こんな感じになっております。
Kicking out ConfigObj
ConfigObjっていうConfigParserの拡張版でValidationとかもやってくれるやつを使ってるんですが、
実はこれ、バージョンだけは新しいんですが2年くらいメンテされてないmoduleでして...
こいつを撤廃して自前でパーサとValidator書きましょうって話ですね。
Implementing --configtest option
よく、/etc/init.d/nginx configtestみたいなのやるじゃないですか、あれあると構成管理アプリケーションでも操作しやすいよねって
話でありまして、実装しようと思います。
Handling any signals (HUP, TERM, USR1)
そもそもの話は/etc/init.d/blackbird reloadしてえなって話をしていたんですが、そのためにはSIGHUP受け取ったら
Thread停止して、config停止して、みたいなことをやらないといけないわけですよ。
っで、他にもSIGTERM受け取ったら全部Queueを吐き出して送信し終わってから停止するみたいなそういうのも必要だなと思いまして。
よって、シグナルハンドリングやります。
Test! Test! Test!
テスト甘いところが結構あるのでテスト頑張ります。
概ねこんな感じですかね！Advent Calendarとか言ってて実は余裕で2015年ですが、みなさんだいたい明日から仕事始めですかね。
2014年もお仕事がんばりましょう。