チュートリアル: Log Analytics ワークスペースのカスタム フィールドを KQL ベースのカスタム列に置き換える

カスタム フィールドは、同じテーブルの別のテキスト列から別の列データに抽出できるようにする Azure Monitor の機能です。 新しいユーザー設定フィールドの作成は、2023 年 3 月 31 日以降無効になります。 カスタム フィールドの機能は非推奨となり、既存のカスタム フィールドは 2026 年 3 月 31 日に機能しなくなります。

DCR ベースの取り込み時変換を使用して同じ結果を実現するには、いくつかの利点があります。

• 文字列関数の完全なセットを適用して、カスタム列を形成できます。
• 同じデータに複数の操作を適用できます。 たとえば、値の一部を別の列に抽出し、元の列を削除します。
• ARM テンプレートで取り込み時変換を使用して、カスタム列を大規模にデプロイできます。

データ収集ルール (DCR) の導入により、KQL ベースの変換は、従来のカスタム フィールドを置き換えるテーブル カスタマイズの標準的な方法です。

このチュートリアルでは、以下の内容を学習します。

• 置換が必要なカスタム フィールドを見つける
• カスタム フィールドの内容を理解する
• テーブル内のカスタム フィールドを置き換える取り込み時変換を設定する

前提条件

• カスタム フィールドを含むテーブルを含む Log Analytics ワークスペース
• データ収集ルールを作成および変更するための十分なアカウント特権 (DCR)

置き換えるカスタム フィールドを見つける

最初に、置き換えるカスタム フィールドを見つけます。 置き換える予定のカスタム フィールドが既にわかっている場合は、次の手順に進みます。

1. カスタム フィールドを含むテーブルが配置されている Log Analytics ワークスペースに移動します。

2. サイド メニューで、[テーブル] を選択します。 テーブルのコンテキスト メニューから [テーブルの管理] を選択します。

   

3. データ収集ルール (DCR) が特定のテーブルに関連付けられている場合は注意してください。

   • 対応するセクションに DCR が存在する場合は、既存のカスタム フィールドが既にこれらの DCR 内に実装されているか、DCR の作成時に破棄されたことを意味します。 このチュートリアルの次の手順でカスタム フィールドの内容を調べ、DCR の追加の更新が必要かどうかを判断します。
   • テーブルに関連付けられているデータ収集ルールがない場合、名前が "_CF" で終わる特定のテーブル内のすべての列は、置き換え対象のカスタム フィールドになります。

   

4. テーブルのプロパティ ダイアログを閉じ、テーブルのコンテキスト メニューから [スキーマの編集] を選択します。 カスタム列が一覧表示されているページの下部までスクロールします。 これらの列は _CF で終わります。

   

5. 次の手順でこれらの列の内容を決定するため、列の名前に注意してください。

カスタム フィールドの内容を理解する

カスタム フィールド定義を直接調べる方法がないため、テーブルに対してクエリを実行してカスタム フィールドの数式を決定する必要があります。

1. サイド メニューで [ログ] を選択し、クエリを実行して、テーブルからデータのサンプルを取得します。

   

2. 前の手順で説明した列を見つけて、その内容を調べます。

   • 列が空ではなく、テーブルに関連付けられている DCR がある場合、カスタム フィールド ロジックは変換で既に実装されています。 必要な操作はありません。
   • 列が空 (またはクエリ結果に存在しない) で、テーブルに関連付けられている DCR がある場合、カスタム フィールド ロジックは DCR と共に実装されませんでした。 既存の DCR のデータフローに変換を追加します。
   • 列が空ではなく、テーブルに関連付けられている DCR がない 場合は、カスタム フィールド ロジックをワークスペース DCR の変換として実装する必要があります。

3. カスタム フィールドの内容を調べて、その計算方法のロジックを決定します。 カスタム フィールドは、通常、同じテーブル内の他の列の部分文字列を計算します。 データの取得元の列と、抽出する文字列の部分を決定します。

変換の作成

これで、必要な KQL スニペットを作成し、DCR に追加する準備ができました。 このロジックは、ワークスペースに取り込まれる各レコードに適用されます。

1. KQL を使用してテーブルのクエリを変更し、カスタム フィールド ロジックをレプリケートします。 複数のカスタム フィールドを置き換える場合は、その計算ロジックを 1 つのステートメントに組み合わせることができます。

   • 文字列内の部分文字列をパターンベースで検索する場合は、parse 演算子を使用します。
   • 正規表現ベースの部分文字列検索には extract() 関数を使用します。
   • split()、substring()などの文字列関数も便利です。

   

2. カスタム列の新しい KQL 定義を配置する必要がある場所を決定します。

   • Azure Monitor エージェント (AMA) を使用して収集されたログの場合は、変換を追加して、テーブルのデータを収集する DCR を編集します。 例については、サンプルを参照してください。 変換クエリは、transformKql 要素で定義されます。
   • 診断設定で収集されたリソース ログの場合は、ワークスペースの既定の DCR に変換を追加します。 テーブルは変換をサポートしている必要があります。

よく寄せられる質問

従来の Log Analytics エージェント (MMA) で収集されたテキスト ログのカスタム フィールドを移行するにはどうすればよいですか?

Azure Monitor エージェント (AMA) への移行を検討してください。 Log Analytics エージェントはサポート終了に近づいているので、Azure Monitor エージェント (AMA) に移行する必要があります。 AMA で収集されたテキスト ログでは、最初から KQL 変換の形式で定義されたログ解析ロジックが使用されます。 カスタム フィールドは必須ではなく、Azure Monitor エージェントによって収集されたテキスト ログではサポートされていません。

カスタム フィールドの KQL への移行は必須ですか?

いいえ。カスタム列を設定する場合にのみ、カスタム フィールドを移行する必要があります。 カスタム フィールドを移行しない場合、カスタム フィールドのサポートが終了したときに、対応する列の入力が停止します。 既に処理され、テーブルに格納されているデータは影響を受けず、引き続き使用できます。

カスタム フィールドを期間内に移行しない場合、対応する列の既存のデータは失われますか?

いいえ。カスタム フィールドは、データ取り込み時に計算されます。 フィールド定義を削除するか、または期間内に移行しない場合、以前に取り込まれたデータには影響しません。

次のステップ

• Azure Monitor での変換に関するページを読んでください。