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

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コードをなるべく使わない ◦ １行の設定で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