More Related Content
Similar to Logにまつわるエトセトラ (20)
More from leverages_event (20)
Logにまつわるエトセトラ
- 3. 3
話しません (´;ω; ` )
● GrowthHack
✔
Retention/ConversionUP 施策
✔
A/B テストによる UI 改善
●
可視化
✔
BI ツール
- 10. 10
Log や Data を軽視する人
/)
///)
/ ,.= ゙ ''" /
/ i f ,.r='"-‐' つ_
/ / _,.-‐'~ /⌒ ⌒\
/ ,i , 二ニ⊃( ●) . (●)\
/ ノ il ゙フ ::::::⌒ ( __ 人 __ )⌒ ::::: \
, イ「ト、 ,!,!| |r┬-| |
/ i トヾヽ _/ ィ " \ ` ー '´ /
Log はどうでもいいんだよ !!
- 11. 11
Log や Data 取得が後回しにされる理由
●
サービスの開発が最優先
●
無くてもサービスは動く
●
LogSystem の開発は簡単という誤解 ( 怒 )( 怒 )( 怒 )
●
UserData を取得すると User の入力負荷が高くなる
●
Data 分析方法が分からない
- 19. 19
LogFormat
●
Default
::1 - - [08/Feb/2014:21:32:10 +0900] "GET / HTTP/1.1" 403 5039 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2"
●
Labeled Tab-Separated Values(LTSV)
host:::1<Tab>ident:-<Tab>user:-<Tab>time:[08/Feb/2014:21:32:10 +0900]<Tab>Request:GET / HTTP/1.1<Tab>status: 403
<Tab>size:5039<Tab>referer:-<Tab>agent:curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3
libidn/1.18 libssh2/1.4.2
●
ControllCharcter Separeted Values
host<^B>::1<^A>ident<^B>-<^A>user<^B>-<^A>time<^B>[08/Feb/2014:21:32:10 +0900]<^A>Request<^B>GET /
HTTP/1.1<^A>status<^B> 403 <^A>size<^B>5039<^A>referer<^B>-<^A>agent<^B>curl/7.19.7 (x86_64-redhat-linux-gnu)
libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
- 20. 20
どの Format が良いか?
●
Log 項目の付け足し / 削除は後から必ず発生する
●
Parse 後の添字参照 ( 順番依存 ) はキツい
●
Parse 後に連想配列 (key => value) 展開する
●
付け足しが発生しても順番依存が無い
●
人目で見ても項目が分かり易い
LTSVFormat がお勧め
- 21. 21
ServerLog の種類と記録項目
1. AccessLog
– Request 時間 (When), RequestURI(What), Access 元 IP, UA, Referer(How)
– 処理時間 , ResponseStatus
– Cookie(Who)
●
BrowserID
●
UserID
●
UserAttribute
– DeviceID(Who)
2. ErrorLog
– Request 時間 , RequestURI, UA, Cookie
– ErrorLevel, ErrorFile&Line, ErrorComment
3. ApplicationLog
– 特定の状況下で記録したい Data
- 24. 24
「 mod_oreore 」による BrowserID 発行
●
Server への初回アクセス時に Cookie を発行する
●
ApacheModule だから楽
●
mod_usertrack,mod_session_cookie の不足点をカバー
●
https://github.com/yutakikuchi/apache_module.git
●
30 秒で設定可能
- 28. 28
PV, Imps, Click, ConversionLog
⑤Staus:302
Location:Url
①Request
② HTML,PVBeaconURL
③BeaconRequest
④Click⑥Buy
⑦HTML,ConversionBeaconURL
⑧ConversionRequest
WebServer
PV/ImpBeacon
ClickRedirector広告主 Server
ConversionBeacon
- 31. 31
導入した Click 検知方法
●
外部 Domain への遷移検知には Redirector を入れる
●
Log にどのページのどのリンクが押されたのか記録する
✔ 予約 Parameter(?__uri=hoo&__link=bar_1)
✔ Click 計測用 Cookie(ClickCookie:__uri=hoo&__link=bar_1)
✔ ※Referer は送信しないブラウザがあるので注意
●
識別子の付与は Javascript:Onclick() で出来ると吉
●
集計処理で Parameter の値を CountUP
●
識別子の管理が FE と BI ツールで共有が必要 ( 改善ポイント )
- 33. 33
ConversionLog に必要な事
●
( 外部 ) サイトに検知用 Beacon を設定してもらう
●
Log にどのサイトでどのような CV が発生したのか記録する
- Parameter で表現する
( 例 )<img src='http://cbeacon.hikalab.com?
siteid=25&productid=13&actionid=2&sign=hikalabo0828' />
- 37. 37
Log の管理構成
RealTime or Batch ?
Push or Pull ?
IP 制限
WebServer①
WebServer②
BeaconServer
Redirector
LogAggregator
MongoDB
FS
Redis
Batch
Mysql
LogFile 取得
集計値格納
- 38. 38
RealTime or Batch
Push or Pull
●
RealTime(Fluentd,Storm)
✔
即時集計 / 解析
✔
一度の転送量を抑える
✗
Batch と比較して転送 / 解析の技術ハー
ドルが高い
●
Batch(Rsyslog,[RD]sync,Hadoop)
✔
定期集計 / 解析
✔
安定した集計
✗
一度の転送量が多くなる
✗
Hadoop は ServerResource が心配
●
Push(Fluentd,[RD]Sync)
✔
送信元 Server が Log 転送する
✔
Log を出力 => 転送が自然な流れ
✗
送信元 Server の負荷が心配
●
Pull(Rsyslog,Storm,[RD]Sync)
✔
受信元 ServerLog が Log を回収する
✔
メインの設定が受信元 Server で出来
る
✔
送信元 Server の負荷は軽減 ?
✗
実装 / 設定が面倒
- 43. 43
+α
Imps,CTs は Push 型
RealTime 集計を準備中
※Imps 保証数を必要以上に超過させない
RealTime でのリターゲティング
Fluentd + fuent-plugin-redis
- 53. 53
BeaconTool(GA) と ServerLog の違い
BeaconTool ServerLog
0
200000
400000
600000
800000
1000000
1200000
1400000
1000000
1200000
300000
250000
PV
User
✔
ServerLog の PV 値は BeaconTool の 120% 程
✔
ServerLog の User 値は BeaconTool の 70% 程
✔
CSC と SSC : 表示数と Request 数の違い
✔
BeaconTool 集計は BlackBox
✔
通信 Error, noscript, 非対応機種 ...
✔
BeaconCookie と独自 Cookie の付与状況
- 55. 55
緊急性と重要度
データの種類 データの項目 緊急性 重要度 格納先
広告 Imp 速報 高 中 Redis
広告 CTs 高 中 Redis
広告 効果レポート 低 高 Mysql
サービス PV 低 高 Mysql
サービス CTR 低 高 Mysql
サービス PV / UU / UB 低 高 Mysql
全て 生ログ 低 高 FS
全て 準生ログ 高 中 MongoDB
- 57. 57
Mysql Table 設計
●
テーブル設計 = 集計する項目の決定
●
Relationは作らない
– 冗長的な登録は許容
●
古いデータは消す事が前提
– 日付のPartitioningでparge
●
複雑な処理は多段集計
– 1次集計Table、2次集計Table
- 58. 58
Mysql への Write
●
Batch 処理
✔ Batch で OnMemory( 連想配列 ) に集計結果を乗せてから BulkInsert
✔ Hadoop で集計し Sqoop で結果を Import
●
RealTime 処理
✔ RunTime で MongoDB へ格納。 MogoDB のデータを Batch で集計
し、 Mysql へ格納
✔ Mysql の BlackHoleEngine を利用。実体を Slave に
✔ 特定行数を一度 Queue/Summary して、 BulkInsert
- 59. 59
Redis の利用
●
データ管理を Memory と Storage の両方で旨くこなす凄い奴
●
大量データの INSERT/SELECT も Mysql より高速
●
Memory と Storage の両方から消えた場合が大変
●
広告の Imp 制御で利用
✔ 超過 Impは極力発生させたく無い
✔ RealTime で広告ID とImp した回数を書き込む
✔ 保険として Batch でも整合性を確認