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

Transcript

1. を用いた アクセスログ調査と解析 勉強会

2. あるぴこら • 株式会社はてな • アプリケーションエンジニア • はてなブックマークチーム 最近

3. サービスの稼働状況・アプリケーションの状態 をどうやって把握するか

4. はてなのサーバー監視 • ◦ 自社サービス

5. None

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. を使ってみて • サービスの運用に役立っている ◦ 探索的なログ調査 ◦ ダッシュボードによる観測 • のモニタリングと組み合わせる