チュートリアル: 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 を編集します。 例については、 Azure Monitor での変換のベスト プラクティスとサンプルを参照してください。 変換クエリは、 transformKql 要素で定義されます。
   • 診断設定で収集されたリソース ログの場合は、ワークスペースの既定の DCR に変換を追加します。 テーブルは 変換をサポートしている必要があります。

よく寄せられる質問

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

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

ユーザー設定フィールドの KQL への移行は必須ですか?

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

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

いいえ。ユーザー設定フィールドは、データ インジェスト時に計算されます。 フィールド定義を削除することや、移行を遅らせることは、これまでに取り込まれたデータに影響しません。

次のステップ

• Azure Monitor での変換について詳しくは、こちらをご覧ください。