Fluentd + ElasticSearch + Kibana3で簡単に様々なログを可視化・解析する
ISUCON本戦に参加することができてしまったため，各種ログを集めて簡単に見れると良さそうだなぁと思っていたところ，Fluentd + Elasticsearch + Kibana3の組み合わせがなかなかよさそうだったので試してみました． 本記事では，NginxのAccessLogとMySQLのSlowQueryLogを可視化してみます． Fluentdはご存知の方も多いと思いますが，Treasure Dataのメンバによって開発が進めれているオープンソースのログ収集ツールです．Fluentdに追加された様々なログデータはJSONに変換，アウトプットされます．実装はRubyで行われており，pluginを追加することでで様々なINPUT/OUTPUT先を追加することができます． Fluentdにはリアルタイムにログを収集して活用できることや，様々なログフォーマットの違いを吸収してJSONで同
fluentd + Elasticsearch + kibana + siege でお手軽に web サイトのレスポンスタイムを可視化する試み（2） - ようへいの日々精進XP
はじめに 前回の記事で fluentd から Elasticsearch にデータを放り込む際にフィールドタイプが軒並み文字列として扱われてしまった対応として fluent-plugin-typecast を使ってフィールドタイプを変更して Elasticsearch にデータを放り込んで対応したが、別のアプローチとして @johtani さんに以下のようなコメントを頂いたので早速試してみる！ elasticsearch側でマッピングを定義してあげてからデータを登録するとおそらく、floatなどは文字列が来ても登録できると思います。 見た感じ、フィールド名などは決まっているようですし。 コメント頂けるだけでも嬉しいのにわざわざ手順まで記載頂いて感謝！有難うございます！ 参考 johtani / double_mapping_test.json mapping core types deve
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
ログをS3にひたすら溜めるんだ！ fluentd編｜アドカレ2013 : CFn #15 | DevelopersIO
よく訓練されたアップル信者、都元です。アドベントカレンダー2013「AWS CloudFormationビッグバンテンプレート」、本日は15日目です。 昨日は植木さんのソンナコトモアロウカト編でした。ナニコノナマエー( ´,_ゝ｀)ﾌﾟｯ fluentd ログっすよ、ログ。システムを物理サーバ1台で回していた時代において、全てのログがローカルファイルシステムに存在しました。grep等を駆使して動きを追いかけたりすることがそこそこ簡単にできましたね。しかし、今はクラウドの時代。サーバインスタンスの数が増えたのはもちろん、Immutable Infrastructure等の考え方が生まれたことにより、インスタンスの使い捨てリソース化が加速しています。 「XX月YY日ZZ時頃にサーバがおかしかったっぽいんだけどログ追ってよ」と簡単に言われるものの、そのファイルどこだよ、ってのがスタートです。当時
柔軟なログ収集を可能にする「fluentd」入門 | さくらのナレッジ
複数台のサーバーやクラウド環境を組み合わせてのサービス運用においては、ログの収集方法に工夫が必要となる。こういった場合に有用なのが、さまざまなログの収集手段を提供するfluentdだ。今回はfluentdのアーキテクチャやそのインストール/設定方法、基礎的な設定例などを紹介する。 さまざまな方法でログを収集できるfluentd 今回紹介するfluentdは、Treasure Dataが開発するログ収集管理ツールだ（図1）。オープンソースで公開されており、Linuxや各種UNIXで動作する。 図1 fluentdのWebサイト ログ収集のためのソフトウェアとしてはsyslogdやsyslog-ngなどが有名だが、fluentdがこれらと異なる点としては、以下が挙げられる。 さまざまなソースからのイベントをさまざまな媒体に出力できる fluentdの大きな特徴としては、ログの収集方法やログの記
Fluentdが流行る理由がいま分かる、10の実践逆引きユースケース集 - Y-Ken Studio
ログデータを活用してビジネスに役立てようという最近のトレンドは理解できる。 しかし、なぜログ収集ソフトウェアのFluentdがこれほどまで話題になるのか、不思議に感じている方もいるのではないだろうか。単にログデータを収集するならばsyslog-ngやrsyslogで十分ではないかという意見もあるだろう。 それらは既存のログシステムを置き換えるプロダクトであり、Fluentdのそれとは根本的に異なる。Fluentdは、既存のログシステムに手を入れることなく新たにログの収集を行い、ストリームデータ処理を実現するプロダクトなのである。 一般的にログデータはサーバの数だけ分散しており、それを定期実行処理で収集するということだけでも、なかなか骨の折れる仕事である。さらに集めるだけでなく、日々増え続けるログデータを活用できる形に加工してしかるべきデータストアに保管するということに挫折した方もいるのでは
Fluentdとはどのようなソフトウェアなのか - たごもりすメモ
Fluentd というソフトウェアがある。日本国内ではそこそこ話題になってきたが、何ができるのか、何に使うと嬉しいのか、何に使えるのか、という点について詳細をよく知らないという人もおそらくまだ多いことでしょう。 なので、簡単にまとめる。 http://fluentd.org/ なお以下の個別項目ごとに書いていくが、その手前にまとめを置いておくので忙しい人はそれだけ読むとよい。インストールや設定については導入部分については日本語の記事はもう多くあるので、触れない。 概要 できること ログの収集 センサデータ等の収集 汎用データ処理プロセッサとして 頻出ユースケース ログの収集 データの集約 簡単なリアルタイム集計 ソフトウェアとしての特徴 コア プラグイン 安定性 性能 開発体制 コミュニティ ぶっちゃけどうなの？ まとめ 現時点で、複数の場所に分散したデータや常に増え続けるデータの安全な転
CentOSでfluentdとzabbixを使い始めたメモ – taichino.com
このエントリを読んでからfluentdを導入したいと思ってたのですが、手元に頑張って監視するに値するサーバが無くてほったらかしてました。最近Bargain Netが監視しても良いかな位になったのでfluentdを導入してみました。先ほどのリンク中のスライドでzabbixにグラフを書かせてたので、真似してzabbixもついでに導入しています。 まずfluentdをインストールします。td-agentという名前でRPMパッケージが提供されていますので、そちらを利用します。 $ vi /etc/yum.repos.d/td.repo --- [treasuredata] name=TreasureData baseurl=http://packages.treasure-data.com/redhat/$basearch gpgcheck=0 $ sudo yum install td-agen
Apacheログ + fluentd + Splunk Stormやってみる – OpenGroove
一部巷で人気のビジュアライゼーションツール Splunkを使ってみた。Splunkはインストール版とクラウドサービス版があり、今回はクラウド版のSplunk Stormを試してみた。StormはTwitterが開発したストリームエンジン。旬なもの同士で結構ときめく組み合わせですw さらにこのサービス自体、今時普通だがAmazon EC2のマシンとS3ストレージが利用されているとのことで、いかにもクラウド全開モード。ネタとしていつものようにApacheのログをfluentd経由で送る。 参考 splunkってなんじゃ？（splunk stormでfluentd） 以下も良記事（English） Splunk Storm – Machine Data Processing in the Cloud 実行環境 例によってhttpd + td-agentが動作しているAWS t1.microマシン
fluentを使ったログ集約 - 俺の備忘録
アプリケーションサーバのログを集約するのにfluentを利用してみたのでその備忘録。 構築手順を以下にまとめてみます。 構成 アプリケーションサーバから、各種のログをログ集約サーバへ送信する。 対象となるOSは、AmazonLinux リポジトリの追加 [treasuredata] name=TreasureData baseurl=http://packages.treasure-data.com/redhat/$basearch gpgcheck=0 ユーザの作成 fludentのユーザを作成します。ユーザ名は、td-agent # groupadd -g xxx td-agent # useradd -u xxx -g td-agent -s /sbin/nologin td-agent udi,gidは各サーバで同一のものを設定する fluentのインストール yum .confに
Fluentdの知られていない6つのこと - Boost Your Programming!
Fluentdの知られていない6つのこと 本当に知られていないかはわからないです。 公式にはあまり説明されていなかったり調べてもなかなか見つからないことが多いと個人的に思ったものを集めました。 機能や言葉の細かい説明は省いているのである程度使っている人が対象です。 out_copyはshallow copy Fluentdで最初に使うであろうビルドインされているout_copyプラグインですが、実はデフォルトではメッセージをdeep copyしないため意図しない結果になることがあります。 <match test> type copy <store> type record_modifier tag test.aa foo bar </store> <store> type retag tag test.bb </store> </match> <match test.{aa,bb}> ty
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で始めるリアルタイムでのログ有効活用
はじめに Fluentdは、ログを収集し格納するためのログ収集基盤ソフトウェアです。Fluentdにインプットされた、すべてのログをJSONに変換し、アウトプットします。インプットとアウトプットはモジュール化されており、モジュールを追加することでインプット元とアウトプット先を追加できるようになっています。 Fluentdは急速に知名度を高め、多くのWebサービス会社で実際に使用されるようになりました。従来のログが抱えていた問題も、Fluentdが適切な解決策となっていると認知され、かつ簡単に導入・スモールスタートできるミドルウェアであったことが大きかったと思います。 本稿では、Fluentdの簡単な仕組みと導入方法、シンプルな動作事例について紹介します。 対象読者 システム管理者 データサイエンティスト 必要な環境 UNIX系OS Ruby 1.9 ログを出力する理由 システム運用を始める
ログ収集基盤のFluentdとFlume NG、どちらが使いやすい？
ログは、システムの障害解析（デバッグ）や運用モニタリングに使うことを想定して、コンピュータに発生したイベントの履歴を時系列に沿ってファイルに出力したものである。有用なデータではあるが、扱いにくい面がある。そのため、複数のログを突き合わせて分析するといった活用が難しく、従来はもっぱら一つのログを単独で利用するにとどまるケースが多かった。 扱いにくい面とは、例えば「ログを一括して処理するには対象ログを各サーバーから収集しなければならない」「ログはサイズが大きくなりがちなので収集する場合は一部を抜き出すなどの加工が必要」といったことである。ログに新たなデータが書き込まれた際に、それを即座に取り出す手段が用意されていないこともそうだ。 こうしたログの扱いにくさは、「ログ収集基盤」と呼ばれるソフトウエアを使うことで克服可能である。ログ収集基盤は、複数のログを結び付けて分析する際などに必要な、対象ログ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - sndyuk/logback-more-appenders: Extra appenders for Logback.
https://qiita.com/advent-calendar/2013/fluentd/participants