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
740
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
Optimizing for Happiness
mojombo
379
70k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
GitHub's CSS Performance
jonrohan
1031
460k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.8k
Practical Orchestrator
shlominoach
188
11k
Done Done
chrislema
184
16k
For a Future-Friendly Web
brad_frost
179
9.8k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
53k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
228
22k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
GraphQLとの向き合い方2022年版
quramy
47
14k
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 にする
な の集計 • の生成で に比例した計算量 • な の集計を行う意義は少ない • ダッシュボードを作った後で
が高くなることも
分散トレーシング • トレースの中でのボトルネックはどこか • ログにトレース を含めても活用が難しい
モニタリング • エンドポイントごとのモニタリングがしたい ◦ 異常があれば自動でアラートをあげたい • ダッシュボードだけではモニタリングではない
アイデア • の を使う ◦ クエリの実行結果を外部に通知できる機能 ◦ 任意のトリガ・整形方法 • のサービスメトリックを投稿
を使ってみて • サービスの運用に役立っている ◦ 探索的なログ調査 ◦ ダッシュボードによる観測 • のモニタリングと組み合わせる