ベスト プラクティス: 守るべき検索ルール
ルール 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