Fluentdのお勧めシステム構成パターン2014年9月9日開催の『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！ での発表スライドです。 Read less
Docker 1.8 に Fluentd logging driver が入りました - たごもりすメモ
以前に書いた話の続きなんだけど、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で既に
DMMゲームのログ解析~ログ収集と解析の概要~ - DMM.comラボエンジニアブログ
現在オンラインゲームのバックエンド、KPIシステムを担当していますマサヨシです。 今回のブログでは【DMMオンラインゲームで実際に実装しているログとKPI】に関して3回にわたってご紹介致します。 DMMオンラインゲームでは、これまではオンラインゲームのプロジェクトごとに行っていたログの収集方法を統一し、プロジェクトに依存しない基本KPI機能とゲーム独自のKPI機能を実装するためのフレームワークを開発しましたのでその事例をもとにご紹介します。 ログ収集、解析の概要 まず、オンラインゲームのログ収集の全体像をご紹介します。 オンラインゲームのログ収集ではApacheやnginx、PHPのログをfluentdで収集しています。 fluentdに集めたログをHadoopの分散処理システムに保存し、HiveやImpalaで解析をする流れになっています。 ご存知の方も多いと思いますが、HiveとはHD
fluentdでつくる監視系 - Qiita
いつもアプリケーションの開発ばかりで、まじめに監視系を考えたことがなかったので、 fluentdを中心にした監視系を作ってみた。 前提 複数台のアプリケーションサーバ 一台のログ収集サーバ ログにはエラーログとアクセスログの大きく2種類を用意する エラーログは更に複数のレベルでファイル単位にわかれている fatal error warn アプリケーションサーバとログ収集サーバは同一ネットワーク上にある やりたいこと メールで来ても絶対に気がつかない自信がある。 異常の側から教えてくれる仕組みを目指す。 fatalログが出た場合は、電話による通知を行う 全てのエラーログはchatツールに出力する ログのバックアップ ログの分析・可視化 この記事では1, 2, 3についてまとめる。 構築 fluentdのインストール 公式のドキュメントが一番わかり易い。 Installation | Flue
並列データ転送ツール『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 とは異なり、高速性やトランザクション制御、スキーマを使ったデータのバリ
オープンソースのバルクデータローダー「Embulk」登場。fluentdのバッチ版、トレジャーデータが支援
オープンソースのバルクデータローダー「Embulk」登場。fluentdのバッチ版、トレジャーデータが支援 何ギガバイトもあるCSVをデータベースに読み込ませるようなバルクデータをバッチ処理するためのツール「Embulk」がオープンソースで公開されました。 コミッターとして開発しているのは、ログ収集ツールとして知られるfluentdなどの開発者として知られる古橋貞之氏、西澤無我氏、中村浩士氏らで、3人が所属するTreasure Dataも開発を支援しています。 古橋氏はEmbulkについて「簡単に言うとfluentdのバッチ版です」と説明。1月27日に行われた「データ転送ミドルウェア勉強会」で、Embulkの紹介を行いました。 Embulkはプラグインベースのバルクデータローダー 古橋氏はまず、例えばCSVファイルをPostgreSQLに読み込ませようとすると、CSVの日付のフォーマットが
リアルタイム集計・可視化環境(Norikra+Kibana4+Elasticsearch+Fluentd+Nginx)をfig一発で気楽に立ち上げる。 - Qiita
リアルタイム集計・可視化環境(Norikra+Kibana4+Elasticsearch+Fluentd+Nginx)をfig一発で気楽に立ち上げる。ElasticsearchDockerNorikraKibanafig このエントリーはドワンゴアドベントカレンダー17日目のエントリーです。 ストリーム処理エンジンのNorikraについて、最近聞くことが増えてきました。 使ってみたい方は結構いるのではないでしょうか。 とは言え、「ストリーム処理を試してみたい、環境構築してやってみよう」と思っても、JRuby入れてNorikra入れて、fluentd入れてNorikraとのin/outの連携して、集計結果を格納する為にElasticsearch構築して、Kibanaから見れるようにして、認証機構や改廃の機構も入れて...あ、ストリームソースも用意しなきゃ...となって、そこそこ手間が掛かりま
Google、FluentdをKubernetesとCompute Engineの標準ログコレクタに採用 - Qiita
Google、FluentdをKubernetesとCompute Engineの標準ログコレクタに採用Fluentdgooglecomputeenginekubernetesgooglecloud まずはFluentdコミュニティの皆さん、おめでとうございます！！！ Googleを中心に開発されているオープンソースのDockerジョブスケジューラKubernetes (k8s)、それにGoogle Cloud Platformのログ収集サービスGoogle Cloud LoggingのGoogle Compute Engine用ログコレクタとして、Fluentdが標準採用されました。もうひとつおまけに、fluent-plugin-bigqueryをフィーチャしたソリューションページも、あと1か月くらいでcloud.google.comにて公開される見込みです（これは私がいま仕上げ中）。
FluentdがKubernetesの標準ログ収集ツールとして採用
Googleがオープンソースとして公開したKubernetesは、コンテナ型仮想化ソフトウェアのDockerを管理するツールです。開発プロジェクトにはDocker、RedHat、IBM、VMware、マイクロソフトなど多数の企業が参加を表明しています。 Kubernetesは、複数のDockerコンテナにまとめてアプリケーションをデプロイし、設定を行い、稼働状況を監視、管理し、サービスへのトラフィックをルーティングするなど、クラスタとしてDockerを運用するための多くの機能を備えています。 このKubernetesで使われる標準のログ収集ツールとして、オープンソースのfluentdが採用されたことが明らかになりました。下記はそれを伝えるGoogle佐藤氏のツイート。 fluentdがKubernetesの標準ログコレクタに採用されたぜ！！！ https://t.co/V8VDM4IE7e
Rails4 + Fluentd + MySQL でランキング機能作ってみた - 筋肉とエンジニアリングで すべてを解決するブログ
アクセスランキングを作ってみよう！ 今、Rails4 を使ってアクセスログからランキング作ってみたいなぁーと思ってたんですが、みんなどうやってんだろうって聞いてみたところ、 Fluentd ってのを組み込むだけで簡単に集計とかできるよーって話だったので、使ってみました。 Fluentd とは まず読み方は、 「ふるーえんとでぃー」であって、「ふるーえんど」とかじゃないっぽいです。d はたぶんデーモンの d 。 色々説明面倒なんで省略しますが、ログ収集元とか出力先が簡単に設定できて、自分の欲しい形でログ保持できますよーって感じっぽい。なので、 「シェルスクリプトで処理した tail の処理結果をファイルに」「nginx から出力されたアクセスログを mongoDB に」とかそういう処理を自前で書く必要なく、簡単な設定だけでいけちゃう。 詳しくは → 柔軟なログ収集を可能にする「fluentd
Fluentdのお勧めシステム構成パターンについて発表しました - Y-Ken Studio
2014年9月9日開催の『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！にて発表してきました。 今回は「Fluentdのお勧めシステム構成パターン」というタイトルで、ユースケース毎にどのようなシステム構成をすると運用しやすいかのノウハウをお話しさせていただきました。 また、パネルディスカッションではラジオ番組のようなスタイルで、モデレータに @naoya_ito（伊藤直也氏）をお招きして行い、Kibana以前の可視化はどうしていたの？など、ざっくばらんなトークが出来てとても楽しい経験でした。 発表資料 今回は書籍に書かれた内容をざっとおさらいしつつ、システム構成パターンについて解説しました。 発表資料はSlideshareにアップしております。 Fluentdのお勧めシステム構成パターン 書籍 本書はWEB+DB Pressを取り扱う書店のほか、
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の設定を考えるときはこんなかんじで考えると便利 - Qiita
Fluentdはデータを流すのに非常に便利なツールでそこら中で使われている(個人調べ)。そのため、なんかいろんなところで設定を見るのであるが、タグに情報が付いていたりフィールドに情報がついていたりして、あれ、これどうなってるんだっけ感に襲われることがよくある。 このあたり自分でも混乱しがちなので、普段どのように考えているかだいたいまとまった気がしたところで書いておくことにした。 Fluentdのデータ構造 まずはFluentdのデータ構造を知っておいた方が良い。Fluentdの内部データはMessagePackで符号化されているが、Fluentdのデータ構造は単なるハッシュではなく、時刻(time)とタグ(tag)という属性を持っている。次のような感じだ。 レコード レコード(record)は入力されたデータそのものであり、tailプラグインであれば、tailした1行のデータに相当する。重
ログ収集や可視化で話題のFluentd、Elasticsearch、Kibanaを徹底解説したムック本が発売となります - Y-Ken Studio
2014年8月8日、ログ収集や可視化を始めたいエンジニア必携の書籍が技術評論社より刊行されます。 本邦初公開となる、全編書き下ろしの特集で構成された本書を読むことで、ログ解析の有用性からログ収集、保存、可視化手法を習得できます。 私はこの第2特集「ログ収集ミドルウェアFluentd徹底攻略」の執筆を担当しました。 サーバ/インフラエンジニア養成読本 ログ収集~可視化編 [現場主導のデータ分析環境を構築!] (Software Design plus) それでは、それぞれの特集について簡単に紹介したいと思います。 サーバ/インフラエンジニア養成読本 ログ収集〜可視化編 特集1 ログ解析からはじめるサービス改善 (鈴木 健太) 第1特集では、ログを蓄積して解析する意義とは何か、コーヒーショップのECサイトを例に、データ分析のケーススタディと共に解説されています。 第1章 はじめに 第2章 サー
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で登壇する機会を頂きましたので、今回
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
fluentdでログが欠損する可能性を考える : sonots:blog
Server::Starter を使って複数の Fluentd で１つのポートを待ち受ける : sonots:blog
Fluentd ソースコード完全解説 (v0.10向け)
excale.net
実例Javaトラブルシューティング！ 〜稼働中のシステムを立て直した半年間の軌跡
