タグ

関連タグで絞り込む (10)

タグの絞り込みを解除

fluentdに関するaerealのブックマーク (10)

  • Fluentd v0.12 ラベル機能の使い方とプラグインの改修方法 - Qiita


    Fluentd v0.12 には Fluentd v0.12 is Released で言及されているように、﹁ラベル﹂という機能が追加されています。本記事ではラベル機能の使い方、またラベル機能に対応するためにプラグインを改修する方法について解説します。 概説 このラベルという機能は、﹁内部ルーティングするのに add_tag_prefix したりremove_tag_prefix したり、タグ設計するのめんどくさい！！﹂という声にお答えして追加されたものです。 ラベル機能を使う事によって、タグを改変することなく、内部ルーティングすることができるようになります。 ラベル機能の導入によって、以下のような利点が生まれていると思います。 タグをいじることが(ほとんど)なくなったので、オリジナルのタグ情報を保てるようになった。 Fluentd 本体がサポートする機能なので、プラグイン作者が個別に
    Fluentd v0.12 ラベル機能の使い方とプラグインの改修方法 - Qiita

  • PostgreSQLのログをfluentdで回収する設定 - still deeper

    PostgreSQLのログをfluentd経由で回収するようにしたので設定を晒しておきます。ほぼ同じ設定を使いまわせるはずなので、fluentd & postgresの組み合わせを使っている人はどうぞ。 PostgreSQL側 postgresql.conf postgresのログの設定はこんな感じ。 # csvlogを出力 logging_collector = on log_destination = 'csvlog,stderr' # 1日でローテーション log_rotation_age = 1440 # /var/log/pgsql/postgres-%Y%m%d.(log|csv)に出力 log_directory = '/var/log/pgsql/' log_filename = 'postgres-%Y%m%d.log' # modeを644に log_file_mode

  • FluentdとRiakの話 - After Coding


    Fluentdは、Ruby製のログコレクタだ。コードは公開されている。 様々なログを構造化して一元管理することができ、収集と解析へのハードルを大きく下げてくれる。 インストールもプラグイン開発も簡単。日本語の資料も多い。 その資料も様々あるが、プラグインを見るならこれが最良だと思う。必要な情報がよくまとまっており、必読といえる。 Big Data入門に見せかけたFluentd入門 from Keisuke Takahashi データの確実な転送を実現するバッファ機能については、池田大輔さんのブログが詳しい。さて、Fluentdはデータを収集してくれるが、保存はしてくれない。 永続化にはデータベースが必要だ。 そこで、Riak。 Basho社がスポンサードするErlang製分散型KVS。これもOSSだが、契約によって商用サービスが受けられる。 これがまたエッジ立ちまくってて

  • fluent-plugin-twitter & fluent-plugin-datacounter - Qiita

    y-ken さんが公開して下さっている fluent-plugin-twitter を使うと tweetstream gem を使って streaming api でツイートを受信して fluentd で扱うことができるようになる。 tagomoris さんが公開して下さっている fluent-plugin-datacounter を使うと指定した時間内に正規表現にマッチするログが何件あるかを数えてその結果を fluentd で扱うことができるようになる。 ツイート数をリアルタイムにカウントする 今回はこの二つを使って、あるアカウントのホームタイムラインのツイートをカウントして mongodb に保存してみたい。 ## fluentd conf # fluent-plugin-twitter の設定 <source> type twitter consumer_key *** consum

    fluent-plugin-twitter & fluent-plugin-datacounter - Qiita

  • Fluentd w/ Ruby 2.0.0-p0 のメモリ使用量 (追記: w/ msgpack v0.5.4) - tagomorisのメモ置き場


    いくつかFluentdのベンチマークをとらないとなー、そういえばRuby 2.0.0-p0も出ましたね、ということでベンチマーク取ろうと思ってあれこれ作業してたらなんか変なのを見付けたのでとりあえず記録。 なおベンチマークの結果については、いろいろ取りかたを考え直す必要があるのでまたこんど。 概要 Fluentd の動作環境が Ruby 2.0.0-p0 with jemalloc なケースで Ruby 1.9.3-p392 に較べて大幅に大幅にメモリを食う上、負荷を停止した時にも何かよくわからない挙動を示す。jemalloc を使わないケースだと 1.9.3 とほとんど変わらないと思われる挙動でjemalloc の必要性が無くなったとかいうわけではない。 詳細 ベンチマークは あるサーバ(4core HT, 16GB RAM)に立てた Fluentd に対し、別のサーバ(同一サブネッ
    Fluentd w/ Ruby 2.0.0-p0 のメモリ使用量 (追記: w/ msgpack v0.5.4) - tagomorisのメモ置き場

  • fluentd + mongodb+ node.js でリアルタイムにグラフを描く - stanaka's blog


    追記 2/22 毎回微妙に追記していますが、今回も追記です。最後にmongodbのinsert性能について80lines/secで厳しくなった、と書いてますが、環境か設定まわりがあやしいので訂正します。もうすこし検証してみようと思います。 → 検証して fluentd側の設定の問題であることが分かりました。詳しくは、http://blog.stanaka.org/entry/2013/02/22/171053 追記ここまで 最近は、fluentd + mongodb でログを蓄積していろいろ便利に使っているわけですが、数分に一回集計スクリプトを周したり、 GrowthForecast の画面をリロードしまくるのではなく、もっとリアルタイムで見たい!という欲求が募ってきたので、 node.js を使って実装してみました。( https://github.com/stanaka/realti
    fluentd + mongodb+ node.js でリアルタイムにグラフを描く - stanaka's blog

  • fluent + mongodb + node.js でwebアクセスの準リアルタイム解析 | Day After Neet

    SEO対策（笑）としてギーク界隈で流行の言葉を３つ並べてみただけです。いや...ううん釣りかどうかは記事で判断してください。 先日「 東京node学園祭2011 」というイベントを聴講して、fluent + mongodb + node.js の組み合わせは、BtoC系の色々...

  • rackのアクセスログをfluentdへ投げるミドルウェア - walf443's blog

    railsのアクセスログは、とても機械的に解析しづらく、運用するにはあまりよろしくない。そこで、Rack::CommonLoggerを使ってアクセスログを別途とったりしようとしていたのですが、(一般的にはNew Rericとかをつかうのが普通なんでしょうか?) ログのローテーションとか考え出すと、あまり良い方法が思いつかない、という関係で、 syslogへ投げる fluentdへ投げる というアイディアを思いついたのですが、syslogだと機械解析しづらいフォーマットになってしまったりあまり詳しい人が意外といなかったりする関係で、流行っているfluentdへ投げちゃえと思いRack::CommonLogger::Fluentというrackのミドルウェアを書いてみた次第。 https://github.com/walf443/rack-common_logger-fluent まだ作り始めで

    rackのアクセスログをfluentdへ投げるミドルウェア - walf443's blog

  • http://fluentd.org/doc/

  • fluentd のベンチマークとってみたよ！ - たごもりすメモ


    入出力プラグインをrubyで書けるのがじつにいい感じの fluentd がいい感じに見える。 fluent/fluentd · GitHub ので使えるかどうか、使えるとしたらどれくらいのノードを用意すればいいのかについて考えるため、とりあえずベンチマークをとってみた。 結論 以下非常に長くなるので結論だけ書くと、大変使える感じ。現状だとほとんど何も考えずにデータ中継させても秒間1万メッセージ、100Mbpsくらいまでは処理できる。効率よくなるよう流す側も考えてやれば 300Mbps を超えるデータの転送に成功した。だいぶいい感じ。 なおこれは in_scribe および out_scribe を使用した場合で、開発者 @frsyuki によるとMessagePackでのデータ転送の場合はこの倍くらい出るらしい。 もちろんこれは右から左に流しただけなので現実にタグによるルーティングだとかロ
    fluentd のベンチマークとってみたよ！ - たごもりすメモ
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.