Downloaded 57 times
![このような通信分析環境を構築してみた
• Netflow CollectorをElastic Stackで構築し、約20,000/秒のフローの取り込みを行う。
※構築時は最終的にどのくらいのフロー数が流れてくるか読めていなかった...(泣)
NetFlow Exporter
Netflow Collector
Netflow
(UDP)
ここの話
input {
udp {
port => "2055"
workers => “4"
queue_size => "2048“
codec => netflow {
versions => [5,9,10]
}
}
}](https://image.slidesharecdn.com/elasticsearchmeetuplogstash-181121115048/85/26-Elasticsearch-Logstash-12-320.jpg)
![ダメ押しで、outputの設定変更を試してみるが...
• output elasticsearchの出力先を絞ることでLogstashのCPU負荷を上げられるか試した。
Elasticsearch#1
Elasticsearch#2
Elasticsearch#3
output {
elasticsearch {
# hosts => [“192.168.0.1:9200”,”192.168.0.2:9200”,”192.168.0.3:9200” ]
hosts => “192.168.0.1:9200”
}
}
192.168.0.1
192.168.0.2
192.168.0.3
【参考URL】Elasticsearch output plugin
https://www.elastic.co/guide/en/logstash/current/plugins-outputs-elasticsearch.html#plugins-outputs-elasticsearch-hosts
【結果】
CPU使用率やSystemLoadは変化せず...](https://image.slidesharecdn.com/elasticsearchmeetuplogstash-181121115048/85/26-Elasticsearch-Logstash-34-320.jpg)
More Related Content
Similar to 【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
- 1.
- 2. 自己紹介 名前：日比野 恒 (ひびのひさし) 所属：フューチャーアーキテクト株式会社 セキュリティアーキテクト (CISSP、CISA、情報処理安全確保支援士) オープンな技術 オープンな環境× 【オープンSIEM構想】 「オープンな技術」や「オープンな環境」でSIEMを作りたい！！ 「個人の知見やスキルは、社会の利益のために使われるべき」というマインド
- 3.
- 4.
- 5. Logstash or Fluentd •Logstashはグローバルスタンダード。でも国内では...(笑)
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12. このような通信分析環境を構築してみた • Netflow CollectorをElasticStackで構築し、約20,000/秒のフローの取り込みを行う。 ※構築時は最終的にどのくらいのフロー数が流れてくるか読めていなかった...(泣) NetFlow Exporter Netflow Collector Netflow (UDP) ここの話 input { udp { port => "2055" workers => “4" queue_size => "2048“ codec => netflow { versions => [5,9,10] } } }
- 13. Logstashのシステム構成 • オンプレ環境のNutanix上に仮想マシンとしてLogstash専用ノード×1台準備。 Nutanix AHV(Host OS) CentOS7 64bit (Guest OS) Server Node Java 8 Logstash 6.2.4 X-Pack Basic 6.2.4 項目 設定値 vCPU 4コア vRAM 16GB vDisk 100GB vNIC 1個 (1000BASE-T)
- 14.
- 15.
- 16. 【参考】codec netflow • 1個のパケット(=FlowSequence)に含まれる複数のフローをフロー単位に分割してくれる。 input (udp) Codec (netflow) Filter Output (elastic search) UDPパケット フロー 【パケットキャプチャデータ】 例)1個のパケットの中には19個のフローが含まれていた。 【参考URL】Netflowcodec plugin https://www.elastic.co/guide/en/logstash/current/plugins-codecs-netflow.html
- 17.
- 18. 障害切り分け • Logstashの各処理で想定外の動きをしていないかを中心に疑い切り分けを実施するも... 【疑った観点1】 Logstashのfilterで parse errorが起きているの では？ 【疑った観点2】 codecnetflowで正しく フローが分割出来ていない のでは？ 【疑った観点3】 そもそもNetflowパケットが 正しく受信出来ていないので は？ 【結果1】 Netflowをパケットキャプ チャして、パケットの中身と比 較するもデータサイズに差分 なし... 【結果2】 同じくパケットキャプチャした パケットのシーケンス単位で フローを比較するも差分な し... 【結果3】 Exporter側とCollecter側 の通信量を比較するも大きく 差分なし... どこでDropしているのか？
- 19. パケットのDropが起きていることが判明 • netstat –suコマンドのpacketreceive errorsのカウンタが上がり続けていた。 【ポイント】 7/2のフロー取得対象機器追加後 収集フロー数が激減していた。 # netstat -su IcmpMsg: InType3: 4 InType8: 1016 OutType0: 1016 OutType3: 8594 Udp: 229538 packets received 340486 packets to unknown port received. 79619 packet receive errors 107 packets sent 79619 receive buffer errors 0 send buffer errors UdpLite: IpExt: InNoRoutes: 2 InBcastPkts: 44 InOctets: 1372994252 OutOctets: 6150335046 InBcastOctets: 5909 InNoECTPkts: 2374707
- 20.
- 21. pipelineアーキテクチャ図 • Logstashのpluginが各処理の中でどのようにメモリ領域を利用しているのかを書いてみた。 CentOS7 Memory JVM Heaps Netflow Exporter UDP Receivebuffer Memory Queue input udp queue Logstash input (udp) Codec (netflow) Filter Output (elastic search) Packet Packet flow Elasticsearch #1 document Netflow Exporter ・ ・ ・ Elasticsearch #2 Elasticsearch #3 document document Workers × Batch SizeWorkers Packet Packet flow flow flow
- 22. 改善対処1: 受信バッファの拡張 • OSのカーネルパラメータ(/etc/sysctl.d)をチューニングすることで受信バッファを拡張。 ※inputudpのreceive_buffer_bytesは利用せずにOS側で設定を実施 ※net.core.rmem_maxを2GBに出来ず、とりあえずで1GBまで拡張 No 設定項目 説明 デフォルト値 設定変更後 1 net.core.somaxconn 待機中の最大TCPコネクション数(個) 128 2,048 2 net.core.netdev_max_backlog パケット受信時にキューに接続できる最大パケット数(個) 1,000 2,048 3 net.core.rmem_max 受信ソケットバッファの最大サイズ(バイト) 212,992 1,073,741,824 4 net.core.rmem_default 受信ソケットバッファのデフォルトサイズ(バイト) 212,992 1,073,741,824 5 net.ipv4.udp_rmem_min UDP受信バッファの最小サイズ(バイト) 4,096 1,073,741,824 6 net.ipv4.udp_mem UDPの全ソケットのキューで利用可能なページ数(個) ※min、pressure、maxの順 769,677 1,026,238 1,539,354 1,610,612,736 3,221,225,472 6,442,450,944
- 23. 改善対処2: CPUリソースの拡張 • 受信バッファの拡張ではDropは収まらず、worker数等を拡張するためにCPUコア数を追加。 vCPU:4 vRAM:16GB vCPU:16 vRAM:32GB vCPU:32 vRAM:64GB No設定ファイル 設定項目 第1形態 第2形態 第3形態 1 jvm.options -Xms 1g 15g 30g 2 jvm.options -Xmx 1g 15g 30g 3 logstash.conf queue_size 2048 8192 16384 4 logstash.conf workers 4 16 32 5 logstash.yml pipeline.workers 4 16 32 6 logstash.yml pipeline.batch.size 125 1000 2000 【第1形態】 【第2形態】 【第3形態】
- 24.
- 25. 【参考】input udpの性能に影響する設定値 • OSに割り当てているCPUコア数に合わせてworkersを設定してinput処理性能を稼ぐ。 •受信バッファやキューサイズはあくまでバースト性のある通信が流れてきた時の保険でしかない。 No 設定項目 説明 デフォルト値 1 buffer_size ネットワーク上を流れる1個のUDPパケットの最大読み取りサイズ(バイト) 65,536 2 queue_size メモリに保持できる未処理のUDPパケット数(パケット) ※メモリ上のキューから溢れるとパケットがドロップする 2,000 3 receive_buffer_bytes OSがUDPパケットを受信した時のソケット受信バッファのサイズ(バイト) ※デフォルトはOSの受信バッファサイズが適用される(net.core.rmem_max) - 4 workers パケットを処理するスレッド数(個) ※CPUコア数と合わせておく 2 【参考URL】Udp input plugin https://www.elastic.co/guide/en/logstash/current/plugins-inputs-udp.html
- 26. 【参考】pipelineの性能に影響する設定値 • Pipeline処理はworker数×Batchサイズで決まるが、大きくなるとJVMヒープ領域を食う。 • GCが頻繁に発生することでCPU性能が低下する場合は、JVMヒープ領域を拡張する必要がある。 【参考URL】logstash.yml https://www.elastic.co/guide/en/logstash/current/logstash-settings-file.html No設定項目 説明 デフォルト値 1 pipeline.workers filter処理とoutput処理を並行して実行するスレッド数(個) ※OSに割り当てられたCPUコア数よりも多めに割り当てておくのが良い CPUコア数 2 pipeline.batch.size 各workerスレッドがinput処理から収集する最大イベント数(イベント) 125 3 pipeline.batch.delay input処理からfilter処理に引き渡すバッチ処理で待機する時間(ミリ秒) 50 4 queue.type filter処理前のイベントをキューイングするバッファ領域を指定 ※memoryはメモリ上、persistedはディスク上に保持 memory
- 27. 第2形態時点におけるLogstashの性能結果 【設定】 ・pipeline.workers:16 ・batch size:1,000 ・JVM Heap(max):15g 【性能】 ・受信フロー数:4,500/s ・CPU使用率:92-94% ・System Load:25-30
- 28. コア拡張(16→32)したLogstashの性能結果 【設定】 ・pipeline.workers:32 ・batch size:1,000 ・JVM Heap(max):15g 【性能】 ・受信フロー数:8,000/s ・CPU使用率:８5-90% ・System Load:35-40
- 29. BatchSizeを拡張したLogstashの性能結果 【設定】 ・pipeline.workers:32 ・batch size:2,000 ・JVM Heap(max):15g 【性能】 ・受信フロー数:9,000/s ・CPU使用率:８5-90% ・System Load:40-45
- 30.
- 31. 改善対処3: pipelineの分割 • リソース追加でも収まらず、multipipeline機能を用いて、netflowとsflowを分割。 ※ここまでNetflowの説明しかしていませんが、実はsflowの収集も実施しています...(笑) -pipeline.id: netflow path.config: "/etc/logstash/conf.d/netflow/*.conf" pipeline.workers: 32 - pipeline.id: sflow path.config: "/etc/logstash/conf.d/sflow/*.conf" pipeline.workers: 32 【pipeline.yml】 【ポイント】 pipeline.workersをpipeline単位に分割することで より並列分散処理することが出来ると期待するも取り込むフロー数に大きな変化は無し 【参考URL】Multiple Pipelines https://www.elastic.co/guide/en/logstash/current/multiple-pipelines.html
- 32. ちなみに、filter処理を全て外してみると... • Event Latencyはほぼ0msとなり、ReceivedRateが約倍増の15,000/sまで上昇した。
- 33. 今度はダメ元でQueueing方式を変更してみると... • Persistent Queueに変更したことでディスクへの書き込みIO待ちのような結果となった。 【参考URL】PersistentQueues https://www.elastic.co/guide/en/logstash/current/persistent-queues.html 【結果】 ・CPU使用率は65-80を大きくバタついた ・SystemLoadは25-45を大きくバタついた →フロー取り込み量は改善せずにDrop多発
- 34. ダメ押しで、outputの設定変更を試してみるが... • output elasticsearchの出力先を絞ることでLogstashのCPU負荷を上げられるか試した。 Elasticsearch#1 Elasticsearch#2 Elasticsearch#3 output{ elasticsearch { # hosts => [“192.168.0.1:9200”,”192.168.0.2:9200”,”192.168.0.3:9200” ] hosts => “192.168.0.1:9200” } } 192.168.0.1 192.168.0.2 192.168.0.3 【参考URL】Elasticsearch output plugin https://www.elastic.co/guide/en/logstash/current/plugins-outputs-elasticsearch.html#plugins-outputs-elasticsearch-hosts 【結果】 CPU使用率やSystemLoadは変化せず...
- 35. 改善対処4: Logstashノードの追加 • 色々試したが1台のLogstashで捌くことに限界を感じ、3ノード追加のスケールアウト構成とした。 ※NetflowExporter側で送信先のIPアドレスを変更することでバランス良く振り分ける 【1号機】 ・vcPU:32 ・vRAM:64GB 【2号機】 ・vcPU:32 ・vRAM:64GB 【3号機】 ・vcPU:32 ・vRAM:64GB 【4号機】 ・vcPU:32 ・vRAM:64GB ノード追加 NetFlow Exporter
- 36. 最終的な構成 • 以下の全コンポーネントをNutanix上に構築することで何とかフローを取り切る。 ※Exporterの機種によって、Logstashで受信出来るフロー量にも違いがあることが分かった 【1号機】 ・vCPU:32 ・vRAM:64GB 【2号機】 ・vCPU:32 ・vRAM:64GB 【3号機】 ・vCPU:32 ・vRAM:64GB 【4号機】 ・vCPU:32 ・vRAM:64GB NetFlow Exporter Elasticsearch#1 Elasticsearch#2 Elasticsearch#3 ElasticsearchCluster 【1号機】 ・vCPU:6 ・vRAM:64GB ・vDisk:2TB 【2号機】 ・vCPU:6 ・vRAM:64GB ・vDisk:2TB 【3号機】 ・vCPU:6 ・vRAM:64GB ・vDisk:2TB 合計:4,000fps 合計:9,000fps 合計:4,000fps 合計:3,500fps 総合計:20,500fps CPU使用率:75% SystemLoad:20 CPU使用率:85% SystemLoad:30 CPU使用率:85% SystemLoad:35 CPU使用率:35% SystemLoad:10
- 37. Elasticsearchの蓄積データ量 • 1週間分の蓄積データ量(Replica込み)と平日のIndexサイズ(日次)は以下の通り。 No Index名Document Count Data(GB) 対象期間 1 logstash-2018.08.06 1.1b(11億) 635.2 8/6(月)9:00-8/7(火)8:59 2 logstash-2018.08.07 1.1b(11億) 600.1 8/7(火)9:00-8/8(水)8:59 3 logstash-2018.08.08 1.1b(11億) 616.1 8/8(水)9:00-8/9(木)8:59 4 logstash-2018.08.09 1.1b(11億) 629.1 8/9(木)9:00-8/10(金)8:59 5 logstash-2018.08.10 1.0b(10億) 556.5 8/10(金)9:00-8/11(土)8:59
- 38. まとめ ✓ やってみないとどこにボトルネックが来るか見えないツラミ ⇒大量フローがないと性能検証が出来ないので、本番環境でないと見えてこない ⇒Netflowを吐く機種によってもLogstashに与える性能負荷が違った ⇒Logstashのどの処理でスタックしているのか切り分けが難しかった ✓ SystemLoad30を超えるとDrop始める傾向があった ⇒workersは上限値がないので、CPUコアの割り当てすれば性能出るはず... ⇒workers３２くらいまでは性能向上したが、48では性能に変化がなかった ⇒filter処理によるCPU負荷が全体のパフォーマンスを大きく左右する ✓トラブルシュートしながらのチューニングだったので... ⇒正直がこれが正解だったのか... ⇒Exporter毎にLogstashノードを分けておけば良かったと反省
- 39.