Container Insights のログ スキーマ
Container Insights では、収集したログ データを Log Analytics ワークスペースの ContainerLogV2 というテーブルに保存します。 この記事では、このテーブルのスキーマとその構成オプションについて説明します。 また、このテーブルを従来の ContainerLog テーブルと比較し、そこから移行するための詳細を提供します。
テーブルの比較
ContainerLogV2 は、CLI バージョン 2.54.0 以降の既定のスキーマです。 これは、マネージド ID 認証を使用して Container Insights をオンボードするお客様用の既定のテーブルです。 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 | サポートされていません。複数行のエントリは複数の行に分割されます。 | 複数行の出力に対して統合された単一エントリを可能にするために、複数行ログがサポートされます。 |
1 LogMessage が有効な JSON で、levelという名前のキーがある場合は、その値が使用されます。 それ以外の場合は、正規表現ベースのキーワード マッチングを使用して、LogMessage から LogLevel を推論します。 この推論にでは、誤分類が発生する可能性があります。 LogLevel は、CRITICAL、ERROR、WARNING、INFO、DEBUG、TRACE、UNKNOWN などの正常性値を持つ文字列フィールドです。
2KubernetesMetadata は、Kubernetes メタデータで有効になっている省略可能な列です。 このフィールドの値は、podLabels、podAnnotations、podUid、Image、ImageTag、および Image repo のフィールドを持つ JSON です。
3 DCR 構成には、マネージド ID 認証が必要です。
Note
受信 LogMessage が有効な JSON でない場合、イベント ハブ とストレージ アカウントへのエクスポートはサポートされません。 最適なパフォーマンスを得るには、JSON 形式でコンテナー ログを出力します。
ContainerLogV2 スキーマを有効にする
クラスターに対して ContainerLogV2 スキーマを有効にするには、クラスターのデータ収集規則 (DCR) または ConfigMap を使用してください。 両方の設定が有効になっている場合、ConfigMap が優先されます。 ContainerLog テーブルは、DCR と ConfigMap の両方が明示的に off に設定されている場合にのみ使用されます。
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
Kubernetes メタデータとログのフィルター処理
Kubernetes のメタデータとログのフィルター処理により、ContainerLogsV2 スキーマが追加の Kubernetes メタデータで拡張されます。 ログ フィルタリング機能は、ワークロード コンテナーとプラットフォーム コンテナーの両方にフィルター処理機能を提供します。 これらの機能により、コンテキストがより充実し、ワークロードの可視性が向上します。
Note
Kubernetes メタデータとログのフィルター処理で、Grafana ダッシュボードは、現在、基本的なログをサポートしていません。
機能
拡張 ContainerLogV2 スキーマ [Kubernetes ログのメタデータ] が有効になっている場合、
ContainerLogV2にKubernetesMetadataと呼ばれる列が追加されます。これによって、単純なログ クエリによりトラブルシューティングが強化され、他のテーブルとの結合の必要性がなくなります。 この列のフィールドには、PodLabels、PodAnnotations、PodUid、Image、ImageID、ImageRepo、ImageTagが含まれます。 これらのフィールドにより、他のテーブルと結合しなくても、ログ クエリを使用したトラブルシューティング エクスペリエンスが向上します。 Kubernetes メタデータ機能の有効化の詳細については、以下を参照してください。ログ レベル この機能は、有効な値が クリティカル、エラー、警告、情報、デバッグ、トレース、または 不明 の値を取りうる
LogLevel列を、ContainerLogV2 に追加します。 これは、重大度レベルに基づいてアプリケーションの正常性を評価するのに役立ちます。 Grafana ダッシュボードを追加すると、時間の経過に伴うログ レベルの傾向を視覚化し、影響を受けるリソースをすばやく特定できます。視覚化用の Grafana ダッシュボード Grafana ダッシュボードは、ログ レベルを色分けした視覚化を提供し、さらにログ ボリューム、ログ レート、ログ レコード、ログに関する分析情報も提供します。 時間依存の分析、時間の経過に伴うログ レベルの傾向に関する動的分析情報、および重要なリアルタイム監視を得ることができます。 ダッシュボードでは、コンピューター、ポッド、コンテナー別の詳細な内訳も提供され、詳細分析および的確なトラブルシューティングが可能になります。 Grafana ダッシュボードのインストールの詳細については、以下を参照してください。
ワークロードに対する注釈ベースのログのフィルター処理 ポッド注釈を使用した効率的なログのフィルター処理手法。 ユーザーは、ノイズから選別する必要なしに、関連情報に集中できます。 注釈ベースのフィルター処理では、ユーザーはポッドに注釈を付けることで、特定のポッドとコンテナーのログ収集を除外できます。これは、ログ分析のコストを大幅に削減するのに役立ちます。 注釈ベースのフィルター処理の構成の詳細については「注釈ベースのログ フィルター処理」を参照してください。
プラットフォーム ログ (システム Kubernetes 名前空間) に対する ConfigMap ベースのログのフィルター処理 プラットフォーム ログは、システム (または同様に制限された) 名前空間内のコンテナーによって出力されます。 既定では、Log Analytics ワークスペース内のデータのコストを最小限に抑えるために、システム名前空間のすべてのコンテナー ログが除外されます。 ただし、特定のトラブルシューティング シナリオでは、システム コンテナーのコンテナー ログが重要な役割を果たします。 1 つの例として、
kube-system名前空間内のcorednsコンテナーがあります。
Kubernetes メタデータを有効にする
重要
Kubernetes メタデータのコレクションには、マネージド ID 認証 および ContainerLogsV2 が必要です
次の設定により ConfigMap を使用して Kubernetes メタデータを有効にします。 metadata_collection が有効になっている場合、すべてのメタデータ フィールドが既定で収集されます。 include_fields のコメントを解除して、収集する個々のフィールドを指定します。
[log_collection_settings.metadata_collection]
enabled = true
include_fields = ["podLabels","podAnnotations","podUid","image","imageID","imageRepo","imageTag"]
数分後には、次に示すように、 KubernetesMetadata 列が ContainerLogV2 テーブルの任意のログ クエリに含まれているはずです。
Grafana ダッシュボードのインストール
重要
「Kubernetes クラスターの監視を有効化する」のガイダンスを使用して Grafana を有効にした場合、Grafana インスタンスは Prometheus メトリック用の Azure Monitor ワークスペースに既にアクセスできるはずです。 Kubernetes ログ メタデータ ダッシュボードには、ログ データが含まれる Log Analytics ワークスペースへのアクセスも必要です。 Log Analytics ワークスペースに対する監視閲覧者ロールを Grafana インスタンスに付与する方法については、「Azure Monitor へのアクセス許可を変更する方法」を参照してください。
ContainerLogV2 ダッシュボードにある Grafana ギャラリーからダッシュボードをインポートします。 ダッシュボードを開き、[データソース]、[サブスクリプション]、[リソース グループ]、[クラスター]、[名前空間]、[ラベル] の値を選択できます。
Note
Grafana ダッシュボードを初回に読み込むときは、変数がまだ選択されていないためにエラーが発生する可能性があります。 これが繰り返されないようにするには、一連の変数を選択した後にダッシュボードを保存して、最初に開いたときに既定になるようにします。
複数行のログ記録
複数のログが有効になっている場合は、以前に分割されたコンテナー ログが結合され、ContainerLogV2 テーブルに単一のエントリとして送信されます。 結合されたログ行が 64 KB を超える場合は、Log Analytics ワークスペースの制限により切り捨てられます。 この機能では、.NET、Go、Python、Java スタック トレースもサポートされています。ContainerLogV2 テーブルに単一エントリとして表示されます。 ConfigMap を使用した Container Insights でのデータ収集の構成に説明されているように、ConfigMapで複数行のログ記録を有効にしてください。
Note
configmap に言語仕様オプションが追加されました。ここでは、顧客が必要な言語のみを選択できます。 この機能を有効にするには、configmap の stacktrace_languages オプションで言語を編集します。
次のスクリーンショットは、Go 例外スタック トレースの複数行のログを示しています。
複数行ログが無効な場合
複数行ログが有効な場合
Java スタック トレース
Python スタック トレース
次のステップ
- ContainerLogv2 の基本ログを構成します。
- ContainerLogV2 からデータのクエリを実行する方法について説明します