Kibanaを用いたアクセスログ調査と解析 / Access Log Analysis Using Kibana

Transcript

1. を用いた アクセスログ調査と解析 勉強会
2. あるぴこら • 株式会社はてな • アプリケーションエンジニア • はてなブックマークチーム 最近
3. サービスの稼働状況・アプリケーションの状態 をどうやって把握するか
4. はてなのサーバー監視 • ◦ 自社サービス
6. • 状態の記録・監視 ◦ ホストの稼働状態 ▪ やミドルウェアのメトリック ◦ サービスの稼働状態 ▪ サービス全体のアクセス状況 レイテンシ • 障害対応など が起点
7. アクセスログのユースケース • リクエストにフォーカスしたいとき ◦ エンドポイント ユーザー 応答時間 • 例 ◦ 障害の原因となるエンドポイントの特定 ◦ アプリケーションのパフォーマンス分析
8. アクセスログの形式 • ベース ◦ 時刻 time リクエスト uri 応答時間 reqtime ステータ スコード status ユーザーエージェント ua • その他 ◦ エンドポイントの識別子 dispatch ◦ ログが生成されたホスト名 hostname
9. アクセスログの配送 • で へ送る • 流量は数億 くらい ◦ リクエスト数とは異なる サンプリングもしてる
10. のマッピング • で定義 ◦ ログの形式は不定 • 基本的に しない
11. ケーススタディ
12. 障害対応時 • のアラートで異常に気づく • で細かい状況把握と原因調査 ◦ で異常を示したメトリクスが手がかり
13. 急なアクセス増加 • 誰が どこに いつから アクセスしている ◦ 典型的には • で可視化 • は次を指定 ◦ date_histgram いつ ua 誰 ◦ date_histgram いつ dispatch どこ
14. 型サーバーの 枯渇 • どこで の時間をたくさん使っている • ◦ dispatch どこ • ◦ reqtime 時間
15. レスポンスの増加 • タブで status: [500 TO inf] • で値の偏りがないか見る ◦ エンドポイント dispatch uri ◦ クライアント ua client_ip ◦ ホスト hostname • 怪しい要素でフィルタして原因特定まで絞り込む
16. リリース・デプロイ時 • ダッシュボードを作っておく • 主要なエンドポイントの健全性を確認 ◦ dispatchでフィルタ ◦ statusの ◦ reqtimeの
17. パフォーマンス振り返り • エンドポイント dispatch ごとに表にする ◦ reqtime ◦ reqtime の時間の利用 ◦ size 帯域の利用
18. 課題／今後の展望
19. 「クソクエリ」問題 • 実行に長時間かかる • 大量のリソースを消費 • クラスタ全体の応答時間が悪化 ◦ ログの投入も遅延
20. 先頭のワイルドカード • ua:*GoogleBot* • あらゆる を考慮することになるので遅い • 対策 allow_leading_wildcardをfalse にする
21. な の集計 • の生成で に比例した計算量 • な の集計を行う意義は少ない • ダッシュボードを作った後で が高くなることも
22. 分散トレーシング • トレースの中でのボトルネックはどこか • ログにトレース を含めても活用が難しい
23. モニタリング • エンドポイントごとのモニタリングがしたい ◦ 異常があれば自動でアラートをあげたい • ダッシュボードだけではモニタリングではない
24. アイデア • の を使う ◦ クエリの実行結果を外部に通知できる機能 ◦ 任意のトリガ・整形方法 • のサービスメトリックを投稿
25. を使ってみて • サービスの運用に役立っている ◦ 探索的なログ調査 ◦ ダッシュボードによる観測 • のモニタリングと組み合わせる