ConfigMap を使用して Container Insights でデータ収集を構成する
この記事では、ConfigMap を使用して、Container Insights でのデータ収集を構成する方法について説明します。 ConfigMaps は、構成ファイルや環境変数などの非機密データを格納できるようにするための Kubernetes メカニズムです。
ConfigMap は主に、クラスターのコンテナー ログおよび環境変数のデータ収集を構成するために使用されます。 stdout および stderr ログを個別に構成できます。また、複数行のログを有効にすることもできます。 I ConfigMap を使用して実行できる具体的な構成は次のとおりです。
- stdout および stderr ログの有効化または無効化、名前空間フィルター処理
- クラスターの環境変数の収集の有効化または無効化
- Normal Kube イベントのフィルター処理
- ログ スキーマを選択する
- 複数行のログの有効化または無効化
- プロキシ設定の無視
重要
Container Insights でのデータ収集を完全な構成では、各メソッドで異なる設定セットを構成できるため、ConfigMap とクラスターのデータ収集ルール (DCR) の両方を編集する必要がある場合があります。
設定の一覧と、DCR を使用してデータ収集を構成するプロセスについては、「データ収集ルールを使用して Container insights でデータ収集を構成する」を参照してください。
前提条件
- ConfigMap はグローバル リストであり、Container Insights のエージェントに適用できる ConfigMap は 1 つだけです。 別の ConfigMap を適用すると、以前の ConfigMap の収集設定は無効になります。
- コンテナー ワークロードからの stdout、stderr、環境変数の収集をサポートされているエージェントの最小バージョンは、ciprod06142019 以降です。 エージェントのバージョンを確認するには、[ノード] タブで、ノードを選択します。 [プロパティ] ウィンドウで、エージェント イメージ タグ プロパティの値をメモします。 エージェント バージョンおよび各リリースに含まれている内容の詳細については、「 エージェントのリリース ノート」を参照してください。
ConfigMap を構成してデプロイする
ConfigMap 構成ファイルを構成してクラスターにデプロイするには、次の手順を使用します。
テンプレートの ConfigMap YAML ファイルをダウンロードし、エディターで開きます。 ConfigMap ファイルを既にお持ちの場合は、それを使用できます。
「データ収集の設定」に説明されている設定を使用して、自分のカスタマイズで ConfigMap YAML ファイルを編集します。
次の kubectl コマンドを実行して、ConfigMap を作成します。
kubectl apply -f <configmap_yaml_file.yaml>例:
kubectl apply -f container-azm-ms-agentconfig.yaml構成の変更が有効になるまでに数分かかる場合があります。 その後、クラスター内のすべての Azure Monitor エージェント ポッドが再起動します。 すべての Azure Monitor エージェント ポッドが同時に再起動するのではなく、ローリング再起動で行われます。 再起動が完了すると、次の結果に類似したメッセージが表示されます。
configmap "container-azm-ms-agentconfig" created`.
データ収集の設定
次の表は、データ収集を制御するために構成できる設定を示しています。
| 設定 | データの種類 | 値 | 説明 |
|---|---|---|---|
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 です。 環境変数の収集がグローバルに有効になっている場合は、特定のコンテナーに対してその収集を無効にすることができます。そのためには、Dockerfile 設定を使用して、またはポッドの構成ファイルの env: セクションで、環境変数 AZMON_COLLECT_ENV を False に設定します。 環境変数の収集がグローバルで無効になっている場合、コレクションを特定のコンテナーで有効にすることはできません。 コンテナー レベルで適用できる唯一のオーバーライドは、コレクションが既にグローバルで有効になっている場合に無効にすることです。 |
[enrich_container_logs] enabled |
Boolean | true false |
クラスター内のすべてのコンテナー ログを対象に ContainerLogV2 または 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 にする必要があります。 |
| [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 です。 |
構成の確認
クラスターに構成が正常に適用されたことを検証するには、次のコマンドを使用して、エージェント ポッドからのログを確認します。
kubectl logs ama-logs-fdf58 -n kube-system
Azure Monitor エージェント ポッドからの構成エラーがある場合は、出力で次の例のようなエラーが示されます。
***************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 errorsLog Analytics ワークスペースの KubeMonAgentEvents テーブルから。 データは、構成エラーに関するエラーの重大度と共に、1 時間ごとに送信されます。 エラーがない場合、テーブルのエントリには重大度情報のデータが含まれ、エラーは報告されません。 Tags プロパティには、エラーが発生したポッドとコンテナー ID に関する詳細情報のほか、直近 1 時間の最初の発生、最後の発生、および発生回数も含まれます。
スキーマのバージョンを確認する
サポートされている構成スキーマのバージョンは、Azure Monitor Agent ポッドのポッド注釈 (schema-versions) として利用できます。 次の kubectl コマンドでそれらを確認できます。
kubectl describe pod ama-logs-fdf58 -n=kube-system.
次の例のような出力が注釈 schema-versions とともに表示されます。
Name: ama-logs-fdf58
Namespace: kube-system
Node: aks-agentpool-95673144-0/10.240.0.4
Start Time: Mon, 10 Jun 2019 15:01:03 -0700
Labels: controller-revision-hash=589cc7785d
dsName=ama-logs-ds
pod-template-generation=1
Annotations: agentVersion=1.10.0.1
dockerProviderVersion=5.0.0-0
schema-versions=v1
よく寄せられる質問
Helm を使用して kube システム名前空間内のコンテナーのログ収集を有効にするにはどうすればよいですか
Kube システム名前空間内のコンテナーからのログ収集は、既定では無効になっています。 Azure Monitor エージェントで環境変数を設定することで、ログ収集を有効にできます。 Container insights に関する GitHub のページを参照してください。
次のステップ
- ConfigMap ではなく DCR を使用してデータ収集を構成するには、「データ収集ルールを使用して Container Insights でデータ収集を構成する」を参照してください。