Fluentdのお勧めシステム構成パターン2014年9月9日開催の『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！ での発表スライドです。 Read less
Fluentdとログ収集のパターン - Go ahead!
「ログを集めて保存する」と言うのは簡単だけど，ログ収集の構成にはいくつか方法があり，勉強会などでちょくちょく聞かれるので，いくつかのパターンについて書く． 「俺はもうバリバリログ収集やってるぜ！」という人は多分すでに知っていることが書かれているので，タブを閉じて良い． ここではログコレクタにFluentdを想定しているが，他のログ収集プロダクトにも適用出来るはず． ただ，Fluentdはタグベースのルーティングを持ち，単体でもキューのように動作させることが可能で，既存のものより複雑な問題を解決しようとしているので，少し工夫が必要かもしれない． Fluentdそのものについては公式ドキュメントや，Fluentdとはどのようなソフトウェアなのかを参考に． クライアントから直接保存する いきなりFluentdを使わないパターン．JavaScript SDKを提供している解析サービスやモバイル端末
おねえさんが、センサー + Raspberry Pi + fluentd + Treasure Data + αで自宅の揺れを検知＆分析してみるよ① - ○○おねえさんのつぶやき
タイトル通り、センサー + Raspberry Pi + fluentd + Treasure Data + 様々なプロダクトを組み合わせて、自宅が揺れる原因を分析してみるお話です♪ 長丁場になりそうなので、これから数回に分けて綴っていこうと思います。 第1回の今回は、揺れ分析をはじめた理由、やりたいこと、システム構成についてお話します。 はじめた理由 実は・・自宅マンション周辺の大規模工事が終わった頃から、毎日ふとした時に自宅が揺れています！ 震度１～２くらいかな？と思ってYahoo!の地震情報を確認してみるのですが、地震は起きていません。 天井から吊してあるパネルも揺れるので、気のせいではないはずなのに。。 管理会社に問い合わせてみましたが、「よくわからないですねー」と素っ気ない返事しか返ってきません。 むむむっ、結構重要な問題だと思うんだけどー＞＜。 揺れの原因によっては引っ越しも考
Googleの虎の子「BigQuery」をFluentdユーザーが使わない理由がなくなった理由 #gcpja - Qiita
「BigQueryは120億行を5秒でフルスキャン可能」は本当か？ 先日、kaheiさんがGoogle BigQuery（Googleクラウドの大規模クエリサービス）について、こんなエントリを書いていた。 とにかくパフォーマンスがすごい。（Fluentd Meetupでの）プレゼン中のデモで、ディスクに収められた5億件のデータをSQLでフルスキャンするのに3秒しかかからない。9億件のデータを正規表現を含んだSQLでスキャンしても、7秒で終わる（これ、記憶がちょっとあいまい。もう少しかかったかも）。これには驚いた。佐藤さんがGoogleに入社して一番驚いた技術が、一般公開される前のBigQueryだったと言っていたが、その気持ちはわかる。 From Fluentd Meetupに行ってきました これを読んだ時、BigQueryの検索スピードについてちょっと補足したくなった。確かにFluent
Norikraでログ集計してアプリのエラーを素早く検知しようという話 - kawamuray's blog
背景 webアプリを書いていると，以下のようなロギングコードを至る所にちりばめる事になると思います． $c->log(error => "Chou Yabai ERROR!"); ただいくらログを吐いても，アプリのログからは片時も目を話さないよ！！みたいな真面目なエンジニアじゃない限り，せっかく吐かれたログに気づけないとかあるわけです． そこで特に重要なログについては別途ikachanとかでIRC等にpostするコードを入れといて，即応できるようにしてることと思います． でも，levelがerrorとかcriticalで吐かれてるログって全部重要だし全部すぐ知りたくね？それにいちいち別途ikachanするコードとか入れるのめんどくね？っていう需要があるわけです． そこでロガーメソッドにif ($level == 'error') { post_to_irc($message) }みたいなコ
そろそろFluentd v11についてひとこと言っておくか - Go ahead!
リリースは永遠にされません！ 日本では色々なところでv11の噂がまことしやかに囁かれていますが， 俺がメインメンテナである限りv11がリリースされることはないので，諦めてv0.10.xを使ってください！ 以下まじめな話になります． v11が生まれた背景と現状 v11が生まれたのは1年以上前です．背景には，v10と呼ばれる今のバージョンがプロトタイプを兼ねたリリースであり， 「利用者のフィードバックを取り込んで，ダメな所をガッツリ書き換えて互換性を壊してメジャーバージョンアップや！」という流れがありました． しかし，v10は十分に柔軟でかつパフォーマンスも発揮しており，コミッタ陣はそれほどモチベーションがあったわけではありません． また，プラグインによって解決出来た問題も多く，v11が生まれた時ほどユーザから「v11が欲しい！」という要望は聞かれなくなりました． 当たり前ですが，ユーザからの
Fluentdでsyslogを取り込むための権限設定（CentOS 5&6両対応） - Y-Ken Studio
syslog経由で出力される次のようなログファイルを、Fluentdに取り込む場合に便利なTIPSを紹介します。 /var/log/messages /var/log/secure 今回はこれらのsyslogを一般ユーザでも読み込みは出来るよう、権限を少し緩める設定を紹介したいと思います。 設定例 素の状態でsyslogをtd-agent(fluentd)から取り込もうとすると、権限エラーが発生します。 Fluentdから読み出せるよう、rsyslog(syslog)の設定を変更していきます。 # サンプルのためsourceブロックのみ記述します $ cat /etc/td-agent/td-agent.conf <source> type tail path /var/log/messages format syslog tag td.syslog.messages pos_file /
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が流行る理由がいま分かる、10の実践逆引きユースケース集 - Y-Ken Studio
ログデータを活用してビジネスに役立てようという最近のトレンドは理解できる。 しかし、なぜログ収集ソフトウェアのFluentdがこれほどまで話題になるのか、不思議に感じている方もいるのではないだろうか。単にログデータを収集するならばsyslog-ngやrsyslogで十分ではないかという意見もあるだろう。 それらは既存のログシステムを置き換えるプロダクトであり、Fluentdのそれとは根本的に異なる。Fluentdは、既存のログシステムに手を入れることなく新たにログの収集を行い、ストリームデータ処理を実現するプロダクトなのである。 一般的にログデータはサーバの数だけ分散しており、それを定期実行処理で収集するということだけでも、なかなか骨の折れる仕事である。さらに集めるだけでなく、日々増え続けるログデータを活用できる形に加工してしかるべきデータストアに保管するということに挫折した方もいるのでは
Fluentd 2013年開発・状況まとめ / 2014年に向けて | Post Moratorium
Fluentd 2013年開発・状況まとめ / 2014年に向けて ワイワイ！Fluentd Advent Calendar 2日目担当の @kzk_mover です。このエントリでは2013年 Fluentd の開発・コミュニティの状況まとめをお届けします。 2013年開発まとめFluentdコア自体は2013年、191 commit (そのうち @repeatedly が 84 commit)。ドキュメントの方は326 commitあります。コア以外にも、2012年年末に約70だったプラグイン数は、2013年12月1日現在に約3倍の206個となっています。 Fluentdのコア自体は10回リリースされ、td-agentは6回リリースされています。大体Fluentdが月1回、td-agentが月に2回の計算になります。また、@repeatedlyがTD社に入社し、td-agentのメンテ
fluentd と Elasticsearch と kibana の組み合わせがとても気に入ったのでメモ - ようへいの日々精進XP
きっかけ fluentd で集めたログを GUI で簡単に見ることが出来ないかと悩んでいたら、以下の参考にしたサイトのように良い事例があるではないですかということで早速チャレンジ。 参考にしたサイト Kibanaってなんじゃ？（Kibana+elasticsearch+fluentdでログ解析） Kibana + ElasticSearch + Fluentd を試してみた Elasticsearch入門 pyfes 201207 http://blog.johtani.info/blog/2013/06/10/fluent-es-kibana/ Kibana Installation rashidkpc/Kibana うんちく 自分なりに整理した Elasticsearch と kibana について。 Elasticsearch Apache Lucene をベースに作られた REST
Fluentd message forwarding with authentication and encryption
Fluentd message forwarding with authentication and encryption
Termtter + Fluentd ですべてのツイートを構造化データとして収集する | 774::Blog
<source> type forward port 9999 </source> <match twitter.statuses> type mongo database twitter host localhost port 27017 tag_mapped flush_interval 1s </match> > show dbs; twitter 0.015625GB > use twitter switched to db twitter > show collections; system.indexes twitter.statuses > db.twitter.statuses.findOne() { "_id" : ObjectId("522828fe1c2a362fed000001"), "created_at" : "Thu Sep 05 04:00:11 +0000
td-agentへのfluent-plugin追加に失敗した件＋解決策 - Qiita
事象 fluent-plugin-mysqlを使ってみようと思って、td-agentにインストールしようとしたところ。 # /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-mysql # vi /etc/td-agent/td-agent.conf # service td-agent restart Starting td-agent: 2013-02-14 18:14:40 +0900: fluent/supervisor.rb:187:rescue in main_process: config error file="/etc/td-agent/td-agent.conf" error="Unknown output plugin 'mysql'. Run 'gem search -rd fluent-plug
Amazon Recommends @Fluentd as "Best Practice for Data Collection" over Flume and Scribe | Treasure Data Blog
Amazon Recommends Fluentd as “Best Practice for Data Collection” over Flume and Scribe Tweet This month, Parviz Deyham from Amazon Web Service promoted Fluentd as the best data collection tool for Amazon Elastic MapReduce (EMR), a hosted Hadoop framework running on Amazon Elastic Compute Cloud (EC2) and Amazon Simple Storage Service (S3). In the best practices whitepaper, Parviz, an Enterpise Solu
アプリを支えるFluentd+mongo dbを使った大規模ログ解析
アプリを支えるFluentd+mongo dbを使った大規模ログ解析 Presentation Transcript アプリを支えるFluentd +MongoDBを使った大規模 ログ解析 2013/03/2513年3月25日月曜日 自己紹介 • 田中 勇輔(@csouls) • ハッカーLv.3（ホイミが使えるようになっ た） • 8ヶ月くらい前にユーザ系SIer→Web業界へ 転職13年3月25日月曜日 変化を善とする文化 • 転職して一番変わったことは、周りの人の技 術変化に対する価値観の基準が悪→善になっ たこと • 停滞はゆるやかな死。しかし、変化する方向 を間違え続けるとすぐに死ぬ13年3月25日月曜日 分析 • 変化の方向を決める道標 • 分析基盤も変化(発展)し続ける13年3月25日月曜日 ログ分析基盤 • fluentでログを集めてMongoDBで集計して Ruby o
Quickstart Guide | Fluentd
Let’s get started with Fluentd! Fluentd is a fully free and fully open-source log collector that instantly enables you to have a ‘Log Everything’ architecture with 125+ types of systems. Fluentd treats logs as JSON, a popular machine-readable format. It is written primarily in C with a thin-Ruby wrapper that gives users flexibility. Fluentd’s scalability has been proven in the field: its largest u
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - embulk/embulk: Embulk: Pluggable Bulk Data Loader.
GitHub - tagomoris/fluent-plugin-secure-forward
Big Data入門に見せかけたFluentd入門
