flunetd、forward先がダメだった時にforward元である程度ログを担保したい · さよならインターネット
April 1, 2014 fluentdのbufferとforwardについて調べたのでメモ。 fluentd v0.10.45 追記( 04/02 00:27) @kenjiskywalker flushしようとしてできなかったbufferにもlimitまで溜まるから、1kbのbufferが128個で限界にはならないような気がしますが — fujiwara (@fujiwara) April 1, 2014 @fujiwara 今手元で試したんですけどflush_interval関係なさそうですね。普通にflush_interval 1s buffer_chunk_limit 10とか指定してもそれ以上のbuffer保持してました — kenjiskywalker (@kenjiskywalker) April 1, 2014 @tagomoris @fujiwara なるほど〜！ —
td-agent のメモリバッファとファイルバッファでどんな違いが発生するか観察してみた - ようへいの日々精進XP
はじめに 先日、DevOps 向け Fluentd 勉強会 at IPROS で聞いた話の中で Ouptput プラグインのバッファの関して下記の点について気になったので調べたくてウズウズ。 Output プラグインのメモリバッファとファイルバッファの性能はほとんど差異は無い デフォルトはメモリバッファだがファイルバッファがオススメ また、fluent-logger を使ってサーバーの負荷が激しく上がってしまった件について質問させて頂いたがよくよく考えるとこのバッファについて全く考慮しないままの利用だったので、この件でも解決への糸口になるのではということでメモリバッファとファイルバッファで何が違うのかを調べてみた。 構成 検証環境 以下のような検証環境を用意した。 役割 バッファタイプ / Output / アプリケーション OS td-agent バージョン スペック 備考 Forwar
fluentdのoutput_s3プラグイン - Qiita
output_s3プラグインは、fluentdでs3にアップロードするためのプラグインです。 プラグイン全般の基礎知識はこちらから。 td-agentを使用している場合はデフォルトで入っていますが、fluentのgemを使用している場合はfluent-gemからインストールします。 パラメーター type (required) output_s3プラグインを使用するのでs3とします。 aws_key_id (required/optional) AWSのアクセスキーid aws_sec_key (required/optional) AWSのシークレットキー s3_bucket (required) S3のバケット名 buffer_path (required) ログをバッファする際のファイルパス s3_region S3のリージョン Asia Pacific (Tokyo)はap-nor
FluentdでバッファつきOutputPluginを使うときのデフォルト値 - たごもりすメモ
なんか自分で docs.fluentd.org へのpatchを書いてて混乱してきたのでまとめる。コードを読んでも関係する設定値がいくつものモジュールに分散しており、完全に把握することが困難である。具体的には、この組合せを記憶だけで答えられる fluentd コミッタはおそらく一人もいない。 概要 対象は BufferedOutput および TimeSlicedOutput を継承している output plugin の全て*1。out_forward, out_exec や out_exec_filter も含まれる。 基本的にはいくつかの設定により flush をするタイミングを制御するパラメータ一式、およびflush対象となるデータのチャンクを溜めておく量の上限を決めることとなる。fluentd をうっかり試したときに「アイエエエ、fluent-cat してみたんだけど、設定したと
Fluentdの仕組み -バッファ機能でログ収集漏れを防ぐ- - Tech-Sketch
OSSのログ収集管理ツールFluentdを用いてログを統合管理している場合の懸念点として、ログの収集漏れが考えられます。 Fluentdでは、バッファ機能を活用することでログを収集漏れすることなく確実に収集することができます。 このバッファ機能のメカニズムを理解すべく動作検証した結果を紹介します。対象とするFluentdのバージョンは0.10.30です。 Fluentdとは Ruby実装のOSSのログ収集管理ツールです。 Fluentdは、Input、Buffer、Outputの3つのコンポーネントで実現されています。 様々な場所からログを収集、JSON形式に変換し(Input)、蓄積(Buffer)、様々な出力先にデータ出力(Output)します。 例として、あるサーバ(server01)のApacheのアクセスログを別のサーバ(server02)内にファイルとして出力する場合
Fluentdで各種ログをS3とElasticsearchにまとめる - BitArts Blog
各々のサーバの様々な場所に分散しているWebサーバやその他各種ログファイルをFluentdでまとめてAmazon S3にガシガシ保存。かつ、分析用にコピーを自前のElasticsearchにも保存します。保存したログはKibanaで手軽にビジュアライズ。 Fluentdはとてもシンプルな仕組みで理解しやすい。「ログを集積したい！」と感じたらサクッと導入できる超便利ツールです。 今回は集積用サーバを経由してElasticsearchとS3に保存する構成にします。 Elasticsearchのインストール Fluentdで集積したログは保存するだけならS3で良いのですが、手軽にビジュアライズしたいので、今回はKibanaを使えるようにElasticsearchにも保存するようにします。今回はCentOSに導入するので、公式のyumリポジトリからインストールします。 $ sudo rpm --i
fluentdと定番プラグインのインストール
fluentdと定番プラグインのインストール：今さら聞けないfluentd～クラウド時代のログ管理入門（2）（2/2 ページ） これは便利！ 知っておきたいfluentdのプラグイン ここまでの説明で、各プラグインを利用する前提となる設定ファイルの記法についてはお分かりいただけたと思います。 ここからは代表的なプラグインの概要および用途、設定例について、各プラグインの利用時の注意点などと併せて紹介します。 各プラグインの設定に関するより詳細な情報は、公式のドキュメントや各プラグインの公開サイトにある「README」などを参照してください。 fluentdの標準組み込みプラグイン インプットプラグイン ・in_tail ログファイルへの書き込み情報を、常時入力として取り込むプラグインです。pathで指定したファイルをリアルタイムに読み込み、formatで指定した形式でログの各データをkeyと
柔軟なログ収集を可能にする「fluentd」入門 | ページ 3 | さくらのナレッジ
設定例：Apacheのアクセスログを記録する fluentdの基本的な設定例として、まずはApacheのアクセスログを処理する例を紹介しよう。今回は入力プラグインとして「in_tail」を使用し、Apacheがデフォルトで出力するログはそのまま残したうえでfluentdでログを記録することにする。 in_tailプラグインは、指定したテキストファイルを監視し、ファイルに新たな行が追加されたらその内容をログとして記録するという動作をする。なお、テキスト形式でログを記録する場合、logrotateというツールで一定期間ごとにログを別ファイルに切り替えたり、ログファイルを圧縮する、といった作業を行うことが多いが、in_tailプラグインではlogrotateを考慮したファイル監視を行うようになっているため、logrotateを利用している場合でも特に追加の設定などを行う必要はない。 今回は、以下
Nginxのログ(LTSV形式)をFluentd(td-agent)で処理する - Devlog
Nginxのログ(LTSV形式)をFluentd(td-agent)で処理する Mar 22nd, 2013 今運用しているプロジェクトで、ログ解析はfluentd(td-agent)とmongodbを利用しています。 最近、LTSVというログフォーマットが流行っているみたいなので、今回はnginxのアクセスログフォーマットをLTSVに変更し、mongodbで確認するところまでやってみたいと思います。 LTSVについてはこちらが分かりやすいです。 参考: LTSV FAQ - LTSV って何? どういうところが良いの? - naoyaのはてなダイアリー nginx設定 confの修正 今までは、”main”を使用していましたが、”ltsv”というタグで新しく追記します。 /etc/nginx/nginx.conf log_format main '$remote_addr - $rem
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
