秒間数万のログをいい感じにするアーキテクチャAWS Summit Tokyo 2016 Developer Conference (2016/06/03)
Fluentd + ElasticSearch + Kibana3で簡単に様々なログを可視化・解析する
ISUCON本戦に参加することができてしまったため，各種ログを集めて簡単に見れると良さそうだなぁと思っていたところ，Fluentd + Elasticsearch + Kibana3の組み合わせがなかなかよさそうだったので試してみました． 本記事では，NginxのAccessLogとMySQLのSlowQueryLogを可視化してみます． Fluentdはご存知の方も多いと思いますが，Treasure Dataのメンバによって開発が進めれているオープンソースのログ収集ツールです．Fluentdに追加された様々なログデータはJSONに変換，アウトプットされます．実装はRubyで行われており，pluginを追加することでで様々なINPUT/OUTPUT先を追加することができます． Fluentdにはリアルタイムにログを収集して活用できることや，様々なログフォーマットの違いを吸収してJSONで同
fluentd+elasticsearch+kibanaの環境を構築してみた - ssossanの日記
背景 webサービスを運用してるんですが、ログをもっと有効活用しようぜ！って話になり、とりあえず手元でfluentd+elasticsearch+kibanaを使って環境を作ってみました。 アプリが入ったサーバには極力負荷をかけたくないので、パース作業は別のサーバで行いました。そのへんでいい感じにまとまってる情報が見つからなかったので、備忘録を兼ねてメモ。 サーバ構成 アプリケーションサーバ(今回はmac) -> fluentdを入れてログの送信だけやらせる。 VM(ubuntu14.04) -> fluentd, elasticsearch, kibanaを入れてログのパース〜蓄積〜表示まで。実運用では変わるだろうけどまあ練習ということで。 ハマった点・困った点 1. アプリケーションサーバからログをそのまま送信するのってどうやるんや 2. 正規表現苦手なんだけど 3. parserプラ
fluent-agent-hydraで省エネログ転送 - Mercari Engineering Blog
Site Reliability Engineering Teamの@cubicdaiyaです。 今回はGo製のログ転送エージェントであるfluent-agent-hydraとメルカリでの利用事例について紹介します。 メルカリとFluentd メルカリではAPIサーバのアクセスログやアプリケーション固有のログをはじめとする各サーバに散らばっているログデータを転送・集約するのにFluentdを活用しています。 具体的にはローカルに書き込まれるログファイルのin_tailやそれらを転送するための(out|in)_forward、ElasticsearchやBigQueryにログを放り込むためのプラグインを利用しているほか、いくつか特殊な用途のプラグインを独自に開発して運用してたりもします。 ログの流量とFluentdのパフォーマンス 多機能で柔軟なプラグイン機構を持つ便利なFluentdですが
カジュアルにMySQLスローログ可視化with Fluentd+Elasticsearch+Kibana - kikumotoのメモ帳
この記事は MySQL Casual Advent Calendar 2015 - Qiita Elasticsearch Advent Calendar 2015 - Qiita Hamee Advent Calendar 2015 - Qiita の第４日目です。 TL;DR 開発者の皆さんに、CasualにMySQLスローログを分析しもらうために、Fluentd + Elasticsearch + Kibana でMySQLスロークエリを下図のようにビジュアライズしました。（Kibana上で EXPLAIN の結果も確認できるようにしてあります） ついでに、以下の Fluentd の filter plugin を作成しました。 kikumoto/fluent-plugin-sql_fingerprint · GitHub kikumoto/fluent-plugin-mysql_e
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で既に
fluentdでつくる監視系 - Qiita
いつもアプリケーションの開発ばかりで、まじめに監視系を考えたことがなかったので、 fluentdを中心にした監視系を作ってみた。 前提 複数台のアプリケーションサーバ 一台のログ収集サーバ ログにはエラーログとアクセスログの大きく2種類を用意する エラーログは更に複数のレベルでファイル単位にわかれている fatal error warn アプリケーションサーバとログ収集サーバは同一ネットワーク上にある やりたいこと メールで来ても絶対に気がつかない自信がある。 異常の側から教えてくれる仕組みを目指す。 fatalログが出た場合は、電話による通知を行う 全てのエラーログはchatツールに出力する ログのバックアップ ログの分析・可視化 この記事では1, 2, 3についてまとめる。 構築 fluentdのインストール 公式のドキュメントが一番わかり易い。 Installation | Flue
Fluentdの現実装のPros/Cons - Go ahead!
TODO: 必要なら図を足す 他に書いた方が良いPros/Consのリクエストがあったら追記 内部のイベントストリームの扱い Pros: Inputがスケーラブルに実装しやすく，データストリームを正常時/エラー時で切り替えやすい Cons: エラーハンドリングがブロッキングモデルよりも複雑になりやすい 以下長々と理由書きます． Fluentdはイベントストリームを効率良く，またロバストに扱うことを目的に設計されています．そのため，独自の転送プロトコル(forwardプラグイン)を実装していますし，内部のイベントのハンドリングもそれに沿うようになっています．ただ，それによって相性の悪い操作とかもあります． Fluentdはバッファ機能を提供しており，これによって転送の効率化とエラー時のデータロスを防ぐ設計になっています．が，あまりにも書き込み先が遅いなどの問題があると，バッファの制限を超えて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Kibanaで秒間1万件のアクセスを可視化した話/nikkei-kibana-loganalyst2015
Dstat + Fluentd + Influxdb + Grafana - Qiita