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

酒井剛

2022.04.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

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

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

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

ソースカテゴリー（Source Categories）の名前設計

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

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

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

（設計要素１）検索するときのスコープを定義するため

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

XX_Service/Prod/ZZ_App/Apache/access

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

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

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ドキュメント参考：

（設計要素２）データを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の最大数を２０までとすることを推奨としています。

Sumoドキュメント参考：

（設計要素３）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文字の制限があります。