AWS Lambda(Python)からCollectdにメトリクス値を送るスクリプト＋要望と感想

Lambda Pythonの最後三つ目の記事で、今度はCollectdに値を送信する内容になります。最後にちょろっと要望／感想的なことを書いてます。

普段は管理サーバーにて、CollectdのExecスクリプトでAWSのAPIを叩いてPUTVALを送っているのですが、これもサーバーレスにできるなと。ただ、見て分かる通り、Zabbixよりだいぶ面倒くさかったです。

使い方

Collectdプロトコルについてはこの辺で。

Binary protocol – collectd Wiki

Python collectd package v1.0, collectd module source code :: PyDoc.net

Lambdaに以下の様な構成でzipをアップロードします。
__init__.py は空ファイルです。

.
├── GraphMetricSender.py
└── modules
    ├── CollectdClient.py
    └── __init__.py

├── GraphMetricSender.py

└── modules

├── CollectdClient.py

└── __init__.py

GraphMetricSender.py は例えばこんな感じ。

from modules.CollectdClient import CollectdClient

def lambda_handler(event, context):
    client = CollectdClient("collectd.example.com", 25826)
    client.putval('example-web-01', 'service', 'gauge', 'metric', 300, 1.2345)
    client.putval('example-web-02', 'service', 'gauge', 'metric', 300, 0.1234)

from modules.CollectdClient import CollectdClient

def lambda_handler(event, context):

client = CollectdClient("collectd.example.com", 25826)

client.putval('example-web-01', 'service', 'gauge', 'metric', 300, 1.2345)

client.putval('example-web-02', 'service', 'gauge', 'metric', 300, 0.1234)

そして、Lambda -> Configuration -> Handler を
GraphMetricSender.lambda_handler として実行させます。

collectdサーバーの方では、試すだけならばnetworkプラグインで受けて、csvプラグインなどで適当に出力してみればよいです。

modules/CollectdClient.py

これを使って、AutoScalingGroupの各種CPU利用率やインスタンス数、利用中のオンデマンド＆スポット価格、今後使いそうなインスタンスタイプのスポット価格などをグラフに記録しておきます。

Lambda用スクリプトを書いて要望／感想

Event sourcesにインプットデータを送りたい

例えば今回の場合、Event sources -> Scheduled Event で最小の5分間隔で実行させることになりますが、lambda_handler の event変数に任意のデータを送れない（っぽい）のが残念に思いました。

Function毎に任意のデータが送れるならば、サーバーホストを直書きする必要がなくなり、複数のアカウントやサービスで全く同等のスクリプトを使いまわせるためです。現状だと、デプロイ時にテンプレート化して、サービスごとに異なる値を埋め込んでからアップロードしたり、リソースグループタグやS3などに埋め込んで取得させて共通化する、といった汚い感じになりそうです。

今回のアラート／グラフの監視系ならば１つでいける場合もありますが、VPC毎にプロキシを用意する場合も多いため、任意の値を仕込めると便利ではないでしょうか。

Blueprintだけでなくモジュールの充実

Create Functionする時に、少々のBlueprintが選択できますが、言語を絞るとまだまだ少ないのと、内容がeventデータを受け取ってAPI叩いてゴニョゴニョ程度のものしかないので、もっとかき集めるように色んな事例を収集して参考にさせてもらえたらなと思いました。

その際は、lambda_handler用のものだけではなく、今回のような捻くれた用途のモジュールなども含まれていると、より皆が幸せになれそうです。

プロトコルを書くことの是非

私が今回、Pythonを初めて書くというのもあり、基本を勉強しながらだったので結構な時間を要しました。その際に強く思い続けたのが、本当にこの作業は正しい方向性なのだろうか、ということです。

管理サーバーのミドルウェアで送ってしまう方が良いのか、サーバーレスのために各プロトコル用スクリプトを書く方が結果的に良いのか・・・。今後、ZabbixやCollectd以外にも、HTTP以外をしゃべる仕組みを使うとしたら、都度コードを書く必要が出てしまい、それが絶対的に正しいとは言い切れないでしょう。

しかしながら、この試みによって、冗長化構成の管理サーバー２台がサーバーレスになり、元が微々たるものとはいえ費用としてもおそらく安くなるため、確実なメリットも見えています。また、管理系以外にもAPI Gatewayなどを通じて色々できるので、こちらに寄せることで知見が貯まり、好都合となる部分も多いでしょう。

あまり頑固に寄せ切るのも考えものですが、今のところは、コード管理・サーバー管理など総合的に踏まえると、サーバーレスで突っ切ることは間違いではなさそう、と言いたいところですが、、、

単にPythonを書くのが楽しくなったから、そう感じているだけかもしれません。なので、とにかく自分を見失わないように進行したいと思う所存であります。