Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

bungoume
October 15, 2015

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

bungoume

October 15, 2015
Tweet

More Decks by bungoume

Other Decks in Technology

Transcript

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

    Ansibleでサーバ管理 ◦ Django+Elasticsearch(ES)で検索API作成 ◦ Fluentd+ES+Kibanaでログ分析 2
  2. 目次 • そもそもログとは ◦ ログの分類 ◦ どう扱うと良いか・事例 • アクセスログの可視化 ◦

    Kibanaについて ◦ 何を可視化すると良いか・事例 • Fluentd-Elasticsearch-Kibana ◦ アクセスログ可視化の構成・設定 ◦ 性能について • まとめ 4
  3. そもそもログとは • 時系列データ ◦ いつ誰がどこで何をどうやってどうした ◦ 数値データや文字データ • 今回は以下のように分類 ◦

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

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

    Network traffic, etc… ▪ Datadog, Mackerel, NewRelic Servers, Zabbixなど ◦ アプリケーション ▪ リクエスト数, 平均応答時間, 5xxレスポンス数, etc... ▪ NewRelic APM • 利用方法 ◦ 統計的に見て異常値があれば通知する ▪ トリガーを用意して通知(例:CPU load 2以上が5分続いたら通知) ◦ トラブル時の原因切り分けに利用 ▪ 例: エラーの原因はディスクFullだった、など 9
  6. 保管用ログ • 即時対応不要だが、収集する必要があるログ ◦ 監査ログ ▪ 紛失・改ざんできない箇所に保管 (別アカウントのS3など) ◦ info,

    noticeレベルのログ ▪ 後で利用できるようにしておく ▪ Elasticsearch, Splunk, Logentries, LOGGLY, BigQuery, S3 ▪ 重要なログ(error以上など)は分離できるようしておく • 利用方法 ◦ 問題発生時に作業内容の確認 ◦ 理想は、普段と違うログエントリを自動で見つけてアラートを出す(≒IDS) ▪ => Splunkの活用 12
  7. 日経のアクセスログ • 秒間1万件超 • 1日約3億件 ◦ およそ1日120GB ◦ 常時1週間分を保持 •

    Elasticsearchはr3.xlargeを6台で運用 ◦ 合計メモリ180GB(ElasticsearchのHeapは72GB) ◦ 月20万円前後 ◦ スポットインスタンスを使えば月約3万円 ◦ 24時間分のログは1分程度で表示できる 21
  8. 簡易な攻撃検知 • マイナーな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
  9. どこまでやるか • Request bodyやcookie, headerでもパターンマッチ ◦ IDSとしての精度は高まる • だけど、本来取る必要はない項目 ◦

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

    トラフィック使用量の多いファイルを見つける ◦ キャッシュの最適化に • 外から直接参照されているファイルを探す • 404のファイルを探す 31
  11. アクセスログをKibanaで表示するまでの流れ 33 構成はFluentd+Elasticsearch+Kibana • Apache, Nginxなどの設定 ◦ ログをパースしやすいように変更 • Fluentdの設定

    ◦ Fluentdでアクセスログをパース ◦ FluentdでアクセスログのUAを解析・Geo_IPを付与 ◦ FluentdでElasticsearchに投げる • Elasticsearchの設定 ◦ ログ用スキーマを入れておく • Kibanaの設定 ◦ 表示するスクリーンを作成する
  12. Elasticsearchの設定 • HEAP Sizeを大きくする(重要) ◦ /etc/sysconfig/elasticsearch ▪ ES_HEAP_SIZE=6g (実メモリの40~50%に設定) •

    更新間隔を長くする ◦ { "settings": { "index": { "refresh_interval" : "5s" }}} ◦ あまり効果はないかも • 定期的にCache clearする ◦ HEAPがいっぱいになると検索できなくなる 45
  13. 性能(感覚値) • Elasticserach ◦ 追加: r3.xlarge 6台で秒6万件は入れられる ◦ 検索: r3.xlarge

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