Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

ログについて 5

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Zabbix 10

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Amazon S3 13

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

今回はアクセスログ 15

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

おかしなstatusの数 26

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Fluentdでログをパース 38

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

FluentdでElasticsearchに入れる 40

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Kibanaを用意 42

Slide 43

Slide 43 text

Visualizationを作成して表示する 43

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

まとめ 48

Slide 49

Slide 49 text

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