次の方法で共有

Azure Kubernetes Service を監視する

  • [アーティクル]

この記事では、次の内容について説明します。

  • このサービスに対して収集できる監視データの種類。
  • そのデータを分析する方法。

Note

このサービスや Azure Monitor を既に使い慣れていて、監視データの分析方法だけを確認したい場合は、この記事で後述する分析に関するセクションをご覧ください。

Azure リソースに依存するクリティカルなアプリケーションやビジネス プロセスがある場合は、システムを監視し、そのアラートを受け取る必要があります。 Azure Monitor サービスでは、システムのすべてのコンポーネントからメトリックとログを収集して集計します。 Azure Monitor を使用すると、可用性、パフォーマンス、回復性を視覚化し、問題に関する通知を受け取ることができます。 Azure portal、PowerShell、Azure CLI、REST API、またはクライアント ライブラリは、監視データの設定および表示に使用できます。

重要

Kubernetes は、多くの動的な構成要素を持つ複雑な分散システムです。 複数のレベルで監視する必要があります。 AKS はマネージド Kubernetes サービスですが、複数のレベルでの監視に関して同じ厳しさが依然として必要です。 この記事では、AKS クラスターを監視するための高度な情報とベスト プラクティスについて説明します。

分析情報

Azure の一部のサービスについては、サービスを監視するための開始点となる監視ダッシュボードが Azure portal に組み込まれています。 これらのダッシュボードは、"分析情報" と呼ばれており、Azure portal の Azure Monitor の [分析情報ハブ] にあります。

Azure Monitor の Container insights は、ノード、ポッド、コンテナー、永続ボリュームに関するカスタム メトリックを収集します。 詳細については、「Container Insights によって収集されるメトリック」を参照してください。

Azure Monitor Application Insights は、アプリケーション パフォーマンス監視 (APM) に使われます。 コードを変更して Application Insights を有効にするには、Azure Monitor での OpenTelemetry の有効化に関する記事をご覧ください。 コードを変更しないで Application Insights を有効にするには、AKS の自動インストルメンテーションに関する記事をご覧ください。 インストルメンテーションについて詳しくは、データ収集の基本に関する記事をご覧ください。

データの監視

AKS では、「Azure リソースからの監視データ」で説明されている他の Azure リソースと同じ種類の監視データが生成されます。 AKS によって作成されるメトリックとログの詳細については、AKS データの監視のリファレンスに関するページを参照してください。 他の Azure サービスと機能は、他のデータを収集し、次の図と表に示すように他の分析オプションを有効にします。

AKS からの監視データ収集の図。

source 説明
プラットフォームのメトリック AKS クラスターのプラットフォームのメトリックは、コストなしで自動的に収集されます。 これらのメトリックは、メトリックス エクスプローラーで分析することも、メトリック アラートのために利用することもできます。
Prometheus メトリック クラスターのメトリック スクレイピングを有効にすると、Azure Monitor の Prometheus 用マネージド サービスは Prometheus メトリックを収集し、Azure Monitor ワークスペースに格納します。 それらは、Azure Managed Grafana の事前構築済みダッシュボードと Prometheus アラートを使用して分析します。
アクティビティ ログ AKS クラスターのアクティビティ ログは、コストなしで自動的に収集されます。 これらのログでは、いつクラスターが作成されたかや、いつクラスターの構成変更があったかといった情報を追跡します。 他のログ データと共に分析するには、アクティビティ ログを Log Analytics ワークスペースに送信します。
リソース ログ AKS のコントロール プレーンのログは、リソース ログとして実装されています。 診断設定を作成して Log Analytics ワークスペースに送信します。そこで、Log Analytics のログ クエリを使用して分析とアラートの作成を行えます。
Container insights Container insights は、クラスターから、stdout/stderr ストリームを含むさまざまなログとパフォーマンス データを収集し、Log Analytics ワークスペースと Azure Monitor のメトリックに格納します。 このデータは、Container 分析情報に含まれるビューとブック、または Log Analytics とメトリックス エクスプローラーを使用して分析します。
Application Insights Azure Monitor Application Insights は、ログ、メトリック、分散トレースを収集します。 このテレメトリは、Azure portal での分析のために Log Analytics ワークスペースに格納されます。

リソースの種類

Azure では、リソースの種類と ID の概念を使用して、サブスクリプション内のすべてを識別します。 リソースの種類は、Azure で実行されているすべてのリソースのリソース ID の一部でもあります。 たとえば、Microsoft.Compute/virtualMachines は、仮想マシンのリソースの種類の 1 つです。 サービスとそれに関連付けられるリソースの種類の一覧については、リソース プロバイダーに関するページをご覧ください。

同様に、Azure Monitor では、コア監視データがリソースの種類 (名前空間とも呼ばれます) に基づいてメトリックとログに整理されます。 リソースの種類に応じてさまざまなメトリックとログが使用できます。 サービスは、複数のリソースの種類に関連付けられる可能性があります。

AKS のリソースの種類の詳細については、「Azure Kubernetes Service 監視データ リファレンス」を参照してください。

データ ストレージ

Azure Monitor の場合:

  • メトリック データは、Azure Monitor メトリック データベースに保存されます。
  • ログ データは、Azure Monitor ログ ストアに保存されます。 Log Analytics は、Azure portal のツールの 1 つであり、このストアに対してクエリを実行することができます。
  • Azure アクティビティ ログは、Azure Portal 内の独自のインターフェイスを持つ別のストアです。

必要に応じて、メトリックおよびアクティビティ ログ データを Azure Monitor ログ ストアにルーティングできます。 次に、Log Analytics を使用してデータのクエリを実行し、他のログ データと関連付けることができます。

多くのサービスで診断設定を使用して、メトリックとログ データを Azure Monitor の外部の他のストレージの場所に送信できます。 たとえば、Azure Storage、ホステッド パートナー システム、Event Hubs を使用する Azure 以外のパートナー システムなどがあります。

Azure Monitor によるデータの保存方法の詳細については、「Azure Monitor データ プラットフォーム」を参照してください。

Azure Monitor プラットフォームのメトリック

Azure Monitor により、ほとんどのサービスに関するプラットフォーム メトリックが提供されます。 これらのメトリックは次のとおりです。

  • 名前空間ごとに個別に定義されます。
  • Azure Monitor 時系列メトリック データベースに保存されます。
  • 軽量であり、凖リアルタイムのアラートをサポートできます。
  • リソースのパフォーマンスを時間の経過と共に追跡するために使用されます。

収集: Azure Monitor では、プラットフォーム メトリックを自動的に収集します。 構成は必要ありません。

ルーティング: また、いくつかのプラットフォーム メトリックを Azure Monitor ログまたは Log Analytics にルーティングして、他のログ データを使用してクエリを実行することもできます。 各メトリックの DS エクスポート設定を確認して、診断設定を使用してメトリックを Azure Monitor ログまたは Log Analytics にルーティングできるかどうかを確認します。

Azure Monitor ですべてのリソースに対して収集できるすべてのメトリックの一覧については、Azure Monitor でサポートされるメトリックに関する記事を参照してください。

AKS に使用できるメトリックの一覧については、「Azure Kubernetes Service 監視データ リファレンス」をご覧ください。

メトリックは、クラスターの監視、問題の特定、AKS クラスターでのパフォーマンスの最適化において重要な役割を果たします。 プラットフォーム メトリックは、kube-system 名前空間にインストールされている既定のメトリック サーバーを使用してキャプチャされます。このサーバーは、Kubelet によって提供されるすべての Kubernetes ノードからメトリックを定期的に収集します。 Azure Managed Prometheus メトリックを有効にして、コンテナー メトリックと Kubernetes オブジェクト メトリック (デプロイのオブジェクトの状態など) を収集する必要もあります。 詳細については、「AKS クラスターから Prometheus メトリックを収集する」を参照してください。

AKS では、Azure Managed Prometheus を介して API サーバー、ETCD、Scheduler などの重要なコントロール プレーン コンポーネントからのメトリックも公開されます。 現在、この機能はプレビュー段階にあります。 詳細については、「Azure Kubernetes Service (AKS) コントロール プレーン メトリックの監視 (プレビュー)」を参照してください。

Azure Monitor ベース以外のメトリック

このサービスは、Azure Monitor メトリック データベースに含まれていない他のメトリックを提供します。

Azure Monitor の次の Azure サービスと機能は、Kubernetes クラスターの追加の監視に使用できます。 これらの機能は、AKS クラスターの作成時に、Azure portal、Azure CLI、Terraform、Azure Policy の [統合] タブから有効にすることも、後でクラスターにオンボードすることもできます。 これらの各機能にはコストが発生する可能性があるため、有効にする前にそれぞれの価格情報を参照してください。

サービスまたは機能 説明
Container insights コンテナー化されたバージョンの Azure Monitor エージェントを使用して、クラスター内の各ノードから stdout/stderr ログと Kubernetes イベントを収集します。 この機能は、AKS クラスターのさまざまな監視シナリオをサポートしています。 Azure CLI、Azure Policy、Azure portal、または Terraform を使用して、AKS クラスターの作成時に監視を有効にすることができます。 クラスターの作成時に Container 分析情報を有効にしていない場合は、「Azure Kubernetes Service (AKS) クラスターの Container 分析情報を有効にする」を参照し、他のオプションでそれを有効にしてください。

Container insights は、そのデータの大部分を Log Analytics ワークスペースに格納し、通常はクラスターのリソース ログと同じログ分析ワークスペースを使用します。 使用する必要があるワークスペースの数と、それらを配置する場所については、「Log Analytics ワークスペース アーキテクチャを設計する」を参照してください。
Prometheus 用の Azure Monitor マネージド サービス Prometheus は、Cloud Native Compute Foundation によるクラウド ネイティブのメトリック ソリューションです。 これは、Kubernetes クラスターからメトリック データを収集および分析するために使用される最も一般的なツールです。 Prometheus 用 Azure Monitor マネージド サービスは、Azure での、フル マネージド Prometheus 互換監視ソリューションです。 クラスターの作成時にマネージド Prometheus を有効にしていない場合は、「AKS クラスターから Prometheus メトリックを収集する」を参照し、他のオプションでそれを有効にしてください。

Prometheus 用 Azure Monitor マネージド サービスでは、データを Azure Monitor ワークスペースに格納します。そこは Grafana ワークスペースにリンクされているため、Azure Managed Grafana を使用してデータを分析できます。
Azure Managed Grafana Grafana のフル マネージド実装。これは、Prometheus データを表示するために一般的に使用される、オープンソースのデータの可視化プラットフォームです。 Kubernetes の監視とフル スタックのトラブルシューティングのために、複数の定義済みの Grafana ダッシュボードを使用できます。 クラスターの作成時にマネージド Grafana を有効にしない場合は、「Grafana ワークスペースをリンクする」を参照してください。 Azure Monitor ワークスペースにリンクして、クラスターの Prometheus メトリックにアクセスできるようにします。

AKS コントロール プレーン メトリックの監視 (プレビュー)

このセクションでは、コントロール プレーン メトリック (プレビュー) 機能を使用する方法について説明します。 コントロール プレーンからメトリックを収集し、Azure Monitor でテレメトリを表示する方法について説明します。 コントロール プレーン メトリック機能は、Prometheus および Grafana と完全に互換性があります。 この機能によって、API サーバー、ETCD、Scheduler、Autoscaler、コントローラー マネージャーなどのコントロール プレーン コンポーネントの可用性とパフォーマンスをより詳細に把握できます。 これらのメトリックを使用して、全体的な可観測性を最大化し、AKS クラスターのオペレーショナル エクセレンスを維持できます。

前提条件と制限事項

aks-preview 拡張機能をインストールする

重要

AKS のプレビュー機能は、セルフサービスのオプトイン単位で利用できます。 プレビューは、"現状有姿" および "利用可能な限度" で提供され、サービス レベル アグリーメントおよび限定保証から除外されるものとします。 AKS プレビューは、ベストエフォート ベースでカスタマー サポートによって部分的にカバーされます。 そのため、これらの機能は、運用環境での使用を意図していません。 詳細については、次のサポート記事を参照してください。

  • az extension add または az extension update コマンドを使用して、aks-preview Azure CLI 拡張機能をインストールまたは更新します。

    # Install the aks-preview extension
az extension add --name aks-preview

# Update the aks-preview extension
az extension update --name aks-preview

AzureMonitorMetricsControlPlanePreview フラグを登録する

  1. az feature register コマンドを使用して、AzureMonitorMetricsControlPlanePreview 機能フラグを登録します。

    az feature register --namespace "Microsoft.ContainerService" --name "AzureMonitorMetricsControlPlanePreview"

    状態が [登録済み] と表示されるまでに数分かかります。

  2. az feature show コマンドを使用して、登録の状態を確認します。

    az feature show --namespace "Microsoft.ContainerService" --name "AzureMonitorMetricsControlPlanePreview"

  3. 状態が Registered と表示されたら、az provider register コマンドを使用して Microsoft.ContainerService リソース プロバイダーの登録を最新の情報に更新します。

    az provider register --namespace "Microsoft.ContainerService"

AKS クラスターでコントロール プレーン メトリックを有効にする

新しいクラスターの作成または既存のクラスターの更新時に、Azure Monitor の Prometheus 用マネージド サービス アドオンを使用してコントロール プレーン メトリックを有効にすることができます。

新しい AKS クラスターでコントロール プレーン メトリックを有効にします。

Kubernetes クラスターから Prometheus メトリックを収集するには、「AKS クラスターの Prometheus と Grafana を有効にする」を参照し、[CLI] タブの「AKS クラスター」の手順に従います。

既存の AKS クラスターでコントロール プレーン メトリックを有効にする

  • ご利用のクラスターに Prometheus アドオンが既にある場合は、az aks update コマンドを使用して、コントロール プレーン メトリックの収集が確実に開始されるようにクラスターを更新します。

    az aks update --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP

Note

クラスター ノードから収集されたメトリックとは異なり、コントロール プレーン メトリックは、ama-metrics アドオンの 一部ではないコンポーネントによって収集されます。 AzureMonitorMetricsControlPlanePreview 機能フラグとマネージド Prometheus アドオンを有効にすると、コントロール プレーン メトリックが確実に収集されます。 メトリック収集を有効した後、データがワークスペースに表示されるまでに数分かかることがあります。

コントロール プレーンのメトリックのクエリを実行する

コントロール プレーン メトリックは、クラスターのリージョンの Azure Monitor ワークスペースに保存されます。 メトリックのクエリは、ワークスペースから直接、またはワークスペースに接続されている Azure Managed Grafana インスタンスを介して実行できます。

コントロール プレーン メトリックは、次の手順を使用して、Azure Monitor ワークスペースで確認します。

  1. Azure portal で自分の AKS クラスターに移動します。

  2. [監視] で [分析情報] を選択します。

    Azure Monitor ワークスペースのスクリーンショット。

Note

AKS には、コントロール プレーンのテレメトリ データをリアルタイムで表示および分析するのに役立つダッシュボード テンプレートが用意されています。 Azure Managed Grafana を使用してデータを視覚化している場合は、次のダッシュボードをインポートできます。

コントロール プレーン メトリックをカスタマイズする

AKS には、コンポーネントごとに収集・保存されるメトリックの事前構成済みセットが含まれています。 API server と etcd は既定で有効になっています。 このリストは、ama-settings-configmap を使用してカスタマイズできます。

既定のターゲットには、次の値が含まれます。

controlplane-apiserver = true
controlplane-cluster-autoscaler = false
controlplane-kube-scheduler = false
controlplane-kube-controller-manager = false
controlplane-etcd = true

すべての ConfigMap を、任意のクラスターの kube-system 名前空間に対して適用する必要があります。

minimal-ingestion プロファイル メトリックの詳細については、「マネージド Prometheus のコントロール プレーン メトリックの最小インジェスト プロファイル」を参照してください。

  • 既定のターゲットから最小メトリックのみを取り込む

    default-targets-metrics-keep-list.minimalIngestionProfile="true" を設定した場合は、既定のターゲットごとに最小限のメトリック セット (controlplane-apiserver と controlplane-etcd) のみが取り込まれます。

  • すべてのターゲットからすべてのメトリックを取り込む

    次の手順を使用して、クラスター上のすべてのターゲットからすべてのメトリックを収集します。

    1. ConfigMap ファイル ama-metrics-settings-configmap.yaml をダウンロードし、名前を configmap-controlplane.yaml に変更します。

    2. minimalingestionprofile = false を設定します。

    3. default-scrape-settings-enabled の下で、スクレイピングするターゲットが true に設定されていることを確認します。 指定できるターゲットは、controlplane-apiserver、controlplane-cluster-autoscaler、controlplane-kube-scheduler、controlplane-kube-controller-manager、controlplane-etcd のみです。

    4. kubectl apply コマンドを使用して ConfigMap を適用します。

      kubectl apply -f configmap-controlplane.yaml

      構成を適用した後、コントロール プレーンから取得した指定されたターゲットのメトリックが Azure Monitor ワークスペースに表示されるまでに数分かかります。

  • 最小限のメトリックに加えて、他のいくつかのメトリックを取り込む

    既定のダッシュボード、既定の記録ルール、既定のアラートで使われるメトリックのみが収集されるため、minimal ingestion profile 設定は、メトリックのインジェスト量を削減するのに役立ちます。 この設定をカスタマイズするには、次の手順を使用します。

    1. ConfigMap ファイル ama-metrics-settings-configmap をダウンロードし、名前を configmap-controlplane.yaml に変更します。

    2. minimalingestionprofile = true を設定します。

    3. default-scrape-settings-enabled の下で、スクレイピングするターゲットが true に設定されていることを確認します。 指定できるターゲットは、controlplane-apiserver、controlplane-cluster-autoscaler、controlplane-kube-scheduler、controlplane-kube-controller-manager、controlplane-etcd のみです。

    4. default-targets-metrics-keep-list の下で、true ターゲットのメトリックの一覧を指定します。 次に例を示します。

      controlplane-apiserver= "apiserver_admission_webhook_admission_duration_seconds| apiserver_longrunning_requests"

    5. kubectl apply コマンドを使用して ConfigMap を適用します。

      kubectl apply -f configmap-controlplane.yaml

    構成を適用した後、コントロール プレーンから取得した指定されたターゲットのメトリックが Azure Monitor ワークスペースに表示されるまでに数分かかります。

  • 一部のターゲットから特定のメトリックのみを取り込む

    1. ConfigMap ファイル ama-metrics-settings-configmap をダウンロードし、名前を configmap-controlplane.yaml に変更します。

    2. minimalingestionprofile = false を設定します。

    3. default-scrape-settings-enabled の下で、スクレイピングするターゲットが true に設定されていることを確認します。 ここで指定できるターゲットは、controlplane-apiserver、controlplane-cluster-autoscaler、controlplane-kube-scheduler、controlplane-kube-controller-manager、controlplane-etcd のみです。

    4. default-targets-metrics-keep-list の下で、true ターゲットのメトリックの一覧を指定します。 次に例を示します。

      controlplane-apiserver= "apiserver_admission_webhook_admission_duration_seconds| apiserver_longrunning_requests"

    5. kubectl apply コマンドを使用して ConfigMap を適用します。

      kubectl apply -f configmap-controlplane.yaml

      構成を適用した後、コントロール プレーンから取得した指定されたターゲットのメトリックが Azure Monitor ワークスペースに表示されるまでに数分かかります。

コントロール プレーン メトリックに関する問題のトラブルシューティング

機能フラグ AzureMonitorMetricsControlPlanePreview が有効になっており、ama-metrics ポッドが実行されていることを確認します。

Note

Azure の Prometheus 用マネージド サービスのトラブルシューティング方法は、コントロール プレーンをスクレイピングするコンポーネントがマネージド Prometheus アドオンには存在しないため、ここでは直接適用できません。

  • ConfigMap の書式設定

    ConfigMap の適切な書式設定を使用していることと、フィールド (具体的には、default-targets-metrics-keep-list、minimal-ingestion-profile、default-scrape-settings-enabled) に意図した値が正しく設定されていることを確認してください。

  • データ プレーンからコントロール プレーンを分離する

    まず、ノード関連のメトリックの一部を true に設定して、メトリックがワークスペースに転送されていることを確認します。 これは、問題がコントロール プレーン メトリックのスクレイピングに固有のものかどうかを判断するのに役立ちます。

  • 取り込まれたイベント

    変更を適用したら、「Azure Monitor の概要」ページ、または選択したクラスターの [監視] セクションからメトリックス エクスプローラーを開き、1 分あたりに取り込まれるイベントの数の増減を確認します。 これは、特定のメトリックが欠落しているか、すべてのメトリックが欠落しているかどうかを判断するのに役立ちます。

  • 特定のメトリックが公開されない

    メトリックが文書化されていても、ターゲットから公開されておらず、Azure Monitor ワークスペースに転送されない場合があります。 この場合は、他のメトリックがワークスペースに転送されていることを確認する必要があります。

  • Azure Monitor ワークスペースにアクセスできない

    アドオンを有効にした際に、アクセス権のない既存のワークスペースを指定した可能性があります。 その場合、メトリックが収集および転送されていないように見える場合があります。 アドオンを有効にする際、またはクラスターの作成時に、新しいワークスペースが作成されたことを確認します。

AKS クラスターでコントロール プレーン メトリックを無効にする

マネージド Prometheus アドオンを無効にするか、AzureMonitorMetricsControlPlanePreview 機能フラグを登録解除することで、いつでもコントロール プレーン メトリックを無効にすることができます。

  1. az aks update コマンドを使用して、Prometheus メトリックをスクレイピングするメトリック アドオンを削除します。

    az aks update --disable-azure-monitor-metrics --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP

  2. az feature unregister コマンドを使用して AzureMonitorMetricsControlPlanePreview 機能フラグの登録を解除して、AKS クラスター上のコントロール プレーン メトリックのスクレイピングを無効にします。

    az feature unregister "Microsoft.ContainerService" --name "AzureMonitorMetricsControlPlanePreview"

よく寄せられる質問

  • コントロール プレーン メトリックは、セルフ ホステッドの Prometheus でスクレイピングできますか?

    いいえ、現在、コントロール プレーン メトリックはセルフ ホステッドの Prometheus でスクレイピングできません。 ロード バランサーによっては、セルフ ホステッドの Prometheus がスクレイピングできるインスタンスは 1 つだけです。 多くの場合、マネージド Prometheus でのみ表示されるコントロール プレーン メトリックのレプリカが複数あるため、これらのメトリックは信頼できません

  • ユーザー エージェントがコントロール プレーン メトリックで使用できないのはなぜですか?

    Kubernetes のコントロール プレーン メトリックにはユーザー エージェントがありません。 ユーザー エージェントは、診断設定で使用可能なコントロール プレーン ログでのみ使用できます。

Azure Monitor リソース ログ

リソース ログでは、Azure リソースによって実行された操作に関する分析情報を提供します。 ログは自動的に生成されますが、保存するかクエリを実行するには、Azure Monitor ログにルーティングする必要があります。 ログはカテゴリに分類されています。 特定の名前空間に複数のリソース ログ カテゴリが含まれる場合があります。

収集: リソース ログは、"診断設定" を作成してログを 1 つ以上の場所にルーティングするまでは収集および保存されません。 診断設定を作成するときは、収集するログのカテゴリを指定します。 診断設定を作成して管理するには、Azure portal、プログラム、Azure Policy など、複数の方法があります。

ルーティング: 既定で推奨されるのは、リソース ログを Azure Monitor ログにルーティングして、他のログ データを使用してクエリを実行できるようにすることです。 Azure Storage、Azure Event Hubs、特定の Microsoft 監視パートナーなど、その他の場所も利用できます。 詳細については、「Azure リソース ログ」およびリソース ログの送信先に関するページを参照してください。

リソース ログの収集、保存、ルーティングの詳細については、「Azure Monitor の診断設定」を参照してください。

Azure Monitor で使用可能なすべてのリソース ログ カテゴリの一覧については、Azure Monitor でサポートされているリソース ログに関するページを参照してください。

Azure Monitor 内のすべてのリソース ログには、同じヘッダー フィールドの後にサービス固有のフィールドがあります。 共通のスキーマの概要については、Azure Monitor リソース ログのスキーマに関する記事をご覧ください。

使用できるリソース ログ カテゴリ、それに関連する Log Analytics テーブル、AKS のログ スキーマについては、「Azure Kubernetes Service 監視データ リファレンス」をご覧ください。

AKS コントロール プレーン/リソース ログ

AKS クラスターのコントロール プレーンのログは、Azure Monitor のリソース ログとして実装されています。 リソース ログは、診断設定を作成して 1 つ以上の場所にルーティングするまでは収集および格納されません。 それらは通常、Log Analytics ワークスペースに送信します。そこが、Container insights のほとんどのデータが格納される場所です。

Azure portal、CLI、または PowerShell を使用して診断設定を作成する詳細な手順については、「診断設定を作成する」を参照してください。 診断設定を作成するときは、収集するログのカテゴリを指定します。 AKS のカテゴリは、AKS 監視データのリファレンスに記載されています。

重要

AKS のリソース ログ収集時には、かなり大きなコストが生じる可能性があります (特に kube-audit ログの場合)。 収集されるデータの量を減らすために、次の推奨事項を検討してください。

  • 不要な場合は、kube-audit ログを無効にします。
  • kube-audit-admin からの収集を有効にします。この場合、監査イベントの取得と一覧表示が除外されます。
  • 以下で説明するようにリソース固有のログを有効にし、AKSAudit テーブルを基本ログとして構成します。

その他の推奨事項については、「Azure サービスとクラウド ネイティブ ツールを使用して Kubernetes クラスターを監視する」を、監視コストを減らすためのその他の戦略については、「コストの最適化と Azure Monitor」を参照してください。

AKS では、リソース ログに対して Azure 診断 モードまたはリソース固有モードがサポートされています。 このモードにより、データが送信される Log Analytics ワークスペース内のテーブルが指定されます。 Azure 診断モードでは、すべてのデータが AzureDiagnostics テーブルに送信されますが、リソース固有のモードでは、「リソース ログ」の表に示されているように、AKS 監査、AKS 監査管理、AKS コントロール プレーンにデータが送信されます。

次の理由から、AKS ではリソース固有モードをお勧めします。

  • データは AKS 専用の個々のテーブル内にあるため、クエリがより簡単です。
  • 大幅なコスト削減のための基本ログとしての構成がサポートされます。

既存の設定を変更する方法など、コレクション モードの違いの詳細については、「コレクション モードを選択する」を参照してください。

Note

CLI を使用して診断設定を構成することもできます。 このような場合、クラスターのプロビジョニング状態がチェックされないため、正常に動作することは保証されません。 構成後、クラスターの診断設定を確認して反映してください。

az monitor diagnostic-settings create --name AKS-Diagnostics --resource /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.ContainerService/managedClusters/my-cluster --logs '[{"category": "kube-audit","enabled": true}, {"category": "kube-audit-admin", "enabled": true}, {"category": "kube-apiserver", "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}]'  --workspace /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/myresourcegroup/providers/microsoft.operationalinsights/workspaces/myworkspace --export-to-resource-specific true

サンプル ログ クエリ

重要

AKS クラスターのメニューから [ログ] を選択すると、クエリのスコープが現在のクラスターに設定された状態で Log Analytics が開かれます。 つまり、ログ クエリには、そのリソースからのデータのみが含まれます。 他のクラスターのデータや他の Azure サービスのデータを含むクエリを実行する場合は、[Azure Monitor] メニューから [ログ] を選択します。 詳細については、「Azure Monitor Log Analytics のログ クエリのスコープと時間範囲」を参照してください。

クラスターの診断設定で Azure 診断 モードが使用されている場合、AKS のリソース ログは AzureDiagnostics テーブルに格納されます。 異なるログは、カテゴリ列で区別できます。 各カテゴリの説明については、「AKS リファレンス リソース ログを」参照してください。

説明 Log query
各カテゴリのログをカウントする
(Azure 診断モード)		 AzureDiagnostics
| where ResourceType == "MANAGEDCLUSTERS"
| summarize count() by Category
すべての API サーバー ログ
(Azure 診断モード)		 AzureDiagnostics
| where Category == "kube-apiserver"
時間範囲内のすべての kube-audit ログ
(Azure 診断モード)		 let starttime = datetime("2023-02-23");
let endtime = datetime("2023-02-24");
AzureDiagnostics
| where TimeGenerated between(starttime..endtime)
| where Category == "kube-audit"
| extend event = parse_json(log_s)
| extend HttpMethod = tostring(event.verb)
| extend User = tostring(event.user.username)
| extend Apiserver = pod_s
| extend SourceIP = tostring(event.sourceIPs[0])
| project TimeGenerated, Category, HttpMethod, User, Apiserver, SourceIP, OperationName, event
すべての監査ログ
(リソース固有モード)		 AKSAudit
get および list 監査イベントを除くすべての監査ログ
(リソース固有モード)		 AKSAuditAdmin
すべての API サーバー ログ
(リソース固有モード)		 AKSControlPlane
| where Category == "kube-apiserver"

Log Analytics ワークスペース内の一連の事前構築済みクエリにアクセスするには、Log Analytics のクエリ インターフェイスを表示し、リソースの種類として [Kubernetes Services] を選択します。 Container 分析情報の一般的なクエリの一覧については、Container 分析情報クエリに関するページを参照してください。

AKS データ プレーン/Container Insights ログ

Container Insights では、コンテナーと Kubernetes クラスターからさまざまな種類のテレメトリ データが収集され、AKS クラスターで実行されているコンテナー化されたアプリケーションの監視、トラブルシューティング、分析情報の取得に役立ちます。 コンテナーの分析情報で使用されるテーブルの一覧と詳細な説明については、「Azure Monitor のテーブル リファレンス」を参照してください。 これらのテーブルはすべて、ログ クエリで使用できます。

コスト最適化の設定 では、コンテナー分析情報エージェントを使用して収集されたメトリック データをカスタマイズおよび制御できます。 この機能は、個々のテーブル選択、データ収集間隔、および名前空間のデータ収集設定をサポートし、Azure Monitor Data Collection Rules (DCR) を使用してデータ収集を除外します。 これらの設定により、インジェストの量が制御され、Container Insights の監視コストが削減されます。 コンテナー分析情報の収集データは、次のオプションを使用して、Azure portal 経由でカスタマイズできます。 [すべて] (既定) 以外のオプションを選択すると、コンテナーの分析情報エクスペリエンスが使用できなくなります。

グループ化 テーブル Notes
すべて (既定値) すべての標準コンテナー分析情報テーブル 既定のコンテナー分析情報の視覚化を有効にするために必要
パフォーマンス Perf、InsightsMetrics
ログとイベント ContainerLog または ContainerLogV2、KubeEvents、KubePodInventory マネージド Prometheus メトリックを有効にしている場合に推奨
ワークロード、デプロイ、および HPA InsightsMetrics、KubePodInventory、KubeEvents、ContainerInventory、ContainerNodeInventory、KubeNodeInventory、KubeServices
永続的ボリューム InsightsMetrics、KubePVInventory

ログとイベント のグループ化では、ContainerLog または ContainerLogV2、KubeEvents、KubePodInventory テーブルから ログがキャプチャされますが、メトリックはキャプチャされません。 メトリックを収集するための推奨パスは、AKS クラスターから Prometheus 用の Azure Monitor マネージド サービス Prometheus for Prometheus を有効にし、データの視覚化に Azure Managed Grafana を使用することです。 詳細については、「Azure Monitor ワークスペースの管理」を参照してください。

ContainerLogV2 スキーマ

Azure Monitor Container Insights には、ContainerLogV2 と呼ばれるコンテナー ログのスキーマが用意されています。これは推奨されるオプションです。 この形式には、AKS および Azure Arc 対応 Kubernetes クラスターに関連するデータを表示するための一般的なクエリを容易にするために、次のフィールドが含まれています:

  • ContainerName
  • PodName
  • PodNamespace

さらに、このスキーマは Basic Logs データ プランと互換性があり、標準の分析ログに代わる低コストの代替手段が提供されます。 基本ログのデータ プランでは、デバッグ、トラブルシューティング、監査用に、大量の詳細ログを Log Analytics ワークスペースに取り込んで保存するコストを削減できます。 分析とアラートのコストには影響しません。 詳細については、「Log Analytics ワークスペースのテーブルを管理する」を参照してください。

ContainerLogV2 は推奨されるアプローチであり、ARM、Bicep、Terraform、Policy、およびAzure portal を使用してマネージド ID 認証を使用してコンテナー分析情報をオンボードするお客様の既定のスキーマです。 クラスターのデータ収集規則 (DCR) または ConfigMap を使用して ContainerLogV2 を有効にする方法の詳細については、「ContainerLogV2 スキーマを有効にする」を参照してください。

Azure activity log

アクティビティ ログには、Azure リソースごとに操作を追跡する、そのリソースの外から見たサブスクリプションレベルのイベント (新しいリソースの作成や仮想マシンの起動など) が含まれます。

収集: アクティビティ ログ イベントは、Azure portal で表示するために、個別のストアに自動的に生成および収集されます。

ルート指定: アクティビティ ログ データを Azure Monitor ログに送信して、他のログ データと共に分析できます。 Azure Storage、Azure Event Hubs、特定の Microsoft 監視パートナーなど、その他の場所も利用できます。 アクティビティ ログをルーティングする方法の詳細については、Azure アクティビティ ログの概要に関するページをご覧ください。

Azure Kubernetes Service (AKS) コンテナー のログ、イベント、ポッドのメトリックをリアルタイムで表示する

このセクションでは、Container Insights の "ライブ データ" 機能を使用して、Azure Kubernetes Service (AKS) コンテナーのログ、イベント、ポッド メトリックをリアルタイムで表示する方法について説明します。 この機能を使用すると、kubectl logs -c、kubectl get イベント、kubectl top pods に直接アクセスして、リアルタイムで問題のトラブルシューティングを行うことができます。

Note

AKS では 、Kubernetes クラスター レベルのログ アーキテクチャが使用されます。 コンテナー ログは、ノードの /var/log/containers 内にあります。 ノードにアクセスするには、「Azure Kubernetes Service (AKS) クラスター ノードへの接続」を参照してください。

ライブ データ 機能の設定については、「Container Insights でのライブ データの構成」を参照してください。 この機能は、Kubernetes API に直接アクセスします。 認証モデルの詳細については、「Kubernetes API」を参照してください。

AKS リソース ライブ ログを表示する

Note

プライベート クラスターのログにアクセスするには、そのクラスターと同じプライベート ネットワーク上のマシンを使用している必要があります。

  1. Azure portal で AKS クラスターに移動します。

  2. [Kubernetes リソース] で、[ワークロード] を選択します。

  3. 表示するログに関するデプロイ、ポッド、レプリカ セット、ステートフル セット、ジョブ または Cron ジョブを選択したら、[ライブ ログ] を選択します。

  4. ログを表示するリソースを選択します。

    次の例は、Pod リソースのログを示しています。

    ライブ ログのデプロイを示すスクリーンショット。

ライブ ログを表示する

[クラスター]、[ノード]、[コントローラー]、または [コンテナー] で、コンテナー エンジンが生成したリアルタイムのログ データを表示できます。

  1. Azure portal で自分の AKS クラスターに移動します。

  2. [監視] で [分析情報] を選択します。

  3. [クラスター]、[ノード]、[コントローラー] または [コンテナー] タブを選択したら、ログを表示するオブジェクトを選択します。

  4. リソースの [概要] で、[ライブ ログ] を選択します。

    Note

    Log Analytics ワークスペースのデータを表示するには、[Log Analytics のログの表示] を選択します。 古いログ、イベント、メトリクスの詳細については、「Container Insights のログをクエリする方法」をご覧ください。

    認証が成功し、データを取得できる場合は、[ライブ ログ] タブへのストリーミングが開始されます。ここでは、ログ データが連続ストリームで表示されます。 次の図は、コンテナー リソースのログを示しています。

    コンテナーの [ライブ ログ] ビューの [データ] オプションを示すスクリーンショット。

ライブ イベントを表示する

[クラスター]、[ノード]、[コントローラー]、または [コンテナー] で、コンテナー エンジンが生成したリアルタイムのイベント データを表示できます。

  1. Azure portal で自分の AKS クラスターに移動します。

  2. [監視] で [分析情報] を選択します。

  3. [クラスター]、[ノード]、[コントローラー] または [コンテナー] タブを選択したら、イベントを表示するオブジェクトを選択します。

  4. リソースの [概要] ページで、[ライブ イベント] を選択します。

    Note

    Log Analytics ワークスペースのデータを表示するには、[Log Analytics のイベントの表示] を選択します。 古いログ、イベント、メトリクスの詳細については、「Container Insights のログをクエリする方法」をご覧ください。

    認証が成功し、データを取得できる場合は、[ライブ イベント] タブへのストリーミングが開始されます。次の図は、コンテナー リソースのイベントを示しています。

    コンテナーの [ライブイベント] ビュー データ オプションを示すスクリーンショット。

メトリックを表示する

[ポッド] リソースを選択すると、[ノード] または [コントローラー] で、コンテナー エンジンが生成したメトリクス データをリアルタイムで表示できます。

  1. Azure portal で自分の AKS クラスターに移動します。

  2. [監視] で [分析情報] を選択します。

  3. [ノード] または [コントローラー] タブを選択し、メトリックを表示する Pod オブジェクトを選択します。

  4. リソースの [概要] ページで、[ライブ メトリクス] を選択します。

    Note

    Log Analytics ワークスペースのデータを表示するには、[Log Analytics のイベントの表示] を選択します。 古いログ、イベント、メトリクスの詳細については、「Container Insights のログをクエリする方法」をご覧ください。

    認証が成功し、データを取得できる場合は、[ライブ メトリクス] タブへのストリーミングが開始されます。次の図は、ポッド リソースのメトリクスを示しています。

    ポッドの [ライブ メトリクス] ビュー データ オプションを示すスクリーンショット。

監視データを分析する

監視データを分析するためのツールは多数あります。

Azure Monitor ツール

Azure Monitor は、次の基本的なツールをサポートします。

より複雑な視覚化を可能にするツールは次のとおりです。

  • ダッシュボードを使用すると、さまざまな種類のデータを組み合わせて、Azure portal 内の 1 つのペインに表示できます。
  • ブック。Azure portal で作成できるカスタマイズ可能なレポート。 ブックには、テキスト、メトリック、ログ クエリを含めることができます。
  • Grafana。運用ダッシュボードに優れたオープン プラットフォーム ツール。 Grafana を使用して、Azure Monitor 以外の複数のソースからのデータを含むダッシュボードを作成できます。
  • Power BI。さまざまなデータ ソースにわたって対話型の視覚化を提供するビジネス分析サービス。 Azure Monitor からログ データを自動的にインポートするように Power BI を構成して、これらの視覚化を利用できます。

Azure Monitor エクスポート ツール

次の方法を使用して、Azure Monitor から他のツールにデータを取得できます。

Azure Monitor 用 REST API の使用を開始するには、「Azure 監視 REST API のチュートリアル」を参照してください。

Azure portal の [監視の概要] ページ

AKS クラスター リソースの [概要] ページの [監視] タブでは、Azure portal で監視データをすばやく表示するための方法を提供します。 このタブには、ノード プールごとに分割されたクラスターの一般的なメトリックが表示されるグラフが含まれます。 これらのグラフのいずれかを選択して、メトリックス エクスプローラーでデータをさらに分析します。

[監視] タブには、クラスターの [マネージド Prometheus] と [コンテナーの分析情報] へのリンクも含まれています。 これらのツールを有効にする必要がある場合は、ここで有効にすることができます。 また、クラスターの監視を向上させるために他の機能を有効にすることを推奨するバナーが画面の上部に表示される場合もあります。

ヒント

Azure portal のホーム ページで [Azure Monitor] を選択すると、サブスクリプション内のすべての AKS クラスターの監視機能にアクセスできます。

Kusto クエリ

Kusto クエリ言語 (KQL) を使用して、Azure Monitor ログ/Log Analytics ストアの監視データを分析できます。

重要

ポータルでサービスのメニューから [ログ] を選択すると、クエリ スコープが現在のサービスに設定された状態で Log Analytics が開きます。 このスコープは、ログ クエリにその種類のリソースのデータのみが含まれることを意味します。 他の Azure サービスのデータを含むクエリを実行する場合は、[Azure Monitor] メニューから [ログ] を選択します。 詳細については、「Azure Monitor Log Analytics のログ クエリのスコープと時間範囲」を参照してください。

いずれかのサービスに関する一般的なクエリの一覧については、Log Analytics クエリ インターフェイスに関するページを参照してください。

警告

Azure Monitor のアラートにより、監視データで特定の状態が見つかったときに事前に通知を受け取ります。 アラートにより、ユーザーが気付く前に、管理者が問題を識別して対処できます。 詳細については、Azure Monitor アラートに関するページを参照してください。

Azure リソースに関する一般的なアラートのソースは数多くあります。 Azure リソースに関する一般的なアラートの例については、ログ アラート クエリのサンプルに関するページをご覧ください。 Azure Monitor ベースライン アラート (AMBA) サイトには、重要なプラットフォーム メトリック アラート、ダッシュボード、ガイドラインを実装するための半自動化された方法が用意されています。 このサイトは、Azure ランディング ゾーン (ALZ) の一部であるすべてのサービスを含む、Azure サービスの継続的に拡張されるサブセットに適用されます。

共通アラート スキーマを使用すると、Azure Monitor のアラート通知の使用を標準化できます。 詳細については、「共通アラート スキーマ」をご覧ください。

アラートの種類

Azure Monitor データ プラットフォームでは、任意のメトリックまたはログ データ ソースに対してアラートを生成できます。 監視するサービスと収集する監視データに応じて、さまざまな種類のアラートがあります。 アラートの種類に応じて、さまざまな利点と欠点があります。 詳細については、適切な種類の監視アラートの選択に関するページをご覧ください。

次の一覧では、作成できる Azure Monitor アラートの種類について説明します。

  • メトリック アラートでは、リソース メトリックを定期的に評価します。 メトリックはプラットフォーム メトリック、カスタム メトリック、メトリックに変換された Azure Monitor からのログまたは Application Insights メトリックにすることができます。 メトリック警告では、複数の条件と動的しきい値を適用することもできます。
  • ログ アラートでは、ユーザーは Log Analytics クエリを使用して、定義済みの頻度でリソース ログを評価できます。
  • アクティビティ ログ アラートは、定義された条件と一致する新しいアクティビティ ログ イベントが発生したときにトリガーされます。 Resource Health アラートと Service Health アラートは、サービスとリソースの正常性を報告するアクティビティ ログ アラートです。

一部の Azure サービスでは、スマート検出アラート、Prometheus アラート、推奨されるアラート ルールもサポートされています。

一部のサービスでは、同じ Azure リージョン内に存在する同じ種類の複数のリソースに同じメトリック警告ルールを適用することで、大規模に監視することができます。 監視対象リソースごとに個別の通知が送信されます。 サポートされている Azure サービスとクラウドについては、「1 つのアラート ルールで複数のリソースを監視する」をご覧ください。

一部の Azure サービスでは、推奨される既定の警告ルールを有効にすることができます。

次に基づいて、推奨される警告ルールの一覧がシステムによってコンパイルされます。

  • リソースを監視するための重要なシグナルとしきい値についてのリソース プロバイダーの知識。
  • 顧客が一般的に、このリソースの警告を何に対して行っているかを示すデータ。

Note

推奨される警告ルールは、次の場合に使用できます。

  • 仮想マシン
  • Azure Kubernetes Service (AKS) リソース
  • Log Analytics ワークスペース

Prometheus メトリックベースのアラート

クラスターに対して Prometheus メトリックの収集を有効にすると、推奨される Prometheus アラート ルールのコレクションをダウンロードできます。 このダウンロードには、次のルールが含まれています。

Level 警告
クラスター レベル KubeCPUQuotaOvercommit
KubeMemoryQuotaOvercommit
KubeContainerOOMKilledCount
KubeClientErrors
KubePersistentVolumeFillingUp
KubePersistentVolumeInodesFillingUp
KubePersistentVolumeErrors
KubeContainerWaiting
KubeDaemonSetNotScheduled
KubeDaemonSetMisScheduled
KubeQuotaAlmostFull
Node レベル KubeNodeUnreachable
KubeNodeReadinessFlapping
ポッド レベル KubePVUsageHigh
KubeDeploymentReplicasMismatch
KubeStatefulSetReplicasMismatch
KubeHpaReplicasMismatch
KubeHpaMaxedOut
KubePodCrashLooping
KubeJobStale
KubePodContainerRestart
KubePodReadyStateLow
KubePodFailedState
KubePodNotReadyByController
KubeStatefulSetGenerationMismatch
KubeJobFailed
KubeContainerAverageCPUHigh
KubeContainerAverageMemoryHigh
KubeletPodStartUpLatencyHigh

「Container Insights からログ アラートを作成する方法」と「Container Insights からログを照会する方法」を参照してください。 ログ アラート では、さまざまなシナリオで監視することができる次の 2 つの異なる事柄を測定できます:

  • 結果数: クエリによって返された行の数をカウントします。Windows イベント ログ、Syslog、アプリケーション例外などのイベントを操作するのに使用できます。
  • 値の計算: 数値列に基づいて計算を行います。任意の数のリソースを含めるために使用できます。 たとえば、CPU の割合です。

必要なアラート シナリオに応じて、 now 演算子を使用して 1 時間戻すことで、DateTime と現在の時刻を比較するログ クエリを作成する必要があります。 ログ ベースのアラートを作成する方法については、「Container insights からログ アラートを作成する」を参照してください。

AKS アラート ルール

次の表に、AKS に推奨されるアラート ルールをいくつか示します。 これらのアラートは例に過ぎません。 「Azure Kubernetes Service 監視データ リファレンス」の中に一覧表示されている任意のメトリック、ログ エントリ、またはアクティビティ ログ エントリに対してアラートを設定することができます。

条件 説明
CPU 使用率 (%) > 95 すべてのノードにわたる平均 CPU 使用率がしきい値を超えると発生します。
メモリ ワーキング セット (%) > 100 すべてのノードにわたる平均ワーキング セットがしきい値を超えると発生します。

Advisor の推奨事項

一部のサービスでは、リソースの操作中にクリティカルな条件や差し迫った変更が発生した場合は、ポータルのサービス [概要] ページにアラートが表示されます。 アラートの詳細と推奨される修正は、左側のメニューの [監視] の下の [アドバイザーのレコメンデーション] に表示されます。 通常の操作中、アドバイザーのレコメンデーションは表示されません。

Azure Advisor の詳細については、Azure Advisor の概要に関するページをご覧ください。

Note

サービスで動作するアプリケーションを作成または実行している場合、Azure Monitor Application Insights は他の種類の警告を表示する場合があります。

ネットワークの監視

ネットワーク監視 は、正常でパフォーマンスの高い Kubernetes クラスターを維持するための重要な部分です。 ネットワーク トラフィックに関するデータを収集し分析することで、クラスターがどのように動作しているかを把握し、障害やパフォーマンス低下を引き起こす前に潜在的な問題を特定できます。

Network Observability アドオンを有効にすると、有用なメトリックが収集され、Prometheus 形式に変換され、これは Grafana で視覚化できます。 有効にすると、収集されたメトリックは Prometheus の Azure Monitor マネージド サービスに自動的に取り込まれます。 Grafana ダッシュボードは、Prometheus によって収集されたネットワーク監視メトリックを視覚化するために、Grafana パブリック ダッシュボード リポジトリで使用できます。 詳細な手順については、「ネットワーク監視のセットアップ」を参照してください。

関連するコンテンツ