自在にタグを書き換える fluent-plugin-rewrite-tag-filter でログ解析が捗るお話 #fluentd - Y-Ken Studio
皆様、ログ解析を行っていますか？ GoogleAnalyticsも便利ですが、表で取れないデータの解析も行いたいですよね。そんな時にfluentdが便利です。 内部の生ログからの解析が捗る、fluent-plugin-rewrite-tag-filter が安定版となりましたので、設定例を交えつつ紹介したいと思います。 このプラグインは100台規模の本番環境で1ヶ月少々、特にトラブルもなく稼働しているものです。 はじめに Amazonでは応答速度が0.1秒遅くなると売り上げが1％減る と言われているように、Webアプリケーションの応答速度はとても重要なものです。 機能追加による性能劣化は良くある話で、応答速度等の見える化を行う事で迅速な対応が取れば売り上げ等への影響も軽微です。 パフォーマンス改善等の指標として利用する場合のユースケースを紹介したいと思います。 fluentdとは リアルタ
LXCベースのDockerとホストマシンのディスクI/O性能を比較検証（Bonnie++編） - Y-Ken Studio
dotCloudが開発しているLinuxコンテナ型仮想ソフト「Docker」が巷で話題ですね！ これはLXCにストレージドライバとしてunionfsから派生したaufs（CentOSではLVMのThin Provisioning）を組み合わせた所がキモで、つまりファイルシステムの差分管理が出来る特徴があります。 なんだか仕組みを想像する限りディスクI/Oが遅そうな印象ですが、どの程度のものかベンチマークを取りました。 ストレージドライバ Dockerは元々aufsで作られていたのですが、それはAUFS対応のカーネルを入れる前提です。 これはRedHat系ディストリビューションへの対応を行う上での大きなハードルでした。 そこで同様にCoW(CopyOnWrite)を実現出来るLVMのThin Provisioningが採用されています。 ドライバがaufsなのかLVMを扱うためのdevice
FluentdでURL付きツイートを漏れなく収集する方法 - Y-Ken Studio
Twitterで言及されている様々な記事のURLを収集したいと考えた時、次の方法が選択肢となります。 定期的にAPIを叩く ストリーミングAPIを使う 前者の方法では単位時間毎のAPIコール制限を容易に超えてしまうので避けたいところですね。 そこでストリーミングAPIを使いたい所ですが、URLのトラッキングを行う方法がわかりにくかったので調べてみました。 ストリーミングAPIでのURLトラッキング方法 その方法は意外なほどシンプルでした。 ドットやスラッシュなどの記号を半角スペースにして、コンマに並べるというものです。 例えば、"example com"と指定すると、次のパターンにマッチします。 example.com www.example.com foo.example.com foo.example.com/bar I hope my startup isn’t merely ano
実は簡単なFluentdプラグインのv1-config対応テストの書き方 - Y-Ken Studio
Fluentd Advent Calendarの4日目は、Fluentdプラグインを数多くメンテナンスする@yoshi_kenがお届けします。 Fluentdはその拡張性の高さから、数多くのプラグインがリリースされております。 これをご覧になる方の中には、プラグインを自作された方もいらっしゃるかもしれません。 本日はこれからプラグインを書かれる方にも、既に自作プラグインを公開されている方にも便利なTipsをお届けします。 さて、設定ファイルの記法が拡張された、V1 Format環境下での動作を保証するためのテストコードの準備はいかがでしょうか。 筆者自身がメンテナンスするプラグインもこれから対応を進めていくといった状況です。 手を付ける前は実装の仕方は意外と大変なのでは無いかと不安でしたが、実際はとても簡単です。 STEP-1 : 既存のconfigureメソッドを拡張する configu
Fluentdのお勧めシステム構成パターンについて発表しました - Y-Ken Studio
2014年9月9日開催の『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！にて発表してきました。 今回は「Fluentdのお勧めシステム構成パターン」というタイトルで、ユースケース毎にどのようなシステム構成をすると運用しやすいかのノウハウをお話しさせていただきました。 また、パネルディスカッションではラジオ番組のようなスタイルで、モデレータに @naoya_ito（伊藤直也氏）をお招きして行い、Kibana以前の可視化はどうしていたの？など、ざっくばらんなトークが出来てとても楽しい経験でした。 発表資料 今回は書籍に書かれた内容をざっとおさらいしつつ、システム構成パターンについて解説しました。 発表資料はSlideshareにアップしております。 Fluentdのお勧めシステム構成パターン 書籍 本書はWEB+DB Pressを取り扱う書店のほか、
ログ収集や可視化で話題のFluentd、Elasticsearch、Kibanaを徹底解説したムック本が発売となります - Y-Ken Studio
2014年8月8日、ログ収集や可視化を始めたいエンジニア必携の書籍が技術評論社より刊行されます。 本邦初公開となる、全編書き下ろしの特集で構成された本書を読むことで、ログ解析の有用性からログ収集、保存、可視化手法を習得できます。 私はこの第2特集「ログ収集ミドルウェアFluentd徹底攻略」の執筆を担当しました。 サーバ/インフラエンジニア養成読本 ログ収集~可視化編 [現場主導のデータ分析環境を構築!] (Software Design plus) それでは、それぞれの特集について簡単に紹介したいと思います。 サーバ/インフラエンジニア養成読本 ログ収集〜可視化編 特集1 ログ解析からはじめるサービス改善 (鈴木 健太) 第1特集では、ログを蓄積して解析する意義とは何か、コーヒーショップのECサイトを例に、データ分析のケーススタディと共に解説されています。 第1章 はじめに 第2章 サー
elasticsearchを全文検索サーバとして活用するなら読んでおきたい、6つのブログ記事をピックアップ（追記あり） - Y-Ken Studio
LuceneベースのNoSQL全文検索サーバ、elasticsearchはログ解析の収集先として取り上げられることが多いですが、優れたNoSQL全文検索サーバでもあります。 日本でも2013年末頃から続々とブログ記事や利用事例が増えている注目の技術でもあります。 今回は、その中で全文検索サーバとしての切り口で分かりやすく解説された6つの記事を紹介します。 （追記）Hello! Elasticsearch. — Medium ナレッジワークス株式会社のKunihiko Kidoさんによるとても分かりやすい記事です。 https://medium.com/hello-elasticsearch 2014年4月に入ってから怒濤の勢いでこれらのステキな記事が追加されています。 Elasticsearch Features — 主にシステムを中心とした特徴まとめ Elasticsearch Quic
Fluentd+Elasticsearch+Kibana構成で便利な、logstash形式インデックスの粒度をカスタマイズする方法 - Y-Ken Studio
fluent-plugin-elasticsearchやKibanaのデフォルトであるlogstash形式では、年月日毎にインデックスを作成されて使われることを想定されています。 これは扱いやすいのですが万能では無く、次のような状況ではパフォーマンス的な観点で、このインデックスの粒度を変更することを検討すると良いケースがあります。 粒度を細かくしたいケース（時間単位） 日毎のインデックス作成では、elasticsearchに割り当てたメモリ量を超えてしまう 粒度を荒くしたいケース（週単位/月単位/年単位） 日毎のインデックス作成では容量が小さく、日常的に検索する範囲が複数のインデックスに渡るとき Kibanaは年月日以外の粒度（時間・日・週・月・年）にも対応していますので、変更することも容易です。これは次の2つの設定変更で適用できます。 ログ収集を行うElasticsearchへ流し込む、
MySQLでMyISAMからInnoDBに乗り換える際に知らないとハマる、怖い話 - Y-Ken Studio
photo by byte MySQLといえば、巷ではInnoDBばかり注目され、MyISAMの地下アイドル化がにわかに語られる今日この頃、皆様いかがお過ごしでしょうか。 まあカジュアルにストレージエンジンを変換するだけで済むなら、簡単なのです。 -- legacy_my_tableをInnoDBストレージエンジンに変換する ALTER TABLE legacy_my_table ENGINE=InnoDB; よし終わった！さあランチタイムだ！ ・・・と片付けてしてしまうと、悲劇が起こるかもしれません。(>o<;) それでは本日、MyISAMからInnoDBへ移行するなら知っておきたい意外な落とし穴とTipsを紹介します。 AUTO INCREMENTの挙動が違う落とし穴 以下に該当するクエリを利用している場合には、注意が必要です。私はハマりました。 INSERT IGNORE INTO
Fluentdが流行る理由がいま分かる、10の実践逆引きユースケース集 - Y-Ken Studio
ログデータを活用してビジネスに役立てようという最近のトレンドは理解できる。 しかし、なぜログ収集ソフトウェアのFluentdがこれほどまで話題になるのか、不思議に感じている方もいるのではないだろうか。単にログデータを収集するならばsyslog-ngやrsyslogで十分ではないかという意見もあるだろう。 それらは既存のログシステムを置き換えるプロダクトであり、Fluentdのそれとは根本的に異なる。Fluentdは、既存のログシステムに手を入れることなく新たにログの収集を行い、ストリームデータ処理を実現するプロダクトなのである。 一般的にログデータはサーバの数だけ分散しており、それを定期実行処理で収集するということだけでも、なかなか骨の折れる仕事である。さらに集めるだけでなく、日々増え続けるログデータを活用できる形に加工してしかるべきデータストアに保管するということに挫折した方もいるのでは
MySQL-5.5/5.6でのレプリケーション利用者に伝えたい「RESET SLAVE」にまつわる怖い話 - Y-Ken Studio
MySQL-5.5よりRESET SLAVE;の挙動が変わり、直後にCHANGE MASTER構文を 発行しないと場合によっては問題が発生するとMySQLのドキュメントに記載されていました。 さらに、RESET SLAVE ALL;というクエリもサポートされたようです。 どういう事なのでしょう？ 調べてみました。 ドキュメントにさらっと何か書いてある In MySQL 5.6 (unlike the case in MySQL 5.1 and earlier), RESET SLAVE does not change any replication connection parameters such as master host, master port, master user, or master password, which are retained in memory. Thi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
