【勉強会メモ】オープンソースで実現するログ分析技術入門
3574 ワード
はじめに
先日 ログ分析技術に関する勉強会 に参加しました。
その際個人的に印象に残った点をまとめます。
イベント概要
オープンソースで実現するリアルタイムログ分析のポイントをお伝えします!
Elasticsearchは現在GitHubにおけるStar数が40,000を超える最も人気のある全文検索エンジンです。
昨年末には累計3.5憶ダウンロードを突破し、IPOを実現したオープンソース企業の中でも非常に注目される存在です。本勉強会では、そんなElasticsearchを「全文検索」ではなく、「ログ分析」のユースケースとして
これまで培ってきたノウハウやナレッジについて、余すところなくご紹介します。
発表
ログ分析におけるElasticStackの勘所 / 株式会社リクルートテクノロジーズ 日比野 恒さん
- ログデータの活用事例
- マーケティング
- ITインフラ運用
- セキュリティ分析
- セキュリティ分析におけるログ解析
- フォレンジック調査業務
- ハンティング業務
- 監査業務(Reporting)
- 監視業務(SIEM)
- 短期データを定型的なクエリで調査する監視業務(SIEM)はElasticsearchを使用するのに向いている
- ElasticStackにおけるログ解析フロー
- Logstash(or Beats) -> Elasticsearch -> kibana
- LogstashとBeatsはデータの取り込みに使用
- 取り込みデータを加工したりするのであればLogstashを使用
- 取り込むだけでよいならBeatsを使用
- Beatsで取り込んでさらにLogstashで加工してElasticsearchへみたいな形もあり
- Logstashから取り込まれた時系列データは自動でローテートされる
- ただしUTC時間での切り替え
- ログ分析システム構築はまずは小さく始めていく
- 用途に応じてクラウド版かオンプレ版か
- ElasticCloud
- ElasticStack
- Amazon ES
- Open Distro
- Open Distroでは、ElasticStackでは有償機能であるアラート通知などがOSSとして利用できる!
- Elasticsearchの設計ポイント
- JVM Heapのサイズは物理メモリの50%もしくは32GB未満
- シャードの数はHeapの1GBに対して20個以下にする
- シャードのサイズは15~40GB
- 物理メモリのサイズはストレージサイズの3%
- 全文検索と時系列データではキャッシュのききかたが変わってくる
- 全文検索では読み込みがメインなので、いかにreadキャッシュにデータを載せるかがポイント
- 時系列データは書き込みがメインなので、writeキャッシュでいっぱいになるのでreadキャッシュがききにくい
- ログ加工は前処理で行うことがElasticsearch的に推奨
- 取り込み前にpythonなどで加工
- もしくはLogstashのFilterで加工
- ログ取り込み失敗を検知する仕組みとしてDead Letter Queue
- ログ取り込み失敗のリトライに重要なこと
- 生ログの確保
- べき等性
【事例紹介】NWフォレンジックにおける活用事例 / 株式会社NTTデータ 掛飛 聡佑さん
- Molochとはパケット解析ツール
- パケットをElasticsearchに取り込みWeb UIで解析するような使い方
- indexのtemplate設定はREST APIではなくMolochのスクリプト(db.pl)で設定する
- Molochの構成として
- パケットを取得する
capture
- Weeb UIを提供する
viewer
- マーケティング
- ITインフラ運用
- セキュリティ分析
- フォレンジック調査業務
- ハンティング業務
- 監査業務(Reporting)
- 監視業務(SIEM)
- 短期データを定型的なクエリで調査する監視業務(SIEM)はElasticsearchを使用するのに向いている
- Logstash(or Beats) -> Elasticsearch -> kibana
- 取り込みデータを加工したりするのであればLogstashを使用
- 取り込むだけでよいならBeatsを使用
- Beatsで取り込んでさらにLogstashで加工してElasticsearchへみたいな形もあり
- ただしUTC時間での切り替え
- ElasticCloud
- ElasticStack
- Amazon ES
- Open Distro
- Open Distroでは、ElasticStackでは有償機能であるアラート通知などがOSSとして利用できる!
- JVM Heapのサイズは物理メモリの50%もしくは32GB未満
- シャードの数はHeapの1GBに対して20個以下にする
- シャードのサイズは15~40GB
- 物理メモリのサイズはストレージサイズの3%
- 全文検索では読み込みがメインなので、いかにreadキャッシュにデータを載せるかがポイント
- 時系列データは書き込みがメインなので、writeキャッシュでいっぱいになるのでreadキャッシュがききにくい
- 取り込み前にpythonなどで加工
- もしくはLogstashのFilterで加工
- 生ログの確保
- べき等性
- パケットを取得する
capture
- Weeb UIを提供する
viewer
※発表スライドを読み返そうと思ったのですが、公開されていないため、あまり書けなかったです。。。
【事例紹介】{ "S" => "E" } で改めて芽生えた何か / 株式会社リクルートテクノロジーズ 日比野 恒さん
- LogstashのS3 inputプラグインとAWS Fargateの相性があまりよろしくないらしい
- Logstashタスクを並列処理してもうまくいかず、処理が重複されてしまった
- 生ログからElasticsearchへ取り込むログはサイズが肥大化する
- CSVからJSON形式に変換するのにも単純にサイズが肥大
- さらに加工処理をすることでサイズが肥大
- kibanaでは絞り込んだ条件からさらに絞り込みを行うサブクエリ検索ができない
- Elasticsearchに取り込み後のデータを加工することは難しい
- 前処理で加工することが推奨されているため
おわりに
個人的には、メモリサイズやストレージサイズの決め方、取り込むデータの性格(全文検索と時系列データ)によってキャッシュのききかたが変わってくる、などOSリソースをいかに有効活用するかといった話に興味を持ちました。
ちょうどOSのリソースについて勉強しているところだったので大変参考になりました。
Author And Source
この問題について(【勉強会メモ】オープンソースで実現するログ分析技術入門), 我々は、より多くの情報をここで見つけました https://qiita.com/shinyashikis@github/items/4288c90c11d274f130c8著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .