docker fluentd logging driver の基礎的な設定 - Qiita
https://docs.docker.com/engine/admin/logging/fluentd/ docker container では、コンテナ内の何かしらのプログラムが標準出力 (strout) や標準エラー (stderr) に出力した内容を docker logs コマンドで取得することができます。 しかし能動的に取得しいにいくだけでなく、何かしら別の方法で forward をしてくれると助かることもあります。 docker では logging driver という機構で、stdout / stderr に出力された内容を指定された方法で forward する仕組みがあります。 サポートされている logging driver の種類については以下公式ドキュメントを参照ください。 https://docs.docker.com/engine/admin/logging/
FireLens を使って fluentd logging driver 起因の fluentd の負荷を分散させる
Fluentd aggregator を構成する際に、Route 53 や NLB を使うことで、forwarder では 1 つのエンドポイントを指定しつつ簡単に fluend の台数を増減させることができます。ところが、Docker で fluentd logging driver を使う際にそのエンドポイントを指定すると、一度コネクションが確立されるとずっとそのコネクションが使い回されるため、大量のログを吐くコンテナと接続された fluentd ホストだけが高負荷な状態が続くことになります。 この問題を解消するために FireLens を使ってみたという話です。 Fluentd logging driver の実装 Fluentd logging driver の実装は daemon/logger/fluentd/fluentd.go ですが、コネクションにメッセージを書き込むところ
NLB + Fluentd の構成でファイルディスクリプタが枯渇する謎の現象を解消した話 - Repro Tech Blog
Repro インフラチーム (SRE + 分析基盤) の伊豆です。今回は、Repro のデータ収集基盤で私たちが遭遇した問題を紹介したいと思います。 具体的には、AWS Network Load Balancer(NLB) + Fluentd の構成でファイルディスクリプタが枯渇する謎の現象に遭遇したので、その問題の調査記録と解決策を共有します。また、この問題を解消するにあたり Fluentd に PR を送ったのでそれの紹介もします。 https://github.com/fluent/fluentd/pull/2352 データ収集基盤の構成 Repro のデータ収集基盤はFlunetd High Availability Configをもとに構成され、大まかに次のようになっています。 SDK からアップロードされたデータは、転送用 Fluentd(log forwarders)を経由し
dockerコンテナのログをfluentdに集める方法 - Qiita
TL;DR Docker logdriverの機能を利用して，ひとつのfluentdコンテナにdockerコンテナのログを集積する方法をまとめます fluentdコンテナで集まったログをローカル・ファイルに書き出します fluent.confの設定を書き換えて，他のログ収集サーバに転送することもできます 設定例をgithub.comで公開しています コンテナ構成例 ホスト（コンテナを稼働させる物理マシン）で，複数のサービスが，docker-compose-{A,B}として稼働している これらのログを，fluentdコンテナに送る設定を行う 設定 ログ収集用のfluentdコンテナを立ち上げおき，その後，サービスを立ち上げます fluentdコンテナの立ち上げ Dockerコマンド版 いくつかのオプションを付けて，fluentdコンテナを立ち上げます 実行時のローカルディレクトリに，flue
Fluentd 入門 〜運用に必要な基礎知識〜
最近業務で Fluentd を触ることが出てきて入門したんですが、最初のうちはトラブルが起きた時に何が起きているのか、どう対処したら良いのかがさっぱりわからなかったので、「Fluentd ってログの収集とかに使われるやつでしょ？」程度の知識しかなかった過去の自分に向けて「とりあえずこれぐらいは知っておけ！」と言いたい内容をまとめてみました。 トラブルが起きた時にどの処理で問題が起きているのか素早くコードを追うことができて、データの消失を最小限に抑えつつ適切に対処できるようになることを目的としています。 なお、現時点で最新版の Fluentd v0.14.21 を対象にしています。 アジェンダ Getting Started Fluentd のアーキテクチャ Processes Supervisor process Worker process Threads Input thread En
fluent-plugin-kinesis-firehoseでAmazon Kinesis Firehoseにログを転送する | DevelopersIO
fluent-plugin-kinesis-firehoseでAmazon Kinesis Firehoseにログを転送する 2015/10/12 23:55更新 td-agent 2では`gem`コマンドの実行を`td-agent-gem`で行うのが推奨されるため、`fluent-gem`を差し替えました。 ども、大瀧です。 AWSのカンファレンスイベント、re:Invent 2015で発表&ローンチされたAmazon Kinesis FirehoseはKinesisによるストリーム処理をより手軽に利用できる期待の新サービスです。 ただ、FirehoseのDelivery Streamにログデータを送信するためにはFirehose APIを直接叩くか、AWS Kinesis Agentを導入する方法しかありませんでした。本日、@winebarrelさん作のfluent-plugin-ki
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の設定 | DevelopersIO
コンニチハ、千葉です。 AutoScalingに組み込んでいるサーバのログ監視をしたいことって、よくあると思います。 今回は、AutoScaling配下のサーバにfluentdを入れてログ収集サーバにて一括で集めて、ログ監視をする場合に気をつけたことをまとめておきます。 ログサーバ側のtd-agent.conf ログサーバではこんな感じで、td-agent.confを設定しました。 <source> type forward port 24224 bind 0.0.0.0 </source> <match dev.web.log> type copy <store> type file buffer_path /var/log/td-agent/buffer/local_dev.web.log.buf symlink_path /var/log/td-agent/logs_current/
fluent-plugin-kinesisでKinesis Streamsにログを送信する | DevelopersIO
EC2インスタンスからfluentdを使ってストリームデータの収集・処理基盤Kinesis Streamsにデータ送信する方法を紹介します。 Amazon Kinesis Streams とは Amazon Kinesis Streams はデータレコードの大量のストリームをリアルタイムで収集し、処理する Amazonのマネージド・サービスです。 EC2インスタンスなどのプロデューサーは継続的にデータを Streams にプッシュし、EMR/Lambda/Kinesis アプリケーションといったコンシューマーがリアルタイムでデータを処理します。 本記事のゴール EC2インスタンスから fluentd の Kinesis Stream へのアウトプットプラグイン fluent-plugin-kinesis を使って、Apacheサーバーのログを Kinesis Stream に送信します。
Fluentdの設定を考えるときはこんなかんじで考えると便利 - Qiita
Fluentdはデータを流すのに非常に便利なツールでそこら中で使われている(個人調べ)。そのため、なんかいろんなところで設定を見るのであるが、タグに情報が付いていたりフィールドに情報がついていたりして、あれ、これどうなってるんだっけ感に襲われることがよくある。 このあたり自分でも混乱しがちなので、普段どのように考えているかだいたいまとまった気がしたところで書いておくことにした。 Fluentdのデータ構造 まずはFluentdのデータ構造を知っておいた方が良い。Fluentdの内部データはMessagePackで符号化されているが、Fluentdのデータ構造は単なるハッシュではなく、時刻(time)とタグ(tag)という属性を持っている。次のような感じだ。 レコード レコード(record)は入力されたデータそのものであり、tailプラグインであれば、tailした1行のデータに相当する。重
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の弱点を
職場でよく耳にするfluentdを試してみました - Qiita
私なりにfluentdの情報を集め、実装してみました。 fluentdとは データのやりとりを管理するソフトウェア データ、主にログをparse(分解)し転送先に格納出来る 既存のプラグインが多く、出力先も多様である(ローカル、S3、MongoDB、Cassandraなど) buffer機能により、長時間転送に失敗してもリトライが出来る 導入してみました インストール ■前提 ruby環境が必要 実装先はEC2(CentOS6.5) ■はじめに TreasureDataというデータウェアハウスより、td-agentというruby環境込みのパッケージ(td-agent)を取得する ■yum でインストールする ▽リポジトリを登録 # vi /etc/yum.repos.d/td.repo ---------- [treasuredata] name=TreasureData baseurl=
fluent-plugin-bigquery の設定 - Qiita
BigQuery側で「1リクエスト500行まで」という制限があるので500とする。 500ちょうどにしておくとエラーになることがあるという情報があるので、300程度にしておくとよいかもしれない(コメント欄参照)。 buffer_chunk_limit チャンクごとの最大バイト数。 BigQuery側で「1リクエスト1MBまで」という制限があるので1000000とする。 1MBちょうどにしておくとエラーになることがあるという情報があるので、768k程度にしておくとよいかもしれない(コメント欄参照)。 buffer_queue_limit プラグイン側でいくつのチャンクをメモリに保持しておくか設定できる。 デフォルト値は1024となっている。 小さすぎるとキューが溢れてエラーとなってしまうので、メモリ量と相談して大きめの値にしておくとよい。 1チャンクの最大サイズが1MBなので、デフォルトの1
Raspberry PiからFluentdでBigQueryにデータを送るウェザーステーションの作り方 - Qiita
最近なんだか個人的に電子工作ブームで、ついAmazonでRaspberry Piをポチってしまった。とりあえずウェザーステーション（気温・湿度・気圧を測るやつ）を作ってみた。 びろーんと伸びてるのは温度・湿度センサーDHT22で、基板上で青く光っているのが気圧センサーLPS331。丸くて黒いやつはなんとなくつけてみた圧電スピーカーで今回は使ってない。 そして、これらのセンサーデータを10秒おきにFluentd経由でGoogle BigQueryに送る簡単なPythonコードを書いた。Google SpreadsheetからBigQueryのクエリを実行して描いた俺の部屋のお天気環境グラフがこんな感じ。 単に1台分のグラフを書くだけならBigQueryにデータを入れる必要はなくてSpreadsheetに直接送れば済むのだけど、RasPi+Fluentd+BQの連携をいちど試してみたかったのだ
Fluentd + BigQuery による Tweet データ収集 - Qiita
はじめに 今回は、Twitter Streaming API で得られる全ツイート中の 1% の 日本語 Tweet のデータをログとして収集し、 Fluentd を用いて、BigQuery に格納するシステムを構築する。 以下に BigQuery と Fluentd を説明を記載する。 BigQuery とは Google BigQuery とは、クラウド上で動作するデータウェアハウス。 以下の様な特徴を持っている。 テラバイト級のデータに対しても、高速に集計が可能。 ストレージ料金が安い (容量あたりの保存単価だとAWS S3 よりも安価) データのインポートが容易 (バルクアップロード / ストリーム)。 細かい話は次のリンクを参照。 Googleの虎の子「BigQuery」をFluentdユーザーが使わない理由がなくなった理由 #gcpja ありとあらゆるログデータを格納する先とし
Collecting and Analyzing Ruby on Rails Logs | Fluentd
Scenario You have an application written in Rails and want to collect data into MongoDB, HDFS, Elasticsearch, et. al. for analytics/search. Logging directly into MongoDB/HDFS/Elasticsearch is not highly recommended since synchronous logging is slow/potentially hazardous for the backend. You can build asynchronous logging into your application, but Fluentd can sit between your application and backe
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fluentd入門 - Qiita
GitHub - fluent/fluent-plugin-sql: SQL input/output plugin for Fluentd
ログイン - はてな
GitHub - moriyoshi/ik
