Docker で Growthforecast をインストールする方法 - tokuhirom's blog
ちょいちょい GrowthForecast のインストールが perl だから難しいとかいってる人をみかけるけれど、Dockerfile が用意してあれば、セットアップは簡単になるんじゃないだろうか。 audreyt が Dockerfile で配布する方法で irc logger を配布していたし、それを真似してみるのもアリかもしれない。そんな風におもって僕もやってみることにした。 Docker をつかうと、アプリをふくんだイメージを簡単に配布することが可能となる。インストール手順をごちゃごちゃとブログに書いたりするのもいいけれど、Dockerfile を共有したほうがいいのではないだろうか。再現可能だし。chef でもなんでもいいけど、docker はインストールが簡単なのがいいし、覚えることがすくなくていい。 いらなくなったら、イメージごとポイすればいいだけで、簡単だしね。 さて本題
fluent-plugin-forest released! - たごもりすメモ
現状のfluentdでは、タグを動的に扱う方法がいまいち無い。具体的に言うと設定項目にタグに応じて変化するような指定をしたい場合、タグごとに分けて書くしかない。例えば out_file で出力先ファイル名をタグに応じてつけたい場合、タグの数だけ match 節を書く必要がある。 <match hoge> type file path /var/log/hoge.log </match> <match pos> type pos path /var/log/pos.log </match> # 以下いっぱいこれには極めて簡単にわかる範囲で、ふたつの大きな問題がある。 多数のタグを扱う場合、設定ファイル全体のボリュームが肥大化して管理コストが増大する(品質が低下する) 新しく扱うタグが増える場合、設定ファイルの更新と適用が必要となり、管理コストが増大する 既に手元でこの問題に悩まされていて、H
Fluentdのタグ書き換えが捗る「tag_parts」プレースホルダを使ってみよう - Y-Ken Studio
Fluentdでログのちょっとした加工をする際に、タグの付け替えが必要です。 新しいタグを指定するか、先頭文字列の付け替えを行う手法が良く使われます。 しかしそれだけではかゆいところに手が届かず、もどかしい思いをされたことでしょう。 そんな時、タグをドットで分解した要素毎に分解して使えるプレースホルダが大活躍します。 この記事を読めば、これがなぜ今まで無かったのか不思議に感じる程です。 そう思えるほど便利な新機能、それでは早速紹介します。 プレースホルダとは プレースホルダとは、一部のfluentdプラグインの設定値の中で使える変数です。 良く使われるプレースホルダとして次のようなものがあります。 ${tag} __TAG__ {$tag_parts[n]} __TAG_PARTS[n]__ ${hostname} __HOSTNAME__ これはFluentdに届いたログを次のように加工
#fluentd fluent-plugin-file-alternative released! - たごもりすメモ
fluentd 標準のファイル出力プラグイン out_file はメッセージをJSONにシリアライズして出力するというもので、これはこれでまあいいんだけど、JSONだと逆に扱いづらいケースなんかもUNIXの文化ではあれこれある。また完全にJSONというわけでもなく、行頭にタブ区切りで日時とタグが入ってたりもするため、いきなり JSON parser にかけるわけにもいかなかったりして面倒だだだ。 ということで、出力フォーマットをさまざまにいじれるようにしたプラグイン out_file_alternative を作り fluent-plugin-file-alternative としてリリースしました。 fluent-plugin-file-alternative | RubyGems.org | your community gem host tagomoris/fluent-plugin
fluent-agent-lite と td-agent で、小さくはじめる fluentd - Studio3104::BLOG.new
fluentdを使ってみたいけど、「JSONでシリアライズしなくていいのに・・・生でいいのに・・・」と思ってなかなか使い出せないというケースはままあるのではないでしょうか。 こんなときに困ってしまうからですよね。 rsyncやscpで毎日深夜にやってくる生ログを解析するスパゲッティスクリプトたちを使えなくなってしまう アプリケーションサーバにログをパースさせるための負荷をかけたくない それでも使ってみたい、現存の古臭い解析機構をアクティブにしたまま、徐々にfluentdによる先鋭的なログ解析を始められたらいいなと思っている方、 fluent-agent-lite と td-agent で、fluentd を小さくはじめてみたらいいと思います。 結論を先に言うと、fluent-agent-lite + fluent-plugin-file-alternative + fluent-plugi
#fluentd 用ログ収集専用のエージェント fluent-agent-lite 書いた - たごもりすメモ
みんな大好きfluentdはたいへん便利ですが、ログの収集＆集約だけをしたい、というときにちょっとオーバースペック気味のところがあります。特に in_tail はログの読み込みと同時に parse をする仕組みになっており、まあログが書かれた場所ならparseのルールもわかってるでしょ、というところは合理的なものでもあるのですが、loadavgが高いサーバでそういうことをするのは正直にいってなかなか厳しいです。 そういうわけで以前に scribeline というエージェントツールを作ったのでこれを fluentd 以降後も使い続けていたのですが、ログをいったん集約するところの fluentd がCPU使用率的にいっぱいいっぱいになって厳しいものがありました。「scribe(Thrift)じゃなくてMessagePackにすれば倍くらいさばけるよ」ということを某開発者が言っていたような気もす
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
fluent-agent-lite と fluentd agent の比較(1) 〜 Haikanko OSS化への道(2) : sonots:blog