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)を経由し
最近業務で Fluentd を触ることが出てきて入門したんですが、最初のうちはトラブルが起きた時に何が起きているのか、どう対処したら良いのかがさっぱりわからなかったので、「Fluentd ってログの収集とかに使われるやつでしょ？」程度の知識しかなかった過去の自分に向けて「とりあえずこれぐらいは知っておけ！」と言いたい内容をまとめてみました。 トラブルが起きた時にどの処理で問題が起きているのか素早くコードを追うことができて、データの消失を最小限に抑えつつ適切に対処できるようになることを目的としています。 なお、現時点で最新版の Fluentd v0.14.21 を対象にしています。 アジェンダ Getting Started Fluentd のアーキテクチャ Processes Supervisor process Worker process Threads Input thread En
Java 版 Fluentd サーバである、Influent のベンチマーク第二弾です。 MessagePack デシリアライズ処理を改善したので、その効果を測定します。 テスト概要 http://blog.okumin.com/entry/2017/01/24/002953#テスト概要 Disclaimer http://blog.okumin.com/entry/2017/01/24/002953#Disclaimer テスト環境 インスタンス 送信側、受信側共に Google Compute Engine asia-northeast1 リージョンの n1-highcpu-32 を用いました。 送信側は二台用意し、それぞれ20プロセス、合計40プロセスの Fluentd が並列にイベントを送信します。 バージョン 環境構築は influent-benchmark の a4565f88
以下に移行しました。 kenzo0107.github.io
FluentBitとは IoT機器や組み込み機器を対象としたオープンソースのデータコレクタです。名前から分かる通り、Fluentdの兄弟アプリで、Treasure Dataのエンジニアが中心となって開発が進められています。 このソフトでは、例えば、 定期的にCPU使用率を取得し、標準出力に出力する カーネルログを取得し、外部のFluentdサーバに送信する センサファイルから定期的に状態を読み出し、HTTP経由で外部に送信する といったことが可能です。 名前はFluent-Bitだったり、Fluent Bitだったり、FluentBitだったり、様々な記載が見受けられます。 特徴 本家のFluentdと比べて次のような特徴があります。 C言語で実装されているため、Rubyが無い環境でも動作する 軽量・高速(らしい)*1 C API経由で自前のアプリからデータを流せる/受け取れる ビルドオプ
This document describes a presentation about introducing black magic programming patterns in Ruby and their pragmatic uses. It provides an overview of Fluentd, including what it is, its versions, and the changes between versions 0.12 and 0.14. Specifically, it discusses how the plugin API was updated in version 0.14 to address problems with the version 0.12 API. It also explains how a compatibilit
HadoopとFluentdは、国内企業のビッグデータにおける事実上の標準になれるか：オープンソースとエンタープライズの関係（4） 日本企業の間でのHadoop普及に向けた課題の克服について、NTTデータとFluentdを推進するトレジャーデータはどう取り組んでいるか。この分野における一般企業とオープンソースソフトウェアの関係を探る。 Hadoopは、非IT産業における普及が期待されるオープンソースソフトウェアの筆頭格といえる。端的にいって、Hadoopのような幅広いユースケースに対応できる単一の商用パッケージ製品は他に存在しない。特にビッグデータ／IoTについてはこのことが当てはまる。ビッグデータ関連のパッケージについてもHadoopを前提とし、これを補完するソフトウェアやハードウェアを組み合わせたものが多い。 では、非ITの一般企業はHadoopを使いさえすればそれでいいのか。過去約8
最近 Fluentd の通信プロトコルまわりをアップデートするためにあれこれいじっている*1んだけど、これはおおむね fluent-plugin-secure-forward がサポートしていた内容を Fluentd 組込みの forward plugin でもサポートしますよ、というものになる。 んで問題なのが secure-forward は SSL/TLS での接続のみしかサポートしてなかったんだけど forward では生の TCP で通信する*2ので、本当に secure-forward と forward それぞれの実装間で互換性が保たれているのか、直接的には確認する手段がない、ということになってしまう。 TCP server の SSL/TLS 化 一方世の中には SSL/TLS ターミネータという機能があって、たとえばロードバランサなんかがこの機能を持っている。何をやるかと
The document discusses Fluentd's changes to its plugin API between versions 0.12 and 0.14. In 0.14, the API was overhauled to separate entry points from implementations and introduce a plugin base class to control data and control flow. A compatibility layer was added to allow most 0.12 plugins to work unmodified in 0.14 by handling calls to overridden methods. However, plugins that override certa
Emacs で apache-mode を使おう！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
本番環境で動いているFluentdのin_forwardに何が流れているのかを知りたい、けど設定を触りたくない…みたいな場合に流れているタグやレコードを見る方法です。特にFluentdに限った話ではないですが、備忘録として書いておきます。 1. tcpdumpでキャプチャ 調べたいサーバ上で、tcpdumpを使ってパケットキャプチャを取ります。in_forwardのポート番号などを指定してキャプチャします。 $ sudo tcpdump -i eth0 -w fluentd.pcap port 24224 and tcp 2. tcptraceでTCPストリームのデータだけ吐き出す tcptraceは-eオプションを渡すと、TCPストリームごとのデータをファイルに吐いてくれるのでこれを利用します。なお、tcptraceはHomebrewやaptで入ると思います。 $ tcptrace -e
treasure-data/kafka-fluentd-consumer Kafkaからデータを取り出してFluentdに転送するJava実装のKafka Consumerを書きました．基本的なことはREADMEに書いてるんですが，一応日本語でも書いておきます． 背景 1トピック1パーティションであれば，すでに公開されているfluent-plugin-kafkaが使えます．ですが，複数トピックだったりをConsumer Groupを使って処理しようとすると，現状fluent-plugin-kafkaが依存しているPoseidonに機能がたりないという問題があります(output側は問題ありません)． 海外だとデータ量が多い会社も多く，それに伴いKafkaを使っている会社が少しずつ増えてます．その影響もあり，FluentdとKafkaを連携させたいという要望がちょくちょく出てきたので，Jav
以前に書いた話の続きなんだけど、Docker 1.8が出た。 blog.docker.com で、それに Fluentd logging driver が入っている。これで Docker container で起動したプロセスのSTDOUTやSTDERRを直接Fluentdに向けて投げることが可能になった。Dockerにpull-reqを送ったのは初めてだったんだけど、無事マージされてリリースまでこぎつけたので、本当に出たときはほっとした。途中だいぶ大変だったので……。 Collecting All Docker Logs with Fluentd | Treasure Data Blog 5 Use Cases Enabled by Docker 1.8’s Fluentd Logging Driver | Treasure Data Blog Treasure Data blogで既に
はじめに Docker 1.8 から Logging driver に Fluentd が加わるということで心待ちにしていたら、Docker 1.8-rc3 がリリースされていたので待ちきれず試してみた。 ※本記事の内容は Docker 1.8-rc3 上で試した内容となるので、リリース版と異なる内容があるかもしれないのでご容赦下さいませ。 追記（2015/08/12 PM 5:15） 1.8 が正式にリリースされていた github.com アップデート or インストール（Ubuntu） d$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION="Ubuntu 14.04.1 LTS" $ $ curl -sSL https://
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
