Fluentd 入門 〜運用に必要な基礎知識〜
最近業務で Fluentd を触ることが出てきて入門したんですが、最初のうちはトラブルが起きた時に何が起きているのか、どう対処したら良いのかがさっぱりわからなかったので、「Fluentd ってログの収集とかに使われるやつでしょ？」程度の知識しかなかった過去の自分に向けて「とりあえずこれぐらいは知っておけ！」と言いたい内容をまとめてみました。 トラブルが起きた時にどの処理で問題が起きているのか素早くコードを追うことができて、データの消失を最小限に抑えつつ適切に対処できるようになることを目的としています。 なお、現時点で最新版の Fluentd v0.14.21 を対象にしています。 アジェンダ Getting Started Fluentd のアーキテクチャ Processes Supervisor process Worker process Threads Input thread En
Google、FluentdをKubernetesとCompute Engineの標準ログコレクタに採用 - Qiita
Google、FluentdをKubernetesとCompute Engineの標準ログコレクタに採用FluentdgooglecomputeenginekubernetesGoogleCloud まずはFluentdコミュニティの皆さん、おめでとうございます！！！ Googleを中心に開発されているオープンソースのDockerジョブスケジューラKubernetes (k8s)、それにGoogle Cloud Platformのログ収集サービスGoogle Cloud LoggingのGoogle Compute Engine用ログコレクタとして、Fluentdが標準採用されました。もうひとつおまけに、fluent-plugin-bigqueryをフィーチャしたソリューションページも、あと1か月くらいでcloud.google.comにて公開される見込みです（これは私がいま仕上げ中）。
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
Fluent Dashboard＋Norikraでリアルタイムダッシュボードを7分で作る話 #dockerjp - Qiita
Fluent Dashboardって？ Fluent Dashboardは、Fluentdで集計したデータをグラフやテーブルで表示できるGoogle Spreadsheet。fluent-plugin-https-jsonを使ってイベントログを送ると、以下のようにリアルタイムにデータを表示してくれる。 使い方 詳しい使い方はREADMEにある通りで、Spreadsheetをコピーして公開設定等をポチポチするだけで準備完了。3分もかからない。あとはfluent-plugin-https-jsonのログ送信先URLとしてFluent SpreadsheetのエンドポイントURLを指定すれば動き始める。 集計ログの表示向け 任意のFluentdログを受け取ってグラフやテーブルを描けるけど、大量のログを直接受け取ることはできない。集計後のログを3秒に1回ほどの割合で受け取って表示する、といった使い
InfluxDBとGrafanaとfluentdで、twitterデータのリアルタイム集計・可視化 - Qiita
require 'influxdb' => true influxdb = InfluxDB::Client.new :username => 'root', :password => 'root' => #<InfluxDB::Client:0x007fb424481ec8 @async=false, @hosts=["localhost"], @initial_delay=0.01, @max_delay=30, @open_timeout=5, @password="root", @port=8086, @read_timeout=300, @time_precision="s", @use_ssl=false, @username="root"> influxdb.create_database('qiitademo') => #<Net::HTTPCreated 201 Crea
dstat + fluentd + Graphite + Grafana でサーバモニタリングする - blog.nomadscafe.jp
ES + kibanaでサーバモニタリングをやってみたのですが、ESのCPU負荷がかなり高くて、リアルタイムにモニタリングできない状況だったので、graphite + grafanaにしてみた。ちなみに、ESのサーバのCPU負荷はこんな感じ。 GrafanaはGraphite用のDash boardを作るツール。最近、influxDBにも対応していてなかなか野心的。 Grafana - Graphite Dashboard kibanaをforkしただけあって、画面はそっくり。まだ修正もれがあるのか、メッセージにkibanaって文字がでてくることもある セットアップ もろもろのセットアップのメモ 監視サーバ まず、監視サーバにGraphiteとGrafanaをいれる。環境はCentOS6 CentOS6.x - CentOSにRPMでGraphite+Diamondをインストールする -
そろそろFluentd v11についてひとこと言っておくか - Go ahead!
リリースは永遠にされません！ 日本では色々なところでv11の噂がまことしやかに囁かれていますが， 俺がメインメンテナである限りv11がリリースされることはないので，諦めてv0.10.xを使ってください！ 以下まじめな話になります． v11が生まれた背景と現状 v11が生まれたのは1年以上前です．背景には，v10と呼ばれる今のバージョンがプロトタイプを兼ねたリリースであり， 「利用者のフィードバックを取り込んで，ダメな所をガッツリ書き換えて互換性を壊してメジャーバージョンアップや！」という流れがありました． しかし，v10は十分に柔軟でかつパフォーマンスも発揮しており，コミッタ陣はそれほどモチベーションがあったわけではありません． また，プラグインによって解決出来た問題も多く，v11が生まれた時ほどユーザから「v11が欲しい！」という要望は聞かれなくなりました． 当たり前ですが，ユーザからの
dockerなら5分で動く！ nginxのログをfluentdで集めてnorikraでストリーム分析 - Qiita
はじめに ようへいさんのポストを参考にしてdocker上でnginxとfluentdとnorikraを動かせたので、docker indexにイメージを掲載した。dockerのある環境ならあっという間に動くはず。 準備 dockerが動くこと ホスト側でfluentd用のファイルディスクリプタ設定を済ませていること 手順 norikraを動かす まずはログの集約先となるnorikraを動かす。 $ sudo docker run -p 26578:26578 -p 26571:26571 -p 24224:24224 -p 24224:24224/udp -d kazunori279/fluentd-norikra-server $ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 7874efdd2e
Fluentdとはどのようなソフトウェアなのか - たごもりすメモ
Fluentd というソフトウェアがある。日本国内ではそこそこ話題になってきたが、何ができるのか、何に使うと嬉しいのか、何に使えるのか、という点について詳細をよく知らないという人もおそらくまだ多いことでしょう。 なので、簡単にまとめる。 http://fluentd.org/ なお以下の個別項目ごとに書いていくが、その手前にまとめを置いておくので忙しい人はそれだけ読むとよい。インストールや設定については導入部分については日本語の記事はもう多くあるので、触れない。 概要 できること ログの収集 センサデータ等の収集 汎用データ処理プロセッサとして 頻出ユースケース ログの収集 データの集約 簡単なリアルタイム集計 ソフトウェアとしての特徴 コア プラグイン 安定性 性能 開発体制 コミュニティ ぶっちゃけどうなの？ まとめ 現時点で、複数の場所に分散したデータや常に増え続けるデータの安全な転
「fluentd」と「Storm」の比較について - Tous Les Jours 攻防記
まず、両者はかなり性質の異なるプロダクトなので、以下の比較は筋違い。 筋違いであることを前提に、ストリームデータ処理プラットフォームとしての両者を比べてみる。 基本情報 fluentd http://fluentd.org/ 今をときめくログコレクター/イベントアグリゲーター。Rubyで実装されているが軽量高速。 RPC基盤ではなく、その下のレイヤーに位置するプロダクト。 Storm http://storm-project.net/ 分散RPC基盤。ストリームデータ版MapReduce風フレームワーク。Java+Clojureで実装されている。 概要については、下記のスライドがとてもわかりやすかった。 Twitterのリアルタイム分散処理システム「Storm」入門 ストリームデータ処理で何をするのかについて ストリームデータ処理のニーズについて、自分が理解している範囲での簡単な説明。 典
#fluentd のためのプラグインをイチから書く手順(bundler版) - tagomorisのメモ置き場
前に自分で書いた fluentdのためのプラグインをイチから書く手順 - tagomorisのメモ置き場 はたいへん重宝していたのだが、書いたすこし後になって実は現在すでに bundle gem コマンドを使うやりかたが良さそうだということがわかってしまったがばたばたしてて移行してなかった。 で、またひとつプラグインを書くことにしたのでついでに bundle を使った手順をざっくりまとめておく。以下のエントリをたいへん参考にさせてもらった。 T-POINTを取得するスクリプトをGistから移動, Bundlerを使ったGem作成メモ (自分用) - ただのにっき(2012-02-18) 準備とディレクトリツリーの作成 bundler は必要なので、なにはなくとも入れておこう。 gem install bundler そしてプラグイン用ディレクトリツリーを作成する。今回は DataCount
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
開発メモ#6 : ログの取り扱い : GrowthForecast, Amazon S3, Treasure Data で心労ゼロ - naoyaのはてなダイアリー
開発メモ#6 です。前回から少し間があいてしまいました。 開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー で書いたように、EC2 へのアプリケーションのデプロイにあたっては Elastic IP の利点を活かしてカジュアルにホストを入れ替えまくっています。ちょっとこのデプロイは慎重になりたいな、と思ったらスナップショットからインスタンスを立ち上げては切り替える、の繰り返し。 この運用をしていると、スナップショットとの差分ができやすいのは chef-solo で吸収するというのが前回、前々回のはなし。 もう一点問題があります。アクセスログやアプリケーションのログです。フロントエンドのサーバをあっちこっち切り替えているうちに、そのままではログが分断されてしまう。ホストを Terminate しようものならログは消失してしまいます。 この
Labeled Tab Separated Values (LTSV) ノススメ - stanaka's blog
追記(2/8 11:30) id:naoyaによる一連のまとめが【今北産業】3分で分かるLTSV業界のまとめ【LTSV】 - naoyaのはてなダイアリーにあります。 また、仕様などをまとめるために http://ltsv.org/ を立ち上げました。 追記ここまで Labeled Tab Separated Values (LTSV) というのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからfluentd、Apache Hiveまで幅広く便利に使えています。 ログフォーマットに期待されることは、 フォーマットが統一されている → 共通のツールで集計し易い 新しいフィールドの追加が容易 → サー
Amazon LinuxにFluentdをインストールしてS3とMongoDB連携する ｜ Developers.IO
あらゆるログを収集する 昨年あたりからfluentdという名前をよく耳にするようになりました。弊社での実際のプロジェクト活用が出てきています。そこで今回は備忘録としてセットアップからプラグインのインストール等の基本的な手順を紹介したいと思います。 セットアップ Amazon Linuxにインストールするためにリポジトリを設定して簡単インストールします。 $ sudo vi /etc/yum.repos.d/td.repo [treasuredata] name=TreasureData baseurl=http://packages.treasure-data.com/redhat/$basearch gpgcheck=0 yumでインストールにて自動起動設定します。 $ sudo yum install td-agent -y $ sudo service td-agent start
#fluentd で maillog を読み込んで MongoDB に投入 - 酒日記 はてな支店
MTA が吐く maillog は普段あまり見ないのだけど、トラブルがあったときには大変重要。これも Mongo に入れれば、問い合わせがあったアドレスで検索してログを管理画面で見るとかできて便利！ということでやってみた。 # fluentd.conf <source> type tail path /var/log/maillog tag maillog format /^(?<date>[^ ]+) (?<host>[^ ]+) (?<process>[^:]+): (?<message>((?<key>[^ :]+)[ :])? ?((to|from)=<(?<address>[^>]+)>)?.*)$/ </source>正規表現がなかなかですが、これで maillog を parse して以下のような生ログから 2012-03-26T19:49:56+09:00 worker00
dstatの万能感を満喫するためにfluentdにログを飛ばしてみた - As a Futurist...
@hirose31 さんが突如として流行らせた感のある dstat ですが、「乗るしかない、このビッグウェーブに！」ということで python の勉強ついでに触ってみました。 dstat の万能感がハンパない – (ひ)メモ dstat の結果を fluentd に投げる やったこととしては、csv に吐き出す部分をパクってそのまま fluend に投げる様にしてみました。 fluent-logger · b6dcb12 · riywo/dstat これで、dstat の起動オプションに--fluentdというのを与えると、ローカルの TCP:24224 で待ち受けている fluentd に対して「debug.*」の形で毎秒ログを送りつけることができます。(fluentd の接続先とかタグとかは誰か調整できるようにして下さい。。。) 2012-03-03 03:36:43 +0900 de
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
fluentdでログが欠損する可能性を考える : sonots:blog
あんまり知られてない機能について - Qiita
第64回、第65回 NHK紅白歌合戦 | クラスメソッド株式会社
