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

D405f3b9dc9fa223f6fa507717f41372?s=47 bungoume
October 15, 2015

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

D405f3b9dc9fa223f6fa507717f41372?s=128

bungoume

October 15, 2015
Tweet

Transcript

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

  2. 自己紹介 梅崎 裕利 • 会社 ◦ 日本経済新聞社デジタル編成局 • 主な業務 ◦

    Ansibleでサーバ管理 ◦ Django+Elasticsearch(ES)で検索API作成 ◦ Fluentd+ES+Kibanaでログ分析 2
  3. 日経電子版の紹介 • 有料のニュースサービス ◦ 40万人を超える有料会員 • 8月にサーバをAWSへ移行 ◦ 合計でおよそ300台 ◦

    移行に合わせてログの可視化を実施 • サービス開発部隊は40人程度 3
  4. 目次 • そもそもログとは ◦ ログの分類 ◦ どう扱うと良いか・事例 • アクセスログの可視化 ◦

    Kibanaについて ◦ 何を可視化すると良いか・事例 • Fluentd-Elasticsearch-Kibana ◦ アクセスログ可視化の構成・設定 ◦ 性能について • まとめ 4
  5. ログについて 5

  6. そもそもログとは • 時系列データ ◦ いつ誰がどこで何をどうやってどうした ◦ 数値データや文字データ • 今回は以下のように分類 ◦

    エラー ▪ 緊急性の高い情報 ◦ メトリクス ▪ 数値化できるもの ◦ 保管用ログ ▪ 即座に活用する必要がなく、数値化もしにくいもの ◦ (カスタムログ) ▪ クライアントサイドで取得するもの、アプリケーションのアクションログ 6
  7. エラーログ • 発生したら対応・確認が必要なログ(アラート) ◦ アプリ ▪ バッチのエラー、Webサービスのエラー ◦ Syslog ▪

    Kernelやドライバのエラー、依存サービスのエラー、etc… • 配慮すべきこと ◦ 即時に通知(電話やSlack, メールなど) ◦ 大量に出る可能性があるので集約する(Sentryを活用) ◦ 十分な情報を出す ◦ 通知不要なログは出さない ▪ アプリ側で出さないようにする。難しい場合はフィルタを作る ▪ オオカミ少年にならないように 7
  8. Sentry • ログを集約してわかりやすく表示 8

  9. メトリクス • 数値化できる情報 ◦ システム ▪ CPU load, Memory, I/O,

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

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

  12. 保管用ログ • 即時対応不要だが、収集する必要があるログ ◦ 監査ログ ▪ 紛失・改ざんできない箇所に保管 (別アカウントのS3など) ◦ info,

    noticeレベルのログ ▪ 後で利用できるようにしておく ▪ Elasticsearch, Splunk, Logentries, LOGGLY, BigQuery, S3 ▪ 重要なログ(error以上など)は分離できるようしておく • 利用方法 ◦ 問題発生時に作業内容の確認 ◦ 理想は、普段と違うログエントリを自動で見つけてアラートを出す(≒IDS) ▪ => Splunkの活用 12
  13. Amazon S3 13

  14. カスタムログ • サービスで活用できるログ ◦ アクセス解析、アクションログ(ユーザの行動ログ) ▪ クライアントサイドで収集するもの ▪ 重要度の高い特定のイベントなど ▪

    Mixpanel, Google Analitics, Adobe marketing cloud, … 14
  15. 今回はアクセスログ 15

  16. アクセスログは? ユーザのHTTPリクエストに紐づくログ 一種のメトリクス • 従来 ◦ 行数やエラー数などを事前に集計し、結果のみをメトリクスとしてDBに保存 ◦ または保管用ログとして残しているだけで、活用はしていない •

    理想 ◦ データベースに全部突っ込んでおいて、あとで必要なメトリクスを集計する ▪ Elasticsearchを使えばできる 16
  17. 後集計のメリット • 目的に合わせて都度、条件を指定して集計できる ◦ 複数の条件を指定してメトリクスを確認 ▪ 抽象的な情報を見てより詳細に確認できる ◦ 目的の数値を変更 ▪

    例: レスポンス時間の平均値、最大値、99%タイル • 直接ログの中身が確認できる 17
  18. 後集計のデメリット • 計算リソース(≒お金)と大量のデータを扱えるDBが必要 ◦ 量が多いので外部サービスに投げると高コスト • 表示(集計)に時間がかかる • 何でも出来る ◦

    時間泥棒 18
  19. Kibanaでアクセスログの可視化 19

  20. Kibanaとは 20 • データ可視化・検索・解析ツール ◦ OSS ◦ ブラウザベース ◦ DBとしてElasticsearchを利用

    ◦ アクセスログや保管用ログの解析に良く使われる
  21. 日経のアクセスログ • 秒間1万件超 • 1日約3億件 ◦ およそ1日120GB ◦ 常時1週間分を保持 •

    Elasticsearchはr3.xlargeを6台で運用 ◦ 合計メモリ180GB(ElasticsearchのHeapは72GB) ◦ 月20万円前後 ◦ スポットインスタンスを使えば月約3万円 ◦ 24時間分のログは1分程度で表示できる 21
  22. 普段何を見ているか • 合計リクエスト数 • レスポンスサイズの合計 ◦ ≒帯域使用量 • 応答に3秒以上掛かっているリクエスト(Path毎) •

    おかしなレスポンスstatusの数 • 攻撃と思われるリクエスト数 22
  23. 普段確認している画面 • 一括で確認できるダッシュボードを作成 23

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

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

  26. おかしなstatusの数 26

  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 <script ▪ %00 %0A %0D ◦ SQLインジェクションを狙ったリクエスト ▪ create select delete insert ▪ waitfor information_schema sleep benchmark 27
  28. SecListsなどを活用 https://github.com/danielmiessler/SecLists 28

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

  30. どこまでやるか • Request bodyやcookie, headerでもパターンマッチ ◦ IDSとしての精度は高まる • だけど、本来取る必要はない項目 ◦

    POSTのbodyなどがログに残るのはリスクになりうる ◦ ログのサイズが大きくなる ◦ 攻撃を検知したところで特にできることはない ▪ 別レイヤーで対応する問題 30
  31. その他の活用方法 • トラブル時の影響調査 • クローラを見つける • DoSを見つける ◦ リクエスト数が多い上位10のIPを表示 •

    トラフィック使用量の多いファイルを見つける ◦ キャッシュの最適化に • 外から直接参照されているファイルを探す • 404のファイルを探す 31
  32. アクセスログ可視化の準備 32

  33. アクセスログをKibanaで表示するまでの流れ 33 構成はFluentd+Elasticsearch+Kibana • Apache, Nginxなどの設定 ◦ ログをパースしやすいように変更 • Fluentdの設定

    ◦ Fluentdでアクセスログをパース ◦ FluentdでアクセスログのUAを解析・Geo_IPを付与 ◦ FluentdでElasticsearchに投げる • Elasticsearchの設定 ◦ ログ用スキーマを入れておく • Kibanaの設定 ◦ 表示するスクリーンを作成する
  34. 構成図 • ログ集約サーバは分けなくても良い ◦ Webサーバへの負荷軽減 34 ログ集約サーバ ロードバランサ Webサーバ Webサーバ

    S3(長期保存) Elassticsearch Elassticsearch Kibana
  35. ログフォーマット • LTSVを利用する • 情報を増やす(出せる情報は出す) 35

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

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

  38. Fluentdでログをパース 38

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

    取れていない項目を削除 近々公開します 39
  40. FluentdでElasticsearchに入れる 40

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

  42. Kibanaを用意 42

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

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

  45. Elasticsearchの設定 • HEAP Sizeを大きくする(重要) ◦ /etc/sysconfig/elasticsearch ▪ ES_HEAP_SIZE=6g (実メモリの40~50%に設定) •

    更新間隔を長くする ◦ { "settings": { "index": { "refresh_interval" : "5s" }}} ◦ あまり効果はないかも • 定期的にCache clearする ◦ HEAPがいっぱいになると検索できなくなる 45
  46. Fluentdの設定 • Record_transformerでrubyコードをなるべく使わない ◦ 1行の設定でCPU使用率が5倍になることも(15%->75%) 46

  47. 性能(感覚値) • Elasticserach ◦ 追加: r3.xlarge 6台で秒6万件は入れられる ◦ 検索: r3.xlarge

    6台で10億件のアグリゲーションがギリギリ可能 • Fluentd ◦ 1cpuで5000~2万件程度(設定次第) ▪ S3に保存する際のgzip処理、geo_ipなどのフィルタ処理で重くなる 47
  48. まとめ 48

  49. まとめ • 後集計でアクセスログを可視化するのは有用 • Fluentd+Elasticsearch+kibanaは便利でおすすめ ◦ アクセスログ可視化だけでなくログ可視化にも使える ◦ 秒2000件ぐらいであれば1台でも大丈夫 ◦

    AWSにElasticsearchが用意されたので準備も簡単 ◦ OSSなので趣味でも使える 49