Log Service は、デフォルトで生ログを content フィールドに格納します。解析プラグインを使用して構造化されたキーと値のペアを抽出すると、フィールドレベルのクエリ、集約、可視化が可能になります。解析プラグインは任意のフィールドで動作します。ターゲットフィールドを指定し、コンテンツフォーマットに適合するプラグインを選択してください。
データ解析の例
一般的なアプリケーションログの解析前と解析後:
データ解析プラグインを使用しない場合
解析を行わない場合、すべての情報は単一の content フィールドに格納されるため、フィールドごとのクエリや分析が困難になります。
content: 127.0.0.1 - - [16/Aug/2024:14:37:52 +0800] "GET /wp-admin/admin-ajax.php?action=rest-nonce HTTP/1.1" 200 41 "http://www.example.com/wp-admin/post-new.php?post_type=page" "Mozilla/5.0 (Windows NT 10.0; Win64; ×64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36 Edg/127.0.0.0"
正規表現解析プラグインを使用する場合
正規表現解析プラグインは、個別にクエリや分析が可能な名前付きフィールドを抽出します。
body_bytes_sent: 41
http_referer: http://www.example.com/wp-admin/post-new.php?post_type=page
http_user_agent: Mozilla/5.0 (Windows NT 10.0; Win64; ×64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36 Edg/127.0.0.0
remote_addr: 127.0.0.1
remote_user: -
request_method: GET
request_protocol: HTTP/1.1
request_uri: /wp-admin/admin-ajax.php?action=rest-nonce
status: 200
time_local: 16/Aug/2024:14:37:52 +0800
データ解析プラグインの選定
-
推奨: 専用ログフォーマット解析
Nginx、Apache、または IIS のログには、専用解析モード (Nginx モード解析、Apache モード解析、IIS モード解析) を使用します。手動でルールを作成する必要はありません。 -
代替: 構造化データ解析 (JSON / デリミタ)
JSON オブジェクト、または固定のデリミタ (カンマ、パイプなど) を使用するログには、JSON 解析 または デリミタモード解析 を使用します。設定が簡単で、解析も高速です。 -
フォールバック: 正規表現解析
他のモードで処理できない、不規則な非構造化ログには 正規表現解析 を使用します。正規表現は汎用性が高い一方で、作成とデバッグが難しく、スループットが低下する可能性があります。
手順
Logtail 構成を作成または変更するときに、解析プラグインを追加します。
既存の構成の変更
Log Serviceコンソールにログインします。
[プロジェクト] セクションで、管理するプロジェクトをクリックします。
-
タブで、対象の Logstore の横にある [>] をクリックし、 を選択します。
-
Logtail 設定 リストで、目的の構成の アクション 列にある Logtail 設定の管理 をクリックします。
-
ページの上部にある 編集 をクリックします。 ページ下部の 設定の処理 セクションで Logtail プラグインを追加し、保存 をクリックします。
新規構成の作成
Log Serviceコンソールにログインします。
-
コンソールの右側にある データのインポート カードをクリックします。
-
データのインポート ダイアログボックスで、データソースカードをクリックしてウィザードに従います。 Logtail 設定 ステップの Logtail 設定 セクションで Logtail プラグインを追加します。
説明プラグインの設定は、Logtail 構成を変更する場合と同じです。
データ解析プラグインの使用
共通パラメーター
これらのパラメーターはすべてのデータ解析プラグインに適用され、後続のセクションでは説明を省略します。
|
パラメーター |
説明 |
|
[元のフィールド] |
解析対象のログコンテンツを含むソースフィールドです。 デフォルトでは、生ログエントリ全体を格納する |
|
[解析が失敗したときに元のフィールドを残す] |
推奨。 解析に失敗した場合 (フォーマットの不一致など) でもソースフィールドに元のコンテンツを保持し、デバッグ用にデータを維持します。 |
|
[解析が成功したときに元のフィールドを残す] |
解析が成功した後も、元のログコンテンツを保持します。 通常、データ検証に使用されます。 |
|
[名前を変更する元のフィールド] |
[解析失敗時に元のフィールドを保持する] または [解析成功時に元のフィールドを保持する] が有効な場合に、保持されるソースフィールドの名前を変更して、名前の競合を防ぎます。 |
正規表現解析
正規表現を使用してログからフィールドを抽出し、キーと値のペアに解析します。 柔軟性が高く、ほぼすべてのテキスト形式に対応できます。
設定
-
パラメーターの詳細
共通パラメーターに加えて、このプラグインには次のコアパラメーターがあります。
パラメーター
説明
[正規表現]
ログコンテンツに一致させるために使用される正規表現です。
-
ログサンプルを提供する場合、正規表現を自動生成するか、手動で入力できます。
-
ヘルプ をクリックします。 ログサンプル テキストボックスで、抽出するコンテンツをハイライト表示し、正規表現の生成 をクリックします。 Simple Log Service は、選択に基づいて正規表現を生成します。
-
手動で入力 をクリックして正規表現を入力します。 式を入力した後、検証 をクリックして、ログコンテンツが正しく解析されることを確認します。 詳細については、「正規表現をテストする方法」をご参照ください。
-
-
ログサンプルを提供しない場合は、ログフォーマットに一致する正規表現を手動で入力する必要があります。
[ログ抽出フィールド]
抽出されたログコンテンツ (値) のフィールド名 (キー) を指定します。
-
-
設定例
-
入力ログ:
127.0.0.1 - - [16/Oct/2023:12:36:49 +0800] "GET /index.html HTTP/1.1" 200 612 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36" -
プラグイン設定
手順に従ってプラグインを設定します。 正規表現は
(\S+)\s-\s(\S+)\s\[([^]]+)]\s"(\w+)\s(\S+)\s([^"]+)"\s(\d+)(\s\d+)[^-]+([^"]+)"\s"([^"]+).*です。[元のフィールド] を
contentに設定し、[ログサンプル] テキストボックスに Nginx アクセスログを入力します。 正規表現でログを解析すると、[抽出されたログフィールド] セクションに、remote_addr、remote_user、time_local、request_method、request_uri、request_protocol、status、body_bytes_sent、http_referer、http_user_agent などのキーと値のペアが入力されます。 [解析失敗時に元のフィールドを保持する] と [解析成功時に元のフィールドを保持する] オプションは選択されていません。 -
解析結果
-
JSON 解析
JSON オブジェクトをキーと値のペアに解析します。
制限事項
JSON プラグインは、JSON オブジェクトからトップレベルのキーと値のペアのみを抽出します。 JSON 配列は直接解析しません。 複雑な JSON を処理するには、「複雑な JSON の処理方法」をご参照ください。
設定
-
パラメーター
このプラグインは「共通設定パラメーター」のみを使用します。
-
設定例
-
入力ログ
{"url": "POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=U0Ujpek********&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=pD12XYLmGxKQ%2Bmkd6x7hAgQ7b1c%3D HTTP/1.1", "ip": "10.200.98.220", "user-agent": "aliyun-sdk-java", "request": {"status": "200", "latency": "18204"}, "time": "05/Jan/2020:13:30:28"} -
プラグイン設定
「手順」に従います。 [プロセッサータイプ] を JSON に、[ソースフィールド] を
contentに設定します。 [失敗時にソースフィールドを保持] と [成功時にソースフィールドを保持] のチェックを外します。 [詳細パラメーター] は無効のままにして、[OK] をクリックします。 -
解析結果
url: POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=U0Ujpek********&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=pD12XYLmGxKQ%2Bmkd6x7hAgQ7b1c%3D HTTP/1.1 ip: 10.200.98.220 user-agent: aliyun-sdk-java request: {"status": "200", "latency": "18204"} time: 05/Jan/2020:13:30:28
-
区切り文字モード解析
区切り文字モード解析プラグインは、区切り文字を使用してログコンテンツを構造化し、複数のキーと値のペアに解析します。
設定
-
パラメーター
共通パラメーターに加えて、このプラグインには以下のパラメーターがあります。
パラメーター
説明
[デリミタ]
ログコンテンツに一致する区切り文字を選択します (例:パイプ (|))。
説明[見えない文字] を区切り文字として指定するには、ASCII コード表でその 16 進数値を確認し、
0x<16進数値>の形式で入力します。例えば、ASCII コードが 1 の非表示文字は 0x01 と入力します。[引用符]
ログフィールドに区切り文字が含まれている場合は、そのフィールドを引用符で囲む必要があります。Simple Log Service は、引用符で囲まれたコンテンツを単一のフィールドとして解析します。ログフォーマットに一致する引用符を選択してください。
説明[見えない文字] を引用符として指定するには、ASCII コード表でその 16 進数値を確認し、
0x<16進数値>の形式で入力します。例えば、ASCII コードが 1 の非表示文字は 0x01 と入力します。抽出ログフィールド
-
ログサンプルを提供する場合、Simple Log Service はサンプルと指定された区切り文字に基づいてログコンテンツを抽出します。Simple Log Service はコンテンツを値として抽出します。各値にキーを割り当てる必要があります。
-
ログサンプルを提供しない場合、値リストは生成されないため、ログデータと区切り文字に基づいてキーを手動で入力する必要があります。
キーには、英字、数字、アンダースコア (_) のみを使用でき、英字またはアンダースコア (_) で始める必要があります。最大長は 128 バイトです。
[一部のフィールドを許可する]
この設定は、抽出された値の数が指定されたキーの数よりも少ない場合に、ログを Simple Log Service にアップロードするかどうかを指定します。ログをアップロードするには、一部のフィールドを許可する を選択します。
例えば、ログが
11|22|33|44、区切り文字がパイプ (|)、キーがA、B、C、D、Eの場合:-
一部のフィールドを許可する を選択すると、
Eフィールドの値は空になり、Simple Log Service はログをアップロードします。 -
一部のフィールドを許可する を選択しない場合、ログは破棄されます。
説明区切り文字モード解析の 一部のフィールドを許可する パラメーターは、Logtail for Linux 1.0.28 以降および Logtail for Windows 1.0.28.0 以降でサポートされています。
[フィールド超過の対応方法]
抽出された値の数が指定されたキーの数を超える場合のログの処理方法を指定します。
-
[展開]:超過した値を保持し、
__column$i__形式の個別のフィールドに追加します。ここで、$iは 0 から始まる超過フィールドのインデックスです。例:__column0__、__column1__。 -
[保持]:すべての超過した値を
__column0__という単一のフィールドに追加します。 -
[破棄]:超過した値を破棄します。
-
-
設定例
-
例1: 単一文字の区切り文字
-
入力ログ
05/May/2025:13:30:28,10.10.*.*,"POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=****************&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=******************************** HTTP/1.1",200,18204,aliyun-sdk-java -
プラグインの設定
手順に従います。区切り文字としてカンマ (,)、引用符として二重引用符 (") を使用します。
説明区切り文字:タブ (
\t)、パイプ (|)、スペース、カンマ (,)、セミコロン (;)、または非表示文字など、単一の文字を使用してログを分割できます。区切り文字に二重引用符 (") は使用できません。フィールド内に二重引用符 (") が含まれている場合は、ログ内で
""としてエスケープする必要があります。Simple Log Service は、フィールドを解析する際に""を自動的に"に復元します。例えば、区切り文字がカンマ (,)、引用符が二重引用符 (") で、フィールドにカンマと二重引用符の両方が含まれている場合は、フィールドを引用符で囲み、二重引用符を""としてエスケープする必要があります。結果として得られるログエントリChevy,"Venture ""Extended Edition, Very Large""",""は、Chevy、Venture "Extended Edition, Very Large"、および空のフィールドの 3 つのフィールドに解析されます。引用符:ログフィールドに区切り文字が含まれている場合は、そのフィールドを引用符で囲む必要があります。Simple Log Service は、囲まれたコンテンツを単一のフィールドとして解析します。引用符には、タブ (
\t)、パイプ (|)、スペース、カンマ (,)、セミコロン (;)、または非表示文字などの単一文字を使用できます。例えば、区切り文字がカンマ (,)、引用符が二重引用符 (") の場合、Simple Log Service はログ
1997,"ac,moon",3000.00を1997、ac,moon、3000.00の 3 つのフィールドに解析します。 -
解析結果
IP:10.10.*.* request:POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=****************&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=******************************** HTTP/1.1 size:18204 status:200 time:05/May/2025:13:30:28 user_agent:aliyun-sdk-java
-
-
例2: 複数文字の区切り文字
-
入力ログ
05/May/2022:13:30:28&&10.200.**.**&&POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=****************&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=******************************** HTTP/1.1&&200&&18204&&aliyun-sdk-java -
プラグインの設定
手順に従います。区切り文字として
&&を使用し、引用符はデフォルトの二重引用符 (") のままにします。重要複数文字モードでは、区切り文字に
||、&&&、^_^などの 2 文字または 3 文字を使用できます。Logtail は区切り文字のマッチングに基づいてログを解析するため、フィールドを引用符で囲む必要はありません。フィールドコンテンツに区切り文字の完全一致が含まれていないことを確認してください。含まれている場合、Logtail がフィールドを誤って分割する可能性があります。 -
解析結果
IP:10.200.**.** request:POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=****************&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=******************************** HTTP/1.1 size:18204 status:200 time:05/May/2022:13:30:28 user_agent:aliyun-sdk-java
-
-
区切り文字解析エラーの処理
区切り文字がログコンテンツ内の他の文字と混在している場合 (例えば、タイムスタンプ自体にスペースとカンマが含まれている場合や、区切り文字の前後にスペースがある場合)、区切り文字モード解析ではフィールドの境界が期待通りに分割されず、抽出されたフィールド値が不正確になる可能性があります。
例
以下のログは、区切り文字としてパイプ (|) を使用しています。
2026-03-06 21:04:32,701 - | 4 | 45 | 980
タイムスタンプ自体にスペースが含まれているため、区切り文字モード解析ではタイムスタンプの末尾のハイフンが保持され、2026-03-06 21:04:32,701 - となり、数値フィールド 4、45、980 には前後にスペースが含まれます。
この場合は、正規表現解析 に切り替え、[正規表現] を使用して各フィールド値と完全一致する正規表現を記述します。例えば、以下の正規表現は、前述のログを 4 つのフィールドに正しく抽出します。
^(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2},\d{3})\s+-\s+\|\s+(\d+)\s+\|\s+(\d+)\s+\|\s+(\d+)$
[ログ抽出フィールド] を順に time、field1、field2、field3 に設定します。解析結果は以下の通りです。
time: 2026-03-06 21:04:32,701
field1: 4
field2: 45
field3: 980
正規表現のデバッグ方法については、How do I test a regular expressionをご参照ください。
トラブルシューティング
設定の処理 内のプラグインが解析エラーの原因かどうか不明な場合は、プラグインを 1 つずつ削除してログを再収集し、確認します。
-
Logtail 設定 リストで、対象の Logtail 設定を見つけて Logtail 設定の管理 をクリックします。
-
編集 をクリックします。設定の処理 セクションで、1 つの処理プラグインを削除し、保存 をクリックします。
-
ログファイルを再収集し、解析結果が正常に戻るかどうかを確認します。
-
解析エラーの原因となるプラグインを特定できるまで、上記の手順を繰り返してプラグインを 1 つずつ削除します。
Nginx モード解析
Nginx モードプラグインは、log_format の定義に基づいてログコンテンツをキーと値のペアに解析します。
Nginx ログ
設定
-
パラメーター
共通パラメーターに加えて、このプラグインには次のパラメーターがあります:
パラメーター
説明
[NGINX ログの設定]
Nginx 設定ファイル内の log_format 定義です。
log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$request_time $request_length ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent"';[ログ抽出フィールド]
プラグインは [NGINX ログの設定] に基づいてログフィールド (キー) を自動的に抽出します。
-
設定例
-
入力ログ
192.168.*.* - - [15/Apr/2025:16:40:00 +0800] "GET /nginx-logo.png HTTP/1.1" 0.000 514 200 368 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.*.* Safari/537.36" -
プラグイン設定
手順に従ってください。本番環境では、
log_formatが Nginx 設定ファイル (通常は /etc/nginx/nginx.conf) の定義と一致している必要があります。log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$request_time $request_length $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"'; -
解析結果
body_bytes_sent: 368 http_referer: - http_user_agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.*.* Safari/537.36 remote_addr: 192.168.*.* remote_user: - request_length: 514 request_method: GET request_time: 0.000 request_uri: /nginx-logo.png status: 200 time_local: 15/Apr/2025:16:40:00
-
Apache パターン解析
Apache パターン解析プラグインは、Apache ログ設定ファイルの定義に基づいて、ログコンテンツをキーと値のペアに構造化します。
Apache ログ
設定
-
パラメーター
共通パラメーター に加えて、このプラグインには次のパラメーターがあります:
パラメーター
説明
[ログ形式]
Apache ログ設定ファイルで定義されているログフォーマットを選択します。 オプションには、
common、combined、customがあります。[APACHE 設定フィールド]
Apache 設定ファイルの
LogFormatディレクティブ。-
ログ形式 を common または combined に設定すると、対応する設定フィールドが自動的に入力されます。 フォーマットが Apache 設定ファイルで定義されているものと一致していることを確認してください。
-
ログ形式 を カスタム に設定した場合は、実際のフォーマット文字列を入力します。 例えば、
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D %f %k %p %q %R %T %I %O" customizedです。
[ログ抽出フィールド]
APACHE 設定フィールド の内容に基づいて自動的に抽出されるログフィールド (キー) です。
-
-
設定例
-
入力ログ
192.168.1.10 - - [08/May/2024:15:30:28 +0800] "GET /index.html HTTP/1.1" 200 1234 "https://www.example.com/referrer" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.X.X Safari/537.36" -
プラグイン設定
手順 に従います。 [ログフォーマット] を
combinedに設定します。 -
解析結果
http_referer:https://www.example.com/referrer http_user_agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.X.X Safari/537.36 remote_addr:192.168.1.10 remote_ident:- remote_user:- request_method:GET request_protocol:HTTP/1.1 request_uri:/index.html response_size_bytes:1234 status:200 time_local:[08/May/2024:15:30:28 +0800]
-
IIS モード解析
IIS モードプラグインは、IIS ログ形式の定義に基づいてログコンテンツを複数のキーと値のペアに解析します。
IIS ログ
設定
-
パラメーターの説明
共通パラメーター に加えて、このプラグインには次のパラメーターがあります:
パラメーター
説明
ログ形式
IIS サーバーが使用するログ形式です。サポートされる形式は IIS、NCSA、W3C です。
IIS 設定フィールド
-
ログ形式が IIS または NCSA の場合、Log Service はデフォルトで IIS Configuration Fields を設定します。
-
ログ形式が W3C の場合は、このパラメーターを IIS 設定ファイル内の
logExtFileFlagsパラメーターの内容に設定してください。例:logExtFileFlags="Date, Time, ClientIP, UserName, SiteName, ComputerName, ServerIP, Method, UriStem, UriQuery, HttpStatus, Win32Status, BytesSent, BytesRecv, TimeTaken, ServerPort, UserAgent, Cookie, Referer, ProtocolVersion, Host, HttpSubStatus"-
デフォルトの IIS 5 設定ファイルパス:
C:\WINNT\system32\inetsrv\MetaBase.bin。 -
デフォルトの IIS 6 設定ファイルパス:
C:\WINDOWS\system32\inetsrv\MetaBase.xml。 -
デフォルトの IIS 7 設定ファイルパス:
C:\Windows\System32\inetsrv\config\applicationHost.config。
-
ログ抽出フィールド
Log Service は、IIS 設定フィールド パラメーターの内容に基づいて、抽出されたログフィールド (キー) を自動的に生成します。
-
-
設定例
-
入力ログ
#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken 2023-10-27 08:00:00 W3SVC1 192.168.1.1 GET /index.html - 80 - 10.0.0.5 Mozilla/5.0 200 0 0 500 100 150 -
プラグイン設定
手順 に従います。[ログ形式] を [W3C] に設定します。
-
解析結果
date: 2023-10-27 time: 08:00:00 s-sitename: W3SVC1 s-ip: 192.168.1.1 cs-method: GET cs-uri-stem: /index.html cs-uri-query: - s-port: 80 cs-username: - c-ip: 10.0.0.5 cs(User-Agent): Mozilla/5.0 sc-status: 200 sc-substatus: 0 sc-win32-status: 0 sc-bytes: 500 cs-bytes: 100 time-taken: 150
-
よくある質問
Log Service での正規表現の失敗
次の一般的な問題を確認してください:
-
ログサンプルの不一致:Logtail 構成で使用するログサンプルが、スペースや特殊文字を含め、収集したログのフォーマットと完全に一致していることを確認してください。
-
ログフォーマットの混在:ログソースに複数のフォーマットが含まれている場合、1つの正規表現ではすべてに一致しないことがあります。解析に失敗した場合に生ログを保持するには、[一致しないコンテンツを保持] を有効にしてください。また、複数の Logtail 構成を使用して、フォーマットごとに個別に処理することもできます。
-
コードとコンソールでのエスケープの違い:コードからコピーした正規表現には、
\\S+のように余分なエスケープ文字が含まれる場合があります。Log Service コンソールでは、\S+のようにバックスラッシュを 1 つ使用してください。
特定のファイルのログのクエリ
Log Service は、各ログエントリに対して、ソースファイルの完全なパスを含む __tag__:__path__ メタデータフィールドを自動的に追加します。このフィールドを使用して、/var/log/app/error.log などの特定のファイルのログをフィルターできます: * AND __tag__:__path__: /var/log/app/error.log。
インデックス変更後に履歴データをクエリできない
インデックスの変更は、新たに取り込まれたデータにのみ適用されます。既存の履歴データを新しいインデックス設定でクエリするには、[再インデックス] タスクを実行してください。
配列を含む JSON ログの処理
JSON 解析プラグインでは、JSON 配列を直接分割して個別のログエントリにすることはできません。
解決策:
Log Service では、JSON 配列フィールドを展開または分割するための JSON フィールド展開プラグイン を提供しています。
動作:展開の深さを指定すると、プラグインは配列フィールドを順に処理し、配列内の各要素に対して新しいログエントリを生成します。また、元のログから他のフィールド (配列以外のメンバー) を各新しいログエントリにコピーします。
処理例:
-
この操作によりログエントリ数が増加します。N 個の要素を持つ配列を含む 1 つのログは、N 個のログエントリになります。ログのストレージおよびインデックスのコストを計画する際に考慮してください。
展開の深さ: JSON オブジェクトを展開するレベルです。値が 0 (デフォルト) の場合はオブジェクトが完全に展開され、1 の場合は現在のレベルのみが展開されます。以降も同様です。
|
生ログ |
処理結果 (events 配列を展開) |
Unwrapping depth: 1 (prefix added) |
|
| |
テキストと埋め込み JSON を含むログの解析
複数の処理プラグインを連結し、前のプラグインの出力を次の入力として使用します。
ユースケース:
アプリケーションログのフォーマットが次のとおりで、タイムスタンプ、ログレベル、および埋め込み JSON メッセージが含まれているとします。
2025-11-12 10:30:15 INFO Request details: {"trace_id": "xyz-123", "user_id": 500, "action": "login"}
解析戦略:次の 2 つのプラグインを順に追加してください。2 つ目のプラグインには正しいソースフィールドを指定してください。この連結方法は、任意の混在フォーマットのログで使用できます。
-
正規表現解析プラグインを使用して先頭のテキストフィールドを抽出し、埋め込み JSON 文字列を別のフィールドに格納します。結果は次のとおりです:
{ "log_time": "2025-11-12 10:30:15", "log_level": "INFO", "json_message": "{\"trace_id\": \"xyz-123\", \"user_id\": 500, \"action\": \"login\"}" } -
JSON 解析プラグインを追加し、ソースフィールドとして
json_messageを設定して、JSON コンテンツをキーと値のペアに解析します。結果は次のとおりです:{ "log_time": "2025-11-12 10:30:15", "log_level": "INFO", "trace_id": "xyz-123", "user_id": 500, "action": "login" }