Azure Monitor の
- Prometheus 指標
- 管理されたGrafana
- コンテナーのログ記録
- コントロール プレーン ログ
前提条件
- オンボードには、少なくともクラスターへの 共同作成者 アクセス権が必要です。
- オンボードの一環として、Azure Monitor ワークスペースを既存の Managed Grafana ワークスペースにリンクするには、Owner アクセス、または少なくとも Contributor と User Access Administrator ロールが必要です。
- 監視を有効にした後でデータを表示するには、 監視閲覧者 ロールまたは 監視共同作成者 ロールが必要です。
Important
クラスターが Azure プライベート リンクを使用して Azure Monitor ワークスペースまたはログ アナリティクス ワークスペースに接続する場合は、「仮想マシンと Kubernetes クラスターを監視するために Azure Monitor でプライベート リンクを有効にする」を参照してください。
ワークスペースを作成する
次の表では、この記事で有効になっているAzure Monitor機能をサポートするために必要なワークスペースについて説明します。 各種類の既存のワークスペースがまだない場合は、オンボード プロセスの一環としてワークスペースを作成できます。 作成するワークスペースの数と配置場所については、「
| 機能 | ワークスペース | メモ |
|---|---|---|
| マネージド Prometheus | Azure Monitor ワークスペース | オンボード時に既存の Azure Monitor ワークスペースを指定しない場合は、リソース グループの既定のワークスペースが使用されます。 クラスターのリージョンに既定のワークスペースがまだ存在しない場合は、 DefaultAzureMonitorWorkspace-<mapped_region> 形式の名前を持つワークスペースが、 DefaultRG-<cluster_region>という名前のリソース グループに作成されます。アドオンがAzure Monitor ワークスペースにデータを送信できるようにするには、 Contributor アクセス許可で十分です。 Azure Monitor ワークスペースをリンクしてAzure Managed Grafanaでメトリックを表示するには、Owner レベルのアクセス許可が必要です。 これは、オンボード 手順を実行しているユーザーが、メトリックに対してクエリを実行するために、Azure Monitor ワークスペースで Azure Managed Grafana System Identity Monitoring Reader ロールを付与できる必要があるために必要です。 |
| コンテナーのログ記録 コントロール プレーン ログ コンテナーの分析情報 |
Log Analytics ワークスペース | クラスターは、同じMicrosoft Entra テナント内の別のAzure サブスクリプション内のLog Analytics ワークスペースにアタッチできますが、Azure CLIまたはAzure Resource Manager テンプレートを使用する必要があります。 現在、Azure ポータルではこの構成を実行できません。 既存のクラスターを別のサブスクリプションのLog Analytics ワークスペースに接続している場合は、Microsoft。ContainerService リソース プロバイダーは、Log Analytics ワークスペースを使用してサブスクリプションに登録する必要があります。 詳細については、「リソース プロバイダーを登録する」 を参照してください。 既存の Log Analytics ワークスペースを指定しない場合は、リソース グループの既定のワークスペースが使用されます。 クラスターのリージョンに既定のワークスペースがまだ存在しない場合は、 DefaultWorkspace-<GUID>-<Region>形式の名前で作成されます。既定のワークスペースに使用する、サポートされているマッピング ペアの一覧については、コンテナー分析情報でサポートされているリージョンのマッピングに関するページを参照してください。 ネットワーク セキュリティ境界を使用してワークスペースを構成する方法については、Azure Monitor の構成を参照してください。 |
| 管理されたGrafana | Azure Managed Grafana ワークスペース | Grafana ワークスペースを Azure Monitor ワークスペース にリンクして、クラスターから収集された Prometheus メトリックを Grafana ダッシュボードで使用できるようにします。 |
Prometheus メトリックとコンテナーの分析情報
注意
Application Insights を使用して、OpenTelemetry Protocol (OTLP) をインストルメンテーションとデータ収集に利用し、AKS クラスターで実行されているアプリケーションを監視する機能がパブリックプレビューとなりました。 OpenTelemetry Protocol (OTLP) 制限付きプレビューを使用した AKS アプリケーションの監視を参照してください。
クラスターで Prometheus とコンテナー分析情報を有効にすると、コンテナー化されたバージョンの Azure Monitor エージェントがクラスターにインストールされます。 これらの機能は、新規または既存のクラスターで同時に構成することも、各機能を個別に有効にすることもできます。
Prometheus メトリックのスクレイピングを有効にすると同時に、クラスターに対して Managed Grafana を有効にします。 Azure Monitor ワークスペースと Azure Managed Grafana ワークスペースを接続するオプションについては、「Link a Grafana workspace」を参照してください。
前提条件
- クラスターではマネージド ID 認証を使用する必要があります。
- 次のリソース プロバイダーは、クラスターと Azure Monitor ワークスペースのサブスクリプションに登録する必要があります。
- Microsoft.ContainerService
- Microsoft。洞察 力
- Microsoft.AlertsManagement
- Microsoft。モニター
- Grafana ワークスペース サブスクリプションのサブスクリプションには、次のリソース プロバイダーが登録されている必要があります。
- Microsoft・ダッシュボード
- CLI バージョン 2.49.0 以降では、マネージド ID 認証が既定です。
-
aks-preview拡張機能は、コマンド を使用してaz extension remove --name aks-previewする必要があります。
AKS クラスターで Prometheus メトリックを有効にする
新しいクラスターの--enable-azure-monitor-metrics コマンドまたは既存のクラスターの az aks create コマンドを使用して、az aks update オプションを使用して、AKS クラスターで Prometheus メトリックを有効にします。 このオプションでは、Azure Monitor の
コマンドの例:
### Use default Azure Monitor workspace
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group>
### Use existing Azure Monitor workspace
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group> --azure-monitor-workspace-resource-id <workspace-name-resource-id>
### Use an existing Azure Monitor workspace and link with an existing Grafana workspace
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group> --azure-monitor-workspace-resource-id <azure-monitor-workspace-name-resource-id> --grafana-resource-id <grafana-workspace-name-resource-id>
### Use optional parameters
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group> --ksm-metric-labels-allow-list "namespaces=[k8s-label-1,k8s-label-n]" --ksm-metric-annotations-allow-list "pods=[k8s-annotation-1,k8s-annotation-n]"
省略可能なパラメーター
コマンド例では、次の省略可能なパラメーターを使用できます。 パラメーター名はそれぞれ異なりますが、使用は同じです。
| パラメーター | 名前と説明 |
|---|---|
| 注釈キー | --ksm-metric-annotations-allow-listリソースの kube_resource_annotations メトリックで使用される Kubernetes 注釈キーのコンマ区切りの一覧。 たとえば、kube_pod_annotations はポッド リソースの注釈メトリックです。 既定では、このメトリックには名前と名前空間のラベルのみが含まれます。 注釈をさらに含めるには、複数形のリソース名と、それらを許可する Kubernetes 注釈キーの一覧を指定します。 リソースごとに 1 つの * を指定して任意の注釈を許可できますが、これはパフォーマンスに重大な影響を及ぼします。 たとえば、pods=[kubernetes.io/team,...],namespaces=[kubernetes.io/team],... のようにします。 |
| ラベルのキー | --ksm-metric-labels-allow-listリソースの kube_resource_labels メトリック kube_resource_labels メトリックで使用されるその他の Kubernetes ラベル キーのコンマ区切りリスト。 たとえば、kube_pod_labels はポッド リソースのラベル メトリックです。 既定では、このメトリックには名前と名前空間のラベルのみが含まれます。 さらに多くのラベルを含めるには、複数形のリソース名のリストと、それらに対して許可する Kubernetes ラベル キーを指定します。リソースごとに 1 つの * を指定して任意のラベルを許可できますが、これはパフォーマンスに重大な影響を及ぼします。 たとえば、pods=[app],namespaces=[k8s-label-1,k8s-label-n,...],... のようにします。 |
| レコーディング ルール | --enable-windows-recording-rulesWindows ダッシュボードを適切に機能させるために必要な記録ルール グループを有効にすることができます。 |
注意
--ksm-metric-annotations-allow-listと--ksm-metric-labels-allow-listを使用して設定されたパラメーターは、オーバーライドすることも、ama-metrics-settings-configmap を使用して設定することもできます。
AKS クラスターでコンテナーの分析情報とログ記録を有効にする
--addon monitoring オプションを使用して、新しいクラスターのaz aks create コマンドまたは既存のクラスターを更新する az aks enable-addon コマンドを使用して、AKS クラスターでコンテナー分析情報とコンテナー ログを有効にします。
コマンドの例:
### Use default Log Analytics workspace
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name>
### Use existing Log Analytics workspace
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name> --workspace-resource-id <workspace-resource-id>
### Use custom log configuration file
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name> --workspace-resource-id <workspace-resource-id> --data-collection-settings dataCollectionSettings.json
ログ構成ファイル
クラスターのログ収集設定をカスタマイズするには、次の形式を使用して構成を JSON ファイルとして指定します。 構成ファイルを指定しない場合は、テーブルで識別される既定の設定が使用されます。
{
"interval": "1m",
"namespaceFilteringMode": "Include",
"namespaces": ["kube-system"],
"enableContainerLogV2": true,
"streams": ["Microsoft-Perf", "Microsoft-ContainerLogV2"]
}
次の表では、ログ構成ファイルの各設定について説明します。
| 名前 | 説明 |
|---|---|
interval |
エージェントでデータを収集する頻度を決定します。 有効な値は、1m 間隔で - 30m です。値が許容範囲外の場合、既定値は 1m です。 既定値: 1m。 |
namespaceFilteringMode |
Include: namespaces フィールドの値からのみデータが収集されます。 Exclude: namespaces フィールドの値を除くすべての名前空間からデータが収集されます。 Off: namespace の選択を無視して、すべての名前空間でデータが収集されます。 既定値: オフ |
namespaces |
namespaceFilteringMode に基づいてインベントリとパフォーマンス データを収集する Kubernetes 名前空間のコンマ区切り配列。 たとえば、Include 設定を指定した namespaces = ["kube-system", "default"] では、これら 2 つの名前空間のみが収集されます。 Exclude 設定の場合、エージェントは、kube-system と default を除くその他すべての名前空間からデータを収集します。 Off 設定を使用すると、エージェントでは、kube-system と default を含むすべての名前空間からデータを収集します。 無効および認識されない名前空間は無視されます。 なし。 |
enableContainerLogV2 |
ContainerLogV2 スキーマを有効にするブール型フラグ。 true に設定すると、stdout/stderr ログが ContainerLogV2 テーブルに取り込まれます。 それ以外の場合は、ConfigMap で特に指定されていない限り、コンテナー ログが ContainerLog テーブルに取り込まれます。 個々のストリームを指定する場合は、ContainerLog または ContainerLogV2 に対応するテーブルを含める必要があります。 既定値: True |
streams |
収集するテーブル ストリームの配列。 有効なストリームとそれに対応するテーブルの一覧については、「ストリーム 値 」を参照してください。 既定値: Microsoft-ContainerInsights-Group-Default |
ストリーム値
CLI または BICEP/ARM を使用して収集するテーブルを指定する場合は、Log Analytics ワークスペース内の特定のテーブルに対応するストリーム名を指定します。 次の表に、ストリーム名とそれに対応するテーブルを示します。
注意
データ収集ルールの構造についてよく理解している場合は、この表のストリーム名は DCR のデータ フローのセクションに指定されていることがお分かりになるでしょう。
| Stream | コンテナー分析情報テーブル |
|---|---|
| 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 |
| Microsoft-ContainerInsights-Group-Default | 上記のすべてのストリームを含むグループ ストリーム。2 |
1 Microsoft-ContainerLogV2 と Microsoft-ContainerLogV2-HighScale の両方を同時に使用しないでください。 その結果、データの重複が生じます。 2 グループ ストリームを短縮形として使用して、個々のすべてのストリームを指定します。 特定のストリーム セットを収集する場合は、グループ ストリームを使用する代わりに、各ストリームを個別に指定します。
適用可能なテーブルとメトリック
収集頻度と名前空間のフィルター処理の設定は、すべてのログ データには適用されません。 次の表に、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の名前空間を収集するメトリックにのみ適用されます。 |
注意
名前空間のフィルター処理は、ama-logs エージェント レコードには適用されません。 その結果、除外された名前空間の中に kube-system 名前空間が一覧表示されている場合でも、ama-logs エージェント コンテナーに関連付けられているレコードは引き続き取り込まれます。
| メトリック名前空間 | インターバル | 名前空間 | 注釈 |
|---|---|---|---|
| Insights.container/nodes | イエス | いいえ | ノードは名前空間スコープのリソースではありません |
| Insights.container/pods | イエス | イエス | |
| Insights.container/containers | イエス | イエス | |
| Insights.container/persistentvolumes | イエス | イエス |
特殊なシナリオ
特定のシナリオの構成要件には、次のリソースを使用します。
- プライベートリンクを使用している場合は、Azure Monitor で Kubernetes 監視用のプライベートリンクを有効にするを参照してください。
- ネットワーク セキュリティ境界でコンテナー のログ記録を有効にするには、Log Analytics ワークスペースを構成するネットワーク セキュリティ境界でのAzure Monitorの構成を参照してください。
- 高スケール モードを有効にするには、「監視アドオンの高スケール モードを有効にする」のオンボーディング プロセスに従います。 また、Update ConfigMap の説明に従って ConfigMap を更新する必要があり、DCR ストリームを
Microsoft-ContainerLogV2からMicrosoft-ContainerLogV2-HighScaleに変更する必要があります。
AKS クラスターでコントロール プレーン ログを有効にする
コントロール プレーン ログは、Azure Monitorで resource logs として実装されます。 これらのログを収集するには、クラスターの 診断設定 を作成します。 コンテナー ログと同じLog Analytics ワークスペースに送信します。
az monitor diagnostic-settings create コマンドを使用して、Azure CLI を使用して診断設定を作成します。 パラメーターの説明については、このコマンドのドキュメントを参照してください。
次の例では、すべての Kubernetes カテゴリを Log Analytics ワークスペースに送信する診断設定を作成します。 これには、リソース固有のモードが含まれます。Microsoftのリソース ログがサポートされている特定のテーブルにログを送信します。ContainerService/fleets。
az monitor diagnostic-settings create \
--name 'Collect control plane logs' \
--resource /subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.ContainerService/managedClusters/<cluster-name> \
--workspace /subscriptions/<subscription ID>/resourcegroups/<resource group name>/providers/microsoft.operationalinsights/workspaces/<log analytics workspace name> \
--logs '[{"category": "karpenter-events","enabled": true},{"category": "kube-audit","enabled": true},
{"category": "kube-apiserver","enabled": true},{"category": "kube-audit-admin","enabled": true},{"category": "kube-controller-manager","enabled": true},{"category": "kube-scheduler","enabled": true},{"category": "cluster-autoscaler","enabled": true},{"category": "cloud-controller-manager","enabled": true},{"category": "guard","enabled": true},{"category": "csi-azuredisk-controller","enabled": true},{"category": "csi-azurefile-controller","enabled": true},{"category": "csi-snapshot-controller","enabled": true},{"category": "fleet-member-agent","enabled": true},{"category": "fleet-member-net-controller-manager","enabled": true},{"category": "fleet-mcs-controller-manager","enabled": true}]'
--metrics '[{"category": "AllMetrics","enabled": true}]' \
--export-to-resource-specific true
Windows メトリックを有効にする (プレビュー)
Windows メトリック収集は、Managed Prometheus アドオン コンテナーのバージョン 6.4.0-main-02-22-2023-3ee44b9e 以降の AKS クラスターで有効になっています。 Azure Monitor メトリック アドオンにオンボードすると、Windows DaemonSet ポッドがノード プールでの実行を開始できるようになります。 Windows Server 2019とWindows Server 2022の両方がサポートされています。 ポッドがWindows ノード プールからメトリックを収集できるようにするには、次の手順に従います。
注意
windows-exporter-daemonset.yaml には CPU/メモリの制限がないため、Windows ノードがオーバープロビジョニングされる可能性があります。 詳細については、リソース予約を参照してください。
ワークロードをデプロイするときに、コンテナーにリソースのメモリと CPU の制限を設定します。 これもまた NodeAllocatable から減算され、クラスター全体のスケジューラが、どのノードにどのポッドを配置するかを決定するのに役立ちます。 制限なしでポッドをスケジュールすると、Windows ノードが過剰にプロビジョニングされる可能性があり、極端な場合はノードが異常になる可能性があります。
Windows エクスポーターをインストールする
windows-exporter を AKS ノードに手動でインストールし、windows-exporter-daemonset YAML ファイルをデプロイしてWindowsメトリックにアクセスします。 次のコレクターを有効にします。 その他のコレクターについては、WindowsメトリックのPrometheus エクスポーターを参照してください。
[defaults]containermemoryprocesscpu_info
windows-exporter-daemonset YAML ファイルをデプロイします。 ノードにテイントが適用されている場合は、適切な容認を適用する必要があります。
kubectl apply -f windows-exporter-daemonset.yaml
Windows メトリックを有効にする
メトリック設定 ConfigMap でwindowsexporterするようにwindowskubeproxyとtrueのブール値を設定し、それをクラスターに適用します。
ConfigMap を使用して Kubernetes クラスターから Prometheus メトリックのコレクションをカスタマイズするを参照してください。
記録ルールを有効にする
すぐに利用できるダッシュボードに必要な記録ルールを有効にします。
- CLI を使用してオンボードする場合は、オプション
--enable-windows-recording-rulesを含めます。 - ARM テンプレート、Bicep、またはAzure Policyを使用してオンボードする場合は、パラメーター ファイルで
enableWindowsRecordingRulesをtrueに設定します。 - クラスターが既にオンボードされている場合は、この ARM テンプレートと this パラメーター ファイルを使用してルール グループを作成します。 これにより、必要な記録規則が追加され、クラスターでの ARM 操作ではなく、クラスターの現在の監視状態には影響しません。
デプロイを検証する
エージェントが正しくデプロイされていることを確認するには、kubectl コマンド ライン ツールを使います。
マネージド Prometheus
DaemonSet が Linux ノード プールに正しくデプロイされたことを確認する
kubectl get ds ama-metrics-node --namespace=kube-system
ポッドの数は、クラスター上の Linux ノードの数と同じである必要があります。 出力は次の例のようになります。
User@aksuser:~$ kubectl get ds ama-metrics-node --namespace=kube-system
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
ama-metrics-node 1 1 1 1 1 <none> 10h
Windowsノードが正しくデプロイされたことを確認します
kubectl get ds ama-metrics-win-node --namespace=kube-system
ポッドの数は、クラスター上のWindowsノードの数と同じである必要があります。 出力は次の例のようになります。
User@aksuser:~$ kubectl get ds ama-metrics-node --namespace=kube-system
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
ama-metrics-win-node 3 3 3 3 3 <none> 10h
Prometheus 用に 2 つのレプリカセットがデプロイされたことを確認する
kubectl get rs --namespace=kube-system
出力は次の例のようになります。
User@aksuser:~$kubectl get rs --namespace=kube-system
NAME DESIRED CURRENT READY AGE
ama-metrics-5c974985b8 1 1 1 11h
ama-metrics-ksm-5fcf8dffcd 1 1 1 11h
コンテナーの分析情報とログ記録
DaemonSet が Linux ノード プールに正しくデプロイされたことを確認する
kubectl get ds ama-logs --namespace=kube-system
ポッドの数は、クラスター上の Linux ノードの数と同じである必要があります。 出力は次の例のようになります。
User@aksuser:~$ kubectl get ds ama-logs --namespace=kube-system
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
ama-logs 2 2 2 2 2 <none> 1d
Windowsノードが正しくデプロイされたことを確認します
kubectl get ds ama-logs-windows --namespace=kube-system
ポッドの数は、クラスター上のWindowsノードの数と同じである必要があります。 出力は次の例のようになります。
User@aksuser:~$ kubectl get ds ama-logs-windows --namespace=kube-system
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
ama-logs-windows 2 2 2 2 2 <none> 1d
コンテナー ログ ソリューションのデプロイを確認する
kubectl get deployment ama-logs-rs --namespace=kube-system
出力は次の例のようになります。
User@aksuser:~$ kubectl get deployment ama-logs-rs --namespace=kube-system
NAME READY UP-TO-DATE AVAILABLE AGE
ama-logs-rs 1/1 1 1 24d
CLI を使って構成を表示する
aks show コマンドを使用して、ソリューションが有効になっているかどうか、Log Analytics ワークスペース リソース ID、クラスターに関する概要情報を確認します。
az aks show --resource-group <resourceGroupofAKSCluster> --name <nameofAksCluster>
このコマンドは、ソリューションに関する JSON 形式の情報を返します。
addonProfiles セクションには、次の例のように omsagent に関する情報を含める必要があります。
"addonProfiles": {
"omsagent": {
"config": {
"logAnalyticsWorkspaceResourceID": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
"useAADAuth": "true"
},
"enabled": true,
"identity": null
},
}
関連するコンテンツ
- オンボードの試行で問題が発生した場合は、 トラブルシューティング ガイドを確認してください。
- Azure ポータルで Kubernetes 監視データを<> Container insights で分析する方法について説明します。