Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 近年、自分の中で集計／可視化は Fluentd(datacounter)+Growthforecast で定番化していました。 しかしプロダクトで新たに集計／可視化の要件が出てきたことと、 最近可視化ツール周りで 「Kibanaってなんじゃ？」「Graphiteってなんじゃ？」「InfluxDBってなんじゃ？」 など、このツール達は一体何なんだろう…？というのが前々から気になっていました。 今回良い機会なので ◯◯は何をするものなのか？ というのを一つ一つ調べてみました。 いわゆる「触ってみた系」の記事なので だいぶ浅い感じです。 大分
Kibanaとは ElasticSearch社が提供している、ログデータの可視化ツール。Apatchなどのシステムログを用いる例ばっかりWeb上で見つかるが、別に検索のクエリログやWebサイトの行動ログだってちゃんと入れて設定すれば使える。 Kibanaのインストール ElasticSearchのプラグインとしてインストール (現在はkibana3としなくても、Kibana3が標準でインストールされる。package.jsonみたら3.0.0pre-milestone5バージョンがインストールされていた。) とりあえずここまででKibanaを見てみる http://localhost:9200/_plugin/kibana にアクセス 何かバージョンが古いよみたいなこと言われるけど、気にしないで使える。 こうすると、Elasticsearch自身のログを使ってサンプルダッシュボードを表示し
行ってきました。 Fluentd meetup in Japan #2 #fluentd on Zusaar #Fluentd meetup in Japan # 2 - Togetter 全セッション濃かったうえに、QAの充実っぷりが凄かったです。(ディスプレイの接続問題で結構時間があって、ちょいちょいQAタイムがあった。しかもwindowsがつながらないという。。時代ですね〜。) ## QA内容ははまとめて古橋さんのセッションのメモ部分の最後に書いてあります。 自分はちょっと触ったことがあるくらいなので、正直、fluentdの何たるかがあんまりピンときてなくてなかったのですが、色んな角度から繰り出される質問に、古橋さんが「なるほどっ」と受けて、その後にずばっと繰り出される明瞭な回答や質問者とのやり取りを聞いているうちに、大分見え方が変わってきました。 「Fluentdの現在と未来」 古
Fluentd Casual Talksに参加してきました。こういった勉強会の情報は、twitterとRSSで素早く把握できる様にしてはいるのですが、申し込んだ時点で補欠40番目というかなり絶望的な状況。。でも当日にキャンセルが続出して余裕で繰り上げ当選となりました！ 会場は先日オフィスを移転したばかりのDeNAのヒカリエオフィスです。外部の人を多数招くのは大変だと思いますが（しかも無料で！）受付も誘導の方々もフレンドリーで余裕のある対応！そういったところ見習わないとな〜なんて思いました。 oranieさんの「fluentdはじめました」 Fluentd casual 大規模で使う様になると困るのがconfigファイルの管理ですよね。ウチの環境でもこのあたりはそのまま真似した方が良いだろうなと思いました。 アプリケーションサーバでは、include httpdでconfig情報を読み込ん
Agent ログの量やFluentd＆CPUの性能を考えると、負荷的には１サーバ１Agentで十分足りるので、ステータス検知などの監視だけしっかりしておけばOKと考えます。なので例えばWEBサーバに普通に１Agent入れてそれが数百・数千台になることを想定します。 Collector 複数台用意し、Agentからroundrobinで送信することで均一化します。Collectorダウン時や復旧時は、ログのロスト無しにすみやかにroundrobinから外れたり復活することを確認済みです。台数が増えすぎた時の懸念点は、HDFSに対する１ファイルへのAPPEND数が増えることですが、ここまでの試験を見る限りはおそらくかなりの数まで大丈夫ですし、仮にHDFSへの書き込みが問題になる場合はAgent -> Collectorの選択条件や、書き込みファイルパスで工夫すれば大丈夫です。 とはいえ、APP
髪を切った@HIROCASTERでございませう。 今日は巷で話題のfluentd（フルーエントディー）を使って、アクセスログを活用するための準備をしたいと思います。 簡単にfluentdを使って何をするのか 例えばこんなこと という、知識や目的の準備です。 fluentd とは？ Linuxサーバなどのログを集約するためのツールです。ログ形式は良くあるテキスト形式ではなく、JSON形式にて構造化された形で保存されるため、集約されたログデータを解析したりするのがとってもやりやすくなります。 従来のテキストデータで出力されるApacheのログなどを読み込んで、fluentdでリモートログサーバに飛ばして、集約保存することなんてことができます。 集約されたログデータを解析サーバで解析して、グラフで出力とかするわけです。 具体的にどういうことができるの？ ログデータの活用は無限大なので、さまざまな
ものすごく流行の波に乗り遅れた感がありますがfluentd入れてみました。 fluentdとは 作者の古橋さんのブログから引用 http://d.hatena.ne.jp/viver/20110929/p1 - fluent は syslogd のようなツールで、イベントログの転送や集約をするためのコンパクトなツールです。 ただ syslogd とは異なり、ログメッセージに テキストではなく JSON オブジェクト を使います。また プラグインアーキテクチャ を採用しており、ログの入力元や出力先を簡単に追加できます。 - ログを素敵な感じで別サーバに転送、集約することが可能です。 ログはJSON形式で構造化されているのでログデータが利用しやすいのも特徴です。 手順 ※前提としてapacheが稼働済みであるとします fluentdインストール yumでさくっと vim /etc/yum.re
tenshiとは サーバ上のログファイルは、ただ記録しておいて問題があったときの調査に使うだけではなく、リアルタイムで監視することでアプリケーションやサーバの不具合の早期発見をすることができる。問題が表面化する前に対策を行なうにはログの監視が不可欠だ。 しかし、サーバは、種類も数もどんどん増えていくものだし、それに合わせログファイルの種類も量もどんどん増えていく。全部見るのはもちろん不可能だし、適当に通知をしてもメールボックスを溢れさしてしまうことになり、結局は無視することになってしまい意味がない。 そこで、賢く効率的に監視するために tenshi というツールが非常に便利に使える。 このツール、最近しばらく使っていなかったのだが、最近会社で再び使い始め、便利さを再確認したので紹介してみる。知る人は知るツールだと思うけどいまいちマイナーなのかな？ tenshiは、元々はGentoo Lin
こんにちは。Treasure Data の古橋です^^; 先日の Treasure Data, Inc. 壮行会 で、イベントログ収集ツール fluent をリリースしました！ Fluent event collector fluent は syslogd のようなツールで、イベントログの転送や集約をするためのコンパクトなツールです。 ただ syslogd とは異なり、ログメッセージに テキストではなく JSON オブジェクト を使います。また プラグインアーキテクチャ を採用しており、ログの入力元や出力先を簡単に追加できます。 Twitterでも話題沸騰中です：イベントログ収集ツール #fluent 周りの最近の話題 背景 「ログの解析」は、Webサービスの品質向上のために非常に重要です。Apacheのアクセスログだけに限らず、アプリケーションからユーザの性別や年齢などの詳しい情報を集め
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く