Kibanaで秒間1万件のアクセスを可視化した話/nikkei-kibana-loganalyst2015

Transcript

1. Kibanaで秒間1万件のアクセスを可視化した話
   2015/10/15 ログ分析勉強会 vol.1
   Yuri Umezaki
   

   View Slide

2. 自己紹介
   梅崎 裕利
   ● 会社
   ○ 日本経済新聞社デジタル編成局
   ● 主な業務
   ○ Ansibleでサーバ管理
   ○ Django+Elasticsearch(ES)で検索API作成
   ○ Fluentd+ES+Kibanaでログ分析
   2
   

   View Slide

3. 日経電子版の紹介
   ● 有料のニュースサービス
   ○ 40万人を超える有料会員
   ● 8月にサーバをAWSへ移行
   ○ 合計でおよそ300台
   ○ 移行に合わせてログの可視化を実施
   ● サービス開発部隊は40人程度
   3
   

   View Slide

4. 目次
   ● そもそもログとは
   ○ ログの分類
   ○ どう扱うと良いか・事例
   ● アクセスログの可視化
   ○ Kibanaについて
   ○ 何を可視化すると良いか・事例
   ● Fluentd-Elasticsearch-Kibana
   ○ アクセスログ可視化の構成・設定
   ○ 性能について
   ● まとめ
   4
   

   View Slide

5. ログについて
   5
   

   View Slide

6. そもそもログとは
   ● 時系列データ
   ○ いつ誰がどこで何をどうやってどうした
   ○ 数値データや文字データ
   ● 今回は以下のように分類
   ○ エラー
   ■ 緊急性の高い情報
   ○ メトリクス
   ■ 数値化できるもの
   ○ 保管用ログ
   ■ 即座に活用する必要がなく、数値化もしにくいもの
   ○ (カスタムログ)
   ■ クライアントサイドで取得するもの、アプリケーションのアクションログ
   6
   

   View Slide

7. エラーログ
   ● 発生したら対応・確認が必要なログ（アラート）
   ○ アプリ
   ■ バッチのエラー、Webサービスのエラー
   ○ Syslog
   ■ Kernelやドライバのエラー、依存サービスのエラー、etc…
   ● 配慮すべきこと
   ○ 即時に通知(電話やSlack, メールなど)
   ○ 大量に出る可能性があるので集約する（Sentryを活用)
   ○ 十分な情報を出す
   ○ 通知不要なログは出さない
   ■ アプリ側で出さないようにする。難しい場合はフィルタを作る
   ■ オオカミ少年にならないように
   7
   

   View Slide

8. Sentry
   ● ログを集約してわかりやすく表示
   8
   

   View Slide

9. メトリクス
   ● 数値化できる情報
   ○ システム
   ■ CPU load, Memory, I/O, Network traffic, etc…
   ■ Datadog, Mackerel, NewRelic Servers, Zabbixなど
   ○ アプリケーション
   ■ リクエスト数, 平均応答時間, 5xxレスポンス数, etc...
   ■ NewRelic APM
   ● 利用方法
   ○ 統計的に見て異常値があれば通知する
   ■ トリガーを用意して通知（例:CPU load 2以上が5分続いたら通知)
   ○ トラブル時の原因切り分けに利用
   ■ 例: エラーの原因はディスクFullだった、など
   9
   

   View Slide

10. Zabbix
    10
    

    View Slide

11. NewRelic APM
    ● URLごとの平均レスポンス時間や関数内の処理時間が分かる
    11
    

    View Slide

12. 保管用ログ
    ● 即時対応不要だが、収集する必要があるログ
    ○ 監査ログ
    ■ 紛失・改ざんできない箇所に保管 (別アカウントのS3など）
    ○ info, noticeレベルのログ
    ■ 後で利用できるようにしておく
    ■ Elasticsearch, Splunk, Logentries, LOGGLY, BigQuery, S3
    ■ 重要なログ（error以上など）は分離できるようしておく
    ● 利用方法
    ○ 問題発生時に作業内容の確認
    ○ 理想は、普段と違うログエントリを自動で見つけてアラートを出す（≒IDS)
    ■ => Splunkの活用
    12
    

    View Slide

13. Amazon S3
    13
    

    View Slide

14. カスタムログ
    ● サービスで活用できるログ
    ○ アクセス解析、アクションログ（ユーザの行動ログ）
    ■ クライアントサイドで収集するもの
    ■ 重要度の高い特定のイベントなど
    ■ Mixpanel, Google Analitics, Adobe marketing cloud, …
    14
    

    View Slide

15. 今回はアクセスログ
    15
    

    View Slide

16. アクセスログは？
    ユーザのHTTPリクエストに紐づくログ
    一種のメトリクス
    ● 従来
    ○ 行数やエラー数などを事前に集計し、結果のみをメトリクスとしてDBに保存
    ○ または保管用ログとして残しているだけで、活用はしていない
    ● 理想
    ○ データベースに全部突っ込んでおいて、あとで必要なメトリクスを集計する
    ■ Elasticsearchを使えばできる
    16
    

    View Slide

17. 後集計のメリット
    ● 目的に合わせて都度、条件を指定して集計できる
    ○ 複数の条件を指定してメトリクスを確認
    ■ 抽象的な情報を見てより詳細に確認できる
    ○ 目的の数値を変更
    ■ 例: レスポンス時間の平均値、最大値、99%タイル
    ● 直接ログの中身が確認できる
    17
    

    View Slide

18. 後集計のデメリット
    ● 計算リソース（≒お金)と大量のデータを扱えるDBが必要
    ○ 量が多いので外部サービスに投げると高コスト
    ● 表示（集計）に時間がかかる
    ● 何でも出来る
    ○ 時間泥棒
    18
    

    View Slide

19. Kibanaでアクセスログの可視化
    19
    

    View Slide

20. Kibanaとは
    20
    ● データ可視化・検索・解析ツール
    ○ OSS
    ○ ブラウザベース
    ○ DBとしてElasticsearchを利用
    ○ アクセスログや保管用ログの解析に良く使われる
    

    View Slide

21. 日経のアクセスログ
    ● 秒間1万件超
    ● 1日約3億件
    ○ およそ1日120GB
    ○ 常時1週間分を保持
    ● Elasticsearchはr3.xlargeを6台で運用
    ○ 合計メモリ180GB(ElasticsearchのHeapは72GB)
    ○ 月20万円前後
    ○ スポットインスタンスを使えば月約3万円
    ○ 24時間分のログは1分程度で表示できる
    21
    

    View Slide

22. 普段何を見ているか
    ● 合計リクエスト数
    ● レスポンスサイズの合計
    ○ ≒帯域使用量
    ● 応答に3秒以上掛かっているリクエスト(Path毎)
    ● おかしなレスポンスstatusの数
    ● 攻撃と思われるリクエスト数
    22
    

    View Slide

23. 普段確認している画面
    ● 一括で確認できるダッシュボードを作成
    23
    

    View Slide

24. 合計リクエスト数の推移
    ● サーバ毎の分散状況、キャッシュのヒット割合なども確認
    24
    

    View Slide

25. 応答に3秒以上掛かっているpath一覧
    25
    

    View Slide

26. おかしなstatusの数
    26
    

    View Slide

27. 簡易な攻撃検知
    ● マイナーなmethod (GET HEAD PROPFIND以外)
    ● 怪しいパターン（例)
    ○ ディレクトリトラバーサル狙い？
    ■ ../ passwd shadow system32 .ini .log
    ○ プログラム脆弱性を狙ったリクエスト
    ■ admin uploader wp-admin
    ■ .jsp .asp .aspx .asp .php .cgi .pl
    ■ action redirectAction redirect
    ■ %3Cscript ■ %00 %0A %0D
    ○ SQLインジェクションを狙ったリクエスト
    ■ create select delete insert
    ■ waitfor information_schema sleep benchmark
    27
    

    View Slide

28. SecListsなどを活用
    https://github.com/danielmiessler/SecLists
    28
    

    View Slide

29. 検索した結果
    ● IP別に表示
    29
    

    View Slide

30. どこまでやるか
    ● Request bodyやcookie, headerでもパターンマッチ
    ○ IDSとしての精度は高まる
    ● だけど、本来取る必要はない項目
    ○ POSTのbodyなどがログに残るのはリスクになりうる
    ○ ログのサイズが大きくなる
    ○ 攻撃を検知したところで特にできることはない
    ■ 別レイヤーで対応する問題
    30
    

    View Slide

31. その他の活用方法
    ● トラブル時の影響調査
    ● クローラを見つける
    ● DoSを見つける
    ○ リクエスト数が多い上位10のIPを表示
    ● トラフィック使用量の多いファイルを見つける
    ○ キャッシュの最適化に
    ● 外から直接参照されているファイルを探す
    ● 404のファイルを探す
    31
    

    View Slide

32. アクセスログ可視化の準備
    32
    

    View Slide

33. アクセスログをKibanaで表示するまでの流れ
    33
    構成はFluentd+Elasticsearch+Kibana
    ● Apache, Nginxなどの設定
    ○ ログをパースしやすいように変更
    ● Fluentdの設定
    ○ Fluentdでアクセスログをパース
    ○ FluentdでアクセスログのUAを解析・Geo_IPを付与
    ○ FluentdでElasticsearchに投げる
    ● Elasticsearchの設定
    ○ ログ用スキーマを入れておく
    ● Kibanaの設定
    ○ 表示するスクリーンを作成する
    

    View Slide

34. 構成図
    ● ログ集約サーバは分けなくても良い
    ○ Webサーバへの負荷軽減
    34
    ログ集約サーバ
    ロードバランサ
    Webサーバ Webサーバ
    S3（長期保存)
    Elassticsearch
    Elassticsearch
    Kibana
    

    View Slide

35. ログフォーマット
    ● LTSVを利用する
    ● 情報を増やす（出せる情報は出す）
    35
    

    View Slide

36. Nginxのログフォーマット例
    36
    

    View Slide

37. Apacheのログフォーマット例
    (分かりやすいよう改行しています)
    37
    

    View Slide

38. Fluentdでログをパース
    38
    

    View Slide

39. Fluentdでいくつかフィルタを挟む
    ● x_forwarded_forの最後のIPを抽出して別カラムに
    ● user_agentをパースしてOSやブラウザ、バージョンを明確に
    ● geo_ipを使ってアクセス元が大まかにわかるように
    ● nginxやapacheのtaken_timeをms単位に統一
    ● 取れていない項目を削除
    近々公開します
    39
    

    View Slide

40. FluentdでElasticsearchに入れる
    40
    

    View Slide

41. Elasticsearchはスキーマを用意する
    41
    

    View Slide

42. Kibanaを用意
    42
    

    View Slide

43. Visualizationを作成して表示する
    43
    

    View Slide

44. 大量のデータを捌く上でのポイント
    44
    

    View Slide

45. Elasticsearchの設定
    ● HEAP Sizeを大きくする（重要)
    ○ /etc/sysconfig/elasticsearch
    ■ ES_HEAP_SIZE=6g (実メモリの40～50%に設定)
    ● 更新間隔を長くする
    ○ { "settings": { "index": { "refresh_interval" : "5s" }}}
    ○ あまり効果はないかも
    ● 定期的にCache clearする
    ○ HEAPがいっぱいになると検索できなくなる
    45
    

    View Slide

46. Fluentdの設定
    ● Record_transformerでrubyコードをなるべく使わない
    ○ １行の設定でCPU使用率が5倍になることも(15%->75%)
    46
    

    View Slide

47. 性能（感覚値）
    ● Elasticserach
    ○ 追加: r3.xlarge 6台で秒6万件は入れられる
    ○ 検索: r3.xlarge 6台で10億件のアグリゲーションがギリギリ可能
    ● Fluentd
    ○ 1cpuで5000～2万件程度(設定次第)
    ■ S3に保存する際のgzip処理、geo_ipなどのフィルタ処理で重くなる
    47
    

    View Slide

48. まとめ
    48
    

    View Slide

49. まとめ
    ● 後集計でアクセスログを可視化するのは有用
    ● Fluentd+Elasticsearch+kibanaは便利でおすすめ
    ○ アクセスログ可視化だけでなくログ可視化にも使える
    ○ 秒2000件ぐらいであれば1台でも大丈夫
    ○ AWSにElasticsearchが用意されたので準備も簡単
    ○ OSSなので趣味でも使える
    49
    

    View Slide