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
Kibanaを用いたアクセスログ調査と解析 / Access Log Analysis Us...
Search
alpicola
August 02, 2018
0
940
Kibanaを用いたアクセスログ調査と解析 / Access Log Analysis Using Kibana
alpicola
August 02, 2018
Tweet
Share
More Decks by alpicola
See All by alpicola
商品レコメンドでのexplicit negative feedbackの活用
alpicola
2
750
Recommending What Video to Watch Next: A Multitask Ranking System
alpicola
1
880
Offline A/B testing for Recommender Systems
alpicola
0
2.1k
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1031
460k
Music & Morning Musume
bryan
46
6.6k
How to Ace a Technical Interview
jacobian
278
23k
A Modern Web Designer's Workflow
chriscoyier
695
190k
A Tale of Four Properties
chriscoyier
160
23k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Practical Orchestrator
shlominoach
189
11k
Writing Fast Ruby
sferik
628
62k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
Transcript
を用いた アクセスログ調査と解析 勉強会
あるぴこら • 株式会社はてな • アプリケーションエンジニア • はてなブックマークチーム 最近
サービスの稼働状況・アプリケーションの状態 をどうやって把握するか
はてなのサーバー監視 • ◦ 自社サービス
None
• 状態の記録・監視 ◦ ホストの稼働状態 ▪ やミドルウェアのメトリック ◦ サービスの稼働状態 ▪ サービス全体のアクセス状況
レイテンシ • 障害対応など が起点
アクセスログのユースケース • リクエストにフォーカスしたいとき ◦ エンドポイント ユーザー 応答時間 • 例 ◦
障害の原因となるエンドポイントの特定 ◦ アプリケーションのパフォーマンス分析
アクセスログの形式 • ベース ◦ 時刻 time リクエスト uri 応答時間 reqtime
ステータ スコード status ユーザーエージェント ua • その他 ◦ エンドポイントの識別子 dispatch ◦ ログが生成されたホスト名 hostname
アクセスログの配送 • で へ送る • 流量は数億 くらい ◦ リクエスト数とは異なる サンプリングもしてる
のマッピング • で定義 ◦ ログの形式は不定 • 基本的に しない
ケーススタディ
障害対応時 • のアラートで異常に気づく • で細かい状況把握と原因調査 ◦ で異常を示したメトリクスが手がかり
急なアクセス増加 • 誰が どこに いつから アクセスしている ◦ 典型的には • で可視化
• は次を指定 ◦ date_histgram いつ ua 誰 ◦ date_histgram いつ dispatch どこ
型サーバーの 枯渇 • どこで の時間をたくさん使っている • ◦ dispatch どこ •
◦ reqtime 時間
レスポンスの増加 • タブで status: [500 TO inf] • で値の偏りがないか見る ◦
エンドポイント dispatch uri ◦ クライアント ua client_ip ◦ ホスト hostname • 怪しい要素でフィルタして原因特定まで絞り込む
リリース・デプロイ時 • ダッシュボードを作っておく • 主要なエンドポイントの健全性を確認 ◦ dispatchでフィルタ ◦ statusの ◦
reqtimeの
パフォーマンス振り返り • エンドポイント dispatch ごとに表にする ◦ reqtime ◦ reqtime の時間の利用
◦ size 帯域の利用
課題/今後の展望
「クソクエリ」問題 • 実行に長時間かかる • 大量のリソースを消費 • クラスタ全体の応答時間が悪化 ◦ ログの投入も遅延
先頭のワイルドカード • ua:*GoogleBot* • あらゆる を考慮することになるので遅い • 対策 allow_leading_wildcardをfalse にする
な の集計 • の生成で に比例した計算量 • な の集計を行う意義は少ない • ダッシュボードを作った後で
が高くなることも
分散トレーシング • トレースの中でのボトルネックはどこか • ログにトレース を含めても活用が難しい
モニタリング • エンドポイントごとのモニタリングがしたい ◦ 異常があれば自動でアラートをあげたい • ダッシュボードだけではモニタリングではない
アイデア • の を使う ◦ クエリの実行結果を外部に通知できる機能 ◦ 任意のトリガ・整形方法 • のサービスメトリックを投稿
を使ってみて • サービスの運用に役立っている ◦ 探索的なログ調査 ◦ ダッシュボードによる観測 • のモニタリングと組み合わせる