Container Insights のログ スキーマ
Container Insights では、収集されたログ データが ContainerLogV2 というテーブルに格納されます。 この記事では、このテーブルのスキーマと、従来の ContainerLog テーブルとの比較と移行について説明します。
重要
ContainerLogV2 は、CLI バージョン 2.54.0 以降の ConfigMap を使用した既定のスキーマになります。 ContainerLogV2 は、ARM、Bicep、Terraform、Policy、Portal のオンボードを使用してマネージド ID 認証でコンテナー分析情報をオンボードするお客様の既定のインジェスト形式になります。 ContainerLogV2 は、データ収集設定を使用して、CLI バージョン 2.51.0 以降で明示的に有効にすることができます。
ContainerLog テーブルのサポートは、2026 年 9 月 30 日に廃止されます。
テーブルの比較
次の表に、ContainerLog と ContainerLogV2 のスキーマを使用する場合の主な違いを示します。
| 機能の違い | ContainerLog | ContainerLogV2 |
|---|---|---|
| [スキーマ] | ContainerLog の詳細。 | ContainerLogV2 の詳細。 その他の列は次のとおりです。 - ContainerName- PodName- PodNamespace- LogLevel1- KubernetesMetadata2 |
| オンボード | ConfigMap を使用してのみ構成可能。 | ConfigMap と DCR の両方を使用して構成可能。 3 |
| 価格 | 完全な価格の分析ログとのみ互換性があります。 | 分析ログに加えて、低コストの基本ログ レベルをサポートします。 |
| クエリ実行 | 標準クエリに対してインベントリ テーブルを使用する複数の結合操作が必要です。 | クエリの複雑さと結合操作を減らすために、追加のポッドとコンテナーのメタデータが含まれています。 |
| Multiline | サポートされていません。複数行のエントリは複数の行に分割されます。 | 複数行の出力に対して統合された単一エントリを可能にするために、複数行ログがサポートされます。 |
1LogMessage が有効な JSON であり、level という名前のキーがある場合、その値が使用されます。 それ以外の場合、正規表現ベースのキーワード マッチング アプローチを使用して、LogMessage 自体から LogLevel を推論します。 この値が推論されるため、誤分類が発生する可能性があることに注意してください。
2KubernetesMetadata は省略可能な列であり、このフィールドの収集は Kubernetes メタデータ機能を使用して有効にできます。 このフィールドの値は JSON であり、podLabels、podAnnotations、podUid、Image、ImageTag、Image repo などのフィールドが含まれます。
3サービス プリンシパル認証ベースのクラスターを使用するクラスターでは、DCR 構成はサポートされません。 このエクスペリエンスを使用するには、サービス プリンシパルを持つクラスターをマネージド ID に移行してください。
Note
受信 LogMessage が有効な JSON でない場合、イベント ハブ とストレージ アカウントへのエクスポートはサポートされません。 最適なパフォーマンスを得るには、JSON 形式でコンテナー ログを出力することをお勧めします。
既存のアラートに対する影響を評価する
ContainerLogsV2 スキーマを有効にする前に、ContainerLog テーブルに依存する警告ルールがあるかどうかを評価する必要があります。 このようなアラートは、新しいテーブルを使用するように更新する必要があります。
ContainerLog テーブルを参照しているアラートをスキャンして見つけるには、次の Azure Resource Graph クエリを実行してください。
resources
| where type in~ ('microsoft.insights/scheduledqueryrules') and ['kind'] !in~ ('LogToMetric')
| extend severity = strcat("Sev", properties["severity"])
| extend enabled = tobool(properties["enabled"])
| where enabled in~ ('true')
| where tolower(properties["targetResourceTypes"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["targetResourceType"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["scopes"]) matches regex 'providers/microsoft.operationalinsights/workspaces($|/.*)?'
| where properties contains "ContainerLog"
| project id,name,type,properties,enabled,severity,subscriptionId
| order by tolower(name) asc
ContainerLogV2 スキーマを有効にする
クラスターに対して ContainerLogV2 スキーマを有効にするには、クラスターのデータ収集規則 (DCR) または ConfigMap を使用してください。 両方の設定が有効になっている場合、ConfigMap が優先されます。 stdout ログと stderr ログは、DCR と ConfigMap の両方が明示的にオフに設定されているときにのみ ContainerLog テーブルに取り込まれます。
Kubernetes メタデータとログのフィルター処理
Kubernetes メタデータとログのフィルター処理により、PodLabels、PodAnnotations、PodUid、Image、ImageID、ImageRepo、ImageTag などのより多くの Kubernetes メタデータを使用して ContainerLogsV2 スキーマが強化されます。 さらに、ログのフィルター処理機能が、ワークロードとプラットフォーム (つまり、システム名前空間) の両方のコンテナーにフィルター処理機能を提供します。 これらの機能により、ユーザーがより豊富なコンテキストを取得するため、ワークロードの可視性が向上します。
主要な機能
Kubernetes メタデータ フィールドを使用した拡張 ContainerLogV2 スキーマ: Kubernetes ログのメタデータは、簡単な Log Analytics クエリでトラブルシューティング エクスペリエンスを強化し、他のテーブルと結合する必要をなくす、他の省略可能なメタデータ フィールドを導入します。 これらのフィールドには、"PodLabels"、"PodAnnotations"、"PodUid"、"ImageID"、"ImageRepo"、"ImageTag" などの不可欠な情報が含まれます。 このコンテキストをすぐに利用できるようにすることで、ユーザーは、トラブルシューティング作業を迅速に行い、問題をすばやく特定できます。
カスタマイズされたインクルード リスト構成: ユーザーは、ConfigMap を編集することで、表示する新しいメタデータ フィールドを調整できます。
metadata_collectionが有効になっているときは、すべてのメタデータ フィールドが既定で収集されることに注意してください。特定のフィールドを選択する場合は、include_fieldsのコメントを解除して、収集する必要があるフィールドを指定します。
ログ レベルを使用した拡張 ContainerLogV2 スキーマ: ユーザーは、CRITICAL、ERROR、WARNING、INFO、DEBUG、TRACE、UNKNOWN などの色分けされた重大度レベルに基づいてアプリケーションの正常性を評価できるようになりました。 これは、インシデント対応と事前対応型モニターのための重要なツールです。 重大度レベルを視覚的に識別することで、ユーザーは影響を受けるリソースをすばやく特定できます。 色分けされたシステムは調査プロセスを合理化し、さらにデバッグするための調査エクスペリエンスのパネルをユーザーが選択することで、さらにドリルダウンできるようにします。 ただし、この機能は Grafana を使用するときにのみ適用されることに注意してください。 Log Analytics ワークスペースを使用している場合、LogLevel は ContainerLogV2 テーブル内の単なる別の列です。
ワークロードの注釈ベースのログのフィルター処理: ポッド注釈を使用した効率的なログのフィルター処理手法。 ユーザーは、ノイズを選別する必要がなく、関連情報に集中できます。 注釈ベースのフィルター処理を使用すると、ユーザーはポッドに注釈を付けることで、特定のポッドとコンテナーのログ収集を除外できます。これは、ログ分析のコストを大幅に削減するのに役立ちます。
プラットフォーム ログ (システム Kubernetes 名前空間) の ConfigMap ベースのログのフィルター処理: プラットフォーム ログは、システム (または同様の制限付き) 名前空間内のコンテナーによって出力されます。 既定では、ログ分析のコストを最小限に抑えるために、システム名前空間のすべてのコンテナー ログが除外されます。 ただし、特定のトラブルシューティング シナリオでは、システム コンテナーのコンテナー ログが重要な役割を果たします。 たとえば、kube-system 名前空間内の coredns コンテナーについて考えてみましょう。 coredns コンテナーフォーム kube-system から排他的にログ (stdout と stderr) を収集するために、ConfigMap で次の設定を有効にできます。
- 視覚化のための Grafana ダッシュボード: Grafana ダッシュボードは、CRITICAL から UNKNOWN までのログ レベルの色分けされた視覚化を表示するだけでなく、ログ ボリューム、ログ速度、ログ レコード、ログも詳細に表示します。 ユーザーは、時間に依存する分析、時間の経過に伴うログ レベルの傾向に関する動的な分析情報、および重要なリアルタイム モニターを取得できます。 詳細な分析および対象を絞り込んだトラブルシューティングを可能にする、コンピューター、ポッド、コンテナー別の詳細な内訳も提供します。最後に、新しいログ テーブル エクスペリエンスでは、ユーザーは展開ビューで詳細を表示してから、各列のデータを表示し、表示対象の情報を拡大できます。
Grafana ダッシュボードを紹介するビデオはこちらです。
Kubernetes メタデータとログのフィルター処理を有効にする方法
前提条件
マネージド ID 認証に移行します。 詳細については、こちらを参照してください。
ContainerLogV2 が有効になっていることを確認します。 マネージド ID 認証クラスターでは、このスキーマが既定で有効になっています。 なっていない場合は、ContainerLogV2 スキーマを有効にします。
制限事項
ContainerLogV2 Grafana ダッシュボードは、ContainerLogV2 テーブルの基本ログ SKU ではサポートされません。
Kubernetes メタデータを有効にする
- ConfigMap をダウンロードし、次のスクリーンショットに示すように、設定を false から true に変更します。 サポートされているすべてのメタデータ フィールドが既定で収集されることに注意してください。 特定のフィールドを収集する場合は、
include_fieldsで必要なフィールドを指定します。
ConfigMap を適用します。 ConfigMap のデプロイと構成の詳細については、ConfigMap の構成に関する記事を参照してください。
数分後、以下のスクリーンショットに示すように、Kubernetes ログのメタデータを使用して ContainerLogV2 テーブルにデータが流れ込みます。
Grafana ダッシュボード エクスペリエンスへのオンボード
- [分析情報] タブで [モニターの設定] を選び、バージョン 10.3.4 以上の Grafana ダッシュボードにオンボードします
- アクセス制御 (IAM) を調べて、Grafana の管理者/エディター/閲覧者のいずれかのロールがあることを確認します。 ない場合は、それらを追加します。
- Grafana インスタンスが Azure Logs Analytics (LA) ワークスペースにアクセスできることを確認します。 アクセス権がない場合は、LA ワークスペースに対する監視閲覧者ロール アクセス権を Grafana インスタンスに付与する必要があります。
Grafana ワークスペースに移動し、Grafana ギャラリーから ContainerLogV2 ダッシュボードをインポートします。
データソース、サブスクリプション、リソース グループ、クラスター、名前空間、およびラベルの情報を選択します。 これで、以下のスクリーンショットに示すようにダッシュボードにデータが設定されます。
Note
Grafana ダッシュボードを初回に読み込むときは、変数がまだ選択されていないためにエラーがスローされる可能性があります。 これが繰り返されないようにするには、一連の変数を選択した後にダッシュボードを保存して、最初に開いたときに既定になるようにします。
注釈ベースのフィルター処理を有効にする
以下に示す手順に従って、注釈ベースのフィルター処理を有効にします。 関連するフィルター処理のドキュメントが公開されたら、"こちらで" リンクを見つけてください。
- ConfigMap をダウンロードし、次のスクリーンショットに示すように、設定を false から true に変更します。
ConfigMap を適用します。 ConfigMap のデプロイと構成の詳細については、ConfigMap の構成に関する記事を参照してください。
必要な注釈をワークロード ポッドの仕様に追加します。次の表に、考えられるさまざまなポッドの注釈と、その処理内容の説明を示します。
| 注釈 | 説明 |
|---|---|
fluentbit.io/exclude: "true" |
ポッド内のすべてのコンテナーで stdout ストリームと stderr ストリームの両方を除外します |
fluentbit.io/exclude_stdout: "true" |
ポッド内のすべてのコンテナーで stdout ストリームのみを除外します |
fluentbit.io/exclude_stderr: "true" |
ポッド内のすべてのコンテナーで stderr ストリームのみを除外します |
fluentbit.io/exclude_container1: "true" |
ポッド内の container1 に対してのみ stdout ストリームと stderr ストリームの両方を除外します |
fluentbit.io/exclude_stdout_container1: "true" |
ポッド内の container1 に対してのみ stdout のみを除外します |
Note
これらの注釈は Fluent Bit ベースです。 独自の Fluent Bit ベースのログ収集ソリューションを Kubernetes プラグインのフィルター処理と注釈ベースの除外とともに使用すると、Container Insights とそのソリューションの両方でログの収集が停止されます。
ポッド仕様での fluentbit.io/exclude: "true" 注釈の例を次に示します。
apiVersion: v1
kind: Pod
metadata:
name: apache-logs
labels:
app: apache-logs
annotations:
fluentbit.io/exclude: "true"
spec:
containers:
- name: apache
image: edsiper/apache_logs
プラットフォーム ログの ConfigMap ベースのログのフィルター処理 (システム Kubernetes 名前空間)
- ConfigMap をダウンロードし、
collect_system_pod_logsとexclude_namespacesに関連する設定を変更します。
たとえば、kube-system 名前空間の coredns コンテナーの stdout ログと stderr ログを収集するには、kube-system 名前空間が exclude_namespaces にないことを確認します。この機能は、kube-system、gatekeeper-system、calico-system、azure-arc、kube-public、kube-node-lease というシステム名前空間のみに制限されています。
- ConfigMap を適用します。 ConfigMap のデプロイと構成の詳細については、ConfigMap の構成に関する記事を参照してください。
コンテナー分析情報での複数行のログ
複数のログが有効になっている場合は、以前に分割されたコンテナー ログが結合され、ContainerLogV2 テーブルに単一のエントリとして送信されます。 結合されたログ行が 64 KB を超える場合は、Log Analytics ワークスペースの制限により切り捨てられます。 この機能では、.NET、Go、Python、Java スタック トレースもサポートされています。ContainerLogV2 テーブルに単一エントリとして表示されます。 ConfigMap を使用した Container Insights でのデータ収集の構成に説明されているように、ConfigMapで複数行のログ記録を有効にしてください。
Note
configmap に言語仕様オプションが追加されました。ここでは、顧客が必要な言語のみを選択できます。 この機能を有効にするには、configmap の stacktrace_languages オプションで言語を編集します。
次のスクリーンショットは、Go 例外スタック トレースの複数行のログを示しています。
複数行ログが無効な場合
複数行ログが有効な場合
Java スタック トレース
Python スタック トレース
次のステップ
- ContainerLogv2 の基本ログを構成します。
- ContainerLogV2 からデータのクエリを実行する方法について説明します