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
850
Kibanaを用いたアクセスログ調査と解析 / Access Log Analysis Using Kibana
alpicola
August 02, 2018
Tweet
Share
More Decks by alpicola
See All by alpicola
Recommending What Video to Watch Next: A Multitask Ranking System
alpicola
1
820
Offline A/B testing for Recommender Systems
alpicola
0
1.9k
Featured
See All Featured
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
KATA
mclloyd
29
13k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
3
370
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
92
16k
For a Future-Friendly Web
brad_frost
175
9.4k
Being A Developer After 40
akosma
86
590k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
A designer walks into a library…
pauljervisheath
202
24k
What's in a price? How to price your products and services
michaelherold
243
12k
A Philosophy of Restraint
colly
203
16k
It's Worth the Effort
3n
183
27k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
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 にする
な の集計 • の生成で に比例した計算量 • な の集計を行う意義は少ない • ダッシュボードを作った後で
が高くなることも
分散トレーシング • トレースの中でのボトルネックはどこか • ログにトレース を含めても活用が難しい
モニタリング • エンドポイントごとのモニタリングがしたい ◦ 異常があれば自動でアラートをあげたい • ダッシュボードだけではモニタリングではない
アイデア • の を使う ◦ クエリの実行結果を外部に通知できる機能 ◦ 任意のトリガ・整形方法 • のサービスメトリックを投稿
を使ってみて • サービスの運用に役立っている ◦ 探索的なログ調査 ◦ ダッシュボードによる観測 • のモニタリングと組み合わせる