ログインデックス¶

システムは設定されたフィルター条件に基づいて、ログデータを対応するインデックスに自動的にアーカイブします。複数のログインデックスを作成することで、次のことが可能になります：

• 業務ライン、環境、プロジェクトごとにログデータを分離する
• インデックスごとに異なる保存ポリシーを設定する
• クエリパフォーマンスを最適化し、無関係なデータのスキャンを減らす

作成¶

1. 「インデックスを作成 > ログインデックス」ページに移動します；
2. インデックス名をカスタマイズします；
3. 必要に応じて説明を追加します；
4. マッチ条件を追加します；

5. データ保存ポリシーを設定します：ログの保持期間を選択し、期限に達すると自動的に削除します；

   • デプロイメントプランのユーザーは保存期間をカスタマイズできます。範囲：1d ～ 1,800d

6. 必要に応じてクローンインデックスを設定します；

   • クローン設定には、名前、保存期間、クローン条件が含まれます。

7. 必要に応じて詳細オプションを設定します；

8. 確定します。

マッチ条件¶

マッチ条件は、ログが現在のインデックスに入るためのフィルタールールを定義します。現在、通常マッチと詳細マッチの2つの設定モードに対応しています。

通常マッチ¶

通常マッチは従来の設定方式をそのまま使用し、フィルターロジックが比較的単純なユースケースに適しています。

1. 条件の関係を選択します：

   • すべての条件を満たす：ログがすべてのフィルター条件を同時に満たす必要があります。満たした場合のみ現在のインデックスに入ります；
   • いずれかの条件を満たす：ログがいずれかのフィルター条件を満たせば、現在のインデックスに入ります。

2. フィルター条件を追加します：

   • フィールド名：source、service、host などのログフィールドを選択します；
   • 演算子：マッチ方法を選択します；
   • マッチ値：フィールド値を入力します。複数の値は半角カンマで区切ります。

通常マッチは、固定フィールドによるインデックスの振り分けをすばやく設定したい場合に適しています。

詳細マッチ¶

詳細マッチは、マッチルールをより柔軟に組み合わせる必要があるユースケースに適しています。詳細マッチを有効にすると、ログデータは Pipeline に入ってマッチ判定が行われ、対応する費用が発生します。

詳細マッチでは、複数のフィルター条件を設定できます。各条件には次の内容が含まれます：

• フィールド名：判定するログフィールドを入力します；
• マッチ方法：=、!=、in、not in、match、not match、wildcard、not wildcard に対応しています；
• マッチ値：フィールドに対応するマッチ値を入力します。

フィルターを追加をクリックすると条件をさらに追加できます；すべての条件をクリアをクリックすると、現在設定されているすべての条件を削除できます。

ページ下部に式プレビューが表示され、現在のフィルター条件から最終的に生成されるマッチ式を確認できます。条件が不完全であるか式が無効な場合、ページに「フィルター条件を補完または修正してください」と表示されます。この場合は、フィールド名、マッチ方法、マッチ値を補完してから保存してください。

詳細オプション¶

詳細オプションはデフォルトで展開されています。ここで全文インデックスフィールドを確認または選択できます。

全文インデックスフィールド¶

1. 全行インデックス（作成時のデフォルト）：全文検索でログ内のすべての業務フィールドをマッチします。システムフィールドは含まれません。システムは業務フィールドを一律 variant に書き込み、variant に対してのみ全文インデックスを作成します；

2. message インデックスフィールドのみ（既存環境との互換性）：全文検索は元の message フィールドのみをマッチします。システムは message に対して全文インデックスを作成します。

新しいログインデックスはデフォルトで全行インデックスを使用します。すでに message インデックスフィールドを使用している既存のログインデックスは引き続き使用できますが、全行インデックスに切り替えることもできます。この切り替えは一方向の操作であり、全行インデックスに切り替えると、message のみのインデックスに戻すことはできません。

全行インデックスのログに message が存在する場合、システムはこのフィールドを削除せず、通常の業務フィールドとして variant に書き込みます。システムは message と variant の両方に全文インデックスを二重作成しないため、インデックスの重複による追加のストレージコストを回避します。

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

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

DataKit の JSON フィールド抽出を設定する場合、または Pipeline でフィールドを抽出した後に元の message を削除する場合は、全行インデックスを参照してください。

従来の「サービスマッチ」機能は、ログインデックスマッピングに移行しました。

クローンインデックス¶

クローンインデックスは、通常のログインデックスからログデータの一部をさらにフィルターしてコピーするために使用します。クエリ頻度が高く、データ範囲が明確なログは、専用のクローンインデックスにコピーすることで、クエリ時にスキャンするデータ量を減らし、ログ検索の効率を向上させることができます。

ログはまず通常インデックスの並び順に従ってマッチされ、最初にヒットした通常インデックスに書き込まれます。書き込みが完了すると、システムはそのインデックスに設定されたクローン条件に基づいて、ログをクローンインデックスにコピーする必要があるかどうかを非同期で判断します。

ログの送信
   ↓
通常インデックスを順番にマッチ
   ↓
最初にヒットした通常インデックスに書き込み
   ↓
クローンルールが設定されているか判断
   ↓
クローン条件を満たす ──→ クローンインデックスに非同期コピー
条件を満たさない   ──→ クローンを実行しない

クローンタスクは非同期で実行されます。クローンが失敗しても、ソースインデックスへのログ書き込みには影響しません。

ユースケース¶

クローンインデックスは以下のようなユースケースに適しています：

• 高頻度のクエリで通常インデックス内の一部のログのみを扱う；
• サービス、環境、ステータス、業務タイプなどの条件でクエリ範囲を絞り込む必要がある；
• 通常インデックスのデータ量が大きく、頻繁に使うクエリのスキャン量を減らしたい；
• 高頻度でクエリするデータに短い保存期間を設定したい；
• ソースインデックスの完全なログを保持しつつ、日常の調査に適した簡潔なデータセットも作りたい。

例えば、通常インデックス application にすべてのアプリケーションログが保存されており、日常の調査では主に本番環境のエラーログを対象としている場合、application にクローンインデックス application_error を設定し、次のクローン条件を構成できます：

env = production AND status = error

条件を満たす新しいログは、次の両方に保存されます：

• ソースインデックス：application
• クローンインデックス：application_error

本番環境のエラーログをクエリする場合は、application_error を直接選択することで、application の全データに対するスキャンを減らせます。

クローンインデックスの設定¶

通常のログインデックスを新規作成または編集するときに、必要に応じてクローンインデックスを設定できます：

1. ログ > インデックスに移動します；
2. ログインデックスを新規作成するか、既存の通常のログインデックスを編集します；
3. クローンインデックスの設定を見つけます；
4. クローンインデックスを有効にします；
5. クローンインデックス名を入力します；
6. クローンインデックスのデータ保存期間を設定します；
7. クローン条件を追加します；
8. インデックス設定を保存します。

各通常インデックスに設定できるクローンインデックスは最大1つです。

クローンインデックス名¶

クローンインデックス名は、インデックスリストとログエクスプローラーでこのインデックスを識別するために使用します。

名前を設定する際の注意点：

• クローンインデックス名は、現在のワークスペース内で一意である必要があります；
• クローンインデックスは、既存の通常インデックス、ネイティブ直接書き込みインデックス、外部インデックス、または他のクローンインデックスと同名にすることはできません；
• 作成後、クローンインデックスはソースインデックスのセカンダリ行として表示されます；
• クローンインデックスを他のクローンインデックスのソースにすることはできません。

保存期間¶

クローンインデックスには独立したデータ保存期間を設定できますが、ソースインデックスの保存期間を超えることはできません。

ソースインデックスの保存期間を変更する場合は、クローンインデックスの保存期間が引き続き制限を満たしていることを確認する必要があります。

クローンインデックス内のログは保存期間に達すると自動的に削除され、ソースインデックスの元のログには影響しません。

クローン条件¶

クローン条件は、ソースインデックスのログをクローンインデックスにコピーする必要があるかどうかを判断するために使用します。

ログフィールドに基づいてフィルタールールを設定できます。例：

• source
• service
• env
• status
• host
• その他のログフィールド

次の条件をすべて同時に満たすログのみがクローンインデックスに入ります：

1. ログがソースの通常インデックスに正常に書き込まれている；
2. ログが現在設定されているクローン条件を満たしている；
3. クローンルールがそのログの書き込み前にすでに有効になっている。

クローン条件を満たさないログもソースインデックスには通常どおり保存されますが、クローンインデックスにはコピーされません。

データ内容¶

クローンインデックスはソースログのフィールドとタグを完全に保持し、クローン条件で使用するフィールドのみを保持するわけではありません。

コピー後のログには次の内容が含まれます：

• 元のログの業務フィールド；
• 元のログのタグ；
• 元のログに存在する message；
• ログのクエリと表示に必要な関連情報。

クローン操作によって、ソースインデックスのログが変更または削除されることはありません。

有効範囲¶

クローンルールは、ルールが有効になった後にソースインデックスへ新しく書き込まれたログのみを処理します。

以下の操作が完了した後、システムは操作が有効になった時点から後続のログを処理します：

• クローンルールを新規作成する；
• クローンルールを有効にする；
• クローン条件を変更する；
• クローンインデックスの関連設定を変更する。

システムはソースインデックスを自動的にスキャンして履歴データをバックフィルすることはありません。そのため、ルールが有効になる前にソースインデックスに書き込まれたログは、クローンインデックスに自動的にコピーされません。

例えば、2026-08-19 10:00:00 にクローンルールを有効にした場合：

• 10:00:00 以降に新しく書き込まれ、条件を満たすログはクローンインデックスに入ります；
• 10:00:00 より前に存在していた履歴ログは自動的にバックフィルされません。

クローンインデックスの表示とクエリ¶

クローンインデックスは、ソースインデックスの子ノードとして表示されます。ソースインデックスが親ノード、クローンインデックスが子ノードになります。クローンインデックスが存在する場合、インデックスツリーはデフォルトで展開されます。

クローンインデックスには専用のアイコンまたは識別子が表示され、通常インデックスと区別できます。

インデックスを検索する場合：

• ソースインデックス名を検索すると、そのソースインデックスとそのクローンインデックスが同時に表示されます；
• クローンインデックス名を検索すると、対応するソースインデックスが上位ノードとして保持され、インデックスの関係を確認しやすくなります。

クエリ時の注意点：

• ソースインデックスとクローンインデックスを同時に選択することはできません；
• ソースインデックスを選択しても、そのクローンインデックスは自動的にはクエリされません；
• クローンインデックスを選択した場合、そのクローンインデックス内のデータのみがクエリされます；
• ワイルドカード * にはデフォルトインデックスとすべての通常インデックスが含まれますが、クローンインデックスは含まれません；
• クローンインデックスをクエリする場合は、対応するクローンインデックスを明示的に選択する必要があります。

クローンインデックスは、以下のクエリエントリで選択できます：

• ログエクスプローラー；
• メトリクス分析；
• シナリオチャートおよびダッシュボード内のログ DQL エディター；
• ダッシュボードのログビュー変数；
• ログモニターのクエリ。

クローンインデックスは、以下の設定エントリには独立したインデックスとして表示されません：

• インデックス設定；
• Pipeline；
• フィールドマッピング；
• データルーティング；
• データアクセスルール；
• ログソート；
• データソースインデックスセレクター。

編集と有効/無効¶

通常インデックスを編集するときに、対応するクローンルールを変更できます。

クローンルールを変更または再度有効にした後：

• 新しいルールは、有効になった時点以降に新しく書き込まれたログにのみ適用されます；
• すでにクローンインデックスに書き込まれた履歴ログは、新しいルールに従って再処理されません；
• すでにソースインデックスに書き込まれた履歴ログは、自動的にバックフィルされません；
• ルールを変更しても、ソースインデックスの元のログデータは変わりません。

クローンルールを無効にすると、後続のログはクローンインデックスにコピーされなくなります。クローンインデックス内で保存期間内にある履歴ログは引き続きクエリできます。

制限事項¶

インデックス制限¶

関連情報¶