Sumo Logicのログ収集設計時に最初に考えること

2022.04.13

Sumo Logicでログ分析を始めたい!と思った後、まず最初にメタデータと呼ばれるログを収集するために必要なコレクターやソースの名前についての設計が必要となります。ここでは、ログ検索の最適化に利用され、設計の際に最も重要とされるソースカテゴリー(Source Category)を中心に、Sumo Logicのメタデータの名前付けについて、Sumo Logicの公式ドキュメントに従いながら考えていきたいと思います。

共通の命名規則として考慮すること

ログ収集に関する設定項目の命名規則で、まず最初に考慮するべきことは、名前に空白を使用しない方がいいということ。Sumo Logicでは空白を名前に割り当てた場合、検索時にクォーテーションやダブルクォーテーションが必要となり、ワイルドカードによる検索ができなくなってしまいます。 名前の区切りには、アンダースコア、ハイフン、ピリオドやスラッシュを使いましょう。また、特にソースカテゴリーの名前にはスラッシュを含めることをSumoでは推奨しています。(※名前に2バイト文字の入力は不可能です)

ソースカテゴリー(Source Categories)の名前設計

ソースカテゴリーは、ソース(Source)の設定時に「_sourceCategory」というフィールドとして定義することが可能で、ログの検索時に検索スピードを上げたり、検索スコープを限定することで検索を最適化するのに利用されます。Sumoの公式ドキュメントでは、ソースカテゴリーの命名には以下の3点を設計要素として検討することが必要だと記載されています。

  1. 検索するときのスコープを定義するため
  2. データをIndex(索引化)とPartition(区画化)するため
  3. Role base access control(RBAC)による、データへのアクセス制御のため

では、それぞれの検討要素について詳しく見ていきましょう。


(設計要素1)検索するときのスコープを定義するため

検索するときのスコープを定義することで、検索用途(何を見たいか)に即した柔軟なサーチを行うことが可能になります。
収集するログをビジネス側の観点あるいはIT運用管理やセキュリティ運用管理の観点で、論理的な単位に分類化します。例えば、収集する対象がApacheログだった場合に、通販ECサイト(XXシステム)の本番環境の販売者向けの出店アプリ(ZZアプリ)のアクセスログだったとします。これらの分類を広義な意味から狭義な意味への分類順に並び替え、分類同士をスラッシュで区切ります。

  • XX_Service/Prod/ZZ_App/Apache/access

これを_sourceCategoryに設定します。検索文に「_sourceCategory=XX_Service/Prod/*」とすることで、通販ECサイトの本番環境のログから検索結果を表示したいというように、検索スコープを限定し目的のログを探し出すことができます。

その他、以下の例のようにログが意味する環境や用途、ベンダー、製品などに分類して、検索時に何を見たいかを事前に検討し決定していきます。※後述の検討要素2、検討要素3も踏まえて決定します。

  • IT/Network/Firewall/Cisco/ASA
  • IT/Network/AP/Aruba
  • Service/Prod/App/StoreFront
  • Service/Dev/App/Shipment
  • Audit/Sorbox
  • Sandbox/Jimmy/linuxtest
  • Debug/CustomApplication/Foo

Sumoドキュメント参考:


(設計要素2)データをIndex(索引化)とPartition(区画化)するため

ログの検索の高速化のため、Partitionという論理的なデータ領域に区画化することで、ログ検索時にIndex(索引化)単位で検索することができます。こちらはスキャンする時のデータの範囲を絞り込むことでデータ検索の効率化を図ることを目的としています。
SumoコンソールのManage Data > Logs > PartitionsからPartitionの設定が可能で、Partition名(任意でOK)とRouting Expressionを設定します。このRouting Expressionに_sourceCategoryを指定することで、Sumoへのログ取り込み時にIndex化が行われ、検索時にスキャン対象となるデータを局所化することができます。

Partitionの設定

PartitionによるIndex化のイメージ

これにより、実際の検索の時に「_sourceCategory=Prod/*」のようなサーチ文を入れると、全体のデータの中からIndex化されたProdの部分のデータだけを検索対象とし、検索を高速化させることができます。
SumoではIndexの断片化やデータ管理の観点からPartitionの最大数を20までとすることを推奨としています。

Sumoドキュメント参考:


(設計要素3)Role base access control(RBAC)による、データへのアクセス制御のため

データへのアクセスを制御するのにソースカテゴリーを利用します。Sumoユーザーの役割に応じて、環境や地理的情報、組織単位でのアクセス制御を検討します。データへのアクセス制御設定は、Administration > Users and Roles > RolesのSearch Filterで設定できます。グループ会社や部署毎にデータへのアクセス制限を行いたい場合は、ソースカテゴリーに分類として含めるように設計しましょう。

  • AWS/XXXX-XXXX-XXXX(Account ID)/Prod/CloudTrail

Sumoドキュメント参考:

その他のメタデータの名前設計

コレクター(Collector)の名前設計

コレクターの名前はコレクターがアクティベーションされた時に入力された値になります。Installed Collectorの場合、収集される側のホストでコレクター(エージェント)をインストールする時に設定することができます。通常ホスト名を入力します。Hosted Collectorの場合、Sumoのコンソール上でコレクターを設定する時に指定します。好きな名前を設定しましょう。

ソース(Source)の名前設計

ソースの名前はソースが作成された時に入力された値になります。最長128文字の制限があります。好きな名前を設定しましょう。

ソースホスト(Source Host)の名前設計

ソースホストの名前はログの収集元となるデバイスのOSレベルでの実際のホスト名をSumoが自動的に取得して設定されます。いくつかのソースの設定ではソースホストを任意の値で書き換えることが可能です。ログの収集元となるデバイスに対して、ユニークに特定できるための階層的な名前があれば設定しましょう。最長128文字の制限があります。

  • Location/Purpose/UID
  • SF/MySQL/Primary
  • Boston/FW/Secondary
  • USEast_Hadoop_37

これらの定義したソースホストは検索時に以下のように活用することができます。

  • _sourceHost=*USEast*
  • _sourceHost=*MySQL*
  • _sourceHost=*FW*

ソース名(Source Name)の名前設計

ソース名の名前はソースの設定時に取得するログのファイルパスが設定されます。取得するログファイルが複数存在している場合、それぞれが_sourceNameにセットされます。

Sumoドキュメント参考:


上記のメタデータについても、目的に応じた検索条件として活用することが可能となりますが、何と言っても「ソースカテゴリー(Source Categories)」の設計が最も重要となります。

まとめ

いかがでしょうか。ログ収集を始める前にメタデータの設計をすることで、柔軟な検索文を作れたり、ログ検索の高速化を図ることが可能となります。Sumo Logicでログ分析を始めたいと思った際には、参考にしていただけたらと思います。