collectdサーバーの方では、試すだけならばnetworkプラグインで受けて、csvプラグインなどで適当に出力してみればよいです。Gist.これを使って、AutoScalingGroupの各種CPU利用率やインスタンス数、利用中のオンデマンド&スポット価格、今後使いそうなインスタンスタイプのスポット価格などをグラフに記録しておきます。event変数に任意のデータを送れない(っぽい)のが残念に思いました。Function毎に任意のデータが送れるならば、サーバーホストを直書きする必要がなくなり、複数のアカウントやサービスで全く同等のスクリプトを使いまわせるためです。現状だと、デプロイ時にテンプレート化して、サービスごとに異なる値を埋め込んでからアップロードしたり、リソースグループタグやS3などに埋め込んで取得させて共通化する、といった汚い感じになりそうです。今回のアラート/グラフの監視系ならば1つでいける場合もありますが、VPC毎にプロキシを用意する場合も多いため、任意の値を仕込めると便利ではないでしょうか。Functionする時に、少々のBlueprintが選択できますが、言語を絞るとまだまだ少ないのと、内容がeventデータを受け取ってAPI叩いてゴニョゴニョ程度のものしかないので、もっとかき集めるように色んな事例を収集して参考にさせてもらえたらなと思いました。その際は、lambda_handler用のものだけではなく、今回のような捻くれた用途のモジュールなども含まれていると、より皆が幸せになれそうです。私が今回、Pythonを初めて書くというのもあり、基本を勉強しながらだったので結構な時間を要しました。その際に強く思い続けたのが、本当にこの作業は正しい方向性なのだろうか、ということです。管理サーバーのミドルウェアで送ってしまう方が良いのか、サーバーレスのために各プロトコル用スクリプトを書く方が結果的に良いのか・・・。今後、ZabbixやCollectd以外にも、HTTP以外をしゃべる仕組みを使うとしたら、都度コードを書く必要が出てしまい、それが絶対的に正しいとは言い切れないでしょう。この試みによって、冗長化構成の管理サーバー2台がサーバーレスになり、元が微々たるものとはいえ費用としてもおそらく安くなるため、確実なメリットも見えています。Gatewayなどを通じて色々できるので、こちらに寄せることで知見が貯まり、好都合となる部分も多いでしょう。Pythonを書くのが楽しくなったから、そう感じているだけかもしれません。自分を見失わないように進行したいと思う所存であります。コメントをキャンセルメールアドレスが公開されることはありません。data-url="">外道父ドリコムで主にインフラエンジニアをやっている何でも屋。WordPress.。