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

ベスト プラクティス: 守るべき検索ルール

Sumo Logic の検索を最大限に活用するために、これらの簡単なルールを用いてください。

ルール 1 - 検索範囲を限定する

少なくともすべての検索で、範囲内のメタデータタグを 1 つ以上使用する必要があります。たとえば、_sourceCategory、_source、_sourceName、_sourceHost、_collector などです。

可能であれば、範囲を限定するために 1 つ以上のキーワードも使用してください。

ルール 2 - 検索の時間範囲を制限する

ユース ケースに必要な最低限の時間範囲を使用します。長期間にわたってデータを確認する場合は、最初に短い時間範囲で検索を作成してテストし、検索が完了したら時間範囲を延ばします。

ルール 3 - FER によって parse されたフィールドを使用し、where operator の使用を避ける

できる限り where operator を使用せずに、キーワード検索と、FER (Field Extraction Rules) によって parse されたフィールドを使用して、データを絞り込みます。キーワードと事前に parse されたフィールドのみの使用で実行できない場合は、キーワード検索と where 句の両方を使用します。

最善の方法 - FER (Field Extraction Rules) フィールドとキーワード

_sourceCategory=foo and fielda=valuea

適切な方法 - キーワード検索と where operator

_sourceCategory=foo and valuea
| parse "somefield *" as somefield
| where somefield="valuea"

最も避けたい方法 - キーワード検索なし、事前に parse されたフィールドなし:

_sourceCategory=foo
| parse "somefield *" as somefield
| where somefield="valuea"

ルール 4 - 集計前にデータをフィルタする

データをフィルタするときは、sum、min、max、average などの集計の操作を実行する前に、使用している結果セットをできるだけ小さくします。ルール 1 で説明しているように、検索範囲内のキーワードとメタデータを使用することを優先してください。where 句を使用する必要がある場合は、ルール 3 を参照してください。

最善の方法

_sourceCategory=Prod/User/Eventlog user="john"
| count by user

最も避けたい方法

_sourceCategory=Prod/User/Eventlog
| count by user
| where user="john"

ルール 5 - 構造化されたメッセージには parse regex ではなく parse anchor を使用する

ルール 3 で説明しているように、事前に parse されたフィールドを使用することが最善の方法です。事前抽出されていないフィールドを parse する必要がある場合は、parse anchor を使用してください。より複雑な構造化されていないメッセージを処理している場合は、parse regex を使用し、FER (Field Extraction Rules) 内に配置します。

ルール 6 - parse regex を使用するときには負荷の大きなトークンを避ける

parse regex を使用する必要がある場合は、「*」のような負荷の大きな操作を使用しないでください。ルール 1 の検索範囲についての説明と同じように、正規表現でもできるだけ検索対象を限定します。

ログ メッセージの例  

52.87.131.109 - - [2016-09-12 20:13:52.870 +0000] "GET /blog/index.php HTTP/1.1" 304 8932

最善の方法

| parse regex "(?<client_ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\s"

最も避けたい方法

| parse regex "(?<client_ip>.*)\s-"

ルール 7 - パーティションと Scheduled View を使用する

Sumo には、パーティションと Scheduled View の 2 つのインデックスベースの検索最適化機能があります。パーティションまたは Scheduled View に対して検索を実行すると、検索の対象となるデータ セットが小規模で済むため、検索結果がよりすばやく効率的に返されます。詳細については、「検索パフォーマンスの最適化」を参照してください。

ルール 8 - 検索パラメータを使用する

検索にフィルタリング条件が含まれていて、検索を実行するたびにこの条件が変化する可能性がある場合は、検索テンプレートを利用します。検索テンプレートを使用することで、経験が浅いユーザでも検索結果を得やすくなります。また、そのようなユーザが負荷の大きな検索を実行してしまうリスクを低減できます。

ルール 9 - ルックアップの前に集計する

可能な限り、ルックアップを行う前にデータを集計します。場合によっては、それによってルックアップが参照するデータの量が大幅に減少します。

最善の方法

| count by client_ip
| lookup is_bad_ip from shared/bad/ips on client_ip=ip

避けたい方法

| lookup is_bad_ip from shared/bad/ips on client_ip=ip
| count by is_bad_ip

ルール 10 - パイプ区切りの演算は改行する

読みやすくするために、クエリ フィールドでソフト リターンを使用して、新しいパイプ区切りの操作ごとに改行します。

最善の方法

_sourceCategory=Apache/Access and GET
| parse "\"GET * HTTP/1.1\"\" * * \"\"*\"\"" as url,status_code,size,referrer
| count by status_code,referrer
| sort _count

避けたい方法

_sourceCategory=Apache/Access and GET | parse "\"GET * HTTP/1.1\"\" * * \"\"*\"\"" as url,status_code,size,referrer | count by status_code,referrer | sort _count

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