Azure サービスとクラウド ネイティブ ツールを使用して Kubernetes クラスターを監視する

この記事では、Azure Monitor と関連する Azure およびクラウド ネイティブ サービスを使用して、そこで実行されている Kubernetes クラスターやワークロードの正常性とパフォーマンスを監視する方法について説明します。 これには、Azure Kubernetes Service (AKS) または AWS や GCP などの他のクラウドで実行されているクラスターが含まれます。 Kubernetes 環境を構成する一意のコンポーネントを通常管理するロールごとに、さまざまな一連のガイダンスが用意されています。

重要

この記事では、他のクラウドの Azure Kubernetes Service (AKS) または Kubernetes クラスターに基づいて、Kubernetes 環境のさまざまなレイヤーを監視するための完全なガイダンスについて説明します。 AKS または Azure Monitor を使い始めたばかりの場合は、AKS クラスターの監視を開始するための基本情報を確認できる「AKS の監視」を参照してください。

Kubernetes 環境のレイヤーとロール

インフラストラクチャ レイヤーからアプリケーションまで、一般的な Kubernetes 環境の共通モデルを次に示します。 各レイヤーには、異なるサービスで対処され、通常は組織内のさまざまなロールによって管理される個別の監視要件があります。

Kubernetes 環境のさまざまなレイヤーと、それに依存するアプリケーションに対する責任は、通常、複数のロールによって対処されます。 組織内のサイズによっては、これらのロールは、異なるユーザーやチームによって実行される場合があります。 次の表では、さまざまなロールについて説明しますが、以下のセクションでは、それぞれが通常発生する監視シナリオを示します。

ロール	説明
開発者	クラスター上で実行されているアプリケーションを開発し、維持します。 アプリケーションのパフォーマンスや失敗など、アプリケーション固有のトラフィックを担当します。 SLA に従ってアプリケーションの信頼性を維持します。
プラットフォーム エンジニア	Kubernetes クラスターを担当します。 開発者が使用するプラットフォームをプロビジョニングし、維持します。
ネットワーク エンジニア	ワークロードとクラスターのイングレス/エグレスとの間のトラフィックを担当します。 ネットワーク トラフィックを分析し、脅威分析を実行します。

監視ツールの選択

Azure には、Kubernetes インフラストラクチャのさまざまなレイヤーと、それに依存するアプリケーションの正常性とパフォーマンスを監視するための Azure Monitor に基づくサービスの完全なセットが用意されています。 これらのサービスは相互に連携して完全な監視ソリューションを提供し、AKS と他のクラウドで実行中の Kubernetes クラスターの両方に推奨されます。 Cloud Native Computing Foundation に承認されているクラウド ネイティブ テクノロジーに既に投資している場合は、Azure ツールを既存の環境に統合することを選択できます。

デプロイするツールとその構成の選択は、特定の環境の要件によって異なります。 たとえば、Prometheus と Grafana 用に Azure でマネージド オファリングを使用したり、これらのツールの既存のインストールを Azure の Kubernetes クラスターで使用したりすることができます。 組織では、Container Insights に代わるツールを使用して、Splunk や Datadog などの Kubernetes ログを収集および分析することもできます。

重要

Kubernetes などの複雑な環境を監視するには、大量のテレメトリを収集する必要があり、多くの場合にコストが発生します。 要件を満たすのに十分なデータのみを収集する必要があります。 これには、収集されるデータの量、収集の頻度、および保持期間が含まれます。 コスト意識が非常に高い場合は、監視の支出を削減するために、完全な機能のサブセットを実装することを選択できます。

ネットワーク エンジニア

ネットワーク エンジニアは、ワークロードとクラスターのイングレス/エグレスとの間のトラフィックを担当します。 ネットワーク トラフィックを分析し、脅威分析を実行します。

ネットワーク管理者向けの Azure サービス

次の表に、Kubernetes クラスターをサポートしているネットワークの正常性とパフォーマンスを監視するために、ネットワーク エンジニアが一般的に使用するサービスの一覧を示します。

サービス	説明
Network Watcher	Kubernetes クラスターで使用される仮想ネットワークを監視し、検出された問題を診断するための Azure の一連のツール。
トラフィック分析	フロー ログを分析してトラフィック フローに関する分析情報を提供する Network Watcher の機能。
ネットワークの分析情報	さまざまなネットワーク コンポーネントのパフォーマンスと正常性を視覚的に表現し、Network Watcher の一部であるネットワーク監視ツールへのアクセスを提供する Azure Monitor の機能。

ネットワーク分析情報は既定で有効になっており、構成は必要ありません。 Network Watcher は、通常、各 Azure リージョンで既定で有効になっています。

監視レベル 1 - ネットワーク

ネットワークを監視するための一般的なシナリオを次に示します。

• フロー ログを作成して、クラスターで使用されるネットワーク セキュリティ グループを流れる IP トラフィックに関する情報をログに記録し、トラフィック分析を使用して、このデータに関する分析情報を分析して提供します。 トラフィック分析には、多くの場合、コンテナーの分析情報とコントロール プレーン ログに使用しているものと同じ Log Analytics ワークスペースが使用されます。
• トラフィック分析を使用すると、クラスターによって使用される予期しないポートとの間でトラフィックが流れているかどうか、また、公開すべきではないパブリック IP 経由でトラフィックが流れているかどうかを判断できます。 この情報を使用して、ネットワーク ルールを変更する必要があるかどうかを判断します。
• AKS クラスターの場合は、AKS のネットワーク監視機能アドオン (プレビュー) を使用して、クラスター内のサービス (東西のトラフィック) 間のアクセスを監視します。

プラットフォーム エンジニア

プラットフォーム エンジニア (クラスター管理者とも呼ばれます) は、Kubernetes クラスター自体を担当します。 開発者が使用するプラットフォームをプロビジョニングして維持します。 クラスターとそのコンポーネントの正常性を把握し、検出された問題をトラブルシューティングできるようにする必要があります。 また、クラスターを運用するためのコストを把握し、さまざまなチームにコストを割り当てることができるようにすることも必要です。

大規模な組織には、プラットフォーム エンジニアに似ているものの、複数のクラスターを担当するフリート アーキテクトがいる場合もあります。 環境全体を視覚化することが必要であり、大規模な管理タスクを実行する必要があります。 下のガイダンスには大規模な推奨事項が含まれています。 マルチクラスターおよび大規模なシナリオ用のフリート リソースの作成の詳細については、「Azure Kubernetes Fleet Manager (プレビュー)とは?」を参照してください。

プラットフォーム エンジニア向けの Azure サービス

次の表に、プラットフォーム エンジニアが Kubernetes クラスターとそのコンポーネントの正常性とパフォーマンスを監視するための Azure サービスの一覧を示します。

サービス	説明
Container Insights	コンテナー化されたバージョンの Azure Monitor エージェントを使用して、クラスター内の各ノードから stdout/stderr ログ、パフォーマンス メトリック、Kubernetes イベントを収集する、AKS と Azure Arc 対応 Kubernetes 向け Azure サービス。 また、Kubernetes コントロール プレーンからメトリックを収集し、ワークスペースに格納します。 Azure portal のデータを表示したり、Log Analytics を使用してクエリを実行したりすることができます。
Prometheus 用の Azure Monitor マネージド サービス	Prometheus は、Cloud Native Compute Foundation のクラウドネイティブ メトリック ソリューションで、Kubernetes クラスターからメトリック データを収集して分析するために使用される最も一般的なツールです。 Azure Monitor の Prometheus 用マネージド サービスは、Prometheus クエリ言語 (PromQL) および Prometheus アラートと互換性があり、視覚化のために Azure Managed Grafana と統合されたフル マネージド ソリューションです。 このサービスは、独自の Prometheus 環境の管理を複雑にすることなく、オープンソース ツールへの投資をサポートします。
Azure Arc 対応 Kubernetes	他のクラウド上で実行されている Kubernetes クラスターを Azure で管理および構成できるようにアタッチできます。 Arc エージェントをインストールすると、Container Insights や Prometheus など、同じメソッドとツールを使用して、AKS クラスターとハイブリッド クラスターを一緒に監視できます。
Azure Managed Grafana	Grafana のフル マネージド実装。これは、Prometheus データやその他のデータを表示するために一般的に使用される、オープンソースのデータの可視化プラットフォームです。 Kubernetes の監視とフル スタックのトラブルシューティングのために、複数の定義済みの Grafana ダッシュボードを使用できます。

プラットフォーム エンジニアの監視を構成する

以下のセクションでは、上記の表の Azure サービスを使用して Kubernetes 環境を完全に監視する手順を示します。 機能と統合のオプションは、特定の要件を満たすためにこの構成を変更する必要がある場所を決定するのに役立ちます。

Prometheus メトリックのスクレイピングを有効にする

重要

Prometheus 用 Azure Monitor マネージド サービスを使用するには、Azure Monitor ワークスペースが必要です。 ワークスペース構成の設計上の考慮事項については、Azure Monitor のワークスペースのアーキテクチャを参照してください。

次のいずれかのメソッドを使用して、クラスターから Prometheus の Azure Monitor マネージド サービスによる Prometheus メトリックのスクレイピングを有効にします。

• AKS クラスターの作成時に [Prometheus メトリックを有効にする] オプションを選択します。
• 既存の AKS クラスターまたは Azure Arc 対応 Kubernetes クラスターで Container insights を有効にする場合は、[Prometheus メトリックを有効にする] オプションを選択します。
• 既存の AKS クラスターまたは Arc 対応 Kubernetes クラスター (プレビュー) に対して有効にします。

AKS クラスターに使用する Prometheus 環境が既にある場合は、Prometheus の Azure Monitor マネージド サービスを有効にしてから、リモート書き込みを使用して既存の Prometheus 環境にデータを送信します。 リモート書き込みを使用して、既存のセルフマネージド Prometheus 環境から Prometheus 用の Azure Monitor マネージド サービスにデータを送信することもできます。

既定で収集されるメトリックとその収集頻度に関する詳細については、「Azure Monitor での既定の Prometheus メトリック構成」を参照してください。 構成をカスタマイズする場合は、「Prometheus の Azure Monitor マネージド サービスで Prometheus メトリックのスクレイピングをカスタマイズする」を参照してください。

Prometheus データの分析で Grafana を有効にする

データ ソースとして Prometheus データを使用できるようにするために、Managed Grafana のインスタンスを作成し、Azure Monitor ワークスペースにリンクします。 Azure Monitor の Prometheus 用マネージド サービスをデータ ソースとして追加して、この構成を手動で実行することもできます。 Kubernetes クラスターの監視には、Container insights ビューと同様の情報を表すダッシュボードなど、さまざまな事前構築済みダッシュボードを使用できます。

既存の Grafana 環境がある場合は、引き続き使用して、Prometheus の Azure Monitor マネージド サービスをデータ ソースとして追加できます。 Azure Monitor データ ソースを Grafana に追加して、Container insights で収集されたデータをカスタム Grafana ダッシュボードで使用することもできます。 Container insights のビューとレポートを使用するのではなく、Grafana ダッシュボードに重点を置く場合は、この構成を実行します。

ログの収集に Container Insights を有効にする

Kubernetes クラスターに対して Container Insights を有効にした場合、コンテナー化されたバージョンの Azure Monitor エージェントがデプロイされ、これによりデータが Azure Monitor の Log Analytics ワークスペースに送信されます。 Container insights では、コンテナー stdout/stderr、インフラストラクチャ ログ、およびパフォーマンス データが収集されます。 すべてのログ データは Log Analytics ワークスペースに格納され、Kusto クエリ言語 (KQL) を使用して分析できます。

Kubernetes クラスターをオンボードするための前提条件と構成オプションについては、「Container insights を有効にする」を参照してください。 Azure Policy を使用してオンボードし、すべてのクラスターで一貫した構成が維持されるようにします。

クラスターに対して Container insights を有効にしたら、次のアクションを実行してインストールを最適化します。

• コンテナー分析情報では、Prometheus と同じメトリック値の多くが収集されます。 これらのメトリックの収集を無効にするには、「Container insights でコスト最適化設定を有効にする」の説明に従って、ログとイベントのみを収集するようにコンテナー分析情報を構成します。 この構成により、Azure portal でのコンテナー分析情報のエクスペリエンスは無効になりますが、Grafana を使用して Prometheus メトリックを視覚化し、Log Analytics を使用してコンテナー分析情報によって収集されたログ データを分析できます。
• 収集されるデータの量を減らすことで、Container Insights データ インジェストのコストを削減します。
• Container insights で収集されたデータに関するクエリ エクスペリエンスを向上させ、収集コストを削減するには、クラスターごとに ContainerLogV2 スキーマを有効にします。 不定期のトラブルシューティングにのみログを使用する場合は、この表を基本ログとして構成することを検討してください。

ログ収集用の既存のソリューションがある場合は、そのツールのガイダンスに従うか、Container insights を有効にして、Log Analytics ワークスペースのデータ エクスポート機能を使用して、データをAzure Event Hubsに送信し、別のシステムに転送します。

AKS クラスターのコントロール プレーン ログを収集する

AKS コントロール プレーン コンポーネントのログは、リソース ログとして Azure に実装されます。 コンテナーの分析情報はこれらのログを使わないため、それらを表示して分析するために独自のログ クエリを作成する必要があります。 ログの構造とクエリの詳細については、「コンテナー分析情報からのクエリ ログ」を参照してください。

AKS リソース ログを Log Analytics ワークスペースに送信するには、各 AKS クラスターの診断設定を作成します。 Azure Policy を使用して、複数のクラスター間で一貫した構成を確保します。

リソース ログをワークスペースに送信するにはコストがかかるため、使うログ カテゴリのみを収集する必要があります。 AKS で使用できるカテゴリの説明については、「リソース ログ」を参照してください。 最初は最小限の数のカテゴリを収集することから始め、ニーズの増加と関連するコストの理解に応じて、診断設定を変更して追加のカテゴリを収集します。 コンプライアンス上の理由で情報を保持する必要がある場合は、Azure Storage アカウントにログを送信してコストを削減できます。 ログ データの取り込みと保持のコストの詳細については、Azure Monitor Logs の料金の詳細に関する記事を参照してください。

最初に有効にするリソース ログがわからない場合は、最も一般的な顧客の要件に基づく次の推奨事項を使用します。 必要に応じて、後で他のカテゴリを有効にできます。

カテゴリ	有効にするかどうか	宛先
kube-apiserver	有効化	Log Analytics ワークスペース
kube-audit	有効化	Azure ストレージ。 これにより、コストを最小限に抑えながら、監査ログが監査担当者に必要な場合は維持します。
kube-audit-admin	有効化	Log Analytics ワークスペース
kube-controller-manager	有効化	Log Analytics ワークスペース
kube-scheduler	無効にする
cluster-autoscaler	自動スケーリングが有効になっている場合は有効化	Log Analytics ワークスペース
guard	Microsoft Entra ID が有効な場合は有効にする	Log Analytics ワークスペース
AllMetrics	Managed Prometheus でメトリックが収集されるため、無効にする	Log Analytics ワークスペース

ログ収集用の既存のソリューションがある場合は、そのツールのガイダンスに従うか、Container insights を有効にして、Log Analytics ワークスペースのデータ エクスポート機能を使用して、データをAzure Event Hubsに送信し、別のシステムに転送します。

AKS クラスターのアクティビティ ログを収集する

AKS クラスターに対する構成の変更は、アクティビティ ログに格納されます。 診断設定を作成して、このデータを Log Analytics ワークスペースに送信し、他の監視データと一緒に分析します。 このデータ収集にはコストはかからず、Log Analytics を使用してデータを分析またはアラートできます。

モニター レベル 2 - クラスター レベルのコンポーネント

クラスター レベルには、次のコンポーネントが含まれます。

コンポーネント	要件の監視
ノード	各ノードの CPU、メモリ、ディスク、IP 使用の準備状態とパフォーマンスを理解し、ワークロードをデプロイする前に、それらの使用状況の傾向を予防的に監視します。

クラスター レベルのコンポーネントを監視するための一般的なシナリオを次に示します。

Container insights

• [クラスター] ビューを使って、CPU とメモリの使用率など、クラスター内のノードのパフォーマンスを確認します。
• [ノード] ビューを使って、各ノードの正常性と、そこで実行されているポッドの正常性とパフォーマンスを確認します。 ノードの正常性とパフォーマンスの分析の詳細については、「Container insights を使用して Kubernetes クラスターのパフォーマンスを監視する」を参照してください。
• [レポート] では、[Node Monitoring] (ノードの監視) ブックを使って、ディスク容量、ディスク IO、GPU 使用率を分析します。 これらのブックの詳細については、「ノード監視のブック」を参照してください。
• [監視] で [ブック]、[Subnet IP Usage] (サブネット IP の使用状況) の順に選び、選んだ時間範囲に関する各ノードの IP 割り当てと割り当てを確認します。

Grafana ダッシュボード

• Kubelet 用 Managed Grafana の事前構築済みダッシュボードを使用して、それぞれの正常性とパフォーマンスを確認します。
• node_disk_io_time_seconds_total や windows_logical_disk_free_bytes などのディスクに関連する Prometheus メトリック値を含む Grafana ダッシュボードを使用して、アタッチされたストレージを監視します。
• Prometheus に格納されているデータに基づいてノードのパフォーマンスと正常性を視覚化する複数の Kubernetes ダッシュボードを使用できます。

Log Analytics

• Log Analytics ワークスペースのクエリ ダイアログで [コンテナー] カテゴリを選択して、Container Insights によって設定された ContainerImageInventory テーブルからデータを取得する イメージ インベントリ ログ クエリなどのクラスター向けの事前構築済みのログ クエリにアクセスします。

トラブルシューティング

• トラブルシューティングのシナリオでは、メンテナンスまたは即時ログ収集のためにノードに直接アクセスする必要がある場合があります。 セキュリティのため、AKS ノードはインターネットに公開されませんが、kubectl debug コマンドを使って AKS ノードに SSH 接続できます。 このプロセスの詳細については、「メンテナンスまたはトラブルシューティングのために SSH を使用して Azure Kubernetes Service (AKS) クラスター ノードに接続する」を参照してください。

コスト分析

• Kubernetes のコストを把握するためのオープンソースでベンダーニュートラルの CNCF サンドボックス プロジェクトである OpenCost を構成して、クラスター コストの分析をサポートします。 詳細なコスト計算データを Azure Storage にエクスポートします。
• OpenCost のデータを使用して、組織内のさまざまなチームによるクラスターの相対的な使用状況を内訳化し、コストをチームに割り当てることができるようにします。
• OpenCost のデータを使用して、多数の小型ノードではなく、より少ない大型ノードを使用して、ワークロードを高密度にパックすることで、クラスターがそのノードの完全な容量を使用していることを確認します。

監視レベル 3 - マネージド Kubernetes コンポーネント

マネージド Kubernetes レベルには、次のコンポーネントが含まれます。

コンポーネント	監視
API サーバー	API サーバーの状態を監視し、サービスがダウンした場合の要求負荷とボトルネックの増加を特定します。
kubelet	Kubelet を監視すると、ポッド管理の問題、ポッドが起動しない、ノードの準備ができていない、ポッドが強制終了された場合のトラブルシューティングに役立ちます。

マネージド Kubernetes コンポーネントを監視するための一般的なシナリオを次に示します。

Container insights

• [監視] で [メトリック] を選択して、[配信要求] カウンターを表示します。
• [レポート] の Kubelet ブックを使って、各 kubelet の正常性とパフォーマンスを確認します。 これらのブックの詳細については、「リソース監視のブック」を参照してください。

Grafana

• Kubelet 用 Managed Grafana の事前構築済みダッシュボードを使用して、それぞれの kubelet の正常性とパフォーマンスを確認します。
• API サーバーの完全なパフォーマンスを表示するには、Kubernetes API サーバーなどのダッシュボードを使用します。 これには、要求の待機時間や作業キューの処理時間などの値が含まれます。

Log Analytics

• リソース ログを含むログ クエリを使用して、AKS コンポーネントによって生成されたコントロール プレーン ログを分析します。

• AKS の構成アクティビティは、アクティビティ ログに記録されます。 アクティビティ ログを Log Analytics ワークスペースに送信する場合は、Log Analytics を使用して分析できます。 たとえば、次のサンプル クエリを使用することで、すべての AKS クラスターで正常にアップグレードされたことを示すレコードを返すことができます。

  AzureActivity
  | where CategoryValue == "Administrative"
  | where OperationNameValue == "MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS/WRITE"
  | extend properties=parse_json(Properties_d) 
  | where properties.message == "Upgrade Succeeded"
  | order by TimeGenerated desc
  

トラブルシューティング

• トラブルシューティングのシナリオでは、「Azure Kubernetes Service (AKS) クラスター ノードから kubelet ログを取得する」で説明されているプロセスを使用して、kubelet ログにアクセスできます。

監視レベル 4 - Kubernetes オブジェクトとワークロード

Kubernetes オブジェクトとワークロード レベルには、次のコンポーネントが含まれます。

コンポーネント	要件の監視
デプロイ	デプロイの実際の状態と望ましい状態、およびデプロイで実行されているポッドの状態とリソース使用率を監視します。
ポッド	AKS クラスターで実行されているポッドの状態と、CPU とメモリを含むリソース使用率を監視します。
Containers	AKS クラスターで実行されているコンテナーの CPU とメモリを含むリソース使用率を監視します。

Kubernetes オブジェクトとワークロードを監視するための一般的なシナリオを次に示します。

Container insights

• [ノード] ビューと [コントローラー] ビューを使って、それらで実行中のポッドの正常性とパフォーマンスを確認し、それらのコンテナーの正常性とパフォーマンスにドリルダウンします。
• [コンテナー] ビューを使って、コンテナーの正常性とパフォーマンスを確認します。 コンテナーの正常性とパフォーマンスの分析の詳細については、「Container insights を使用して Kubernetes クラスターのパフォーマンスを監視する」を参照してください。
• [レポート] の [デプロイ] ブックを使ってデプロイのメトリックを確認します。 詳細については、「Container insights によるデプロイと HPA メトリック」を参照してください。

Grafana ダッシュボード

• ノードおよびポッド 用 Managed Grafana の事前構築済みダッシュボードを使用して、正常性とパフォーマンスを表示します。
• Prometheus に格納されているデータに基づいてノードのパフォーマンスと正常性を視覚化する複数の Kubernetes ダッシュボードを使用できます。

ライブ データ

• トラブルシューティングのシナリオでは、コンテナーの分析情報はライブ AKS コンテナー ログ (stdout または stderror)、イベント、ポッド メトリックにアクセスできます。 この機能の詳細については、「Kubernetes ログ、イベント、およびポッド メトリックをリアルタイムで表示する方法」を参照してください。

プラットフォーム エンジニアに対するアラート

Azure Monitor のアラートでは、監視データの興味深いデータやパターンを事前に通知します。 これにより、ユーザーが気付く前に、管理者が問題を識別して対処できます。 アラート用の既存の ITSM ソリューション がある場合は、Azure Monitor と統合できます。 ワークスペース データをエクスポートして、Log Analytics ワークスペースから現在のアラート ソリューションをサポートする別の場所にデータを送信することもできます。

アラートの種類

次の表では、上述のサービスで収集されたデータに基づいて作成できるさまざまな種類のカスタム アラート ルールについて説明します。

アラートの種類	説明
Prometheus アラート	Prometheus 警告は、Prometheus の Azure Monitor 管理サービスに格納されている Prometheus メトリックに適用される Prometheus クエリ言語 (Prom QL) で記述されます。 推奨アラートには、最も一般的な Prometheus アラートが既に含まれており、必要に応じて追加のアラート ルールを作成できます。
メトリック アラート ルール	メトリック アラート ルールでは、メトリックス エクスプローラーと同じメトリック値が使われます。 実際には、現在分析しているデータを使って、メトリックス エクスプローラーから直接アラート ルールを作成できます。 メトリック アラート ルールは、AKS データ参照メトリックのいずれかの値を使用して AKS のパフォーマンスに関するアラートを生成するのに役立ちます。
ログ検索警告ルール	ログ検索警告ルールを使用して、ログ クエリの結果からアラートを生成します。 詳細については、コンテナーの分析情報からログ検索アラートを作成する方法とコンテナーの分析情報からログのクエリを実行する方法に関する記事を参照してください。

推奨アラート

まず、Kubernetes クラスターの最も一般的なアラート条件を含む、Container insights のメトリック アラート ルール (プレビュー) で推奨される Prometheus アラートのセットから始めます。 追加のアラート条件を特定すると、後でさらにアラート ルールを追加できます。

開発者

開発者は、アプリケーションの開発に加えて、クラスター上で実行されているアプリケーションを維持します。 また、アプリケーションのパフォーマンスや失敗などのアプリケーション固有のトラフィックを担当し、会社で定義された SLA に従ってアプリケーションの信頼性を維持します。

開発者向けの Azure サービス

次の表に、クラスターで実行されているアプリケーションの正常性とパフォーマンスを監視するために、開発者が般的に使用するサービスの一覧を示します。

サービス	説明
Application Insights	Kubernetes クラスターで実行中のアプリケーションを開発からテストを通じて運用環境まで監視する、アプリケーション パフォーマンス監視 (APM) を提供する Azure Monitor の機能。 分散トレースを使用して、待機時間と信頼性の問題をすばやく特定して軽減します。 ベンダーニュートラルなインストルメンテーションの OpenTelemetry をサポートします。

クラスターで実行中のアプリケーションからのデータ収集を構成するオプションと、特定の要件に最適なメソッドの決定基準については、「Azure Monitor Application Insights のデータ収集の基本」を参照してください。

監視レベル 5 - アプリケーション

アプリケーションを監視するための一般的なシナリオを次に示します。

アプリケーションのパフォーマンス

• アプリケーションの分析情報の [パフォーマンス] ビューを使用して、アプリケーションのさまざまな操作のパフォーマンスを表示します。
• Profiler を使用して、アプリケーションのパフォーマンス トレースをキャプチャして表示します。
• アプリケーション マップを使用して、アプリケーション コンポーネント間の依存関係を表示し、ボトルネックを特定します。
• クラウドおよびマイクロサービス アーキテクチャの呼び出し履歴のように動作するパフォーマンス プロファイラーを提供し、サービス間の相互作用をより適切に監視できるようにする分散トレースを有効にします。

アプリケーション エラー

• Application insights の [失敗] タブを使用して、失敗した要求の数と最も一般的な例外を表示します。
• スマート検出で特定された失敗の異常のアラートが正しく構成されていることを確認します。

正常性の監視

• Application insights で可用性テストを作成し、アプリケーションの可用性と応答性を監視する反復テストを作成します。
• SLA レポートを使用して、Web テストの SLA を計算してレポートします。
• 注釈を使用して、新しいビルドがデプロイされるタイミングを特定し、更新後のパフォーマンスの変化を視覚的に検査できるようにします。

アプリケーション ログ

• Container insights は、stdout/stderr ログを Log Analytics ワークスペースに送信します。 さまざまなログの説明については、リソース ログを参照し、それぞれが送信される表の一覧については、Kubernetes Services を参照してください。

サービス メッシュ

• AKS クラスターの場合は、マイクロサービス アーキテクチャを監視できる Istio ベースのサービス メッシュ アドオンをデプロイします。 Istio は、既存の分散アプリケーションに透過的にレイヤー化するオープンソース サービス メッシュです。 アドオンは、AKS 用 Istio のデプロイと管理をサポートします。

関連項目

• Azure Kubernetes Service (AKS) に固有の監視に関するガイダンスについては、「AKS の監視」を参照してください。