Fluentd Meetup 2016 - ServerEngine Integration & Windows supportRitta Narita
![Fluentd Hacking Guide at RubyKaigi 2014](https://cdn-ak-scissors.b.st-hatena.com/image/square/90b9a16468908951018b8a20770bcc13241f23d9/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Ffluentdrubykaigi20140920-140920115601-phpapp01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
分散パフォーマンステスト関係を書こうと思っていたんですが,よくよく考えたらMongoプラグインについて日本語でまともな記事を書いたことなかったので書きます. このエントリはウィークリーFluentdユースケースエントリリレーの参加エントリです. 概要 MongoプラグインはMongoDBに対するInput/Outputプラグインを提供します.またユーティリティとして,MongoDBのcappedコレクションに対してtailを行うmongo-tailコマンドも付属しています. リポジトリ: https://github.com/fluent/fluent-plugin-mongo MongoDBは内部はBSONですが,API的にはJSONでやりとりしており,また明示的なスキーマもいらないため,Fluentd周辺では集計サーバやテンポラリサーバとして広く利用されています. td-agentには
「BigQueryは120億行を5秒でフルスキャン可能」は本当か? 先日、kaheiさんがGoogle BigQuery(Googleクラウドの大規模クエリサービス)について、こんなエントリを書いていた。 とにかくパフォーマンスがすごい。(Fluentd Meetupでの)プレゼン中のデモで、ディスクに収められた5億件のデータをSQLでフルスキャンするのに3秒しかかからない。9億件のデータを正規表現を含んだSQLでスキャンしても、7秒で終わる(これ、記憶がちょっとあいまい。もう少しかかったかも)。これには驚いた。佐藤さんがGoogleに入社して一番驚いた技術が、一般公開される前のBigQueryだったと言っていたが、その気持ちはわかる。 From Fluentd Meetupに行ってきました これを読んだ時、BigQueryの検索スピードについてちょっと補足したくなった。確かにFluent
結構既出な内容ですが、思いっきりハマったので改めて。 ●fluentd→fluentdの通信時にfowardを使おうとしたらエラーになる。 ※追記 VMwareの場合はこっちを参考に。fluentdじゃなくてVMwareの問題というパターンもあり。 http://d.hatena.ne.jp/oranie/20121107/1352298768 中間fluentdから最終的に集約するfluentdにfowardでログを送ろうとすると、始めはちゃんと送れるのに、ちょっとするとログにエラーが出ていた。もちろん集約先の方ではログ受信出来なくなっている。 failed to flush the buffer, retrying. error="no nodes are available" もっと具体的にはこんなの。 で、理由は @oranie 死活監視にUDPのほう使うらしいのでそっちも通さない
Please provide a valid email address and we will send you a copy of the Fluentd Documentation PDF immediately. Email Download Fluentdをインストールする前に、以下の手順にしたがってお使いの環境をセットアップする必要があります。そうしなければ多くの不要な問題の原因となるでしょう。 Table of Contents NTPの設定 ファイルディスクリプタの最大値を増やす ネットワーク関係のカーネルパラメータの最適化 NTPの設定 ログ内に無効なタイムスタンプが入ることを防ぐためにノード上で ntpd を設定することを強くお勧めします。 ファイルディスクリプタの最大値を増やす ファイルディスクリプタの最大数を増やしてください。現在の数値は ulimit -n コマ
ゴクロの大平です。ごくろうさまです。 Redisは高速で、かつデータの永続化や、複数のデータ型によるストア(list,set,sorted set等)も対応しており、機能的が豊富ということから愛用者の多いKVS実装の一つだと思います。 特に私のようなアプリケーションエンジニアの人間にとってはデータ型のバリエーションの豊富さが便利さを感じる部分で、たとえばlistを用いてタイムライン的な情報や履歴情報の管理、sorted setを用いてランキング情報の管理、などのようにアプリケーションの需要の多くにRedisが対応することができます。 これらの情報を登録する際のフローとしては自作のアプリケーションから直接、というケースが多いと思いますが、せっかくFluentdのような便利なlog collector実装があるので、FluentdとRedisを組み合わせる事でカジュアルに情報の蓄積を行いたい
Fluentdを使おうと思って調べてる。 Fluentdを使うと、各種ログを集約したり、いろいろな出力先に振り分けたりが簡単にできる。 Rubyで実装されていて、gemでインストールすることができるけど、今回はRubyの実行環境も含めてパッケージ化されたtd-agentを使う。 GitHub - treasure-data/td-agent: This repository is OBSOLETE, check gh/treasure-data/omnibus-td-agent バージョンはUbuntu 12.04(precise)、Python 2.7、td-agent 0.10.35、fluent-logger-python 0.3.3。 ドキュメントがあるので、この通りでよさそう。 http://help.treasure-data.com/kb/installing-td-agen
id:tagomoris さんにお声がけいただきまして、Fluentd Casual Talks にて「fluentdでWebサイト運用を楽にする」というタイトルで発表させていただきました。 発表資料はこちら 主催者の id:tagomoris さん、会場を提供していただいた DeNA 様、いろいろ準備をしてくださった id:riywo さんはじめ多くの方々、参加してくださった100名以上の皆様、ありがとうございました!楽しかったです。 発表ではここ半年ほど Fluentd を運用して来た経験をお話ししましたが、発表内で触れなかったことで大事(?)なことがありますので以下に補遺をいくつか書いておきます。 MongoDB にログを溜めすぎない方がいいかも 太田さん (@kzk_mover) の発表内でも触れられていましたが、数千万件程度にしておいたほうがいいのでは……という実感です。 発表内
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く