ログ分析におけるElasticStackの勘所
www.slideshare.net
※ESはver7.0
時系列データの勘所
- 時刻情報を持つイベントデータ(ログ/メトリックス) , 時刻データが大事
- logstashやBeatsから取り込んだ時系列データは自動的にローテートしてくれる(indexの肥大化を防ぐ、ただしUTC)
セキュリティにおけるログとは
- フォレンジック調査
- ハンティング業務(驚異を見つけるために主体的に見に行く)
- 監査
- 監視業務
ElasticStack
- Kibana+elasticsearch+(beats+logstash)
beats
- beats family
- metricsをとるならmetricbeatのような感じ
- ちなみにgoで書かれている
logstash
- beatsで取り込んだものの加工
- DB接続
beatsとlogstash
- beatsはagent投入してelastic stackへ投げるようなもの 軽量
logstashはソースとフィルタが多様
機械学習したいならElastic Cloudがいいかも
- AWS ES
- Open Distro for ES
Elasticsearchの設計
- nodeの役割がいろいろある。兼務もできるし専用ノードでもいける
- メモリとストレージの設計において JVM Heapを効率良くできるかがポイント
全文検索と時系列データの違い
- 全文検索はcache上にのこるか。がポイント
- 時系列はwritecacheの方がおおいはず。 なのでread cacheには乗らないのでDiskから読むようになる。
なのでDiskのI/O性能が大切
スキーマ定義は?
- やったほうがいい。stringで格納されるので分析したいのが正しく分析できなくなる
Elastic SIEMってのがでたよ
- OSSじゃないけどBasicなので無料で使える
ETL
parseとenrich
- parse: csvをパースする
- enrich IPをhostにしたり、 blackリストのIPであればflag立てたり
- ログの加工はいろいろ流派ある。
- ログ自体を加工する
- logstashで加工する (前処理
- elasticsearchで引っ張ってきたデータをあとから加工する(後処理
plugin作るか、rubyfilter書くか
ESにつっこめなかったのはDeadLetterQueueにファイルとして突っ込める。 これをLogstashで再取り込みする
- logstashのfingerprint filterで一位になるようなIDを生成してdocument_idで突っ込む
Molochではじめるネットワークフォレンジック
ネットワークフォレンジック
- ネットワークログ = パケットデータの情報収集・侵入検知など
パケットキャプチャ
- エンドポイントでキャプチャする
- ミラーリングしてネットワーク経路上でキャプチャする
課題
Moloch
splunk→ ElasticStackで芽生えたなにか
- 用途に応じて複数存在しているログ分析システムを統合するかどうか
- AWS上でElasticStack環境を構築して、オンプレミス環境からログを転送する構成とした。
- 各パイプラインごとにLogStashをFargate上にデプロイしている。
- 外はEC2運用
- オンプレからS3へログ転送 するLogStashと実際にESに入れるLogStashがある。
問題
- Logstashのinput s3はスケールアウトできない
- S3に入っているデータをQueueに突っ込んだりするのは別にする必要がある
まとめ
- 時系列データで性能を出そうとするとインフラコストかかる
- 長期データはあまり向かないかも？
