CloudNativeCon Europe 2017に行ってきた＆しゃべってきた - たごもりすメモ
うぎゃあ、これ今年の初エントリなのか。なんてこった。 で、FluentdがめでたくCNCF (Cloud Native Computing Foundation)に加わって初めてのCloudNativeConなので、Treasure DataのOSSチームで都合のつく人みんなで参加してきたというやつ。前夜祭的なところで同僚の Eduardo がKeynoteをやったり、Fluentd Salonという枠がつくられてFluentd関連の話をしたり。 自分はそれとは別にTalk proposalを出していて通っていたので、それを話しに行く、というのが個人的には最大の目的。 しゃべってきた セッションはカンファレンス2日目、全体でいちばん最後の時間枠。正直話すのが終わるまで気が抜けないからあんま好きじゃないんだけど、とりあえず、やるだけはやった。けっこう多い人が来てくれて席がぜんぶ埋まる(70人
TreasureDataの2015年を新機能で振り返る - Qiita
普段トレジャーデータでサポートしてる@nora96oです。 今回は、Treasure Data Advent Calendar 2015の10日目の記事です。 去年は、TreasureDataの1年半を機能面で振り返るという記事を12月に書いたので、今年も2015年を振り返ってみます。 Streaming Import Fluent Bit Fluentd Bitという組み込みLinux向けにC言語で書き直された軽量のFluentdをリリースしました。 MQTTやXbee Input Pluginを持っていてIoT向けのFluentdといったところです。 ちなみにMailing ListやSlackなどもあって、興味があれば参加してみていただけると嬉しいです。 メインメンテナのEduardoが喜びます。 Slack: http://slack.fluentd.org Mailing lis
BigQueryのstreaming insertでログが欠損する - Qiita
3千万件送信して、2605件のログが欠落した。 今回の調査ではここまでになった。 BigQueryはログを取り入れてからは素晴らしいけど、まずログを取り入れる部分で不安がある。td-agentを使わなければ良いのかもしれないが、そうするとログ収集システムを自前で構築せねばならず非効率である。 googleはfluetdをGCEなどの標準ログコレクターにしたのだから、bigqueryプラグインについても手を加えてくれても良いかも知れない。 TreasureDataへ、並列送信 後半は、TreasureDataへも並列で送信を行った。一番最後に一千万件のログを送信した際には、TreasureData,BigQuery両方共ログ欠損はなかった。 TreasureDataの設定は特に何もしなくても、ログ欠損が起こらないのが素晴らしい。 ログ欠損とデータ分析 今回の調査ではfluent-plugin
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の弱点を
Pascal〜Puree + ngx_lua + Fluentd + BigQueryでつくるメルカリのログ分析基盤〜
Pascal〜Puree + ngx_lua + Fluentd + BigQueryでつくるメルカリのログ分析基盤〜 Backend Author: cubicdaiya エンジニアではなくプログラマと呼ばれたい@cubicdaiyaです。今回はメルカリのログ分析基盤のお話です。 メルカリにおけるログデータ分析 メルカリでは初期の頃からログデータの分析をサービスの成長にとって重要なタスクとして位置づけ、そのための基盤作りに取り組んできました。ログの種類はいくつかありますが、中でも代表的なのがアプリケーションサーバで出力されるアクセスログやアプリケーション固有のログです。これらのログはサイズが大きいので効率良くログデータを転送するための工夫が必要になります。そこで活躍するのがFluentdです。 大雑把に説明するとアプリケーションサーバで出力されたログはFluentdから最終的にBigQu
Norikra meetup #2で発表してきました #norikra - BLOG::はるかさん
Norikra meetup #2でNorikraをログ解析に使うというごくごく一般的な内容の発表をしてきました。主催の@tagomorisさん、会場を提供頂いた:DeNAさん、皆様ありがとうございました。1年前に導入を検討し始めて、別に特段変わったこともしてないし、すごくヘビーに使っている訳でもないので、ゆるくまとめようとおもったらかなり時間余ってしまいました…… speakerdeck.com 最初MongoDBのcapped collectionに入れていたのが、Elasticsearch/Kibanaが流行してElasticsearchが全文検索以外に使われ出したり、ログ解析のトレンドはすごい勢いで変わってきているように感じます。Stream processingを行う方法にはFluentdのプラグインを用いる方法がありましたが、使っているfluent.confの中にfluent-
fluentdで本番環境を再現する - Qiita
toyama0919/fluent-plugin-http_shadowというShadow Proxyっぽいことを簡単にやるプラグインを作りました。 production環境で半年くらい動かしてたのでメモしときます。 「Fluentd Meetup 2015 夏」で実際のユースケースを発表しました。 Shadow Proxyサーバとは Shadow Proxyサーバについては以下がわかりやすいです。 気軽なMySQLバージョンアップ - まめ畑 Go言語を含む複数種類の言語により実装されたソフトウェアのベンチマーク - Qiita 実装としては以下のようなものが公開されています。 cookpad/kage lestrrat/p5-Geest kentaro/delta 本番のリクエストをそのままバックエンドにあるサーバーに複製して送信するのですが、アプリケーションの規模が大きくなればなるほ
並列データ転送ツール『Embulk』リリース！ - Blog by Sadayuki Furuhashi
こんにちは。古橋です。 先日の*1 データ転送ミドルウェア勉強会で、新しいオープンソースツール Embulk をリリースしました。 Embulk, an open-source plugin-based parallel bulk data loader from Sadayuki Furuhashi Embulk は、リアルタイムなログ収集では常識となった fluentd のバッチ版のようなツールで、ファイルやデータベースからデータを吸い出し、別のストレージやデータベースにロードするためのコンパクトなツールです。 fluentd と同様にプラグイン型のアーキテクチャを採用 しているため、RubyやJavaで簡単なコードを書くことで、様々なファイルフォーマットやストレージに対応することができます。一方で fluentd とは異なり、高速性やトランザクション制御、スキーマを使ったデータのバリ
「データ転送ミドルウェア勉強会」レポート #dtm_meetup | DevelopersIO
こんにちは、虎塚です。 1月27日(火)に「データ転送ミドルウェア勉強会」に参加してきましたのでレポートします。イベントは、SAPジャパンさんで開催されました。 今回のテーマは、まず、当日リリースされたばかりのOSSツールEmbulkの解説、次に、データ転送業界のドンHULFTの紹介、そして、今年リリース予定のfluentd v1について、最後に、HTTP/1とHTTP/2両対応のHTTPサーバH2Oの紹介でした。盛りだくさんですね。 懇親会ではトレジャーデータさんからピザが提供されました。SAPジャパンさん、トレジャーデータさん、ありがとうございます。 データ転送ミドルウェア勉強会 - dots.[ドッツ] 「バルクデータロードツール『Embulk』リリース 〜 fluentdの柔軟性と堅牢性をバルクでも」 最初のセッションは、トレジャーデータの古橋貞之さんによるEmbulkの思想やアー
Fluentd update 2014 - Qiita
毎年恒例1年のまとめ記事です．2014年はFluentdの飛躍の年でもあったので，エコシステム周りも含め色々と紹介したいと思います． 2014年は0.10.43から始まり，v0.10の最新版は0.10.57，v0.12が開発版としてpre2までリリースされています．v0.12に関しては13日，v1を含めた来年の開発に関しては25日に書く予定です． Fluentd本体 すべてを列挙するのは難しいので，すべてを見たい方はChangeLogを参照してください．ここでは特に運用やプラグイン周りで有用なものをピックアップします． プラグイン毎のlog_levelオプション (0.10.43) グローバルなレベルとは別に，各プラグイン毎にログレベルを設定出来る機能です．詳細は以前書いたFluentdのロギングを参照してください． sigdump (0.10.43) sigdumpが同梱されるようになり
プラグインを書く | Fluentd
Please provide a valid email address and we will send you a copy of the Fluentd Documentation PDF immediately. Email Download Table of Contents カスタムプラグインをインストールする インプットプラグインを書く バッファドアウトプットプラグインを書く Time Slicedアウトプットプラグインを書く ノンバッファドアウトプラグインを書く Tailインプットプラグインパーサーをカスタマイズする デバッグプラグイン テストケースを書く 参考文献 カスタムプラグインをインストールする プラグインをインストールするために、/etc/fluent/pluginディレクトリにrubyスクリプトを配置してください。 あるいは、lib/fluent/plugin
Fluentdの設定を考えるときはこんなかんじで考えると便利 - Qiita
Fluentdはデータを流すのに非常に便利なツールでそこら中で使われている(個人調べ)。そのため、なんかいろんなところで設定を見るのであるが、タグに情報が付いていたりフィールドに情報がついていたりして、あれ、これどうなってるんだっけ感に襲われることがよくある。 このあたり自分でも混乱しがちなので、普段どのように考えているかだいたいまとまった気がしたところで書いておくことにした。 Fluentdのデータ構造 まずはFluentdのデータ構造を知っておいた方が良い。Fluentdの内部データはMessagePackで符号化されているが、Fluentdのデータ構造は単なるハッシュではなく、時刻(time)とタグ(tag)という属性を持っている。次のような感じだ。 レコード レコード(record)は入力されたデータそのものであり、tailプラグインであれば、tailした1行のデータに相当する。重
Fluentular: a Fluentd regular expression editor
Regular Expression Test String Custom Time Format (See also ruby document; strptime) Example (Apache) Regular expression: ^(?<host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^ ]*) +\S*)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)")?$ Time Format: %d/%b/%Y:%H:%M:%S %z
ログ集計システムを自前で作る - Y's note
Index ログ集計システムの要件 DB設計 データ保存方針 table設計 サーバ構成 Fluentd fluentd,fluent-plugin-mysql-bulk install td-agent.conf mysqlにデータが格納される事を確認する 集計用のバッチ その他 Table肥大化防止 可視化 ログ集計システムの要件 爆弾ログ処理班の@yutakikuchi_です。 ログ集計システムというものを作る時に皆さんはどのように対応していますか？ 以下の候補から要件のレベルで使い分けをしている人が多いと予想しています。ざっくりの評価ですが、導入難易度、正確性、可視化、リアルタイム、長期集計、スケール、運用費用という点で評価を書いています。 ツール 導入難易度 正確性 可視化 リアルタイム 長期集計 スケール 運用費用 リンク GA(スタンダード) ○ × ○ ○ ○ ○ ○ Go
fluentdで集約したerror_logをslackに流すと捗る - UNIX的なアレ
nanapiでは社内のチャットツールに、Slackを導入しています。Slackの便利なところはintegration周りで、要するに他のツールとの連携が非常にし易いんですね。そういった、Chatを中心にした業務効率化を最近ではChatOpsと呼んだりします。 http://nanapi.co.jp/blog/2014/07/24/nanapi_chatops/ ChatOpsの重要な点はコンテキストを共有できる点ですよね。「○○ってエラーログが出てるよ」みたいな情報を直接誰かに伝えるのではなく、ログが出ているという状態をChatを経由して同じものを見ることで、説明が非常にラクになります。 ほかにもデプロイをHubot経由で指示したり、ステータス取得をしたりなど様々な使い方がありますがやはり重要なのは同じ画面を皆が見ているということですね。そういった点がChatOpsの大きなメリットとしてあ
Fluentdとログ収集のパターン - Go ahead!
「ログを集めて保存する」と言うのは簡単だけど，ログ収集の構成にはいくつか方法があり，勉強会などでちょくちょく聞かれるので，いくつかのパターンについて書く． 「俺はもうバリバリログ収集やってるぜ！」という人は多分すでに知っていることが書かれているので，タブを閉じて良い． ここではログコレクタにFluentdを想定しているが，他のログ収集プロダクトにも適用出来るはず． ただ，Fluentdはタグベースのルーティングを持ち，単体でもキューのように動作させることが可能で，既存のものより複雑な問題を解決しようとしているので，少し工夫が必要かもしれない． Fluentdそのものについては公式ドキュメントや，Fluentdとはどのようなソフトウェアなのかを参考に． クライアントから直接保存する いきなりFluentdを使わないパターン．JavaScript SDKを提供している解析サービスやモバイル端末
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fluentd ソースコード完全解説 (v0.10向け)
fluentdでログが欠損する可能性を考える : sonots:blog
今日から始める PHPエンジニアのためのアクセスログ解析基盤構築入門
Fluentd ソースコード完全解説 at RubyKaigi2014 : sonots:blog
