in_tail+(in|out)_forwardができるログエージェントfluent-agent-hydraをGoで書いている - 酒日記 はてな支店
タイトルが長いですが、つまりそういうものをGoで書いています。 fluent-agent-hydra - Github (hydraっていうのは首のいっぱいあるアレです。キングヒドラとか) 特徴 fluent-agent-lite 的なファイルを tail -F のように追尾する機能 1プロセスで複数ファイルを追跡できます in_tail のような pos_file, parse 機能は今のところありません in_forward 的な TCP で msgpack 形式のログを受け取る機能 各種言語の logger (Ruby, Perl, Go など) から投げたログを受け取って fluentd に送り直せます JSON 形式には対応していません 簡易的なオンメモリバッファを持っています 上記から入力されたログを fluentd に送信する out_forward 的な機能 複数の送信先を
Rails4 + Fluentd + MySQL でランキング機能作ってみた - 筋肉とエンジニアリングで すべてを解決するブログ
アクセスランキングを作ってみよう！ 今、Rails4 を使ってアクセスログからランキング作ってみたいなぁーと思ってたんですが、みんなどうやってんだろうって聞いてみたところ、 Fluentd ってのを組み込むだけで簡単に集計とかできるよーって話だったので、使ってみました。 Fluentd とは まず読み方は、 「ふるーえんとでぃー」であって、「ふるーえんど」とかじゃないっぽいです。d はたぶんデーモンの d 。 色々説明面倒なんで省略しますが、ログ収集元とか出力先が簡単に設定できて、自分の欲しい形でログ保持できますよーって感じっぽい。なので、 「シェルスクリプトで処理した tail の処理結果をファイルに」「nginx から出力されたアクセスログを mongoDB に」とかそういう処理を自前で書く必要なく、簡単な設定だけでいけちゃう。 詳しくは → 柔軟なログ収集を可能にする「fluentd
Fluentdの設定を考えるときはこんなかんじで考えると便利 - Qiita
Fluentdはデータを流すのに非常に便利なツールでそこら中で使われている(個人調べ)。そのため、なんかいろんなところで設定を見るのであるが、タグに情報が付いていたりフィールドに情報がついていたりして、あれ、これどうなってるんだっけ感に襲われることがよくある。 このあたり自分でも混乱しがちなので、普段どのように考えているかだいたいまとまった気がしたところで書いておくことにした。 Fluentdのデータ構造 まずはFluentdのデータ構造を知っておいた方が良い。Fluentdの内部データはMessagePackで符号化されているが、Fluentdのデータ構造は単なるハッシュではなく、時刻(time)とタグ(tag)という属性を持っている。次のような感じだ。 レコード レコード(record)は入力されたデータそのものであり、tailプラグインであれば、tailした1行のデータに相当する。重
LINE DEVELOPER DAY 2016 開催のお知らせ « LINE Engineers' Blog
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog saegusa2017-04-16Yoshihiro was a network engineer at LINE, responsible for all levels of LINE's infrastructure. Since being named Infra Platform Department manager, he is finding ways to apply LINE's technology and business goals to the platform. こんにちは。LINEでネットワークやデータセンターを担当している三枝です。2017年1月にJANOG39で登壇する機会を頂きましたので、今回
Fluentdとログ収集のパターン - Go ahead!
「ログを集めて保存する」と言うのは簡単だけど，ログ収集の構成にはいくつか方法があり，勉強会などでちょくちょく聞かれるので，いくつかのパターンについて書く． 「俺はもうバリバリログ収集やってるぜ！」という人は多分すでに知っていることが書かれているので，タブを閉じて良い． ここではログコレクタにFluentdを想定しているが，他のログ収集プロダクトにも適用出来るはず． ただ，Fluentdはタグベースのルーティングを持ち，単体でもキューのように動作させることが可能で，既存のものより複雑な問題を解決しようとしているので，少し工夫が必要かもしれない． Fluentdそのものについては公式ドキュメントや，Fluentdとはどのようなソフトウェアなのかを参考に． クライアントから直接保存する いきなりFluentdを使わないパターン．JavaScript SDKを提供している解析サービスやモバイル端末
ログ集計／時系列DB／可視化ツールの調査結果 - Qiita
近年、自分の中で集計／可視化は Fluentd(datacounter)+Growthforecast で定番化していました。 しかしプロダクトで新たに集計／可視化の要件が出てきたことと、 最近可視化ツール周りで 「Kibanaってなんじゃ？」「Graphiteってなんじゃ？」「InfluxDBってなんじゃ？」 など、このツール達は一体何なんだろう…？というのが前々から気になっていました。 今回良い機会なので ◯◯は何をするものなのか？ というのを一つ一つ調べてみました。 いわゆる「触ってみた系」の記事なので だいぶ浅い感じです。 大分類 大きく分けると、可視化ツールは以下の３つに分けられそうです。 ログ収集/集計 時系列DB（＋API）の担当。バックエンド側。 可視化部分の担当。 今回は バックエンド と 可視化部分 に焦点を当ててみます。 バックエンド 全文検索時エンジン+Restfu
Googleの虎の子「BigQuery」をFluentdユーザーが使わない理由がなくなった理由 #gcpja - Qiita
「BigQueryは120億行を5秒でフルスキャン可能」は本当か？ 先日、kaheiさんがGoogle BigQuery（Googleクラウドの大規模クエリサービス）について、こんなエントリを書いていた。 とにかくパフォーマンスがすごい。（Fluentd Meetupでの）プレゼン中のデモで、ディスクに収められた5億件のデータをSQLでフルスキャンするのに3秒しかかからない。9億件のデータを正規表現を含んだSQLでスキャンしても、7秒で終わる（これ、記憶がちょっとあいまい。もう少しかかったかも）。これには驚いた。佐藤さんがGoogleに入社して一番驚いた技術が、一般公開される前のBigQueryだったと言っていたが、その気持ちはわかる。 From Fluentd Meetupに行ってきました これを読んだ時、BigQueryの検索スピードについてちょっと補足したくなった。確かにFluent
Fluent Dashboard＋Norikraでリアルタイムダッシュボードを7分で作る話 #dockerjp - Qiita
Fluent Dashboardって？ Fluent Dashboardは、Fluentdで集計したデータをグラフやテーブルで表示できるGoogle Spreadsheet。fluent-plugin-https-jsonを使ってイベントログを送ると、以下のようにリアルタイムにデータを表示してくれる。 使い方 詳しい使い方はREADMEにある通りで、Spreadsheetをコピーして公開設定等をポチポチするだけで準備完了。3分もかからない。あとはfluent-plugin-https-jsonのログ送信先URLとしてFluent SpreadsheetのエンドポイントURLを指定すれば動き始める。 集計ログの表示向け 任意のFluentdログを受け取ってグラフやテーブルを描けるけど、大量のログを直接受け取ることはできない。集計後のログを3秒に1回ほどの割合で受け取って表示する、といった使い
そろそろFluentd v11についてひとこと言っておくか - Go ahead!
リリースは永遠にされません！ 日本では色々なところでv11の噂がまことしやかに囁かれていますが， 俺がメインメンテナである限りv11がリリースされることはないので，諦めてv0.10.xを使ってください！ 以下まじめな話になります． v11が生まれた背景と現状 v11が生まれたのは1年以上前です．背景には，v10と呼ばれる今のバージョンがプロトタイプを兼ねたリリースであり， 「利用者のフィードバックを取り込んで，ダメな所をガッツリ書き換えて互換性を壊してメジャーバージョンアップや！」という流れがありました． しかし，v10は十分に柔軟でかつパフォーマンスも発揮しており，コミッタ陣はそれほどモチベーションがあったわけではありません． また，プラグインによって解決出来た問題も多く，v11が生まれた時ほどユーザから「v11が欲しい！」という要望は聞かれなくなりました． 当たり前ですが，ユーザからの
第3章 パフォーマンスの改善～現状を可視化し、トップダウン／ボトムアップでアプローチする | gihyo.jp
パフォーマンス面での変化 Webサービスが成長するにつれ、パフォーマンス改善を行わなければならない局面が必ず立ち現れてきます。より複雑な要求に基づく機能の追加、アクセス数の増加、データ量の増大などによるものです。本章では、筆者の勤務先であるpaperboy&co.（以下、ペパボ）での取り組みを紹介します。 まずはじめにパフォーマンス改善とは何か、どのように改善するのかという基本的な考え方について説明し、次にその考え方に基づいて取り組んだ実践の詳細について述べます。 ブクログのパブー ブクログのパブー （以下、パブー）は、ペパボの子会社であるブクログが運営する電子書籍作成・販売プラットフォームです（図1）。このサイト1つで電子書籍の作成から販売、さらには外部の電子書籍ストアへの出版すらも可能な、まさに「プラットフォーム」と言うべきサービスを提供しています。 図1 ブクログのパブー 電子
データの更新履歴をRDBMSからfluentdに流すfluent-plugin-sql - Blog by Sadayuki Furuhashi
Fluentd Advent Calendar 9日目。担当の古橋です。 Fluentd v11の情報は Fluentd Casual Talks #3 at :D でお話しすることにして、今回はFluentdの大幅な性能向上を可能にするMultiprocessプラグインを紹介…しようと思っていたら@niku4i さんに先を越されてしまったので！今回はSQL inputプラグインを紹介します。 SQL inputプラグインとは？ SQL inputプラグインは、SELECT文を定期的に実行することで、RDBMSから最近更新されたレコードや最近追加されたレコードを定期的に取り出してFluentdに流すことができるプラグインです。内部では"前回読み出したレコード"を記憶しており、前回読み出したタイミングより後になって更新/追加されたレコードを定期的に読み出します。 SQL input plug
td-agent のメモリバッファとファイルバッファでどんな違いが発生するか観察してみた - ようへいの日々精進XP
はじめに 先日、DevOps 向け Fluentd 勉強会 at IPROS で聞いた話の中で Ouptput プラグインのバッファの関して下記の点について気になったので調べたくてウズウズ。 Output プラグインのメモリバッファとファイルバッファの性能はほとんど差異は無い デフォルトはメモリバッファだがファイルバッファがオススメ また、fluent-logger を使ってサーバーの負荷が激しく上がってしまった件について質問させて頂いたがよくよく考えるとこのバッファについて全く考慮しないままの利用だったので、この件でも解決への糸口になるのではということでメモリバッファとファイルバッファで何が違うのかを調べてみた。 構成 検証環境 以下のような検証環境を用意した。 役割 バッファタイプ / Output / アプリケーション OS td-agent バージョン スペック 備考 Forwar
Fluentdの知られていない6つのこと - Boost Your Programming!
Fluentdの知られていない6つのこと 本当に知られていないかはわからないです。 公式にはあまり説明されていなかったり調べてもなかなか見つからないことが多いと個人的に思ったものを集めました。 機能や言葉の細かい説明は省いているのである程度使っている人が対象です。 out_copyはshallow copy Fluentdで最初に使うであろうビルドインされているout_copyプラグインですが、実はデフォルトではメッセージをdeep copyしないため意図しない結果になることがあります。 <match test> type copy <store> type record_modifier tag test.aa foo bar </store> <store> type retag tag test.bb </store> </match> <match test.{aa,bb}> ty
fluent-plugin-fastladderができました - laiso
いつまで目grepするつもりですか？ https://github.com/laiso/fluent-plugin-fastladder ログを購読して全行読みたいビジネスパーソンに最適のソリューションが完成しました。 これからは目tailして脳cachedから取り出すことができるでしょう。 コード 実用的なrubyコードってはじめて書いてみたのでエキスパートの人はレビューしてね。 # -*- coding: utf-8 -*- module Fluent class FastladderOutput < Fluent::Output Fluent::Plugin.register_output('fastladder', self) config_param :base_url, :string, :default => 'http://localhost:3000' config_pa
fluentdで、1つのログから複数のメトリクスを得る。 - Studio3104::BLOG.new
ウィークリーFluentdユースケースエントリリレーの記事です。 「1つのログから複数のメトリクスを得る」という目的主眼の記事です。 各プラグインの仕様や紹介していないオプションについては、他の方が書かれる記事や、作者様のブログやGitHubをご参照ください。 WEBのレスポンスタイムをグラフ化する fluentd casual talks で、fujiwaraさんが発表されたfluentdでWebサイト運用を楽にするがきっかけで、WEBのレスポンスタイムを可視化し始めた方、多いと思います。 (かなり極端な例ですが)こんなふうにグラフが出ることによって、「14:30頃からレスポンスが著しく悪くなっている！」ということが見て取れるようになります。 これによって"14:30から遅い応答が増え始めた"ということはわかるようになるのですが、「じゃあどこが遅いの？」となって結局生のログを漁ったりする
Fluentd meetup #2
20121115 オープンソースでハイアベイラビリティ！ ～クラスタ管理の設計構築ハウツー＆エンジニア思考力～Iwasaki Noboru
Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例
CEDEC 2015 IoT向け汎用protocol MQTTのリアルタイムゲーム通信利用と実装、そして未来へ…Drecom Co., Ltd.
検証中のtd-agent（fluentd）の設定とか負荷とか - mikedaの日記
せっかくなのでアクセスログ関連のところだけ抜き出してみます。 構成 概要 Fluentdを使ってWEBサーバ（APPサーバ）のアクセスログを集約サーバに集約、いくつかの処理をやってます。 要するにこの3つです。 まとめてファイルに保存する（とりあえずやってみてるだけ） TreasureDataプラットフォームにデータを送信して集計可能にする Zabbixでサービスの稼働状況を可視化する TreasureDataプラットフォームに関しては前の記事で書いたように、簡単な管理画面を作って集計テストをしています。自社フレームワーク用のライブラリも作成するつもりです。 Zabbixを使った可視化はこんな感じです。 プラグインの構成図 td-agentはサーバごとに1プロセス、できる限りシンプルでFluentdっぽい使い方を心がけてます。 負荷 2億/dayくらいのログを突っ込んでみたところ、集約サー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - mackerelio/fluent-plugin-mackerel: Fluent plugin to send metrics to mackerel.io
Fluentd でプラグインごとにログレベルを設定できるようになった件 : sonots:blog
