fluentd(td-agent)のインストールと設定
fluentd / td-agent とは fluentd とは fluentdはruby gemによって提供されるログ転送/収集の仕組みです。rsyslogdでは実現できないような大量ログの収集/分析を行う目的で使用すると良いと思います。 td-agent とは td-agentとはfluentdのラッパープログラムです。ruby, gem等のプログラムや起動スクリプトなどの便利なファイルをインストールコマンドひとつで提供してくれます。td-agentは環境変数PATHには存在しないディレクトリにrubyやgemをインストールしてくれるので、システム全体への影響を与えずにfluentdが使えるメリットがあります。 fluentdのデメリット(弱点) fluentdは万能ではなく、業務要件によってはクラシックなrsyslogdを使用する方が良い場面も存在します。以下にfluentdの弱点を
td-agent(fluentd)でtailするファイルをいろいろしたときのメモ - tweeeetyのぶろぐ的めも
はじめに td-agentのin_tailプラグインを使うと 指定したファイルをtail-fしてるように読みこんでからごにょごにょしてくれるわけですが、sourceディレクティブに指定するpath(tailするファイル)について確認してみました in_tailプラグインとは tail インプットプラグインは、Fluentdがイベントログをテキストファイルの末尾から読み取れるようにします。その読み取り方は tail -F コマンドによく似ています。 引用→http://documents.mazgi.com/fluentd/doc/plugin.html#tail 公式→http://docs.fluentd.org/ja/articles/in_tail 試したい内容 tailするファイル自体や中身の有無、変更について試してみます 1.tail監視前にtailするファイルがある(中身数件あ
Fluentd+Elasticsearch+Kibana+Norikra+Zabbixを使ってOpenStackのログ解析してみた | 技術畑 | 情報畑でつかまえて
2.2. システム処理イメージ ログを解析する仕組みとして、こんなフローを考えてみました。 (1) OpenStackが出力するログを、ログ中継サーバーへ集約する。 (2) 集約したログをElasticsearchとNorikraへ送信する。 (3) Norikraへ送られたログを、SQLストリーミング解析にかける。 (4) 解析の結果は問題の有無に関わらずElasticsearchへ格納し、異常が検出された場合はZabbixへ通知する。 (5) 通常のサーバー監視はZabbixが行う。 (6) (2)、(4)でElasticsearchへ送られたデータはKibanaを使用して可視化する。 図 1 システム処理イメージ 3. ログを収集してグラフ化してみる。 まずは、OpenStackの各コンポーネントが出力するログ量の推移と、API実行数の推移のグラフ化してみました。ログメッセージの内容
fluentdでつくる監視系 - Qiita
いつもアプリケーションの開発ばかりで、まじめに監視系を考えたことがなかったので、 fluentdを中心にした監視系を作ってみた。 前提 複数台のアプリケーションサーバ 一台のログ収集サーバ ログにはエラーログとアクセスログの大きく2種類を用意する エラーログは更に複数のレベルでファイル単位にわかれている fatal error warn アプリケーションサーバとログ収集サーバは同一ネットワーク上にある やりたいこと メールで来ても絶対に気がつかない自信がある。 異常の側から教えてくれる仕組みを目指す。 fatalログが出た場合は、電話による通知を行う 全てのエラーログはchatツールに出力する ログのバックアップ ログの分析・可視化 この記事では1, 2, 3についてまとめる。 構築 fluentdのインストール 公式のドキュメントが一番わかり易い。 Installation | Flue
Fluentdの現実装のPros/Cons - Go ahead!
TODO: 必要なら図を足す 他に書いた方が良いPros/Consのリクエストがあったら追記 内部のイベントストリームの扱い Pros: Inputがスケーラブルに実装しやすく，データストリームを正常時/エラー時で切り替えやすい Cons: エラーハンドリングがブロッキングモデルよりも複雑になりやすい 以下長々と理由書きます． Fluentdはイベントストリームを効率良く，またロバストに扱うことを目的に設計されています．そのため，独自の転送プロトコル(forwardプラグイン)を実装していますし，内部のイベントのハンドリングもそれに沿うようになっています．ただ，それによって相性の悪い操作とかもあります． Fluentdはバッファ機能を提供しており，これによって転送の効率化とエラー時のデータロスを防ぐ設計になっています．が，あまりにも書き込み先が遅いなどの問題があると，バッファの制限を超えて
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 /
fluentdの効果的な活用例と安定運用のポイント
fluentdの効果的な活用例と安定運用のポイント：今さら聞けないfluentd～クラウド時代のログ管理入門（3）（1/3 ページ） 効率良く、意味のあるログ管理を実現するツールとして注目されている「fluentd」。最終回では、実際の利用シーンを想定し、より効果的なfluentdの利用法を紹介します。 第1回、第2回でfluentdを使って基本的なログ管理が実現できるようになったのではないでしょうか。fluentdはプラグインの組み合わせにより更に効果を発揮します。最終回では、実際の利用シーンを想定し、より効果的な利用法を紹介します。 fluentdの具体的な活用例 実際の利用シーンを想定した2つのfluentdの活用例を紹介します。 大量のログを分析し、「意味のある情報」として管理する タグデータを効果的に活用し、ログデータのフィルタリング管理を行う 1.大量のログを分析し、「意味のあ
Norikra+FluentdでDoS攻撃をブロックする仕組みを作ってみた ｜ Developers.IO
Norikraとは Norikraとはリアルタイム集計プロダクトです。イベントストリームに対してSQLライクな言語で処理を書くことが出来ます。 例えば、ApacheのアクセスログをNorikraに流し込み、1分あたりのアクセス数やレスポンスタイムの最大値をリアルタイムに集計することが出来ます。 Norikraの利用例は作者であるtagomorisさんのブログで紹介があります。 今回は、Norikraを使ってDoS攻撃をブロックする仕組みを作ってみました。 DoS攻撃ブロックの仕組み アクセス元はApacheのアクセスログから取得し、ログの受け渡しにはFluentdを利用しました。 ブロックの手順は以下のようになります。 アクセスログをFluentdのin_tailプラグインで取得。 Fluentdのout_norikraプラグインで、アクセスログをNorikraに流し込み。 Norikra
Fluentd + ElasticSearch + Kibana3で簡単に様々なログを可視化・解析する
ISUCON本戦に参加することができてしまったため，各種ログを集めて簡単に見れると良さそうだなぁと思っていたところ，Fluentd + Elasticsearch + Kibana3の組み合わせがなかなかよさそうだったので試してみました． 本記事では，NginxのAccessLogとMySQLのSlowQueryLogを可視化してみます． Fluentdはご存知の方も多いと思いますが，Treasure Dataのメンバによって開発が進めれているオープンソースのログ収集ツールです．Fluentdに追加された様々なログデータはJSONに変換，アウトプットされます．実装はRubyで行われており，pluginを追加することでで様々なINPUT/OUTPUT先を追加することができます． Fluentdにはリアルタイムにログを収集して活用できることや，様々なログフォーマットの違いを吸収してJSONで同
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
Kibana + ElasticSearch + fluentd でDBスロークエリログなどを集計し表示したい - Tatsuya Takamura
最近、Fluentd + ElasticSearch + Kibana 3 の構成でお試し運用を始めました。 すると下記のような事をやりたくなったが Apache アクセスログをURL毎に集計したい DB スロークエリログをクエリ毎に集計したい 単純に文字列のフィールドで pie/bar チャートなどを利用すると、期待を打ち砕かれる（打ち砕かれた） ふむふむ、遅いクエリーには select, where, from が多いのか.... orz 見事に単語毎に集計されてしまった。 どうもトークナイズを止めるには ElasticSearch の multi field を利用するのが良さそう。（Solr で言うと copy field？） fluentd + ElasticSearch + Kibana + logstash フォーマットを下記の構成で利用する場合 fluentd のタグは m
fluentdの簡単な使い方、設定方法一覧
fluentdはログの転送・集約を簡単に行うためのツール fluentd ログの転送・集約を行うためのツール。複数台のサーバーを運用している時にそれぞれのサーバーにたまるログを、簡単な記述で特定の場所に集約できる。 今までは同じことをどうやって実現していたの？ バッチでコピーしたり、似たようなことをやるScribeというツールを使っていた。この方法だと、設定が複雑になりがちだし、バッチだとリアルタイムに処理することができなかった。 fluentdの利点は？ 設定が簡単、かつリアルタイムに処理できること。fluentdを使うとバッチではなくリアルタイムなストリーミング処理ができる。 fluentとfluentdのどっちの読み方が正しいの？ 一応、fluentdが正しいっぽいです。 fluentdのインストール方法 簡単なのは、GemやRPMを使ったインストール。yumでのインストールも自分で
FluentdとFnordMetricの連携 | しんめいブログ
前回のエントリ(FnordMetricはGrowthForecastの夢をみるか)から引き続きFnordMetricネタ。 今回はfluent-plugin-fnordmetricを使ってFluentdとの連携を試してみました。 FnordMetricって？ FnordMetricはGrowthForecastの夢をみるかを参考 今回はfluent-plugin-fnordmetricを使ってFluentdと連携させてみた パターン１：dstatのcpu,memoryを可視化 プラグイン ・fluent-plugin-dstat ・fluent-plugin-fnordmetric fnordmetric.rb require "fnordmetric" FnordMetric.namespace :myapp do gauge :dstat_cpu_usr ,:title =>
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
motionの動体検知イベントをfluentd + Zabbixで監視する - GeekFactory
動体検知アプリケーションmotionのログをZabbixで監視してみました。参考になりましたら嬉しいです。 基本的な考え方 motionのイベントが発生するとログファイルにJSONを書き出します。そのログファイルをfluentdで監視し、Zabbixに通知します。具体的には、ログファイルをtailしたものをforwardし、fluentd-plugin-zabbix で通知します。 fluentdを使わなくても、zabbix-senderを実行してZabbixに通知する方法もあります。本稿の方法は以下のメリットがあります。 ホスト間の転送やZabbixへの通知はfluentdがやってくれる。複雑なシェルスクリプトを書く必要がない。 fluentdが再送処理をやってくれる。ネットワークが不安定な場合やダウンタイムの再送処理を自分で作り込む必要がない。 motionが不安定にならない。（イベン
fluentを入れてみた
「fluent」というワードがbuzzっているみたいなのでタイトルに入れてみました。釣りです。 いや釣りではなく一応インストールと簡単な動作確認はしてみました。 ◯fluentとは Treasure Data Inc. の古橋さんが開発されているログ・イベント収集のOSS...
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
fluentdでログが欠損する可能性を考える : sonots:blog