すべてのプロダクト
Search
ドキュメントセンター

Simple Log Service:検索構文と関数

最終更新日:Oct 16, 2025

Simple Log Service (SLS) では、検索文を実行して Logstore に保存されているログをクエリできます。検索結果は、個別に使用することも、分析文の入力として使用して複雑なデータ分析を実行することもできます。

前提条件

インデックスが作成されている

基本構文

各クエリ文は、検索文と分析文で構成されます。検索文と分析文は、縦棒 (|) で区切られます。クエリ文の例:

* | SELECT status, count(*) AS PV GROUP BY status

説明

検索文

検索文は、1 つ以上の検索条件を指定します。キーワード、数値、範囲、またはアスタリスク (*) などの検索文で検索条件を指定します。スペースまたはアスタリスク (*) を指定すると、すべてのログに一致します。

重要

検索文には最大 30 個の検索条件を指定します。

分析文

重要

分析文に FROM 句や WHERE 句を指定する必要はありません。デフォルトでは、現在の Logstore のすべてのデータが分析されます。分析文では大文字と小文字は区別されず、オフセットはサポートされず、末尾にセミコロン (;) を付ける必要もありません。

分析文は、検索結果または Logstore 内のすべてのデータを集計または分析するために使用されます。SLS がログの分析でサポートする関数と構文の詳細については、次のトピックをご参照ください。

検索文の作成プロセス

クエリ文を作成するには、次のステップを実行します。

ステップ 1: 検索タイプを選択する

重要

クエリと分析の結果は、インデックスの構成によって異なります。フルテキストインデックスとフィールドインデックスを作成した場合、フィールドインデックスが優先されます。

検索は、インデックスタイプに基づいて全文検索とフィールド指定検索に分類されます。全文検索とフィールド指定検索の違いは次のとおりです。

  • Logstore にフルテキストインデックスのみを作成する場合は、全文検索構文のみを使用してクエリ条件を指定します。

  • Logstore にフィールドインデックスを作成する場合、検索構文はフィールドのデータ型によって異なります。

    • double および long: フィールド指定検索構文のみを使用してクエリ条件を指定します。

    • text: キーワードの関連フィールドがわかっており、フィールドインデックスが作成されている場合は、クエリ条件にフィールド指定検索構文を使用します。関連フィールドが不明な場合は、全文検索構文を使用します。

      • 全文検索が無効になっている場合、テキストインデックスが個別に有効になっているフィールドでのみ全文検索を実行できます。

      • フルテキストインデックスが作成されている場合、すべてのフィールドからデータをクエリし、インデックス付けされたすべてのデータは text 型になります。

全文検索

全文検索構文を使用して特定のフィールドからデータをクエリすることはできません。全文検索構文: keywords1 [ [ and | or | not ] keywords2 ] ...

Keywords1 は、データをクエリするためのキーワードを指定します。アスタリスク (*) と疑問符 (?) をあいまい一致に使用することもできます。クエリ条件を組み合わせるには、andor などのオペレーターを使用します。

  • 例 1

    GET キーワードを含むログをクエリします。検索構文: GET

  • 例 2

    GET または POST キーワードを含むログをクエリします。検索構文: GET or POST

  • 例 3

    Jo で始まるログ (Joe や Jon など) をクエリします。検索構文: Jo?

フィールド指定検索

フィールドにインデックスが付けられている場合、数値比較や正規表現マッチングなどの型固有の操作を実行します。

重要
  • indexname1 は、データをクエリするフィールドの名前を指定します。フィールド名やテーブル名などの固有名詞に、スペースや漢字などの特殊文字、または andor などの構文キーワードが含まれている場合は、固有名詞を二重引用符 ("") で囲む必要があります。詳細については、「クエリ文で引用符を使用する方法」をご参照ください。

  • long または double 型のフィールドにインデックスが作成されている場合は、次の比較演算子を使用します: >>=<<==、および in

検索構文

indexname1 [ : | > | >= | < | <= | = | in ] keyword1 [ [ and | or | not ] indexname2 ... ]
  • 例 1

    request_method フィールドの値が GET であるログをクエリします。検索構文: request_method: GET

  • 例 2

    request_time_msec フィールドの値が 50 より大きいログをクエリします。検索構文: request_time_msec>50。request_time_msec フィールドは double 型です。

  • 例 3

    request_method フィールドの値が GET で、request_time_msec フィールドの値が 50 より大きいログをクエリします。検索構文: request_method: GET and request_time_msec>50

ステップ 2: フィールドのデータ型を選択する

検索文を作成するときは、フィールドのデータ型を考慮し、正しいオペレーターを使用して効率的かつ正確にログを取得します。

フィールドのデータ型

フィールドのデータ型

説明

サポートされているオペレーター

text

関連フィールドのデータ型を text に設定して、文字列型のデータをクエリします。デフォルトでは、全文検索を有効にすると、ログ内の __time__ フィールドを除くすべてのフィールドのデータ型が text に設定されます。

andornot():""\*、および ?

long または double

フィールドのデータ型を long または double に設定した場合にのみ、数値範囲を使用してフィールドの値をクエリします。

  • フィールドのデータ型を double または long に設定しない場合、または数値範囲の構文が無効な場合、SLS は全文検索を実行し、検索結果が期待される結果と異なる場合があります。

    たとえば、owner_id>100 検索文を実行し、owner_id フィールドのデータ型が double または long でない場合、owner_id>、および 100 を含むログが返されます。この例では、大なり記号 (>) はデリミタではありません。

  • フィールドのデータ型を text から double または long に変更した場合、等号 (=) のみを使用してデータをクエリします。範囲や、大なり (>) や小なり (<) 記号などの比較演算子を使用してデータをクエリする場合は、データを再インデックス化する必要があります。詳細については、「Logstore のログを再インデックス化する」をご参照ください。

andornot()>>=<<==、および in

json

JSON オブジェクト内のフィールドのデータ型を、フィールド値に基づいて longdouble、または text に設定し、そのフィールドの [分析を有効にする] をオンにします。

JSON オブジェクト内のフィールドのデータ型に基づいてオペレーターを指定します。

オペレーター

重要
  • in オペレーターの文字は小文字でなければなりません。他のオペレーターでは大文字と小文字は区別されません。

  • SLS は次のオペレーターをサポートしています: sortascdescgroup byavgsumminmax、および limit。これらのオペレーターをキーワードとして使用する場合は、オペレーターを二重引用符 ("") で囲む必要があります。

  • 次のオペレーターは優先度の高い順にリストされています:

    1. コロン (:)

    2. 二重引用符 ("")

    3. 括弧 ()

    4. AND AND NOT

    5. or

オペレーター

説明

:

このオペレーターは、キー:値のフォーマットに基づいてフィールド指定検索に使用されます。例: request_method:GET

フィールド名またはフィールド値にスペース、コロン (:)、ハイフン (-) などの特殊文字が含まれている場合は、フィールド名またはフィールド値を二重引用符 ("") で囲む必要があります。例: "file info":apsara

and

and オペレーター。例: request_method:GET and status:200

明示的なオペレーターなしで複数のキーワードが指定された場合、それらは暗黙的に and で結合されます。たとえば、GET 200 cn-shanghaiGET and 200 and cn-shanghai と同等です。

or

or オペレーター。例: request_method:GET or status:200

not

not オペレーター。例: request_method:GET not status:200 または not status:200

( )

このオペレーターは、括弧 () で囲まれたクエリ条件の優先度を上げるために使用されます。例: (request_method:GET or request_method:POST) and status:200

""

このオペレーターは、構文キーワードを囲むために使用されます。構文キーワードが二重引用符 ("") で囲まれている場合、そのキーワードはオペレーターではなくリテラル文字列として扱われます。フィールド指定検索では、二重引用符 ("") で囲まれた単語は全体として見なされます。

  • フィールド名またはフィールド値にスペース、漢字、コロン (:)、ハイフン (-) などの特殊文字、または andor などの構文キーワードが含まれている場合は、フィールド名またはフィールド値を二重引用符 ("") で囲む必要があります。たとえば、"and" は、単語 "and" をオペレーターではなく term として扱い、それを含むログを返します。

  • SLS は次のオペレーターをサポートしています: sortascdescgroup byavgsumminmax、および limit。これらのオペレーターをキーワードとして使用する場合は、オペレーターを二重引用符 ("") で囲む必要があります。

  • ログがデータ変換機能または Logtail プラグインを使用して処理される場合、__tag__:__client_ip__ フィールドのキーは共通キーに変換されます。ログを検索する場合は、検索文で __tag__:__client_ip__ フィールドの名前を二重引用符 ("") で囲む必要があります。例: "__tag__:__client_ip__":192.0.2.1__tag__:__client_ip__ フィールドは SLS の予約済みフィールドです。このフィールドは、ログが収集されたホストの IP アドレスを示します。詳細については、「予約済みフィールド」をご参照ください。

\

エスケープ文字。この文字は、二重引用符 ("") をエスケープするために使用されます。二重引用符 ("") は、エスケープされた後にのみそれ自体を示すことができます。たとえば、ログの内容が instance_id:nginx"01" の場合、instance_id:nginx\"01\" 文を実行してログを検索します。

*

ワイルドカード文字。0 個以上の文字に一致させるために使用されます。例: host:www*com

説明

パフォーマンスのため、ワイルドカード検索はすべてのデータをスキャンしません。代わりに、SLS はまずインデックス辞書から最大 100 個の一致する term を見つけ、それらの term のいずれかを含むログを返します。

?

ワイルドカード文字。1 つの文字に一致させるために使用されます。例: host:aliyund?c

>

このオペレーターは、フィールドの値が特定の数値より大きいログをクエリするために使用されます。例: request_time>100

>=

このオペレーターは、フィールドの値が特定の数値以上であるログをクエリするために使用されます。例: request_time>=100

<

このオペレーターは、フィールドの値が特定の数値より小さいログをクエリするために使用されます。例: request_time<100

<=

このオペレーターは、フィールドの値が特定の数値以下であるログをクエリするために使用されます。例: request_time<=100

=

このオペレーターは、フィールドの値が特定の数値と等しいログをクエリするために使用されます。等号 (=) とコロン (:) は、double または long 型のフィールドに対して同じ効果があります。たとえば、request_time=100request_time:100 と同等です。

in

このオペレーターは、フィールドの値が特定の数値範囲内にあるログをクエリするために使用されます。角括弧 [] は閉区間を示し、括弧 () は開区間を示します。スペースは、数値範囲内の 2 つの数値を区切るために使用されます。例: request_time in [100 200] または request_time in (100 200]

重要

in オペレーターの文字は小文字でなければなりません。

__source__

このオペレーターは、特定のログソースのログをクエリするために使用されます。ワイルドカード文字がサポートされています。例: __source__:192.0.2.*

重要

__source__ フィールドは SLS の予約済みフィールドです。このフィールドは source に短縮できます。カスタムの source フィールドを構成すると、カスタムフィールドは SLS の予約済み source フィールドと競合します。カスタムフィールドを検索する場合は、検索文で Source または SOURCE を使用する必要があります。

__tag__

このオペレーターは、メタデータを使用してログをクエリするために使用されます。例: __tag__:__receive_time__:1609837139

__topic__

このオペレーターは、特定のログトピックのログをクエリするために使用されます。例: __topic__:nginx_access_log

ステップ 3: 一致モードを選択する

キーワードとビジネス要件に基づいて、完全一致検索またはあいまい検索を使用します。

検索タイプ

説明

完全一致検索

検索には完全な単語が使用されます。

SLS は単語分割を使用してログをクエリします。完全一致検索では、フレーズを完全に一致させることはできません。たとえば、abc def 検索文は、abcdef を含むログを返します。フレーズ abc def は完全に一致させることはできません。abc def フレーズを完全に一致させたい場合は、フレーズ検索を実行するか、LIKE 句を使用します。詳細については、「フレーズ検索」および「完全一致を使用してログをクエリする方法」をご参照ください。

  • host:example.com: host フィールドの値に example.com が含まれるログを返します。

  • PUT and cn-shanghai: PUTcn-shanghai キーワードを含むログを返します。

  • * | Select * where http_user_agent like '%like Gecko%': http_user_agent フィールドの値に like Gecko フレーズが含まれるログを返します。

  • #"redo_index/1": redo_index/1 フレーズを含むログを返します。

あいまい検索

あいまい検索を実行するときは、検索文の単語の途中または末尾にワイルドカード文字としてアスタリスク (*) または疑問符 (?) を追加します。単語の長さは 1 ~ 64 文字である必要があります。単語にワイルドカード文字が含まれている場合、SLS はすべてのログを検索して、その単語に一致する 100 個の単語をクエリします。次に、SLS はそれらの単語の 1 つ以上を含むログを返します。より正確な単語を指定すると、検索結果はより正確になります。

重要
  • 単語の先頭にアスタリスク (*) または疑問符 (?) を追加することはできません。

  • long および double データ型は、あいまい検索でのアスタリスク (*) または疑問符 (?) をサポートしていません。数値範囲を指定してあいまい検索を実行します。例: status in [200 299]。

あいまい検索は、次のメカニズムを使用するサンプルクエリです:

  • フィールドインデックス機能を有効にして、ログをクエリするフィールドを指定すると、SLS はそのフィールドのインデックス付きデータからランダムサンプルを取得して結果を返します。SLS は全文スキャンを実行しません。

  • 全文検索機能を有効にして、ログをクエリするフィールドを指定しない場合、SLS はすべてのフィールドのインデックス付きデータからランダムサンプルを取得して結果を返します。SLS は全文スキャンを実行しません。

  • request_time>60 and request_method:Ge*: request_time フィールドの値が 60 より大きく、request_method フィールドの値が Ge で始まるログを返します。

  • addr*: すべてのログで addr で始まる 100 個の単語をクエリし、それらの単語の 1 つ以上を含むログを返します。

  • host:www.yl*: すべてのログの host フィールド値で www.yl で始まる 100 個の単語をクエリし、それらの単語の 1 つ以上を含むログを返します。

詳細については、「あいまい一致を使用してログをクエリする方法」をご参照ください。

検索文の例

異なるインデックス構成に基づいて異なるログに対して検索文を実行すると、文は異なる結果を返します。このセクションで提供される例は、次のサンプルログとインデックス構成に基づいています。

text、double、long 型

サンプルログ

サンプルログとして NGINX アクセスログが使用されます。

日志样例

インデックス構成

インデックスを作成してから検索文を実行します。インデックス構成を確認するには、次のステップを実行します。

  1. Logstore の [クエリと分析] ページで、[インデックス属性] > [属性] を選択します。image

  2. [検索と分析] パネルで、フィールドインデックスが構成されているかどうかを確認します。索引

一般的な検索例

期待される検索結果

検索文

デバッグ

成功した GET リクエストを記録したログ (状態コード: 200 ~ 299)。

request_method:GET and status in [200 299]

デバッグ

中国 (杭州) リージョンから発信されていない GET リクエストのログ。

request_method:GET not region:cn-hangzhou

なし

GET リクエストまたは POST リクエストを記録したログ。

request_method:GET or request_method:POST

デバッグ

GET リクエストを記録していないログ。

not request_method:GET

デバッグ

成功した GET または POST リクエストを記録したログ。

(request_method:GET or request_method:POST) and status in [200 299]

デバッグ

失敗した GET または POST リクエストを記録したログ。

(request_method:GET or request_method:POST) not status in [200 299]

デバッグ

成功した GET リクエスト (状態コード: 200 ~ 299) を記録し、リクエスト期間が 60 秒未満のログ。

request_method:GET and status in [200 299] not request_time>=60

デバッグ

リクエスト期間が 60 秒に等しいログ。

request_time:60

デバッグ

request_time=60

デバッグ

リクエスト期間が 60 秒以上 200 秒未満のログ。

request_time>=60 and request_time<200

デバッグ

request_time in [60 200)

デバッグ

request_time フィールドが存在するかどうか。

request_time:*

デバッグ

request_time フィールドが空であるか、フィールド値が無効な数値であるログ。

(request_time:"") or (not request_time > -10000000000)

デバッグ

request_time フィールドを含み、フィールド値が数値であるログ。

request_time > -1000000000

デバッグ

and を含むログ。

"and"
説明

単語 and はリテラル文字列として扱われ、オペレーターとしては扱われません。

デバッグ

request method フィールドの値が PUT であるログ。

"request method":PUT
重要

request method フィールドの名前にはスペースが含まれています。検索文ではフィールド名を二重引用符 ("") で囲む必要があります。

なし

トピックが HTTPS または HTTP のログ。

__topic__:HTTPS or __topic__:HTTP

なし

192.0.2.1 ホストから収集されたログ。

__tag__:__client_ip__:192.0.2.1

__tag__:__client_ip__ フィールドは SLS の予約済みフィールドです。このフィールドは、ログが収集されたホストの IP アドレスを示します。詳細については、「予約済みフィールド」をご参照ください。

重要

ログがデータ変換機能または Logtail プラグインを使用して処理される場合、__tag__:__client_ip__ フィールドのキーは共通キーに変換されます。ログを検索する場合は、検索文で __tag__:__client_ip__ フィールドの名前を二重引用符 ("") で囲む必要があります。例: "__tag__:__client_ip__":192.0.2.1

なし

IP アドレスが 192.168.XX.XX に一致するログ。

* | select * from log where key like '192.168.%.%'

詳細については、「LIKE 句を使用してあいまい一致を実装する」をご参照ください。

なし

remote_user フィールドが空でないログ。

not remote_user:""

デバッグ

remote_user フィールドが空であるログ。

remote_user:""

デバッグ

remote_user フィールドの値が null でないログ。

not remote_user:"null"

デバッグ

remote_user フィールドを含まないログ。

not remote_user:*

デバッグ

remote_user フィールドを含むログ。

remote_user:*

デバッグ

city フィールドの値が Shanghai でないログ。

not city:Shanghai
説明

中国語の文字列をクエリする場合は、インデックスを構成するときに [中国語を含む] をオンにする必要があります。詳細については、「インデックスの作成」をご参照ください。

なし

高度な検索例

  • あいまい検索

    期待される検索結果

    検索文

    デバッグ

    特定の単語を含むログ。単語は cn で始まります。

    cn*

    デバッグ

    region フィールドの値が cn で始まるログ。

    region:cn*

    なし

    region フィールドの値に cn* が含まれるログ。

    region:"cn*"
    説明

    この検索文では、cn* は完全な文字列です。例:

    • ログの内容が region:cn*,en で、デリミタがコンマ (,) の場合、SLS はログの内容を regioncn*、および en に分割します。検索文を使用してログを検索します。

    • ログの内容が region:cn*hangzhou の場合、SLS は cn*hangzhou を全体として見なすため、検索文でログを検索することはできません。

    なし

    特定の単語を含むログ。単語は mozi で始まり、la で終わり、mozila の間に 1 文字含まれます。

    mozi?la

    デバッグ

    特定の単語を含むログ。単語は mo で始まり、la で終わり、mola の間に 0 個以上の文字が含まれます。

    mo*la

    デバッグ

    特定の単語を含むログ。単語は moz または sa で始まります。

    moz* and sa*

    デバッグ

    region フィールドの値が hai で終わるログ。

    検索文ではログを見つけることができません。代わりに SQL 文で LIKE 句を使用します。詳細については、「LIKE 句を使用してあいまい一致を実装する」をご参照ください。

    * | select * from log where region like '%hai'

    なし

    message フィールドの値が "get_time: 0. で始まるログ。

    SQL 分析で like 構文を使用します。

    *| select message where message like '"get_time: 0.%'

    または、構造化プロセス言語 (SPL) の where 命令を使用してログをフィルターします。

    なし

  • デリミタベースの検索

    SLS は、指定したデリミタに基づいてログの内容を複数の単語に分割します。デフォルトのデリミタは , '";=()[]{}?@&<>/:\n\t\r です。Delimiter 設定を空のままにすると、SLS はフィールド値全体を 1 つの term として扱い、文字列全体の完全一致またはあいまい検索でのみ検索可能になります。デリミタの指定方法の詳細については、「インデックスの作成」をご参照ください。

    たとえば、http_user_agent フィールドの値は Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.2 (KHTML, like Gecko) Chrome/192.0.2.0 Safari/537.2 です。

    • [デリミタ] を空のままにすると、SLS はフィールド値を全体として見なします。http_user_agent:Chrome 検索文を使用してログを検索することはできません。

    • [デリミタ], '";=()[]{}?@&<>/:\n\t\r に設定すると、SLS はフィールド値を Mozilla5.0WindowsNT6.1AppleWebKit537.2KHTMLlikeGeckoChrome192.0.2.0Safari、および 537.2 に分割します。http_user_agent:Chrome 検索文を使用してログを検索できます。

    重要

    検索キーワードにデリミタが含まれている場合は、フレーズ検索を実行するか、LIKE 句を使用します。例:

    • フレーズ検索: #"redo_index/1"。詳細については、「フレーズ検索」をご参照ください。

    • LIKE 句: * | select * from log where key like 'redo_index/1'

    期待される検索結果

    検索文

    デバッグ

    http_user_agent フィールドの値に Chrome が含まれるログ。

    http_user_agent:Chrome

    デバッグ

    http_user_agent フィールドの値に LinuxChrome が含まれるログ。

    http_user_agent:Linux and http_user_agent:Chrome

    デバッグ

    http_user_agent:"Linux Chrome"

    デバッグ

    http_user_agent フィールドの値に Firefox または Chrome が含まれるログ。

    http_user_agent:Firefox or http_user_agent:Chrome

    デバッグ

    request_uri フィールドの値に /request/path-2 が含まれるログ。

    request_uri:/request/path-2

    デバッグ

    request_uri フィールドの値が /request で始まり、/file-0 を含まないログ。

    request_uri:/request* not request_uri:/file-0

    デバッグ

    redo_index/1 フレーズが完全に一致するログ。

    • #"redo_index/1"

    • * | select * from log where key like 'redo_index/1'

    説明

    完全一致には、フレーズ検索または LIKE 句を使用できます。完全一致検索を実行すると、redo_index1 などの単語が一致します。

    なし

特殊なユースケースでのクエリ例

  • 検索文

    このオペレーターは、構文キーワードを囲むために使用されます。構文キーワードが二重引用符 ("") で囲まれている場合、そのキーワードはオペレーターではなくリテラル文字列として扱われます。フィールド指定検索では、二重引用符 ("") で囲まれた単語は全体として見なされます。

    • フィールド名またはフィールド値にスペース、漢字、コロン (:)、ハイフン (-) などの特殊文字、または andor などの構文キーワードが含まれている場合は、フィールド名またはフィールド値を二重引用符 ("") で囲む必要があります。たとえば、"and" は、単語 "and" をオペレーターではなく term として扱い、それを含むログを返します。

    • SLS は次のオペレーターをサポートしています: sortascdescgroup byavgsumminmax、および limit。これらのオペレーターをキーワードとして使用する場合は、オペレーターを二重引用符 ("") で囲む必要があります。

    • ログがデータ変換機能または Logtail プラグインを使用して処理される場合、__tag__:__client_ip__ フィールドのキーは共通キーに変換されます。ログを検索する場合は、検索文で __tag__:__client_ip__ フィールドの名前を二重引用符 ("") で囲む必要があります。例: "__tag__:__client_ip__":192.0.2.1__tag__:__client_ip__ フィールドは SLS の予約済みフィールドです。このフィールドは、ログが収集されたホストの IP アドレスを示します。詳細については、「予約済みフィールド」をご参照ください。

    期待されるクエリ結果

    検索文

    request method フィールドの値に PUT が含まれるログ。フィールド名にはスペースが含まれています。

    "request method":PUT

    system error description フィールドの値に DB が含まれるログ。フィールド名にはスペースが含まれています。

    "system error description":DB*

    region フィールドに文字列 cn* が含まれるログ。ログの内容が region:cn*,en で、デリミタがコンマ (,) の場合、regioncn*、および en に分割されます。

    region:"cn*"

    remote_user フィールドが空であるログ。

    remote_user:""

    Authorization フィールドの値が Bearer 12345 であり、スペースが含まれているログ。

    "Authorization": "Bearer 12345"

    errorContent フィールドの値に The body is not valid json string が含まれ、スペースが含まれているログ。

    * | select * where errorContent like '%The body is not valid json string%'

    192.0.2.1 ホストから収集されたログ。

    "__tag__:__client_ip__":192.0.2.1
  • 分析文

    • フィールド名やテーブル名などの固有名詞に、スペース、漢字、コロン (:)、ハイフン (-) などの特殊文字、または andor などの構文キーワードが含まれている場合は、分析文で固有名詞を二重引用符 ("") で囲む必要があります。

    • 特定の文字が文字列を表す場合は、分析文でその文字を一重引用符 ('') で囲む必要があります。たとえば、'status' は status 文字列を示し、status または "status" は status ログフィールドを示します。

    期待されるクエリ結果

    クエリ文

    IP アドレスが 192.168.XX.XX に一致するログ。

    * | select * from log where key like '192.168.%.%'

    最も長いリクエスト期間の上位 10 件。

    スペースを含む列名は二重引用符 ("") で囲む必要があります。

    * | SELECT max(request_time,10) AS "top 10"

    異なるリクエストステータスに対応するログの数。

    content フィールドは JSON 型としてインデックス付けされます。詳細については、「インデックス付き JSON フィールドをクエリおよび分析する方法」をご参照ください。

    * | SELECT "content.status", COUNT(*) AS PV GROUP BY "content.status"

json 型

サンプルログ

{
  "timestamp": "2025-03-21T14:35:18Z",
  "level": "ERROR",
  "service": {
    "name": "payment-processor",
    "version": "v2.8.1",
    "environment": "production"
  },
  "error": {
    "code": 5031,
    "message": "Failed to connect to third-party API",
    "details": {
      "endpoint": "https://api.paymentgateway.com/v3/verify",
      "attempts": 3,
      "last_response": {
        "status_code": 504,
        "headers": {
          "Content-Type": "application/json",
          "X-RateLimit-Limit": "100"
        }
      }
    }
  },
  "user": {
    "id": "usr-9a2b3c4d",
    "session": {
      "id": "sess-zxy987",
      "device": {
        "type": "mobile",
        "os": "Android 14",
        "network": "4G"
      }
    }
  },
  "trace": {
    "correlation_id": "corr-6f5e4d3c",
    "span_id": "span-00a1b2"
  }
}

インデックス構成

検索文を実行する前に、インデックスが構成されていることを確認してください。詳細については、「インデックスの作成」をご参照ください。インデックス構成を確認するには、次のステップを実行します。

  1. Logstore の [クエリと分析] ページで、[インデックス属性] > [属性] を選択します。image

  2. [検索と分析] パネルで、フィールドインデックスが構成されているかどうかを確認します。索引

クエリと分析の例の詳細については、「JSON ログのクエリと分析」および「JSON ログのクエリと分析に関するよくある質問」をご参照ください。

期待されるクエリ結果

クエリ文

失敗したリクエストを記録したログ

level:error

usr-9a2b3c4d ユーザー ID のリクエストを記録したログ

user.id:usr-9a2b3c4d

usr-9a2b3c4d ユーザー ID と状態コードで失敗したリクエストを記録したログ

user.id:usr-9a2b3c4d and error.details.last_response.status_code :504

参考