Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Fluentdでアクセスログをゴニョった話 / Aggregating Access Logs...
Search
Shinya Tsunematsu
May 22, 2012
Technology
0
79
Fluentdでアクセスログをゴニョった話 / Aggregating Access Logs and Visualizing with Fluentd
2012/05/18 Fluentd Casual Talks #1 LT資料
Shinya Tsunematsu
May 22, 2012
Tweet
Share
More Decks by Shinya Tsunematsu
See All by Shinya Tsunematsu
GMOペパボでのSREの実践 / SRE Practices of GMO Pepabo, Inc.
tnmt
3
4.8k
ペパボサービスインフラの今までこれから / pepabo infra past and future
tnmt
3
680
知らなかった、時に困るWebサービスのセキュリティ対策 / Where Do We Start With Information Security?
tnmt
19
9.4k
IaaSをいじっている人が PaaSについて考えたこと / Should We Prepare Own PaaS?
tnmt
5
2.2k
成長を支援する “ふりかえり”の技術 / How to lockback using "furik"
tnmt
7
1.7k
こんにちわ福岡 / hello-fukuoka
tnmt
0
1.3k
Inside Nyah & Future - A case of "Private Cloud" using OpenStack -
tnmt
0
270
OpenStackクラスタ間マイグレーション事例 Havana to Mitaka / OpenStack Migration Case (Shift from Havana to Mitaka)
tnmt
1
1.2k
ペパボのプライベートクラウド "Nyah" その後 / Pepabo's PrivateCloud "Nyah" After That
tnmt
8
13k
Other Decks in Technology
See All in Technology
現場で効くClaude Code ─ 最新動向と企業導入
takaakikakei
1
260
会社紹介資料 / Sansan Company Profile
sansan33
PRO
6
380k
AIエージェント開発用SDKとローカルLLMをLINE Botと組み合わせてみた / LINEを使ったLT大会 #14
you
PRO
0
130
初めてAWSを使うときのセキュリティ覚書〜初心者支部編〜
cmusudakeisuke
1
280
TS-S205_昨年対比2倍以上の機能追加を実現するデータ基盤プロジェクトでのAI活用について
kaz3284
1
210
サラリーマンの小遣いで作るtoCサービス - Cloudflare Workersでスケールする開発戦略
shinaps
2
470
JTCにおける内製×スクラム開発への挑戦〜内製化率95%達成の舞台裏/JTC's challenge of in-house development with Scrum
aeonpeople
0
250
なぜスクラムはこうなったのか?歴史が教えてくれたこと/Shall we explore the roots of Scrum
sanogemaru
5
1.7k
スマートファクトリーの第一歩 〜AWSマネージドサービスで 実現する予知保全と生成AI活用まで
ganota
2
300
2025/09/16 仕様駆動開発とAI-DLCが導くAI駆動開発の新フェーズ
masahiro_okamura
0
110
Snowflake×dbtを用いたテレシーのデータ基盤のこれまでとこれから
sagara
0
110
EncryptedSharedPreferences が deprecated になっちゃった!どうしよう! / Oh no! EncryptedSharedPreferences has been deprecated! What should I do?
yanzm
0
480
Featured
See All Featured
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Rails Girls Zürich Keynote
gr2m
95
14k
Code Review Best Practice
trishagee
71
19k
YesSQL, Process and Tooling at Scale
rocio
173
14k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
Designing for humans not robots
tammielis
253
25k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.2k
Speed Design
sergeychernyshev
32
1.1k
Java REST API Framework Comparison - PWX 2021
mraible
33
8.8k
Into the Great Unknown - MozCon
thekraken
40
2k
KATA
mclloyd
32
14k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
Transcript
Fluentdでアクセスログを ゴニョった話 導入のTipsとか分かったこととか Fluentd Casual Talks LT Shinya Tsunematsu @tnmt
Fluentdがキテるらしい • けど使ったことない • 使い道とか何が嬉しいのか分からない • 今度Fluentd Casual Talksというのをやるらしい
お酒って怖いですね
というわけで • 初めて触ってみた俺ですが • 導入するまでと • やってみた感想を • それこそもうカジュアルにザーッとお話します •
これから始める方の参考になれば幸いです
何をしようか
30days Album 画像APIサーバのアクセスログ • 画像ストレージは複数のサービスから参照され ている • アクセスログの「分析」みたいなことは特にやっ てきていなかった •
必要に応じて手でログをゴニョる程度
やってみよう • 画像ストレージのサービスごとの利用内訳をグ ラフ化
こんな感じ ログ集約 サーバ ストレージAPI (lighttpd Catalyst) Fluentd Fluentd Growth Forecast
インストールする
rbenv + bunder が 便利 • rbenv: 複数バージョンRubyの管理ツール • システム全体に影響与えずに個人ユーザ権限
で気軽に始められる • 古いディストリでも新しいRuby使える • plugin追加もGemfileに追加してbundle install すればOK の後に画像API側はtd-agentとか fluent-agent-liteとかでも良かったなと…
rbenv入ってたらこれだけ # mkdir -p $HOME/work/fluentd # cd $HOME/work/fluentd # cat
<< EOF > Gemfile source "http://rubygems.org" gem 'fluentd' EOF # bundle install --path vendor/bundle
GrowthForecast # cd $HOME/work # git clone git://github.com/kazeburo/GrowthForecast.git # cd
GrowthForecast # sudo yum -y install cairo-devel pango-devel libxml2-devel # cpanm -l extlib Alien::RRDtool
実際の設定
送り元サーバ設定(1) # アクセスログをフォーマットでバラして <source> type tail format /^(?<host>[^ ]*) (?<vhost>[^
]*) (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^ ]*) +\S*)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)")?$/ pos_file ./pos.txt path /var/log/lighttpd/access.log tag api.access </source>
送り元サーバ設定(2) # 集約サーバに送る <match api.access> type forward flush_interval 10 <server>
name delegate host 192.168.XXX.XXX </server> </match>
集約サーバ設定(1) # ストリームを受け取って <source> type forward </source> # 適度にサンプリングして <match
api.**> type sampling_filter interval 10 remove_prefix api add_prefix sampled
集約サーバ設定(2) # サンプリングしたデータを集計して <match sampled.**> type datacounter unit minute count_key
vhost pattern1 aaa ^aaa.jp$ pattern2 bbb ^img.bbb.jp$ pattern3 ccc ^img.ccc.jp$ tag access </match>
集約サーバ設定(3) # 集計結果をGrowthForecastに投げる <match access> type growthforecast gfapi_url http://localhost:5125/api/ service
aaa section access_count name_keys sampled.access_unmatched_count,sampled.access_aaa_c ount,sampled.access_bbb_count,sampled.access_ccc_cou nt </match>
グラフ出来た
あっさり出来たすごい • 設定ファイルの行数少ない ◦ 送り元: 18 ◦ delegate: 28 •
MongoDBにつっこんだりすることなく、グラフ描 画まで終わる • pluginは tagomoris さんのものをふんだんに利 用した • というかブログに書いてあることをかいつまんで そのままやっただけ
負荷は? • 送り元サーバ ◦ ログはdaily約100万行 1台あたり 15 req/s くらい •
集約サーバ ◦ 送り元8台に対して1台 →今のところ全く問題無し
やってみた感想
手頃なログのグラフ化から始めると吉 • 既にあるログからスタート • グラフが出るとテンションが上がる(取り方が分 かる) • テンションが上がると他にも色々データが取りた くなる ◦
画像ストレージノードのレスポンスタイムにばらつきばあ るっぽいので突き止めたい
まとめ • rbenvを使うと導入お手軽(プラグイン追加とか 特に) • 簡単なデータ集計は既にあるプラグインを使う だけで色々出来る (tagomoris++) • GrowthForecastがグラフ化するのが楽すぎて
しびれる (kazeburo++) • 目に見える形でデータが出るとテンションが上 がる • グラフ化から始めて徐々に使い道を探っていく と吉ではないかと
というLTでしたがSoftware Designに もっと詳しく載ってました!