全行インデックス¶

全行インデックスとは¶

全行インデックスは、ログの全文検索方式の一つです。有効にすると、システムはログ内のすべての業務フィールドを全文インデックスに取り込みます。検索時にフィールド名を事前に指定する必要はなく、任意の業務フィールドの値を入力するだけで、その値を含むログを検索できます。

例えば、あるログに次のフィールドが含まれるとします：

{
  "service": "order-api",
  "trace_id": "8d4f2a",
  "order_id": "O-1001",
  "amount": 128.5
}

全行インデックスを有効にすると、8d4f2a、O-1001、128.5 のいずれを直接検索しても、このログを検索できます。

全行インデックスは次のようなユースケースに適しています：

ログがすでに複数の構造化フィールドに抽出されており、message の一括保存に依存していない。
trace_id、注文番号、ユーザー ID など、さまざまな業務フィールドからすばやく検索する必要がある。
同じログインデックスに多様なログ構造が含まれており、すべてのログに対して統一した検索フィールドを事前に決められない。
フィールド化されたクエリ機能を維持しつつ、業務フィールドを横断した全文検索にも対応したい。

`message` のみのインデックスとの違い¶

比較項目	`message` のみのインデックス	全行インデックス
全文検索の範囲	`message` フィールドのみ	`message` を含むすべての業務フィールド
元のログの保持が必要か	`message` の保持が必要	必須ではない。保持しても、フィールド抽出後に削除してもよい
適したデータ	プレーンテキストログ、非構造化ログ	JSON ログ、Pipeline で抽出された構造化ログ
全文インデックスフィールド	`message`	`variant`

全行インデックスは全文検索の範囲を変えるだけで、フィールド絞り込みの代わりにはなりません。抽出済みのフィールドについては、引き続き service:order-api などのフィールド条件で絞り込み、集計、分析が可能です。

動作の仕組み¶

システムは variant によって全行インデックス内の業務フィールドを統一的に保持し、variant に対してのみ全文インデックスを作成します。

message が存在しない場合：
業務フィールド → variant → 全文インデックス

message が存在する場合：
message + その他の業務フィールド → variant → 全文インデックス

具体的なルールは次のとおりです：

全行インデックスにはログの業務フィールドが含まれますが、システムフィールドは含まれません。
ログに message が存在しない場合でも、その他の業務フィールドは全文検索に参加できます。
ログに message が存在する場合、システムはこのフィールドを削除せず、通常の業務フィールドとして variant に書き込みます。
システムは message と variant の両方に全文インデックスを二重に作成することはありません。
同じログインデックスに、message を含むログと含まないログを同時に保存できます。

message が存在するかどうかは、ログの元の内容と、DataKit・Pipeline による実際の処理結果によって決まります。全行インデックスを有効にしても、message を削除する必要はありません。

全行インデックスを使用する、または切り替える¶

新しいログインデックスを作成するとき、システムはデフォルトで全行インデックスを使用するため、追加で有効化する必要はありません。

依然として message のみのインデックスフィールドを使用している既存のログインデックスは、次の操作を実行できます：

ログ > インデックス に移動する。
対象のログインデックスを編集する。
詳細オプション を展開する。
全文インデックスフィールド で 全行インデックス を選択する。
影響範囲を確認して設定を保存する。

注意

message のみのインデックスから全行インデックスへの切り替えは一方通行の操作です。保存後は message のみのインデックスに戻せません。操作前に、関連するクエリやデータの利用方法を確認してください。

前提条件

現在のワークスペースが全行インデックスに対応している必要があります。ページにこのオプションが表示されない場合は、ワークスペースのバージョンと関連機能の権限を確認してください。

全行インデックスで検索する¶

設定が完了してログが書き込まれたら、ログ > エクスプローラー に移動し、対応するログインデックスを選択します。

エクスプローラーは、テキスト検索、フィールド絞り込み、複合検索、JSON 検索、DQL クエリなどに対応しています。完全な検索構文と使い方については、エクスプローラー検索を参照してください。

全文検索¶

検索ボックスに業務フィールドの値を入力すると、フィールド名を指定せずにすべての業務フィールドを検索できます。

上記の注文ログを例にすると：

O-1001 を入力すると、order_id に一致します。
8d4f2a を入力すると、trace_id に一致します。
order-api を入力すると、service に一致します。
ログに message が保持されている場合は、message 内の内容も検索できます。

テキスト検索では、入力内容がトークナイズされます。完全で連続した内容に一致させたい場合は、検索内容を半角のダブルクォーテーションで囲みます。詳細はテキスト検索を参照してください。

フィールド絞り込み¶

フィールド名がすでにわかっている場合は、フィールド条件を使用して検索範囲を絞り込めます。例：

service:order-api

全文検索は「内容がどのフィールドにあるかわからない」場合に適しています。フィールド絞り込みは、フィールド名がわかっていて、正確な絞り込みや集計分析が必要な場合に適しています。両方を組み合わせて使用できます。フィールド絞り込みの完全な構文は絞り込みを参照してください。

検索時の注意事項¶

全行の全文検索は業務フィールドのみに一致し、システムフィールドには一致しません。
ログに message がない場合、エクスプローラーは現在のログの業務フィールドを組み合わせてログ内容を表示します。
システムフィールドは全行インデックスのログ内容の一部にはなりません。
業務フィールドが元のログからまだ抽出されていない場合、全行インデックスでは現在実際に存在するフィールドのみを検索できます。そのため、JSON やプレーンテキストのログでは、後述の方法で必要なフィールドを先に抽出してください。

ログフィールドの抽出¶

全行インデックスはログ内にすでに存在する業務フィールドをインデックス化しますが、message 内の内容を自動的に理解して分割することはありません。元のログが依然として 1 つの JSON またはプレーンテキストである場合は、DataKit または Pipeline を使用して、その内容を構造化フィールドに抽出できます。

フィールド抽出後、元の message を保持するかどうかは、実際のニーズに応じて決めます：

完全な原文を確認する必要がある場合や、従来の利用方法を維持したい場合は、message を保持できます。
十分な構造化フィールドがすでにあり、原文を保存する必要がない場合は、message を削除できます。
message を保持するかどうかに関係なく、抽出済みの業務フィールドは全行の全文インデックスに参加できます。

DataKit で JSON フィールドを抽出する¶

各行が標準的な JSON オブジェクトであり、すべてのトップレベルフィールドを直接抽出したいログに適しています。DataKit 2.9.0 以降では json_as_fields を有効にできます。

有効にすると、DataKit は文字デコード、ANSI クリーンアップ、複数行の結合の後に、JSON ルートオブジェクトのトップレベルプロパティをログフィールドに変換してから、Pipeline を実行します。

ホストログ収集¶

logging.conf を編集します：

[[inputs.logging]]
  logfiles = ["/var/log/order/*.json"]
  source = "order"
  service = "order-api"
  json_as_fields = true

設定を保存したら、DataKit を再起動します。

Kubernetes コンテナログ収集¶

Pod Annotation を使用して、指定したコンテナの JSON フィールドモードを有効にできます：

metadata:
  annotations:
    datakit/order-api.logs: >-
      [{"source":"order","service":"order-api","json_as_fields":true}]

ここで、order-api はコンテナ名です。コンテナ環境変数 DATAKIT_LOGS_CONFIG でも同じ JSON 設定を使用できます。

コンテナ設定の制限

json_as_fields は現在、コンテナ環境変数および Pod Annotation/Label の JSON ログ設定のみをサポートしており、ClusterLoggingConfig CRD には対応していません。

Log Streaming¶

logstreaming.conf で有効にします：

[inputs.logstreaming]
  json_as_fields = true

json_as_fields はコレクター設定であり、HTTP URL パラメータではありません。この設定は influxdb、firelens、firehose タイプには適用されません。

抽出結果¶

元のログ：

{"timestamp":"2026-08-18T10:00:00+08:00","level":"INFO","service":"order-api","trace_id":"8d4f2a","order_id":"O-1001","amount":128.5,"labels":{"channel":"web"}}

変換が成功すると：

timestamp、level、service、trace_id、order_id、amount が独立したフィールドになります。
labels オブジェクトはコンパクトな JSON 文字列として保存されます。
DataKit は、元の JSON 全体を保存する message を追加で生成しません。
元の JSON 自体に message が含まれている場合、そのフィールドは通常どおり保持されます。

主なフィールド変換ルールは次のとおりです：

トップレベルの文字列、ブール値、整数、小数は型を維持します。オブジェクトと配列はコンパクトな JSON 文字列として保存されます。null は無視されます。
不正な JSON、ルートノードがオブジェクトでない場合、有効なフィールドがない場合は、元の message にフォールバックします。
フィールド名の . は _ に変換され、改行文字はスペースに変換されます。フィールド名の最大長は 256 バイトです。
各ログで保持されるフィールドは最大 1024 個で、タグは含みません。
JSON フィールドは、コレクター内の同名のタグまたはフィールドを上書きします。
JSON 内の time、source、date、storage_index は、それぞれ json_time、json_source、json_date、json_storage_index にリネームされます。

完全なルールは JSON フィールドモードを参照してください。

Pipeline でフィールドを抽出する¶

次のような場合に適しています：

一部のフィールドだけを抽出したい。
フィールドをリネームまたは変換したい。
ログが標準的な JSON ではない。
既存の Pipeline 処理フローがあり、それを継続して使用したい。

すべてのトップレベルスカラーフィールドを抽出する¶

DataKit 2.2.0 以降では json_all() を使用できます：

# 元データ：
# {"service":"order-api","status":"info","trace_id":"8d4f2a","order_id":"O-1001","amount":128.5}

json_all(_, key_patterns=["*"])

処理後、service、status、trace_id、order_id、amount などの独立したフィールドが得られます。

json_all() はトップレベルの文字列、数値、ブール値のみを抽出し、オブジェクトや配列を再帰的に展開せず、null も保存しません。include_keys と key_patterns の両方が設定されていない場合、フィールドは抽出されません。すべてのトップレベルスカラーフィールドを抽出する場合は、必ず key_patterns=["*"] を明示的に設定する必要があります。

指定したフィールドのみを抽出する¶

json(_, service)
json(_, level, status)
json(_, trace_id)
json(_, order_id)
json(_, amount)

この方法で、全行インデックスに入れるフィールドの範囲を制御できます。また、異なるログのフィールドを同じ名前に統一することもできます。

オブジェクトや配列は json_all() では抽出されません。このような内容を保持する必要がある場合は、json() でフィールドを指定して抽出できます。抽出結果は JSON 文字列として保存されます。

フィールド抽出後に message を削除する¶

Pipeline でフィールドを抽出する場合、元のログはデフォルトで message に保存されたままです。構造化フィールドで表示と検索のニーズを満たせる場合は、フィールド抽出後に drop_origin_data() を呼び出して、元の内容を保存しないようにできます。

json_all(_, key_patterns=["*"])
drop_origin_data()

指定したフィールドの抽出後に削除することもできます：

json(_, service)
json(_, level, status)
json(_, trace_id)
json(_, order_id)
json(_, amount)
drop_origin_data()

JSON 自体に message が含まれており、そのフィールドも抽出されている場合は、必要に応じて保持または削除できます。明確に不要な場合は、次のようにします：

json_all(_, key_patterns=["*"])
drop_origin_data()
drop_key(message)

3 つの関数の役割は異なります：

drop_origin_data()：初期化時に保存された元のテキストを出力しなくなります。ログ全体は引き続きアップロードされます。
drop_key(message)：抽出済みの message フィールドを削除します。
drop()：ログ全体を破棄します。ログはアップロードされず、message の削除には使用できません。

drop() を message の削除に使用しないでください

drop() は現在のログを破棄対象としてマークします。Pipeline の実行後、ログ全体はアップロードされません。

詳しい構文は、json()、json_all()、drop_origin_data()、drop_key() を参照してください。

Pipeline をローカルで検証する¶

Pipeline スクリプトを保存したら、DataKit が動作しているホストで次を実行します：

datakit pipeline -P full_line_json.p \
  -T '{"service":"order-api","status":"info","trace_id":"8d4f2a","order_id":"O-1001","amount":128.5}'

出力が次の期待どおりであることを確認します：

検索が必要なフィールドがすべて抽出されている。
drop_origin_data() を設定している場合は、元の message が削除されている。
ログが drop: true としてマークされていない。
status やログ時間などのフィールドが業務上の期待どおりである。

よくある質問¶

全行インデックスでは message を削除する必要がありますか？¶

いいえ、必要ありません。message が存在する場合、システムはそれを通常の業務フィールドとして variant に書き込み、message 用に別途全文インデックスを作成することはありません。message を削除するかどうかは、元の内容の保持・表示のニーズに応じて決めてください。

全行インデックスを有効にしたのに、message 内の JSON フィールドを検索できないのはなぜですか？¶

JSON 全体が依然として message の文字列内容にすぎない場合、その中のプロパティは独立した業務フィールドではありません。message 内のテキストを検索することはできますが、これらのプロパティをフィールド絞り込みや集計に直接使用することはできません。DataKit または Pipeline を使用して、必要なフィールドを先に抽出することをお勧めします。

message がない場合、ログエクスプローラーは内容をどのように表示しますか？¶

ログに message が存在しない場合、ログエクスプローラーは現在のログの業務フィールドを組み合わせてログ内容を表示します。システムフィールドはログ内容の一部にはなりません。

同じインデックスに、message を含むログと含まないログを同時に存在させられますか？¶

できます。両方のタイプのログは、統一されたルールに従って業務フィールドを variant に書き込み、variant が全文インデックスに参加します。

全行インデックスでシステムフィールドを検索できますか？¶

できません。全行インデックスは業務フィールドのみを含み、システムフィールドは含みません。システムフィールドは引き続きフィールド絞り込みなどでクエリできます。

全行インデックスに切り替えた後、message インデックスに戻せますか？¶

戻せません。message のみのインデックスから全行インデックスへの切り替えは一方通行の操作であり、保存後は元に戻せません。既存の message インデックスは切り替えを実行しなければ、従来どおりの方法で使い続けられます。