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
Navigating Team Friction
lara
187
15k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Unsuck your backbone
ammeep
671
58k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Docker and Python
trallard
44
3.5k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
970
The Language of Interfaces
destraynor
158
25k
The Straight Up "How To Draw Better" Workshop
denniskardys
234
140k
Rebuilding a faster, lazier Slack
samanthasiow
82
9.1k
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 にする
な の集計 • の生成で に比例した計算量 • な の集計を行う意義は少ない • ダッシュボードを作った後で
が高くなることも
分散トレーシング • トレースの中でのボトルネックはどこか • ログにトレース を含めても活用が難しい
モニタリング • エンドポイントごとのモニタリングがしたい ◦ 異常があれば自動でアラートをあげたい • ダッシュボードだけではモニタリングではない
アイデア • の を使う ◦ クエリの実行結果を外部に通知できる機能 ◦ 任意のトリガ・整形方法 • のサービスメトリックを投稿
を使ってみて • サービスの運用に役立っている ◦ 探索的なログ調査 ◦ ダッシュボードによる観測 • のモニタリングと組み合わせる