Container insights でログ収集を構成する
この記事では、オンボード後に Kubernetes クラスターの Container insights でデータ収集を構成する方法について詳しく説明します。 クラスターで Container Insights を有効にする方法については、「Kubernetes クラスターの監視を有効にする」を参照してください。
構成方法
Container insights で収集されたデータを構成し、フィルター処理するために使用される方法は 2 つあります。 設定によっては、2 つの方法から選択できる場合もあれば、いずれかを使用するよう求められる場合もあります。 次の表では、2 つの方法について説明し、詳細情報を以降のセクションに記載します。
| Method | 説明 |
|---|---|
| データ収集ルール (DCR) | データ収集ルール (DCR) は、Azure Monitor パイプラインを使用したデータ収集をサポートする指示セットです。 DCR は、Container Insights を有効にすると作成されます。この DCR の設定は、Azure portal またはその他の方法を使用して変更できます。 |
| ConfigMap | ConfigMaps は、構成ファイルや環境変数などの非機密データを格納できるようにするための Kubernetes メカニズムです。 Container Insights では、収集するべきデータを定義する特定の設定を使用して、各クラスターで ConfigMap が検索されます。 |
DCR を使用してデータ収集を構成する
Container insights によって作成される DCR の名前は、MSCI- <cluster-region>-<cluster-name>です。 サブスクリプション内の他の DCR と共にこの DCR を表示でき、「Azure Monitor でのデータ収集ルール (DCR) の作成と編集」で説明されている方法を使用して編集できます。 特定のカスタマイズを行うために DCR を直接変更することもできますが、ほとんどの必要な設定は、以下に説明する方法を使用して行うことができます。 詳細な構成について直接 DCR を編集する方法の詳細については、「Container insights でのデータ変換」を参照してください。
重要
AKS クラスターは、システム割り当てマネージド ID またはユーザー割り当てマネージド ID のどちらかを使用する必要があります。 クラスターがサービス プリンシパルを使用している場合、システム割り当てマネージド ID またはユーザー割り当てマネージド ID を使用するようにクラスターを更新する必要があります。
Azure portal を使用して DCR を構成する
Azure portal を使用すると、Container insights でのデータ収集用の複数のプリセット構成から選択できます。 これらの構成には、ユーザーの優先事項に応じて、異なるテーブル セットと収集頻度が含まれます。 必要なデータのみを収集するように設定をカスタマイズすることもできます。 Container Insights を有効にした後、Azure portal を使用して既存のクラスターの構成をカスタマイズすることも、クラスターで Container Insights を有効にしたときにこの構成を実行することもできます。
Azure portal でクラスターを選択します。
メニューの [監視] セクションで、[分析情報] オプションを選択します。
Container Insights がクラスターで既に有効になっている場合は、[監視の設定] ボタンを選択します。 それ以外の場合は、[Azure Monitor の構成] を選択します。監視を有効にする方法の詳細については、Azure Monitor を使用して Kubernetes クラスターで監視を有効にする方法に関するページを参照してください。
AKS および Arc 対応 Kubernetes については、クラスターをまだマネージド ID 認証に移行していない場合、[マネージド ID を使用する] を選択します。
コスト プリセットのいずれかを選択します。
コスト プリセット 収集の頻度 名前空間フィルター Syslog collection 収集されるデータ Standard 1 m なし 無効 すべての標準コンテナー分析情報テーブル Cost-optimized (コスト最適化) 5 m kube-system、gatekeeper-system、azure-arc を除外します 無効 すべての標準コンテナー分析情報テーブル Syslog 1 m なし 既定で有効 すべての標準コンテナー分析情報テーブル ログとイベント 1 m なし 無効 ContainerLog/ContainerLogV2
KubeEvents
KubePodInventory設定をカスタマイズする場合は、[コレクション設定の編集] を選択します。
名前 説明 収集の頻度 エージェントでデータを収集する頻度を決定します。 有効な値は 1m から 30m (1 分間隔) です。既定値は 1m です。 名前空間のフィルター処理 オフ: すべての名前空間のデータを収集します。
Include: namespaces フィールドの値からのみデータが収集されます。
Exclude: namespaces フィールドの値を除くすべての名前空間からデータが収集されます。
namespaceFilteringMode に基づいてインベントリとパフォーマンス データを収集する Kubernetes 名前空間のコンマ区切り配列。 たとえば、Include 設定を指定した namespaces = ["kube-system", "default"] では、これら 2 つの名前空間のみが収集されます。 Exclude 設定の場合、エージェントは、kube-system と default を除くその他すべての名前空間からデータを収集します。収集対象データ 収集する Container insights 情報テーブルを定義します。 各グループの説明については、以下を参照してください。 ContainerLogV2 を有効にする ContainerLogV2 スキーマを有効にするブール型フラグ。 true に設定すると、stdout/stderr ログが ContainerLogV2 テーブルに取り込まれます。 それ以外の場合は、ConfigMap で特に指定されていない限り、コンテナー ログが ContainerLog テーブルに取り込まれます。 個々のストリームを指定する場合は、ContainerLog または ContainerLogV2 に対応するテーブルを含める必要があります。 Syslog 収集を有効にする クラスターからの Syslog 収集を有効にします。 [収集対象データ] オプションを使用すると、クラスターに対して設定されているテーブルを選択できます。 テーブルは、最も一般的なシナリオによってグループ化されます。 個々のテーブルを指定するには、別の方法を使用して DCR を変更する必要があります。
グループ化 テーブル Notes すべて (既定値) すべての標準コンテナー分析情報テーブル 既定の Container Insights の視覚化を有効にするために必要 パフォーマンス Perf、InsightsMetrics ログとイベント ContainerLog または ContainerLogV2、KubeEvents、KubePodInventory マネージド Prometheus メトリックを有効にしている場合に推奨 ワークロード、デプロイ、および HPA InsightsMetrics、KubePodInventory、KubeEvents、ContainerInventory、ContainerNodeInventory、KubeNodeInventory、KubeServices 永続的ボリューム InsightsMetrics、KubePVInventory [構成] を選択して設定を保存します。
DCR に適用可能なテーブルとメトリック
DCR の収集頻度と名前空間のフィルター処理の設定は、必ずしもすべての Container Insights データに適用されるとは限りません。 次の各表は、Container Insights で使用される Log Analytics ワークスペース内のテーブルおよび収集されるメトリックと、それぞれに適用される設定の一覧を示しています。
| テーブル名 | 間隔 | 名前空間 | 解説 |
|---|---|---|---|
| ContainerInventory | はい | はい | |
| ContainerNodeInventory | はい | いいえ | Kubernetes ノードは名前空間スコープのリソースではないため、名前空間のデータ収集設定は適用されません |
| KubeNodeInventory | はい | いいえ | Kubernetes ノードは名前空間スコープのリソースではないため、名前空間のデータ収集設定は適用されません |
| KubePodInventory | はい | はい | |
| KubePVInventory | はい | はい | |
| KubeServices | はい | はい | |
| KubeEvents | いいえ | はい | 間隔のデータ収集設定は、Kubernetes イベントには適用されません |
| Perf | はい | はい | Kubernetes ノードは名前空間スコープを持つオブジェクトではないため、名前空間のデータ収集設定は Kubernetes ノード関連のメトリックには適用されません。 |
| InsightsMetrics | はい | はい | データ収集設定は、名前空間 container.azm.ms/kubestate、container.azm.ms/pv、container.azm.ms/gpu を収集するメトリックにのみ適用されます |
| メトリック名前空間 | 間隔 | 名前空間 | 解説 |
|---|---|---|---|
| Insights.container/nodes | はい | いいえ | ノードは名前空間スコープのリソースではありません |
| Insights.container/pods | はい | はい | |
| Insights.container/containers | はい | はい | |
| Insights.container/persistentvolumes | はい | はい |
DCR のストリーム値
CLI または ARM を使用して、収集するテーブルを指定する場合、Log Analytics ワークスペース内の特定のテーブルに対応するストリーム名を指定します。 次の表は、各テーブルのストリーム名の一覧を示しています。
Note
データ収集ルールの構造についてよく理解している場合は、この表のストリーム名は DCR のデータ フローのセクションに指定されていることがお分かりになるでしょう。
| ストリーム | コンテナー分析情報テーブル |
|---|---|
| Microsoft-ContainerInventory | ContainerInventory |
| Microsoft-ContainerLog | ContainerLog |
| Microsoft-ContainerLogV2 | ContainerLogV2 |
| Microsoft-ContainerLogV2-HighScale | ContainerLogV2 (高スケール モード)1 |
| Microsoft-ContainerNodeInventory | ContainerNodeInventory |
| Microsoft-InsightsMetrics | InsightsMetrics |
| Microsoft-KubeEvents | KubeEvents |
| Microsoft-KubeMonAgentEvents | KubeMonAgentEvents |
| Microsoft-KubeNodeInventory | KubeNodeInventory |
| Microsoft-KubePodInventory | KubePodInventory |
| Microsoft-KubePVInventory | KubePVInventory |
| Microsoft-KubeServices | KubeServices |
| Microsoft-Perf | Perf |
1 Microsoft-ContainerLogV2 と Microsoft-ContainerLogV2-HighScale の両方を同じ DCR で使わないでください。 その結果、データの重複が生じます。
DCR を複数のクラスターと共有する
Kubernetes クラスターで Container Insights を有効にすると、そのクラスター用に新しい DCR が作成され、各クラスターの DCR を個別に変更できます。 カスタム監視構成を持つ複数のクラスターがある場合は、1 つの DCR を複数のクラスターと共有できます。 その後、1 つの DCR に変更を加えると、それに関連付けられたすべてのクラスターに自動的に適用されます。
DCR は、データ収集ルール関連付け (DCRA) を持つクラスターに関連付けられます。 [DCR エクスペリエンスを表示] を使用して、各クラスターの既存の DCR 関連付けを表示および削除します。 その後、この機能を使用して、複数のクラスターに 1 つの DCR への関連付けを追加できます。
ConfigMap を使用してデータ収集を構成する
ConfigMaps は、構成ファイルや環境変数などの非機密データを格納できるようにするための Kubernetes メカニズムです。 Container Insights では、収集するべきデータを定義する特定の設定を使用して、各クラスターで ConfigMap が検索されます。
重要
ConfigMap はグローバル リストであり、Container Insights のエージェントに適用できる ConfigMap は 1 つだけです。 別の ConfigMap を適用すると、以前の ConfigMap の収集設定は無効になります。
前提条件
- コンテナー ワークロードからの stdout、stderr、環境変数の収集をサポートされているエージェントの最小バージョンは、ciprod06142019 以降です。
ConfigMap を構成してデプロイする
ConfigMap 構成ファイルを構成してクラスターにデプロイするには、次の手順を使用します。
Container Insights 用の ConfigMap がまだない場合は、ConfigMap YAML ファイルのテンプレート をダウンロードし、エディターで開きます。
ご自分のカスタマイズで ConfigMap yaml ファイルを編集します。 このテンプレートには、説明を含むすべての有効な設定が含まれています。 設定を有効にするには、コメント文字 (#) を削除し、その値を設定します。
次の kubectl コマンドを実行して、ConfigMap を作成します。
kubectl config set-context <cluster-name> kubectl apply -f <configmap_yaml_file.yaml> # Example: kubectl config set-context my-cluster kubectl apply -f container-azm-ms-agentconfig.yaml構成の変更が有効になるまでに数分かかる場合があります。 その後、クラスター内のすべての Azure Monitor エージェント ポッドが再起動します。 すべての Azure Monitor エージェント ポッドが同時に再起動するのではなく、ローリング再起動で行われます。 再起動が完了すると、次の結果に類似したメッセージが表示されます。
configmap "container-azm-ms-agentconfig" created`.
構成の確認
クラスターに構成が正常に適用されたことを検証するには、次のコマンドを使用して、エージェント ポッドからのログを確認します。
kubectl logs ama-logs-fdf58 -n kube-system -c ama-logs
Azure Monitor Agent ポッドからの構成エラーがある場合は、出力で次の例のようなエラーが示されます。
***************Start Config Processing********************
config::unsupported/missing config schema version - 'v21' , using defaults
構成変更のトラブルシューティングを行うには、次のオプションを使用します。
エージェント ポッドから同じ
kubectl logsコマンドを使用します。次のようなエラーが表示されているかどうかを確認します。
config::error::Exception while parsing config map for log collection/env variable settings: \nparse error on value \"$\" ($end), using defaults, please check config map for errorsデータは 1 時間ごとに、構成エラーの重大度と共にお客様の Log Analytics ワークスペース内の
KubeMonAgentEventsテーブルに送信されます。 エラーがない場合、テーブルのエントリには重大度情報のデータが含まれ、エラーは報告されません。Tags列には、エラーが発生したポッドとコンテナー ID に関する詳細情報のほか、直近 1 時間の最初の発生、最後の発生、発生回数も含まれます。
スキーマのバージョンを確認する
サポートされている構成スキーマのバージョンは、Azure Monitor Agent ポッドのポッド注釈 (schema-versions) として利用できます。 次の kubectl コマンドでそれらを確認できます。
kubectl describe pod ama-logs-fdf58 -n=kube-system.
ConfigMap の設定
次の表では、ConfigMap を使用してデータ収集を制御するために構成できる設定を示しています。
| 設定 | データの種類 | 値 | 説明 |
|---|---|---|---|
schema-version |
String (大文字と小文字が区別されます) | v1 | この ConfigMap を解析する際にエージェントによって使用されます。 現在サポートされているスキーマのバージョンは、v1 です。 この値に対する変更はサポートされておらず、ConfigMap の評価時に拒否されます。 |
config-version |
String | ソース管理システムまたはリポジトリ内で、この構成ファイルのバージョンを追跡できます。 許容される最大文字数は 10 で、他のすべての文字は切り捨てられます。 | |
| [log_collection_settings] | |||
[stdout]enabled |
Boolean | true false |
stdout コンテナーのログ収集を有効にするかどうかを制御します。 true に設定した場合、stdout のログ収集に対して名前空間を除外しないと、クラスター内のすべてのポッドおよびノードのすべてのコンテナーから、stdout ログが収集されます。 ConfigMap で指定しない場合、既定値は true です。 |
[stdout]exclude_namespaces |
String | コンマ区切りの配列 | stdout のログを収集しない Kubernetes 名前空間の配列。 この設定は、enabled を true に設定した場合にのみ有効です。 ConfigMap で指定しない場合、既定値は["kube-system","gatekeeper-system"] |
[stderr]enabled |
Boolean | true false |
stderr コンテナーのログ収集を有効にするかどうかを制御します。 true に設定した場合、stderr のログ収集に対して名前空間を除外しないと、クラスター内のすべてのポッドおよびノードのすべてのコンテナーから、stderr ログが収集されます。 ConfigMap で指定しない場合、既定値は true です。 |
[stderr]exclude_namespaces |
String | コンマ区切りの配列 | stderr のログを収集しない Kubernetes 名前空間の配列。 この設定は、enabled を true に設定した場合にのみ有効です。 ConfigMap で指定しない場合、既定値は["kube-system","gatekeeper-system"] |
[env_var]enabled |
Boolean | true false |
クラスター内のすべてのポッドおよびノードにわたる環境変数の収集を制御します。 ConfigMap で指定しない場合、既定値は true です。 |
[enrich_container_logs]enabled |
Boolean | true false |
クラスター内のすべてのコンテナー ログを対象に ContainerLog テーブルに書き込まれるあらゆるログ レコードに関して、Name と Image のプロパティ値にデータを入力するとき、コンテナー ログのエンリッチメントが制御されます。 ConfigMap で指定しない場合、既定値は false です。 |
[collect_all_kube_events]enabled |
Boolean | true false |
すべての種類の Kube イベントを収集するかどうかを制御します。 既定では、種類が Normal の Kube イベントは収集されません。 この設定が true である場合、Normal イベントはフィルター処理されず、すべてのイベントが収集されます。 ConfigMap で指定しない場合、既定値は false です。 |
[schema]containerlog_schema_version |
String (大文字と小文字が区別されます) | v2 v1 |
ログ インジェストの形式を設定します。 v2 の場合は、ContainerLogV2 テーブルが使用されます。 v1 の場合は、ContainerLog テーブルが使用されます (このテーブルは非推奨になりました)。 Azure CLI バージョン 2.54.0 以降を使用して Container Insights を有効にするクラスターの場合、既定の設定は v2 です。 詳細については、「Container Insights のログ スキーマ」を参照してください。 |
[enable_multiline_logs]enabled |
Boolean | true false |
複数行のコンテナー ログを有効にするかどうかを制御します。 詳細については、「Container Insights での複数行のログ」を参照してください。 ConfigMap で指定しない場合、既定値は false です。 これを使用するには、schema 設定を v2 にする必要があります。 |
[metadata_collection]enabled |
Boolean | true false |
ContainerLogV2 テーブルの KubernetesMetadata 列にメタデータを収集するかどうかを制御します。 |
[metadata_collection]include_fields |
String | コンマ区切りの配列 | 含めるメタデータ フィールドの一覧。 設定が使用されていない場合は、すべてのフィールドが収集されます。 有効な値: ["podLabels","podAnnotations","podUid","image","imageID","imageRepo","imageTag"] |
| [metric_collection_settings] | |||
[collect_kube_system_pv_metrics]enabled |
Boolean | true false |
kube-system 名前空間で永続ボリューム (PV) の使用状況メトリックを収集できます。 既定では、kube-system 名前空間の永続ボリューム要求を持つ永続ボリュームの使用状況メトリックは収集されません。 この設定を true に設定すると、すべての名前空間の PV 使用状況メトリックが収集されます。 ConfigMap で指定しない場合、既定値は false です。 |
| [agent_settings] | |||
[proxy_config]ignore_proxy_settings |
Boolean | true false |
true の場合は、プロキシ設定が無視されます。 AKS および Arc 対応 Kubernetes の両方の環境では、クラスターが転送プロキシで構成されている場合、プロキシ設定が自動的に適用されて、エージェントに使用されます。 特定の構成 (たとえば、AMPLS + プロキシを使用) では、プロキシ構成を無視したい場合があります。 ConfigMap で指定しない場合、既定値は false です。 |
次のステップ
- 必要のないデータをフィルター処理するように Container insights を構成してコストを節約する方法の詳細については、「Container insights でのログ収集をフィルター処理する」を参照してください。