Fluentd の forward 系プラグインの比較 : sonots:blog
Fluentdのタグ書き換えが捗る「tag_parts」プレースホルダを使ってみよう - Y-Ken Studio
Fluentdでログのちょっとした加工をする際に、タグの付け替えが必要です。 新しいタグを指定するか、先頭文字列の付け替えを行う手法が良く使われます。 しかしそれだけではかゆいところに手が届かず、もどかしい思いをされたことでしょう。 そんな時、タグをドットで分解した要素毎に分解して使えるプレースホルダが大活躍します。 この記事を読めば、これがなぜ今まで無かったのか不思議に感じる程です。 そう思えるほど便利な新機能、それでは早速紹介します。 プレースホルダとは プレースホルダとは、一部のfluentdプラグインの設定値の中で使える変数です。 良く使われるプレースホルダとして次のようなものがあります。 ${tag} __TAG__ {$tag_parts[n]} __TAG_PARTS[n]__ ${hostname} __HOSTNAME__ これはFluentdに届いたログを次のように加工
fluent-plugin-graphite を書いたよ - Studio3104::BLOG.new
graphite にメトリクスをポストする fluent-plugin を書きました 先に github で公開されていた fluent-plugin-graphite がありましたが、イチから書いて gem release いたしました https://github.com/studio3104/fluent-plugin-graphite http://rubygems.org/gems/fluent-plugin-graphite なぜイチから書いたのか 以下のような箇所に懸念があり、修正だと結局まるっと書き直すのと変わらないと思いイチから書いてしまいました 先行プラグインは、 Fluent::BufferedOutput を継承し、内部でサンプリングやカウントなどの計算をしていたが、そういうのは他のプラグインに任せて、来た値をそのまま投げてあげればいいのではないかと思った レコード
flunetd、forward先がダメだった時にforward元である程度ログを担保したい · さよならインターネット
April 1, 2014 fluentdのbufferとforwardについて調べたのでメモ。 fluentd v0.10.45 追記( 04/02 00:27) @kenjiskywalker flushしようとしてできなかったbufferにもlimitまで溜まるから、1kbのbufferが128個で限界にはならないような気がしますが — fujiwara (@fujiwara) April 1, 2014 @fujiwara 今手元で試したんですけどflush_interval関係なさそうですね。普通にflush_interval 1s buffer_chunk_limit 10とか指定してもそれ以上のbuffer保持してました — kenjiskywalker (@kenjiskywalker) April 1, 2014 @tagomoris @fujiwara なるほど〜！ —
fluentdのちょっとしたチューニングの代理の報告 - Guutaraの日記
はじめに 色々、テストをしてみてる結果をまとめてみた。 検証は、自分がやっている訳ではないので、検証結果からのまとめ。 あと、公開出来ない部分もあったるするので、若干、整理しきれてないけど その辺は、また、修正出来るかな。 以下の感じで繋がっている。 td-agent --> td-agent out_webhdfs ---> HDFS ZeroMQ_pub ---> Subscriberここまでのチューニングで、上記の２つのPluginが、ボトルネックになるという事がわかった。 ZeroMQ_pubは、Aggregatorに仕込んであり、情報が見たい時に、自由に件数などを見れる様にしているらしい。 ということで、以下、チューニング。 チューニング zmq_pubについて zmq_pubは単一スレッドで動いている。その場合、fluentdがflushできるのは1秒間に1チャンクのみ。 従っ
Norikra+FluentdでDoS攻撃をブロックする仕組みを作ってみた ｜ Developers.IO
Norikraとは Norikraとはリアルタイム集計プロダクトです。イベントストリームに対してSQLライクな言語で処理を書くことが出来ます。 例えば、ApacheのアクセスログをNorikraに流し込み、1分あたりのアクセス数やレスポンスタイムの最大値をリアルタイムに集計することが出来ます。 Norikraの利用例は作者であるtagomorisさんのブログで紹介があります。 今回は、Norikraを使ってDoS攻撃をブロックする仕組みを作ってみました。 DoS攻撃ブロックの仕組み アクセス元はApacheのアクセスログから取得し、ログの受け渡しにはFluentdを利用しました。 ブロックの手順は以下のようになります。 アクセスログをFluentdのin_tailプラグインで取得。 Fluentdのout_norikraプラグインで、アクセスログをNorikraに流し込み。 Norikra
dstat + fluentd + Elasticsearch + kibana でサーバモニタリングする - blog.nomadscafe.jp
普段はサーバのメトリクス可視化のためにcloudforecastを使っていますが、某案件用に数秒単位で数十台のサーバのメトリクスを表示したいので、記事タイトルのような構成を作ってみた。 dstatでとった各種値の他に、nginxとmemcachedの情報も合わせて表示させています。 セットアップ もろもろのセットアップのメモ 監視サーバ まず、監視サーバにElasticsearchとkibanaをいれる。環境はCentOS6 $ sudo yum install java-1.7.0-openjdk $ sudo rpm -Uvh https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.x.x.noarch.rpm Elasticsearchは特に設定なく起動 $ sudo service
Fluentdでelasticsearchの一般ログ・スロークエリログを収集する設定 - Y-Ken Studio
FluentdのtailプラグインでElasticsearchのログを収集する方法を紹介します。 収集対象ログ /etc/elasticsearch/logging.ymlにて設定された動作でログを次のファイルに出力します。 /var/log/elasticsearch/elasticsearch.log /var/log/elasticsearch/elasticsearch_index_search_slowlog.log /var/log/elasticsearch/elasticsearch_index_indexing_slowlog.log slowlogに関しては/etc/elasticsearch/elasticsearch.ymlにて設定した閾値時間を超えて処理したクエリを記録できますが、デフォルトでは設定が行われていません。後々のパフォーマンス観察を容易にするためにも設
td-agentでqueue size exceeds limit - Glide Note
昨年構築してからずっと安定稼働していたfluend(td-agent)が年明けくらいから下記のエラーが出て連日停止してしまって、 ちょっとハマったのでメモしておく。(ハッキリとした原因は掴めてないですが) 利用しているtd-agentのバージョンはtd-agent-1.1.18-0.x86_64。 現象 fluent.logには下記が出ていて、機能が停止している。 2014-01-09T20:28:59+09:00 fluent.error {"error":"#<Fluent::BufferQueueLimitError: queue size exceeds limit>","error_class":"Fluent::BufferQueueLimitError","message":"forward error"} 2014-01-09T20:28:59+09:00 fluent.w
Fluentular: a Fluentd regular expression editor
Regular Expression Test String Custom Time Format (See also ruby document; strptime) Example (Apache) Regular expression: ^(?<host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^ ]*) +\S*)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)")?$ Time Format: %d/%b/%Y:%H:%M:%S %z
fluent-plugin-ec2-metadata という fluentd プラグインを書いてみた · takus's blog
前々から fluentd のプラグインを書いてみようと思っていたので、ec2 の metadata をレコードに追加するようなプラグインを書いてみました。 takus/fluent-plugin-ec2-metadata プラグインの書き方は @tagomoris 先生の “fluentdのためのプラグインをイチから書く手順(bundler版)” が大変参考になったので、プラグインを書いてみたい人は見るとよさそうです。 あとは、@sonots 先生の fluent-plugin-record-reformer をかなり参考にさせていただいたのと、Ruby 初心者なので“パーフェクトRuby”にもお世話になりました。 なにをするプラグインか？ ### Input foo.bar {"message":"hello ec2!"} ### Output web.foo.bar { "role_t
#fluentd のためのプラグインをイチから書く手順(bundler版) - tagomorisのメモ置き場
前に自分で書いた fluentdのためのプラグインをイチから書く手順 - tagomorisのメモ置き場 はたいへん重宝していたのだが、書いたすこし後になって実は現在すでに bundle gem コマンドを使うやりかたが良さそうだということがわかってしまったがばたばたしてて移行してなかった。 で、またひとつプラグインを書くことにしたのでついでに bundle を使った手順をざっくりまとめておく。以下のエントリをたいへん参考にさせてもらった。 T-POINTを取得するスクリプトをGistから移動, Bundlerを使ったGem作成メモ (自分用) - ただのにっき(2012-02-18) 準備とディレクトリツリーの作成 bundler は必要なので、なにはなくとも入れておこう。 gem install bundler そしてプラグイン用ディレクトリツリーを作成する。今回は DataCount
Flunetd::MultiOutputとmonitor_agentの関係 - still deeper
monitor_agent fluentd v0.10.33 で in_monitor_agent が追加されました。 in_monitor_agent は次の様なsourceを定義しておくと ... <source> type monitor_agent bind 0.0.0.0 port 24220 </source> ... http経由で、各pluginの内部の状態を取得することができるようになります。 $ curl http://localhost:24220/api/plugins plugin_id:object:3f8747e35fa4 type:forward output_plugin:false plugin_id:object:3f8747e34c30 type:debug_agent output_plugin:false plugin_id:object:3f8
JMXのメトリクスをfluentd経由で蓄積する | nagaseyasuhito Daily works.
みなさんJMXは使っていますか？Javaアプリケーションのメモリ使用量を始めとした統計情報を取得したりできる、運用には欠かせないモニタリング・管理の仕組みですが、統計情報を蓄積する方法に悩んでいる方も多いのではないでしょうか。 今回はアプリケーションから取得できる様々な統計情報をfluentd経由で蓄積し、分析やトラブルシュートに活用する方法を紹介します。 JMX用のfluentdプラグイン JMXの統計情報をfluentdで収集するfluent-plugin-jolokiaというプラグインを使います。 fluent-plugin-jmxではなくfluent-plugin-jolokia？と思われるかもしれません。 JolokiaはJMXをJSONベースのREST APIとして提供するためのエージェントです。fluentdのプラグインはRubyで書かれていますが、Rubyから直接JMXのプ
Fluentdドキュメント２０１３ – hkmurakami's Japanese blog
Fluentdのドキュメント担当の@hkmurakamiです。主にエンジニアコミッタの面々から上がって来た、ほかほかのドキュメントを「えいや！」と編集するのを担当しています。 これはFluentd Advent Calendar。。。とは関係無いですが、似たような文脈で書こうと思います。 進捗どうですか？ ２０１３年には新たに４０のドキュメントが書かれ、新たに３８１のコミットがされました。１日に約１コミットですね。 ２０１２年、末のスナップショット：57 docs、162 commits ２０１３年、末のスナップショット：97 docs、543 commits 日本語ドキュメント @repeatedlyもAdvent Calendarで書いていますが、２０１３年はドキュメントの日本語版がスタートしました。@mazgiさんが４番バッターですが、最近は他の有志によるPull Requestも見
Fluentd+Elasticsearch+Kibana構成で便利な、logstash形式インデックスの粒度をカスタマイズする方法 - Y-Ken Studio
fluent-plugin-elasticsearchやKibanaのデフォルトであるlogstash形式では、年月日毎にインデックスを作成されて使われることを想定されています。 これは扱いやすいのですが万能では無く、次のような状況ではパフォーマンス的な観点で、このインデックスの粒度を変更することを検討すると良いケースがあります。 粒度を細かくしたいケース（時間単位） 日毎のインデックス作成では、elasticsearchに割り当てたメモリ量を超えてしまう 粒度を荒くしたいケース（週単位/月単位/年単位） 日毎のインデックス作成では容量が小さく、日常的に検索する範囲が複数のインデックスに渡るとき Kibanaは年月日以外の粒度（時間・日・週・月・年）にも対応していますので、変更することも容易です。これは次の2つの設定変更で適用できます。 ログ収集を行うElasticsearchへ流し込む、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
さよならインターネット
fluentd pluginの作り方 | Miew Tech Blog: 株式会社Miewのエンジニアがお送りするテックブログ
Design & Implement Batch Stream Processing Application for Ruby
excale.net
