Rubygems => fluent-plugin-in_http_healthcheck
GitHUB => fluent-plugin-in_http_healthcheck
『HTTPリクエストに対し、HTTPステータスコード200を返すだけ』のfluentdプラグインを作りました!
ELBとかGoogle Cloud Computingのロードバランサー配下に、fluentd配置したいとき使うといいんじゃないかな―と思います!というかそれ以外使い道あるんでしょうか!
…ということで一応解説しますと、fluentd標準の『in_http』プラグインは『jsonまたはmessagepack』以外のデータが投稿されるとエラーを返すのですね。なので、L7レイヤーでサービス監視しているロードバランサーには、何らかの応答(status:200)をする必要があるのです。
ということで、『fluentdとしてはなんのデータも処理しないプラグイン』が必要ということでした。
2015年4月13日月曜日
2015年4月9日木曜日
fluent-plugin-json_serializerをリリースしましたのまき
Rubygems => fluent-plugin-json_serializer
Source => GitHUB
fluentdのレコードを一つのkeyにまとめるだけという、fluentd filter pluginを書きました。Rubygemsに公開しておきましたので、使ってみてください!
…というgem開発にDockerを使うととても便利だったというお話。
という感じで『とりあえず手を動かしてみよう!』と気軽に作るにはいいんじゃないかな―と思いました。
Source => GitHUB
fluentdのレコードを一つのkeyにまとめるだけという、fluentd filter pluginを書きました。Rubygemsに公開しておきましたので、使ってみてください!
…というgem開発にDockerを使うととても便利だったというお話。
- 未インストール状態に、簡単に復元できるのでクリーンインストール試験が簡単
- とりあえず動かない時、Dockerfile内のソースを修正できる
- 「gem使ってみたけど違うな―」という時に未インストール状態に戻せる
- 複数バージョンのfluentdでテスト出来る
という感じで『とりあえず手を動かしてみよう!』と気軽に作るにはいいんじゃないかな―と思いました。
2015年4月6日月曜日
awscliでS3バケットにあるファイルを、パターンマッチでダウンロードしたいのまき
AWS S3でバケットに収納したログをダウンロードしたい時、awscliを使う事があると思います!その時、ファイル名を指定してダウンロードしたいなーという時のお話。
下記のようにバケット内にログがいっぱいあるとき、パターンマッチでダウンロードしたいということですね。
2014-01-01.log
2014-01-02.log
2014-01-03.log
2014-01-04.log
(中略)
2015-04-01.log
2015-04-02.log
2015-04-03.log
2015-04-04.log
でこれをダウンロードするときなのですが、excludeオプションで全部除外しないとだめなのです。全ファイルがダウンロード対象になってしまいます。
あとはincludeオプションでパターンマッチかければ大丈夫!
あとはincludeオプションでパターンマッチかければ大丈夫!
aws s3 cp s3://[bucket-name] [local-dir] \
--recursive \
--exclude "*" \
--include "*2015-04-*"
NGiNXのアクセス元を、GoogleMapにレンダリングするのまき
NGiNXのアクセス元を可視化する方法を実験してたら、うまくいったので資料化してみました!結構使い道あるんじゃないかな−と思います!たぶん!
2015年4月1日水曜日
fluentdにHTTPヘルスチェックを返答させるのまき
(2015/04/13:RubyGem化しました)
Google Compute Engineの微妙な困りどころとして、「ロードバランサーのヘルスチェックがHTTPプロトコルかつstatus:200を返答しなくてはならない」というのがあります。
つまり『サーバーがHTTPを返答させる必要が無くても、ヘルスチェックのためにHTTPを返答させる必要がある』ということです。
…ということで、みんな大好きfluentdにヘルスチェックを返答させちゃおう!というおはなし。
方針としてはデフォルトで入っている「in_http」プラグインを使って、サブクラス化しちゃうという作戦です。
これをfluentdに読み込ませます!念のため、既存のin_httpも動くか確認します。
チェックしてみましょう!
Google Compute Engineの微妙な困りどころとして、「ロードバランサーのヘルスチェックがHTTPプロトコルかつstatus:200を返答しなくてはならない」というのがあります。
つまり『サーバーがHTTPを返答させる必要が無くても、ヘルスチェックのためにHTTPを返答させる必要がある』ということです。
…ということで、みんな大好きfluentdにヘルスチェックを返答させちゃおう!というおはなし。
方針としてはデフォルトで入っている「in_http」プラグインを使って、サブクラス化しちゃうという作戦です。
module Fluent
class HttpHealthCheckInput < HttpInput
Plugin.register_input('http_healthcheck', self)
def on_request(path_info, params)
begin
return ["200 OK", {'Content-type'=>'text/plain'}, ":) < Hello!"]
end
end
end
end
これをfluentdに読み込ませます!念のため、既存のin_httpも動くか確認します。
<source> type http_healthcheck port 8889 bind 0.0.0.0 </source> <source> type http port 8888 bind 0.0.0.0 body_size_limit 32m keepalive_timeout 10s </source>
チェックしてみましょう!
root@hoge:/etc/google-fluentd/catch-all-inputs.d# curl http://localhost:8889 :) < Hello! root@hoge:/etc/google-fluentd/catch-all-inputs.d# curl http://localhost:8888 400 Bad Request 'json' or 'msgpack' parameter is required
2015年3月9日月曜日
NGiNX_Luaでバックエンドからのリターンコードで処理をわけるのまき
NGiNXのリバースプロキシ使ってますか!Apache+mod_wsgiの前段にNGiNXを置くとかあるんじゃないでしょうか!多分!
…ですが、とっても困るのがバックエンドサーバーで50xエラーが出ることがあるんですよね。困りますね。ということで、NGiNX_luaでリトライ処理するサンプルコードを書いてみました!
…ですが、とっても困るのがバックエンドサーバーで50xエラーが出ることがあるんですよね。困りますね。ということで、NGiNX_luaでリトライ処理するサンプルコードを書いてみました!
upstream backend {
server [proxy先URL];
}
server {
listen 80 default;
server_name 127.0.0.1 localhost;
location / {
content_by_lua '
local STR = "/check"..ngx.var.uri
local res = ngx.location.capture(STR)
if res.status == ngx.HTTP_OK then
ngx.say(res.body)
else
ngx.sleep(1)
res = ngx.location.capture("/check")
ngx.say(res.body)
end
';
}
location /check {
internal;
rewrite /check/(.*) /$1 break;
proxy_pass http://backend/;
}
}
2015年2月18日水曜日
Google Compute Engine上にfluentdを立てて、BigQueryまでつなぎこんでみたのまき
Google Compute Engine上にfluentdを立てて、ログを収集してみました!
何がしたかったのかというと、モバイル端末のログを収集してBigQueryに突っ込んでみたかったんです!
まとめておいたので、みんなみてね!
何がしたかったのかというと、モバイル端末のログを収集してBigQueryに突っ込んでみたかったんです!
まとめておいたので、みんなみてね!
登録:
投稿 (Atom)