Fluentdの現実装のPros/Cons - Go ahead!
TODO: 必要なら図を足す 他に書いた方が良いPros/Consのリクエストがあったら追記 内部のイベントストリームの扱い Pros: Inputがスケーラブルに実装しやすく，データストリームを正常時/エラー時で切り替えやすい Cons: エラーハンドリングがブロッキングモデルよりも複雑になりやすい 以下長々と理由書きます． Fluentdはイベントストリームを効率良く，またロバストに扱うことを目的に設計されています．そのため，独自の転送プロトコル(forwardプラグイン)を実装していますし，内部のイベントのハンドリングもそれに沿うようになっています．ただ，それによって相性の悪い操作とかもあります． Fluentdはバッファ機能を提供しており，これによって転送の効率化とエラー時のデータロスを防ぐ設計になっています．が，あまりにも書き込み先が遅いなどの問題があると，バッファの制限を超えて
TrailDashでCloudTrailを可視化する | DevelopersIO
はじめに 皆さん、CloudTrail使ってますか？AWSアカウントのAPI呼び出しを記録しログとして保存するCloudTrailは、とりあえずデフォルトで有効にしても良いほど、監査証跡の観点で有用なサービスです。 しかしそのログはgz圧縮されたJSONファイルなので、正直人間の目でチェックするには厳しいものがあります。様々なパートナーベンダがCloudTrailを可視化するソリューションを提供していますが、商用プロダクトはなかなか簡単に試すことはできません。 そんな中、AWSのChief EvangelistであるJeff Barrのtweetで面白そうなものを知りました。 Traildash is an #AWS Cloudtrail dashboard - http://t.co/58fjvreh9v - nice work, @AppliedTrust ! pic.twitter.
スマートニュースの世界進出を支えるログ解析基盤 #jawsdays #tech
スマートニュースは昨年の 10/1 に米国版をローンチするにあたり、ログ解析基盤のリニューアルを行いました。日本に加えて米国やその他の国が入ってくることにより、単なるユーザ数の増加に加え、OS x 国 x タイムゾーン x 多種多様なメトリクスのような集計軸が増えることで、ログの前処理、集計、可視化に様…
OSSEC ではじめるセキュリティログ監視 - クックパッド開発者ブログ
インフラストラクチャー部の星 (@kani_b) です。 Heartbleed, ShellShock, XSA-108 (a.k.a. EC2 インスタンス再起動祭), POODLE など、今年は話題となるような脆弱性が各地を襲う一年でした。 脆弱性への対応に加え、いわゆるセキュリティ対策に日頃頭を悩ませている方も多いのではないかと思います。 一言にセキュリティ対策と言っても、実際やるべきことは多岐にわたります。今回はそのうちの一つとして、OSSEC という IDS (侵入検知システム) を使ったセキュリティログ監視についてご紹介します。 OSSEC とは OSSEC は、いわゆるホスト型の IDS (HIDS) です。以下のような機能を持っています。 ログ解析、監視 ファイルの変更監視 rootkit の検知 それらをトリガにしたプログラムの自動実行 (Active Response)
Fluentdのロギング - Qiita
Fluentdの公式ドキュメントにloggingのページがあるんですが，まだ英語しかなく，運用の話を聞いてるとここに書いてあることで解決出来るケースがいくつかあったので，とりあえず日本語で記事にしておきます． プラグイン毎のログレベル 昔のFluentdはグローバルに一つしかログレベルを設定出来なかったんですが，今ならプラグイン毎に設定出来ます．プラグインが対応している必要がありますが，まぁ今時のプラグインや広くつかわれているやつはほとんど対応していると思います． in_tailプラグインはログにマッチしない行があったらwarnでメッセージを出しますが，そういうbrokenな行があることが分かっていてログを出さずに無視して欲しい，というような場合に有効です． その他にも，あるプラグインだけデバッグモードで走らせたい，みたいなことが出来るようになります． ログのスタックトレースの抑制 Flu
PostgreSQLのログをFluentdで収集する
データベースの運用管理にログの情報は不可欠ですが、オープンソースのDBMSであるPostgreSQLが出力するログは、直接取り扱うのに適した形式とは言えません。そこで本記事では、オープンソースのログ収集ツールであるFluentdを使って、PostgreSQLのログを運用管理に活用しやすい形に加工する方法を紹介します。 PostgreSQLの運用管理に使う稼働統計情報とログ データベースを安定稼働させるには、データベースを健全な状態に保つ運用管理が必要不可欠です。データベースの運用管理には一般的に死活監視、リソース監視、性能分析、チューニング、バックアップといった項目が挙げられますが、まずは監視によって正しく現状を把握することが、運用管理の第一歩と言えるでしょう。PostgreSQLで監視に使える機能には、稼働統計情報とログがあります。稼働統計情報はPostgreSQLの様々な稼働情報を蓄積
Fluentdのお勧めシステム構成パターンについて発表しました - Y-Ken Studio
2014年9月9日開催の『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！にて発表してきました。 今回は「Fluentdのお勧めシステム構成パターン」というタイトルで、ユースケース毎にどのようなシステム構成をすると運用しやすいかのノウハウをお話しさせていただきました。 また、パネルディスカッションではラジオ番組のようなスタイルで、モデレータに @naoya_ito（伊藤直也氏）をお招きして行い、Kibana以前の可視化はどうしていたの？など、ざっくばらんなトークが出来てとても楽しい経験でした。 発表資料 今回は書籍に書かれた内容をざっとおさらいしつつ、システム構成パターンについて解説しました。 発表資料はSlideshareにアップしております。 Fluentdのお勧めシステム構成パターン 書籍 本書はWEB+DB Pressを取り扱う書店のほか、
サービス改善とログデータ解析について発表してきました - すずけんメモ
『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』の出版記念イベントで発表してきました。会場を提供していただいたGMOのみなさま、主催のTreasure Data / 技術評論社のみなさま、そして聴きに来てくださった方々、どうもありがとうございました。 http://eventdots.jp/event/137658 各特集の著者によるそれぞれの特集の導入が前半にあり、後半はnaoyaさんとのパネルディスカッションがありました。 サービス改善はログデータ分析から from Kenta Suzuki 養成読本、おかげさまで多くの方に読んでいただいており、嬉しい限りです。僕のところは導入の章ということで、「なぜログの分析をするのか？」という点に絞って発表しました。内容としてはざっくりいうと、 ElasticsearchやFluentdを使いつつも、何をやりたいかによって使うツールは変え
ログ集計／時系列DB／可視化ツールの調査結果 - Qiita
近年、自分の中で集計／可視化は Fluentd(datacounter)+Growthforecast で定番化していました。 しかしプロダクトで新たに集計／可視化の要件が出てきたことと、 最近可視化ツール周りで 「Kibanaってなんじゃ？」「Graphiteってなんじゃ？」「InfluxDBってなんじゃ？」 など、このツール達は一体何なんだろう…？というのが前々から気になっていました。 今回良い機会なので ◯◯は何をするものなのか？ というのを一つ一つ調べてみました。 いわゆる「触ってみた系」の記事なので だいぶ浅い感じです。 大分類 大きく分けると、可視化ツールは以下の３つに分けられそうです。 ログ収集/集計 時系列DB（＋API）の担当。バックエンド側。 可視化部分の担当。 今回は バックエンド と 可視化部分 に焦点を当ててみます。 バックエンド 全文検索時エンジン+Restfu
fluentdでnginxのログをElasticsearchとBigQueryに保存するお話 - ハウテレビジョンブログ
こんにちは。夏休みに長野に行って居酒屋で馬刺しをたらふく食べていたら 地元のおっさん人生の大先輩の絡み酒に付き合わされた祖山です。 4月に入社して以降、サーバサイドのWeb開発やスクラムの導入、サイト内検索の改善など様々な業務に 取り組んでいますが、最近の大きな案件としては、アクセスログ解析基盤の整備がありました。 nginxのアクセスログを分析しやすい環境を作るため、ElasticsearchとBigQueryにログを蓄積し始めたのですが、 その際に一番のキモとなるのは、みんな大好きfluentdです。 今回は、我々ハウテレビジョンがどのようにアクセスログを収集、保存しているのかについて、fluentdの設定を中心にご紹介します。 アクセスログ収集の目的 現在の我々のサービス環境を考慮すると、アクセスログの収集には下記2つの目的が存在します。 アクセス情報をもとにユーザーの行動を解析 閲
Fluentdとログ収集のパターン - Go ahead!
「ログを集めて保存する」と言うのは簡単だけど，ログ収集の構成にはいくつか方法があり，勉強会などでちょくちょく聞かれるので，いくつかのパターンについて書く． 「俺はもうバリバリログ収集やってるぜ！」という人は多分すでに知っていることが書かれているので，タブを閉じて良い． ここではログコレクタにFluentdを想定しているが，他のログ収集プロダクトにも適用出来るはず． ただ，Fluentdはタグベースのルーティングを持ち，単体でもキューのように動作させることが可能で，既存のものより複雑な問題を解決しようとしているので，少し工夫が必要かもしれない． Fluentdそのものについては公式ドキュメントや，Fluentdとはどのようなソフトウェアなのかを参考に． クライアントから直接保存する いきなりFluentdを使わないパターン．JavaScript SDKを提供している解析サービスやモバイル端末
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IPA、サーバーログを解析して攻撃の痕跡を検出する「iLogScanner」v4.0を無償公開
サービス改善はログデータ分析から