ログインデックス¶

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

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

インデックスを作成¶

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. message のみインデックスフィールド（デフォルト）：全文検索は元の message フィールドのみをマッチングします。システムは message に対して全文インデックスを作成します。

2. 全行インデックス：全文検索は、ログ内のすべてのビジネスフィールド（システムフィールドを除く）をマッチングします。システムはビジネスフィールドを統一的に variant に書き込み、variant に対してのみ全文インデックスを作成します。

ログに 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 より前に存在する履歴ログは、自動的にはバックフィルされません。

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

クローンインデックスは、インデックスリストでソースインデックスの子行として表示されます。

application
└── application_error

リストの表示は、以下のルールに従います。

• 通常のインデックスは、第 1 レベルの行として表示されます。
• クローンインデックスは、そのソースインデックスの下に表示されます。
• クローンインデックスは、通常のインデックスの並び替えには参加しません。
• クローンインデックスは、通常のインデックスのページネーション数にカウントされません。
• 通常のインデックスの順序を調整する場合、クローンインデックスはソースインデックスに追随して移動します。

ログ > エクスプローラー に移動した後、インデックスリストでクローンインデックスを明示的に選択して、その中のログをクエリできます。

編集と有効/無効の切り替え¶

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

クローンルールを変更または再び有効にした後は、以下のようになります。

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

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

制限事項¶

インデックスの制限¶

関連情報¶