メインコンテンツまでスキップ
Sumo Logic Japanese

ベスト プラクティス: Good Source Category, Bad Source Category (良いソース カテゴリ、悪いソース カテゴリ)

ソース カテゴリ値 (_sourceCategory) の設定は、特に小規模なソースの場合、最初は小さなことに思えるかもしれません。しかし、正しい命名規則に従って良いソース カテゴリ値を作成することは、長期にわたって Sumo Logic のデプロイを正しく拡張してパフォーマンスを引き出すために重要です。このトピックでは、良いソース カテゴリ値の作成に関するベスト プラクティスをいくつか紹介します。

ソース カテゴリでできること

  • 検索の範囲を定義する。
  • データをインデックス化してパーティション化する。
  • RBAC を通じてデータを表示できるユーザを制御する。

推奨される _sourceCategory の命名規則

component1/component2/component3…

具体性が低い最上位のグループ化から始めて、各コンポーネントをより具体的に説明していきます。値全体でデータのサブセットを詳細に説明するようにします。

たとえば、次のような数種類のファイアウォール アプライアンスがあるとします: Cisco の ASA と FWSM、Palo Alto Networks の 7050。さらに、Cisco ルータの 800 シリーズもあるとします。

上記の命名規則に従い、(単純に「FWSM」や「ASA」などを使用するのではなく) 次の _sourceCategory 値を設定することもできます。

Networking/Firewall/Cisco/FWSM
Networking/Firewall/Cisco/ASA
Networking/Firewall/PAN/7050
Networking/Router/Cisco/800

値の先頭にあるコンポーネントは具体的な値を追加するものではなく、このデータの最上位のグループ化になります。これにより、ソース カテゴリの 3 つの目的を達成できます。

検索の範囲を定義する

ここで説明している命名規則に従えば、検索の範囲を簡単かつ効果的に定義できます。

たとえば、次のいずれかの _sourceCategory 値を使用するとします。

_sourceCategory=Networking/Firewall/* (すべてのファイアウォール データ)
_sourceCategory=Networking/*/Cisco/* (すべての Cisco データ)

ワイルドカードを使用すれば、ブール ロジック (OR) を追加しなくてもデータのサブセットを見つけることができます。

データをインデックス化してパーティション化する

パフォーマンスを高めるためにネットワーキング データの個別のパーティションを作成するには、次のルーティング式を使用してパーティションを指定します。

_sourceCategory=Networking*

パーティションは作成後に変更できないため (廃止して新しい名前またはルーティング式で作成し直すしかありません)、あまり頻繁に変更せずに済むようにしてください。

RBAC を通じてデータを表示できるユーザを制御する

インデックスを使用した場合と同じように、このデータ セットへのアクセスを制限するために、データが増えたときに上位の値を使用して管理するデータ量を削減することができます。

上位のグループ化はさまざまな項目で構築できます。たとえば、環境の詳細 (運用環境か開発環境か)、地理情報 (東か西か)、アプリケーション、事業単位、その他データに適した値を基準にグループ化できます。

これらの値を使用する順序は、データの検索方法によって決まります。

たとえば、ほとんどの使用事例で運用環境と開発環境の両方のデータが必要でない場合、次の _sourceCategory 値を使用できます。

Prod/Web/Apache/Access
Dev/Web/Apache/Access
Prod/DB/MySQL/Error

Dev/DB/MySQL/Error

必要に応じて、引き続き運用環境と開発環境の両方で検索を行うことはできますが、このスキームによってより直感的にすべてのデータが運用環境と開発環境に分けられます。

一方、この両方のデータを頻繁に検索する必要がある場合には、次の値を使用できます。

Web/Apache/Access/Prod
Web/Apache/Access/Dev
DB/MySQL/Error/Prod
DB/MySQL/Error/Dev

このようにシンプルに変更するだけで、上位のグループ化が完全に変更されます。どちらのスキームでも、両方の使用事例にシンプルに対応できます。重要なのは、ユーザがデータを検索するときに自然だと感じられる方法でデータをグループ化することです。  

  • この記事は役に立ちましたか?