# Container Insights
CloudWatch Container Insights を使用して、コンテナ化されたアプリケーションとマイクロサービスのメトリクスとログを収集、集計、要約します。Container Insights は、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS)、RedHat OpenShift on AWS (ROSA)、および Amazon EC2 の Kubernetes プラットフォームで利用できます。Container Insights は、Amazon ECS と Amazon EKS の両方の AWS Fargate にデプロイされたクラスターからのメトリクスの収集をサポートしています。
CloudWatch は、CPU やメモリ、ディスク、ネットワークなど、多数のリソースのメトリクスを自動的に収集します。Container Insights では、問題の迅速な特定と解決に役立つ、コンテナの再起動失敗などの診断情報も提供されます。また、Container Insights が収集するメトリクスには CloudWatch アラームを設定できます。
Container Insights は、[埋め込みメトリクス形式](CloudWatch_Embedded_Metric_Format.md)を使用して、*パフォーマンスログイベント*としてデータを収集します。このパフォーマンスログイベントは、高濃度データを取り込み、大規模に保存することが可能な構造化された JSON スキーマを使用するエントリです。CloudWatch は、このデータから、クラスター、ノード、ポッド、タスク、サービスのレベルで CloudWatch メトリクスとして集約されたメトリクスを作成します。Container Insights が収集するメトリクスは、CloudWatch 自動ダッシュボードで使用でき、CloudWatch コンソールの **[メトリクス]** セクションでも表示できます。メトリクスは、コンテナタスクがしばらく実行されるまで表示されません。
Container Insights をデプロイする場合、パフォーマンスログイベント用のロググループが自動的に作成されます。このロググループを手動で作成する必要はありません。
Container Insights のコスト管理に役立てるため、CloudWatch によりログデータからあらゆるメトリクスが自動的に作成されるわけではありません。CloudWatch Logs Insights を使って生のパフォーマンスログイベントを分析すると、メトリクスと粒度レベルの詳細を確認できます。
Container Insights の元のバージョンでは、収集されたメトリクスおよび取り込まれたログはカスタムメトリクスとして課金されます。Amazon EKS 向けにオブザーバビリティが強化された Container Insights では、観察結果ごと Container Insights メトリクスおよびログに課金されます。保存されたメトリクスまたは取り込まれたログごとには課金されません。CloudWatch の料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」をご覧ください。
**[プレビュー]** Amazon EKS では、Container Insights with OpenTelemetry は、OpenTelemetry Protocol (OTLP) を使用してメトリクスを収集し、PromQL クエリをサポートする追加のメトリクスモードを提供します。各メトリクスは、OpenTelemetry セマンティック規則属性、Kubernetes ポッドおよびノードラベルなど、最大 150 個のラベルで強化されています。詳細については、「[Amazon EKS の OpenTelemetry メトリクスを使用した Container Insights](container-insights-otel-metrics.md)」を参照してください。
Amazon EKS、RedHatOpenshift on AWS、および Kubernetes では、Container Insights はコンテナ化されたバージョンの CloudWatch エージェントを使用して、クラスターで実行中のすべてのコンテナを検出します。次に、パフォーマンススタックの各レイヤーでパフォーマンスデータを収集します。
Container Insights は、収集するログおよびメトリクスの AWS KMS key による暗号化をサポートします。この暗号化を有効にするには、Container Insights データを受信するロググループに対して AWS KMS 暗号化を手動で有効にする必要があります。これにより、Container Insights は提供された KMS キーを使用してこのデータを暗号化するようになります。対称キーのみがサポートされます。ロググループの暗号化に非対称 KMS キーを使用しないでください。
詳細については、[AWS KMS を使用した CloudWatch Logs でのログデータの暗号化](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html)を参照してください。
## サポートされているプラットフォーム
Container Insights は、Amazon Elastic Container Service、Amazon Elastic Kubernetes Service、RedHat OpenShift on AWS、および Amazon EC2 インスタンスの Kubernetes プラットフォームで利用できます。
+ Amazon ECS の場合、Container Insights により Linux インスタンスおよび Windows Server インスタンスの両方のクラスター、タスク、およびサービスレベルでメトリクスが収集されます。Container Insights は、Linux インスタンスのみにインスタンスレベルでメトリクスを収集します。ネットワークメトリクスは、`bridge` ネットワークモードおよび `awsvpc` ネットワークモードを使用するコンテナに利用できますが、`host` ネットワークモードを使用するコンテナには使用できません。
+ Amazon Elastic Kubernetes Service と、Amazon EC2 インスタンスの Kubernetes プラットフォームでは、Container Insights は Linux インスタンスと Windows インスタンスの両方でサポートされます。
+ **[プレビュー]** Amazon EKS では OpenTelemetry メトリクスを使用した Container Insights を利用できます。詳細については、「[Amazon EKS の OpenTelemetry メトリクスを使用した Container Insights](container-insights-otel-metrics.md)」を参照してください。
# Amazon ECS 用にオブザーバビリティが強化された Container Insights
2024 年 12 月 2 日、AWS で Amazon ECS 用にオブザーバビリティが強化された Container Insights がリリースされました。このバージョンでは、Amazon EC2 および Fargate 起動タイプを使用して Amazon ECS 用に強化されたオブザーバビリティがサポートされます。Amazon ECS でオブザーバビリティが強化された Container Insights を設定したら、Container Insights はクラスターレベルから環境内のコンテナレベルまで詳細なインフラストラクチャテレメトリを自動的に収集し、これらの重要なパフォーマンスデータを厳選されたダッシュボードに表示し、オブザーバビリティ設定に伴う負担を軽減します。オブザーバビリティが強化された Container Insights を設定する方法の詳細については、「[Amazon ECS での Container Insights のセットアップ](deploy-container-insights-ECS-cluster.md)」を参照してください。
オブザーバビリティが強化された Container Insights はすべての Container Insights メトリクスに加え、追加のタスクおよびコンテナメトリクスを提供します。詳細については、「[Amazon ECS 用にオブザーバビリティメトリクスが強化された Container Insights](Container-Insights-enhanced-observability-metrics-ECS.md)」を参照してください。
オブザーバビリティが強化された Container Insights は、CloudWatch のクロスアカウントオブザーバビリティもサポートしています。単一のモニタリングアカウントを使用し、単一のリージョン内で複数の AWS アカウントにまたがるアプリケーションをモニタリングおよびトラブルシューティングできます。詳細については、「[CloudWatch のクロスアカウントオブザーバビリティ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)」を参照してください。
# Amazon EKS 向けに拡張オブザーバビリティを備えた Container Insights
2023 年 11 月 6 日、Container Insights の新しいバージョンがリリースされました。このバージョンでは、Amazon EC2 で実行されている Amazon EKS クラスター向けの強化されたオブザーバビリティがサポートされます。また、これらのクラスターから、より詳細なメトリクスを収集できます。インストール後は、Amazon EKS クラスターの詳細なインフラストラクチャテレメトリとコンテナログが自動的に収集されます。その後、キュレーションされたすぐに使用できるダッシュボードを使用して、アプリケーションおよびインフラストラクチャテレメトリを掘り下げて調べることができます。
Amazon EKS 向けにオブザーバビリティが強化された Container Insights では、コンテナレベルまでの詳細なヘルス、パフォーマンス、ステータスのメトリクスだけでなく、コントロールプレーンのメトリクスも収集できます。収集されるその他のメトリクスおよびディメンションの詳細については、「[Amazon EKS およびオブザーバビリティが強化された Kubernetes Container Insights](Container-Insights-metrics-enhanced-EKS.md)」を参照してください。
2023 年 11 月 6 日以降に Amazon EC2 上の Amazon EKS クラスターで CloudWatch エージェントを使用して Container Insights をインストールした場合、Amazon EKS 向けにオブザーバビリティが強化された Container Insights を利用できます。そうでない場合、[CloudWatch の Amazon EKS 向けにオブザーバビリティが強化された Container Insights へのアップグレード](Container-Insights-upgrade-enhanced.md) の手順に従って Amazon EKS クラスターをこの新しいバージョンにアップグレードできます。
Container Insights は、CloudWatch クロスアカウントオブザーバビリティをサポートしています。単一のモニタリングアカウントで、単一のリージョン内の複数の AWS アカウントにまたがるアプリケーションをモニタリングし、トラブルシューティングできます。詳細については、「[CloudWatch のクロスアカウントオブザーバビリティ](CloudWatch-Unified-Cross-Account.md)」を参照してください。
Amazon EKS 向けにオブザーバビリティが強化された Container Insights は、Windows ワーカーノードもサポートします。
Amazon EKS 向けにオブザーバビリティが強化された Container Insights は、Fargate ではサポートされていません。
**注記**
Amazon EKS 向けにオブザーバビリティが強化された Container Insights にアップグレードできるクラスターがあるかどうかは、Container Insights コンソールに移動して確認できます。これを行うには、CloudWatch コンソールのナビゲーションペインで **[インサイト]**、**[コンテナインサイト]** の順に選択します。Container Insights コンソールには、アップグレード可能な Amazon EKS クラスターがあるかどうかを知らせるバナーと、アップグレードページへのリンクが表示されます。
# Amazon EKS の OpenTelemetry メトリクスを使用した Container Insights
**プレビュー**
OpenTelemetry メトリクスを使用した Container Insights により、Amazon EKS クラスターインフラストラクチャの運用状態が可視化されます。米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー) では、追加料金なしでパブリックプレビューで利用できます。
Amazon CloudWatch Observability EKS アドオンは、Amazon EKS クラスターからオープンソースメトリクスを収集し、OpenTelemetry Protocol (OTLP) を使用して 30 秒の精度でそれらを CloudWatch に送信します。これらのメトリクスは、cAdvisor、Prometheus Node Exporter、NVIDIA DCGM、Kube State Metrics、AWS Neuron Monitor など、元のソースのメトリクス名を使用します。これらのメトリクスは、CloudWatch Query Studio の PromQL を使用して、または Prometheus 互換クエリ API を介してクエリできます。
各メトリクスは、OpenTelemetry セマンティック規則属性、Kubernetes ポッドおよびノードラベルなど、最大 150 個のラベルで自動的に強化されます。PromQL はクエリ時に集計を処理するので、各メトリクスは複数の集計レベルではなく、リソースごとに 1 回発行されます。アドオンは、AWS Neuron および AWS Elastic Fabric Adapter からのアクセラレーターメトリクスを、それらを使用する特定のポッドとコンテナと関連付け、メトリクスソースだけでは利用できない可視性を提供します。
Amazon EKS クラスターで OTel Container Insights を有効にするには、Amazon CloudWatch Observability EKS アドオンバージョン `v6.0.1-eksbuild.1` 以降を Amazon EKS コンソールまたは Infrastructure as Code を介してインストールします。
OTel Container Insights のセットアップの詳細については、「[Container Insights の設定](deploy-container-insights.md)」を参照してください。
PromQL を使用したこれらのメトリクスのクエリの詳細については、「[PromQL クエリ](CloudWatch-PromQL-Querying.md)」を参照してください。
## OTel Container Insights を Container Insights と比較する方法 (拡張)
次の表は、Container Insights (拡張) と OTel Container Insights の違いをまとめたものです。
| 機能 | Container Insights (拡張) | OTel Container Insights |
| --- | --- | --- |
| メトリクス名 | CloudWatch 形式のメトリクス (例: pod\$1cpu\$1utilization) | オープンソースネイティブ (例: container\$1cpu\$1usage\$1seconds\$1total) |
| メトリクスあたりのラベル | メトリクスあたり 3～6 個の定義済みディメンション | すべての Kubernetes ポッドラベルとノードラベルを含む、最大 150 個のラベル |
| 集計 | 複数のレベル (クラスター、名前空間、ワークロード、ポッド) で事前集計されている | リソースごとの raw メトリクス。PromQL を使用したクエリ時の集計 |
| クエリ言語 | CloudWatch メトリクス API | PromQL (Prometheus 互換) |
| メトリクスの取り込み | EMF 形式の CloudWatch Logs | OTLP エンドポイント |
## メトリクスをラベル付けする方法
OTel Container Insights によって収集された各メトリクスには、3 個のソースからのラベルが付けられます。
テレメトリソースのネイティブラベル
元のメトリクスソースからのラベル (例えば、cAdvisor は `pod`、`namespace`、`container` などのラベルを提供します)。これらはデータポイント属性として保持されます。
OpenTelemetry リソース属性
アドオンは、`k8s.pod.name`、`k8s.namespace.name`、`k8s.node.name`、`host.name`、`cloud.region` など、[Kubernetes](https://opentelemetry.io/docs/specs/semconv/resource/k8s/)、[ホスト](https://opentelemetry.io/docs/specs/semconv/resource/host/)、および[クラウド](https://opentelemetry.io/docs/specs/semconv/resource/cloud/)の OpenTelemetry セマンティック規則に従ってリソース属性を追加します。これらの属性は、すべてのメトリクスソース全体で一貫しています。
Kubernetes ポッドとノードのラベル
Kubernetes API から検出されたすべてのポッドラベルとノードラベルは、`k8s.pod.label` および `k8s.node.label` というプレフィックスが付いたリソース属性として追加されます。
PromQL を使用してこれらの属性をクエリする方法の詳細については、「[PromQL クエリ](CloudWatch-PromQL-Querying.md)」を参照してください。
## サポートされるメトリクス
次の表は、OTel Container Insights によって収集されたメトリクスソースとカテゴリを示します。
| メトリクスソース | メトリクスカテゴリ | 前提条件 |
| --- | --- | --- |
| cAdvisor | CPU メトリクス | - |
| cAdvisor | メモリメトリクス | - |
| cAdvisor | ネットワークメトリクス | - |
| cAdvisor | ディスクとファイルシステムのメトリクス | - |
| Prometheus Node Exporter | CPU メトリクス | - |
| Prometheus Node Exporter | メモリメトリクス | - |
| Prometheus Node Exporter | ディスクメトリクス | - |
| Prometheus Node Exporter | ファイルシステムのメトリクス | - |
| Prometheus Node Exporter | ネットワークメトリクス | - |
| Prometheus Node Exporter | システムメトリクス | - |
| Prometheus Node Exporter | VMStat メトリクス | - |
| Prometheus Node Exporter | Netstat とソケットのメトリクス | - |
| NVIDIA DCGM | GPU 使用率とパフォーマンスのメトリクス | [NVIDIA デバイスプラグイン](https://github.com/NVIDIA/k8s-device-plugin)と [NVIDIA コンテナツールキット](https://github.com/NVIDIA/nvidia-container-toolkit)をインストールする必要があります。 |
| NVIDIA DCGM | GPU メモリメトリクス | [NVIDIA デバイスプラグイン](https://github.com/NVIDIA/k8s-device-plugin)と [NVIDIA コンテナツールキット](https://github.com/NVIDIA/nvidia-container-toolkit)をインストールする必要があります。 |
| NVIDIA DCGM | GPU 電力と熱のメトリクス | [NVIDIA デバイスプラグイン](https://github.com/NVIDIA/k8s-device-plugin)と [NVIDIA コンテナツールキット](https://github.com/NVIDIA/nvidia-container-toolkit)をインストールする必要があります。 |
| NVIDIA DCGM | GPU スロットリングメトリクス | [NVIDIA デバイスプラグイン](https://github.com/NVIDIA/k8s-device-plugin)と [NVIDIA コンテナツールキット](https://github.com/NVIDIA/nvidia-container-toolkit)をインストールする必要があります。 |
| NVIDIA DCGM | GPU エラーと信頼性のメトリクス | [NVIDIA デバイスプラグイン](https://github.com/NVIDIA/k8s-device-plugin)と [NVIDIA コンテナツールキット](https://github.com/NVIDIA/nvidia-container-toolkit)をインストールする必要があります。 |
| NVIDIA DCGM | GPU NVLink メトリクス | [NVIDIA デバイスプラグイン](https://github.com/NVIDIA/k8s-device-plugin)と [NVIDIA コンテナツールキット](https://github.com/NVIDIA/nvidia-container-toolkit)をインストールする必要があります。 |
| NVIDIA DCGM | GPU 情報メトリクス | [NVIDIA デバイスプラグイン](https://github.com/NVIDIA/k8s-device-plugin)と [NVIDIA コンテナツールキット](https://github.com/NVIDIA/nvidia-container-toolkit)をインストールする必要があります。 |
| AWS Neuron モニター | NeuronCore メトリクス | [Neuron ドライバー](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/general/setup/neuron-setup/pytorch/neuronx/ubuntu/torch-neuronx-ubuntu22.html)と [Neuron デバイスプラグイン](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/containers/kubernetes-getting-started.html)をインストールする必要があります。 |
| AWS Neuron モニター | NeuronDevice メトリクス | [Neuron ドライバー](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/general/setup/neuron-setup/pytorch/neuronx/ubuntu/torch-neuronx-ubuntu22.html)と [Neuron デバイスプラグイン](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/containers/kubernetes-getting-started.html)をインストールする必要があります。 |
| AWS Neuron モニター | Neuron システムメトリクス | [Neuron ドライバー](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/general/setup/neuron-setup/pytorch/neuronx/ubuntu/torch-neuronx-ubuntu22.html)と [Neuron デバイスプラグイン](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/containers/kubernetes-getting-started.html)をインストールする必要があります。 |
| AWS Elastic Fabric Adapter | EFA メトリクス | [EFA デバイスプラグイン](https://github.com/aws/eks-charts/tree/master/stable/aws-efa-k8s-device-plugin)をインストールする必要があります。 |
| NVMe | NVMe SMART メトリクス | - |
| Kube State メトリクス | Pod、ノード、デプロイ、DaemonSet、StatefulSet、ReplicaSet、Job、CronJob、Service、名前空間、PersistentVolume、PersistentVolumeClaim メトリクス | - |
| Kubernetes API サーバー | API サーバーと etcd メトリクス | - |
## CloudWatch エージェントコンテナイメージ
Amazon は、Amazon Elastic Container Registry に CloudWatch エージェントコンテナイメージを提供しています。詳細については、Amazon ECR の 「[cloudwatch-agent](https://gallery.ecr.aws/cloudwatch-agent/cloudwatch-agent)」を参照してください。
# Container Insights の設定
Container Insights のセットアッププロセスは Amazon ECS と Amazon EKS および Kubernetes では異なります。
+ [Amazon EKS と Kubernetes での Container Insights のセットアップ](deploy-container-insights-EKS.md)
+ [Amazon ECS での Container Insights のセットアップ](deploy-container-insights-ECS.md)
**Topics**
+ [Amazon ECS での Container Insights のセットアップ](deploy-container-insights-ECS.md)
+ [Amazon EKS と Kubernetes での Container Insights のセットアップ](deploy-container-insights-EKS.md)
+ [RedHat OpenShift on AWS (ROSA) での Container Insights の設定](deploy-container-insights-RedHatOpenShift.md)
# Amazon ECS での Container Insights のセットアップ
次のオプションのいずれかまたは両方を使用して、Amazon ECS クラスターで Container Insights を有効にできます。
+ クラスターレベル、タスクレベル、およびサービスレベルのメトリクスの収集を開始するには、AWS マネジメントコンソール または AWS CLI を使用します。
+ CloudWatch エージェントをデーモンサービスとしてデプロイし、インスタンスでホストされているクラスターで Amazon EC2 インスタンスレベルのメトリクスの収集を開始します。
**Topics**
+ [Amazon ECS での Container Insights のセットアップ](deploy-container-insights-ECS-cluster.md)
+ [AWS Distro for OpenTelemetry を使用した Amazon ECS での Container Insights の設定](deploy-container-insights-ECS-adot.md)
+ [Amazon ECS で EC2 インスタンスレベルのメトリクスを収集するための CloudWatch エージェントのデプロイ](deploy-container-insights-ECS-instancelevel.md)
+ [Amazon ECS クラスター上で EC2 インスタンスレベルのメトリクスを収集するための AWS Distro for OpenTelemetry のデプロイ](deploy-container-insights-ECS-OTEL.md)
+ [FireLens のログ送信先を CloudWatch Logs に設定する](deploy-container-insights-ECS-logs.md)
# Amazon ECS での Container Insights のセットアップ
Amazon ECS コンソールまたは AWS CLI のいずれかを使用し、新規および既存の Amazon ECS クラスターでオブザーバビリティが強化された Container Insights または Container Insights を設定できます。Container Insights は、クラスター、タスク、およびサービスレベルでメトリクスを収集します。オブザーバビリティが強化された Container Insights は追加のディメンションおよびメトリクスを提供し、コンテナレベルの可視性まで深く掘り下げることができます。
Amazon EC2 インスタンスで Amazon ECS を使用している場合、Amazon ECS エージェントバージョン 1.29 以降を含む AMI を使用してそのインスタンスを起動します。エージェントのバージョンを更新する方法の詳細については、「[Amazon ECS コンテナエージェントの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-update.html)」を参照してください。
**注記**
Amazon ECS Container Insights メトリクスに使用するカスタマーマネージド AWS KMS キーがまだ CloudWatch と連携するように設定されていない場合、CloudWatch Logs で暗号化されたログを許可するためにキーポリシーを更新する必要があります。独自の AWS KMS キーを `/aws/ecs/containerinsights/ClusterName/performance` のロググループに関連付ける必要があります。詳細については、「[Encrypt log data in CloudWatch Logs using AWS Key Management Service](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html)」を参照してください。
コンテナ環境で詳細な可視性を提供し、解決までの平均時間を短縮するため、Container Insights ではなく、オブザーバビリティが強化された Container Insights を使用することをお勧めします。
## オブザーバビリティが強化された Container Insights の設定
Amazon ECS コンソールまたは AWS CLI を使用し、オブザーバビリティが強化された Container Insights を有効にできます。
------
#### [ AWS CLI ]
次のコマンドを使用し、オブザーバビリティが強化された Container Insights を有効にします。
`containerInsights` アカウント設定を `enhanced` に設定
```
aws ecs put-account-setting --name containerInsights --value enhanced
```
出力の例
```
{
"setting": {
"name": "containerInsights",
"value": "enhanced",
"principalArn": "arn:aws:iam::123456789012:johndoe",
"type": user
}
}
```
**注記**
デフォルトでは、`put-account-setting` は、現在認証されているユーザーにのみ適用されます。すべてのユーザーとロールに対してアカウント全体の設定を有効にするには、次の例のようにルートユーザーを使用します。
```
aws ecs put-account-setting --name containerInsights --value enhanced --principal-arn arn:aws:iam::accountID:root
```
このアカウント設定を行ったら、すべての新しいクラスターはオブザーバビリティが強化された Container Insights を自動的に使用します。`update-cluster-settings` コマンドを使用してオブザーバビリティが強化された Container Insights を既存のクラスターに追加するか、現在 Container Insights を使用しているクラスターをオブザーバビリティが強化された Container Insights にアップグレードします。
```
aws ecs update-cluster-settings --cluster cluster-name --settings name=containerInsights,value=enhanced
```
------
#### [ Amazon ECS console ]
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. 上部にあるナビゲーションバーで、アカウント設定を表示するリージョンを選択します。
1. ナビゲーションペインで **[Account Settings]** (アカウント設定) を選択します。
1. **[更新]** を選択します。
1. オブザーバビリティが強化された Container Insights を使用するには、**[オブザーバビリティが強化された Container Insights]** を選択します。
1. **[Save changes]** (変更の保存) をクリックします。
1. 確認画面で [**Confirm (確認)**] を選択すると、選択内容が保存されます。
これを設定したら、すべての新しいクラスターはオブザーバビリティが強化された Container Insights を自動的に使用します。オブザーバビリティが強化された Container Insights を既存のクラスターに追加したり、現在 Container Insights を使用しているクラスターをオブザーバビリティが強化された Container Insights に更新したりすることができます。詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[Amazon ECS クラスターの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-cluster-v2.html)」を参照してください。
------
## Container Insights の設定
Amazon ECS コンソールまたは AWS CLI を使用して Container Insights を有効にできます。
------
#### [ AWS CLI ]
Container Insights を使用するには、`container Insights` アカウント設定を `enabled` に設定します。次のコマンドを使用して Container Insights を有効にします。
```
aws ecs put-account-setting --name containerInsights --value enabled
```
出力の例
```
{
"setting": {
"name": "container Insights",
"value": "enabled",
"principalArn": "arn:aws:iam::123456789012:johndoe",
"type": user
}
}
```
`container Insights` アカウント設定を `enabled` に設定すると、すべての新しいクラスターはデフォルトで Container Insights が有効になります。`update-cluster-settings` コマンドを使用して Container Insights を既存のクラスターに追加します。
```
aws ecs update-cluster-settings --cluster cluster-name --settings name=containerInsights,value=enabled
```
------
#### [ Amazon ECS console ]
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. 上部にあるナビゲーションバーで、アカウント設定を表示するリージョンを選択します。
1. ナビゲーションペインで **[Account Settings]** (アカウント設定) を選択します。
1. **[更新]** を選択します。
1. Container Insights を使用するには、**[Container Insights]** を選択します。
1. **[Save changes]** (変更の保存) をクリックします。
1. 確認画面で [**Confirm (確認)**] を選択すると、選択内容が保存されます。
これを設定したら、すべての新しいクラスターは自動的に Container Insights を使用します。既存のクラスターを更新して Container Insights を追加します。詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[Amazon ECS クラスターの更新](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-cluster-v2.html)」を参照してください。
------
# AWS Distro for OpenTelemetry を使用した Amazon ECS での Container Insights の設定
このセクションは、AWS Distro for OpenTelemetry を使用して Amazon ECS クラスターで CloudWatch Container Insights を設定する場合に使用します。AWS Distro for Open Telemetry の詳細については、[AWS Distro for OpenTelemetry](https://aws.amazon.com/otel/) を参照してください。
以下の手順では、クラスターが Amazon ECS を実行するように既に設定されていることを前提としています。Amazon ECS で AWS Distro for Open Telemetry を使用し、この目的のために Amazon ECS クラスターを設定する方法の詳細については、[Amazon Elastic Container Service で AWS Distro for OpenTelemetry Collector を設定する](https://aws-otel.github.io/docs/setup/ecs)を参照してください。
## ステップ 1: タスクロールを作成する
最初のステップでは、AWS OpenTelemetry Collector が使用するクラスター内にタスクロールを作成します。
**AWS Distro for OpenTelemetry のタスクロールを作成するには**
1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。
1. ナビゲーションペインで、[**Policies (ポリシー)**] を選択し、[**Create Policy (ポリシーの作成)**] を選択します。
1. [**JSON**] タブを選択し、以下のポリシーをコピーします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:PutLogEvents",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:DescribeLogStreams",
"logs:DescribeLogGroups",
"ssm:GetParameters"
],
"Resource": "*"
}
]
}
```
------
1. **[ポリシーの確認]** を選択します。
1. 名前に **AWSDistroOpenTelemetryPolicy** と入力し、[**Create policy**] (ポリシーの作成) を選択します。
1. 左側のナビゲーションペインから、[**Roles**] (ロール) を選択してから、[**Create role**] (ロールの作成) をクリックします。
1. サービスのリストで、[**Elastic Container Service**] を選択します。
1. ページの下部にある [**Elastic Container Service Task**] を選択し、[**Next: Permissions**] (次へ: アクセス許可) を選択します。
1. ポリシーのリストで **AWSDistroOpenTelemetryPolicy** を検索します。
1. **AWSDistroOpenTelemetryPolicy** の横にあるチェックボックスをオンにします。
1. [**Next: Tags**] (次へ: タグ)、[**Next: Review**] (次へ: 確認) の順に選択します。
1. [**Role name**] (ロール名) に **AWSOpenTelemetryTaskRole** と入力し、[**Create role**] (ロールの作成) を選択します。
## ステップ 2: タスク実行ロールを作成する
次のステップでは、AWS OpenTelemetry Collector のタスク実行ロールを作成します。
**AWS Distro for OpenTelemetry のタスク実行ロールを作成するには**
1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。
1. 左側のナビゲーションペインから、[**Roles**] (ロール) を選択してから、[**Create role**] (ロールの作成) をクリックします。
1. サービスのリストで、[**Elastic Container Service**] を選択します。
1. ページの下部にある [**Elastic Container Service Task**] を選択し、[**Next: Permissions**] (次へ: アクセス許可) を選択します。
1. ポリシーのリストで **AmazonECSTaskExecutionRolePolicy** を検索し、**AmazonECSTaskExecutionRolePolicy** の横にあるチェックボックスをオンにします。
1. ポリシーのリストで **CloudWatchLogsFullAccess** を検索し、**CloudWatchLogsFullAccess** の横にあるチェックボックスをオンにします。
1. ポリシーのリストで **AmazonSSMReadOnlyAccess** を検索し、**AmazonSSMReadOnlyAccess** の横にあるチェックボックスをオンにします。
1. [**Next: Tags**] (次へ: タグ)、[**Next: Review**] (次へ: 確認) の順に選択します。
1. [**Role name**] (ロール名) に **AWSOpenTelemetryTaskExecutionRole** と入力し、[**Create role**] (ロールの作成) を選択します。
## ステップ 3: タスク定義を作成する
次のステップでは、タスク定義を作成します。
**AWS Distro for OpenTelemetry のタスク定義を作成するには**
1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。
1. ナビゲーションペインで、**[Task definitions]** (タスク定義) を選択します。
1. **[Create new task definition]** (新しいタスク定義の作成)、**[Create new task definition]** (新しいタスク定義の作成) の順に選択します。
1. **[Task definition family]** (タスク定義ファミリー) を使用する場合、タスク定義ファミリーには、タスク定義に一意の名前を指定します。
1. コンテナを設定し、**[次へ]** を選択します。
1. **[メトリクスとログ記録]** で、**[メトリクス収集の使用]** を選択します。
1. [**次へ**] を選択します。
1. **[作成]** を選択します。
AWS OpenTelemetry Collector を Amazon ECS で使用する方法の詳細については、[Amazon Elastic Container Service での AWS Distro for OpenTelemetry Collector の設定](https://aws-otel.github.io/docs/setup/ecs)を参照してください。
## ステップ 4: タスクを実行する
最後のステップでは、作成したタスクを実行します。
**AWS Distro for OpenTelemetry のタスクを実行するには**
1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。
1. 左のナビゲーションペインで、[**Task Definitions**] (タスク定義) を選択し、作成したタスクを選択します。
1. **[アクション]**、**[デプロイ]**、**[タスクの実行]** を選択します。
1. **[Deploy]** (デプロイ)、**[Run task]** (タスク実行) の順に選択します。
1. **[コンピューティングオプション]** セクションの **[既存のクラスター]** から、クラスターを選択します。
1. **[作成]** を選択します。
1. 次に、CloudWatch コンソールで新しいメトリクスを確認できます。
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. 左のナビゲーションペインで **[Metrics]** (メトリクス) を選択します。
**ECS/ContainerInsights** 名前空間が表示されます。その名前空間を選択すると、8 つのメトリクスが表示されます。
# Amazon ECS で EC2 インスタンスレベルのメトリクスを収集するための CloudWatch エージェントのデプロイ
EC2 インスタンスでホストされている Amazon ECS クラスターからインスタンスレベルのメトリクスを収集するために CloudWatch エージェントをデプロイするには、デフォルト設定でクイックスタート設定を使用するか、エージェントを手動でインストールしてカスタマイズできるようにします。
どちらの方法でも、EC2 起動タイプでデプロイされた Amazon EC2 クラスターが既に少なくとも 1 つあることと、CloudWatch エージェントコンテナが Amazon EC2 インスタンスメタデータサービス (IMDS) にアクセスできることが必要になります。IMDS の詳細については、「[インスタンスメタデータとユーザーデータ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)」を参照してください。
また、これらの方法では、AWS CLI がインストールされていることを前提としています。また、次の手順でコマンドを実行するには、[**IAMFullAccess**] ポリシーと [**AmazonECS\$1FullAccess**] ポリシーを持つアカウントまたはロールにログオンする必要があります。
**重要**
タスク定義で CloudWatch エージェントコンテナを定義するときは、`essential: false` を設定します。これにより、CloudWatch エージェントコンテナに障害が発生した場合に Amazon ECS サービス全体が停止するのを防ぐことができます。エージェントが一時的に使用できない場合でも、他の重要なアプリケーションコンテナは引き続き実行されます。
**Topics**
+ [CloudFormation を使用した高速セットアップ](#deploy-container-insights-ECS-instancelevel-quickstart)
+ [手動およびカスタムセットアップ](#deploy-container-insights-ECS-instancelevel-manual)
## CloudFormation を使用した高速セットアップ
高速セットアップを使用するには、次のコマンドを入力して、エージェントをインストールする CloudFormation を使用します。*cluster-name* と *cluster-regions* を Amazon ECS クラスターの名前とリージョンに置き換えます。
このコマンドは、IAM ロールの [**CWAgentECSTaskRole**] と [**CWAgentECSExecutionRole**] を作成します。これらのロールがアカウントにすでに存在する場合は、コマンドを入力ときに、`ParameterKey=CreateIAMRoles,ParameterValue=False` ではなく、`ParameterKey=CreateIAMRoles,ParameterValue=True` を使用します。そうしないと、コマンドは失敗します。
```
ClusterName=cluster-name
Region=cluster-region
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/daemon-service/cwagent-ecs-instance-metric/cloudformation-quickstart/cwagent-ecs-instance-metric-cfn.json
aws cloudformation create-stack --stack-name CWAgentECS-${ClusterName}-${Region} \
--template-body file://cwagent-ecs-instance-metric-cfn.json \
--parameters ParameterKey=ClusterName,ParameterValue=${ClusterName} \
ParameterKey=CreateIAMRoles,ParameterValue=True \
--capabilities CAPABILITY_NAMED_IAM \
--region ${Region}
```
**(代替) 独自の IAM ロールの使用**
[**CWAgentECSTaskRole**] および [**CWAgentECSExecutionRole**] ロールの代わりに、独自のカスタム ECS タスクロールと ECS タスク実行ロールを使用する場合は、最初に ECS タスクロールとして使用するロールに アタッチされている [**CloudWatchAgentServerPolicy**] が含まれていることを確認します。また、ECS タスク実行ロールとして使用するロールに、[**CloudWatchAgentServerPolicy**] ポリシー と [**AmazonECSTaskExecutionRolePolicy**] ポリシーの 両方がアタッチされていることを確認してください。次に、以下のコマンドを入力します。コマンドで、*task-role-arn* をカスタム ECS タスクロールの ARN に置き換え、*execution-role-arn* をカスタム ECS タスク実行ロールの ARN に置き換えます。
```
ClusterName=cluster-name
Region=cluster-region
TaskRoleArn=task-role-arn
ExecutionRoleArn=execution-role-arn
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/daemon-service/cwagent-ecs-instance-metric/cloudformation-quickstart/cwagent-ecs-instance-metric-cfn.json
aws cloudformation create-stack --stack-name CWAgentECS-${ClusterName}-${Region} \
--template-body file://cwagent-ecs-instance-metric-cfn.json \
--parameters ParameterKey=ClusterName,ParameterValue=${ClusterName} \
ParameterKey=TaskRoleArn,ParameterValue=${TaskRoleArn} \
ParameterKey=ExecutionRoleArn,ParameterValue=${ExecutionRoleArn} \
--capabilities CAPABILITY_NAMED_IAM \
--region ${Region}
```
**高速セットアップのトラブルシューティング**
CloudFormation スタックのステータスを確認するには、次のコマンドを入力します。
```
ClusterName=cluster-name
Region=cluster-region
aws cloudformation describe-stacks --stack-name CWAgentECS-$ClusterName-$Region --region $Region
```
`StackStatus` が `CREATE_COMPLETE`または `CREATE_IN_PROGRESS` 以外の場合、スタックイベントをチェックしてエラーを検出します。以下のコマンドを入力します。
```
ClusterName=cluster-name
Region=cluster-region
aws cloudformation describe-stack-events --stack-name CWAgentECS-$ClusterName-$Region --region $Region
```
`cwagent` デーモンサービスの状態を確認するには、次のコマンドを入力します。出力では、`runningCount` セクション の`desiredCount` が `deployment` と等しいことがわかります。等しくない場合は、出力の `failures` セクションを確認してください。
```
ClusterName=cluster-name
Region=cluster-region
aws ecs describe-services --services cwagent-daemon-service --cluster $ClusterName --region $Region
```
CloudWatch Logs コンソールを使用してエージェントログを確認することもできます。[**/ecs/ecs-cwagent-daemon-service**] ロググループを探します。
**CloudWatch エージェントの CloudFormation スタックの削除**
CloudFormation スタックを削除する必要がある場合は、次のコマンドを入力します。
```
ClusterName=cluster-name
Region=cluster-region
aws cloudformation delete-stack --stack-name CWAgentECS-${ClusterName}-${Region} --region ${Region}
```
## 手動およびカスタムセットアップ
このセクションのステップに従って、CloudWatch エージェントを手動でデプロイして、EC2 インスタンスでホストされている Amazon ECS クラスターからインスタンスレベルのメトリクスを収集します。
### 必要な IAM ロールとポリシー
2 つの IAM ロールが必要です。まだ存在しない場合は、作成する必要があります。これらのロールの詳細については、「[タスク用の IAM ロール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html)」および「[Amazon ECS タスク実行ロール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html)」を参照してください。
+ メトリクスを公開するために CloudWatch エージェントによって使用される、*ECS タスクロール*。このロールがすでに存在する場合は、`CloudWatchAgentServerPolicy` ポリシーがアタッチされていることを確認する必要があります。
+ CloudWatch エージェントを起動するために Amazon ECS エージェントが使用する、*EC2 タスク実行ロール*。このロールがすでに存在する場合は、`AmazonECSTaskExecutionRolePolicy` ポリシー `CloudWatchAgentServerPolicy` とポリシーがアタッチされていることを確認する必要があります。
これらのロールがまだない場合は、次のコマンドを使用してロールを作成し、必要なポリシーをアタッチできます。この最初のコマンドは、ECS タスクロールを作成します。
```
aws iam create-role --role-name CWAgentECSTaskRole \
--assume-role-policy-document "{\"Version\": \"2012-10-17\", \"Statement\": [{\"Sid\": \"\",\"Effect\": \"Allow\",\"Principal\": {\"Service\": \"ecs-tasks.amazonaws.com\"},\"Action\": \"sts:AssumeRole\"}]}"
```
前のコマンドを入力したら、コマンド出力の `Arn` の値を「TaskRoleArn」と書き留めます。このタスクは、後でタスク定義を作成するときに使用する必要があります。次に、以下のコマンドを入力して、必要なポリシーをアタッチします。
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
--role-name CWAgentECSTaskRole
```
次のコマンドは、ECS タスク実行ロールを作成します。
```
aws iam create-role --role-name CWAgentECSExecutionRole \
--assume-role-policy-document "{\"Version\": \"2012-10-17\", \"Statement\": [{\"Sid\": \"\",\"Effect\": \"Allow\",\"Principal\": {\"Service\": \"ecs-tasks.amazonaws.com\"},\"Action\": \"sts:AssumeRole\"}]}"
```
前のコマンドを入力したら、コマンド出力の `Arn` の値を「ExecutionRoleArn」と書き留めます。このタスクは、後でタスク定義を作成するときに使用する必要があります。次に、以下のコマンドを入力して、必要なポリシーをアタッチします。
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
--role-name CWAgentECSExecutionRole
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy \
--role-name CWAgentECSExecutionRole
```
### タスク定義を作成し、デーモンサービスを起動する
タスク定義を作成し、それを使用して CloudWatch エージェントをデーモンサービスとして起動します。タスク定義を作成するには、次のコマンドを入力します。最初の行で、プレースホルダーをデプロイの実際の値に置き換えます。*logs-region* は、CloudWatch Logs が 配置されているリージョンで、*cluster-region* はクラスターが配置されているリージョンです。*task-role-arn* は、使用している ECS タスクロールの ARN で、*execution-role-arn* は ECS タスク実行ロールの ARN です。
```
TaskRoleArn=task-role-arn
ExecutionRoleArn=execution-role-arn
AWSLogsRegion=logs-region
Region=cluster-region
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/daemon-service/cwagent-ecs-instance-metric/cwagent-ecs-instance-metric.json \
| sed "s|{{task-role-arn}}|${TaskRoleArn}|;s|{{execution-role-arn}}|${ExecutionRoleArn}|;s|{{awslogs-region}}|${AWSLogsRegion}|" \
| xargs -0 aws ecs register-task-definition --region ${Region} --cli-input-json
```
次に、以下のコマンドを実行してデーモンサービスを起動します。*cluster-name* と *cluster-regions* を Amazon ECS クラスターの名前とリージョンに置き換えます。
**重要**
このコマンドを実行する前に、すべてのキャパシティプロバイダー戦略を削除します。削除しない場合、コマンドは機能しません。
```
ClusterName=cluster-name
Region=cluster-region
aws ecs create-service \
--cluster ${ClusterName} \
--service-name cwagent-daemon-service \
--task-definition ecs-cwagent-daemon-service \
--scheduling-strategy DAEMON \
--region ${Region}
```
次のエラーメッセージ、`An error occurred (InvalidParameterException) when calling the CreateService operation: Creation of service was not idempotent` が表示された場合は、`cwagent-daemon-service` という名前のデーモンサービスは既に作成されています。まず、次のコマンドを例として使用して、そのサービスを削除する必要があります。
```
ClusterName=cluster-name
Region=cluster-region
aws ecs delete-service \
--cluster ${ClusterName} \
--service cwagent-daemon-service \
--region ${Region} \
--force
```
### (オプション) 詳細設定
オプションで、SSM を使用して、EC2 インスタンスでホストされている Amazon ECS クラスター内の CloudWatch エージェントの他の設定オプションを指定できます。オプションは以下のとおりです。
+ `metrics_collection_interval` – CloudWatch エージェントがメトリクスを収集する頻度 (秒) 。デフォルトは 60 です。範囲は 1～172,000 です。
+ `endpoint_override` – (オプション) ログの送信先となる別のエンドポイントを指定します。VPC のクラスターからデータを発行し、ログデータの送信先を VPC エンドポイントとする場合は、この操作を行うことをお勧めします。
`endpoint_override` の値は URL 文字列であることが必要です。
+ `force_flush_interval` – ログがサーバーに送信されるまでにメモリバッファ内に残留する最大時間を秒単位で指定します。このフィールドの設定にかかわらず、バッファ内のログのサイズが 1 MB に達すると、ログは即座にサーバーに送信されます。デフォルト値は 5 秒です。
+ `region` – デフォルトでは、エージェントは Amazon ECS コンテナインスタンスがあるのと同じリージョンにメトリクスを発行します。これを上書きするには、ここで別のリージョンを指定します。例: `"region" : "us-east-1"`
次に、カスタマイズした設定の例を示します。
```
{
"agent": {
"region": "us-east-1"
},
"logs": {
"metrics_collected": {
"ecs": {
"metrics_collection_interval": 30
}
},
"force_flush_interval": 5
}
}
```
**Amazon ECS コンテナで CloudWatch エージェントの設定をカスタマイズするには**
1. [**AmazonSSMReadOnlyAccess**] ポリシーが Amazon ECS タスク実行ロールにアタッチされていることを確認します。これを行うには、次のコマンドを入力します。この例では、Amazon ECS タスク実行ロールが CWAgentECSExecutionRole であることを前提としています。別のロールを使用している場合は、次のコマンドでそのロール名を置き換えます。
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonSSMReadOnlyAccess \
--role-name CWAgentECSExecutionRole
```
1. 前の例と同様のカスタマイズした設定ファイルを作成します。このファイル `/tmp/ecs-cwagent-daemon-config.json` の名前を変更します。
1. 次のコマンドを実行して、この設定を Parameter Store に配置します。*cluster-region* をお使いの Amazon ECS クラスターのリージョンに置き換えます。このコマンドを実行するには、**AmazonSSMFullAccess** ポリシーを持つユーザーまたはロールにログオンする必要があります。
```
Region=cluster-region
aws ssm put-parameter \
--name "ecs-cwagent-daemon-service" \
--type "String" \
--value "`cat /tmp/ecs-cwagent-daemon-config.json`" \
--region $Region
```
1. `/tmp/cwagent-ecs-instance-metric.json` などのタスク定義ファイルをローカルファイルにダウインロードします
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/daemon-service/cwagent-ecs-instance-metric/cwagent-ecs-instance-metric.json -o /tmp/cwagent-ecs-instance-metric.json
```
1. タスク定義ファイルを変更します。次のセクションを削除します。
```
"environment": [
{
"name": "USE_DEFAULT_CONFIG",
"value": "True"
}
],
```
そのセクションを次のように置き換えます。
```
"secrets": [
{
"name": "CW_CONFIG_CONTENT",
"valueFrom": "ecs-cwagent-daemon-service"
}
],
```
1. 次のステップに従って、エージェントをデーモンサービスとして再起動します。
1. 次のコマンドを実行します。
```
TaskRoleArn=task-role-arn
ExecutionRoleArn=execution-role-arn
AWSLogsRegion=logs-region
Region=cluster-region
cat /tmp/cwagent-ecs-instance-metric.json \
| sed "s|{{task-role-arn}}|${TaskRoleArn}|;s|{{execution-role-arn}}|${ExecutionRoleArn}|;s|{{awslogs-region}}|${AWSLogsRegion}|" \
| xargs -0 aws ecs register-task-definition --region ${Region} --cli-input-json
```
1. 次のコマンドを実行して、デーモンサービスを起動します。*cluster-name* と *cluster-regions* を Amazon ECS クラスターの名前とリージョンに置き換えます。
```
ClusterName=cluster-name
Region=cluster-region
aws ecs create-service \
--cluster ${ClusterName} \
--service-name cwagent-daemon-service \
--task-definition ecs-cwagent-daemon-service \
--scheduling-strategy DAEMON \
--region ${Region}
```
次のエラーメッセージ、`An error occurred (InvalidParameterException) when calling the CreateService operation: Creation of service was not idempotent` が表示された場合は、`cwagent-daemon-service` という名前のデーモンサービスは既に作成されています。まず、次のコマンドを例として使用して、そのサービスを削除する必要があります。
```
ClusterName=cluster-name
Region=Region
aws ecs delete-service \
--cluster ${ClusterName} \
--service cwagent-daemon-service \
--region ${Region} \
--force
```
# Amazon ECS クラスター上で EC2 インスタンスレベルのメトリクスを収集するための AWS Distro for OpenTelemetry のデプロイ
このセクションの手順を使用して、AWS Distro for OpenTelemetry を使用して Amazon ECS クラスターで EC2 インスタンスレベルのメトリクスを収集します。AWS Distro for OpenTelemetry の詳細については、[AWS Distro for OpenTelemetry](https://aws.amazon.com/otel/) を参照してください。
以下の手順では、クラスターが Amazon ECS を実行するように既に設定されていることを前提としています。このクラスターは、EC2 起動タイプを使用してデプロイする必要があります。Amazon ECS で AWS Distro for Open Telemetry を使用し、この目的のために Amazon ECS クラスターを設定する方法の詳細については、「[Amazon Elastic Container Service で ECS EC2 インスタンスレベルのメトリクスのための AWS Distro for OpenTelemetry Collector を設定する](https://aws-otel.github.io/docs/setup/ecs#3-setup-the-aws-otel-collector-for-ecs-ec2-instance-metrics)」を参照してください。
**Topics**
+ [CloudFormation を使用した高速セットアップ](#container-insights-ECS-OTEL-quicksetup)
+ [手動およびカスタムセットアップ](#container-insights-ECS-OTEL-custom)
## CloudFormation を使用した高速セットアップ
Amazon ECS 向けの AWS Distro for OpenTelemetry コレクターを EC2 にインストールするための CloudFormation テンプレートファイルをダウンロードします。次の curl コマンドを実行します。
```
curl -O https://raw.githubusercontent.com/aws-observability/aws-otel-collector/main/deployment-template/ecs/aws-otel-ec2-instance-metrics-daemon-deployment-cfn.yaml
```
テンプレートファイルをダウンロードしたら、ファイルを開き、*PATH\$1TO\$1CloudFormation\$1TEMPLATE* をテンプレートファイルを保存したパスに置き換えます。そして、次のコマンドのように、以下のパラメータをエクスポートして、CloudFormation コマンドを実行します。
+ **Cluster\$1Name** — Amazon ECS のクラスター名
+ **AWS\$1REGION** — データが送信されるリージョン
+ **PATH\$1TO\$1CloudFormation\$1TEMPLATE** — CloudFormation テンプレートファイルを保存したパス
+ **command** — AWS Distro for Open Telemetry コレクターが Amazon EC2 上で Amazon ECS のインスタンスレベルのメトリクスを収集できるようにするには、このパラメータの `--config=/etc/ecs/otel-instance-metrics-config.yaml` を指定する必要があります。
```
ClusterName=Cluster_Name
Region=AWS_Region
command=--config=/etc/ecs/otel-instance-metrics-config.yaml
aws cloudformation create-stack --stack-name AOCECS-${ClusterName}-${Region} \
--template-body file://PATH_TO_CloudFormation_TEMPLATE \
--parameters ParameterKey=ClusterName,ParameterValue=${ClusterName} \
ParameterKey=CreateIAMRoles,ParameterValue=True \
ParameterKey=command,ParameterValue=${command} \
--capabilities CAPABILITY_NAMED_IAM \
--region ${Region}
```
このコマンドを実行したら、Amazon ECS コンソールを使用して、タスクが実行されているかどうかを確認します。
### 高速セットアップのトラブルシューティング
CloudFormation スタックのステータスを確認するには、次のコマンドを入力します。
```
ClusterName=cluster-name
Region=cluster-region
aws cloudformation describe-stack --stack-name AOCECS-$ClusterName-$Region --region $Region
```
`StackStatus` が `CREATE_COMPLETE` または `CREATE_IN_PROGRESS` 以外の場合、スタックイベントをチェックしてエラーを検出します。次のコマンドを入力します。
```
ClusterName=cluster-name
Region=cluster-region
aws cloudformation describe-stack-events --stack-name AOCECS-$ClusterName-$Region --region $Region
```
`AOCECS` デーモンサービスの状態を確認するには、次のコマンドを入力します。出力では、デプロイセクションの `runningCount` が `desiredCount` と等しいことがわかります。等しくない場合は、出力の「エラー」セクションを確認してください。
```
ClusterName=cluster-name
Region=cluster-region
aws ecs describe-services --services AOCECS-daemon-service --cluster $ClusterName --region $Region
```
CloudWatch Logs コンソールを使用してエージェントログを確認することもできます。**/aws/ecs/containerinsights/\$1ClusterName\$1/performance** のロググループを探します。
## 手動およびカスタムセットアップ
このセクションの手順に従って、Amazon EC2 インスタンスでホストされている Amazon ECS クラスターからインスタンスレベルのメトリクスを収集するための AWS Distro for OpenTelemetry を手動でデプロイします。
### ステップ 1: 必要なロールとポリシー
2 つの IAM ロールが必要です。まだ存在しない場合は、作成する必要があります。これらのロールの詳細については、「[IAM ポリシーの作成](https://aws-otel.github.io/docs/setup/ecs/create-iam-policy)」および「[IAM ロールの作成](https://aws-otel.github.io/docs/setup/ecs/create-iam-role)」を参照してください。
### ステップ 2: タスク定義を作成する
タスク定義を作成し、それを使用して AWS Distro for OpenTelemetry をデーモンサービスとして起動します。
タスク定義テンプレートを使用してタスク定義を作成するには、「[AWS OTel Collector を使用して EC2 インスタンスの ECS EC2 タスク定義を作成する](https://aws-otel.github.io/docs/setup/ecs/task-definition-for-ecs-ec2-instance)」の手順に従います。
Amazon ECS コンソールを使用してタスク定義を作成するには、「[Amazon ECS の EC2 インスタンスメトリクス用に、AWS コンソールでタスク定義を作成して AWS OTel Collector をインストールする](https://aws-otel.github.io/docs/setup/ecs/create-task-definition-instance-console)」の手順に従います。
### ステップ 3: デーモンサービスを起動する
AWS Distro for OpenTelemetry をデーモンサービスとして起動するには、「[デーモンサービスを使用して Amazon Elastic Container Service (Amazon ECS) でタスクを実行する](https://aws-otel.github.io/docs/setup/ecs/run-daemon-service)」の手順に従います。
### (オプション) 詳細設定
オプションで、SSM を使用して、Amazon EC2 インスタンスでホストされている Amazon ECS クラスター内の AWS Distro for OpenTelemetry の他の設定オプションを指定できます。設定ファイルの作成についての詳細は、「[OpenTelemetry のカスタム設定](https://aws-otel.github.io/docs/setup/ecs#5-custom-opentelemetry-configuration)」を参照してください。設定ファイルで使用できるオプションの詳細については、「[AWS Container Insights Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/awscontainerinsightreceiver/README.md)」を参照してください。
# FireLens のログ送信先を CloudWatch Logs に設定する
Amazon ECS 用の FireLens では、タスク定義パラメータを使用して、ログのストレージと分析のために Amazon CloudWatch Logs にログをルーティングできます。FireLens は [Fluent Bit](https://fluentbit.io/) および [Fluentd](https://www.fluentd.org/) で動作します。提供されている AWS for Fluent Bit イメージを使用することも、独自の Fluent Bit または Fluentd イメージを使用することもできます。FireLens 設定を使用した Amazon ECS タスク定義の作成は、AWS SDK、AWS CLI、および AWS マネジメントコンソール でサポートされています。CloudWatch の詳細については、「[CloudWatch Logs とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)」を参照してください。
Amazon ECS に FireLens を使用する場合、重要な考慮事項があります。詳細については、「[考慮事項](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_firelens.html#firelens-considerations)」をご参照ください。
Fluent Bit イメージ用の AWS を見つけるには、「[Fluent Bit イメージのために AWS を使用する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/firelens-using-fluentbit.html)」をご参照ください。
FireLens 設定を使用するタスク定義を作成するには、「[FireLens 設定を使用するタスク定義の作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/firelens-taskdef.html)」をご参照ください。
**例**
次のタスク定義の例は、CloudWatch Logs ロググループにログを転送するログ設定を指定する方法を示しています。詳細については、*Amazon CloudWatch Logs ユーザーガイド*の「[Amazon CloudWatch Logs とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)」を参照してください。
ログ設定オプションで、ロググループ名とロググループが存在するリージョンを指定します。Fluent Bit で自動的にロググループを作成するには、`"auto_create_group":"true"` を指定します。フィルタリングに役立つログストリームプレフィックスとしてタスク ID を指定することもできます。詳細については、「[CloudWatch Logs 用の Fluent Bit プラグイン](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit/blob/mainline/README.md)」を参照してください。
```
{
"family": "firelens-example-cloudwatch",
"taskRoleArn": "arn:aws:iam::123456789012:role/ecs_task_iam_role",
"containerDefinitions": [
{
"essential": true,
"image": "906394416424.dkr.ecr.us-west-2.amazonaws.com/aws-for-fluent-bit:latest",
"name": "log_router",
"firelensConfiguration": {
"type": "fluentbit"
},
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "firelens-container",
"awslogs-region": "us-west-2",
"awslogs-create-group": "true",
"awslogs-stream-prefix": "firelens"
}
},
"memoryReservation": 50
},
{
"essential": true,
"image": "nginx",
"name": "app",
"logConfiguration": {
"logDriver":"awsfirelens",
"options": {
"Name": "cloudwatch_logs",
"region": "us-west-2",
"log_key": "log",
"log_group_name": "/aws/ecs/containerinsights/my-cluster/application",
"auto_create_group": "true",
"log_stream_name": "my-task-id"
}
},
"memoryReservation": 100
}
]
}
```
# Amazon EKS と Kubernetes での Container Insights のセットアップ
Container Insights は、Amazon EKS バージョン 1.23 以降でサポートされています。インストールのクイックスタート方法は、バージョン 1.24 以降でのみサポートされています。
Amazon EKS または Kubernetes で Container Insights をセットアップするための全体的なプロセスを次に示します。
1. 必要な前提条件を満たしていることを確認します。
1. Amazon CloudWatch Observability EKS アドオン、CloudWatch エージェント、または AWS Distro for OpenTelemetry をクラスターにセットアップして、メトリクスを CloudWatch に送信します。
**注記**
Amazon EKS 向けにオブザーバビリティが強化された Container Insights を使用するには、Amazon CloudWatch Observability EKS アドオンまたは CloudWatch エージェントを使用する必要があります。Container Insights のこのバージョンについての詳細は、「[Amazon EKS 向けに拡張オブザーバビリティを備えた Container Insights](container-insights-detailed-metrics.md)」を参照してください。
Fargate で Container Insights を使用するには、AWS Distro for OpenTelemetry を使用する必要があります。Amazon EKS 向けにオブザーバビリティが強化された Container Insights は、Fargate ではサポートされていません。
**注記**
Container Insights が Amazon EKS クラスターの Windows ワーカーノードをサポートするようになりました。Amazon EKS 向けにオブザーバビリティが強化された Container Insights も、Windows でサポートされています。Windows で Container Insights を有効にする詳細については、「[Container Insights の強化されたオブザーバビリティを有効にした状態で CloudWatch エージェントを使用する](Container-Insights-EKS-agent.md)」を参照してください。
OpenTelemetry メトリクスで Container Insights を使用するには、Amazon CloudWatch Observability EKS アドオンバージョン `v6.0.1-eksbuild.1` 以降をインストールします。詳細については、「[Amazon EKS の OpenTelemetry メトリクスを使用した Container Insights](container-insights-otel-metrics.md)」を参照してください。
Fluent Bit または Fluentd をセットアップしてログを CloudWatch Logs に送信します。(Amazon CloudWatch Observability EKS アドオンをインストールする場合、これはデフォルトで有効になっています。)
CloudWatch エージェントを使用している場合、これらのステップは、クイックスタートセットアップの一部として一度に実行することも、個別に行うこともできます。
1. (オプション) Amazon EKS コントロールプレーンのログ記録の設定
1. (オプション) クラスターで StatsD メトリクスを CloudWatch に送信するように StatsD エンドポイントとして CloudWatch エージェントをセットアップします。
1. (オプション) App Mesh Envoy アクセスログを有効にします。
Container Insights の元のバージョンでは、収集されたメトリクスおよび取り込まれたログはカスタムメトリクスとして課金されます。Amazon EKS 向けにオブザーバビリティが強化された Container Insights では、観察結果ごと Container Insights メトリクスおよびログに課金されます。保存されたメトリクスまたは取り込まれたログごとには課金されません。CloudWatch の料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」をご覧ください。
**Topics**
+ [CloudWatch での Container Insights の前提条件の検証](Container-Insights-prerequisites.md)
+ [Container Insights の強化されたオブザーバビリティを有効にした状態で CloudWatch エージェントを使用する](Container-Insights-EKS-agent.md)
+ [AWS Distro for OpenTelemetry の使用](Container-Insights-EKS-otel.md)
+ [CloudWatch Logs にログを送信する](Container-Insights-EKS-logs.md)
+ [Amazon EKS および Kubernetes での Container Insights の更新または削除](ContainerInsights-update-delete.md)
# CloudWatch での Container Insights の前提条件の検証
Amazon EKS または Kubernetes で Container Insights をインストールする前に、以下を確認してください。これらの前提条件は、CloudWatch エージェントまたは AWS Distro for OpenTelemetry を使用して Amazon EKS クラスターに Container Insights をセットアップする場合に適用されます。
+ Amazon EKS および Kubernetes に Container Insights がサポートされているいずれかのリージョンに、ノードがアタッチされて機能している Amazon EKS または Kubernetes クラスターがある。サポートされているリージョンのリストについては、「[Container Insights](ContainerInsights.md)」を参照してください。
+ `kubectl` がインストールされ、実行されている。詳細については、*Amazon EKS ユーザーガイド*の「[`kubectl` のインストール](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)」を参照してください。
+ Amazon EKS を使用する代わりに、AWS で実行されている Kubernetes を使用している場合は、以下の前提条件も必要になります。
+ Kubernetes クラスターで、ロールベースのアクセス制御 (RBAC) が有効になっている。詳細については、Kubernetes Reference の「[RBAC 認可の使用](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)」を参照してください。
+ kubelet で Webhook 認可モードが有効になっている。詳細については、Kubernetes Reference の「[Kubelet の認証/認可](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/)」を参照してください。
また、Amazon EKS ワーカーノードが CloudWatch にメトリクスとログを送信できるようにするには、IAM にもアクセス許可を付与する必要があります。次の 2 通りの方法があります。
+ ワーカーノードの IAM ロールにポリシーをアタッチします。これは、Amazon EKS クラスターと他の Kubernetes クラスターの両方に有効です。
+ クラスターでサービスアカウントの IAM ロールを使用し、このロールにポリシーをアタッチします。これは Amazon EKS クラスターでのみ機能します。
最初のオプションはノード全体へのアクセス許可を CloudWatch に付与しますが、サービスアカウントの IAM ロールを使用した場合は、該当する daemonset ポッドへのアクセス権のみを CloudWatch に付与します。
**ワーカーノードの IAM ロールにポリシーをアタッチする**
ワーカーノードの IAM ロールにポリシーをアタッチするには、次の手順に従います。これは、Amazon EKS クラスターと、Amazon EKS 外の Kubernetes クラスターの両方で機能します。
**ワーカーノードの IAM ロールに必要なポリシーをアタッチするには**
1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。
1. ワーカーノードのインスタンスの 1 つを選択し、説明で IAM ロールを選択します。
1. IAM ロールページで、[**Attach policies (ポリシーをアタッチします)**] を選択します。
1. ポリシーのリストで、[**CloudWatchAgentServerPolicy**] の横にあるチェックボックスを選択します。必要に応じて、検索ボックスを使用してポリシーを見つけます。
1. [**ポリシーのアタッチ**] を選択します。
Amazon EKS 外で Kubernetes クラスターを実行している場合、まだワーカーノードにアタッチされた IAM ロールがない可能性があります。アタッチしていない場合は、最初に IAM ロールをインスタンスにアタッチし、前の手順で説明しているようにポリシーを追加する必要があります。インスタンスへのロールのアタッチの詳細については、「Amazon EC2 ユーザーガイド」の「[インスタンスへの IAM ロールのアタッチ](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/iam-roles-for-amazon-ec2.html#attach-iam-role)」を参照してください。
Amazon EKS 外で Kubernetes クラスターを実行しており、メトリクスで EBS ボリューム ID を収集する場合は、インスタンスにアタッチされた IAM ロールに別のポリシーを追加する必要があります。以下をインラインポリシーとして追加します。詳細については、*IAM ユーザーガイド*の「[IAM ID アクセス許可の追加と削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeVolumes"
],
"Resource": "*",
"Effect": "Allow"
}
]
}
```
------
**IAM サービスアカウントのロールを使用する**
この方法は Amazon EKS クラスターでのみ機能します。
**IAM サービスアカウントロールを使用して CloudWatch にアクセス許可を付与するには**
1. クラスターでサービスアカウントの IAM ロールを有効にします (まだ有効にしていない場合)。詳細については、「[クラスターでサービスアカウントの IAM ロールを有効にする](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html)」を参照してください。
1. まだ設定していない場合は、サービスアカウントが IAM ロールを使用するように設定します。詳細については、「[IAM ロールを引き受けるための Kubernetes サービスアカウントの設定](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html)」を参照してください。
ロールの作成時に、ロール用に作成するポリシーに加えて、**CloudWatchAgentServerPolicy** IAM ポリシーをロールにアタッチします。また、このロールにリンクされている関連する Kubernetes サービスアカウントは、次のステップで CloudWatch と Fluent Bit のデーモンセットがデプロイされる `amazon-cloudwatch` 名前空間に作成する必要があります
1. IAM ロールをクラスターのサービスアカウントに関連付けます (まだ関連付けていない場合)。詳細については、「[IAM ロールを引き受けるための Kubernetes サービスアカウントの設定](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html)」を参照してください。
# Container Insights の強化されたオブザーバビリティを有効にした状態で CloudWatch エージェントを使用する
次のセクションのいずれかに記載されている手順を実施して、CloudWatch エージェントを使用して Amazon EKS クラスターまたは Kubernetes クラスターに Container Insights をセットアップします。クイックスタートの手順は、Amazon EKS バージョン 1.24 以降でのみサポートされています。
**注記**
Container Insights は、次のセクションのいずれかの手順に従いインストールできます。3 つの手順すべてを実施する必要はありません。
**Topics**
+ [Amazon CloudWatch Observability EKS アドオンのクイックスタート](Container-Insights-setup-EKS-addon.md)
+ [Amazon EKS および Kubernetes の Container Insights のクイックスタートセットアップ](Container-Insights-setup-EKS-quickstart.md)
+ [クラスターメトリクスを収集するよう CloudWatch エージェントを設定する](Container-Insights-setup-metrics.md)
# Amazon CloudWatch Observability EKS アドオンのクイックスタート
Amazon EKS アドオンを使用して、Amazon EKS 向けにオブザーバビリティが強化された Container Insights をインストールできます。このアドオンは、CloudWatch エージェントをインストールしてクラスターからインフラストラクチャメトリクスを送信します。また、Fluent Bit をインストールしてコンテナログを送信するほか、CloudWatch [Application Signals](CloudWatch-Application-Monitoring-Sections.md) を有効にしてアプリケーションパフォーマンステレメトリを送信します。
Amazon EKS アドオンバージョン 1.5.0 以降を使用すると、Container Insights はクラスター内の Linux と Windows の両方のワーカーノードで有効になります。Amazon EKS の Windows では、Application Signals はサポートされていません。
Amazon EKS アドオンは、Amazon EKS ではなく Kubernetes を実行しているクラスターではサポートされていません。
Amazon CloudWatch Observability EKS アドオンについての詳細は、「[Amazon CloudWatch Observability EKS アドオンまたは Helm チャートを使用して CloudWatch エージェントをインストールする](install-CloudWatch-Observability-EKS-addon.md)」を参照してください。
バージョン 3.1.0 以降のアドオンを使用している場合は、EKS Pod Identity を使用して、必要なアクセス許可をアドオンに付与できます。EKS Pod Identity は、推奨オプションであり、最小特権、認証情報のローテーション、監査可能性などなどの利点を提供します。さらに、EKS Pod Identity を使用すると、クラスター作成自体の一部として EKS アドオンをインストールできます。
**Amazon CloudWatch Observability EKS アドオンをインストールするには**
1. [EKS Pod Identity の関連付け](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html#pod-id-association-create/)の手順に従って、IAM ロールを作成して EKS Pod Identity エージェントを設定します。
1. ロールに必要なアクセス許可を付与する IAM ポリシーをアタッチします。*my-role* を前のステップの IAM ロール名に置き換えます。
```
aws iam attach-role-policy \
--role-name my-role \
--policy-arn=arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
1. 前のステップで作成した IAM ロールを使用して、次のコマンドを入力します。
```
aws eks create-addon \
--addon-name amazon-cloudwatch-observability \
--cluster-name my-cluster-name \
--pod-identity-associations serviceAccount=cloudwatch-agent,roleArn=arn:aws:iam::111122223333:role/my-role
```
# Amazon EKS および Kubernetes の Container Insights のクイックスタートセットアップ
**重要**
Amazon EKS クラスターに Container Insights をインストールする場合は、このセクションの手順を使用するのではなく Amazon CloudWatch Observability EKS アドオンを使用してインストールすることをお勧めします。また、高速コンピューティングネットワークを取得するには、Amazon CloudWatch Observability EKS アドオンを使用する必要があります。詳細と手順については、[Amazon CloudWatch Observability EKS アドオンのクイックスタート](Container-Insights-setup-EKS-addon.md) を参照してください。
Container Insights のセットアップを完了するには、このセクションのクイックスタート手順に従います。2023 年 11 月 6 日以降にこのセクションの手順を使用して Amazon EKS クラスターにインストールを行う場合は、Amazon EKS 向けにオブザーバビリティが強化された Container Insights をそのクラスターにインストールします。
**重要**
このセクションに記載されている手順を完了する前に、IAM アクセス許可を含む前提条件を確認しておく必要があります。詳細については、「[CloudWatch での Container Insights の前提条件の検証](Container-Insights-prerequisites.md)」を参照してください。
または、代わりに「[クラスターメトリクスを収集するよう CloudWatch エージェントを設定する](Container-Insights-setup-metrics.md)」および「[CloudWatch Logs にログを送信する](Container-Insights-EKS-logs.md)」の 2 つのセクションの手順に従うことができます。これらのセクションでは、CloudWatch エージェントがどのように Amazon EKS および Kubernetes と動作するかについてより詳しく説明されていますが、追加のインストール手順を実行する必要があります。
Container Insights の元のバージョンでは、収集されたメトリクスおよび取り込まれたログはカスタムメトリクスとして課金されます。Amazon EKS 向けにオブザーバビリティが強化された Container Insights では、観察結果ごと Container Insights メトリクスおよびログに課金されます。保存されたメトリクスまたは取り込まれたログごとには課金されません。CloudWatch の料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」をご覧ください。
**注記**
Amazon は、Container Insights のデフォルトのログソリューションとして Fluent Bit の提供を開始しました。これにより、パフォーマンスの大幅な向上が見込めます。Fluentd の代わりに Fluent Bit を使用することをお勧めします。
## CloudWatch エージェントオペレーターと Fluent Bit を使用したクイックスタート
Fluent Bit については、最適化されたバージョンと Fluentd に似た使用感を提供するバージョンの 2 つの設定があります。クイックスタート設定では、最適化されたバージョンが使用されます。Fluentd 互換の設定の詳細については、「[CloudWatch Logs へログを送信する DaemonSet として Fluent Bit を設定する](Container-Insights-setup-logs-FluentBit.md)」を参照してください。
CloudWatch エージェントオペレーターは、Amazon EKS クラスターにインストールされる追加のコンテナです。OpenTelemetry Operator for Kubernetes をモデルにしています。オペレーターは、クラスター内の Kubernetes リソースのライフサイクルを管理します。CloudWatch エージェント、DCGM Exporter (NVIDIA)、および AWS Neuron Monitor を Amazon EKS クラスターにインストールして管理します。Fluent Bit および Windows 用 CloudWatch エージェントは、オペレーターが管理しなくても Amazon EKS クラスターに直接インストールされます。
安全性の高い多機能な証明機関を利用できるように、CloudWatch エージェントオペレーターには cert-manager が必要です。これは、Kubernetes で TLS 証明書を管理するのに広く採用されているソリューションです。cert-manager を使用すると、これらの証明書を取得、更新、管理、使用するプロセスを簡素化できます。これにより、証明書が有効で最新の状態であることが保証されます。有効期限前の設定しておいた時刻になると、証明書が更新されます。また、AWS Certificate Manager Private Certificate Authority などサポートされているさまざまな発行元から簡単に証明書を発行できます。
**クイックスタートを使用して Container Insights をデプロイするには**
1. まだクラスターにインストールされていない場合は、cert-manager をインストールします。詳細については、[cert-manager Installation](https://cert-manager.io/docs/installation/) を参照してください。
1. 次のコマンドを入力して、カスタムリソース定義 (CRD) をインストールします。
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-custom-resource-definitions.yaml | kubectl apply --server-side -f -
```
1. 次のコマンドを入力して、オペレーターをインストールします。*my-cluster-name* は Amazon EKS または Kubernetes クラスターの名前に置き換え、*my-cluster-region* はログが発行されるリージョンの名前に置き換えます。AWS アウトバウンドデータ転送コストを削減するために、クラスターがデプロイされているのと同じリージョンを使用することをお勧めします。
```
ClusterName=my-cluster-name
RegionName=my-cluster-region
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-operator-rendered.yaml | sed 's/{{cluster_name}}/'${ClusterName}'/g;s/{{region_name}}/'${RegionName}'/g' | kubectl apply -f -
```
例えば、`MyCluster` という名前のクラスターに Container Insights をデプロイし、ログとメトリクスを米国西部 (オレゴン) に発行するには、次のコマンドを入力します。
```
ClusterName='MyCluster'
RegionName='us-west-2'
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-operator-rendered.yaml | sed 's/{{cluster_name}}/'${ClusterName}'/g;s/{{region_name}}/'${RegionName}'/g' | kubectl apply -f -
```
**Container Insights からの移行**
Amazon EKS クラスターで既に Container Insights を設定しており、Amazon EKS 向けにオブザーバビリティが強化された Container Insights に移行する場合は、「[CloudWatch の Amazon EKS 向けにオブザーバビリティが強化された Container Insights へのアップグレード](Container-Insights-upgrade-enhanced.md)」を参照してください。
**Container Insights の使用**
クイックスタートセットアップの使用後に Container Insights を削除する場合は、次のコマンドを入力します。
```
ClusterName=my-cluster-name
RegionName=my-cluster-region
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-operator-rendered.yaml | sed 's/{{cluster_name}}/'${ClusterName}'/g;s/{{region_name}}/'${RegionName}'/g' | kubectl delete -f -
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-custom-resource-definitions.yaml | kubectl delete -f -
```
# クラスターメトリクスを収集するよう CloudWatch エージェントを設定する
**重要**
Amazon EKS クラスターに Container Insights をインストールする場合は、このセクションの手順を使用するのではなく Amazon CloudWatch Observability EKS アドオンを使用してインストールすることをお勧めします。詳細と手順については、[Amazon CloudWatch Observability EKS アドオンのクイックスタート](Container-Insights-setup-EKS-addon.md) を参照してください。
Container Insights をセットアップしてメトリクスを収集するには、「[Amazon EKS および Kubernetes の Container Insights のクイックスタートセットアップ](Container-Insights-setup-EKS-quickstart.md)」の手順に従うか、このセクションの手順に従います。以下のステップでは、クラスターからメトリクスを収集できるよう CloudWatch エージェントをセットアップします。
2023 年 11 月 6 日以降にこのセクションの手順を使用して Amazon EKS クラスターにインストールを行う場合は、Amazon EKS 向けにオブザーバビリティが強化された Container Insights をそのクラスターにインストールします。
## ステップ 1: CloudWatch の名前空間を作成する
CloudWatch に対して `amazon-cloudwatch` という Kubernetes 名前空間を作成するには、次のステップを使用します。すでにこの名前空間を作成している場合は、以下のステップをスキップできます。
**CloudWatch の名前空間を作成するには**
+ 以下のコマンドを入力します。
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cloudwatch-namespace.yaml
```
## ステップ 2: クラスターのサービスアカウントを作成する
次の方法のいずれかを使用して、CloudWatch エージェントのサービスアカウントを作成します (作成済みでない場合)。
+ `kubectl` を使用する
+ `kubeconfig` ファイルを使用する
### 認証に `kubectl` を使用する
**`kubectl` を使用して CloudWatch エージェントのサービスアカウントを作成するには**
+ 次のコマンドを入力します。
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-serviceaccount.yaml
```
前のステップに従っていないが、使用する CloudWatch エージェントのサービスアカウントが既にある場合は、そのアカウントに次のルールがあることを確認する必要があります。さらに、Container Insights のインストールの残りの手順では、`cloudwatch-agent` の代わりにそのサービスアカウントの名前を使用する必要があります。
```
rules:
- apiGroups: [""]
resources: ["pods", "nodes", "endpoints"]
verbs: ["list", "watch"]
- apiGroups: [ "" ]
resources: [ "services" ]
verbs: [ "list", "watch" ]
- apiGroups: ["apps"]
resources: ["replicasets", "daemonsets", "deployments", "statefulsets"]
verbs: ["list", "watch"]
- apiGroups: ["batch"]
resources: ["jobs"]
verbs: ["list", "watch"]
- apiGroups: [""]
resources: ["nodes/proxy"]
verbs: ["get"]
- apiGroups: [""]
resources: ["nodes/stats", "configmaps", "events"]
verbs: ["create", "get"]
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["cwagent-clusterleader"]
verbs: ["get","update"]
- nonResourceURLs: ["/metrics"]
verbs: ["get", "list", "watch"]
- apiGroups: [ "discovery.k8s.io" ]
resources: [ "endpointslices" ]
verbs: [ "list", "watch", "get" ]
```
### 認証に `kubeconfig` を使用する
または、認証に `kubeconfig` ファイルを使用することもできます。この方法を使用して CloudWatch エージェント設定で `kubeconfig` パスを直接指定すれば、サービスアカウントは不要になります。また、認証のための Kubernetes コントロールプレーン API への依存関係を除去できるため、セットアップが合理化され、kubeconfig ファイルを通じて認証を管理することでセキュリティが強化される可能性があります。
この方法を使用するには、次の例のように CloudWatch エージェント設定ファイルを更新して `kubeconfig` ファイルへのパスを指定します。
```
{
"logs": {
"metrics_collected": {
"kubernetes": {
"cluster_name": "YOUR_CLUSTER_NAME",
"enhanced_container_insights": false,
"accelerated_compute_metrics": false,
"tag_service": false,
"kube_config_path": "/path/to/your/kubeconfig"
"host_ip": "HOSTIP"
}
}
}
}
```
`kubeconfig` ファイルを作成するには、`system:masters` Kubernetes ロールを持つ `admin/{create_your_own_user}` ユーザーの Certificate Signing Request (CSR) を作成します。次に、Kubernetes クラスターの認証局 (CA) で署名し、`kubeconfig` ファイルを作成します。
## ステップ 3: CloudWatch エージェント用の ConfigMap を作成する
CloudWatch エージェント用の ConfigMap を作成するには、次のステップを使用します。
**CloudWatch エージェント用の ConfigMap を作成するには**
1. 以下のコマンドを実行して、ConfigMap YAML を `kubectl` クライアントホストにダウンロードします。
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-configmap-enhanced.yaml
```
1. ダウンロードした YAML ファイルを次のように編集します。
+ **cluster\$1name** – `kubernetes` セクションで、`{{cluster_name}}` をクラスターの名前と置き換えます。`{{}}` 文字を削除します。または、Amazon EKS クラスターを使用している場合、`"cluster_name"` フィールドと値を削除できます。そうした場合、CloudWatch エージェントは Amazon EC2 タグからクラスター名を検出します。
1. (オプション) モニターリング要件に基づいて、次のように ConfigMap をさらに変更します。
+ **metrics\$1collection\$1interval** – `kubernetes` セクションで、エージェントがメトリクスを収集する頻度を指定できます。デフォルト値は 60 秒です。kubelet でのデフォルトの cadvisor 収集間隔は 15 秒であるため、この値を 15 秒未満に設定しないでください。
+ **endpoint\$1override** – `logs` セクションで、デフォルトのエンドポイントを上書きする場合は、CloudWatch Logs エンドポイントを指定できます。VPC のクラスターからデータを発行し、データの送信先を VPC エンドポイントとする場合は、この操作を行うことをお勧めします。
+ **force\$1flush\$1interval** – `logs` セクションで、CloudWatch Logs に発行される前にバッチ処理のログイベントのインターバルを指定できます。デフォルト値は 5 秒です。
+ **region** – デフォルトでは、エージェントはワーカーノードがあるリージョンにメトリクスを発行します。これを無効にするには、`region` セクションに `agent` フィールドを追加できます。例: `"region":"us-west-2"`。
+ **statsd** セクション – クラスターの各ワーカーノードで StatsD リスナーとして CloudWatch Logs エージェントを実行する場合は、次の例のように `statsd` セクションに `metrics` セクションを追加できます。このセクションの他の StatsD オプションについては、「[StatsD を使用してカスタムメトリクスを取得する](CloudWatch-Agent-custom-metrics-statsd.md)」を参照してください。
```
"metrics": {
"metrics_collected": {
"statsd": {
"service_address":":8125"
}
}
}
```
JSON セクションの完全な例を次に示します。認証に `kubeconfig` ファイルを使用している場合は、`kube_config_path` パラメータを追加して kubeconfig ファイルへのパスを指定します。
```
{
"agent": {
"region": "us-east-1"
},
"logs": {
"metrics_collected": {
"kubernetes": {
"cluster_name": "MyCluster",
"metrics_collection_interval": 60,
"kube_config_path": "/path/to/your/kubeconfig" //if using kubeconfig for authentication
}
},
"force_flush_interval": 5,
"endpoint_override": "logs.us-east-1.amazonaws.com"
},
"metrics": {
"metrics_collected": {
"statsd": {
"service_address": ":8125"
}
}
}
}
```
1. 次のコマンドを実行して、クラスターに ConfigMap を作成します。
```
kubectl apply -f cwagent-configmap-enhanced.yaml
```
## ステップ 4: CloudWatch エージェントを DaemonSet としてデプロイする
CloudWatch エージェントのインストールを完了してコンテナメトリクスの収集を開始するには、次のステップを使用します。
**CloudWatch エージェントを DaemonSet としてデプロイするには**
1.
+ クラスターで StatsD を使用しない場合は、次のコマンドを入力します。
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-daemonset.yaml
```
+ StatsD を使用する場合は、以下の手順に従います。
1. 次のコマンドを実行して、`kubectl` クライアントに DaemonSet YAML をダウンロードします。
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-daemonset.yaml
```
1. 次のように、`port` ファイルの `cwagent-daemonset.yaml` セクションのコメントを解除します。
```
ports:
- containerPort: 8125
hostPort: 8125
protocol: UDP
```
1. 次のコマンドを実行して、クラスターに CloudWatch エージェントをデプロイします。
```
kubectl apply -f cwagent-daemonset.yaml
```
1. 次のコマンドを実行して、クラスターの Windows ノードに CloudWatch エージェントをデプロイします。StatsD リスナーは Windows 上の CloudWatch エージェントではサポートされていません。
```
kubectl apply -f cwagent-daemonset-windows.yaml
```
1. 次のコマンドを実行して、エージェントがデプロイされたことを確認します。
```
kubectl get pods -n amazon-cloudwatch
```
操作を完了すると、CloudWatch エージェントは `/aws/containerinsights/Cluster_Name/performance` という名前のロググループを作成し、このロググループにパフォーマンスログイベントを送信します。また、このエージェントを StatsD リスナーとしてもセットアップする場合、エージェントはアプリケーションポッドがスケジュールされたノードの IP アドレスを使用して、ポート 8125 で StatsD メトリクスをリッスンします。
### トラブルシューティング
エージェントが正しくデプロイされない場合は、次の操作を試してください。
+ 次のコマンドを実行して、ポッドのリストを取得します。
```
kubectl get pods -n amazon-cloudwatch
```
+ 次のコマンドを実行して、出力の下部にあるイベントを確認します。
```
kubectl describe pod pod-name -n amazon-cloudwatch
```
+ 次のコマンドを実行して、ログを確認します。
```
kubectl logs pod-name -n amazon-cloudwatch
```
# AWS Distro for OpenTelemetry の使用
AWS Distro for OpenTelemetry コレクターを使用して、Amazon EKS クラスターからメトリクスを収集するように Container Insights を設定できます。AWS Distro for OpenTelemetry の詳細については、[AWS Distro for OpenTelemetry](https://aws.amazon.com/otel/) を参照してください。
**重要**
AWS Distro for OpenTelemetry を使用してインストールする場合、Container Insights はインストールされますが、Amazon EKS 向けにオブザーバビリティが強化された Container Insights はインストールされません。また、Amazon EKS 向けにオブザーバビリティが強化された Container Insights でサポートされている詳細なメトリクスは収集できません。
Container Insights の設定方法は、クラスターが Amazon EC2 インスタンスでホストされているか、または AWS Fargate でホストされているかによって異なります。
## Amazon EC2 でホストされている Amazon EKS クラスター
まだ行っていない場合は、必要な IAM ロールを含む前提条件を満たしていることを確認してください。詳細については、「[CloudWatch での Container Insights の前提条件の検証](Container-Insights-prerequisites.md)」を参照してください。
Amazon は、Amazon EC2 で Amazon Elastic Kubernetes Service のモニターリングを設定するために使用できる Helm チャートを提供します。このモニターリングでは、メトリクスに AWS Distro for OpenTelemetry(ADOT) Collector を使用し、ログに Fluent Bit を使用します。したがって、Helm チャートは Amazon EC2 で Amazon EKS を使用し、CloudWatch Container Insights に送信するメトリクスとログを収集したいお客様にとって有用です。この Helm チャートの詳細については、「[ADOT Helm chart for EKS on EC2 metrics and logs to Amazon CloudWatch Container Insights](https://github.com/aws-observability/aws-otel-helm-charts/tree/main/charts/adot-exporter-for-eks-on-ec2)」(EKS on EC2 メトリクスと Amazon CloudWatch Container Insights へのログに関する ADOT Helm チャート) を参照してください。
または、このセクションの残りの手順を使用することもできます。
まず、次のコマンドを入力して、AWS Distro for OpenTelemetry コレクターを DaemonSet としてデプロイします。
```
curl https://raw.githubusercontent.com/aws-observability/aws-otel-collector/main/deployment-template/eks/otel-container-insights-infra.yaml |
kubectl apply -f -
```
コレクターが実行中であることを確認するには、次のコマンドを使用します。
```
kubectl get pods -l name=aws-otel-eks-ci -n aws-otel-eks
```
このコマンドの出力に `Running` 状態の複数のポッドが含まれている場合、コレクターは実行中であり、クラスターからメトリクスを収集しています。コレクターは `aws/containerinsights/cluster-name/performance` という名前のロググループを作成し、パフォーマンスログイベントを送信します。
CloudWatch で Container Insights メトリクスを表示する方法については、[Container Insights メトリクスの表示](Container-Insights-view-metrics.md) を参照してください。
AWS は、このシナリオの GitHub に関するドキュメントも提供しています。Container Insights によって公開されるメトリクスとログをカスタマイズする場合は、[https://aws-otel.github.io/docs/getting-started/container-insights/eks-infra](https://aws-otel.github.io/docs/getting-started/container-insights/eks-infra) を参照してください。
## Fargate でホストされている Amazon EKS クラスター
ADOT Collector を設定およびデプロイして、Fargate 上の Amazon EKS クラスターにデプロイされたワークロードからシステムメトリクスを収集し、CloudWatch Container Insights に送信する方法については、AWS Distro for OpenTelemetry ドキュメントの「[Container Insights EKS Fargate](https://aws-otel.github.io/docs/getting-started/container-insights/eks-fargate)」を参照してください。
# CloudWatch Logs にログを送信する
コンテナから Amazon CloudWatch Logs にログを送信するには、Fluent Bitを使用します。詳細については、「[Fluent Bit](https://fluentbit.io/)」を参照してください。
**注記**
2025 年 2 月 10 日現在、AWS は CloudWatch Logs へのログ転送として FluentD のサポートを廃止しました。Fluent Bit を使用することをお勧めします。これは、軽量でリソース効率の高い代替手段です。既存の FluentD デプロイは引き続き機能します。ログ記録パイプラインを Fluent Bit に移行して、継続的なサポートと最適なパフォーマンスを確保します。
Container Insights は、以前は FluentD を使用してコンテナからログを送信することもサポートしていました。FluentD は廃止され、Container Insights ではサポートされなくなりました。代わりに Fluent Bit を使用してください。
**Topics**
+ [CloudWatch Logs へログを送信する DaemonSet として Fluent Bit を設定する](Container-Insights-setup-logs-FluentBit.md)
+ [(オプション) Amazon EKS コントロールプレーンのログ記録の設定](Container-Insights-setup-control-plane-logging.md)
+ [(オプション) 大規模なクラスターで Use\$1Kubelet 機能を有効にします。](ContainerInsights-use-kubelet.md)
# CloudWatch Logs へログを送信する DaemonSet として Fluent Bit を設定する
以下のセクションでは、Fluent Bit をデプロイして、コンテナから CloudWatch Logs にログを送信する方法について説明します。
**Topics**
+ [Fluent Bit の設定](#Container-Insights-FluentBit-setup)
+ [複数行ログのサポート](#ContainerInsights-fluentbit-multiline)
+ [(オプション) Fluent Bit からのログボリュームの縮小](#ContainerInsights-fluentbit-volume)
+ [トラブルシューティング](#Container-Insights-FluentBit-troubleshoot)
+ [ダッシュボード](#Container-Insights-FluentBit-dashboard)
## Fluent Bit の設定
コンテナからログを収集するように Fluent Bit を設定するには、「[Amazon EKS および Kubernetes の Container Insights のクイックスタートセットアップ](Container-Insights-setup-EKS-quickstart.md)」のステップを実行するか、このセクションのステップを実行します。
どちらの方法でも、クラスターノードにアタッチされた IAM ロールに十分なアクセス許可が必要です。Amazon EKS クラスターの実行に必要なアクセス許可の詳細については、*Amazon EKS ユーザーガイド*の「[Amazon EKS IAM ポリシー、ロール、アクセス許可](https://docs.aws.amazon.com/eks/latest/userguide/IAM_policies.html)」を参照してください。
以下のステップでは、CloudWatch Logs へログを送信する daemonSet として Fluent Bit を設定します。このステップを完了すると、Fluent Bit は、次のロググループを作成します (まだ存在していない場合)。
**重要**
Container Insights で既に FluentD を設定しており、FluentD DaemonSet が期待どおりに実行されない場合 (`containerd` ランタイムを使用していると発生する場合があります)、Fluent Bit をインストールする前にアンインストールして、Fluent Bit が FluentD エラーログメッセージを処理しないようにする必要があります。それ以外の場合は、Fluent Bit が正常にインストールされたらすぐに FluentD をアンインストールする必要があります。Fluent Bit のインストール後に Fluentd をアンインストールすることで、この移行プロセス中のログ記録の継続性が確保されます。ログを CloudWatch Logs に送信するには、Fluent Bit または FluentD のいずれか 1 つのみが必要になります。
| ロググループ名 | ログソース |
| --- | --- |
| `/aws/containerinsights/Cluster_Name/application` | `/var/log/containers` のすべてのログファイル |
| `/aws/containerinsights/Cluster_Name/host` | `/var/log/dmesg`、`/var/log/secure`、および `/var/log/messages` からのログ |
| `/aws/containerinsights/Cluster_Name/dataplane` | `/var/log/journal`、`kubelet.service`、および`kubeproxy.service` に対する `docker.service` のログ。 |
**Fluent Bit をインストールしてコンテナから CloudWatch Logs にログを送信するには**
1. `amazon-cloudwatch` という名前の名前空間がまだない場合は、次のコマンドを入力して作成します。
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cloudwatch-namespace.yaml
```
1. 次のコマンドを実行して、クラスター名とログを送信するリージョンを持つ `cluster-info` という名前の ConfigMap を作成します。*cluster-name* と *cluster-region* をクラスターの名前とリージョンに置き換えます。
```
ClusterName=cluster-name
RegionName=cluster-region
FluentBitHttpPort='2020'
FluentBitReadFromHead='Off'
[[ ${FluentBitReadFromHead} = 'On' ]] && FluentBitReadFromTail='Off'|| FluentBitReadFromTail='On'
[[ -z ${FluentBitHttpPort} ]] && FluentBitHttpServer='Off' || FluentBitHttpServer='On'
kubectl create configmap fluent-bit-cluster-info \
--from-literal=cluster.name=${ClusterName} \
--from-literal=http.server=${FluentBitHttpServer} \
--from-literal=http.port=${FluentBitHttpPort} \
--from-literal=read.head=${FluentBitReadFromHead} \
--from-literal=read.tail=${FluentBitReadFromTail} \
--from-literal=logs.region=${RegionName} -n amazon-cloudwatch
```
このコマンドでは、プラグインメトリクスをモニターリングするための `FluentBitHttpServer` がデフォルトでオンになっています。無効にするには、コマンドの 3 行目を `FluentBitHttpPort=''` (空の文字列) に変更します。
また、デフォルトでは、Fluent Bit はテールからログファイルを読み取り、デプロイ後に新しいログのみを取得します。逆をご希望の場合は、`FluentBitReadFromHead='On'` を設定することで、ファイルシステム内のすべてのログが収集されます。
1. 次のいずれかのコマンドを実行して、Fluent Bit daemonset をクラスターにダウンロードしてデプロイします。
+ Linux コンピュータ用の Fluent Bit 最適化設定が必要な場合は、このコマンドを実行します。
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/fluent-bit/fluent-bit.yaml
```
+ Windows コンピュータ用の Fluent Bit 最適化設定が必要な場合は、このコマンドを実行します。
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/fluent-bit/fluent-bit-windows.yaml
```
+ Linux コンピュータを使用しており、より Fluentd に似ている Fluent Bit の設定が必要な場合は、このコマンドを実行します。
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/fluent-bit/fluent-bit-compatible.yaml
```
**重要**
Fluent Bit デーモンセットの設定では、デフォルトでログレベルが INFO に設定されるため、CloudWatch Logs の取り込みコストが高くなる可能性があります。ログの取り込み量とコストを削減したい場合は、ログレベルを ERROR に変更すると削減できます。
ログの量を減らす方法の詳細については、「[(オプション) Fluent Bit からのログボリュームの縮小](#ContainerInsights-fluentbit-volume)」を参照してください
1. 次のコマンドを実行してデプロイを検証します。各ノードには、**fluent-bit-\$1** という名前の 1 つのポッドが必要です。
```
kubectl get pods -n amazon-cloudwatch
```
上記の手順を実行することにより、クラスターに次のリソースが作成されます。
+ `Fluent-Bit` 名前空間の `amazon-cloudwatch` という名前のサービスアカウント。このサービスアカウントは、Fluent Bit daemonSet を実行するために使用されます。詳細については、Kubernetes Reference の[サービスアカウントの管理](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/)を参照してください。
+ `Fluent-Bit-role` 名前空間の `amazon-cloudwatch` という名前のクラスターロール。このクラスターロールは、ポッドログの `get`、`list`、`watch` の各アクセス許可を `Fluent-Bit` サービスアカウントに付与します。詳細については、Kubernetes Reference の [API の概要](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#api-overview/)を参照してください。
+ `Fluent-Bit-config` 名前空間の `amazon-cloudwatch` という名前の ConfigMap。この ConfigMap には、Fluent Bit によって使用される設定が含まれています。詳細については、Kubernetes Tasks ドキュメントの「[Configure a Pod to Use a ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/)」を参照してください。
Fluent Bit の設定を検証する場合は、次の手順を実行します。
**Fluent Bit 設定の検証**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、**[Log groups]** (ロググループ) を選択します。
1. Fluent Bit をデプロイしたリージョンにいることを確認してください。
1. リージョン内のロググループのリストを確認します。次のように表示されます。
+ `/aws/containerinsights/Cluster_Name/application`
+ `/aws/containerinsights/Cluster_Name/host`
+ `/aws/containerinsights/Cluster_Name/dataplane`
1. これらのロググループのいずれかに移動し、ログストリームの [**Last Event Time**] (最終のイベント時刻) を確認します。Fluent Bit をデプロイしたときと比べて最近のものである場合は、設定が検証されます。
`/dataplane` ロググループの作成にわずかな遅延が生じることがあります。Fluent Bit がそのロググループのログ送信を開始したときにのみ、これらのロググループが作成されるため、これは正常です。
## 複数行ログのサポート
複数行ログで Fluent Bit を使用する方法については、Fluent Bit のドキュメントの次のセクションを参照してください。
+ [複数行の解析](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/multiline-parsing)
+ [複数行とコンテナ (v1.8)](https://docs.fluentbit.io/manual/pipeline/inputs/tail#multiline-and-containers-v1.8)
+ [複数行コア (v1.8)](https://docs.fluentbit.io/manual/pipeline/inputs/tail#multiline-core-v1.8)
+ [tail 入力で常に複数行を使用する](https://github.com/aws/aws-for-fluent-bit/blob/mainline/troubleshooting/debugging.md#always-use-multiline-the-tail-input)
## (オプション) Fluent Bit からのログボリュームの縮小
デフォルトでは、Fluent Bit アプリケーションログおよび Kubernetes メタデータを CloudWatch に送信します。CloudWatch に送信されるデータの量を減らす場合は、これらのデータソースが一方または両方の CloudWatch に送信されることを停止できます。このページの手順に従って Fluent Bit をセットアップした場合は、以前に実行した kubectl `apply` コマンドから Kubernetes マニフェスト YAML ファイルをダウンロードし、変更を加えて修正し、クラスターに再適用できます。または、Amazon CloudWatch Observability EKS アドオンまたは Helm チャートを使用している場合、アドオンの高度な設定または Helm チャートを使用して Fluent Bit 設定を管理する方法については、「[(オプション) その他の設定](install-CloudWatch-Observability-EKS-addon.md#install-CloudWatch-Observability-EKS-addon-configuration)」を参照してください。
Fluent Bit アプリケーションログを停止するには、`Fluent Bit configuration` ファイルから次のセクションを削除します。
```
[INPUT]
Name tail
Tag application.*
Path /var/log/containers/fluent-bit*
Parser docker
DB /fluent-bit/state/flb_log.db
Mem_Buf_Limit 5MB
Skip_Long_Lines On
Refresh_Interval 10
```
CloudWatch に送信されたログイベントに Kubernetes メタデータが追加されないように削除するには、Fluent Bit 設定の `application-log.conf` セクションに以下のフィルターを追加します。** および同様のフィールドを実際のメタデータ識別子に置き換えます。
```
application-log.conf: |
[FILTER]
Name nest
Match application.*
Operation lift
Nested_under kubernetes
Add_prefix Kube.
[FILTER]
Name modify
Match application.*
Remove Kube.
Remove Kube.
Remove Kube.
[FILTER]
Name nest
Match application.*
Operation nest
Wildcard Kube.*
Nested_under kubernetes
Remove_prefix Kube.
```
## トラブルシューティング
正しいリージョンで確認しているが、これらのロググループが表示されない場合は、Fluent Bit daemonSet ポッドのログでエラーを確認します。
次のコマンドを実行してステータスが `Running` であることを確認します。
```
kubectl get pods -n amazon-cloudwatch
```
IAM アクセス許可に関連するエラーがログにある場合は、クラスターノードにアタッチされた IAM ロールを確認します。Amazon EKS クラスターの実行に必要なアクセス許可の詳細については、*Amazon EKS ユーザーガイド*の「[Amazon EKS IAM ポリシー、ロール、アクセス許可](https://docs.aws.amazon.com/eks/latest/userguide/IAM_policies.html)」を参照してください。
ポッドのステータスが `CreateContainerConfigError` である場合は、次のコマンドを実行して正確なエラーを取得します。
```
kubectl describe pod pod_name -n amazon-cloudwatch
```
## ダッシュボード
実行中の各プラグインのメトリクスをモニターリングするダッシュボードを作成できます。入力バイトと出力バイト、レコード処理レート、出力エラー、およびリトライ/失敗率のデータを表示できます。これらのメトリクスを表示するには、Amazon EKS と Kubernetes クラスターの Prometheus メトリクスコレクションを使用して CloudWatch エージェントをインストールする必要があります。ダッシュボードの設定方法の詳細については、「[Amazon EKS および Kubernetes クラスターに Prometheus メトリクスコレクションを使用して CloudWatch エージェントをインストールするAmazon EKS および Kubernetes クラスターに Prometheus メトリクスコレクションを使用して CloudWatch エージェントをインストールする](ContainerInsights-Prometheus-Setup.md)」を参照してください。
**注記**
このダッシュボードを設定する前に、Prometheus メトリクスの Container Insights を設定する必要があります。詳細については、「[Container Insights の Prometheus メトリクスのモニターリング](ContainerInsights-Prometheus.md)」を参照してください。
**Fluent Bit Prometheus メトリクスのダッシュボードを作成するには**
1. 環境変数を作成し、次の行の右側の値をデプロイと一致するように置き換えます。
```
DASHBOARD_NAME=your_cw_dashboard_name
REGION_NAME=your_metric_region_such_as_us-west-1
CLUSTER_NAME=your_kubernetes_cluster_name
```
1. 次のコマンドを実行して、ダッシュボードを作成します。
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_cloudwatch_dashboards/fluent-bit/cw_dashboard_fluent_bit.json \
| sed "s/{{YOUR_AWS_REGION}}/${REGION_NAME}/g" \
| sed "s/{{YOUR_CLUSTER_NAME}}/${CLUSTER_NAME}/g" \
| xargs -0 aws cloudwatch put-dashboard --dashboard-name ${DASHBOARD_NAME} --dashboard-body
```
# (オプション) Amazon EKS コントロールプレーンのログ記録の設定
Amazon EKS を使用している場合は、オプションで Amazon EKS コントロールプレーンのログ記録を有効にして、Amazon EKS コントロールプレーンから CloudWatch Logs に監査ログと診断ログを直接提供することができます。詳細については、「[Amazon EKS コントロールプレーンのログ記録](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)」を参照してください。
# (オプション) 大規模なクラスターで Use\$1Kubelet 機能を有効にします。
デフォルトでは、FluentBit Kubernetes プラグインでは Use\$1Kubelet 機能は無効になっています。この機能を有効にすると、API サーバーへのトラフィックが減少し、API サーバーがボトルネックになる問題を軽減できます。大規模なクラスターに対してこの機能を有効にすることをお勧めします。
Use\$1Kubelet を有効にするには、まずノードとノード/プロキシのアクセス許可を clusterRole 設定に追加します。
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: fluent-bit-role
rules:
- nonResourceURLs:
- /metrics
verbs:
- get
- apiGroups: [""]
resources:
- namespaces
- pods
- pods/logs
- nodes
- nodes/proxy
verbs: ["get", "list", "watch"]
```
DaemonSet 設定では、この機能にはホストネットワークアクセスが必要です。`amazon/aws-for-fluent-bit` のイメージバージョンが 2.12.0 以降か、Fluent Bit のイメージバージョンが 1.7.2 以降である必要があります。
```
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluent-bit
namespace: amazon-cloudwatch
labels:
k8s-app: fluent-bit
version: v1
kubernetes.io/cluster-service: "true"
spec:
selector:
matchLabels:
k8s-app: fluent-bit
template:
metadata:
labels:
k8s-app: fluent-bit
version: v1
kubernetes.io/cluster-service: "true"
spec:
containers:
- name: fluent-bit
image: amazon/aws-for-fluent-bit:2.19.0
imagePullPolicy: Always
env:
- name: AWS_REGION
valueFrom:
configMapKeyRef:
name: fluent-bit-cluster-info
key: logs.region
- name: CLUSTER_NAME
valueFrom:
configMapKeyRef:
name: fluent-bit-cluster-info
key: cluster.name
- name: HTTP_SERVER
valueFrom:
configMapKeyRef:
name: fluent-bit-cluster-info
key: http.server
- name: HTTP_PORT
valueFrom:
configMapKeyRef:
name: fluent-bit-cluster-info
key: http.port
- name: READ_FROM_HEAD
valueFrom:
configMapKeyRef:
name: fluent-bit-cluster-info
key: read.head
- name: READ_FROM_TAIL
valueFrom:
configMapKeyRef:
name: fluent-bit-cluster-info
key: read.tail
- name: HOST_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: HOSTNAME
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: metadata.name
- name: CI_VERSION
value: "k8s/1.3.8"
resources:
limits:
memory: 200Mi
requests:
cpu: 500m
memory: 100Mi
volumeMounts:
# Please don't change below read-only permissions
- name: fluentbitstate
mountPath: /var/fluent-bit/state
- name: varlog
mountPath: /var/log
readOnly: true
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
- name: fluent-bit-config
mountPath: /fluent-bit/etc/
- name: runlogjournal
mountPath: /run/log/journal
readOnly: true
- name: dmesg
mountPath: /var/log/dmesg
readOnly: true
terminationGracePeriodSeconds: 10
hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet
volumes:
- name: fluentbitstate
hostPath:
path: /var/fluent-bit/state
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
- name: fluent-bit-config
configMap:
name: fluent-bit-config
- name: runlogjournal
hostPath:
path: /run/log/journal
- name: dmesg
hostPath:
path: /var/log/dmesg
serviceAccountName: fluent-bit
tolerations:
- key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule
- operator: "Exists"
effect: "NoExecute"
- operator: "Exists"
effect: "NoSchedule"
```
Kubernetes プラグインの設定は次のようになります。
```
[FILTER]
Name kubernetes
Match application.*
Kube_URL https://kubernetes.default.svc:443
Kube_Tag_Prefix application.var.log.containers.
Merge_Log On
Merge_Log_Key log_processed
K8S-Logging.Parser On
K8S-Logging.Exclude Off
Labels Off
Annotations Off
Use_Kubelet On
Kubelet_Port 10250
Buffer_Size 0
```
# Amazon EKS および Kubernetes での Container Insights の更新または削除
これらのセクションのステップを使用して、CloudWatch エージェントコンテナイメージを更新するか、Container Insights を Amazon EKS または Kubernetes クラスターから削除します。
**Topics**
+ [CloudWatch の Amazon EKS 向けにオブザーバビリティが強化された Container Insights へのアップグレード](Container-Insights-upgrade-enhanced.md)
+ [CloudWatch エージェントコンテナイメージの更新](ContainerInsights-update-image.md)
+ [Container Insights の CloudWatch エージェントと Fluent Bit の削除](ContainerInsights-delete-agent.md)
# CloudWatch の Amazon EKS 向けにオブザーバビリティが強化された Container Insights へのアップグレード
**重要**
Amazon EKS クラスターに Container Insights をアップグレードまたはインストールする場合は、このセクションの手順を使用するのではなく Amazon CloudWatch Observability EKS アドオンを使用してインストールすることをお勧めします。また、高速コンピューティングメトリクスを取得するには、Amazon CloudWatch Observability EKS アドオンを使用する必要があります。詳細と手順については、[Amazon CloudWatch Observability EKS アドオンのクイックスタート](Container-Insights-setup-EKS-addon.md) を参照してください。
Amazon EKS 向けにオブザーバビリティが強化された Container Insights は、Container Insights の最新バージョンです。Amazon EKS を実行しているクラスターから詳細なメトリクスが収集され、キュレーションされたすぐに使用できるダッシュボードが提供されます。これにより、アプリケーションやインフラストラクチャテレメトリを掘り下げて調べることができます。Container Insights のこのバージョンについての詳細は、「[Amazon EKS 向けに拡張オブザーバビリティを備えた Container Insights](container-insights-detailed-metrics.md)」を参照してください。
Amazon EKS クラスターに Container Insights の元のバージョンをインストールしており、オブザーバビリティが強化された新しいバージョンにアップグレードしたい場合は、このセクションの手順に従ってください。
**重要**
このセクションに記載されている手順を完了する前に、cert-manager を含む前提条件を確認しておく必要があります。詳細については、「[CloudWatch エージェントオペレーターと Fluent Bit を使用したクイックスタート](Container-Insights-setup-EKS-quickstart.md#Container-Insights-setup-EKS-quickstart-FluentBit)」を参照してください。
**Amazon EKS 向けにオブザーバビリティが強化された Container Insights にAmazon EKS クラスターをアップグレードするには**
1. 次のコマンドを入力して、CloudWatch エージェントオペレーターをインストールします。*my-cluster-name* は Amazon EKS または Kubernetes クラスターの名前に置き換え、*my-cluster-region* はログが発行されるリージョンの名前に置き換えます。AWS アウトバウンドデータ転送コストを削減するために、クラスターがデプロイされているのと同じリージョンを使用することをお勧めします。
```
ClusterName=my-cluster-name
RegionName=my-cluster-region
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-operator-rendered.yaml | sed 's/{{cluster_name}}/'${ClusterName}'/g;s/{{region_name}}/'${RegionName}'/g' | kubectl apply -f -
```
リソースの競合によって生じるエラーが見られる場合は、CloudWatch エージェントと Fluent Bit で ServiceAccount、ClusterRole、ClusterRoleBinding などの関連コンポーネントがクラスターに既にインストールされていることが原因である可能性があります。CloudWatch エージェントオペレーターによって CloudWatch エージェントとその関連コンポーネントがインストールされるときに内容の変更が検出されると、デフォルトではインストールまたは更新が失敗します。これによって、クラスター上にあるリソースの状態が上書きされることを防いでいます。クラスターに以前にインストールしていた Container Insights セットアップを含む既存の CloudWatch エージェントをすべて削除してから、CloudWatch エージェントオペレーターをインストールすることをお勧めします。
1. (オプション) 既存のカスタム Fluent Bit 設定を適用するには、Fluent Bit daemonset に関連付けられている configmap を更新する必要があります。CloudWatch エージェントオペレーターは Fluent Bit 用のデフォルト設定を提供し、デフォルト設定は必要に応じて上書きまたは変更できます。カスタム設定を適用するには、以下の手順に従います。
1. 次のコマンドを入力して、既存の設定を開きます。
```
kubectl edit cm fluent-bit-config -n amazon-cloudwatch
```
1. ファイルに変更を加え、`:wq` と入力してファイルを保存し、編集モードを終了します。
1. 次のコマンドを入力して Fluent Bit を再起動します。
```
kubectl rollout restart ds fluent-bit -n amazon-cloudwatch
```
# CloudWatch エージェントコンテナイメージの更新
**重要**
Amazon EKS クラスターに Container Insights をアップグレードまたはインストールする場合は、このセクションの手順を使用するのではなく Amazon CloudWatch Observability EKS アドオンを使用してインストールすることをお勧めします。また、高速コンピューティングメトリクスを取得するには、Amazon CloudWatch Observability EKS アドオンまたは CloudWatch エージェントオペレーターを使用する必要があります。詳細と手順については、[Amazon CloudWatch Observability EKS アドオンのクイックスタート](Container-Insights-setup-EKS-addon.md) を参照してください。
コンテナイメージを最新バージョンに更新する必要がある場合は、このセクションの手順を使用します。
**コンテナイメージを更新するには**
1. 次のコマンドを入力して、`amazoncloudwatchagent` カスタマーリソース定義 (CRD) が既に存在しているかどうかを確認します。
```
kubectl get crds amazoncloudwatchagents.cloudwatch.aws.amazon.com -n amazon-cloudwatch
```
このコマンドで CRD がないというエラーが返される場合、クラスターには、CloudWatch エージェントオペレーターで設定された Amazon EKS 向けにオブザーバビリティが強化された Container Insights がありません。この場合は、[CloudWatch の Amazon EKS 向けにオブザーバビリティが強化された Container Insights へのアップグレード](Container-Insights-upgrade-enhanced.md) を参照してください。
1. 次のコマンドを入力して、最新の `cwagent-version.yaml` ファイルを適用します。
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-version.yaml | kubectl apply -f -
```
# Container Insights の CloudWatch エージェントと Fluent Bit の削除
Amazon EKS 向けの CloudWatch Observability アドオンのインストールを使用して Container Insights をインストールした場合、次のコマンドを入力して Container Insights と CloudWatch エージェントを削除できます。
**注記**
Amazon EKS アドオンは Windows ワーカーノードで Container Insights をサポートするようになりました。Amazon EKS アドオンを削除すると、Windows 用の Container Insights も削除されます。
```
aws eks delete-addon —cluster-name my-cluster —addon-name amazon-cloudwatch-observability
```
そうでない場合、CloudWatch エージェントおよび Fluent Bit に関連するすべてのリソースを削除するには、次のコマンドを入力します。このコマンドで、*My\$1Cluster\$1Name* はお使いの Amazon EKS または Kubernetes クラスターの名前、*My\$1Region* はログが発行されるリージョンの名前です。
```
ClusterName=My_Cluster_Name
RegionName=My-Region
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-operator-rendered.yaml | sed 's/{{cluster_name}}/'${ClusterName}'/g;s/{{region_name}}/'${RegionName}'/g' | kubectl delete -f -
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/main/k8s-quickstart/cwagent-custom-resource-definitions.yaml | kubectl delete -f -
```
# RedHat OpenShift on AWS (ROSA) での Container Insights の設定
オブザーバビリティが強化された CloudWatch Container Insights は、RedHat OpenShift on AWS (ROSA) をサポートしています。このバージョンは、ROSA クラスターの強化されたオブザーバビリティに対応しています。CloudWatch エージェントオペレーター Helm チャートをインストールすると、Container Insights はクラスターレベルから環境内のコンテナレベルまで詳細なインフラストラクチャテレメトリを自動的に収集します。そして、このパフォーマンスデータが厳選されたダッシュボードに表示されるため、オブザーバビリティ設定の手間が省けます。
**注記**
RedHat for OpenShift on AWS (ROSA) の場合、Helm チャートを使用して CloudWatch エージェントオペレータをインストールすると、CloudWatch エージェントもデフォルトで有効になり、Application Signals 用に計測されたアプリケーションからのメトリクスとトレースの両方を受信できるようになります。もしカスタム設定ルールを渡したい場合は、[(オプション) その他の設定](install-CloudWatch-Observability-EKS-addon.md#install-CloudWatch-Observability-EKS-addon-configuration) に記載する (オプション) [追加設定] で説明されているように、Helm チャートを使用してカスタムエージェント設定を渡すことでカスタム設定ルールを渡すことができます。
**RedHat OpenShift on AWS (ROSA) クラスターにオブザーバビリティが強化された Container Insights をインストールするには**
1. 必要に応じて、Helm をインストールします。詳細については、Helm ドキュメントの「[クイックスタートガイド](https://helm.sh/docs/intro/quickstart/)」を参照してください。
1. 次のコマンドを入力して、CloudWatch エージェントオペレーターをインストールします。*my-cluster-name* をクラスターの名前に置き換え、*my-cluster-region* をクラスターが実行されるリージョンに置き換えます。
```
helm repo add aws-observability https://aws-observability.github.io/helm-charts
helm repo update aws-observability
helm install --wait --create-namespace \
--namespace amazon-cloudwatch amazon-cloudwatch-observability \
aws-observability/amazon-cloudwatch-observability \
--set clusterName=my-cluster-name \
--set region=my-cluster-region \
--set k8sMode=ROSA
```
1. [Amazon CloudWatch Observability EKS アドオンまたは Helm チャートを使用して CloudWatch エージェントをインストールする](install-CloudWatch-Observability-EKS-addon.md) のオプション 1、オプション 2、またはオプション 3 の手順に従って、エージェントオペレータの承認を設定します。
# Container Insights メトリクスの表示
Container Insights を設定してメトリクスを収集したら、CloudWatch コンソールでそれらのメトリクスを表示できます。
Container Insights のメトリクスがダッシュボードに表示されるようにするには、Container Insights のセットアップを完了する必要があります。詳細については、「[Container Insights の設定](deploy-container-insights.md)」を参照してください。
この手順では、収集したログデータから Container Insights が自動的に生成するメトリクスを表示する方法について説明します。このセクションの残りの部分では、データについてさらに詳しく把握し、 CloudWatch Logs Insights を使用して、より詳細なレベルでより多くのメトリクスを表示する方法について説明します。
**Container Insights のメトリクスを表示するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、**[インサイト]**、**[Contributor Insights]** の順に選択します。
1. 上部近くにあるドロップダウンボックスを使用して、表示するリソースのタイプと特定のリソースを選択します。
Container Insights が収集する任意のメトリクスに CloudWatch アラームを設定できます。詳細については、[Amazon CloudWatch でのアラームの使用](CloudWatch_Alarms.md)を参照してください。
**注記**
コンテナ化されたアプリケーションをモニターリングするように CloudWatch Application Insights を既に設定している場合は、Container Insights ダッシュボードの下に Application Insights ダッシュボードが表示されます。Application Insights をまだ有効にしていない場合は、Container Insights ダッシュボードのパフォーマンスビューの下の **[Auto-configure Application Insights]** (Application Insights の自動設定) を選択して有効にできます。
Application Insights とコンテナ化されたアプリケーションの詳細については、「[Amazon ECS および Amazon EKS リソースのモニターリングで Application Insights を有効にする](appinsights-setting-up-console.md#appinsights-container-insights)」を参照してください。
## 寄与度が上位の要素の表示
Container Insights によるパフォーマンスモニターリングの一部のビューでは、メモリまたは CPU、または最近アクティブにされたリソース別に、寄与度が高い要素を表示することもできます。これは、ページの上部近くにあるドロップダウンボックスで、次のいずれかのダッシュボードを選択すると表示されます。
+ ECS サービス
+ ECS タスク
+ EKS 名前空間
+ EKS サービス
+ EKS ポッド
これらのリソースタイプから 1 つを表示すると、初期状態では CPU 使用率でソートされた表がページの下部に表示されます。この表は、メモリの使用量または最近のアクティビティでソートするように変更できます。表内の 1 つの行の詳細を表示するには、その行の横にあるチェックボックスをオンにし、[**アクション**] をクリックします。その後で、開いた [**アクション**] メニューからオプションの 1 つを選択します。
## CloudWatch Logs Insights を使用して Container Insights データを表示する
Container Insights は、[埋め込みメトリクス形式](CloudWatch_Embedded_Metric_Format.md)を使用して、パフォーマンスログイベントでメトリクスを収集します。ログは CloudWatch Logs に保存されます。CloudWatch は、CloudWatch コンソールで表示できるログから複数のメトリクスを自動的に生成します。また、CloudWatch Logs Insight クエリを使用して収集されるパフォーマンスデータをより深く分析することもできます。
CloudWatch Logs Insights の詳細については、「[CloudWatch Logs Insights を使用したログデータの分析](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)」を参照してください。クエリで使用できるログフィールドの詳細については、「[Amazon EKS および Kubernetes の Container Insights パフォーマンスログイベント](Container-Insights-reference-performance-logs-EKS.md)」を参照してください。
**CloudWatch Logs Insights を使用してコンテナメトリクスデータをクエリするには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、**[ログ]**、**[Logs Insights]** を選択します。
画面の上部にクエリエディタがあります。CloudWatch Logs Insights を初めて開くと、このボックスにデフォルトクエリが表示されます。デフォルトでは、最新の 20 件のログイベントが返されます。
1. クエリエディタの上部にあるボックスで、クエリの対象となるいずれかの Container Insights ロググループを選択します。次の例のクエリが機能するためには、ロググループ名が **performance** で終わる必要があります。
ロググループを選択すると、CloudWatch Logs Insights はロググループのデータのフィールドを自動的に検出し、右側のペインの [**Discovered fields (検出済みフィールド)**] に表示します。また、このロググループのログイベントを時間の経過に従って棒グラフで表示します。この棒グラフは、表に示されるイベントだけでなく、クエリと時間範囲に一致するロググループ内のイベントの分布を示します。
1. クエリエディタで、デフォルトのクエリを次のクエリで置き換え、[**クエリの実行**] を選択します。
```
STATS avg(node_cpu_utilization) as avg_node_cpu_utilization by NodeName
| SORT avg_node_cpu_utilization DESC
```
このクエリでは、ノードの平均 CPU 使用率でソートされたノードのリストが表示されます。
1. 別の例を試すには、このクエリを別のクエリに置き換え、[**Run query (クエリの実行)**] を選択します。その他のサンプルクエリについては、このページの後半で示します。
```
STATS avg(number_of_container_restarts) as avg_number_of_container_restarts by PodName
| SORT avg_number_of_container_restarts DESC
```
このクエリでは、コンテナ再起動の平均数によってソートされたポッドのリストが表示されます。
1. 別のクエリを試す場合は、画面の右にあるリストのインクルードフィールドを選択できます。クエリ構文の詳細については、「[CloudWatch Logs Insights クエリ構文](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html)」を参照してください。
**リソースのリストを表示するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、[**Resources (リソース)**] を選択します。
1. デフォルトのビューは、Container Insights によってモニターリングされているリソースと、それらのリソースに対して設定したアラームのリストです。リソースの視覚的なマップを表示するには、[**Map view (マップビュー)**] を選択します。
1. マップビューから、マップ内の任意のリソースの上にポインタを置くと、そのリソースに関する基本的なメトリクスを表示できます。任意のリソースを選択して、そのリソースに関するより詳細なグラフを表示できます。
## ユースケース: Amazon ECS コンテナでのタスクレベルのメトリクスの表示
次の例は、CloudWatch Logs Insights を使用して Container Insights のログをより詳しく調べる方法を示しています。他の例については、ブログ記事「[Amazon ECS 向け Amazon CloudWatch Container Insights のご紹介](https://aws.amazon.com/blogs/mt/introducing-container-insights-for-amazon-ecs/)」をご覧ください。
Container Insights は、タスクレベルの詳細度でメトリクスを自動的に生成しません。次のクエリは、CPU およびメモリ使用量のタスクレベルのメトリクスを表示します。
```
stats avg(CpuUtilized) as CPU, avg(MemoryUtilized) as Mem by TaskId, ContainerName
| sort Mem, CPU desc
```
## Container Insights のその他のサンプルクエリ
**コンテナの再起動の平均回数順にソートされるポッドのリスト**
```
STATS avg(number_of_container_restarts) as avg_number_of_container_restarts by PodName
| SORT avg_number_of_container_restarts DESC
```
**リクエストされたポッドと実行中のポッドの比較**
```
fields @timestamp, @message
| sort @timestamp desc
| filter Type="Pod"
| stats min(pod_number_of_containers) as requested, min(pod_number_of_running_containers) as running, ceil(avg(pod_number_of_containers-pod_number_of_running_containers)) as pods_missing by kubernetes.pod_name
| sort pods_missing desc
```
**クラスターノードの障害数**
```
stats avg(cluster_failed_node_count) as CountOfNodeFailures
| filter Type="Cluster"
| sort @timestamp desc
```
**コンテナ名別のアプリケーションログエラー**
```
stats count() as countoferrors by kubernetes.container_name
| filter stream="stderr"
| sort countoferrors desc
```
# Container Insights により収集されるメトリクス
Container Insights は、Amazon ECS と Amazon ECS 上の AWS Fargate で 1 つのメトリクスセットを収集し、Amazon EKS、Amazon EKS 上の AWS Fargate、RedHat OpenShift on AWS (ROSA)、および Kubernetes では別のセットを収集します。
メトリクスは、コンテナタスクがしばらく実行されるまで表示されません。
**Topics**
+ [Amazon ECS 用にオブザーバビリティメトリクスが強化された Container Insights](Container-Insights-enhanced-observability-metrics-ECS.md)
+ [「Amazon ECS Container Insights メトリクス」](Container-Insights-metrics-ECS.md)
+ [Amazon EKS およびオブザーバビリティが強化された Kubernetes Container Insights](Container-Insights-metrics-enhanced-EKS.md)
+ [Amazon EKS および Kubernetes Container Insights のメトリクス](Container-Insights-metrics-EKS.md)
+ [Container Insights パフォーマンスログリファレンス](Container-Insights-reference.md)
+ [Container Insights の Prometheus メトリクスのモニターリング](ContainerInsights-Prometheus.md)
+ [Application Insights との統合](container-insights-appinsights.md)
+ [Container Insights 内での Amazon ECS ライフサイクルイベントの表示](container-insights-ECS-lifecycle-events.md)
+ [Container Insights のトラブルシューティング](ContainerInsights-troubleshooting.md)
+ [独自の CloudWatch エージェント Docker イメージの構築](ContainerInsights-build-docker-image.md)
+ [コンテナへの他の CloudWatch エージェント機能のデプロイ](ContainerInsights-other-agent-features.md)
# Amazon ECS 用にオブザーバビリティメトリクスが強化された Container Insights
オブザーバビリティが強化された Container Insights は、コンテナ化されたワークロードをより詳細に可視化します。具体的な内容は、以下のとおりです。
+ タスクレベルとコンテナレベルの両方でのより高いメトリクス詳細度
+ モニタリングおよびトラブルシューティング機能の改善
+ CloudWatch Logs との統合により、以下を実現:
+ メトリクスの異常とログエントリの関連付け
+ より迅速な根本原因分析の実行
+ 複雑なコンテナの問題の解決時間の短縮
**ユースケース**
オブザーバビリティが強化された Container Insights は、標準の Container Insights の機能を拡張します。以下のユースケースが可能となります。
+ **タスクレベルのトラブルシューティング** – タスクレベルでパフォーマンスのボトルネックを特定します。タスクレベルのメトリクスを分析し、リザーブドリソースと比較して、タスクに十分な処理能力があるかどうかを判断します
+ **コンテナレベルのリソース最適化** – 予約レベルに対する使用率を追跡して、リソースに制約があるか、過剰にプロビジョニングされているコンテナを特定します
+ **コンテナのヘルス評価** – 再起動数と状態遷移をモニタリングして、介入が必要な不安定なコンテナを検出します
+ **アプリケーションパフォーマンスのモニタリング** – アプリケーションが相互に通信する方法を追跡し、リソースの使用状況パターンをモニタリングして、データストレージのパフォーマンスを最適化します
+ **運用モニタリング** – デプロイをモニタリングし、ブルーデプロイまたはグリーンデプロイのタスクセットを追跡し、サービスメトリクスによるプラットフォームの状態を維持します
Amazon ECS メトリクスの詳細については、「[Amazon ECS サービス使用率メトリクスのユースケース](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_utilization-metrics-explanation.html)」を参照してください。また、オブザーバビリティが強化された Container Insights の詳細については、「[Amazon ECS 用にオブザーバビリティメトリクスが強化された Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-enhanced-observability-metrics-ECS.html)」を参照してください。
Container Insights は、すべてのタスクのデータを平均化することで、クラスター、サービス、およびデーモン全体の統計も表示します。これにより、サービスとデーモンの状態をより詳細に把握でき、環境モニタリングとキャパシティプランニングの両方に役立ちます。
**注記**
Amazon ECS マネージドデーモンメトリクスは、サービスメトリクスと同じ `ECS/ContainerInsights` 名前空間および同じ `ServiceName` ディメンションを使用します。デーモンメトリクスでは、`ServiceName` ディメンション値は形式 `daemon:daemon-name` を使用します。例えば、`my-daemon` という名前のデーモンには、`daemon:my-daemon` の `ServiceName` ディメンション値があります。`ServiceName` ディメンションを含む以下の表のすべてのメトリクスは、マネージドデーモンにも適用されます。
次の表には、オブザーバビリティが強化された Container Insights が Amazon ECS 用に収集するメトリクスおよびディメンションが一覧表示されます。これらのメトリクスは `ECS/ContainerInsights` 名前空間にあります。詳細については、「[メトリクス](cloudwatch_concepts.md#Metric)」を参照してください。
コンソールで Container Insights メトリクスが表示されない場合、オブザーバビリティが強化された Container Insights の設定が完了していることを確認します。オブザーバビリティが強化された Container Insights が完全に設定されるまで、メトリクスは表示されません。詳細については、「[オブザーバビリティが強化された Container Insights の設定](deploy-container-insights-ECS-cluster.md#set-container-insights-ECS-cluster-enhanced)」を参照してください。
次のメトリクスはすべての起動タイプに利用できます。
| メトリクス名 | ディメンション | 説明 |
| --- | --- | --- |
| `ContainerInstanceCount` | `ClusterName` | クラスターに登録されている Amazon ECS エージェントを実行している EC2 インスタンスの数。 このメトリクスは、クラスターで Amazon ECS タスクが実行されているコンテナインスタンスに対してのみ収集されます。Amazon ECS タスクがない空のコンテナインスタンスについては収集されません。 単位: 数 |
| `ContainerCpuUtilized` | `ClusterName` `ContainerName`, `TaskId`, `ServiceName`, `ClusterName` `ContainerName`, `TaskDefinitionFamily`, `ClusterName`, `TaskId` `TaskDefinitionFamily`, `ClusterName`, `ContainerName` `ServiceName`, `ClusterName`, `ContainerName` | お使いのディメンションセットが指定するリソースのコンテナによって使用される CPU ユニット。 マネージドデーモンにも適用されます。 単位: なし |
| `ContainerCpuReserved` | `ClusterName` `ContainerName`, `TaskId`, `ServiceName`, `ClusterName` `ContainerName`, `TaskDefinitionFamily`, `ClusterName`, `TaskId` `TaskDefinitionFamily`, `ClusterName`, `ContainerName` `ServiceName`, `ClusterName`, `ContainerName` | お使いのディメンションセットが指定するリソースのコンテナによって予約されている CPU ユニット。このメトリクスは、タスクまたはすべてのコンテナレベルなど、タスク定義で定義された CPU 予約に基づいて収集されます。タスク定義で指定されていない場合は、インスタンスの CPU 予約が使用されます。 マネージドデーモンにも適用されます。 単位: なし |
| `ContainerCpuUtilization` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | お使いのディメンションセットが指定するリソースのコンテナによって使用されている CPU ユニットの合計パーセンテージ。 単位: パーセント |
| `ContainerMemoryUtilized` | `ClusterName` `ContainerName`, `TaskId`, `ServiceName`, `ClusterName` `ContainerName`, `TaskDefinitionFamily`, `ClusterName`, `TaskId` `TaskDefinitionFamily`, `ClusterName`, `ContainerName` `ServiceName`, `ClusterName`, `ContainerName` | お使いのディメンションセットが指定するリソースのコンテナによって使用されているメモリ。 マネージドデーモンにも適用されます。 単位: メガバイト |
| `ContainerMemoryReserved` | `ClusterName` `ContainerName`, `TaskId`, `ServiceName`, `ClusterName` `ContainerName`, `TaskDefinitionFamily`, `ClusterName`, `TaskId` `TaskDefinitionFamily`, `ClusterName`, `ContainerName` `ServiceName`, `ClusterName`, `ContainerName` | お使いのディメンションセットが指定するリソースのコンテナによって予約されているメモリ。 このメトリクスは、タスクまたはすべてのコンテナレベルなど、タスク定義で定義されたメモリ予約に基づいて収集されます。タスク定義で指定されていない場合は、インスタンスのメモリ予約が使用されます。 マネージドデーモンにも適用されます。 単位: メガバイト |
| `ContainerMemoryUtilization` | `ClusterName` `ContainerName`, `TaskId`, `ServiceName`, `ClusterName` `ContainerName`, `TaskDefinitionFamily`, `ClusterName`, `TaskId` `TaskDefinitionFamily`, `ClusterName`, `ContainerName` `ServiceName`, `ClusterName`, `ContainerName` | お使いのディメンションセットが指定するリソースのコンテナによって使用されているメモリの合計パーセンテージ。 マネージドデーモンにも適用されます。 単位: パーセント |
| `ContainerNetworkRxBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | お使いのディメンションが指定するコンテナによって受信されるバイト数。このメトリクスは、Docker ランタイムから取得されます。 このメトリクスは、`awsvpc` または `bridge` ネットワークモードを使用するタスクのコンテナでのみ使用できます。 マネージドデーモンにも適用されます。 単位: バイト/秒 |
| `ContainerNetworkTxBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | お使いのディメンションが指定するコンテナによって送信されるバイト数。このメトリクスは、Docker ランタイムから取得されます。 このメトリクスは、`awsvpc` または `bridge` ネットワークモードを使用するタスクのコンテナでのみ使用できます。 マネージドデーモンにも適用されます。 単位: バイト/秒 |
| `ContainerStorageReadBytes` | `ClusterName` `ClusterName`, `ServiceName`, `ContainerName` `ClusterName`, `TaskDefinitionFamily`, `ContainerName` `ClusterName`, `ServiceName`, `TaskId`, `ContainerName` `ClusterName`, `TaskDefinitionFamily`, `TaskId`, `ContainerName` | お使いのディメンションが指定するリソースのコンテナ上のストレージから読み取られるバイト数。これにはストレージデバイスの読み取りバイト数は含まれません。このメトリクスは、Docker ランタイムから取得されます。 マネージドデーモンにも適用されます。 単位: バイト |
| `ContainerStorageWriteBytes` | `ClusterName` `ClusterName`, `ServiceName`, `ContainerName` `ClusterName`, `TaskDefinitionFamily`, `ContainerName` `ClusterName`, `ServiceName`, `TaskId`, `ContainerName` `ClusterName`, `TaskDefinitionFamily`, `TaskId`, `ContainerName` | お使いのディメンションが指定するコンテナのストレージに書き込まれるバイト数。このメトリクスは、Docker ランタイムから取得されます。 マネージドデーモンにも適用されます。 単位: バイト |
| `CpuUtilized` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | 使用しているディメンションセットによって指定されるリソースのタスクにより使用されている CPU ユニット数。 マネージドデーモンにも適用されます。 単位: なし |
| `CpuReserved` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | 使用しているディメンションセットによって指定されるリソースのタスクにより予約されている CPU ユニット数。このメトリクスは、タスクまたはすべてのコンテナレベルなど、タスク定義で定義された CPU 予約に基づいて収集されます。タスク定義で指定されていない場合は、インスタンスの CPU 予約が使用されます。 マネージドデーモンにも適用されます。 単位: なし |
| `DeploymentCount` | `ServiceName`, `ClusterName` | Amazon ECS サービスでのデプロイの数。 単位: 数 |
| `DesiredTaskCount` | `ServiceName`, `ClusterName` | Amazon ECS サービスに必要なタスクの数。 単位: 数 |
| `EBSFilesystemSize` | `ClusterName` ,`TaskDefinitionFamily`, `VolumeName` `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` | 使用しているディメンションで指定されたリソースに割り当てられる Amazon EBS ファイルシステムストレージの合計容量 (GB)。 このメトリクスは、プラットフォームバージョン `1.4.0` を使用する Fargate で実行されている Amazon ECS インフラストラクチャ、またはコンテナエージェントバージョン `1.79.0` 以降を使用する Amazon EC2 インスタンスで実行されるタスクでのみ使用できます。 マネージドデーモンにも適用されます。 単位: ギガバイト (GB) |
| `EBSFilesystemUtilized` | `ClusterName` ,`TaskDefinitionFamily`, `VolumeName` `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` | 使用しているディメンションで指定されたリソースに使用される Amazon EBS ファイルシステムストレージの合計容量 (GB)。 このメトリクスは、プラットフォームバージョン `1.4.0` を使用する Fargate で実行されている Amazon ECS インフラストラクチャ、またはコンテナエージェントバージョン `1.79.0` 以降を使用する Amazon EC2 インスタンスで実行されるタスクでのみ使用できます。 Fargate で実行されるタスクの場合、Fargate は Fargate でのみ使用されるディスク上のスペースを予約します。Fargate が使用するスペースにコストは発生しませんが、`df` のようなツールで使用されるこの追加ストレージが表示されます。 マネージドデーモンにも適用されます。 単位: ギガバイト (GB) |
| `TaskEBSFilesystemUtilization` | `TaskDefinitionFamily`, `ClusterName` `ClusterName`, `ServiceName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `TaskDefinitionFamily`, `ClusterName`, `TaskId` | 使用中のディメンションにより指定されたタスクで使用される Amazon EBS ファイルシステムストレージの割合。 このメトリクスは、プラットフォームバージョン `1.4.0` を使用する Fargate で実行されている Amazon ECS インフラストラクチャ、またはコンテナエージェントバージョン `1.79.0` 以降を使用する Amazon EC2 インスタンスで実行されるタスクでのみ使用できます。 マネージドデーモンにも適用されます。 単位: パーセント |
| EphemeralStorageReserved [1](#ci-enhanced-metrics-ecs-storage-fargate-note) | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | 使用しているディメンションによって指定されたリソースのエフェメラルストレージから予約されたバイト数。エフェメラルストレージは、コンテナルートファイルシステム、およびコンテナイメージとタスク定義で定義されているバインドマウントホストボリュームに使用されます。エフェメラルストレージの容量は、実行中のタスクでは変更できません。 このメトリクスは、Fargate Linux プラットフォームのバージョン 1.4.0 以降で実行されるタスクでのみ使用できます。 マネージドデーモンにも適用されます。 単位: ギガバイト (GB) |
| EphemeralStorageUtilized [1](Container-Insights-metrics-ECS.md#ci-metrics-ecs-storage-fargate-note) | `ClusterName` `ClusterName`, `TaskDefinitionFamily` `ClusterName`, `ServiceName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | 使用しているディメンションで指定されたリソースのエフェメラルストレージから使用されたバイト数。エフェメラルストレージは、コンテナルートファイルシステム、およびコンテナイメージとタスク定義で定義されているバインドマウントホストボリュームに使用されます。エフェメラルストレージの容量は、実行中のタスクでは変更できません。 このメトリクスは、Fargate Linux プラットフォームのバージョン 1.4.0 以降で実行されるタスクでのみ使用できます。 マネージドデーモンにも適用されます。 単位: ギガバイト (GB) |
| `MemoryUtilized` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | 使用しているディメンションセットによって指定されるリソースのタスクにより使用されているメモリ。 マネージドデーモンにも適用されます。 単位: メガバイト |
| `MemoryReserved` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | 使用しているディメンションセットによって指定されるリソースのタスクにより予約されているメモリ。 このメトリクスは、タスクまたはすべてのコンテナレベルなど、タスク定義で定義されたメモリ予約に基づいて収集されます。タスク定義で指定されていない場合は、インスタンスのメモリ予約が使用されます。 マネージドデーモンにも適用されます。 単位: メガバイト |
| `NetworkRxBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | 使用しているディメンションによって指定されたリソースにより受信されるバイト数。このメトリクスは、Docker ランタイムから取得されます。 このメトリクスは、`awsvpc` または `bridge` ネットワークモードを使用するタスクのコンテナでのみ使用できます。 マネージドデーモンにも適用されます。 単位: バイト/秒 |
| `NetworkTxBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | 使用しているディメンションによって指定されたリソースにより送信されるバイト数。このメトリクスは、Docker ランタイムから取得されます。 このメトリクスは、`awsvpc` または `bridge` ネットワークモードを使用するタスクのコンテナでのみ使用できます。 マネージドデーモンにも適用されます。 単位: バイト/秒 |
| `PendingTaskCount` | `ServiceName`, `ClusterName` | 現在、`PENDING` 状態にあるタスクの数。 単位: 数 |
| `RunningTaskCount` | `ServiceName`, `ClusterName` | 現在、`RUNNING` 状態にあるタスクの数。 単位: 数 |
| `RestartCount` | `ClusterName` `ClusterName`, `ServiceName` `ClusterName`, `TaskDefinitionFamily` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` `ClusterName`, `ServiceName`, `ContainerName` `ClusterName`, `ServiceName`, `TaskId`, `ContainerName` `TaskDefinitionFamily`, `ClusterName`, `ContainerName` `TaskDefinitionFamily`, `ClusterName`, `TaskId`, `ContainerName` | Amazon ECS タスク内のコンテナが再起動された回数。 このメトリクスは、再起動ポリシーが有効になっているコンテナのみを対象として収集されます。 マネージドデーモンにも適用されます。 単位: 数 |
| `UnHealthyContainerHealthStatus` | `ClusterName` `ClusterName`, `ServiceName`, `ContainerName` `ClusterName`, `TaskDefinitionFamily`, `ContainerName` `ClusterName`, `ServiceName`, `TaskId`, `ContainerName` `ClusterName`, `TaskDefinitionFamily`, `TaskId`, `ContainerName` | コンテナのヘルスチェックステータスに基づいた異常コンテナの数。ヘルスチェックが異常ステータスを返すと、コンテナは異常と見なされます。 このメトリクスは、タスク定義でヘルスチェックが設定されているコンテナに対してのみ収集されます。 メトリクス値は、コンテナのヘルスステータスが `UNHEALTHY` の場合は 1、ヘルスステータスが `HEALTHY` の場合は 0 です。 単位: 数 |
| `ServiceCount` | `ClusterName` | クラスター内のサービスの数。 単位: 数 |
| `StorageReadBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | 使用しているディメンションによって指定されたリソース内のインスタンスのストレージから読み取られたバイト数。これにはストレージデバイスの読み取りバイト数は含まれません。このメトリクスは、Docker ランタイムから取得されます。 マネージドデーモンにも適用されます。 単位: バイト |
| `StorageWriteBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | 使用しているディメンションによって指定されたリソースのストレージに書き込まれたバイト数。このメトリクスは、Docker ランタイムから取得されます。 マネージドデーモンにも適用されます。 単位: バイト |
| `TaskCount` | `ClusterName` | クラスターで実行されているタスクの数。 単位: 数 |
| `TaskCpuUtilization` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | タスクで使用されている CPU ユニットの合計パーセンテージ。 マネージドデーモンにも適用されます。 単位: パーセント |
| `TaskEphemeralStorageUtilization` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | タスクで使用されているエフェメラルストレージの合計パーセンテージ。 マネージドデーモンにも適用されます。 単位: パーセント |
| `TaskMemoryUtilization` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` `ClusterName`, `ServiceName`, `TaskId` `ClusterName`, `TaskDefinitionFamily`, `TaskId` | タスクで使用されているメモリの合計パーセンテージ。 マネージドデーモンにも適用されます。 単位: パーセント |
| `TaskSetCount` | `ServiceName`, `ClusterName` | サービス内のタスクセットの数。 単位: 数 |
**注記**
`EphemeralStorageReserved` および `EphemeralStorageUtilized` メトリクスは、Fargate Linux プラットフォームのバージョン 1.4.0 以降で実行されるタスクでの使用できます。
Fargate はディスク上のスペースを予約します。スペースは Fargate によってのみ使用されます。これには課金されることはありません。これらのメトリクスには表示されません。ただし、この追加ストレージは、`df` などの他のツールでも確認できます。
「[Amazon ECS で EC2 インスタンスレベルのメトリクスを収集するための CloudWatch エージェントのデプロイ](deploy-container-insights-ECS-instancelevel.md)」の手順を完了して EC2 起動タイプを使用すると、次のメトリクスが利用できるようになります。
| メトリクス名 | ディメンション | 説明 |
| --- | --- | --- |
| `instance_cpu_limit` | `ClusterName` | クラスターの単一 EC2 インスタンスに割り当てることができる CPU ユニットの最大数。 単位: なし |
| `instance_cpu_reserved_capacity` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | クラスター内の単一の EC2 インスタンスで現在予約されている CPU の割合。 単位: パーセント |
| `instance_cpu_usage_total` | `ClusterName` | クラスター内の単一 EC2 インスタンスで使用されている CPU ユニットの数。 単位: なし |
| `instance_cpu_utilization` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | クラスター内の単一の EC2 インスタンスで使用されている CPU ユニットの合計割合。 単位: パーセント |
| `instance_filesystem_utilization` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | クラスター内の単一の EC2 インスタンスで使用されているファイルシステム容量の合計割合。 単位: パーセント |
| `instance_memory_limit` | `ClusterName` | このクラスターの単一 EC2 インスタンスに割り当てることができるメモリの最大量 (バイト単位)。 単位: バイト |
| `instance_memory_reserved_capacity` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | クラスターの単一 EC2 インスタンスで現在予約されているメモリのパーセンテージ。 単位: パーセント |
| `instance_memory_utilization` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | クラスターの単一 EC2 インスタンスで使用されているメモリの合計パーセンテージ。 アプリケーションに Java ZGC ガベージコレクタを使用している場合、このメトリクスが不正確である可能性があります。 単位: パーセント |
| `instance_memory_working_set` | `ClusterName` | クラスターの単一 EC2 インスタンスで使用されているメモリの量 (バイト単位)。 アプリケーションに Java ZGC ガベージコレクタを使用している場合、このメトリクスが不正確である可能性があります。 単位: バイト |
| `instance_network_total_bytes` | `ClusterName` | クラスターの単一 EC2 インスタンスでネットワーク上で送受信される 1 秒あたりの合計バイト数。 単位: バイト/秒 |
| `instance_number_of_running_tasks` | `ClusterName` | クラスターの単一 EC2 インスタンスで実行中のタスクの数。 単位: 数 |
# 「Amazon ECS Container Insights メトリクス」
Container Insights メトリクスは、追加のネットワーク、ストレージ、エフェメラルストレージメトリクスを提供します。これらのメトリクスは、標準の Amazon ECS メトリクスよりも多くの情報を提供します。Container Insights は CloudWatch Logs と統合されます。メトリクスの変更をログエントリと関連付けて、トラブルシューティングを容易にできます。Container Insights は、すべてのタスクのデータを平均化することで、クラスター、サービス、およびデーモン全体の統計も表示します。これにより、サービスとデーモンの状態をより詳細に把握でき、環境モニタリングとキャパシティプランニングの両方に役立ちます。
**ユースケース**
+ **問題の特定とトラブルシューティング** – タスク状態遷移パターンを分析して失敗したデプロイを追跡し、障害ポイントを迅速に特定できるようにします。タスクの起動シーケンスと初期化動作を包括的に調べて設定問題を診断します
+ **クラスターとサービスレベルのヘルス評価** – クラスター全体の平均タスクパフォーマンスを表示します。このアプローチは外れ値をモデレートして、クラスターとサービスのヘルスをより安定的に表示します。これらのインサイトは、極端な値が誤解を招く可能性がある一般的なサービスモニタリングに使用します
+ **サービスの可用性の問題** – 実行中のタスク数メトリクスをモニタリングして、デプロイの失敗を検出します。サービスイベントログをパフォーマンスメトリクスと関連付けて、インフラストラクチャへの影響を理解します。タスクの再起動パターンを追跡して、不安定なサービスやインフラストラクチャの問題を特定します
+ **平均負荷のキャパシティプランニング** – 一般的なタスク動作パターンに基づいてリソース要件を決定し、効果的な長期計画をサポートする一貫したメトリクスを提供し、キャパシティの決定に対する短期間のスパイクの影響を軽減します
+ **追加のメトリクスを提供** – 提供されたメトリクスでは利用できない追加のネットワーク、ストレージ、エフェメラルストレージメトリクスを収集します
Amazon ECS メトリクスの詳細については、「[Amazon ECS サービス使用率メトリクスのユースケース](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_utilization-metrics-explanation.html)」を参照してください。また、オブザーバビリティが強化された Container Insights の詳細については、「[Amazon ECS 用にオブザーバビリティメトリクスが強化された Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-enhanced-observability-metrics-ECS.html)」を参照してください。
**注記**
Amazon ECS マネージドデーモンメトリクスは、サービスメトリクスと同じ `ECS/ContainerInsights` 名前空間および同じ `ServiceName` ディメンションを使用します。デーモンメトリクスでは、`ServiceName` ディメンション値は形式 `daemon:daemon-name` を使用します。例えば、`my-daemon` という名前のデーモンには、`daemon:my-daemon` の `ServiceName` ディメンション値があります。`ServiceName` ディメンションを含む以下の表のすべてのメトリクスは、マネージドデーモンにも適用されます。
以下の表は、Container Insights で Amazon ECS に収集されるメトリクスとディメンションを示しています。これらのメトリクスは `ECS/ContainerInsights` 名前空間にあります。詳細については、「[メトリクス](cloudwatch_concepts.md#Metric)」を参照してください。
コンソールに Container Insights メトリクスが表示されない場合は、Container Insights のセットアップが完了していることを確認します。メトリクスは、Container Insights が完全にセットアップされるまで表示されません。詳細については、「[Container Insights の設定](deploy-container-insights.md)」を参照してください。
「[Amazon ECS での Container Insights のセットアップ](deploy-container-insights-ECS-cluster.md)」の手順を完了すると、次のメトリクスが利用できるようになります。
| メトリクス名 | ディメンション | 説明 |
| --- | --- | --- |
| `ContainerInstanceCount` | `ClusterName` | クラスターに登録されている Amazon ECS エージェントを実行している EC2 インスタンスの数。 このメトリクスは、クラスターで Amazon ECS タスクが実行されているコンテナインスタンスに対してのみ収集されます。Amazon ECS タスクがない空のコンテナインスタンスについては収集されません。 単位: 数 |
| `CpuUtilized` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | 使用しているディメンションセットによって指定されるリソースのタスクにより使用されている CPU ユニット数。 マネージドデーモンにも適用されます。 単位: なし |
| `CpuReserved` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | 使用しているディメンションセットによって指定されるリソースのタスクにより予約されている CPU ユニット数。 このメトリクスは、タスクまたはすべてのコンテナレベルなど、タスク定義で定義された CPU 予約に基づいて収集されます。タスク定義で指定されていない場合は、インスタンスの CPU 予約が使用されます。 マネージドデーモンにも適用されます。 単位: なし |
| `DeploymentCount` | `ServiceName`, `ClusterName` | Amazon ECS サービスでのデプロイの数。 単位: 数 |
| `DesiredTaskCount` | `ServiceName`, `ClusterName` | Amazon ECS サービスに必要なタスクの数。 単位: 数 |
| `EBSFilesystemSize` | `VolumeName`, `TaskDefinitionFamily`, `ClusterName` `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` | 使用しているディメンションで指定されたリソースに割り当てられる Amazon EBS ファイルシステムストレージの合計容量 (GB)。 このメトリクスは、プラットフォームバージョン `1.4.0` を使用する Fargate で実行されている Amazon ECS インフラストラクチャ、またはコンテナエージェントバージョン `1.79.0` 以降を使用する Amazon EC2 インスタンスで実行されるタスクでのみ使用できます。 マネージドデーモンにも適用されます。 単位: ギガバイト (GB) |
| `EBSFilesystemUtilized` | `VolumeName`, `TaskDefinitionFamily`, `ClusterName` `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` | 使用しているディメンションで指定されたリソースに使用される Amazon EBS ファイルシステムストレージの合計容量 (GB)。 このメトリクスは、プラットフォームバージョン `1.4.0` を使用する Fargate で実行されている Amazon ECS インフラストラクチャ、またはコンテナエージェントバージョン `1.79.0` 以降を使用する Amazon EC2 インスタンスで実行されるタスクでのみ使用できます。 Fargate で実行されるタスクの場合、Fargate は Fargate でのみ使用されるディスク上のスペースを予約します。Fargate が使用するスペースにコストは発生しませんが、`df` のようなツールで使用されるこの追加ストレージが表示されます。 マネージドデーモンにも適用されます。 単位: ギガバイト (GB) |
| EphemeralStorageReserved [1](#ci-metrics-ecs-storage-fargate-note) | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | 使用しているディメンションによって指定されたリソースのエフェメラルストレージから予約されたバイト数。エフェメラルストレージは、コンテナルートファイルシステム、およびコンテナイメージとタスク定義で定義されているバインドマウントホストボリュームに使用されます。エフェメラルストレージの容量は、実行中のタスクでは変更できません。 このメトリクスは、Fargate Linux プラットフォームのバージョン 1.4.0 以降で実行されるタスクでのみ使用できます。 マネージドデーモンにも適用されます。 単位: ギガバイト (GB) |
| EphemeralStorageUtilized [1](#ci-metrics-ecs-storage-fargate-note) | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | 使用しているディメンションで指定されたリソースのエフェメラルストレージから使用されたバイト数。エフェメラルストレージは、コンテナルートファイルシステム、およびコンテナイメージとタスク定義で定義されているバインドマウントホストボリュームに使用されます。エフェメラルストレージの容量は、実行中のタスクでは変更できません。 このメトリクスは、Fargate Linux プラットフォームのバージョン 1.4.0 以降で実行されるタスクでのみ使用できます。 マネージドデーモンにも適用されます。 単位: ギガバイト (GB) |
| `InstanceOSFilesystemUtilization` | `CapacityProviderName`, `ClusterName`, `ContainerInstanceId`, `EC2InstanceId` `ClusterName` | OS ボリューム用に使用された合計ディスクスペースの割合。 |
| `InstanceDataFilesystemUtilization` | `CapacityProviderName`, `ClusterName`, `ContainerInstanceId`, `EC2InstanceId` `ClusterName` | データボリューム用に使用された合計ディスクスペースの割合。 |
| `MemoryUtilized` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | 使用しているディメンションセットによって指定されるリソースのタスクにより使用されているメモリ。 アプリケーションに Java ZGC ガベージコレクタを使用している場合、このメトリクスが不正確である可能性があります。 `MemoryUtilized` と `MemoryReserved` は「メガバイト」とマークされますが、実際の単位は MiB (メビバイト) です。 マネージドデーモンにも適用されます。 単位: メガバイト |
| `MemoryReserved` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | 使用しているディメンションセットによって指定されるリソースのタスクにより予約されているメモリ。このメトリクスは、タスクまたはすべてのコンテナレベルなど、タスク定義で定義されたメモリ予約に基づいて収集されます。タスク定義で指定されていない場合は、インスタンスのメモリ予約が使用されます。 マネージドデーモンにも適用されます。 単位: メガバイト `MemoryUtilized` と `MemoryReserved` は「メガバイト」とマークされますが、実際の単位は MiB (メビバイト) です。 |
| `NetworkRxBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | 使用しているディメンションによって指定されたリソースにより受信されるバイト数。このメトリクスは、Docker ランタイムから取得されます。 このメトリクスは、`awsvpc` または `bridge` ネットワークモードを使用するタスクのコンテナでのみ使用できます。 マネージドデーモンにも適用されます。 単位: バイト/秒 |
| `NetworkTxBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | 使用しているディメンションによって指定されたリソースにより送信されるバイト数。このメトリクスは、Docker ランタイムから取得されます。 このメトリクスは、`awsvpc` または `bridge` ネットワークモードを使用するタスクのコンテナでのみ使用できます。 マネージドデーモンにも適用されます。 単位: バイト/秒 |
| `PendingTaskCount` | `ServiceName`, `ClusterName` | 現在、`PENDING` 状態にあるタスクの数。 単位: 数 |
| `RunningTaskCount` | `ServiceName`, `ClusterName` | 現在、`RUNNING` 状態にあるタスクの数。 単位: 数 |
| `RestartCount` | `ClusterName` `ClusterName`, `ServiceName` `ClusterName`, `TaskDefinitionFamily` | Amazon ECS タスク内のコンテナが再起動された回数。 このメトリクスは、再起動ポリシーが有効になっているコンテナのみを対象として収集されます。 マネージドデーモンにも適用されます。 単位: 数 |
| `ServiceCount` | `ClusterName` | クラスター内のサービスの数。 単位: 数 |
| `StorageReadBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | 使用しているディメンションによって指定されたリソース内のインスタンスのストレージから読み取られたバイト数。これにはストレージデバイスの読み取りバイト数は含まれません。このメトリクスは、Docker ランタイムから取得されます。 マネージドデーモンにも適用されます。 単位: バイト |
| `StorageWriteBytes` | `TaskDefinitionFamily`, `ClusterName` `ServiceName`, `ClusterName` `ClusterName` | 使用しているディメンションによって指定されたリソースのストレージに書き込まれたバイト数。このメトリクスは、Docker ランタイムから取得されます。 マネージドデーモンにも適用されます。 単位: バイト |
| `TaskCount` | `ClusterName` | クラスターで実行されているタスクの数。 単位: 数 |
| `TaskSetCount` | `ServiceName`, `ClusterName` | サービス内のタスクセットの数。 単位: 数 |
**注記**
`EphemeralStorageReserved` および `EphemeralStorageUtilized` メトリクスは、Fargate Linux プラットフォームのバージョン 1.4.0 以降で実行されるタスクでの使用できます。
Fargate はディスク上のスペースを予約します。スペースは Fargate によってのみ使用されます。これには課金されることはありません。これらのメトリクスには表示されません。ただし、この追加ストレージは、`df` などの他のツールでも確認できます。
「[Amazon ECS で EC2 インスタンスレベルのメトリクスを収集するための CloudWatch エージェントのデプロイ](deploy-container-insights-ECS-instancelevel.md)」のステップを完了すると、以下のメトリクスが使用できるようになります
| メトリクス名 | ディメンション | 説明 |
| --- | --- | --- |
| `instance_cpu_limit` | `ClusterName` | このクラスター内の単一の EC2 インスタンスに割り当てることができる CPU ユニットの最大数。 単位: なし |
| `instance_cpu_reserved_capacity` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | クラスター内の単一の EC2 インスタンスで現在予約されている CPU の割合。 単位: パーセント |
| `instance_cpu_usage_total` | `ClusterName` | クラスター内の単一 EC2 インスタンスで使用されている CPU ユニットの数。 単位: なし |
| `instance_cpu_utilization` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | クラスター内の単一の EC2 インスタンスで使用されている CPU ユニットの合計割合。 単位: パーセント |
| `instance_filesystem_utilization` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | クラスター内の単一の EC2 インスタンスで使用されているファイルシステム容量の合計割合。 単位: パーセント |
| `instance_memory_limit` | `ClusterName` | このクラスター内の単一の EC2 インスタンスに割り当てることができるメモリの最大量（バイト単位）。 単位: バイト |
| `instance_memory_reserved_capacity` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | クラスター内の単一の EC2 インスタンスで現在予約されているメモリの割合。 単位: パーセント |
| `instance_memory_utilization` | `ClusterName` `InstanceId`, `ContainerInstanceId`, `ClusterName` | クラスター内の単一の EC2 インスタンスで使用されているメモリの合計割合。 アプリケーションに Java ZGC ガベージコレクタを使用している場合、このメトリクスが不正確である可能性があります。 単位: パーセント |
| `instance_memory_working_set` | `ClusterName` | クラスター内の単一の EC2 インスタンスで使用されているメモリの量（バイト単位）。 アプリケーションに Java ZGC ガベージコレクタを使用している場合、このメトリクスが不正確である可能性があります。 単位: バイト |
| `instance_network_total_bytes` | `ClusterName` | クラスター内の単一の EC2 インスタンスでネットワーク上で送受信された 1 秒あたりの合計バイト数。 単位: バイト/秒 |
| `instance_number_of_running_tasks` | `ClusterName` | クラスター内の単一の EC2 インスタンスで実行中のタスクの数。 単位: 数 |
# Amazon EKS およびオブザーバビリティが強化された Kubernetes Container Insights
次の表には、オブザーバビリティが強化された Container Insights が Amazon EKS および Kubernetes 用に収集するメトリクスおよびディメンションについて一覧表示されます。これらのメトリクスは `ContainerInsights` 名前空間にあります。詳細については、「[メトリクス](cloudwatch_concepts.md#Metric)」を参照してください。
コンソールでオブザーバビリティメトリクスが強化された Container Insights が表示されない場合、オブザーバビリティが強化された Container Insights の設定が完了していることを確認します。オブザーバビリティが強化された Container Insights が完全に設定されるまで、メトリクスは表示されません。詳細については、「[Container Insights の設定](deploy-container-insights.md)」を参照してください。
Amazon EKS アドオンのバージョン 1.5.0 以降、または CloudWatch エージェントのバージョン 1.300035.0 を使用している場合、次の表に示されているほとんどのメトリクスは Linux ノードと Windows ノードの両方で収集されます。Windows で収集されないメトリクスを確認するには、表の「**メトリクス名**」列を参照してください。
クラスターおよびサービスレベルで集約されたメトリクスを配信する以前のバージョンの Container Insights では、メトリクスはカスタムメトリクスとして課金されます。Amazon EKS 向けにオブザーバビリティが強化された Container Insights では、観察結果毎に Container Insights メトリクスに課金されます。保存されたメトリクスまたは取り込まれたログ単位では課金されません。CloudWatch の料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」をご覧ください。
**注記**
Windows で、ホストプロセスコンテナの `pod_network_rx_bytes` や `pod_network_tx_bytes` などのネットワークメトリクスは収集されません。
RedHat OpenShift on AWS (ROSA) クラスター では、`node_diskio_io_serviced_total` や `node_diskio_io_service_bytes_total` などの diskio メトリクスは収集されません。
| メトリクス名 | ディメンション | 説明 |
| --- | --- | --- |
| `cluster_failed_node_count` | `ClusterName` | クラスター内の失敗したワーカーノードの数。*ノードの状態*に何らかの問題がある場合は、そのノードは失敗したとみなされます。詳細については、Kubernetes ドキュメントの 「[Conditions (状態)](https://kubernetes.io/docs/concepts/architecture/nodes/#condition)」を参照してください。 |
| `cluster_node_count` | `ClusterName` | クラスター内のワーカーノードの総数。 |
| `namespace_number_of_running_pods` | `Namespace` `ClusterName` `ClusterName` | 使用しているディメンションによって指定されたリソースの名前空間ごとに実行されているポッドの数。 |
| `node_cpu_limit` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | このクラスター内の単一のノードに割り当てることができる CPU ユニットの最大数。 |
| `node_cpu_reserved_capacity` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | ノードコンポーネント (kubelet、kube-proxy、Docker など) に予約されている CPU ユニットの割合。 計算式: `node_cpu_request / node_cpu_limit` `node_cpu_request` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `node_cpu_usage_total` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | クラスターのノードで使用されている CPU ユニットの数。 |
| `node_cpu_utilization` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | クラスター内のノードで使用されている CPU ユニットの合計使用率。 計算式: `node_cpu_usage_total / node_cpu_limit` |
| `node_filesystem_utilization` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | クラスター内のノードで使用されているファイルシステム容量の合計使用率。 計算式: `node_filesystem_usage / node_filesystem_capacity` `node_filesystem_usage` および `node_filesystem_capacity` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `node_memory_limit` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | このクラスター内の単一のノードに割り当てることができるメモリの最大量 (バイト単位)。 |
| `node_filesystem_inodes` Windows ではご利用いただけません。 | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノード上の inode (使用済みおよび未使用) の総数。 |
| `node_filesystem_inodes_free` Windows ではご利用いただけません。 | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノード上の未使用の inode の数。 |
| `node_gpu_limit` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノードで使用可能な GPU の合計数。 |
| `node_gpu_usage_total` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノードで実行中のポッドによって使用されている GPU の数。 |
| `node_gpu_reserved_capacity` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` |
| `node_memory_reserved_capacity` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | クラスター内のノードで現在使用されているメモリの割合。 計算式: `node_memory_request / node_memory_limit` `node_memory_request` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `node_memory_utilization` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | ノードによって現在使用されているメモリの割合。これは、ノードのメモリ制限で割られたノードのメモリ使用量の割合です。 計算式: `node_memory_working_set / node_memory_limit` |
| `node_memory_working_set` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | クラスターで現在稼働しているノードのセットで使用されているメモリの量 (バイト単位)。 |
| `node_network_total_bytes` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | クラスターのノードごとにネットワーク経由で送信および受信された合計バイト数。 計算式: `node_network_rx_bytes + node_network_tx_bytes` `node_network_rx_bytes` および `node_network_tx_bytes` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `node_number_of_running_containers` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | クラスターのノードごとに実行中のコンテナの数。 |
| `node_number_of_running_pods` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | クラスターのノードごとに実行中のポッドの数。 |
| `node_status_allocatable_pods` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | 割り当て可能なリソースに基づいてノードに割り当てることができるポッドの数。システムデーモンの予約とハードエビクションのしきい値の考慮後のノードの残りの容量として定義されます。 |
| `node_status_capacity_pods` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | 容量に基づいてノードに割り当てることができるポッドの数。 |
| `node_status_condition_ready` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノード ステータスの条件 `Ready` が、Amazon EC2 ノードに当てはまるかどうかを示します。 |
| `node_status_condition_memory_pressure` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノードステータスの条件 `MemoryPressure` が正しいかどうかを示します。 |
| `node_status_condition_pid_pressure` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノードステータスの条件 `PIDPressure` が正しいかどうかを示します。 |
| `node_status_condition_disk_pressure` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノードステータスの条件 `OutOfDisk` が正しいかどうかを示します。 |
| `node_status_condition_unknown` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノードステータス条件のいずれかが不明であるかどうかを示します。 |
| `node_interface_network_rx_dropped` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノード上のネットワークインターフェイスによって受信されたが、その後削除されたパケットの数。 |
| `node_interface_network_tx_dropped` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノード上のネットワークインターフェイスによって送信される予定だったが、削除されたパケットの数。 |
| `node_diskio_io_service_bytes_total` Windows または ROSA クラスターでは使用できません。 | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノード上のすべての I/O オペレーションにより送信された合計バイト数。 |
| `node_diskio_io_serviced_total` Windows または ROSA クラスターでは使用できません。 | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノード上の I/O オペレーションの総数。 |
| `pod_cpu_reserved_capacity` | `PodName`, `Namespace`, `ClusterName` `ClusterName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `Service` | クラスターのポッドごとに予約されている CPU 容量。 計算式: `pod_cpu_request / node_cpu_limit` `pod_cpu_request` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `pod_cpu_utilization` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッドで使用されている CPU ユニットの割合。 計算式: `pod_cpu_usage_total / node_cpu_limit` |
| `pod_cpu_utilization_over_pod_limit` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッドの制限に対する、ポッドで使用されている CPU ユニットの割合。 計算式: `pod_cpu_usage_total / pod_cpu_limit` |
| `pod_memory_reserved_capacity` | `PodName`, `Namespace`, `ClusterName` `ClusterName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `Service` | ポッド用に予約されているメモリの割合。 計算式: `pod_memory_request / node_memory_limit` `pod_memory_request` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `pod_memory_utilization` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッドが現在使用しているメモリの割合。 計算式: `pod_memory_working_set / node_memory_limit` |
| `pod_memory_utilization_over_pod_limit` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッドの制限に対する、ポッドで使用されているメモリの割合。ポッドのいずれかのコンテナに、定義されたメモリ制限がない場合、このメトリクスは表示されません。 計算式: `pod_memory_working_set / pod_memory_limit` |
| `pod_network_rx_bytes` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッドによって、ネットワーク経由で受信されているバイト数。 計算式: `sum(pod_interface_network_rx_bytes)` `pod_interface_network_rx_bytes` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `pod_network_tx_bytes` | `PodName`, `Namespace`, `ClusterName` `Namespace,` `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッドによって、ネットワーク経由で送信されているバイト数。 計算式: `sum(pod_interface_network_tx_bytes)` `pod_interface_network_tx_bytes` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `pod_cpu_request` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッドの CPU リクエスト。 計算式: `sum(container_cpu_request)` `pod_cpu_request` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `pod_memory_request` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッドのメモリリクエスト。 計算式: `sum(container_memory_request)` `pod_memory_request` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `pod_cpu_limit` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッド内のコンテナに定義されている CPU 制限。ポッド内のいずれかのコンテナに定義された CPU 制限がない場合、このメトリクスは表示されません。 計算式: `sum(container_cpu_limit)` `pod_cpu_limit` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `pod_memory_limit` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッド内のコンテナに定義されているメモリ上限。ポッドのいずれかのコンテナに、定義されたメモリ制限がない場合、このメトリクスは表示されません。 計算式: `sum(container_memory_limit)` `pod_cpu_limit` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `pod_status_failed` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッド内のすべてのコンテナが終了したことを示します。また、少なくとも 1 つのコンテナがゼロ以外のステータスで終了したか、システムによって終了されたことを示します。 |
| `pod_status_ready` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッド内のすべてのコンテナの準備が整い、条件 `ContainerReady` に達したことを示します。 |
| `pod_status_running` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッド内のすべてのコンテナが実行中であることを示します。 |
| `pod_status_scheduled` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッドがノードにスケジュールされていることを示します。 |
| `pod_status_unknown` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッドのステータスを取得できないことを示します。 |
| `pod_status_pending` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッドはクラスターに受け入れられたが、1 つ以上のコンテナの準備がまだ整っていないことを示します。 |
| `pod_status_succeeded` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッド内のすべてのコンテナが正常に終了し、再起動されていないことを示します。 |
| `pod_number_of_containers` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッドの仕様で定義されているコンテナの数をレポートします。 |
| `pod_number_of_running_containers` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | 現在、`Running` 状態にあるポッド内のコンテナの数をレポートします。 |
| `pod_container_status_terminated` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | `Terminated` 状態にあるポッド内のコンテナの数をレポートします。 |
| `pod_container_status_running` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | `Running` 状態にあるポッド内のコンテナの数をレポートします。 |
| `pod_container_status_waiting` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | `Waiting` 状態にあるポッド内のコンテナの数をレポートします。 |
| `pod_container_status_waiting_reason_crash_loop_back_off` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | `CrashLoopBackOff` エラーのために保留中のポッド内のコンテナの数をレポートします。この場合、コンテナは繰り返し起動できません。 |
| `pod_container_status_waiting_reason_create_container_config_error` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | 理由 `CreateContainerConfigError` で保留中のポッド内のコンテナの数をレポートします。これは、コンテナ設定の作成中にエラーが発生したことが原因です。 |
| `pod_container_status_waiting_reason_create_container_error` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | コンテナの作成中にエラーが発生したため、理由 `CreateContainerError` で保留中のポッド内のコンテナの数をレポートします。 |
| `pod_container_status_waiting_reason_image_pull_error` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | `ErrImagePull`、`ImagePullBackOff`、または `InvalidImageName` のために保留中のポッド内のコンテナの数をレポートします。これらの状況は、コンテナイメージのプル中にエラーが発生したことが原因です。 |
| `pod_container_status_waiting_reason_start_error` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | コンテナの起動中にエラーが発生したため、`StartError` であることが理由で保留中のポッド内のコンテナの数をレポートします。 |
| `pod_container_status_terminated_reason_oom_killed` | `ContainerName`, `FullPodName`, `PodName`, `Namespace`, `ClusterName` `ContainerName`, `PodName`, `Namespace`, `ClusterName` `ClusterName` | メモリ制限を超えたためにポッドが終了したことを示します。このメトリクスは、この問題が発生した場合にのみ表示されます。 |
| `pod_interface_network_rx_dropped` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッド用にネットワークインターフェイスが受信されたが、その後削除されたパケットの数。 |
| `pod_interface_network_tx_dropped` | `ClusterName` `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッド用に送信される予定だったが、削除されたパケットの数。 |
| `pod_memory_working_set` | `ClusterName` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッドで現在使用されているバイト単位のメモリ。 |
| `pod_cpu_usage_total` | `ClusterName` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` | ポッドで使用されている CPU ユニットの数。 |
| `container_cpu_utilization` | `ClusterName` `PodName`, `Namespace`, `ClusterName`, `ContainerName` `PodName`, `Namespace`, `ClusterName`, `ContainerName`, `FullPodName` | コンテナで使用されている CPU ユニットの割合。 計算式: `container_cpu_usage_total / node_cpu_limit` `container_cpu_utilization` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `container_cpu_utilization_over_container_limit` | `ClusterName` `PodName`, `Namespace`, `ClusterName`, `ContainerName` `PodName`, `Namespace`, `ClusterName`, `ContainerName`, `FullPodName` | コンテナの制限に対する、コンテナで使用されている CPU ユニットの割合。コンテナに定義された CPU 制限がない場合、このメトリクスは表示されません。 計算式: `container_cpu_usage_total / container_cpu_limit` `container_cpu_utilization_over_container_limit` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `container_memory_utilization` | `ClusterName` `PodName`, `Namespace`, `ClusterName`, `ContainerName` `PodName`, `Namespace`, `ClusterName`, `ContainerName`, `FullPodName` | コンテナで使用されているメモリユニットの割合。 計算式: `container_memory_working_set / node_memory_limit` `container_memory_utilization` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `container_memory_utilization_over_container_limit` | `ClusterName` `PodName`, `Namespace`, `ClusterName`, `ContainerName` `PodName`, `Namespace`, `ClusterName`, `ContainerName`, `FullPodName` | コンテナの制限に対する、コンテナで使用されているメモリユニットの割合。コンテナに定義されたメモリ制限がない場合、このメトリクスは表示されません。 計算式: `container_memory_working_set / container_memory_limit` `container_memory_utilization_over_container_limit` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `container_memory_failures_total` Windows ではご利用いただけません。 | `ClusterName` `PodName`, `Namespace`, `ClusterName`, `ContainerName` `PodName`, `Namespace`, `ClusterName`, `ContainerName`, `FullPodName` | コンテナがメモリの割り当てに失敗した回数。 |
| `pod_number_of_container_restarts` | PodName、`Namespace`、`ClusterName` | ポッドでのコンテナ再起動の合計数。 |
| `service_number_of_running_pods` | Service、`Namespace`、`ClusterName` `ClusterName` | クラスターでサービス (1 つまたは複数) を実行しているポッドの数。 |
| `replicas_desired` | `ClusterName` `PodName`, `Namespace`, `ClusterName` | ワークロードの仕様で定義されているワークロードに必要なポッドの数。 |
| `replicas_ready` | `ClusterName` `PodName`, `Namespace`, `ClusterName` | 準備完了の状態に達したワークロードにおけるポッドの数。 |
| `status_replicas_available` | `ClusterName` `PodName`, `Namespace`, `ClusterName` | 1 つのワークロードで使用可能なポッドの数。ポッドは、ワークロードの仕様で定義されている `minReadySeconds` の準備が完了した時点で利用可能になります。 |
| `status_replicas_unavailable` | `ClusterName` `PodName`, `Namespace`, `ClusterName` | ワークロードで利用できないポッドの数。ポッドは、ワークロードの仕様で定義されている `minReadySeconds` の準備が完了した時点で利用可能になります。この基準を満たしていない場合、ポッドは使用できません。 |
| `apiserver_storage_objects` | `ClusterName` `ClusterName`, `resource` | 最後の確認時に etcd に保存されたオブジェクトの数。 |
| `apiserver_storage_db_total_size_in_bytes` | `ClusterName` `ClusterName`, `endpoint` | 物理的に割り当てられたストレージデータベースファイルの合計サイズ (バイト単位)。このメトリクスは実験段階で、Kubernetes の今後のリリースで変更される可能性があります。 単位: バイト 有意義な統計: 合計、平均、最小、最大 |
| `apiserver_request_total` | `ClusterName` `ClusterName`, `code`, `verb` | Kubernetes API サーバーに転送された API リクエストの総数。 |
| `apiserver_request_duration_seconds` | `ClusterName` `ClusterName`, `verb` | Kubernetes API サーバーへの API リクエストの応答レイテンシー。 |
| `apiserver_admission_controller_admission_duration_seconds` | `ClusterName` `ClusterName`, `operation` | アドミッションコントローラーのレイテンシー (秒単位)。アドミッションコントローラーは Kubernetes API サーバーへのリクエストをインターセプトするコードです。 |
| `rest_client_request_duration_seconds` | `ClusterName` `ClusterName`, `operation` | Kubernetes API サーバーを呼び出すクライアントに起こる応答レイテンシー。このメトリクスは実験段階で、Kubernetes の今後のリリースで変更される可能性があります。 |
| `rest_client_requests_total` | `ClusterName` `ClusterName`, `code`, `method` | クライアントにより作成された Kubernetes API サーバーへの API リクエストの総数。このメトリクスは実験段階で、Kubernetes の今後のリリースで変更される可能性があります。 |
| `etcd_request_duration_seconds` | `ClusterName` `ClusterName`, `operation` | Etcd への API 呼び出しの応答レイテンシー。このメトリクスは実験段階で、Kubernetes の今後のリリースで変更される可能性があります。 |
| `apiserver_storage_size_bytes` | `ClusterName` `ClusterName`, `endpoint` | 物理的に割り当てられたストレージデータベースファイルのサイズ (バイト単位)。このメトリクスは実験段階で、Kubernetes の今後のリリースで変更される可能性があります。 |
| `apiserver_longrunning_requests` | `ClusterName` `ClusterName`, `resource` | Kubernetes API サーバーへの長時間稼働リクエストの数。 |
| `apiserver_current_inflight_requests` | `ClusterName` `ClusterName`, `request_kind` | Kubernetes API サーバーにより処理されているリクエストの数。 |
| `apiserver_admission_webhook_admission_duration_seconds` | `ClusterName` `ClusterName`, `name` | アドミッションウェブフックのレイテンシー (秒単位)。アドミッションウェブフックはアドミッションリクエストを受信し、何らかの処理を行う HTTP コールバックです。 |
| `apiserver_admission_step_admission_duration_seconds` | `ClusterName` `ClusterName`, `operation` | アドミッションのサブステップのレイテンシー (秒単位)。 |
| `apiserver_requested_deprecated_apis` | `ClusterName` `ClusterName`, `group` | Kubernetes API サーバー上での非推奨の API へのリクエストの数。 |
| `apiserver_request_total_5xx` | `ClusterName` `ClusterName`, `code`, `verb` | Kubernetes API サーバーへのリクエストのうち、5XX HTTP レスポンスコードで応答されたリクエストの数。 |
| `apiserver_storage_list_duration_seconds` | `ClusterName` `ClusterName`, `resource` | Etc からのオブジェクトを一覧表示する応答レイテンシー。このメトリクスは実験段階で、Kubernetes の今後のリリースで変更される可能性があります。 |
| `apiserver_flowcontrol_request_concurrency_limit` | `ClusterName` `ClusterName`, `priority_level` | API Priority and Fairness サブシステムで現在実行中のリクエストによって使用されているスレッドの数。 |
| `apiserver_flowcontrol_rejected_requests_total` | `ClusterName` `ClusterName`, `reason` | API Priority and Fairness のサブシステムによって拒否されたリクエストの数。このメトリクスは実験段階で、Kubernetes の今後のリリースで変更される可能性があります。 |
| `apiserver_current_inqueue_requests` | `ClusterName` `ClusterName`, `request_kind` | Kubernetes API サーバーによりキューに保存されたリクエストの数。このメトリクスは実験段階で、Kubernetes の今後のリリースで変更される可能性があります。 |
## NVIDIA GPU メトリクス
CloudWatch エージェントのバージョン `1.300034.0` 以降で Amazon EKS 向けにオブザーバビリティが強化された Container Insights は、デフォルトで EKS ワークロードから NVIDIA GPU メトリクスを収集します。CloudWatch エージェントは、CloudWatch Observability EKS アドオンのバージョン `v1.3.0-eksbuild.1` 以降を使用してインストールする必要があります。詳細については、「[Amazon CloudWatch Observability EKS アドオンまたは Helm チャートを使用して CloudWatch エージェントをインストールする](install-CloudWatch-Observability-EKS-addon.md)」を参照してください。収集されるこれらの NVIDIA GPU メトリクスは、このセクションにある表に一覧表示されています。
Container Insights が NVIDIA GPU メトリクスを収集するには、次の前提条件を満たす必要があります。
+ Amazon EKS 向けにオブザーバビリティが強化された Container Insights を使用するには、Amazon CloudWatch Observability EKS アドオンバージョン `v1.3.0-eksbuild.1` 以降を使用する必要があります。
+ クラスターに [Kubernetes 用 NVIDIA デバイスプラグイン](https://github.com/NVIDIA/k8s-device-plugin)がインストールされている必要があります。
+ クラスターのノードに [NVIDIA コンテナツールキット](https://github.com/NVIDIA/nvidia-container-toolkit)がインストールされている必要があります。例えば、Amazon EKS-Optimized Accelerated AMI は、必要なコンポーネントで作成されています。
最初の CloudWatch エージェント設定ファイルの `accelerated_compute_metrics` オプションを `false` に設定することで、NVIDIA GPU メトリクスの収集をオプトアウトできます。詳細とオプトアウトの設定の例については、「[(オプション) その他の設定](install-CloudWatch-Observability-EKS-addon.md#install-CloudWatch-Observability-EKS-addon-configuration)」を参照してください。
| メトリクス名 | ディメンション | 説明 |
| --- | --- | --- |
| `container_gpu_memory_total` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `GpuDevice` | コンテナに割り当てられた GPU のフレームバッファの合計サイズ (バイト)。 |
| `container_gpu_memory_used` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `GpuDevice` | コンテナに割り当てられた GPU で使用されているフレームバッファのバイト数。 |
| `container_gpu_memory_utilization` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `GpuDevice` | コンテナに割り当てられた GPU のうち、使用されているフレームバッファの割合。 |
| `container_gpu_power_draw` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `GpuDevice` | コンテナに割り当てられた GPU の電力使用量 (ワット)。 |
| `container_gpu_temperature` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `GpuDevice` | コンテナに割り当てられた GPU の温度 (摂氏)。 |
| `container_gpu_utilization` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `GpuDevice` | コンテナに割り当てられた GPU の使用率。 |
| `container_gpu_tensor_core_utilization` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `GpuDevice` | コンテナに割り当てられた GPU 上の Tensor コアの使用率。 |
| `node_gpu_memory_total` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `GpuDevice` | ノードに割り当てられた GPU のフレームバッファの合計サイズ (バイト)。 |
| `node_gpu_memory_used` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `GpuDevice` | ノードに割り当てられた GPU で使用されているフレームバッファのバイト数。 |
| `node_gpu_memory_utilization` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `GpuDevice` | ノードに割り当てられた GPU で使用されているフレームバッファの割合。 |
| `node_gpu_power_draw` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `GpuDevice` | ノードに割り当てられた GPU の電力使用量 (ワット)。 |
| `node_gpu_temperature` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `GpuDevice` | ノードに割り当てられた GPU の温度 (摂氏)。 |
| `node_gpu_utilization` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `GpuDevice` | ノードに割り当てられた GPU の使用率。 |
| `node_gpu_tensor_core_utilization` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `GpuDevice` | ノードに割り当てられた GPU 上の Tensor コアの使用率。 |
| `pod_gpu_memory_total` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`. `GpuDevice` | ポッドに割り当てられた GPU のフレームバッファの合計サイズ (バイト)。 |
| `pod_gpu_memory_used` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`. `GpuDevice` | ポッドに割り当てられた GPU で使用されているフレームバッファのバイト数。 |
| `pod_gpu_memory_utilization` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`. `GpuDevice` | ポッドに割り当てられた GPU で使用されているフレームバッファの割合。 |
| `pod_gpu_power_draw` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`. `GpuDevice` | ポッドに割り当てられた GPU の電力使用量 (ワット)。 |
| `pod_gpu_temperature` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`. `GpuDevice` | ポッドに割り当てられた GPU の温度 (摂氏)。 |
| `pod_gpu_utilization` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `GpuDevice` | ポッドに割り当てられた GPU の使用率。 |
| `pod_gpu_tensor_core_utilization` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `GpuDevice` | ポッドに割り当てられた GPU 上の Tensor コアの使用率。 |
### 詳細な GPU モニタリング
CloudWatch エージェントのバージョン `1.300062.0` 以降、Amazon EKS のオブザーバビリティが強化された Container Insights は、1 分未満の収集間隔で詳細な GPU モニタリングをサポートします。これにより、標準的な収集間隔では場合によって完全に見逃される短期間の機械学習推論ワークロードのモニタリングギャップに対処できます。CloudWatch エージェントは、CloudWatch Observability EKS アドオンのバージョン `v4.7.0-eksbuild.1` 以降を使用してインストールする必要があります。詳細については、「[Amazon CloudWatch Observability EKS アドオンまたは Helm チャートを使用して CloudWatch エージェントをインストールする](install-CloudWatch-Observability-EKS-addon.md)」を参照してください。
デフォルトでは、GPU メトリクスが収集され、60 秒間隔で取り込まれます。詳細モニタリングを有効にすると、CloudWatch エージェントは 1 分未満の間隔 (最短 1 秒) で GPU メトリクスを収集しますが、メトリクスは引き続き 1 分間隔で CloudWatch に取り込まれます。ただし、1 分未満のデータポイントを 1 分間ごとに集計した統計 (最小値、最大値、p90 のようなパーセンタイルなど) をクエリできるため、正確な GPU 使用率データが得られ、リソースの最適化が向上します。
#### 設定
詳細な GPU モニタリングを有効にするには、次の例のように、 `kubernetes` セクションに `accelerated_compute_gpu_metrics_collection_interval` パラメータを含めるように CloudWatch エージェント設定を更新します。
```
{
"logs": {
"metrics_collected": {
"kubernetes": {
"cluster_name": "MyCluster",
"enhanced_container_insights": true,
"accelerated_compute_metrics": true,
"accelerated_compute_gpu_metrics_collection_interval": 1
}
}
}
}
```
`accelerated_compute_gpu_metrics_collection_interval` パラメータは値を秒単位で受け入れます。最小値は 1 秒です。`1` に設定すると、収集間隔が 1 秒になります。このパラメータを指定しない場合、デフォルトの 60 秒間隔が使用されます。
完全な設定手順については、「[クラスターメトリクスを収集するよう CloudWatch エージェントを設定する](Container-Insights-setup-metrics.md)」を参照してください。
## AWS Trainium と AWS Inferentia の AWS Neuron メトリクス
CloudWatch エージェントのバージョン `1.300036.0` 以降、Amazon EKS 向けにオブザーバビリティが強化された Container Insights は、デフォルトで AWS Trainium および AWS Inferentia アクセラレーターから高速コンピューティングメトリクスを収集します。CloudWatch エージェントは、CloudWatch Observability EKS アドオンのバージョン `v1.5.0-eksbuild.1` 以降を使用してインストールする必要があります。アドオンの詳細については、「[Amazon CloudWatch Observability EKS アドオンまたは Helm チャートを使用して CloudWatch エージェントをインストールする](install-CloudWatch-Observability-EKS-addon.md)」を参照してください。AWS Trainium の詳細については、「[AWS Trainium](https://aws.amazon.com/machine-learning/trainium/)」を参照してください。AWS Inferentia の詳細については、「[AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)」を参照してください。
Container Insights が AWS Neuron メトリクスを収集するには、次の前提条件を満たす必要があります。
+ Amazon EKS 向けにオブザーバビリティが強化された Container Insights を使用するには、Amazon CloudWatch Observability EKS アドオンバージョン `v1.5.0-eksbuild.1` 以降を使用する必要があります。
+ [Neuron ドライバー](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/general/setup/neuron-setup/pytorch/neuronx/ubuntu/torch-neuronx-ubuntu22.html#setup-torch-neuronx-ubuntu22)はクラスターのノードにインストールする必要があります。
+ [Neuron デバイスプラグイン](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/containers/kubernetes-getting-started.html)はクラスターにインストールする必要があります。例えば、Amazon EKS-Optimized Accelerated AMI は、必要なコンポーネントで作成されています。
収集されるメトリクスは、このセクションにある表に一覧表示されています。AWS Trainium、AWS Inferentia、および AWS Inferentia2 のメトリクスが収集されます。
CloudWatch エージェントは [Neuron Monitor](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-monitor-user-guide.html) からこれらのメトリクスを収集し、必要な Kubernetes リソースの関連付けを行って、ポッドレベルとコンテナレベルでメトリクスを配信します。
| メトリクス名 | ディメンション | 説明 |
| --- | --- | --- |
| `container_neuroncore_utilization` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NeuronDevice`, `NeuronCore` | コンテナに割り当てられた NeuronCore のキャプチャ期間中の NeuronCore 使用率。 単位: パーセント |
| `container_neuroncore_memory_usage_constants` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NeuronDevice`, `NeuronCore` | コンテナに割り当てられた NeuronCore によってトレーニング中に定数 (または推論中の重み) に使用されるデバイスメモリの量。 単位: バイト |
| `container_neuroncore_memory_usage_model_code` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NeuronDevice`, `NeuronCore` | コンテナに割り当てられた NeuronCore によってモデルの実行コードに使用されるデバイスメモリの量。 単位: バイト |
| `container_neuroncore_memory_usage_model_shared_scratchpad` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NeuronDevice`, `NeuronCore` | コンテナに割り当てられた NeuronCore によってモデルの共有スクラッチパッドに使用されるデバイスメモリの量。このメモリ領域はモデル用に予約されています。 単位: バイト |
| `container_neuroncore_memory_usage_runtime_memory` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NeuronDevice`, `NeuronCore` | コンテナに割り当てられた NeuronCore によって Neuron ランタイムに使用されるデバイスメモリの量。 単位: バイト |
| `container_neuroncore_memory_usage_tensors` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NeuronDevice`, `NeuronCore` | コンテナに割り当てられた NeuronCore によってテンソルに使用されるデバイスメモリの量。 単位: バイト |
| `container_neuroncore_memory_usage_total` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NeuronDevice`, `NeuronCore` | コンテナに割り当てられた NeuronCore によって使用されるメモリの合計量。 単位: バイト |
| `container_neurondevice_hw_ecc_events_total` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NeuronDevice` | ノード上の Neuron デバイスのオンチップ SRAM とデバイスメモリの修正済みおよび未修正 ECC イベントの数。 単位: 数 |
| `pod_neuroncore_utilization` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NeuronDevice`, `NeuronCore` | ポッドに割り当てられた NeuronCore のキャプチャ期間中の NeuronCore 使用率。 単位: パーセント |
| `pod_neuroncore_memory_usage_constants` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NeuronDevice`, `NeuronCore` | ポッドに割り当てられた NeuronCore によってトレーニング中に定数 (または推論中の重み) に使用されるデバイスメモリの量。 単位: バイト |
| `pod_neuroncore_memory_usage_model_code` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NeuronDevice`, `NeuronCore` | ポッドに割り当てられた NeuronCore によってモデルの実行コードに使用されるデバイスメモリの量。 単位: バイト |
| `pod_neuroncore_memory_usage_model_shared_scratchpad` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NeuronDevice`, `NeuronCore` | ポッドに割り当てられた NeuronCore によってモデルの共有スクラッチパッドに使用されるデバイスメモリの量。このメモリ領域はモデル用に予約されています。 単位: バイト |
| `pod_neuroncore_memory_usage_runtime_memory` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NeuronDevice`, `NeuronCore` | ポッドに割り当てられた NeuronCore によって Neuron ランタイムに使用されるデバイスメモリの量。 単位: バイト |
| `pod_neuroncore_memory_usage_tensors` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NeuronDevice`, `NeuronCore` | ポッドに割り当てられた NeuronCore によってテンソルに使用されるデバイスメモリの量。 単位: バイト |
| `pod_neuroncore_memory_usage_total` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NeuronDevice`, `NeuronCore` | ポッドに割り当てられた NeuronCore によって使用されるメモリの合計量。 単位: バイト |
| `pod_neurondevice_hw_ecc_events_total` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NeuronDevice` | ポッドに割り当てられた Neuron デバイスのオンチップ SRAM とデバイスメモリの修正済みおよび未修正 ECC イベントの数。 単位: バイト |
| `node_neuroncore_utilization` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceType`, `InstanceId`, `NodeName`, `NeuronDevice`, `NeuronCore` | ノードに割り当てられた NeuronCore のキャプチャ期間中の NeuronCore 使用率。 単位: パーセント |
| `node_neuroncore_memory_usage_constants` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceType`, `InstanceId`, `NodeName`, `NeuronDevice`, `NeuronCore` | ノードに割り当てられた NeuronCore によってトレーニング中に定数 (または推論中の重み) に使用されるデバイスメモリの量。 単位: バイト |
| `node_neuroncore_memory_usage_model_code` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceType`, `InstanceId`, `NodeName`, `NeuronDevice`, `NeuronCore` | ノードに割り当てられた NeuronCore によってモデルの実行コードに使用されるデバイスメモリの量。 単位: バイト |
| `node_neuroncore_memory_usage_model_shared_scratchpad` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceType`, `InstanceId`, `NodeName`, `NeuronDevice`, `NeuronCore` | ノードに割り当てられた NeuronCore によってモデルの共有スクラッチパッドに使用されるデバイスメモリの量。これはモデル用に予約されているメモリ領域です。 単位: バイト |
| `node_neuroncore_memory_usage_runtime_memory` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceType`, `InstanceId`, `NodeName`, `NeuronDevice`, `NeuronCore` | ノードに割り当てられた NeuronCore によって Neuron ランタイムに使用されるデバイスメモリの量。 単位: バイト |
| `node_neuroncore_memory_usage_tensors` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceType`, `InstanceId`, `NodeName`, `NeuronDevice`, `NeuronCore` | ノードに割り当てられた NeuronCore によってテンソルに使用されるデバイスメモリの量。 単位: バイト |
| `node_neuroncore_memory_usage_total` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceType`, `InstanceId`, `NodeName`, `NeuronDevice`, `NeuronCore` | ノードに割り当てられた NeuronCore によって使用されるメモリの合計量。 単位: バイト |
| `node_neuron_execution_errors_total` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` | ノード上の実行エラーの合計数。これは、CloudWatch エージェントで `generic`、`numerical`、`transient`、`model`、`runtime`、`hardware` の各タイプのエラーを集計することによって計算されます。 単位: 数 |
| `node_neurondevice_runtime_memory_used_bytes` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` | ノード上の Neuron デバイスの合計メモリ使用量 (バイト)。 単位: バイト |
| `node_neuron_execution_latency` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` | Neuron ランタイムによって測定されたノードでの実行のレイテンシー (秒)。 単位: 秒 |
| `node_neurondevice_hw_ecc_events_total` | `ClusterName` `ClusterName`, `UltraServer` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `NodeName`, `NeuronDevice` | ノード上の Neuron デバイスのオンチップ SRAM とデバイスメモリの修正済みおよび未修正 ECC イベントの数。 単位: 数 |
## AWS Elastic Fabric Adapter (EFA) メトリクス
CloudWatch エージェントのバージョン `1.300037.0` 以降、Amazon EKS 向けにオブザーバビリティが強化された Container Insights は Linux インスタンス上の Amazon EKS クラスターから AWS Elastic Fabric Adapter (EFA) メトリクスを収集します。CloudWatch エージェントは、CloudWatch Observability EKS アドオンのバージョン `v1.5.2-eksbuild.1` 以降を使用してインストールする必要があります。アドオンの詳細については、「[Amazon CloudWatch Observability EKS アドオンまたは Helm チャートを使用して CloudWatch エージェントをインストールする](install-CloudWatch-Observability-EKS-addon.md)」を参照してください。AWS Elastic Fabric Adapter の詳細については、「[Elastic Fabric Adapter](https://aws.amazon.com/hpc/efa/)」を参照してください。
Container Insights が AWS Elastic Fabric Adapter メトリクスを収集するには、次の前提条件を満たす必要があります。
+ Amazon EKS 向けにオブザーバビリティが強化された Container Insights を使用するには、Amazon CloudWatch Observability EKS アドオンバージョン `v1.5.2-eksbuild.1` 以降を使用する必要があります。
+ EFA デバイスプラグインはクラスターにインストールする必要があります。詳細については、GitHub の [aws-efa-k8s-device-plugin](https://github.com/aws/eks-charts/tree/master/stable/aws-efa-k8s-device-plugin) を参照してください。
収集されるメトリクスのリストを次の表に示します。
| メトリクス名 | ディメンション | 説明 |
| --- | --- | --- |
| `container_efa_rx_bytes` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NetworkInterfaceId` | コンテナに割り当てられた EFA デバイスによって受信された 1 秒あたりのバイト数。 単位: バイト/秒 |
| `container_efa_tx_bytes` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NetworkInterfaceId` | コンテナに割り当てられた EFA デバイスによって送信された 1 秒あたりのバイト数。 単位: バイト/秒 |
| `container_efa_rx_dropped` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NetworkInterfaceId` | コンテナに割り当てられた EFA デバイスによって受信され、ドロップされたパケットの数。 単位: カウント/秒 |
| `container_efa_rdma_read_bytes` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NetworkInterfaceId` | コンテナに割り当てられた EFA デバイスによって、リモートダイレクトメモリアクセスの読み取りオペレーションを使用して受信された 1 秒あたりのバイト数。 単位: バイト/秒 |
| `container_efa_rdma_write_bytes` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NetworkInterfaceId` | コンテナに割り当てられた EFA デバイスによって、リモートダイレクトメモリアクセスの読み取りオペレーションを使用して送信された 1 秒あたりのバイト数。 単位: バイト/秒 |
| `container_efa_rdma_write_recv_bytes` | `ClusterName` `ClusterName`, `Namespace`, `PodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `ContainerName`, `NetworkInterfaceId` | コンテナに割り当てられた EFA デバイスによって、リモートダイレクトメモリアクセスの書き込みオペレーションを使用して受信された 1 秒あたりのバイト数。 単位: バイト/秒 |
| `pod_efa_rx_bytes` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NetworkInterfaceId` | ポッドに割り当てられた EFA デバイスによって受信された 1 秒あたりのバイト数。 単位: バイト/秒 |
| `pod_efa_tx_bytes` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NetworkInterfaceId` | ポッドに割り当てられた EFA デバイスによって送信された 1 秒あたりのバイト数。 単位: バイト/秒 |
| `pod_efa_rx_dropped` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NetworkInterfaceId` | ポッドに割り当てられた EFA デバイスによって受信され、ドロップされたパケットの数。 単位: カウント/秒 |
| `pod_efa_rdma_read_bytes` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NetworkInterfaceId` | ポッドに割り当てられた EFA デバイスによって、リモートダイレクトメモリアクセスの読み取りオペレーションを使用して受信された 1 秒あたりのバイト数。 単位: バイト/秒 |
| `pod_efa_rdma_write_bytes` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NetworkInterfaceId` | ポッドに割り当てられた EFA デバイスによって、リモートダイレクトメモリアクセスの読み取りオペレーションを使用して送信された 1 秒あたりのバイト数。 単位: バイト/秒 |
| `pod_efa_rdma_write_recv_bytes` | `ClusterName` `ClusterName`, `Namespace` `ClusterName`, `Namespace`, `Service` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName` `ClusterName`, `Namespace`, `PodName`, `FullPodName`, `NetworkInterfaceId` | ポッドに割り当てられた EFA デバイスによって、リモートダイレクトメモリアクセスの書き込みオペレーションを使用して受信された 1 秒あたりのバイト数。 単位: バイト/秒 |
| `node_efa_rx_bytes` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `NetworkInterfaceId` | ノードに割り当てられた EFA デバイスによって受信された 1 秒あたりのバイト数。 単位: バイト/秒 |
| `node_efa_tx_bytes` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `NetworkInterfaceId` | ノードに割り当てられた EFA デバイスによって送信された 1 秒あたりのバイト数。 単位: バイト/秒 |
| `node_efa_rx_dropped` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `NetworkInterfaceId` | ノードに割り当てられた EFA デバイスによって受信され、ドロップされたパケットの数。 単位: カウント/秒 |
| `node_efa_rdma_read_bytes` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `NetworkInterfaceId` | ノードに割り当てられた EFA デバイスによって、リモートダイレクトメモリアクセスの読み取りオペレーションを使用して受信された 1 秒あたりのバイト数。 単位: バイト/秒 |
| `node_efa_rdma_write_bytes` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `NetworkInterfaceId` | ポッドに割り当てられた EFA デバイスによって、リモートダイレクトメモリアクセスの読み取りオペレーションを使用して送信された 1 秒あたりのバイト数。 単位: バイト/秒 |
| `node_efa_rdma_write_recv_bytes` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` `ClusterName`, `InstanceId`, `InstanceType`, `NodeName`, `NetworkInterfaceId` | ノードに割り当てられた EFA デバイスによって、リモートダイレクトメモリアクセスの書き込みオペレーションを使用して受信された 1 秒あたりのバイト数。 単位: バイト/秒 |
## Amazon SageMaker AI HyperPod メトリクス
CloudWatch Observability EKS アドオンのバージョン `v2.0.1-eksbuild.1` 以降、Amazon EKS 用にオブザーバビリティが強化された Container Insights は、Amazon EKS クラスターから Amazon SageMaker AI HyperPod メトリクスを自動的に収集します。アドオンの詳細については、「[Amazon CloudWatch Observability EKS アドオンまたは Helm チャートを使用して CloudWatch エージェントをインストールする](install-CloudWatch-Observability-EKS-addon.md)」を参照してください。Amazon SageMaker AI HyperPod の詳細については、「[Amazon SageMaker AI HyperPod](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks.html)」を参照してください。
収集されるメトリクスのリストを次の表に示します。
| メトリクス名 | ディメンション | 説明 |
| --- | --- | --- |
| `hyperpod_node_health_status_unschedulable` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノードが Amazon SageMaker AI HyperPod によって `Unschedulable` としてラベル付けされているかどうかを示します。これは、ノードがディープヘルスチェックを実行しており、実行中のワークロードでは使用できないことを意味します。 単位: 数 |
| `hyperpod_node_health_status_schedulable` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノードが Amazon SageMaker AI HyperPod によって `Schedulable` としてラベル付けされているかどうかを示します。これは、ノードが基本的なヘルスチェックまたはディープヘルスチェックに合格し、実行中のワークロードで使用できることを意味します。 単位: 数 |
| `hyperpod_node_health_status_unschedulable_pending_replacement` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノードが HyperPod によって `UnschedulablePendingReplacement` としてラベル付けされているかどうかを示します。これは、ノードがディープヘルスチェックまたはヘルスモニタリングエージェントチェックで不合格となり、置き換えが必要であることを意味します。 自動ノード復旧が有効になっている場合、ノードは自動的に Amazon SageMaker AI HyperPod に置き換えられます。 単位: 数 |
| `hyperpod_node_health_status_unschedulable_pending_reboot` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノードが Amazon SageMaker AI HyperPod によって `UnschedulablePendingReboot` としてラベル付けされているかどうかを示します。これは、ノードがディープヘルスチェックを実行しており、再起動が必要であることを意味します。 自動ノード復旧が有効になっている場合、ノードは Amazon SageMaker AI HyperPod によって自動的に再起動されます。 単位: 数 |
## Amazon EBS NVMe ドライバーメトリクス
CloudWatch エージェントのバージョン ` 1.300056.0` 以降、Amazon EKS 用にオブザーバビリティが強化された Container Insights は、Linux インスタンス上の Amazon EKS クラスターから Amazon EBS NVMe ドライバーメトリクスを自動的に収集します。CloudWatch エージェントは、CloudWatch Observability Amazon EKS アドオンのバージョン `4.1.0` 以降を使用してインストールする必要があります。アドオンの詳細については、「[Amazon CloudWatch Observability EKS アドオンまたは Helm チャートを使用して CloudWatch エージェントをインストールする](install-CloudWatch-Observability-EKS-addon.md)」を参照してください。Amazon EBS の詳細については、「[Amazon EBS の詳細なパフォーマンス統計](https://docs.aws.amazon.com/ebs/latest/userguide/nvme-detailed-performance-stats.html)」を参照してください。
Container Insights が Amazon EBS NVMe ドライバーメトリクスを収集するには、次の前提条件を満たす必要があります。
+ Amazon EKS 用にオブザーバビリティが強化された Container Insights を使用するには、CloudWatch Observability Amazon EKS アドオンバージョン `4.1.0` 以降を使用する必要があります。
+ EBS CSI ドライバー `1.42.0` アドオンまたは Helm チャートは、メトリクスが有効になっているクラスターにインストールする必要があります。
+ Amazon EBS CSI ドライバーアドオンを使用している場合にメトリクスを有効にするには、アドオンを作成または更新するときに `--configuration-values '{ "node": { "enableMetrics": true } }'` オプションを使用します。
+ Helm チャートを使用している場合にメトリクスを有効にするには、アドオンを作成または更新するときに `--set node.enableMetrics=true` オプションを使用します。
収集されるメトリクスのリストを次の表に示します。
| メトリクス名 | ディメンション | 説明 |
| --- | --- | --- |
| `node_diskio_ebs_total_read_ops` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | 完了した読み取りオペレーションの合計回数。 |
| `node_diskio_ebs_total_write_ops` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | 完了した書き込みオペレーションの合計回数。 |
| `node_diskio_ebs_total_read_bytes` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | 転送された読み取りバイトの合計数。 |
| `node_diskio_ebs_total_write_bytes` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | 転送された書き込みバイトの合計数。 |
| `node_diskio_ebs_total_read_time` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | 完了したすべての読み取りオペレーションで費やされた合計時間 (マイクロ秒単位)。 |
| `node_diskio_ebs_total_write_time` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | 完了したすべての書き込みオペレーションで費やされた合計時間 (マイクロ秒単位)。 |
| `node_diskio_ebs_volume_performance_exceeded_iops` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | IOPS 需要がボリュームのプロビジョンド IOPS パフォーマンスを超えた合計時間 (マイクロ秒単位)。 |
| `node_diskio_ebs_volume_performance_exceeded_tp` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | スループット需要がボリュームのプロビジョンドスループットパフォーマンスを超えた合計時間 (マイクロ秒単位)。 |
| `node_diskio_ebs_ec2_instance_performance_exceeded_iops` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | EBS ボリュームがアタッチされた Amazon EC2 インスタンスの最大 IOPS パフォーマンスを超えた合計時間 (マイクロ秒単位)。 |
| `node_diskio_ebs_ec2_instance_performance_exceeded_tp` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | EBS ボリュームがアタッチされた Amazon EC2 インスタンスの最大スループットパフォーマンスを超えた合計時間 (マイクロ秒単位)。 |
| `node_diskio_ebs_volume_queue_length` | `ClusterName` `ClusterName`, `NodeName`, `InstanceId` `ClusterName`, `NodeName`, `InstanceId` `VolumeId` | 完了を待機している読み取りおよび書き込みオペレーションの数。 |
# Amazon EKS および Kubernetes Container Insights のメトリクス
以下の表は、Container Insights で収集する Amazon EKS および Kubernetes のメトリクスとディメンションを示しています。これらのメトリクスは `ContainerInsights` 名前空間にあります。詳細については、「[メトリクス](cloudwatch_concepts.md#Metric)」を参照してください。
コンソールに Container Insights メトリクスが表示されない場合は、Container Insights のセットアップが完了していることを確認します。メトリクスは、Container Insights が完全にセットアップされるまで表示されません。詳細については、「[Container Insights の設定](deploy-container-insights.md)」を参照してください。
| メトリクス名 | ディメンション | 説明 |
| --- | --- | --- |
| `cluster_failed_node_count` | `ClusterName` | クラスター内の失敗したワーカーノードの数。*ノードの状態*に何らかの問題がある場合は、そのノードは失敗したとみなされます。詳細については、Kubernetes ドキュメントの 「[Conditions (状態)](https://kubernetes.io/docs/concepts/architecture/nodes/#condition)」を参照してください。 |
| `cluster_node_count` | `ClusterName` | クラスター内のワーカーノードの総数。 |
| `namespace_number_of_running_pods` | `Namespace` `ClusterName` `ClusterName` | 使用しているディメンションによって指定されたリソースの名前空間ごとに実行されているポッドの数。 |
| `node_cpu_limit` | `ClusterName` | このクラスター内の単一のノードに割り当てることができる CPU ユニットの最大数。 |
| `node_cpu_reserved_capacity` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | ノードコンポーネント (kubelet、kube-proxy、Docker など) に予約されている CPU ユニットの割合。 計算式: `node_cpu_request / node_cpu_limit` `node_cpu_request` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `node_cpu_usage_total` | `ClusterName` | クラスターのノードで使用されている CPU ユニットの数。 |
| `node_cpu_utilization` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | クラスター内のノードで使用されている CPU ユニットの合計使用率。 計算式: `node_cpu_usage_total / node_cpu_limit` |
| `node_gpu_limit` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノードで使用可能な GPU の合計数。 |
| `node_gpu_usage_total` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノードで実行中のポッドによって使用されている GPU の数。 |
| `node_gpu_reserved_capacity` | `ClusterName` `ClusterName`, `InstanceId`, `NodeName` | ノードで現在予約されている GPU の割合。式は `node_gpu_request / node_gpu_limit` です。 `node_gpu_request` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `node_filesystem_utilization` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | クラスター内のノードで使用されているファイルシステム容量の合計使用率。 計算式: `node_filesystem_usage / node_filesystem_capacity` `node_filesystem_usage` および `node_filesystem_capacity` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `node_memory_limit` | `ClusterName` | このクラスター内の単一のノードに割り当てることができるメモリの最大量 (バイト単位)。 |
| `node_memory_reserved_capacity` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | クラスター内のノードで現在使用されているメモリの割合。 計算式: `node_memory_request / node_memory_limit` `node_memory_request` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `node_memory_utilization` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | ノードによって現在使用されているメモリの割合。これは、ノードのメモリ制限で割られたノードのメモリ使用量の割合です。 計算式: `node_memory_working_set / node_memory_limit` |
| `node_memory_working_set` | `ClusterName` | クラスターで現在稼働しているノードのセットで使用されているメモリの量 (バイト単位)。 |
| `node_network_total_bytes` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | クラスターのノードごとにネットワーク経由で送信および受信された合計バイト数。 計算式: `node_network_rx_bytes + node_network_tx_bytes` `node_network_rx_bytes` および `node_network_tx_bytes` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `node_number_of_running_containers` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | クラスターのノードごとに実行中のコンテナの数。 |
| `node_number_of_running_pods` | `NodeName`, `ClusterName`, `InstanceId` `ClusterName` | クラスターのノードごとに実行中のポッドの数。 |
| `pod_cpu_reserved_capacity` | `PodName`, `Namespace`, `ClusterName` `ClusterName` | クラスターのポッドごとに予約されている CPU 容量。 計算式: `pod_cpu_request / node_cpu_limit` `pod_cpu_request` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `pod_cpu_utilization` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` | ポッドで使用されている CPU ユニットの割合。 計算式: `pod_cpu_usage_total / node_cpu_limit` |
| `pod_cpu_utilization_over_pod_limit` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` | ポッドの制限に対する、ポッドで使用されている CPU ユニットの割合。 計算式: `pod_cpu_usage_total / pod_cpu_limit` |
| `pod_gpu_request` | `ClusterName` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `FullPodName`, `Namespace`, `PodName` | ポッドの GPU リクエスト。この値は常に `pod_gpu_limit` と等しいことが必要です。 |
| `pod_gpu_limit` | `ClusterName` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `FullPodName`, `Namespace`, `PodName` | ノード内のポッドに割り当てることができる GPU の最大数。 |
| `pod_gpu_usage_total` | `ClusterName` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `FullPodName`, `Namespace`, `PodName` | ポッドに割り当てられる GPU の数。 |
| `pod_gpu_reserved_capacity` | `ClusterName` `ClusterName`, `Namespace`, `PodName` `ClusterName`, `FullPodName`, `Namespace`, `PodName` | 現在ポッド用に予約されている GPU の割合。式は pod\$1gpu\$1request / node\$1gpu\$1reserved\$1capacity です。 |
| `pod_memory_reserved_capacity` | `PodName`, `Namespace`, `ClusterName` `ClusterName` | ポッド用に予約されているメモリの割合。 計算式: `pod_memory_request / node_memory_limit` `pod_memory_request` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `pod_memory_utilization` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` | ポッドが現在使用しているメモリの割合。 計算式: `pod_memory_working_set / node_memory_limit` |
| `pod_memory_utilization_over_pod_limit` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` | ポッドの制限に対する、ポッドで使用されているメモリの割合。ポッドのいずれかのコンテナに、定義されたメモリ制限がない場合、このメトリクスは表示されません。 計算式: `pod_memory_working_set / pod_memory_limit` |
| `pod_network_rx_bytes` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` | ポッドによって、ネットワーク経由で受信されているバイト数。 計算式: `sum(pod_interface_network_rx_bytes)` `pod_interface_network_rx_bytes` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `pod_network_tx_bytes` | `PodName`, `Namespace`, `ClusterName` `Namespace`, `ClusterName` `Service`, `Namespace`, `ClusterName` `ClusterName` | ポッドによって、ネットワーク経由で送信されているバイト数。 計算式: `sum(pod_interface_network_tx_bytes)` `pod_interface_network_tx_bytes` はメトリクスとして直接報告されませんが、パフォーマンスログイベント内のフィールドです。詳細については、「[Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)」を参照してください。 |
| `pod_number_of_container_restarts` | `PodName`, `Namespace`, `ClusterName` | ポッドでのコンテナ再起動の合計数。 |
| `service_number_of_running_pods` | `Service`, `Namespace`, `ClusterName` `ClusterName` | クラスターでサービス (1 つまたは複数) を実行しているポッドの数。 |
## Kueue メトリクス
CloudWatch Observability EKS アドオンのバージョン `v2.4.0-eksbuild.1` 以降、Container Insights for Amazon EKS は Amazon EKS クラスターから Kueue メトリクスの収集をサポートします。アドオンの詳細については、「[Amazon CloudWatch Observability EKS アドオンまたは Helm チャートを使用して CloudWatch エージェントをインストールする](install-CloudWatch-Observability-EKS-addon.md)」を参照してください。
メトリクスを有効にする方法の詳細については、「[Kueue メトリクスの有効化](install-CloudWatch-Observability-EKS-addon.md#enable-Kueue-metrics)」を参照して有効にしてください。
収集される Kueue メトリクスは、次の表に一覧表示されます。これらのメトリクスは、CloudWatch の `ContainerInsights/Prometheus` 名前空間内で発行されます。これらのメトリクスの一部は次のディメンションを使用します。
+ `ClusterQueue` は ClusterQueue の名前です
+ `Status` の想定される値は `active` および `inadmissible` です
+ `Reason` の想定される値は `Preempted`、`PodsReadyTimeout`、`AdmissionCheck`、`ClusterQueueStopped`、`InactiveWorkload` です
+ `Flavor` は参照されるフレーバーです。
+ `Resource` は `cpu`、`memory`、`gpu` などのクラスターコンピュータリソースを指します。
| メトリクス名 | ディメンション | 説明 |
| --- | --- | --- |
| `kueue_pending_workloads` | `ClusterName`, `ClusterQueue`, `Status` `ClusterName`, `ClusterQueue` `ClusterName`, `Status` `ClusterName` | 保留中のワークロードの数。 |
| `kueue_evicted_workloads_total` | `ClusterName`, `ClusterQueue`, `Reason` `ClusterName`, `ClusterQueue` `ClusterName`, `Reason` `ClusterName` | 削除されたワークロードの合計数。 |
| `kueue_admitted_active_workloads` | `ClusterName`, `ClusterQueue` `ClusterName` | アクティブな許可されたワークロードの数 (停止されておらず、完了していないもの)。 |
| `kueue_cluster_queue_resource_usage` | `ClusterName`, `ClusterQueue`, `Resource`, `Flavor` `ClusterName`, `ClusterQueue`, `Resource` `ClusterName`, `ClusterQueue`, `Flavor` `ClusterName`, `ClusterQueue` `ClusterName` | ClusterQueue のリソース使用量の合計をレポートします。 |
| `kueue_cluster_queue_nominal_quota` | `ClusterName`, `ClusterQueue`, `Resource`, `Flavor` `ClusterName`, `ClusterQueue`, `Resource` `ClusterName`, `ClusterQueue`, `Flavor` `ClusterName`, `ClusterQueue` `ClusterName` | ClusterQueue のリソースクォータをレポートします。 |
# Container Insights パフォーマンスログリファレンス
このセクションには、Container Insights がパフォーマンスログイベントを使用してメトリクスを収集する方法に関するリファレンス情報が含まれています。Container Insights をデプロイする場合、パフォーマンスログイベント用のロググループが自動的に作成されます。このロググループを手動で作成する必要はありません。
**Topics**
+ [Amazon ECS の Container Insights パフォーマンスログイベント](Container-Insights-reference-performance-logs-ECS.md)
+ [Amazon EKS および Kubernetes の Container Insights パフォーマンスログイベント](Container-Insights-reference-performance-logs-EKS.md)
+ [Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド](Container-Insights-reference-performance-entries-EKS.md)
# Amazon ECS の Container Insights パフォーマンスログイベント
次に、Container Insights が Amazon ECS から収集するパフォーマンスログイベントの例を示します。
これらのログは、CloudWatch Logs の `/aws/ecs/containerinsights/CLUSTER_NAME/performance` という名前のロググループにあります。そのロググループ内では、各コンテナインスタンスに `AgentTelemetry-CONTAINER_INSTANCE_ID` という名前のログストリームがあります。
すべてのコンテナログイベントを表示する `{ $.Type = "Container" }` などのクエリを使用して、これらのログをクエリできます。
**型: コンテナ**
```
{
"Version":"0",
"Type":"Container",
"ContainerName":"sleep",
"TaskId":"7ac4dfba69214411b4783a3b8189c9ba",
"TaskDefinitionFamily":"sleep360",
"TaskDefinitionRevision":"1",
"ContainerInstanceId":"0d7650e6dec34c1a9200f72098071e8f",
"EC2InstanceId":"i-0c470579dbcdbd2f3",
"ClusterName":"MyCluster",
"Image":"busybox",
"ContainerKnownStatus":"RUNNING",
"Timestamp":1623963900000,
"CpuUtilized":0.0,
"CpuReserved":10.0,
"MemoryUtilized":0,
"MemoryReserved":10,
"StorageReadBytes":0,
"StorageWriteBytes":0,
"NetworkRxBytes":0,
"NetworkRxDropped":0,
"NetworkRxErrors":0,
"NetworkRxPackets":14,
"NetworkTxBytes":0,
"NetworkTxDropped":0,
"NetworkTxErrors":0,
"NetworkTxPackets":0
}
```
**型: タスク**
`StorageReadBytes` および `StorageWriteBytes` の単位はバイト/秒ですが、値はそれぞれストレージから読み取られたバイト数とストレージに書き込まれたバイト数の累計を表します。
```
{
"Version": "0",
"Type": "Task",
"TaskId": "7ac4dfba69214411b4783a3b8189c9ba",
"TaskDefinitionFamily": "sleep360",
"TaskDefinitionRevision": "1",
"ContainerInstanceId": "0d7650e6dec34c1a9200f72098071e8f",
"EC2InstanceId": "i-0c470579dbcdbd2f3",
"ClusterName": "MyCluster",
"AccountID": "637146863587",
"Region": "us-west-2",
"AvailabilityZone": "us-west-2b",
"KnownStatus": "RUNNING",
"LaunchType": "EC2",
"PullStartedAt": 1623963608201,
"PullStoppedAt": 1623963610065,
"CreatedAt": 1623963607094,
"StartedAt": 1623963610382,
"Timestamp": 1623963900000,
"CpuUtilized": 0.0,
"CpuReserved": 10.0,
"MemoryUtilized": 0,
"MemoryReserved": 10,
"StorageReadBytes": 0,
"StorageWriteBytes": 0,
"NetworkRxBytes": 0,
"NetworkRxDropped": 0,
"NetworkRxErrors": 0,
"NetworkRxPackets": 14,
"NetworkTxBytes": 0,
"NetworkTxDropped": 0,
"NetworkTxErrors": 0,
"NetworkTxPackets": 0,
"EBSFilesystemUtilized": 10,
"EBSFilesystemSize": 20,
"CloudWatchMetrics": [
{
"Namespace": "ECS/ContainerInsights",
"Metrics": [
{
"Name": "CpuUtilized",
"Unit": "None"
},
{
"Name": "CpuReserved",
"Unit": "None"
},
{
"Name": "MemoryUtilized",
"Unit": "Megabytes"
},
{
"Name": "MemoryReserved",
"Unit": "Megabytes"
},
{
"Name": "StorageReadBytes",
"Unit": "Bytes/Second"
},
{
"Name": "StorageWriteBytes",
"Unit": "Bytes/Second"
},
{
"Name": "NetworkRxBytes",
"Unit": "Bytes/Second"
},
{
"Name": "NetworkTxBytes",
"Unit": "Bytes/Second"
},
{
"Name": "EBSFilesystemSize",
"Unit": "Gigabytes"
},
{
"Name": "EBSFilesystemUtilzed",
"Unit": "Gigabytes"
}
],
"Dimensions": [
["ClusterName"],
[
"ClusterName",
"TaskDefinitionFamily"
]
]
}
]
}
```
**タイプ: Service**
```
{
"Version": "0",
"Type": "Service",
"ServiceName": "myCIService",
"ClusterName": "myCICluster",
"Timestamp": 1561586460000,
"DesiredTaskCount": 2,
"RunningTaskCount": 2,
"PendingTaskCount": 0,
"DeploymentCount": 1,
"TaskSetCount": 0,
"CloudWatchMetrics": [
{
"Namespace": "ECS/ContainerInsights",
"Metrics": [
{
"Name": "DesiredTaskCount",
"Unit": "Count"
},
{
"Name": "RunningTaskCount",
"Unit": "Count"
},
{
"Name": "PendingTaskCount",
"Unit": "Count"
},
{
"Name": "DeploymentCount",
"Unit": "Count"
},
{
"Name": "TaskSetCount",
"Unit": "Count"
}
],
"Dimensions": [
[
"ServiceName",
"ClusterName"
]
]
}
]
}
```
**タイプ: ボリューム**
```
{
"Version": "0",
"Type": "Volume",
"TaskDefinitionFamily": "myCITaskDef",
"TaskId": "7ac4dfba69214411b4783a3b8189c9ba",
"ClusterName": "myCICluster",
"ServiceName": "myCIService",
"VolumeId": "vol-1233436545ff708cb",
"InstanceId": "i-0c470579dbcdbd2f3",
"LaunchType": "EC2",
"VolumeName": "MyVolumeName",
"EBSFilesystemUtilized": 10,
"EBSFilesystemSize": 20,
"CloudWatchMetrics": [
{
"Namespace": "ECS/ContainerInsights",
"Metrics": [
{
"Name": "EBSFilesystemSize",
"Unit": "Gigabytes"
},
{
"Name": "EBSFilesystemUtilzed",
"Unit": "Gigabytes"
}
],
"Dimensions": [
["ClusterName"],
[
"VolumeName",
"TaskDefinitionFamily",
"ClusterName"
],
[
"ServiceName",
"ClusterName"
]
]
}
]
}
```
**型: クラスター**
```
{
"Version": "0",
"Type": "Cluster",
"ClusterName": "myCICluster",
"Timestamp": 1561587300000,
"TaskCount": 5,
"ContainerInstanceCount": 5,
"ServiceCount": 2,
"CloudWatchMetrics": [
{
"Namespace": "ECS/ContainerInsights",
"Metrics": [
{
"Name": "TaskCount",
"Unit": "Count"
},
{
"Name": "ContainerInstanceCount",
"Unit": "Count"
},
{
"Name": "ServiceCount",
"Unit": "Count"
}
],
"Dimensions": [
[
"ClusterName"
]
]
}
]
}
```
# Amazon EKS および Kubernetes の Container Insights パフォーマンスログイベント
次に、Container Insights が Amazon EKS および Kubernetes から収集するパフォーマンスログイベントの例を示します。
**タイプ: Node**
```
{
"AutoScalingGroupName": "eksctl-myCICluster-nodegroup-standard-workers-NodeGroup-1174PV2WHZAYU",
"CloudWatchMetrics": [
{
"Metrics": [
{
"Unit": "Percent",
"Name": "node_cpu_utilization"
},
{
"Unit": "Percent",
"Name": "node_memory_utilization"
},
{
"Unit": "Bytes/Second",
"Name": "node_network_total_bytes"
},
{
"Unit": "Percent",
"Name": "node_cpu_reserved_capacity"
},
{
"Unit": "Percent",
"Name": "node_memory_reserved_capacity"
},
{
"Unit": "Count",
"Name": "node_number_of_running_pods"
},
{
"Unit": "Count",
"Name": "node_number_of_running_containers"
}
],
"Dimensions": [
[
"NodeName",
"InstanceId",
"ClusterName"
]
],
"Namespace": "ContainerInsights"
},
{
"Metrics": [
{
"Unit": "Percent",
"Name": "node_cpu_utilization"
},
{
"Unit": "Percent",
"Name": "node_memory_utilization"
},
{
"Unit": "Bytes/Second",
"Name": "node_network_total_bytes"
},
{
"Unit": "Percent",
"Name": "node_cpu_reserved_capacity"
},
{
"Unit": "Percent",
"Name": "node_memory_reserved_capacity"
},
{
"Unit": "Count",
"Name": "node_number_of_running_pods"
},
{
"Unit": "Count",
"Name": "node_number_of_running_containers"
},
{
"Name": "node_cpu_usage_total"
},
{
"Name": "node_cpu_limit"
},
{
"Unit": "Bytes",
"Name": "node_memory_working_set"
},
{
"Unit": "Bytes",
"Name": "node_memory_limit"
}
],
"Dimensions": [
[
"ClusterName"
]
],
"Namespace": "ContainerInsights"
}
],
"ClusterName": "myCICluster",
"InstanceId": "i-1234567890123456",
"InstanceType": "t3.xlarge",
"NodeName": "ip-192-0-2-0.us-west-2.compute.internal",
"Sources": [
"cadvisor",
"/proc",
"pod",
"calculated"
],
"Timestamp": "1567096682364",
"Type": "Node",
"Version": "0",
"kubernetes": {
"host": "ip-192-168-75-26.us-west-2.compute.internal"
},
"node_cpu_limit": 4000,
"node_cpu_request": 1130,
"node_cpu_reserved_capacity": 28.249999999999996,
"node_cpu_usage_system": 33.794636630852764,
"node_cpu_usage_total": 136.47852169244098,
"node_cpu_usage_user": 71.67075111567326,
"node_cpu_utilization": 3.4119630423110245,
"node_memory_cache": 3103297536,
"node_memory_failcnt": 0,
"node_memory_hierarchical_pgfault": 0,
"node_memory_hierarchical_pgmajfault": 0,
"node_memory_limit": 16624865280,
"node_memory_mapped_file": 406646784,
"node_memory_max_usage": 4230746112,
"node_memory_pgfault": 0,
"node_memory_pgmajfault": 0,
"node_memory_request": 1115684864,
"node_memory_reserved_capacity": 6.7109407818311055,
"node_memory_rss": 798146560,
"node_memory_swap": 0,
"node_memory_usage": 3901444096,
"node_memory_utilization": 6.601302600149552,
"node_memory_working_set": 1097457664,
"node_network_rx_bytes": 35918.392817386324,
"node_network_rx_dropped": 0,
"node_network_rx_errors": 0,
"node_network_rx_packets": 157.67565245448117,
"node_network_total_bytes": 68264.20276554905,
"node_network_tx_bytes": 32345.80994816272,
"node_network_tx_dropped": 0,
"node_network_tx_errors": 0,
"node_network_tx_packets": 154.21455923431654,
"node_number_of_running_containers": 16,
"node_number_of_running_pods": 13
}
```
**タイプ: NodeFS**
```
{
"AutoScalingGroupName": "eksctl-myCICluster-nodegroup-standard-workers-NodeGroup-1174PV2WHZAYU",
"CloudWatchMetrics": [
{
"Metrics": [
{
"Unit": "Percent",
"Name": "node_filesystem_utilization"
}
],
"Dimensions": [
[
"NodeName",
"InstanceId",
"ClusterName"
],
[
"ClusterName"
]
],
"Namespace": "ContainerInsights"
}
],
"ClusterName": "myCICluster",
"EBSVolumeId": "aws://us-west-2b/vol-0a53108976d4a2fda",
"InstanceId": "i-1234567890123456",
"InstanceType": "t3.xlarge",
"NodeName": "ip-192-0-2-0.us-west-2.compute.internal",
"Sources": [
"cadvisor",
"calculated"
],
"Timestamp": "1567097939726",
"Type": "NodeFS",
"Version": "0",
"device": "/dev/nvme0n1p1",
"fstype": "vfs",
"kubernetes": {
"host": "ip-192-168-75-26.us-west-2.compute.internal"
},
"node_filesystem_available": 17298395136,
"node_filesystem_capacity": 21462233088,
"node_filesystem_inodes": 10484720,
"node_filesystem_inodes_free": 10367158,
"node_filesystem_usage": 4163837952,
"node_filesystem_utilization": 19.400767547940255
}
```
**タイプ: NodeDiskIO**
```
{
"AutoScalingGroupName": "eksctl-myCICluster-nodegroup-standard-workers-NodeGroup-1174PV2WHZAYU",
"ClusterName": "myCICluster",
"EBSVolumeId": "aws://us-west-2b/vol-0a53108976d4a2fda",
"InstanceId": "i-1234567890123456",
"InstanceType": "t3.xlarge",
"NodeName": "ip-192-0-2-0.us-west-2.compute.internal",
"Sources": [
"cadvisor"
],
"Timestamp": "1567096928131",
"Type": "NodeDiskIO",
"Version": "0",
"device": "/dev/nvme0n1",
"kubernetes": {
"host": "ip-192-168-75-26.us-west-2.compute.internal"
},
"node_diskio_io_service_bytes_async": 9750.505814277016,
"node_diskio_io_service_bytes_read": 0,
"node_diskio_io_service_bytes_sync": 230.6174506688036,
"node_diskio_io_service_bytes_total": 9981.123264945818,
"node_diskio_io_service_bytes_write": 9981.123264945818,
"node_diskio_io_serviced_async": 1.153087253344018,
"node_diskio_io_serviced_read": 0,
"node_diskio_io_serviced_sync": 0.03603397666700056,
"node_diskio_io_serviced_total": 1.1891212300110185,
"node_diskio_io_serviced_write": 1.1891212300110185
}
```
**タイプ: NodeNet**
```
{
"AutoScalingGroupName": "eksctl-myCICluster-nodegroup-standard-workers-NodeGroup-1174PV2WHZAYU",
"ClusterName": "myCICluster",
"InstanceId": "i-1234567890123456",
"InstanceType": "t3.xlarge",
"NodeName": "ip-192-0-2-0.us-west-2.compute.internal",
"Sources": [
"cadvisor",
"calculated"
],
"Timestamp": "1567096928131",
"Type": "NodeNet",
"Version": "0",
"interface": "eni972f6bfa9a0",
"kubernetes": {
"host": "ip-192-168-75-26.us-west-2.compute.internal"
},
"node_interface_network_rx_bytes": 3163.008420864309,
"node_interface_network_rx_dropped": 0,
"node_interface_network_rx_errors": 0,
"node_interface_network_rx_packets": 16.575629266820258,
"node_interface_network_total_bytes": 3518.3935157426017,
"node_interface_network_tx_bytes": 355.385094878293,
"node_interface_network_tx_dropped": 0,
"node_interface_network_tx_errors": 0,
"node_interface_network_tx_packets": 3.9997714100370625
}
```
**タイプ: Pod**
```
{
"AutoScalingGroupName": "eksctl-myCICluster-nodegroup-standard-workers-NodeGroup-1174PV2WHZAYU",
"CloudWatchMetrics": [
{
"Metrics": [
{
"Unit": "Percent",
"Name": "pod_cpu_utilization"
},
{
"Unit": "Percent",
"Name": "pod_memory_utilization"
},
{
"Unit": "Bytes/Second",
"Name": "pod_network_rx_bytes"
},
{
"Unit": "Bytes/Second",
"Name": "pod_network_tx_bytes"
},
{
"Unit": "Percent",
"Name": "pod_cpu_utilization_over_pod_limit"
},
{
"Unit": "Percent",
"Name": "pod_memory_utilization_over_pod_limit"
}
],
"Dimensions": [
[
"PodName",
"Namespace",
"ClusterName"
],
[
"Service",
"Namespace",
"ClusterName"
],
[
"Namespace",
"ClusterName"
],
[
"ClusterName"
]
],
"Namespace": "ContainerInsights"
},
{
"Metrics": [
{
"Unit": "Percent",
"Name": "pod_cpu_reserved_capacity"
},
{
"Unit": "Percent",
"Name": "pod_memory_reserved_capacity"
}
],
"Dimensions": [
[
"PodName",
"Namespace",
"ClusterName"
],
[
"ClusterName"
]
],
"Namespace": "ContainerInsights"
},
{
"Metrics": [
{
"Unit": "Count",
"Name": "pod_number_of_container_restarts"
}
],
"Dimensions": [
[
"PodName",
"Namespace",
"ClusterName"
]
],
"Namespace": "ContainerInsights"
}
],
"ClusterName": "myCICluster",
"InstanceId": "i-1234567890123456",
"InstanceType": "t3.xlarge",
"Namespace": "amazon-cloudwatch",
"NodeName": "ip-192-0-2-0.us-west-2.compute.internal",
"PodName": "cloudwatch-agent-statsd",
"Service": "cloudwatch-agent-statsd",
"Sources": [
"cadvisor",
"pod",
"calculated"
],
"Timestamp": "1567097351092",
"Type": "Pod",
"Version": "0",
"kubernetes": {
"host": "ip-192-168-75-26.us-west-2.compute.internal",
"labels": {
"app": "cloudwatch-agent-statsd",
"pod-template-hash": "df44f855f"
},
"namespace_name": "amazon-cloudwatch",
"pod_id": "2f4ff5ac-c813-11e9-a31d-06e9dde32928",
"pod_name": "cloudwatch-agent-statsd-df44f855f-ts4q2",
"pod_owners": [
{
"owner_kind": "Deployment",
"owner_name": "cloudwatch-agent-statsd"
}
],
"service_name": "cloudwatch-agent-statsd"
},
"pod_cpu_limit": 200,
"pod_cpu_request": 200,
"pod_cpu_reserved_capacity": 5,
"pod_cpu_usage_system": 1.4504841104992765,
"pod_cpu_usage_total": 5.817016867430125,
"pod_cpu_usage_user": 1.1281543081661038,
"pod_cpu_utilization": 0.14542542168575312,
"pod_cpu_utilization_over_pod_limit": 2.9085084337150624,
"pod_memory_cache": 8192,
"pod_memory_failcnt": 0,
"pod_memory_hierarchical_pgfault": 0,
"pod_memory_hierarchical_pgmajfault": 0,
"pod_memory_limit": 104857600,
"pod_memory_mapped_file": 0,
"pod_memory_max_usage": 25268224,
"pod_memory_pgfault": 0,
"pod_memory_pgmajfault": 0,
"pod_memory_request": 104857600,
"pod_memory_reserved_capacity": 0.6307275170893897,
"pod_memory_rss": 22777856,
"pod_memory_swap": 0,
"pod_memory_usage": 25141248,
"pod_memory_utilization": 0.10988455961791709,
"pod_memory_utilization_over_pod_limit": 17.421875,
"pod_memory_working_set": 18268160,
"pod_network_rx_bytes": 9880.697124714186,
"pod_network_rx_dropped": 0,
"pod_network_rx_errors": 0,
"pod_network_rx_packets": 107.80005532263283,
"pod_network_total_bytes": 10158.829201483635,
"pod_network_tx_bytes": 278.13207676944796,
"pod_network_tx_dropped": 0,
"pod_network_tx_errors": 0,
"pod_network_tx_packets": 1.146027574644318,
"pod_number_of_container_restarts": 0,
"pod_number_of_containers": 1,
"pod_number_of_running_containers": 1,
"pod_status": "Running"
}
```
**タイプ: PodNet**
```
{
"AutoScalingGroupName": "eksctl-myCICluster-nodegroup-standard-workers-NodeGroup-1174PV2WHZAYU",
"ClusterName": "myCICluster",
"InstanceId": "i-1234567890123456",
"InstanceType": "t3.xlarge",
"Namespace": "amazon-cloudwatch",
"NodeName": "ip-192-0-2-0.us-west-2.compute.internal",
"PodName": "cloudwatch-agent-statsd",
"Service": "cloudwatch-agent-statsd",
"Sources": [
"cadvisor",
"calculated"
],
"Timestamp": "1567097351092",
"Type": "PodNet",
"Version": "0",
"interface": "eth0",
"kubernetes": {
"host": "ip-192-168-75-26.us-west-2.compute.internal",
"labels": {
"app": "cloudwatch-agent-statsd",
"pod-template-hash": "df44f855f"
},
"namespace_name": "amazon-cloudwatch",
"pod_id": "2f4ff5ac-c813-11e9-a31d-06e9dde32928",
"pod_name": "cloudwatch-agent-statsd-df44f855f-ts4q2",
"pod_owners": [
{
"owner_kind": "Deployment",
"owner_name": "cloudwatch-agent-statsd"
}
],
"service_name": "cloudwatch-agent-statsd"
},
"pod_interface_network_rx_bytes": 9880.697124714186,
"pod_interface_network_rx_dropped": 0,
"pod_interface_network_rx_errors": 0,
"pod_interface_network_rx_packets": 107.80005532263283,
"pod_interface_network_total_bytes": 10158.829201483635,
"pod_interface_network_tx_bytes": 278.13207676944796,
"pod_interface_network_tx_dropped": 0,
"pod_interface_network_tx_errors": 0,
"pod_interface_network_tx_packets": 1.146027574644318
}
```
**型: コンテナ**
```
{
"AutoScalingGroupName": "eksctl-myCICluster-nodegroup-standard-workers-NodeGroup-sample",
"ClusterName": "myCICluster",
"InstanceId": "i-1234567890123456",
"InstanceType": "t3.xlarge",
"Namespace": "amazon-cloudwatch",
"NodeName": "ip-192-0-2-0.us-west-2.compute.internal",
"PodName": "cloudwatch-agent-statsd",
"Service": "cloudwatch-agent-statsd",
"Sources": [
"cadvisor",
"pod",
"calculated"
],
"Timestamp": "1567097399912",
"Type": "Container",
"Version": "0",
"container_cpu_limit": 200,
"container_cpu_request": 200,
"container_cpu_usage_system": 1.87958283771964,
"container_cpu_usage_total": 6.159993652997942,
"container_cpu_usage_user": 1.6707403001952357,
"container_cpu_utilization": 0.15399984132494854,
"container_memory_cache": 8192,
"container_memory_failcnt": 0,
"container_memory_hierarchical_pgfault": 0,
"container_memory_hierarchical_pgmajfault": 0,
"container_memory_limit": 104857600,
"container_memory_mapped_file": 0,
"container_memory_max_usage": 24580096,
"container_memory_pgfault": 0,
"container_memory_pgmajfault": 0,
"container_memory_request": 104857600,
"container_memory_rss": 22736896,
"container_memory_swap": 0,
"container_memory_usage": 24453120,
"container_memory_utilization": 0.10574541028701798,
"container_memory_working_set": 17580032,
"container_status": "Running",
"kubernetes": {
"container_name": "cloudwatch-agent",
"docker": {
"container_id": "8967b6b37da239dfad197c9fdea3e5dfd35a8a759ec86e2e4c3f7b401e232706"
},
"host": "ip-192-168-75-26.us-west-2.compute.internal",
"labels": {
"app": "cloudwatch-agent-statsd",
"pod-template-hash": "df44f855f"
},
"namespace_name": "amazon-cloudwatch",
"pod_id": "2f4ff5ac-c813-11e9-a31d-06e9dde32928",
"pod_name": "cloudwatch-agent-statsd-df44f855f-ts4q2",
"pod_owners": [
{
"owner_kind": "Deployment",
"owner_name": "cloudwatch-agent-statsd"
}
],
"service_name": "cloudwatch-agent-statsd"
},
"number_of_container_restarts": 0
}
```
**タイプ: ContainerFS**
```
{
"AutoScalingGroupName": "eksctl-myCICluster-nodegroup-standard-workers-NodeGroup-1174PV2WHZAYU",
"ClusterName": "myCICluster",
"EBSVolumeId": "aws://us-west-2b/vol-0a53108976d4a2fda",
"InstanceId": "i-1234567890123456",
"InstanceType": "t3.xlarge",
"Namespace": "amazon-cloudwatch",
"NodeName": "ip-192-0-2-0.us-west-2.compute.internal",
"PodName": "cloudwatch-agent-statsd",
"Service": "cloudwatch-agent-statsd",
"Sources": [
"cadvisor",
"calculated"
],
"Timestamp": "1567097399912",
"Type": "ContainerFS",
"Version": "0",
"device": "/dev/nvme0n1p1",
"fstype": "vfs",
"kubernetes": {
"container_name": "cloudwatch-agent",
"docker": {
"container_id": "8967b6b37da239dfad197c9fdea3e5dfd35a8a759ec86e2e4c3f7b401e232706"
},
"host": "ip-192-168-75-26.us-west-2.compute.internal",
"labels": {
"app": "cloudwatch-agent-statsd",
"pod-template-hash": "df44f855f"
},
"namespace_name": "amazon-cloudwatch",
"pod_id": "2f4ff5ac-c813-11e9-a31d-06e9dde32928",
"pod_name": "cloudwatch-agent-statsd-df44f855f-ts4q2",
"pod_owners": [
{
"owner_kind": "Deployment",
"owner_name": "cloudwatch-agent-statsd"
}
],
"service_name": "cloudwatch-agent-statsd"
}
}
```
**型: クラスター**
```
{
"CloudWatchMetrics": [
{
"Metrics": [
{
"Unit": "Count",
"Name": "cluster_node_count"
},
{
"Unit": "Count",
"Name": "cluster_failed_node_count"
}
],
"Dimensions": [
[
"ClusterName"
]
],
"Namespace": "ContainerInsights"
}
],
"ClusterName": "myCICluster",
"Sources": [
"apiserver"
],
"Timestamp": "1567097534160",
"Type": "Cluster",
"Version": "0",
"cluster_failed_node_count": 0,
"cluster_node_count": 3
}
```
**タイプ: ClusterService**
```
{
"CloudWatchMetrics": [
{
"Metrics": [
{
"Unit": "Count",
"Name": "service_number_of_running_pods"
}
],
"Dimensions": [
[
"Service",
"Namespace",
"ClusterName"
],
[
"ClusterName"
]
],
"Namespace": "ContainerInsights"
}
],
"ClusterName": "myCICluster",
"Namespace": "amazon-cloudwatch",
"Service": "cloudwatch-agent-statsd",
"Sources": [
"apiserver"
],
"Timestamp": "1567097534160",
"Type": "ClusterService",
"Version": "0",
"kubernetes": {
"namespace_name": "amazon-cloudwatch",
"service_name": "cloudwatch-agent-statsd"
},
"service_number_of_running_pods": 1
}
```
**タイプ: ClusterNamespace**
```
{
"CloudWatchMetrics": [
{
"Metrics": [
{
"Unit": "Count",
"Name": "namespace_number_of_running_pods"
}
],
"Dimensions": [
[
"Namespace",
"ClusterName"
],
[
"ClusterName"
]
],
"Namespace": "ContainerInsights"
}
],
"ClusterName": "myCICluster",
"Namespace": "amazon-cloudwatch",
"Sources": [
"apiserver"
],
"Timestamp": "1567097594160",
"Type": "ClusterNamespace",
"Version": "0",
"kubernetes": {
"namespace_name": "amazon-cloudwatch"
},
"namespace_number_of_running_pods": 7
}
```
# Amazon EKS と Kubernetes のパフォーマンスログイベントの関連フィールド
Amazon EKS および Kubernetes では、コンテナ化された CloudWatch エージェントは、パフォーマンスログイベントとしてデータを出力します。これにより、CloudWatch は高カーディナリティのデータを取り込み、保存することができます。CloudWatch は、パフォーマンスログイベントのデータを使用して、詳細を失うことなく、クラスター、ノード、ポッドレベルで、集計された CloudWatch メトリクスを作成します。
以下の表は、Container Insights メトリクスデータの収集に関連する、これらのパフォーマンスログイベントのフィールドを示しています。CloudWatch Logs Insights を使用して、これらの任意のフィールドをクエリし、データを収集したり、問題を調査したりできます。詳細については、「[CloudWatch Logs Insights を使用したログデータの分析](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)」を参照してください。
| タイプ | ログフィールド | 送信元 | 計算式またはコメント |
| --- | --- | --- | --- |
| ポッド | `pod_cpu_utilization` | 計算 | 計算式: `pod_cpu_usage_total / node_cpu_limit` |
| ポッド | `pod_cpu_usage_total` `pod_cpu_usage_total` はミリコア単位で報告されます。 | cadvisor | |
| ポッド | `pod_cpu_limit` | 計算 | 計算式: `sum(container_cpu_limit)` `sum(container_cpu_limit)` には、既に完成したポッドが含まれます。 ポッドのいずれかのコンテナで、定義された CPU 制限がない場合、このフィールドはログイベントに表示されません。これには[初期化コンテナ](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#resources)が含まれます。 |
| ポッド | `pod_cpu_request` | 計算 | 計算式: `sum(container_cpu_request)` `container_cpu_request` の設定は保証されません。設定されているもののみが合計に含まれます。 |
| ポッド | `pod_cpu_utilization_over_pod_limit` | 計算 | 計算式: `pod_cpu_usage_total / pod_cpu_limit` |
| ポッド | `pod_cpu_reserved_capacity` | 計算 | 計算式: `pod_cpu_request / node_cpu_limit` |
| ポッド | `pod_memory_utilization` | 計算 | 計算式: `pod_memory_working_set / node_memory_limit` これは、ノードのメモリ制限に対する Pod メモリ使用量の割合です。 |
| ポッド | `pod_memory_working_set` | cadvisor | |
| ポッド | `pod_memory_limit` | 計算 | 計算式: `sum(container_memory_limit)` ポッドのいずれかのコンテナに、定義されたメモリ制限がない場合、このフィールドはログイベントに表示されません。これには[初期化コンテナ](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#resources)が含まれます。 |
| ポッド | `pod_memory_request` | 計算 | 計算式: `sum(container_memory_request)` `container_memory_request` の設定は保証されません。設定されているもののみが合計に含まれます。 |
| ポッド | `pod_memory_utilization_over_pod_limit` | 計算 | 計算式: `pod_memory_working_set / pod_memory_limit` ポッドのいずれかのコンテナに、定義されたメモリ制限がない場合、このフィールドはログイベントに表示されません。これには[初期化コンテナ](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#resources)が含まれます。 |
| ポッド | `pod_memory_reserved_capacity` | 計算 | 計算式: `pod_memory_request / node_memory_limit` |
| ポッド | `pod_network_tx_bytes` | 計算 | 計算式: `sum(pod_interface_network_tx_bytes)` このデータは、ポッドごとにすべてのネットワークインターフェイスで使用できます。CloudWatch エージェントが合計を計算し、メトリクス抽出ルールを追加します。 |
| ポッド | `pod_network_rx_bytes` | 計算 | 計算式: `sum(pod_interface_network_rx_bytes)` |
| ポッド | `pod_network_total_bytes` | 計算 | 計算式: `pod_network_rx_bytes + pod_network_tx_bytes` |
| PodNet | `pod_interface_network_rx_bytes` | cadvisor | このデータは、ポッドネットワークインターフェイスの 1 秒あたりのネットワーク rx バイトです。 |
| PodNet | `pod_interface_network_tx_bytes` | cadvisor | このデータは、ポッドネットワークインターフェイスの 1 秒あたりのネットワーク tx バイトです。 |
| コンテナ | `container_cpu_usage_total` | cadvisor | |
| コンテナ | `container_cpu_limit` | cadvisor | 設定は保証されていません。設定されていない場合は出力されません。 |
| コンテナ | `container_cpu_request` | cadvisor | 設定は保証されていません。設定されていない場合は出力されません。 |
| コンテナ | `container_memory_working_set` | cadvisor | |
| コンテナ | `container_memory_limit` | ポッド | 設定は保証されていません。設定されていない場合は出力されません。 |
| コンテナ | `container_memory_request` | ポッド | 設定は保証されていません。設定されていない場合は出力されません。 |
| ノード | `node_cpu_utilization` | 計算 | 計算式: `node_cpu_usage_total / node_cpu_limit` |
| ノード | `node_cpu_usage_total` | cadvisor | |
| ノード | `node_cpu_limit` | /proc | |
| ノード | `node_cpu_request` | 計算 | 計算式: `sum(pod_cpu_request)` CronJob の場合、`node_cpu_request` には完了したポッドからのリクエストも含まれます。これにより、`node_cpu_reserved_capacity` の値が高くなる可能性があります。 |
| ノード | `node_cpu_reserved_capacity` | 計算 | 計算式: `node_cpu_request / node_cpu_limit` |
| ノード | `node_memory_utilization` | 計算 | 計算式: `node_memory_working_set / node_memory_limit` |
| ノード | `node_memory_working_set` | cadvisor | |
| ノード | `node_memory_limit` | /proc | |
| ノード | `node_memory_request` | 計算 | 計算式: `sum(pod_memory_request)` |
| ノード | `node_memory_reserved_capacity` | 計算 | 計算式: `node_memory_request / node_memory_limit` |
| ノード | `node_network_rx_bytes` | 計算 | 計算式: `sum(node_interface_network_rx_bytes)` |
| ノード | `node_network_tx_bytes` | 計算 | 計算式: `sum(node_interface_network_tx_bytes)` |
| ノード | `node_network_total_bytes` | 計算 | 計算式: `node_network_rx_bytes + node_network_tx_bytes` |
| ノード | `node_number_of_running_pods` | ポッドリスト | |
| ノード | `node_number_of_running_containers` | ポッドリスト | |
| NodeNet | `node_interface_network_rx_bytes` | cadvisor | このデータは、ワーカーノードネットワークインターフェイスの 1 秒あたりのネットワーク rx バイトです。 |
| NodeNet | `node_interface_network_tx_bytes` | cadvisor | このデータは、ワーカーノードネットワークインターフェイスの 1 秒あたりのネットワーク tx バイトです。 |
| NodeFS | `node_filesystem_capacity` | cadvisor | |
| NodeFS | `node_filesystem_usage` | cadvisor | |
| NodeFS | `node_filesystem_utilization` | 計算 | 計算式: `node_filesystem_usage / node_filesystem_capacity` このデータはデバイス名ごとに使用できます。 |
| クラスター | `cluster_failed_node_count` | API サーバー | |
| クラスター | `cluster_node_count` | API サーバー | |
| サービス | `service_number_of_running_pods` | API サーバー | |
| `Namespace` | `namespace_number_of_running_pods` | API サーバー | |
## メトリクスの計算例
このセクションには、前述の表の一部の値を計算する方法を示す例が含まれています。
次の状態のクラスターがあるとします。
```
Node1
node_cpu_limit = 4
node_cpu_usage_total = 3
Pod1
pod_cpu_usage_total = 2
Container1
container_cpu_limit = 1
container_cpu_request = 1
container_cpu_usage_total = 0.8
Container2
container_cpu_limit = null
container_cpu_request = null
container_cpu_usage_total = 1.2
Pod2
pod_cpu_usage_total = 0.4
Container3
container_cpu_limit = 1
container_cpu_request = 0.5
container_cpu_usage_total = 0.4
Node2
node_cpu_limit = 8
node_cpu_usage_total = 1.5
Pod3
pod_cpu_usage_total = 1
Container4
container_cpu_limit = 2
container_cpu_request = 2
container_cpu_usage_total = 1
```
以下の表は、このデータを使用してポッド CPU メトリクスがどのように計算されるかを示しています。
| メトリクス | 計算式 | Pod1 | Pod2 | Pod3 |
| --- | --- | --- | --- | --- |
| `pod_cpu_utilization` | `pod_cpu_usage_total / node_cpu_limit` | 2 / 4 = 50% | 0.4 / 4 = 10% | 1 / 8 = 12.5% |
| `pod_cpu_utilization_over_pod_limit` | `pod_cpu_usage_total / sum(container_cpu_limit)` | 該当なし (`Container2` の CPU 制限が定義されていないため) | 0.4 / 1 = 40% | 1 / 2 = 50% |
| `pod_cpu_reserved_capacity` | `sum(container_cpu_request) / node_cpu_limit` | (1 \$1 0) / 4 = 25% | 0.5 / 4 = 12.5% | 2 / 8 = 25% |
以下の表は、このデータを使用してノードの CPU メトリクスがどのように計算されるかを示しています。
| メトリクス | 計算式 | Node1 | Node2 |
| --- | --- | --- | --- |
| `node_cpu_utilization` | `node_cpu_usage_total / node_cpu_limit` | 3 / 4 = 75% | 1.5 / 8 = 18.75% |
| `node_cpu_reserved_capacity` | `sum(pod_cpu_request) / node_cpu_limit` | 1.5 / 4 = 37.5% | 2 / 8 = 25% |
# Container Insights の Prometheus メトリクスのモニターリング
CloudWatch Container Insights で Prometheus をモニターリングすると、コンテナ化されたシステムとワークロードからの Prometheus メトリクスの検出が自動化されます。Prometheus はオープンソースのシステムモニターリングおよび警告ツールキットです。詳細については、Prometheus のドキュメントの「[What is Prometheus?](https://prometheus.io/docs/introduction/overview/)」を参照してください。
Prometheus メトリクスの検出は、[Amazon Elastic Container Service](https://aws.amazon.com/ecs/)、[Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/)、および Amazon EC2 インスタンスで実行されている [Kubernetes](https://aws.amazon.com/kubernetes/) クラスターでサポートされています。Prometheus カウンタ、ゲージ、およびサマリーメトリクスタイプが収集されます。
Amazon ECS クラスターと Amazon EKS クラスターでは、EC2 と Fargate の両方の起動タイプがサポートされています。Container Insights は、複数のワークロードからメトリクスを自動的に収集し、任意のワークロードからメトリクスを収集するように設定できます。
Prometheus は、CloudWatch でカスタムメトリクスを取り込むオープンソースかつオープンスタンダードな方法として採用できます。Prometheus をサポートする CloudWatch エージェントは、Prometheus メトリクスを検出して収集し、アプリケーションのパフォーマンスの低下や障害をより迅速にモニターリング、トラブルシューティング、警告します。これにより、オブザーバビリティを強化するために必要なモニターリングツールの数も削減されます。
Container Insights の Prometheus サポートでは、収集、保存、分析などのメトリクスとログの使用量に応じて課金されます。詳細については、[Amazon CloudWatch 料金表](https://aws.amazon.com/cloudwatch/pricing/)をご覧ください。
**一部のワークロード用に構築済みのダッシュボード**
Container Insights Prometheus ソリューションには、このセクションに記載されている一般的なワークロード用の事前構築済みのダッシュボードが含まれています。これらのワークロードの設定例については、「[(オプション) Prometheus メトリクスのテストのためにコンテナ化された Amazon ECS のサンプルワークロードを設定する](ContainerInsights-Prometheus-Sample-Workloads-ECS.md)」および「[(オプション) Prometheus メトリクスのテストのためにコンテナ化された Amazon EKS サンプルワークロードを設定する](ContainerInsights-Prometheus-Sample-Workloads.md)」を参照してください。
エージェント設定ファイルを編集して、他のコンテナ化されたサービスおよびアプリケーションから Prometheus メトリクスを収集するように Container Insights を設定することもできます。
Amazon EC2 インスタンスで実行されている Amazon EKS クラスターおよび Kubernetes クラスター用の事前構築済みのダッシュボードを使用したワークロードには、以下があります。
+ AWS App Mesh
+ NGINX
+ Memcached
+ Java/JMX
+ HAProxy
Amazon ECS クラスター用の事前構築済みダッシュボードを使用したワークロードには、以下があります。
+ AWS App Mesh
+ Java/JMX
+ NGINX
+ NGINX Plus
# Amazon ECS クラスターで Prometheus メトリクスコレクションをセットアップおよび設定する
Amazon ECS クラスターから Prometheus メトリクスを収集するには、CloudWatch エージェントをコレクターとして使用するか、AWS Distro for OpenTelemetry コレクターを使用できます。AWS Distro for OpenTelemetry コレクターの使用については、[https://aws-otel.github.io/docs/getting-started/container-insights/ecs-prometheus](https://aws-otel.github.io/docs/getting-started/container-insights/ecs-prometheus) を参照してください。
以下のセクションでは、CloudWatch エージェントをコレクターとして使用して Prometheus メトリクスを取得する方法について説明します。Amazon ECS を実行しているクラスターに Prometheus モニターリングを使用して CloudWatch エージェントをインストールし、オプションで追加のターゲットをスクレイプするようにエージェントを設定することができます。また、これらのセクションでは、Prometheus モニターリングでのテストに使用するサンプルワークロードを設定するためのオプションのチュートリアルも提供します。
Amazon ECS の Container Insights は、Prometheus メトリクスの次の起動タイプとネットワークモードの組み合わせをサポートしています。
| Amazon ECS 起動タイプ | サポートされているネットワークモード |
| --- | --- |
| EC2 (Linux) | ブリッジ、ホストおよび awsvpc |
| Fargate | awsvpc |
**VPC セキュリティグループの要件**
Prometheus ワークロードのセキュリティグループの受信ルールでは、Prometheus のメトリクスをプライベート IP でスクレイピングするために、CloudWatch エージェントへの Prometheus ポートを開く必要があります。
CloudWatch エージェントのセキュリティグループの出力ルールでは、CloudWatch エージェントがプライベート IP によって Prometheus ワークロードのポートに接続できるようにする必要があります。
**Topics**
+ [Amazon ECS クラスターに Prometheus メトリクスコレクションを持つ CloudWatch エージェントをインストールする](ContainerInsights-Prometheus-install-ECS.md)
+ [追加の Prometheus ソースのスクレイピングと、それらのメトリクスのインポート](ContainerInsights-Prometheus-Setup-configure-ECS.md)
+ [(オプション) Prometheus メトリクスのテストのためにコンテナ化された Amazon ECS のサンプルワークロードを設定する](ContainerInsights-Prometheus-Sample-Workloads-ECS.md)
# Amazon ECS クラスターに Prometheus メトリクスコレクションを持つ CloudWatch エージェントをインストールする
このセクションでは、Amazon ECS を実行しているクラスターで Prometheus モニターリングを使用して CloudWatch エージェントをセットアップする方法について説明します。これを行うと、エージェントは、そのクラスターで実行されている次のワークロードのメトリクスを自動的にスクレイプし、インポートします。
+ AWS App Mesh
+ Java/JMX
また、追加の Prometheus ワークロードとソースからメトリクスをスクレイプしてインポートするようにエージェントを設定することもできます。
## IAM ロールの設定
CloudWatch エージェントタスク定義には、2 つの IAM ロールが必要です。Container Insights がこれらのロールを作成するように **CreateIAMRoles=True** スタックで CloudFormation を指定すると、ロールは正しいアクセス許可によって作成されます。お客様自身でロールを作成する場合、または既存のロールを使用する場合は、次のロールとアクセス許可が必要です。
+ **CloudWatch エージェントの ECS タスクロール** – CloudWatch エージェントコンテナはこのロールを使用します。これには、**CloudWatchAgentServerPolicy** ポリシーと、次の読み取り専用のアクセス許可を含むカスタマー管理ポリシーが含まれている必要があります。
+ `ec2:DescribeInstances`
+ `ecs:ListTasks`
+ `ecs:ListServices`
+ `ecs:DescribeContainerInstances`
+ `ecs:DescribeServices`
+ `ecs:DescribeTasks`
+ `ecs:DescribeTaskDefinition`
+ **CloudWatch エージェント ECS タスク実行ロール** – これは、コンテナを起動して実行するために Amazon ECS が必要とするロールです。タスク実行ロールに [**AmazonSSMReadOnlyAccess**]、[**AmazonECSTaskExecutionRolePolicy**]、および [**CloudWatchAgentServerPolicy**] ポリシーがアタッチされていることを確認します。Amazon ECS で使用するためにより機密性の高いデータを保存する場合は、「[機密データの指定](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specifying-sensitive-data.html)」を参照してください。
## を使用して、Prometheus モニターリングを使用する CloudWatch エージェントをインストールするCloudFormation
AWS CloudFormation を使用して、Amazon ECS クラスターの Prometheus モニターリングで CloudWatch エージェントをインストールします。次のリストは、CloudFormation テンプレートで使用するパラメータを示しています。
+ **EcsClusterName** – ターゲット Amazon ECS クラスターを指定します。
+ **CreateIamRoles** – Amazon ECS タスク実行ロールと Amazon ECS タスクロールの新しいロールを作成するときに **True** を指定します 。既存のロールを再利用する場合に **False** を指定します。
+ **TaskRoleName** – [**CreateIAMRoles**] に **True** を指定した場合、新しい Amazon ECS タスクロールに使用する名前を指定します。[**CreateIAMRoles**] に **False** を指定した場合、Amazon ECS タスクロールとして使用する既存のロールを指定します。
+ **ExecutionRoleName** – [**CreateIAMRoles**] に **True** を指定した場合、新しい Amazon ECS タスク実行ロールに使用する名前を指定します。[**CreateIAMRoles**] に **False** を指定した場合、Amazon ECS タスク実行ロールとして使用する既存のロールを指定します。
+ **ECSNetworkMode** – EC2 起動タイプを使用している場合、ここでネットワークモードを指定します。これは **bridge** または **host** である必要があります。
+ **ECSLaunchType** – **fargate** または **EC2** を指定します。
+ **SecurityGroupID** – [**ECSNetworkMode**] が **awsvpc** である場合、ここでセキュリティグループ ID を指定します。
+ **SubnetID** – **ECSNetworkMode** が **awsvpc** の場合、ここでサブネット ID を指定します。
### コマンドサンプル
このセクションでは、さまざまなシナリオで Prometheus モニターリングを使用して Container Insights をインストールするためのサンプル CloudFormation コマンドについて説明します。
**ブリッジネットワークモードで Amazon ECS クラスターの CloudFormation スタックを作成する**
```
export AWS_PROFILE=your_aws_config_profile_eg_default
export AWS_DEFAULT_REGION=your_aws_region_eg_ap-southeast-1
export ECS_CLUSTER_NAME=your_ec2_ecs_cluster_name
export ECS_NETWORK_MODE=bridge
export CREATE_IAM_ROLES=True
export ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
export ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-bridge-host.yaml
aws cloudformation create-stack --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=${ECS_CLUSTER_NAME} \
ParameterKey=CreateIAMRoles,ParameterValue=${CREATE_IAM_ROLES} \
ParameterKey=ECSNetworkMode,ParameterValue=${ECS_NETWORK_MODE} \
ParameterKey=TaskRoleName,ParameterValue=${ECS_TASK_ROLE_NAME} \
ParameterKey=ExecutionRoleName,ParameterValue=${ECS_EXECUTION_ROLE_NAME} \
--capabilities CAPABILITY_NAMED_IAM \
--region ${AWS_DEFAULT_REGION} \
--profile ${AWS_PROFILE}
```
**ホストネットワークモードで Amazon ECS クラスターの CloudFormation スタックを作成する**
```
export AWS_PROFILE=your_aws_config_profile_eg_default
export AWS_DEFAULT_REGION=your_aws_region_eg_ap-southeast-1
export ECS_CLUSTER_NAME=your_ec2_ecs_cluster_name
export ECS_NETWORK_MODE=host
export CREATE_IAM_ROLES=True
export ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
export ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-bridge-host.yaml
aws cloudformation create-stack --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=${ECS_CLUSTER_NAME} \
ParameterKey=CreateIAMRoles,ParameterValue=${CREATE_IAM_ROLES} \
ParameterKey=ECSNetworkMode,ParameterValue=${ECS_NETWORK_MODE} \
ParameterKey=TaskRoleName,ParameterValue=${ECS_TASK_ROLE_NAME} \
ParameterKey=ExecutionRoleName,ParameterValue=${ECS_EXECUTION_ROLE_NAME} \
--capabilities CAPABILITY_NAMED_IAM \
--region ${AWS_DEFAULT_REGION} \
--profile ${AWS_PROFILE}
```
**awsvpc ネットワークモードで Amazon ECS クラスターの CloudFormation スタックを作成する**
```
export AWS_PROFILE=your_aws_config_profile_eg_default
export AWS_DEFAULT_REGION=your_aws_region_eg_ap-southeast-1
export ECS_CLUSTER_NAME=your_ec2_ecs_cluster_name
export ECS_LAUNCH_TYPE=EC2
export CREATE_IAM_ROLES=True
export ECS_CLUSTER_SECURITY_GROUP=your_security_group_eg_sg-xxxxxxxxxx
export ECS_CLUSTER_SUBNET=your_subnet_eg_subnet-xxxxxxxxxx
export ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
export ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-awsvpc.yaml
aws cloudformation create-stack --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-${ECS_LAUNCH_TYPE}-awsvpc \
--template-body file://cwagent-ecs-prometheus-metric-for-awsvpc.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=${ECS_CLUSTER_NAME} \
ParameterKey=CreateIAMRoles,ParameterValue=${CREATE_IAM_ROLES} \
ParameterKey=ECSLaunchType,ParameterValue=${ECS_LAUNCH_TYPE} \
ParameterKey=SecurityGroupID,ParameterValue=${ECS_CLUSTER_SECURITY_GROUP} \
ParameterKey=SubnetID,ParameterValue=${ECS_CLUSTER_SUBNET} \
ParameterKey=TaskRoleName,ParameterValue=${ECS_TASK_ROLE_NAME} \
ParameterKey=ExecutionRoleName,ParameterValue=${ECS_EXECUTION_ROLE_NAME} \
--capabilities CAPABILITY_NAMED_IAM \
--region ${AWS_DEFAULT_REGION} \
--profile ${AWS_PROFILE}
```
** awsvpc ネットワークモードでの Fargate クラスターの CloudFormation スタックの作成**
```
export AWS_PROFILE=your_aws_config_profile_eg_default
export AWS_DEFAULT_REGION=your_aws_region_eg_ap-southeast-1
export ECS_CLUSTER_NAME=your_ec2_ecs_cluster_name
export ECS_LAUNCH_TYPE=FARGATE
export CREATE_IAM_ROLES=True
export ECS_CLUSTER_SECURITY_GROUP=your_security_group_eg_sg-xxxxxxxxxx
export ECS_CLUSTER_SUBNET=your_subnet_eg_subnet-xxxxxxxxxx
export ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
export ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-awsvpc.yaml
aws cloudformation create-stack --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-${ECS_LAUNCH_TYPE}-awsvpc \
--template-body file://cwagent-ecs-prometheus-metric-for-awsvpc.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=${ECS_CLUSTER_NAME} \
ParameterKey=CreateIAMRoles,ParameterValue=${CREATE_IAM_ROLES} \
ParameterKey=ECSLaunchType,ParameterValue=${ECS_LAUNCH_TYPE} \
ParameterKey=SecurityGroupID,ParameterValue=${ECS_CLUSTER_SECURITY_GROUP} \
ParameterKey=SubnetID,ParameterValue=${ECS_CLUSTER_SUBNET} \
ParameterKey=TaskRoleName,ParameterValue=${ECS_TASK_ROLE_NAME} \
ParameterKey=ExecutionRoleName,ParameterValue=${ECS_EXECUTION_ROLE_NAME} \
--capabilities CAPABILITY_NAMED_IAM \
--region ${AWS_DEFAULT_REGION} \
--profile ${AWS_PROFILE}
```
### AWS スタックによって作成された CloudFormation リソース
次の表は、AWS を使用して Amazon ECS クラスターで Prometheus モニターリングを使用した Container Insights をセットアップするときに作成される CloudFormation リソースの一覧です。
| リソースタイプ | リソース名 | コメント |
| --- | --- | --- |
| AWS::SSM::Parameter | AmazonCloudWatch-CWAgentConfig-\$1*ECS\$1CLUSTER\$1NAME*-\$1*ECS\$1LAUNCH\$1TYPE*-\$1*ECS\$1NETWORK\$1MODE* | これは、デフォルト App Mesh および Java/JMX 埋め込みメトリクス形式定義を持つ CloudWatch エージェントです。 |
| AWS::SSM::Parameter | AmazonCloudWatch-PrometheusConfigName-\$1*ECS\$1CLUSTER\$1NAME*-\$1*ECS\$1LAUNCH\$1TYPE*-\$1*ECS\$1NETWORK\$1MODE* | これは Prometheus のスクレイピング設定です。 |
| AWS::IAM::Role | **\$1ECS\$1TASK\$1ROLE\$1NAME**。 | Amazon ECS タスクロール。これは、**True** に `CREATE_IAM_ROLES` を指定した場合にのみ作成されます 。 |
| AWS::IAM::Role | **\$1\$1ECS\$1EXECUTION\$1ROLE\$1NAME\$1** | Amazon ECS タスク実行ロール。これは、**True** に `CREATE_IAM_ROLES` を指定した場合にのみ作成されます 。 |
| AWS::ECS::TaskDefinition | cwagent-prometheus-\$1*ECS\$1CLUSTER\$1NAME*-\$1*ECS\$1LOUNCH\$1TYPE*-\$1*ECS\$1NETWORK\$1MODE* | |
| AWS::ECS::Service | cwagent-prometheus-replica-service-\$1*ECS\$1LAUNCH\$1TYPE*-\$1*ECS\$1NETWORK\$1MODE* | |
### Prometheus モニターリングを使用した CloudWatch エージェントの CloudFormation スタックの削除
Amazon ECS クラスターから CloudWatch エージェントを削除するには、次のコマンドを入力します。
```
export AWS_PROFILE=your_aws_config_profile_eg_default
export AWS_DEFAULT_REGION=your_aws_region_eg_ap-southeast-1
export CLOUDFORMATION_STACK_NAME=your_cloudformation_stack_name
aws cloudformation delete-stack \
--stack-name ${CLOUDFORMATION_STACK_NAME} \
--region ${AWS_DEFAULT_REGION} \
--profile ${AWS_PROFILE}
```
# 追加の Prometheus ソースのスクレイピングと、それらのメトリクスのインポート
Prometheus モニターリングを使用した CloudWatch エージェントは、Prometheus メトリクスをスクレイプするために 2 つの設定が必要です。1 つは標準の Prometheus 設定用で、Prometheus ドキュメントの「[](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config)」に記載されています。もう 1 つは CloudWatch エージェント設定用です。
Amazon ECS クラスターでは、設定は Amazon ECS タスク定義のシークレットによって AWS Systems Manager の Parameter Store と統合されます。
+ このシークレット `PROMETHEUS_CONFIG_CONTENT` は、Prometheus スクレイプ設定用です。
+ このシークレット `CW_CONFIG_CONTENT` は、 CloudWatch エージェント設定用です。
追加の Prometheus メトリクスソースをスクレイプし、それらのメトリクスを CloudWatch にインポートするには、Prometheus スクレイプ設定と CloudWatch エージェント設定の両方を変更し、更新された設定でエージェントを再デプロイします。
**VPC セキュリティグループの要件**
Prometheus ワークロードのセキュリティグループの受信ルールでは、Prometheus のメトリクスをプライベート IP でスクレイピングするために、CloudWatch エージェントへの Prometheus ポートを開く必要があります。
CloudWatch エージェントのセキュリティグループの出力ルールでは、CloudWatch エージェントがプライベート IP によって Prometheus ワークロードのポートに接続できるようにする必要があります。
## Prometheus スクレイプ設定
この CloudWatch エージェントは、Prometheus のドキュメントの「[](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config)」に記載されているように、標準の Prometheus スクレイプ設定をサポートしています。このセクションを編集して、このファイルに既に含まれている設定を更新したり、Prometheus スクレイピングターゲットを追加したりできます。デフォルトでは、サンプル設定ファイルに次のグローバル設定行が含まれています。
```
global:
scrape_interval: 1m
scrape_timeout: 10s
```
+ **scrape\$1interval** – ターゲットをスクレイプする頻度を定義します。
+ **scrape\$1timeout** – スクレイプリクエストがタイムアウトするまでの待機時間を定義します。
また、ジョブレベルでこれらの設定に対して異なる値を定義し、グローバル設定をオーバーライドすることもできます。
### Prometheus スクレイピングジョブ
CloudWatch エージェント YAML ファイルには、既にいくつかのデフォルトのスクレイピングジョブが設定されています。例えば、`cwagent-ecs-prometheus-metric-for-bridge-host.yaml` などのAmazon ECS の YAML ファイルでは、デフォルトのスクレイピングジョブが `ecs_service_discovery` セクションで設定されています。
```
"ecs_service_discovery": {
"sd_frequency": "1m",
"sd_result_file": "/tmp/cwagent_ecs_auto_sd.yaml",
"docker_label": {
},
"task_definition_list": [
{
"sd_job_name": "ecs-appmesh-colors",
"sd_metrics_ports": "9901",
"sd_task_definition_arn_pattern": ".*:task-definition\/.*-ColorTeller-(white):[0-9]+",
"sd_metrics_path": "/stats/prometheus"
},
{
"sd_job_name": "ecs-appmesh-gateway",
"sd_metrics_ports": "9901",
"sd_task_definition_arn_pattern": ".*:task-definition/.*-ColorGateway:[0-9]+",
"sd_metrics_path": "/stats/prometheus"
}
]
}
```
これらのデフォルトターゲットはそれぞれスクレイピングされ、メトリクスは埋め込みメトリクス形式を使用してログイベントで CloudWatch に送信されます。詳細については、「[ログ内へのメトリクスの埋め込み](CloudWatch_Embedded_Metric_Format.md)」を参照してください。
Amazon ECS クラスターからのログイベントは、[**/aws/ecs/containerinsights/*cluster\$1name*/prometheus**] ロググループに保存されます。
各スクレイピングジョブは、このロググループ内の異なるログストリームに含まれています。
新しいスクレイピングターゲットを追加するには、YAML ファイルの `task_definition_list` セクションの `ecs_service_discovery` セクションに新しいエントリを追加し、エージェントを再起動します。このプロセスの例については、「[新しい Prometheus スクレイピングターゲットを追加するためのチュートリアル: Prometheus API サーバーメトリクス](ContainerInsights-Prometheus-Setup-configure.md#ContainerInsights-Prometheus-Setup-new-exporters)」を参照してください。
## Prometheus の CloudWatch エージェント設定
CloudWatch エージェント設定ファイルには、Prometheus スクレイピング設定の `prometheus` の `metrics_collected` セクションがあります。これには、次の設定オプションが含まれます。
+ **cluster\$1name** – ログイベントのラベルとして追加されるクラスター名を指定します。このフィールドはオプションです。これを省略すると、エージェントは Amazon ECS クラスター名を検出できます。
+ **log\$1group\$1name** – スクレイプされた Prometheus メトリクスのロググループ名を指定します。このフィールドはオプションです。これを省略すると、CloudWatch では Amazon ECS クラスターからのログに**/aws/ecs/containerinsights/*cluster\$1name*/prometheus**が使用されます。
+ **prometheus\$1config\$1path** – Prometheus スクレイプ設定ファイルパスを指定します。このフィールドの値が `env:` で始まる場合、Prometheus スクレイプ設定ファイルの内容は、コンテナの環境変数から取得されます。このフィールドは変更しないでください。
+ **ecs\$1service\$1discovery** – Amazon ECS Prometheus ターゲット自動検出関数の設定を指定するセクションです。Prometheus ターゲットを検出するには、コンテナの docker ラベルに基づく検出と、Amazon ECS タスク定義の ARN 正規表現に基づく検出の 2 つのモードがサポートされています。2 つのモードを一緒に使用すると、CloudWatch エージェントは *\$1private\$1ip\$1:\$1port\$1/\$1metrics\$1path\$1* に基づいて検出されたターゲットの重複排除を行います。
`ecs_service_discovery` セクションには、次のフィールドを含めることができます。
+ `sd_frequency` は、Prometheus エクスポーターを検出する頻度です。数値と単位サフィックスを指定します。例えば、`1m` の場合は 1 分に 1 回、`30s` の場合は 30 秒に 1 回です。有効な単位サフィックスは、`ns`、`us`、`ms`、`s`、`m`、`h` です。
このフィールドはオプションです。デフォルト値は 60 秒 (1 分) です。
+ `sd_target_cluster` は、自動検出のターゲット Amazon ECS クラスター名です。このフィールドはオプションです。デフォルトは、CloudWatch エージェントがインストールされている Amazon ECS クラスターの名前です。
+ `sd_cluster_region` は、ターゲット Amazon ECS クラスターのリージョンです。このフィールドはオプションです。デフォルトは、CloudWatch エージェントがインストールされている Amazon ECS クラスターのリージョンです。
+ `sd_result_file` は、Prometheus ターゲット結果の YAML ファイルのパスです。Prometheus スクレイプ設定は、このファイルを参照します。
+ `docker_label` は、docker のラベルベースのサービス検出の設定を指定するために使用できるオプションのセクションです。このセクションを省略すると、docker のラベルベースの検出は使用されません。このセクションには、次のフィールドを含めることができます。
+ `sd_port_label` は、Prometheus メトリクスのコンテナポートを指定するコンテナの docker ラベル名です。デフォルト値は `ECS_PROMETHEUS_EXPORTER_PORT` です。コンテナにこの docker ラベルがない場合、CloudWatch エージェントはそれをスキップします。
+ `sd_metrics_path_label` は、Prometheus メトリクスパスを指定するコンテナの docker ラベル名です。デフォルト値は `ECS_PROMETHEUS_METRICS_PATH` です。コンテナにこの docker ラベルがない場合は、エージェントはデフォルトパス `/metrics` を想定します。
+ `sd_job_name_label` は、Prometheus スクレイプジョブ名を指定するコンテナの docker ラベル名です。デフォルト値は `job` です。コンテナにこの docker ラベルがない場合、CloudWatch エージェントは Prometheus スクレイプ設定でジョブ名を使用します。
+ `task_definition_list` は、タスク定義ベースのサービス検出の設定を指定するために使用できるオプションのセクションです。このセクションを省略すると、タスク定義ベースの検出は使用されません。このセクションには、次のフィールドを含めることができます。
+ `sd_task_definition_arn_pattern` は、検出する Amazon ECS タスク定義を指定するために使用するパターンです。これは正規表現です。
+ `sd_metrics_ports` に、Prometheus メトリクスの containerPort を示します。containerPort はセミコロンで区切ります。
+ `sd_container_name_pattern` は、Amazon ECS タスクコンテナ名を指定します。これは正規表現です。
+ `sd_metrics_path` は、Prometheus のメトリクスパスを指定します。これを省略すると、エージェントはデフォルトのパス `/metrics` を引き受けます。
+ `sd_job_name` Prometheus スクレイプジョブ名を指定します。このフィールドを省略すると、CloudWatch エージェントは Prometheus スクレイプ設定のジョブ名を使用します。
+ `service_name_list_for_tasks` は、サービス名ベースの検出の設定を指定するために使用できるオプションのセクションです。このセクションを省略すると、サービス名ベースの検出は使用されません。このセクションには、次のフィールドを含めることができます。
+ `sd_service_name_pattern` は、タスクを検出する Amazon ECS サービスを指定するために使用するパターンです。これは正規表現です。
+ `sd_metrics_ports` は、Prometheus メトリクスの `containerPort` をリストします。複数の `containerPorts` をセミコロンで区切ります。
+ `sd_container_name_pattern` は、Amazon ECS タスクコンテナ名を指定します。これは正規表現です。
+ `sd_metrics_path` は、Prometheus のメトリクスパスを指定します。これを省略すると、エージェントはデフォルトのパス `/metrics` を引き受けます。
+ `sd_job_name` Prometheus スクレイプジョブ名を指定します。このフィールドを省略すると、CloudWatch エージェントは Prometheus スクレイプ設定のジョブ名を使用します。
+ **metric\$1declaration** – 生成されるメトリクス形式が埋め込まれたログの配列を指定するセクションです。CloudWatch エージェントがインポートする各 Prometheus ソースには、デフォルトで `metric_declaration` セクションがあります。これらの各セクションには、次のフィールドが含まれています。
+ `label_matcher` は、 `source_labels` に表示されているラベルの値をチェックする正規表現です。一致するメトリクスは、CloudWatch に送信される埋め込みメトリクス形式に含めることができます。
`source_labels` で複数のラベルを指定する場合は、`^` の正規表現に `$` や `label_matcher` 文字を使用しないことをお勧めします。
+ `source_labels` は、`label_matcher` 行によってチェックされるラベルの値を指定します。
+ `label_separator` は、複数の ` label_matcher` が指定されている場合に、`source_labels` 行で使用するセパレータを指定します。デフォルト: `;`。このデフォルトは、次の例の `label_matcher` 行で使用されています。
+ `metric_selectors` は、収集され、CloudWatch に送信されるメトリクスを指定する正規表現です。
+ `dimensions` は、選択した各メトリクスの CloudWatch ディメンションとして使用されるラベルのリストです。
次の `metric_declaration` の例を参照してください。
```
"metric_declaration": [
{
"source_labels":[ "Service", "Namespace"],
"label_matcher":"(.*node-exporter.*|.*kube-dns.*);kube-system$",
"dimensions":[
["Service", "Namespace"]
],
"metric_selectors":[
"^coredns_dns_request_type_count_total$"
]
}
]
```
この例では、次の条件が満たされた場合にログイベントとして送信される埋め込みメトリクス形式セクションを設定します。
+ `Service` の値には `node-exporter` または `kube-dns` が含まれます。
+ `Namespace` の値は `kube-system` です。
+ Prometheus メトリクス `coredns_dns_request_type_count_total` には、`Service` ラベルおよび `Namespace` ラベルの両方が含まれます。
送信されるログイベントには、次の強調表示されたセクションが含まれます。
```
{
"CloudWatchMetrics":[
{
"Metrics":[
{
"Name":"coredns_dns_request_type_count_total"
}
],
"Dimensions":[
[
"Namespace",
"Service"
]
],
"Namespace":"ContainerInsights/Prometheus"
}
],
"Namespace":"kube-system",
"Service":"kube-dns",
"coredns_dns_request_type_count_total":2562,
"eks_amazonaws_com_component":"kube-dns",
"instance":"192.168.61.254:9153",
"job":"kubernetes-service-endpoints",
...
}
```
# Amazon ECS クラスターでの自動検出の詳細ガイド
Prometheus には、[](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config)で説明されているように、多数の動的なサービス検出メカニズムが用意されています。ただし、Amazon ECS の組み込みサービス検出はありません。CloudWatch エージェントはこのメカニズムを追加します。
Amazon ECS Prometheus サービス検出を有効にするときに、CloudWatch エージェントは定期的に Amazon ECS および Amazon EC2 フロントエンドに対して次の API コールを行い、ターゲット ECS クラスターで実行中の ECS タスクのメタデータを取得します。
```
EC2:DescribeInstances
ECS:ListTasks
ECS:ListServices
ECS:DescribeContainerInstances
ECS:DescribeServices
ECS:DescribeTasks
ECS:DescribeTaskDefinition
```
このメタデータは、ECS クラスター内の Prometheus ターゲットをスキャンするために CloudWatch エージェントによって使用されます。CloudWatch エージェントは、次の 3 つのサービス検出モードをサポートします。
+ コンテナドッカーのラベルベースのサービス検出
+ ECS タスク定義 ARN 正規表現ベースのサービス検出
+ ECS サービス名正規表現ベースのサービス検出
すべてのモードを一緒に使用することができます。CloudWatch エージェントは、`{private_ip}:{port}/{metrics_path}` に基づいて検出されたターゲットの重複を解除します。
検出されたターゲットはすべて、CloudWatch エージェントコンテナ内の `sd_result_file` 設定フィールドで指定された結果ファイルに書き込まれます。次に、結果ファイルの例を示します。
```
- targets:
- 10.6.1.95:32785
labels:
__metrics_path__: /metrics
ECS_PROMETHEUS_EXPORTER_PORT: "9406"
ECS_PROMETHEUS_JOB_NAME: demo-jar-ec2-bridge-dynamic
ECS_PROMETHEUS_METRICS_PATH: /metrics
InstanceType: t3.medium
LaunchType: EC2
SubnetId: subnet-123456789012
TaskDefinitionFamily: demo-jar-ec2-bridge-dynamic-port
TaskGroup: family:demo-jar-ec2-bridge-dynamic-port
TaskRevision: "7"
VpcId: vpc-01234567890
container_name: demo-jar-ec2-bridge-dynamic-port
job: demo-jar-ec2-bridge-dynamic
- targets:
- 10.6.3.193:9404
labels:
__metrics_path__: /metrics
ECS_PROMETHEUS_EXPORTER_PORT_SUBSET_B: "9404"
ECS_PROMETHEUS_JOB_NAME: demo-tomcat-ec2-bridge-mapped-port
ECS_PROMETHEUS_METRICS_PATH: /metrics
InstanceType: t3.medium
LaunchType: EC2
SubnetId: subnet-123456789012
TaskDefinitionFamily: demo-tomcat-ec2-bridge-mapped-port
TaskGroup: family:demo-jar-tomcat-bridge-mapped-port
TaskRevision: "12"
VpcId: vpc-01234567890
container_name: demo-tomcat-ec2-bridge-mapped-port
job: demo-tomcat-ec2-bridge-mapped-port
```
この結果ファイルは、Prometheus ファイルベースのサービス検出と直接統合できます。Prometheus ファイルベースのサービス検出の詳細については、「[](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#file_sd_config)」を参照してください。
結果ファイルが `/tmp/cwagent_ecs_auto_sd.yaml` に書き込まれたとします。次の Prometheus スクレイプ設定はそれを消費します。
```
global:
scrape_interval: 1m
scrape_timeout: 10s
scrape_configs:
- job_name: cwagent-ecs-file-sd-config
sample_limit: 10000
file_sd_configs:
- files: [ "/tmp/cwagent_ecs_auto_sd.yaml" ]
```
CloudWatch エージェントは、検出されたターゲットに対して次の追加ラベルも追加します。
+ `container_name`
+ `TaskDefinitionFamily`
+ `TaskRevision`
+ `TaskGroup`
+ `StartedBy`
+ `LaunchType`
+ `job`
+ `__metrics_path__`
+ Docker のラベル
クラスターの起動タイプが EC2 の場合、次の 3 つのラベルが追加されます。
+ `InstanceType`
+ `VpcId`
+ `SubnetId`
**注記**
正規表現 `[a-zA-Z_][a-zA-Z0-9_]*` と一致しない Docker ラベルは除外されます。これは、Prometheus のマニュアルの「[構成ファイル](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#labelname)」 の `label_name` に記載されている Prometheus の規則と一致します。
## ECS サービス検出の設定例
このセクションでは、ECS サービスの検出を示す例について説明します。
**例 1**
```
"ecs_service_discovery": {
"sd_frequency": "1m",
"sd_result_file": "/tmp/cwagent_ecs_auto_sd.yaml",
"docker_label": {
}
}
```
この例では、Docker ラベルベースのサービス検出を有効にします。CloudWatch エージェントは、ECS タスクのメタデータを 1 分間に照会し、検出されたターゲットを CloudWatch エージェントコンテナ内の `/tmp/cwagent_ecs_auto_sd.yaml` ファイルに書き込みます。
`sd_port_label` セクションの `docker_label` のデフォルト値は `ECS_PROMETHEUS_EXPORTER_PORT` です。ECS タスク内の実行中のコンテナに `ECS_PROMETHEUS_EXPORTER_PORT` ドッカーラベルがある場合、CloudWatch エージェントはその値を `container port` として使用して、コンテナのすべての公開ポートをスキャンします。一致するものがある場合、マッピングされたホストポートとコンテナのプライベート IP を使用して、Prometheus エクスポータターゲットが `private_ip:host_port` の形式で構築されます。
`sd_metrics_path_label` セクションの `docker_label` のデフォルト値は `ECS_PROMETHEUS_METRICS_PATH` です。コンテナにこのドッカーラベルがある場合、その値は `__metrics_path__` として使用されます。コンテナにこのラベルがない場合は、デフォルト値 `/metrics` が使用されます。
`sd_job_name_label` セクションの `docker_label` のデフォルト値は `job` です。コンテナにこのドッカーラベルがある場合、その値はターゲットのラベルの 1 つとして追加され、Prometheus 設定で指定されたデフォルトのジョブ名が置き換えられます。このドッカーラベルの値は、CloudWatch Logs ロググループのログストリーム名として使用されます。
**例 2**
```
"ecs_service_discovery": {
"sd_frequency": "15s",
"sd_result_file": "/tmp/cwagent_ecs_auto_sd.yaml",
"docker_label": {
"sd_port_label": "ECS_PROMETHEUS_EXPORTER_PORT_SUBSET_A",
"sd_job_name_label": "ECS_PROMETHEUS_JOB_NAME"
}
}
```
この例では、Docker ラベルベースのサービス検出を有効にします。CloudWatch エージェントは、ECS タスクのメタデータを 15 秒ごとに照会し、検出されたターゲットを CloudWatch エージェントコンテナ内の `/tmp/cwagent_ecs_auto_sd.yaml` ファイルに書き込みます。ドッカーラベルが `ECS_PROMETHEUS_EXPORTER_PORT_SUBSET_A` のコンテナがスキャンされます。ドッカーラベルが `ECS_PROMETHEUS_JOB_NAME` の値がジョブ名として使用されます。
**例 3**
```
"ecs_service_discovery": {
"sd_frequency": "5m",
"sd_result_file": "/tmp/cwagent_ecs_auto_sd.yaml",
"task_definition_list": [
{
"sd_job_name": "java-prometheus",
"sd_metrics_path": "/metrics",
"sd_metrics_ports": "9404; 9406",
"sd_task_definition_arn_pattern": ".*:task-definition/.*javajmx.*:[0-9]+"
},
{
"sd_job_name": "envoy-prometheus",
"sd_metrics_path": "/stats/prometheus",
"sd_container_name_pattern": "^envoy$",
"sd_metrics_ports": "9901",
"sd_task_definition_arn_pattern": ".*:task-definition/.*appmesh.*:23"
}
]
}
```
この例では、ECS タスク定義 ARN 正規表現ベースのサービス検出をイネーブルにします。CloudWatch エージェントは、ECS タスクのメタデータを 5 分ごとに照会し、検出されたターゲットを CloudWatch エージェントコンテナ内の `/tmp/cwagent_ecs_auto_sd.yaml` ファイルに書き込みます。
2 つのタスク定義 ARN 通常記述セクションが定義されています。
+ 最初のセクションでは、ECS タスク定義 ARN に `javajmx` が含まれる ECS タスクが、コンテナポートスキャン用にフィルタリングされます。これらの ECS タスク内のコンテナが 9404 または 9406 のコンテナポートを公開する場合、マップされたホストポートとコンテナのプライベート IP が Prometheus エクスポーターターゲットの作成に使用されます。`sd_metrics_path` の値は `__metrics_path__` から `/metrics` に設定します。したがって、CloudWatch エージェントは Prometheus メトリクスを `private_ip:host_port/metrics` からスクレイプし、スクレイプされたメトリクスは、`java-prometheus` ロググループ内の CloudWatch Logs の `/aws/ecs/containerinsights/cluster_name/prometheus` ログストリームに送信 されます。
+ 2 番目のセクションでは、ECS タスク定義 ARN に `appmesh` があり、`version` の `:23` がある ECS タスクが、コンテナポートスキャン用にフィルタリングされます。コンテナポートを `envoy` 上に公開する `9901` という名前のコンテナの場合、マッピングされたホストポートとコンテナのプライベート IP が Prometheus エクスポーターターゲットの作成に使用されます。これらの ECS タスク内の値は、9404 または 9406 のコンテナポートを公開し、マッピングされたホストポートとコンテナのプライベート IP が Prometheus エクスポーターターゲットの作成に使用されます。`sd_metrics_path` の値は `__metrics_path__` から `/stats/prometheus` に設定します。したがって、CloudWatch エージェントは `private_ip:host_port/stats/prometheus` から Prometheus メトリクスをスクレイプし、スクレイプされたメトリクスをロググループ `envoy-prometheus` 内の CloudWatch Logs の `/aws/ecs/containerinsights/cluster_name/prometheus` ログストリームに送信します。
**例 4**
```
"ecs_service_discovery": {
"sd_frequency": "5m",
"sd_result_file": "/tmp/cwagent_ecs_auto_sd.yaml",
"service_name_list_for_tasks": [
{
"sd_job_name": "nginx-prometheus",
"sd_metrics_path": "/metrics",
"sd_metrics_ports": "9113",
"sd_service_name_pattern": "^nginx-.*"
},
{
"sd_job_name": "haproxy-prometheus",
"sd_metrics_path": "/stats/metrics",
"sd_container_name_pattern": "^haproxy$",
"sd_metrics_ports": "8404",
"sd_service_name_pattern": ".*haproxy-service.*"
}
]
}
```
この例では、ECS サービス名正規表現ベースのサービス検出を有効にします。CloudWatch エージェントは、ECS サービスのメタデータを 5 分ごとに照会し、検出されたターゲットを CloudWatch エージェントコンテナ内の `/tmp/cwagent_ecs_auto_sd.yaml` ファイルに書き込みます。
2 つのサービス名正規表現セクションが定義されています。
+ 最初のセクションについて、正規表現 `^nginx-.*` に一致する名前を持つ ECS サービスに関連付けられた ECS タスクがコンテナポートスキャン用にフィルタリングされます。これらの ECS タスク内のコンテナが 9113 のコンテナポートを公開する場合、マップされたホストポートとコンテナのプライベート IP が Prometheus エクスポーターターゲットの作成に使用されます。`sd_metrics_path` の値は `__metrics_path__` から `/metrics` に設定します。したがって、CloudWatch エージェントは Prometheus メトリクスを `private_ip:host_port/metrics` からスクレイプし、スクレイプされたメトリクスは、`nginx-prometheus` ロググループ内の CloudWatch Logs の `/aws/ecs/containerinsights/cluster_name/prometheus` ログストリームに送信されます。
+ または、2 つ目のセクションについて、正規表現 `.*haproxy-service.*` に一致する名前を持つ ECS サービスに関連付けられた ECS タスクがコンテナポートスキャン用にフィルタリングされます。コンテナポートを 8404 上に公開する `haproxy` という名前のコンテナの場合、マッピングされたホストポートとコンテナのプライベート IP が Prometheus エクスポーターターゲットの作成に使用されます。`sd_metrics_path` の値は `__metrics_path__` から `/stats/metrics` に設定します。したがって、CloudWatch エージェントは Prometheus メトリクスを `private_ip:host_port/stats/metrics` からスクレイプし、スクレイプされたメトリクスは、`haproxy-prometheus` ロググループ内の CloudWatch Logs の `/aws/ecs/containerinsights/cluster_name/prometheus` ログストリームに送信されます。
**例 5**
```
"ecs_service_discovery": {
"sd_frequency": "1m30s",
"sd_result_file": "/tmp/cwagent_ecs_auto_sd.yaml",
"docker_label": {
"sd_port_label": "MY_PROMETHEUS_EXPORTER_PORT_LABEL",
"sd_metrics_path_label": "MY_PROMETHEUS_METRICS_PATH_LABEL",
"sd_job_name_label": "MY_PROMETHEUS_METRICS_NAME_LABEL"
}
"task_definition_list": [
{
"sd_metrics_ports": "9150",
"sd_task_definition_arn_pattern": "*memcached.*"
}
]
}
```
この例では、両方の ECS サービス検出モードを有効にします。CloudWatch エージェントは、ECS タスクのメタデータを 90 秒ごとに照会し、検出されたターゲットを CloudWatch エージェントコンテナ内の `/tmp/cwagent_ecs_auto_sd.yaml` ファイルに書き込みます。
ドッカーベースのサービス検出設定の場合。
+ ドッカーラベル `MY_PROMETHEUS_EXPORTER_PORT_LABEL` 付きの ECS タスクは、Prometheus ポートスキャン用にフィルタリングされます。ターゲットの Prometheus コンテナポートは、ラベル `MY_PROMETHEUS_EXPORTER_PORT_LABEL` の値によって指定されます。
+ ドッカーラベル `MY_PROMETHEUS_EXPORTER_PORT_LABEL` の値は、`__metrics_path__` に使用されます。コンテナにこのドッカーラベルがない場合は、デフォルト値 `/metrics` が使用されます。
+ ドッカーラベル `MY_PROMETHEUS_EXPORTER_PORT_LABEL` の値は、ジョブラベルとして使用されます。コンテナにこのドッカーラベルがない場合は、Prometheus 設定で定義されたジョブ名が使用されます。
ECS タスク定義 ARN 正規表現ベースのサービス検出設定の場合。
+ ECS タスク定義 ARN `memcached` 内の ECS タスクは、コンテナポートスキャン用にフィルタリングされます。ターゲットの Prometheus コンテナポートは、`sd_metrics_ports` で定義されている 9150 です。デフォルトのメトリクスパス `/metrics` が使用されます。Prometheus 設定で定義されているジョブ名が使用されます。
# (オプション) Prometheus メトリクスのテストのためにコンテナ化された Amazon ECS のサンプルワークロードを設定する
CloudWatch Container Insights で Prometheus メトリクスのサポートをテストするには、次のコンテナ化されたワークロードを 1 つ以上設定できます。Prometheus をサポートする CloudWatch エージェントは、これらの各ワークロードからメトリクスを自動的に収集します。デフォルトで収集されるメトリクスを表示する方法については、「[CloudWatch エージェントにより収集される Prometheus メトリクス](ContainerInsights-Prometheus-metrics.md)」を参照してください。
**Topics**
+ [Amazon ECS クラスターの App Mesh ワークロードのサンプル](ContainerInsights-Prometheus-Sample-Workloads-ECS-appmesh.md)
+ [Amazon ECS クラスター用の Java/JMX ワークロードのサンプル](ContainerInsights-Prometheus-Sample-Workloads-ECS-javajmx.md)
+ [Amazon ECS クラスターの NGINX ワークロードのサンプル](ContainerInsights-Prometheus-Setup-nginx-ecs.md)
+ [Amazon ECS クラスターの NGINX Plus ワークロードのサンプル](ContainerInsights-Prometheus-Setup-nginx-plus-ecs.md)
+ [新しい Prometheus スクレイピングターゲットを追加するためのチュートリアル: Amazon ECS の Memcached](ContainerInsights-Prometheus-Setup-memcached-ecs.md)
+ [Amazon ECS Fargate 上の Redis OSS Prometheus メトリクスのスクレイピングに関するチュートリアル](ContainerInsights-Prometheus-Setup-redis-ecs.md)
# Amazon ECS クラスターの App Mesh ワークロードのサンプル
Amazon ECS のサンプル Prometheus ワークロードからメトリクスを収集するには、クラスターで Container Insights を実行している必要があります。Container Insights のインストールの詳細については、「[Amazon ECS での Container Insights のセットアップ](deploy-container-insights-ECS.md)」を参照してください。
まず、この[チュートリアル](https://github.com/aws/aws-app-mesh-examples/tree/main/examples/apps/colorapp#app-mesh-walkthrough-deploy-the-color-app-on-ecs)に従って、サンプルカラーアプリを Amazon ECS クラスターにデプロイします。完了したら、ポート 9901 に App Mesh Prometheus メトリクスが公開されます。
次に、以下のステップに従って、カラーアプリをインストールした同じ Amazon ECS クラスターに Prometheus モニターリングを使用して CloudWatch エージェントをインストールします。このセクションのステップでは、ブリッジネットワークモードで CloudWatch エージェントをインストールします。
チュートリアルで設定した環境変数 `ENVIRONMENT_NAME`、 `AWS_PROFILE`、`AWS_DEFAULT_REGION` は、次のステップでも使用されます。
**テスト用に Prometheus モニターリングを使用して CloudWatch エージェントをインストールするには**
1. 次のコマンドを入力して、CloudFormation テンプレートをダウンロードします。
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-bridge-host.yaml
```
1. 次のコマンドを入力して、ネットワークモードを設定します。
```
export ECS_CLUSTER_NAME=${ENVIRONMENT_NAME}
export ECS_NETWORK_MODE=bridge
```
1. 次のコマンドを入力して、CloudFormation スタックを作成します。
```
aws cloudformation create-stack --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=${ECS_CLUSTER_NAME} \
ParameterKey=CreateIAMRoles,ParameterValue=True \
ParameterKey=ECSNetworkMode,ParameterValue=${ECS_NETWORK_MODE} \
ParameterKey=TaskRoleName,ParameterValue=CWAgent-Prometheus-TaskRole-${ECS_CLUSTER_NAME} \
ParameterKey=ExecutionRoleName,ParameterValue=CWAgent-Prometheus-ExecutionRole-${ECS_CLUSTER_NAME} \
--capabilities CAPABILITY_NAMED_IAM \
--region ${AWS_DEFAULT_REGION} \
--profile ${AWS_PROFILE}
```
1. (オプション) CloudFormation スタックが作成されると、 `CREATE_COMPLETE` メッセージが表示されます。そのメッセージが表示される前にステータスを確認する場合は、次のコマンドを入力します。
```
aws cloudformation describe-stacks \
--stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--query 'Stacks[0].StackStatus' \
--region ${AWS_DEFAULT_REGION} \
--profile ${AWS_PROFILE}
```
**トラブルシューティング**
チュートリアルのステップでは、jq を使用して、 の出力結果を解析しますAWS CLI jq のインストールの詳細については、「[ jq](https://stedolan.github.io/jq/)」を参照してください。jq が正しく解析できるように、次のコマンドを使用して AWS CLI のデフォルトの出力形式を JSON に設定します。
```
$ aws configure
```
レスポンスが `Default output format` に到達したら、**json** と入力します 。
## Prometheus モニターリングを使用した CloudWatch エージェントのアンインストール
テストが終了したら、次のコマンドを入力し、CloudFormation スタックを削除して CloudWatch エージェントをアンインストールします。
```
aws cloudformation delete-stack \
--stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--region ${AWS_DEFAULT_REGION} \
--profile ${AWS_PROFILE}
```
# Amazon ECS クラスター用の Java/JMX ワークロードのサンプル
JMX Exporter は、Prometheus メトリクスとして JMX mBeans をスクレイプおよび公開できる公式の Prometheus エクスポーターです。詳細については、[prometheus/jmx\$1exporter](https://github.com/prometheus/jmx_exporter) を参照してください。
Prometheus をサポートする CloudWatch エージェントは、Amazon ECS クラスターのサービス検出設定に基づいて Java/JMX Prometheus メトリクスをスクレイプします。別のポートまたは metrics\$1path でメトリクスを公開するように JMX Exporter を設定できます。ポートまたはパスを変更する場合は、CloudWatch エージェント設定のデフォルトの `ecs_service_discovery` セクションを更新します。
Amazon ECS のサンプル Prometheus ワークロードからメトリクスを収集するには、クラスターで Container Insights を実行している必要があります。Container Insights のインストールの詳細については、「[Amazon ECS での Container Insights のセットアップ](deploy-container-insights-ECS.md)」を参照してください。
**Amazon ECS クラスターの Java/JMX サンプルワークロードをインストールするには**
1. これらのセクションのステップに従って、Docker イメージを作成します。
+ [例: Prometheus メトリクスを使用した Java Jar アプリケーション Docker イメージ](ContainerInsights-Prometheus-Sample-Workloads-javajmx.md#ContainerInsights-Prometheus-Sample-Workloads-javajmx-jar)
+ [例: Prometheus メトリクスを使用した Apache Tomcat Docker イメージ](ContainerInsights-Prometheus-Sample-Workloads-javajmx.md#ContainerInsights-Prometheus-Sample-Workloads-javajmx-tomcat)
1. Amazon ECS タスク定義ファイルに次の 2 つの docker ラベルを指定します。その後、クラスター内で Amazon ECS サービスまたは Amazon ECS タスクとしてタスク定義を実行できます。
+ Prometheus メトリクスが公開されている ContainerPort を指定するように`ECS_PROMETHEUS_EXPORTER_PORT` を設定します 。
+ `Java_EMF_Metrics` を `true` に設定します。CloudWatch エージェントは、このフラグを使用してログイベントに埋め込みメトリクス形式を生成します。
次に例を示します。
```
{
"family": "workload-java-ec2-bridge",
"taskRoleArn": "{{task-role-arn}}",
"executionRoleArn": "{{execution-role-arn}}",
"networkMode": "bridge",
"containerDefinitions": [
{
"name": "tomcat-prometheus-workload-java-ec2-bridge-dynamic-port",
"image": "your_docker_image_tag_for_tomcat_with_prometheus_metrics",
"portMappings": [
{
"hostPort": 0,
"protocol": "tcp",
"containerPort": 9404
}
],
"dockerLabels": {
"ECS_PROMETHEUS_EXPORTER_PORT": "9404",
"Java_EMF_Metrics": "true"
}
}
],
"requiresCompatibilities": [
"EC2" ],
"cpu": "256",
"memory": "512"
}
```
CloudFormation テンプレートの CloudWatch エージェントのデフォルト設定では、docker のラベルベースのサービス検出とタスク定義の ARN ベースのサービス検出の両方が有効になります。これらのデフォルト設定を表示するには、「[CloudWatch エージェント YAML 設定ファイル](https://github.com/aws-samples/amazon-cloudwatch-container-insights/blob/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-bridge-host.yaml#L65)」の 65 行目を参照してください。`ECS_PROMETHEUS_EXPORTER_PORT` ラベル付きのコンテナは、Prometheus スクレイピング用に指定されたコンテナポートに基づいて自動検出されます。
CloudWatch エージェントのデフォルト設定には、同じファイルの 112 行目に Java/JMX の `metric_declaration` 設定もあります。ターゲットコンテナのすべての docker ラベルは、Prometheus メトリクスに追加ラベルとして追加され、CloudWatch Logs に送信されます。docker ラベル `Java_EMF_Metrics=“true”` 付きの Java/JMX コンテナの場合、埋め込みメトリクス形式が生成されます。
# Amazon ECS クラスターの NGINX ワークロードのサンプル
NGINX Prometheus エクスポーターは、NGINX データを Prometheus のメトリクスとしてスクレイピングして公開できます。この例では、エクスポーターを Amazon ECS 用の NGINX リバースプロキシサービスと連動させて使用します。
NGINX Prometheus エクスポーターの詳細については、GitHub の [nginx-prometheus-exporter](https://github.com/nginxinc/nginx-prometheus-exporter) をご参照ください。NGINX リバースプロキシの詳細については、GitHub の [ecs-nginx-reverse-proxy](https://github.com/awslabs/ecs-nginx-reverse-proxy)をご参照ください。
Prometheus をサポートする CloudWatch エージェントは、Amazon ECS クラスターのサービス検出設定に基づいて NGINX Prometheus メトリクスをスクレイプします。別のポートまたはパスでメトリクスを公開するように NGINX Prometheus Exporter を設定できます。ポートまたはパスを変更する場合は、CloudWatch エージェント設定ファイルの `ecs_service_discovery` セクションを更新します。
## Amazon ECS クラスター用の NGINX リバースプロキシサンプルワークロードをインストールする
NGINX リバースプロキシサンプルワークロードをインストールするには、次の手順を実行します。
### Docker イメージを作成する
**NGINX リバースプロキシサンプルワークロード用の Docker イメージを作成するには**
1. NGINX リバースプロキシリポジトリから次のフォルダをダウンロードします: [ https://github.com/awslabs/ecs-nginx-reverse-proxy/tree/master/reverse-proxy/](https://github.com/awslabs/ecs-nginx-reverse-proxy/tree/master/reverse-proxy/)。
1. `app` ディレクトリを検索し、そのディレクトリからイメージを作成します。
```
docker build -t web-server-app ./path-to-app-directory
```
1. NGINX 用のカスタムイメージを作成します。まず、次の 2 つのファイルを含むディレクトリを作成します。
+ サンプル Dockerfile:
```
FROM nginx
COPY nginx.conf /etc/nginx/nginx.conf
```
+ [https://github.com/awslabs/ecs-nginx-reverse-proxy/tree/master/reverse-proxy/](https://github.com/awslabs/ecs-nginx-reverse-proxy/tree/master/reverse-proxy/) から変更された `nginx.conf` ファイル:
```
events {
worker_connections 768;
}
http {
# Nginx will handle gzip compression of responses from the app server
gzip on;
gzip_proxied any;
gzip_types text/plain application/json;
gzip_min_length 1000;
server{
listen 8080;
location /stub_status {
stub_status on;
}
}
server {
listen 80;
# Nginx will reject anything not matching /api
location /api {
# Reject requests with unsupported HTTP method
if ($request_method !~ ^(GET|POST|HEAD|OPTIONS|PUT|DELETE)$) {
return 405;
}
# Only requests matching the whitelist expectations will
# get sent to the application server
proxy_pass http://app:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_cache_bypass $http_upgrade;
}
}
}
```
**注記**
`stub_status` は、`nginx-prometheus-exporter` がメトリクスをスクレイピングするように設定されているのと同じポートで有効にする必要があります。このタスク定義例では、`nginx-prometheus-exporter` がポート 8080 からメトリクスをスクレイピングするように設定されています。
1. 新しいディレクトリのファイルからイメージを作成します。
```
docker build -t nginx-reverse-proxy ./path-to-your-directory
```
1. 後で使用するために、新しいイメージをイメージリポジトリにアップロードします。
### Amazon ECS で NGINX とウェブサーバーアプリを実行するタスク定義を作成します。
次に、タスク定義を設定します。
このタスク定義により、NGINX Prometheus メトリクスの収集とエクスポートが可能になります。NGINX コンテナは、アプリからの入力を追跡し、(`nginx.conf` で設定されているとおり) そのデータをポート 8080 に公開します。NGINX Prometheus エクスポーターコンテナは、CloudWatch で使用するために、これらのメトリクスをスクレイピングし、ポート 9113 に投稿します。
**NGINX サンプル Amazon ECS ワークロードのタスク定義を設定するには**
1. 次の内容でタスク定義 JSON ファイルを作成します。*your-customized-nginx-iamge* をカスタマイズした NGINX イメージのイメージ URI に置き換え、*your-web-server-app-image* をウェブサーバーアプリイメージのイメージ URI に置き換えます。
```
{
"containerDefinitions": [
{
"name": "nginx",
"image": "your-customized-nginx-image",
"memory": 256,
"cpu": 256,
"essential": true,
"portMappings": [
{
"containerPort": 80,
"protocol": "tcp"
}
],
"links": [
"app"
]
},
{
"name": "app",
"image": "your-web-server-app-image",
"memory": 256,
"cpu": 256,
"essential": true
},
{
"name": "nginx-prometheus-exporter",
"image": "docker.io/nginx/nginx-prometheus-exporter:0.8.0",
"memory": 256,
"cpu": 256,
"essential": true,
"command": [
"-nginx.scrape-uri",
"http://nginx:8080/stub_status"
],
"links":[
"nginx"
],
"portMappings":[
{
"containerPort": 9113,
"protocol": "tcp"
}
]
}
],
"networkMode": "bridge",
"placementConstraints": [],
"family": "nginx-sample-stack"
}
```
1. 次のコマンドを入力して、タスク定義を登録します。
```
aws ecs register-task-definition --cli-input-json file://path-to-your-task-definition-json
```
1. 次のコマンドを入力して、タスクを実行するサービスを作成します。
サービス名は変更しないでください。CloudWatch エージェントサービスは、タスクを開始したサービスの名前パターンを使用してタスクを検索する設定を使用して実行します。例えば、このコマンドによって起動されたタスクを CloudWatch エージェントが検出するには、`sd_service_name_pattern` の値を `^nginx-service$` に指定します。次のセクションでは、詳細を説明します。
```
aws ecs create-service \
--cluster your-cluster-name \
--service-name nginx-service \
--task-definition nginx-sample-stack:1 \
--desired-count 1
```
### NGINX Prometheus メトリクスをスクレイプするように CloudWatch エージェントを設定する
最後のステップでは、NGINX メトリクスをスクレイピングするように CloudWatch エージェントを設定します。この例では、CloudWatch エージェントはサービス名パターンとポート 9113 を使用してタスクを検出します。このポートでは、エクスポーターは NGINX の Prometheus メトリクスを公開します。タスクが検出され、メトリクスが使用可能になると、CloudWatch エージェントは、ログストリーム **nginx-prometheus-exporter** への収集したメトリクスの投稿を開始します。
**NGINX メトリクスをスクレイピングするように CloudWatch エージェントを設定するには**
1. 次のコマンドを入力して、必要な YAML ファイルの最新バージョンをダウンロードします。
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-bridge-host.yaml
```
1. テキストエディタでファイルを開き、`value` セクションの `resource:CWAgentConfigSSMParameter` キーにある完全な CloudWatch エージェント設定を見つけます。その後、`ecs_service_discovery` セクションで、次の `service_name_list_for_tasks` セクションを追加します。
```
"service_name_list_for_tasks": [
{
"sd_job_name": "nginx-prometheus-exporter",
"sd_metrics_path": "/metrics",
"sd_metrics_ports": "9113",
"sd_service_name_pattern": "^nginx-service$"
}
],
```
1. 同じファイルで、`metric_declaration` セクションに次のセクションを追加して、NGINX メトリクスを許可します。デフォルトのインデントパターンに従ってください。
```
{
"source_labels": ["job"],
"label_matcher": ".*nginx.*",
"dimensions": [["ClusterName", "TaskDefinitionFamily", "ServiceName"]],
"metric_selectors": [
"^nginx_.*$"
]
},
```
1. このクラスターにまだ CloudWatch エージェントがデプロイされていない場合は、ステップ 8 に進みます。
AWS CloudFormation を使用することによって Amazon ECS クラスターに CloudWatch エージェントを既にデプロイしている場合は、次のコマンドを入力して変更セットを作成できます。
```
ECS_CLUSTER_NAME=your_cluster_name
AWS_REGION=your_aws_region
ECS_NETWORK_MODE=bridge
CREATE_IAM_ROLES=True
ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
aws cloudformation create-change-set --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=CreateIAMRoles,ParameterValue=$CREATE_IAM_ROLES \
ParameterKey=ECSNetworkMode,ParameterValue=$ECS_NETWORK_MODE \
ParameterKey=TaskRoleName,ParameterValue=$ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region $AWS_REGION \
--change-set-name nginx-scraping-support
```
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソール を開きます。
1. 新しく作成されたチェンジセット **nginx-scraping-support** を確認します。**CWAgentConfigSSMParameter** リソースに適用された変更が 1 つ表示されます。次のコマンドを入力して、変更セットを実行し、CloudWatch エージェントタスクを再起動します。
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 0 \
--service cwagent-prometheus-replica-service-EC2-$ECS_NETWORK_MODE \
--region $AWS_REGION
```
1. 10 秒ほど待ってから、次のコマンドを入力します。
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 1 \
--service cwagent-prometheus-replica-service-EC2-$ECS_NETWORK_MODE \
--region $AWS_REGION
```
1. クラスターの Prometheus メトリクス収集を使用して CloudWatch エージェントを初めてインストールする場合は、次のコマンドを入力します。
```
ECS_CLUSTER_NAME=your_cluster_name
AWS_REGION=your_aws_region
ECS_NETWORK_MODE=bridge
CREATE_IAM_ROLES=True
ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
aws cloudformation create-stack --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=CreateIAMRoles,ParameterValue=$CREATE_IAM_ROLES \
ParameterKey=ECSNetworkMode,ParameterValue=$ECS_NETWORK_MODE \
ParameterKey=TaskRoleName,ParameterValue=$ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region $AWS_REGION
```
## NGINX メトリクスとログの表示
これで、収集されている NGINX メトリクスを表示できるようになりました。
**サンプル NGINX ワークロードのメトリクスを表示するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. クラスターが実行されているリージョンにおいて、左のナビゲーションペインで [**Metrics**] (メトリクス) を選択します。**ContainerInsights/Prometheus** 名前空間を検索して、メトリクスを確認します。
1. CloudWatch Logs イベントを表示するには、ナビゲーションペインで [**Log Groups (ロググループ)**] を選択します。イベントは、ログストリーム *nginx-prometheus-exporter* のロググループ **/aws/containerinsights/*your\$1cluster\$1name*/prometheus** にあります。
# Amazon ECS クラスターの NGINX Plus ワークロードのサンプル
NGINX Plus は NGINX の商用バージョンです。これを使用するには、ライセンスが必要です。詳細については、「[NGINX Plus](https://www.nginx.com/products/nginx/)」をご参照ください。
NGINX Prometheus エクスポーターは、NGINX データを Prometheus のメトリクスとしてスクレイピングして公開できます。この例では、エクスポーターを Amazon ECS 用の NGINX Plus リバースプロキシサービスと連動させて使用します。
NGINX Prometheus エクスポーターの詳細については、GitHub の [nginx-prometheus-exporter](https://github.com/nginxinc/nginx-prometheus-exporter) をご参照ください。NGINX リバースプロキシの詳細については、GitHub の [ecs-nginx-reverse-proxy](https://github.com/awslabs/ecs-nginx-reverse-proxy)をご参照ください。
Prometheus をサポートする CloudWatch エージェントは、Amazon ECS クラスターのサービス検出設定に基づいて NGINX Plus Prometheus メトリクスをスクレイプします。別のポートまたはパスでメトリクスを公開するように NGINX Prometheus Exporter を設定できます。ポートまたはパスを変更する場合は、CloudWatch エージェント設定ファイルの `ecs_service_discovery` セクションを更新します。
## Amazon ECS クラスター用の NGINX Plus リバースプロキシサンプルワークロードをインストールする
NGINX リバースプロキシサンプルワークロードをインストールするには、次の手順を実行します。
### Docker イメージを作成する
**NGINX Plus リバースプロキシサンプルワークロード用の Docker イメージを作成するには**
1. NGINX リバースプロキシリポジトリから次のフォルダをダウンロードします: [ https://github.com/awslabs/ecs-nginx-reverse-proxy/tree/master/reverse-proxy/](https://github.com/awslabs/ecs-nginx-reverse-proxy/tree/master/reverse-proxy/)。
1. `app` ディレクトリを検索し、そのディレクトリからイメージを作成します。
```
docker build -t web-server-app ./path-to-app-directory
```
1. NGINX Plus 用のカスタムイメージを作成します。NGINX Plus のイメージを作成する前に、ライセンスされている NGINX Plus の `nginx-repo.key` という名前のキーと SSL 証明書 `nginx-repo.crt` を取得する必要があります。ディレクトリを作成し、その中に `nginx-repo.key` ファイルと `nginx-repo.crt` ファイルを格納します。
作成したディレクトリに、次の 2 つのファイルを作成します。
+ 以下の内容を含むサンプル Dockerfile。この docker ファイルは [https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-docker/\$1docker\$1plus\$1image](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-docker/#docker_plus_image) で提供されているサンプルファイルから採用されています。実行する重要な変更は、次のステップで作成される `nginx.conf` と呼ばれる別個のファイルをロードすることです。
```
FROM debian:buster-slim
LABEL maintainer="NGINX Docker Maintainers “
# Define NGINX versions for NGINX Plus and NGINX Plus modules
# Uncomment this block and the versioned nginxPackages block in the main RUN
# instruction to install a specific release
# ENV NGINX_VERSION 21
# ENV NJS_VERSION 0.3.9
# ENV PKG_RELEASE 1~buster
# Download certificate and key from the customer portal (https://cs.nginx.com (https://cs.nginx.com/))
# and copy to the build context
COPY nginx-repo.crt /etc/ssl/nginx/
COPY nginx-repo.key /etc/ssl/nginx/
# COPY nginx.conf /etc/ssl/nginx/nginx.conf
RUN set -x \
# Create nginx user/group first, to be consistent throughout Docker variants
&& addgroup --system --gid 101 nginx \
&& adduser --system --disabled-login --ingroup nginx --no-create-home --home /nonexistent --gecos "nginx user" --shell /bin/false --uid 101 nginx \
&& apt-get update \
&& apt-get install --no-install-recommends --no-install-suggests -y ca-certificates gnupg1 \
&& \
NGINX_GPGKEY=573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62; \
found=''; \
for server in \
ha.pool.sks-keyservers.net (http://ha.pool.sks-keyservers.net/) \
hkp://keyserver.ubuntu.com:80 \
hkp://p80.pool.sks-keyservers.net:80 \
pgp.mit.edu (http://pgp.mit.edu/) \
; do \
echo "Fetching GPG key $NGINX_GPGKEY from $server"; \
apt-key adv --keyserver "$server" --keyserver-options timeout=10 --recv-keys "$NGINX_GPGKEY" && found=yes && break; \
done; \
test -z "$found" && echo >&2 "error: failed to fetch GPG key $NGINX_GPGKEY" && exit 1; \
apt-get remove --purge --auto-remove -y gnupg1 && rm -rf /var/lib/apt/lists/* \
# Install the latest release of NGINX Plus and/or NGINX Plus modules
# Uncomment individual modules if necessary
# Use versioned packages over defaults to specify a release
&& nginxPackages=" \
nginx-plus \
# nginx-plus=${NGINX_VERSION}-${PKG_RELEASE} \
# nginx-plus-module-xslt \
# nginx-plus-module-xslt=${NGINX_VERSION}-${PKG_RELEASE} \
# nginx-plus-module-geoip \
# nginx-plus-module-geoip=${NGINX_VERSION}-${PKG_RELEASE} \
# nginx-plus-module-image-filter \
# nginx-plus-module-image-filter=${NGINX_VERSION}-${PKG_RELEASE} \
# nginx-plus-module-perl \
# nginx-plus-module-perl=${NGINX_VERSION}-${PKG_RELEASE} \
# nginx-plus-module-njs \
# nginx-plus-module-njs=${NGINX_VERSION}+${NJS_VERSION}-${PKG_RELEASE} \
" \
&& echo "Acquire::https::plus-pkgs.nginx.com::Verify-Peer \"true\";" >> /etc/apt/apt.conf.d/90nginx \
&& echo "Acquire::https::plus-pkgs.nginx.com::Verify-Host \"true\";" >> /etc/apt/apt.conf.d/90nginx \
&& echo "Acquire::https::plus-pkgs.nginx.com::SslCert \"/etc/ssl/nginx/nginx-repo.crt\";" >> /etc/apt/apt.conf.d/90nginx \
&& echo "Acquire::https::plus-pkgs.nginx.com::SslKey \"/etc/ssl/nginx/nginx-repo.key\";" >> /etc/apt/apt.conf.d/90nginx \
&& printf "deb https://plus-pkgs.nginx.com/debian buster nginx-plus\n" > /etc/apt/sources.list.d/nginx-plus.list \
&& apt-get update \
&& apt-get install --no-install-recommends --no-install-suggests -y \
$nginxPackages \
gettext-base \
curl \
&& apt-get remove --purge --auto-remove -y && rm -rf /var/lib/apt/lists/* /etc/apt/sources.list.d/nginx-plus.list \
&& rm -rf /etc/apt/apt.conf.d/90nginx /etc/ssl/nginx
# Forward request logs to Docker log collector
RUN ln -sf /dev/stdout /var/log/nginx/access.log \
&& ln -sf /dev/stderr /var/log/nginx/error.log
COPY nginx.conf /etc/nginx/nginx.conf
EXPOSE 80
STOPSIGNAL SIGTERM
CMD ["nginx", "-g", "daemon off;"]
```
+ [https://github.com/awslabs/ecs-nginx-reverse-proxy/tree/master/reverse-proxy/nginx](https://github.com/awslabs/ecs-nginx-reverse-proxy/tree/master/reverse-proxy/nginx) から変更された `nginx.conf` ファイル:
```
events {
worker_connections 768;
}
http {
# Nginx will handle gzip compression of responses from the app server
gzip on;
gzip_proxied any;
gzip_types text/plain application/json;
gzip_min_length 1000;
upstream backend {
zone name 10m;
server app:3000 weight=2;
server app2:3000 weight=1;
}
server{
listen 8080;
location /api {
api write=on;
}
}
match server_ok {
status 100-599;
}
server {
listen 80;
status_zone zone;
# Nginx will reject anything not matching /api
location /api {
# Reject requests with unsupported HTTP method
if ($request_method !~ ^(GET|POST|HEAD|OPTIONS|PUT|DELETE)$) {
return 405;
}
# Only requests matching the whitelist expectations will
# get sent to the application server
proxy_pass http://backend;
health_check uri=/lorem-ipsum match=server_ok;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_cache_bypass $http_upgrade;
}
}
}
```
1. 新しいディレクトリのファイルからイメージを作成します。
```
docker build -t nginx-plus-reverse-proxy ./path-to-your-directory
```
1. 後で使用するために、新しいイメージをイメージリポジトリにアップロードします。
### Amazon ECS で NGINX Plus とウェブサーバーアプリを実行するタスク定義を作成します。
次に、タスク定義を設定します。
このタスク定義により、NGINX Plus Prometheus メトリクスの収集とエクスポートが可能になります。NGINX コンテナは、アプリからの入力を追跡し、(`nginx.conf` で設定されているとおり) そのデータをポート 8080 に公開します。NGINX Prometheus エクスポーターコンテナは、CloudWatch で使用するために、これらのメトリクスをスクレイピングし、ポート 9113 に投稿します。
**NGINX サンプル Amazon ECS ワークロードのタスク定義を設定するには**
1. 次の内容でタスク定義 JSON ファイルを作成します。*your-customized-nginx-plus-image* をカスタマイズした NGINX Plus イメージのイメージ URI に置き換え、*your-web-server-app-image* をウェブサーバーアプリイメージのイメージ URI に置き換えます。
```
{
"containerDefinitions": [
{
"name": "nginx",
"image": "your-customized-nginx-plus-image",
"memory": 256,
"cpu": 256,
"essential": true,
"portMappings": [
{
"containerPort": 80,
"protocol": "tcp"
}
],
"links": [
"app",
"app2"
]
},
{
"name": "app",
"image": "your-web-server-app-image",
"memory": 256,
"cpu": 128,
"essential": true
},
{
"name": "app2",
"image": "your-web-server-app-image",
"memory": 256,
"cpu": 128,
"essential": true
},
{
"name": "nginx-prometheus-exporter",
"image": "docker.io/nginx/nginx-prometheus-exporter:0.8.0",
"memory": 256,
"cpu": 256,
"essential": true,
"command": [
"-nginx.plus",
"-nginx.scrape-uri",
"http://nginx:8080/api"
],
"links":[
"nginx"
],
"portMappings":[
{
"containerPort": 9113,
"protocol": "tcp"
}
]
}
],
"networkMode": "bridge",
"placementConstraints": [],
"family": "nginx-plus-sample-stack"
}
```
1. タスク定義を登録します。
```
aws ecs register-task-definition --cli-input-json file://path-to-your-task-definition-json
```
1. 次のコマンドを入力して、タスクを実行するサービスを作成します。
```
aws ecs create-service \
--cluster your-cluster-name \
--service-name nginx-plus-service \
--task-definition nginx-plus-sample-stack:1 \
--desired-count 1
```
サービス名は変更しないでください。CloudWatch エージェントサービスは、タスクを開始したサービスの名前パターンを使用してタスクを検索する設定を使用して実行します。例えば、このコマンドによって起動されたタスクを CloudWatch エージェントが検出するには、`sd_service_name_pattern` の値を `^nginx-plus-service$` に指定します。次のセクションでは、詳細を説明します。
### NGINX Plus Prometheus メトリクスをスクレイプするように CloudWatch エージェントを設定する
最後のステップでは、NGINX メトリクスをスクレイピングするように CloudWatch エージェントを設定します。この例では、CloudWatch エージェントはサービス名パターンとポート 9113 を使用してタスクを検出します。このポートでは、エクスポーターは NGINX の Prometheus メトリクスを公開します。タスクが検出され、メトリクスが使用可能になると、CloudWatch エージェントは、ログストリーム **nginx-prometheus-exporter** への収集したメトリクスの投稿を開始します。
**NGINX メトリクスをスクレイピングするように CloudWatch エージェントを設定するには**
1. 次のコマンドを入力して、必要な YAML ファイルの最新バージョンをダウンロードします。
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-bridge-host.yaml
```
1. テキストエディタでファイルを開き、`value` セクションの `resource:CWAgentConfigSSMParameter` キーにある完全な CloudWatch エージェント設定を見つけます。その後、`ecs_service_discovery` セクションで、次の `service_name_list_for_tasks` セクションを追加します。
```
"service_name_list_for_tasks": [
{
"sd_job_name": "nginx-plus-prometheus-exporter",
"sd_metrics_path": "/metrics",
"sd_metrics_ports": "9113",
"sd_service_name_pattern": "^nginx-plus.*"
}
],
```
1. 同じファイルで、`metric_declaration` セクションに次のセクションを追加して、NGINX Plus メトリクスを許可します。デフォルトのインデントパターンに従ってください。
```
{
"source_labels": ["job"],
"label_matcher": "^nginx-plus.*",
"dimensions": [["ClusterName", "TaskDefinitionFamily", "ServiceName"]],
"metric_selectors": [
"^nginxplus_connections_accepted$",
"^nginxplus_connections_active$",
"^nginxplus_connections_dropped$",
"^nginxplus_connections_idle$",
"^nginxplus_http_requests_total$",
"^nginxplus_ssl_handshakes$",
"^nginxplus_ssl_handshakes_failed$",
"^nginxplus_up$",
"^nginxplus_upstream_server_health_checks_fails$"
]
},
{
"source_labels": ["job"],
"label_matcher": "^nginx-plus.*",
"dimensions": [["ClusterName", "TaskDefinitionFamily", "ServiceName", "upstream"]],
"metric_selectors": [
"^nginxplus_upstream_server_response_time$"
]
},
{
"source_labels": ["job"],
"label_matcher": "^nginx-plus.*",
"dimensions": [["ClusterName", "TaskDefinitionFamily", "ServiceName", "code"]],
"metric_selectors": [
"^nginxplus_upstream_server_responses$",
"^nginxplus_server_zone_responses$"
]
},
```
1. このクラスターにまだ CloudWatch エージェントがデプロイされていない場合は、ステップ 8 に進みます。
AWS CloudFormation を使用することによって Amazon ECS クラスターに CloudWatch エージェントを既にデプロイしている場合は、次のコマンドを入力して変更セットを作成できます。
```
ECS_CLUSTER_NAME=your_cluster_name
AWS_REGION=your_aws_region
ECS_NETWORK_MODE=bridge
CREATE_IAM_ROLES=True
ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
aws cloudformation create-change-set --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=CreateIAMRoles,ParameterValue=$CREATE_IAM_ROLES \
ParameterKey=ECSNetworkMode,ParameterValue=$ECS_NETWORK_MODE \
ParameterKey=TaskRoleName,ParameterValue=$ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region $AWS_REGION \
--change-set-name nginx-plus-scraping-support
```
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソール を開きます。
1. 新しく作成されたチェンジセット **nginx-plus-scraping-support** を確認します。**CWAgentConfigSSMParameter** リソースに適用された変更が 1 つ表示されます。次のコマンドを入力して、変更セットを実行し、CloudWatch エージェントタスクを再起動します。
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 0 \
--service cwagent-prometheus-replica-service-EC2-$ECS_NETWORK_MODE \
--region $AWS_REGION
```
1. 10 秒ほど待ってから、次のコマンドを入力します。
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 1 \
--service cwagent-prometheus-replica-service-EC2-$ECS_NETWORK_MODE \
--region $AWS_REGION
```
1. クラスターの Prometheus メトリクス収集を使用して CloudWatch エージェントを初めてインストールする場合は、次のコマンドを入力します。
```
ECS_CLUSTER_NAME=your_cluster_name
AWS_REGION=your_aws_region
ECS_NETWORK_MODE=bridge
CREATE_IAM_ROLES=True
ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
aws cloudformation create-stack --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=CreateIAMRoles,ParameterValue=$CREATE_IAM_ROLES \
ParameterKey=ECSNetworkMode,ParameterValue=$ECS_NETWORK_MODE \
ParameterKey=TaskRoleName,ParameterValue=$ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region $AWS_REGION
```
## NGINX Plus メトリクスとログの表示
これで、収集されている NGINX Plus メトリクスを表示できるようになりました。
**サンプル NGINX ワークロードのメトリクスを表示するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. クラスターが実行されているリージョンにおいて、左のナビゲーションペインで [**Metrics**] (メトリクス) を選択します。**ContainerInsights/Prometheus** 名前空間を検索して、メトリクスを確認します。
1. CloudWatch Logs イベントを表示するには、ナビゲーションペインで [**Log Groups (ロググループ)**] を選択します。イベントは、ログストリーム *nginx-plus-prometheus-exporter* のロググループ **/aws/containerinsights/*your\$1cluster\$1name*/prometheus** にあります。
# 新しい Prometheus スクレイピングターゲットを追加するためのチュートリアル: Amazon ECS の Memcached
このチュートリアルでは、EC2 起動タイプの Amazon ECS クラスター上のサンプル Memcached アプリケーションの Prometheus メトリクスをスクレイプする実践的な紹介を提供します。Memcached Prometheus エクスポーターのターゲットは、ECS タスク定義ベースのサービス検出によって CloudWatch エージェントによって自動検出されます。
Memcached は、汎用分散メモリキャッシュシステムです。多くの場合、データおよびオブジェクトを RAM にキャッシュし、外部データソース (データベースや API など) を読み取る回数を減らすことで、動的なデータベース駆動のウェブサイトを高速化するために使用されます。詳細については、「[Memcached とは](https://www.memcached.org/)」を参照してください。
[ memchached\$1exporter](https://github.com/prometheus/memcached_exporter) (Apache License 2.0) は、Prometheus 公式エクスポーターの一つです。デフォルトでは、memcache\$1exporter は `/metrics.` のポート 0.0.0.0:9150 でサービスを提供します。
このチュートリアルでは、次の 2 つの Docker ハブリポジトリの Docker イメージを使用します。
+ [Memcached](https://hub.docker.com/_/memcached?tab=description)
+ [ prom/memcached-exporter](https://hub.docker.com/r/prom/memcached-exporter/)
**前提条件**
Amazon ECS のサンプル Prometheus ワークロードからメトリクスを収集するには、クラスターで Container Insights を実行している必要があります。Container Insights のインストールの詳細については、「[Amazon ECS での Container Insights のセットアップ](deploy-container-insights-ECS.md)」を参照してください。
**Topics**
+ [Amazon ECS EC2 クラスター環境変数を設定する](#ContainerInsights-Prometheus-Setup-memcached-ecs-environment)
+ [Memcached サンプルワークロードのインストール](#ContainerInsights-Prometheus-Setup-memcached-ecs-install-workload)
+ [Memcached Prometheus メトリクスをスクレイプするように CloudWatch エージェントを設定する](#ContainerInsights-Prometheus-Setup-memcached-ecs-agent)
+ [Memcached メトリクスの表示](#ContainerInsights-Prometheus-ECS-memcached-view)
## Amazon ECS EC2 クラスター環境変数を設定する
**Amazon ECS EC2 クラスター環境変数を設定するには**
1. まだの場合は、Amazon ECS CLI をインストールしてください。詳細については、「[Amazon ECS CLI のインストール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_CLI_installation.html)」を参照してください。
1. 新しい Amazon ECS クラスター名とリージョンを設定します。次に例を示します。
```
ECS_CLUSTER_NAME=ecs-ec2-memcached-tutorial
AWS_DEFAULT_REGION=ca-central-1
```
1. (オプション) Memcached サンプルワークロードと CloudWatch エージェントをインストールする EC2 起動タイプの Amazon ECS クラスターがまだない場合は、次のコマンドを入力してクラスターを作成できます。
```
ecs-cli up --capability-iam --size 1 \
--instance-type t3.medium \
--cluster $ECS_CLUSTER_NAME \
--region $AWS_REGION
```
このコマンドの予想される結果は次のとおりです。
```
WARN[0000] You will not be able to SSH into your EC2 instances without a key pair.
INFO[0000] Using recommended Amazon Linux 2 AMI with ECS Agent 1.44.4 and Docker version 19.03.6-ce
INFO[0001] Created cluster cluster=ecs-ec2-memcached-tutorial region=ca-central-1
INFO[0002] Waiting for your cluster resources to be created...
INFO[0002] Cloudformation stack status stackStatus=CREATE_IN_PROGRESS
INFO[0063] Cloudformation stack status stackStatus=CREATE_IN_PROGRESS
INFO[0124] Cloudformation stack status stackStatus=CREATE_IN_PROGRESS
VPC created: vpc-xxxxxxxxxxxxxxxxx
Security Group created: sg-xxxxxxxxxxxxxxxxx
Subnet created: subnet-xxxxxxxxxxxxxxxxx
Subnet created: subnet-xxxxxxxxxxxxxxxxx
Cluster creation succeeded.
```
## Memcached サンプルワークロードのインストール
**Prometheus メトリクスを公開する Memcached サンプルワークロードをインストールするには**
1. 次のコマンドを入力して、Memcached CloudFormation テンプレートをダウンロードします。
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/sample_traffic/memcached/memcached-traffic-sample.yaml
```
1. 次のコマンドを入力して、Memcached 用に作成する IAM ロール名を設定します。
```
MEMCACHED_ECS_TASK_ROLE_NAME=memcached-prometheus-demo-ecs-task-role-name
MEMCACHED_ECS_EXECUTION_ROLE_NAME=memcached-prometheus-demo-ecs-execution-role-name
```
1. 次のコマンドを入力して、Memcached サンプルワークロードをインストールします。このサンプルでは、ワークロードを `host` ネットワークモードでインストールします。
```
MEMCACHED_ECS_NETWORK_MODE=host
aws cloudformation create-stack --stack-name Memcached-Prometheus-Demo-ECS-$ECS_CLUSTER_NAME-EC2-$MEMCACHED_ECS_NETWORK_MODE \
--template-body file://memcached-traffic-sample.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=ECSNetworkMode,ParameterValue=$MEMCACHED_ECS_NETWORK_MODE \
ParameterKey=TaskRoleName,ParameterValue=$MEMCACHED_ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$MEMCACHED_ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region $AWS_REGION
```
CloudFormation スタックは、次の 4 つのリソースを作成します。
+ 1 つの ECS タスクロール
+ 1 つの ECS タスク実行ロール
+ 1 つの Memcached タスク定義
+ 1 つの Memcached サービス
Memcached タスク定義では、次の 2 つのコンテナが定義されています。
+ プライマリコンテナは単純な Memcached アプリケーションを実行し、アクセス用にポート 11211 を開きます。
+ もう一方のコンテナは Redis OSS エクスポータープロセスを実行して、ポート 9150 の Prometheus メトリクスを公開します。これは、CloudWatch エージェントによって検出され、スクレイプされるコンテナです。
## Memcached Prometheus メトリクスをスクレイプするように CloudWatch エージェントを設定する
**Memcached Prometheus メトリクスをスクレイプするように CloudWatch エージェントを設定するには**
1. 次のコマンドを入力して、`cwagent-ecs-prometheus-metric-for-awsvpc.yaml` の最新バージョンをダウンロードします。
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-awsvpc.yaml
```
1. テキストエディタでファイルを開き、`value` セクションの `resource:CWAgentConfigSSMParameter` キーの背後にある完全な CloudWatch エージェント設定を見つけます。
次に、`ecs_service_discovery` セクションで、次の設定を `task_definition_list` セクションに追加します。
```
{
"sd_job_name": "ecs-memcached",
"sd_metrics_ports": "9150",
"sd_task_definition_arn_pattern": ".*:task-definition/memcached-prometheus-demo.*:[0-9]+"
},
```
`metric_declaration` セクションの場合、デフォルト設定では Memcached メトリクスを許可しません。Memcached メトリクスを許可するには、次のセクションを追加します。デフォルトのインデントパターンに従ってください。
```
{
"source_labels": ["container_name"],
"label_matcher": "memcached-exporter-.*",
"dimensions": [["ClusterName", "TaskDefinitionFamily"]],
"metric_selectors": [
"^memcached_current_(bytes|items|connections)$",
"^memcached_items_(reclaimed|evicted)_total$",
"^memcached_(written|read)_bytes_total$",
"^memcached_limit_bytes$",
"^memcached_commands_total$"
]
},
{
"source_labels": ["container_name"],
"label_matcher": "memcached-exporter-.*",
"dimensions": [["ClusterName", "TaskDefinitionFamily","status","command"], ["ClusterName", "TaskDefinitionFamily","command"]],
"metric_selectors": [
"^memcached_commands_total$"
]
},
```
1. CloudFormation によって Amazon ECS クラスターに CloudWatch エージェントを既にデプロイしている場合は、次のコマンドを入力して変更セットを作成できます。
```
ECS_NETWORK_MODE=bridge
CREATE_IAM_ROLES=True
ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
aws cloudformation create-change-set --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=CreateIAMRoles,ParameterValue=$CREATE_IAM_ROLES \
ParameterKey=ECSNetworkMode,ParameterValue=$ECS_NETWORK_MODE \
ParameterKey=TaskRoleName,ParameterValue=$ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region $AWS_REGION \
--change-set-name memcached-scraping-support
```
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソール を開きます。
1. 新しく作成された変更セット `memcached-scraping-support` を確認します。`CWAgentConfigSSMParameter` リソースに 1 つの変更が適用されていることがわかります。次のコマンドを入力して、変更セットを実行し、CloudWatch エージェントタスクを再起動します。
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 0 \
--service cwagent-prometheus-replica-service-EC2-$ECS_NETWORK_MODE \
--region $AWS_REGION
```
1. 10 秒ほど待ってから、次のコマンドを入力します。
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 1 \
--service cwagent-prometheus-replica-service-EC2-$ECS_NETWORK_MODE \
--region $AWS_REGION
```
1. クラスターの Prometheus メトリクス収集を使用して CloudWatch エージェントを初めてインストールする場合は、次のコマンドを入力します。
```
ECS_NETWORK_MODEE=bridge
CREATE_IAM_ROLES=True
ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
aws cloudformation create-stack --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=CreateIAMRoles,ParameterValue=$CREATE_IAM_ROLES \
ParameterKey=ECSNetworkMode,ParameterValue=$ECS_NETWORK_MODE \
ParameterKey=TaskRoleName,ParameterValue=$ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region $AWS_REGION
```
## Memcached メトリクスの表示
このチュートリアルでは、次のメトリクスを CloudWatch の **ECS/ContainerInsights/Prometheus** 名前空間に送信します。CloudWatch コンソールを使用して、その名前空間のメトリクスを表示できます。
| メトリクス名 | ディメンション |
| --- | --- |
| `memcached_current_items` | `ClusterName`, `TaskDefinitionFamily` |
| `memcached_current_connections` | `ClusterName`, `TaskDefinitionFamily` |
| `memcached_limit_bytes` | `ClusterName`, `TaskDefinitionFamily` |
| `memcached_current_bytes` | `ClusterName`, `TaskDefinitionFamily` |
| `memcached_written_bytes_total` | `ClusterName`, `TaskDefinitionFamily` |
| `memcached_read_bytes_total` | `ClusterName`, `TaskDefinitionFamily` |
| `memcached_items_evicted_total` | `ClusterName`, `TaskDefinitionFamily` |
| `memcached_items_reclaimed_total` | `ClusterName`, `TaskDefinitionFamily` |
| `memcached_commands_total` | `ClusterName`, `TaskDefinitionFamily` `ClusterName`、TaskDefinitionFamily、コマンド `ClusterName`、TaskDefinitionFamily、ステータス、コマンド |
**注記**
**コマンド** ディメンションの値には `delete`、`get`、`cas`、`set`、`decr`、`touch`、`incr`、または `flush` を指定できます。
**ステータス** ディメンションの値は `hit`、`miss`、または `badval`です。
Memcached Prometheus メトリクスの CloudWatch ダッシュボードを作成することもできます。
**Memcached Prometheus メトリクスのダッシュボードを作成するには**
1. 環境変数を作成し、以下の値をデプロイに合わせて置き換えます。
```
DASHBOARD_NAME=your_memcached_cw_dashboard_name
ECS_TASK_DEF_FAMILY=memcached-prometheus-demo-$ECS_CLUSTER_NAME-EC2-$MEMCACHED_ECS_NETWORK_MOD
```
1. 次のコマンドを入力して、ダッシュボードを作成します。
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/sample_cloudwatch_dashboards/memcached/cw_dashboard_memcached.json \
| sed "s/{{YOUR_AWS_REGION}}/$AWS_REGION/g" \
| sed "s/{{YOUR_CLUSTER_NAME}}/$ECS_CLUSTER_NAME/g" \
| sed "s/{{YOUR_TASK_DEF_FAMILY}}/$ECS_TASK_DEF_FAMILY/g" \
| xargs -0 aws cloudwatch put-dashboard --dashboard-name ${DASHBOARD_NAME} --region $AWS_REGION --dashboard-body
```
# Amazon ECS Fargate 上の Redis OSS Prometheus メトリクスのスクレイピングに関するチュートリアル
このチュートリアルでは、Amazon ECS Fargate クラスター内のサンプル Redis OSS アプリケーションの Prometheus メトリクスをスクレイピングする方法を実践的に説明します。Redis OSS Prometheus エクスポーターのターゲットは、コンテナの Docker ラベルに基づいて Prometheus メトリクスサポートを持つ CloudWatch エージェントによって自動検出されます。
Redis OSS (https://redis.io/) は、オープンソース (BSD ライセンス適用) のインメモリ型のデータ構造ストアで、データベース、キャッシュ、メッセージブローカーとして使用されます。詳細については、「[redis](https://redis.io/)」を参照してください。
redis\$1exporter (MIT ライセンス適用) は、指定されたポート (デフォルト: 0.0.0.0:9121) で Redis OSS Prometheus メトリクスを公開するために使用します。詳細については、「[redis\$1exporter](https://github.com/oliver006/redis_exporter)」を参照してください。
このチュートリアルでは、次の 2 つの Docker ハブリポジトリの Docker イメージを使用します。
+ [redis](https://hub.docker.com/_/redis?tab=description)
+ [redis\$1exporter](https://hub.docker.com/r/oliver006/redis_exporter)
**前提条件**
Amazon ECS のサンプル Prometheus ワークロードからメトリクスを収集するには、クラスターで Container Insights を実行している必要があります。Container Insights のインストールの詳細については、「[Amazon ECS での Container Insights のセットアップ](deploy-container-insights-ECS.md)」を参照してください。
**Topics**
+ [Amazon ECS Fargate クラスター環境変数を設定する](#ContainerInsights-Prometheus-Setup-redis-ecs-variable)
+ [Amazon ECS Fargate クラスターのネットワーク環境変数を設定する](#ContainerInsights-Prometheus-Setup-redis-ecs-variable2)
+ [サンプル Redis OSS ワークロードのインストール](#ContainerInsights-Prometheus-Setup-redis-ecs-install-workload)
+ [CloudWatch エージェントを設定して Redis OSS Prometheus メトリクスをスクレイピングする](#ContainerInsights-Prometheus-Setup-redis-ecs-agent)
+ [Redis OSS メトリクスの表示](#ContainerInsights-Prometheus-Setup-redis-view)
## Amazon ECS Fargate クラスター環境変数を設定する
**Amazon ECS Fargate クラスター環境変数を設定するには**
1. まだの場合は、Amazon ECS CLI をインストールしてください。詳細については、「[Amazon ECS CLI のインストール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_CLI_installation.html)」を参照してください。
1. 新しい Amazon ECS クラスター名とリージョンを設定します。例えば、次のようになります。
```
ECS_CLUSTER_NAME=ecs-fargate-redis-tutorial
AWS_DEFAULT_REGION=ca-central-1
```
1. (オプション) サンプル Redis OSS ワークロードと CloudWatch エージェントのインストール先となる Amazon ECS Fargate クラスターがまだない場合は、次のコマンドを入力してクラスターを作成できます。
```
ecs-cli up --capability-iam \
--cluster $ECS_CLUSTER_NAME \
--launch-type FARGATE \
--region $AWS_DEFAULT_REGION
```
このコマンドの予想される結果は次のとおりです。
```
INFO[0000] Created cluster cluster=ecs-fargate-redis-tutorial region=ca-central-1
INFO[0001] Waiting for your cluster resources to be created...
INFO[0001] Cloudformation stack status stackStatus=CREATE_IN_PROGRESS
VPC created: vpc-xxxxxxxxxxxxxxxxx
Subnet created: subnet-xxxxxxxxxxxxxxxxx
Subnet created: subnet-xxxxxxxxxxxxxxxxx
Cluster creation succeeded.
```
## Amazon ECS Fargate クラスターのネットワーク環境変数を設定する
**Amazon ECS Fargate クラスターのネットワーク環境変数を設定するには**
1. Amazon ECS クラスターの VPC とサブネット ID を設定します。前の手順で新しいクラスターを作成した場合は、最後のコマンドの結果にこれらの値が表示されます。それ以外の場合は、Redis で使用する既存のクラスターの ID を使用します。
```
ECS_CLUSTER_VPC=vpc-xxxxxxxxxxxxxxxxx
ECS_CLUSTER_SUBNET_1=subnet-xxxxxxxxxxxxxxxxx
ECS_CLUSTER_SUBNET_2=subnet-xxxxxxxxxxxxxxxxx
```
1. このチュートリアルでは、Redis OSS アプリケーションと CloudWatch エージェントを Amazon ECS クラスターの VPC のデフォルトセキュリティグループにインストールします。デフォルトセキュリティグループでは、同じセキュリティグループ内のすべてのネットワーク接続が許可されるため、CloudWatch エージェントによる Redis OSS コンテナで公開されている Prometheus メトリクスのスクレイピングが可能です。実際の本番環境では、Redis OSS アプリケーションと CloudWatch エージェント専用のセキュリティグループを作成し、カスタマイズしたアクセス許可をそれぞれに設定することもできます。
次のコマンドを入力して、デフォルトのセキュリティグループ ID を取得します。
```
aws ec2 describe-security-groups \
--filters Name=vpc-id,Values=$ECS_CLUSTER_VPC \
--region $AWS_DEFAULT_REGION
```
次に、次のコマンドを入力して、Fargate クラスターデフォルトセキュリティグループ変数を設定します。*my-default-security-group* を前のコマンドから取得した値に置き換えます。
```
ECS_CLUSTER_SECURITY_GROUP=my-default-security-group
```
## サンプル Redis OSS ワークロードのインストール
**Prometheus メトリクスを公開するサンプル Redis OSS ワークロードをインストールするには**
1. 次のコマンドを入力して、Redis OSS CloudFormation テンプレートをダウンロードします。
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/sample_traffic/redis/redis-traffic-sample.yaml
```
1. 次のコマンドを入力して、Redis OSS 用に作成する IAM ロール名を設定します。
```
REDIS_ECS_TASK_ROLE_NAME=redis-prometheus-demo-ecs-task-role-name
REDIS_ECS_EXECUTION_ROLE_NAME=redis-prometheus-demo-ecs-execution-role-name
```
1. 次のコマンドを入力して、サンプル Redis OSS ワークロードをインストールします。
```
aws cloudformation create-stack --stack-name Redis-Prometheus-Demo-ECS-$ECS_CLUSTER_NAME-fargate-awsvpc \
--template-body file://redis-traffic-sample.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=SecurityGroupID,ParameterValue=$ECS_CLUSTER_SECURITY_GROUP \
ParameterKey=SubnetID,ParameterValue=$ECS_CLUSTER_SUBNET_1 \
ParameterKey=TaskRoleName,ParameterValue=$REDIS_ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$REDIS_ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region $AWS_DEFAULT_REGION
```
CloudFormation スタックは、次の 4 つのリソースを作成します。
+ 1 つの ECS タスクロール
+ 1 つの ECS タスク実行ロール
+ 1 つの Redis OSS タスク定義
+ 1 つの Redis OSS サービス
Redis OSS タスク定義では、2 つのコンテナが定義されています。
+ プライマリコンテナは単純な Redis OSS アプリケーションを実行し、アクセス用にポート 6379 を開きます。
+ もう一方のコンテナは Redis OSS エクスポータープロセスを実行して、ポート 9121 で Prometheus メトリクスを公開します。これは、CloudWatch エージェントによって検出され、スクレイプされるコンテナです。次のドッカーラベルは、CloudWatch エージェントがそれに基づいてこのコンテナを検出できるように定義されています。
```
ECS_PROMETHEUS_EXPORTER_PORT: 9121
```
## CloudWatch エージェントを設定して Redis OSS Prometheus メトリクスをスクレイピングする
**CloudWatch エージェントを設定して Redis OSS Prometheus メトリクスをスクレイピングするには**
1. 次のコマンドを入力して、`cwagent-ecs-prometheus-metric-for-awsvpc.yaml` の最新バージョンをダウンロードします。
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/ecs-task-definition-templates/deployment-mode/replica-service/cwagent-prometheus/cloudformation-quickstart/cwagent-ecs-prometheus-metric-for-awsvpc.yaml
```
1. テキストエディタでファイルを開き、`value` セクションの `resource:CWAgentConfigSSMParameter` キーの背後にある完全な CloudWatch エージェント設定を見つけます。
次に、ここに示す `ecs_service_discovery` セクションでは、`docker_label` ベースのサービス検出が、Redis OSS ECS タスク定義で定義した Docker ラベルと一致する `ECS_PROMETHEUS_EXPORTER_PORT` をベースとしたデフォルト設定で有効になっています。したがって、このセクションで変更を加える必要はありません。
```
ecs_service_discovery": {
"sd_frequency": "1m",
"sd_result_file": "/tmp/cwagent_ecs_auto_sd.yaml",
* "docker_label": {
},*
...
```
`metric_declaration` セクションの場合、デフォルト設定で Redis OSS メトリクスは許可されません。Redis OSS メトリクスを許可するには、次のセクションを追加します。デフォルトのインデントパターンに従ってください。
```
{
"source_labels": ["container_name"],
"label_matcher": "^redis-exporter-.*$",
"dimensions": [["ClusterName","TaskDefinitionFamily"]],
"metric_selectors": [
"^redis_net_(in|out)put_bytes_total$",
"^redis_(expired|evicted)_keys_total$",
"^redis_keyspace_(hits|misses)_total$",
"^redis_memory_used_bytes$",
"^redis_connected_clients$"
]
},
{
"source_labels": ["container_name"],
"label_matcher": "^redis-exporter-.*$",
"dimensions": [["ClusterName","TaskDefinitionFamily","cmd"]],
"metric_selectors": [
"^redis_commands_total$"
]
},
{
"source_labels": ["container_name"],
"label_matcher": "^redis-exporter-.*$",
"dimensions": [["ClusterName","TaskDefinitionFamily","db"]],
"metric_selectors": [
"^redis_db_keys$"
]
},
```
1. CloudFormation によって Amazon ECS クラスターに CloudWatch エージェントを既にデプロイしている場合は、次のコマンドを入力して変更セットを作成できます。
```
ECS_LAUNCH_TYPE=FARGATE
CREATE_IAM_ROLES=True
ECS_CLUSTER_SUBNET=$ECS_CLUSTER_SUBNET_1
ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
aws cloudformation create-change-set --stack-name CWAgent-Prometheus-ECS-$ECS_CLUSTER_NAME-$ECS_LAUNCH_TYPE-awsvpc \
--template-body file://cwagent-ecs-prometheus-metric-for-awsvpc.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=CreateIAMRoles,ParameterValue=$CREATE_IAM_ROLES \
ParameterKey=ECSLaunchType,ParameterValue=$ECS_LAUNCH_TYPE \
ParameterKey=SecurityGroupID,ParameterValue=$ECS_CLUSTER_SECURITY_GROUP \
ParameterKey=SubnetID,ParameterValue=$ECS_CLUSTER_SUBNET \
ParameterKey=TaskRoleName,ParameterValue=$ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region ${AWS_DEFAULT_REGION} \
--change-set-name redis-scraping-support
```
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソール を開きます。
1. 新しく作成された変更セット `redis-scraping-support` を確認します。`CWAgentConfigSSMParameter` リソースに 1 つの変更が適用されていることがわかります。次のコマンドを入力して、変更セットを実行し、CloudWatch エージェントタスクを再起動します。
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 0 \
--service cwagent-prometheus-replica-service-$ECS_LAUNCH_TYPE-awsvpc \
--region ${AWS_DEFAULT_REGION}
```
1. 10 秒ほど待ってから、次のコマンドを入力します。
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 1 \
--service cwagent-prometheus-replica-service-$ECS_LAUNCH_TYPE-awsvpc \
--region ${AWS_DEFAULT_REGION}
```
1. クラスターの Prometheus メトリクス収集を使用して CloudWatch エージェントを初めてインストールする場合は、次のコマンドを入力します。
```
ECS_LAUNCH_TYPE=FARGATE
CREATE_IAM_ROLES=True
ECS_CLUSTER_SUBNET=$ECS_CLUSTER_SUBNET_1
ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
aws cloudformation create-stack --stack-name CWAgent-Prometheus-ECS-$ECS_CLUSTER_NAME-$ECS_LAUNCH_TYPE-awsvpc \
--template-body file://cwagent-ecs-prometheus-metric-for-awsvpc.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=CreateIAMRoles,ParameterValue=$CREATE_IAM_ROLES \
ParameterKey=ECSLaunchType,ParameterValue=$ECS_LAUNCH_TYPE \
ParameterKey=SecurityGroupID,ParameterValue=$ECS_CLUSTER_SECURITY_GROUP \
ParameterKey=SubnetID,ParameterValue=$ECS_CLUSTER_SUBNET \
ParameterKey=TaskRoleName,ParameterValue=$ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region ${AWS_DEFAULT_REGION}
```
## Redis OSS メトリクスの表示
このチュートリアルでは、次のメトリクスを CloudWatch の **ECS/ContainerInsights/Prometheus** 名前空間に送信します。CloudWatch コンソールを使用して、その名前空間のメトリクスを表示できます。
| メトリクス名 | ディメンション |
| --- | --- |
| `redis_net_input_bytes_total` | ClusterName、`TaskDefinitionFamily` |
| `redis_net_output_bytes_total` | ClusterName、`TaskDefinitionFamily` |
| `redis_expired_keys_total` | ClusterName、`TaskDefinitionFamily` |
| `redis_evicted_keys_total` | ClusterName、`TaskDefinitionFamily` |
| `redis_keyspace_hits_total` | ClusterName、`TaskDefinitionFamily` |
| `redis_keyspace_misses_total` | ClusterName、`TaskDefinitionFamily` |
| `redis_memory_used_bytes` | ClusterName、`TaskDefinitionFamily` |
| `redis_connected_clients` | ClusterName、`TaskDefinitionFamily` |
| `redis_commands_total` | ` ClusterName`, `TaskDefinitionFamily`, `cmd` |
| `redis_db_keys` | `ClusterName`, `TaskDefinitionFamily`, `db` |
**注記**
**cmd** ディメンションの値には `append`、`client`、`command`、`config`、`dbsize`、`flushall`、`get`、`incr`、`info`、`latency`、または `slowlog` を指定できます。
**db** ディメンションの値は `db0` から `db15` に指定できます。
また、Redis OSS Prometheus メトリクスの CloudWatch ダッシュボードを作成することもできます。
**Redis OSS Prometheus メトリクスのダッシュボードを作成するには**
1. 環境変数を作成し、以下の値をデプロイに合わせて置き換えます。
```
DASHBOARD_NAME=your_cw_dashboard_name
ECS_TASK_DEF_FAMILY=redis-prometheus-demo-$ECS_CLUSTER_NAME-fargate-awsvpc
```
1. 次のコマンドを入力して、ダッシュボードを作成します。
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_cloudwatch_dashboards/redis/cw_dashboard_redis.json \
| sed "s/{{YOUR_AWS_REGION}}/${REGION_NAME}/g" \
| sed "s/{{YOUR_CLUSTER_NAME}}/${CLUSTER_NAME}/g" \
| sed "s/{{YOUR_NAMESPACE}}/${NAMESPACE}/g" \
```
# Amazon EKS および Kubernetes クラスターでの Prometheus メトリクスコレクションの設定と構成
Amazon EKS または Kubernetes を実行しているクラスターから Prometheus メトリクスを収集するには、CloudWatch エージェントをコレクターとして使用するか、AWS Distro for OpenTelemetry コレクターを使用できます。AWS Distro for OpenTelemetry コレクターの使用については、[https://aws-otel.github.io/docs/getting-started/container-insights/eks-prometheus](https://aws-otel.github.io/docs/getting-started/container-insights/eks-prometheus) を参照してください。
以下のセクションでは、CloudWatch エージェントを使用して Prometheus メトリクスを収集する方法について説明します。Amazon EKS または Kubernetes を実行しているクラスターに Prometheus モニターリングを使用して CloudWatch エージェントをインストールする方法と、追加のターゲットをスクレイプするようにエージェントを設定する方法について説明します。また、Prometheus モニターリングでのテストに使用するサンプルワークロードを設定するためのオプションのチュートリアルも提供します。
**Topics**
+ [Amazon EKS および Kubernetes クラスターに Prometheus メトリクスコレクションを使用して CloudWatch エージェントをインストールする](ContainerInsights-Prometheus-Setup.md)
# Amazon EKS および Kubernetes クラスターに Prometheus メトリクスコレクションを使用して CloudWatch エージェントをインストールする
このセクションでは、Amazon EKS または Kubernetes を実行しているクラスターで Prometheus モニターリングを使用して CloudWatch エージェントをセットアップする方法について説明します。これを行うと、エージェントは、そのクラスターで実行されている次のワークロードのメトリクスを自動的にスクレイプし、インポートします。
+ AWS App Mesh
+ NGINX
+ Memcached
+ Java/JMX
+ HAProxy
+ Fluent Bit
また、追加の Prometheus ワークロードとソースをスクレイプしてインポートするようにエージェントを設定することもできます。
以下のステップに従って Prometheus メトリクスコレクション用の CloudWatch エージェントをインストールする前に、Amazon EKS でクラスターが実行されているか、Amazon EC2 インスタンスで Kubernetes クラスターが実行されている必要があります。
**VPC セキュリティグループの要件**
Prometheus ワークロードのセキュリティグループの受信ルールでは、Prometheus のメトリクスをプライベート IP でスクレイピングするために、CloudWatch エージェントへの Prometheus ポートを開く必要があります。
CloudWatch エージェントのセキュリティグループの出力ルールでは、CloudWatch エージェントがプライベート IP によって Prometheus ワークロードのポートに接続できるようにする必要があります。
**Topics**
+ [Amazon EKS および Kubernetes クラスターに Prometheus メトリクスコレクションを使用して CloudWatch エージェントをインストールする](#ContainerInsights-Prometheus-Setup-roles)
+ [追加の Prometheus ソースのスクレイピングと、それらのメトリクスのインポート](ContainerInsights-Prometheus-Setup-configure.md)
+ [(オプション) Prometheus メトリクスのテストのためにコンテナ化された Amazon EKS サンプルワークロードを設定する](ContainerInsights-Prometheus-Sample-Workloads.md)
## Amazon EKS および Kubernetes クラスターに Prometheus メトリクスコレクションを使用して CloudWatch エージェントをインストールする
このセクションでは、Amazon EKS または Kubernetes を実行しているクラスターで Prometheus モニターリングを使用して CloudWatch エージェントをセットアップする方法について説明します。これを行うと、エージェントは、そのクラスターで実行されている次のワークロードのメトリクスを自動的にスクレイプし、インポートします。
+ AWS App Mesh
+ NGINX
+ Memcached
+ Java/JMX
+ HAProxy
+ Fluent Bit
また、追加の Prometheus ワークロードとソースをスクレイプしてインポートするようにエージェントを設定することもできます。
以下のステップに従って Prometheus メトリクスコレクション用の CloudWatch エージェントをインストールする前に、Amazon EKS でクラスターが実行されているか、Amazon EC2 インスタンスで Kubernetes クラスターが実行されている必要があります。
**VPC セキュリティグループの要件**
Prometheus ワークロードのセキュリティグループの受信ルールでは、Prometheus のメトリクスをプライベート IP でスクレイピングするために、CloudWatch エージェントへの Prometheus ポートを開く必要があります。
CloudWatch エージェントのセキュリティグループの出力ルールでは、CloudWatch エージェントがプライベート IP によって Prometheus ワークロードのポートに接続できるようにする必要があります。
**Topics**
+ [IAM ロールの設定](#ContainerInsights-Prometheus-Setup-roles)
+ [Prometheus メトリクスを収集するための CloudWatch エージェントのインストール](#ContainerInsights-Prometheus-Setup-install-agent)
### IAM ロールの設定
最初のステップでは、クラスターで必要な IAM ロールを設定します。2 つの方法があります。
+ サービスアカウントの IAM ロール (*サービスロール*とも呼ばれます) を設定します。このメソッドは、EC2 起動タイプと Fargate 起動タイプの両方で機能します。
+ クラスターに使用される IAM ロールに IAM ポリシーを追加します。これは EC2 起動タイプでのみ機能します。
**サービスロール (EC2 起動タイプと Fargate 起動タイプ) を設定する**
サービスロールを設定するには、次のコマンドを入力します。*MyCluster* をクラスターの名前に置き換えます。
```
eksctl create iamserviceaccount \
--name cwagent-prometheus \
--namespace amazon-cloudwatch \
--cluster MyCluster \
--attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
--approve \
--override-existing-serviceaccounts
```
**ノードグループの IAM ロールにポリシーを追加する (EC2 起動タイプのみ)**
**Prometheus のサポートのためにノードグループで IAM ポリシーを設定するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**インスタンス**] を選択してください。
1. クラスターの IAM ロール名のプレフィックスを検索する必要があります。これを行うには、クラスター内のインスタンスの名前の横にあるチェックボックスをオンにし、[**アクション**]、[**セキュリティ**]、[**IAM Role を変更**] の順に選択します。次に、IAM ロールのプレフィックス (`eksctl-dev303-workshop-nodegroup` など) をコピーします。
1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。
1. ナビゲーションペインで **Roles (ロール) ** を選択してください。
1. 検索ボックスを使用して、この手順で先ほどコピーしたプレフィックスを検索し、そのロールを選択します。
1. [**ポリシーのアタッチ**] を選択します。
1. 検索ボックスを使用して、[**CloudWatchAgentServerPolicy**] を検索します。[**CloudWatchAgentServerPolicy**] の横にあるチェックボックスをオンにして、[**Attach policy (ポリシーをアタッチ)**] を選択します。
### Prometheus メトリクスを収集するための CloudWatch エージェントのインストール
メトリクスを収集するには、CloudWatch エージェントをクラスターにインストールする必要があります。エージェントのインストール方法は、Amazon EKS クラスターと Kubernetes クラスターによって異なります。
**Prometheus をサポートする以前のバージョンの CloudWatch エージェントを削除する**
Prometheus をサポートするバージョンの CloudWatch エージェントが既にクラスターにインストールされている場合は、次のコマンドを入力してそのバージョンを削除する必要があります。この操作は、Prometheus をサポートする以前のバージョンのエージェントでのみ必要です。Prometheus をサポートせずに Container Insights を有効にする CloudWatch エージェントを削除する必要はありません。
```
kubectl delete deployment cwagent-prometheus -n amazon-cloudwatch
```
#### EC2 起動タイプの Amazon EKS クラスターへの CloudWatch エージェントのインストール
Prometheus をサポートする CloudWatch エージェントを Amazon EKS クラスターにインストールするには、次の手順に従います。
**Amazon EKS クラスターに Prometheus サポートをする CloudWatch エージェントをインストールするには**
1. 次のコマンドを入力して、`amazon-cloudwatch` 名前空間がすでに作成されているかどうかを確認します。
```
kubectl get namespace
```
1. 結果に `amazon-cloudwatch` が表示されない場合は、次のコマンドを入力して作成します。
```
kubectl create namespace amazon-cloudwatch
```
1. デフォルトの設定でエージェントをデプロイし、インストール先の AWS リージョンにデータを送信するには、次のコマンドを入力します。
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-eks.yaml
```
エージェントから代わりに別のリージョンにデータを送信するには、次のステップに従います。
1. 次のコマンドを入力して、エージェントの YAML ファイルをダウンロードします。
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-eks.yaml
```
1. テキストエディタでファイルを開き、ファイルの `cwagentconfig.json` ブロックを検索します。
1. ハイライト表示された行を追加し、必要なリージョンを指定します。
```
cwagentconfig.json: |
{
"agent": {
"region": "us-east-2"
},
"logs": { ...
```
1. ファイルを保存し、更新されたファイルを使用してエージェントをデプロイします。
```
kubectl apply -f prometheus-eks.yaml
```
#### Fargate 起動タイプの Amazon EKS クラスターへの CloudWatch エージェントのインストール
Prometheus をサポートする CloudWatch エージェントを Fargate 起動タイプの Amazon EKS クラスターにインストールするには、次の手順に従います。
**Prometheus をサポートする CloudWatch エージェントを Fargate 起動タイプの Amazon EKS クラスターにインストールするには**
1. クラスター内で実行できるように、次のコマンドを入力して、CloudWatch エージェントの Fargate プロファイルを作成します。*MyCluster* をクラスターの名前に置き換えます。
```
eksctl create fargateprofile --cluster MyCluster \
--name amazon-cloudwatch \
--namespace amazon-cloudwatch
```
1. CloudWatch エージェントをインストールするには、次のコマンドを入力します。*MyCluster* をクラスターの名前に置き換えます。この名前は、エージェントによって収集されたログイベントを保存するロググループ名に使用されます。また、エージェントによって収集されたメトリクスのディメンションとしても使用されます。
*region* は、メトリクスの送信先となるリージョンの名前に置き換えます。例えば、`us-west-1`。
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-eks-fargate.yaml |
sed "s/{{cluster_name}}/MyCluster/;s/{{region_name}}/region/" |
kubectl apply -f -
```
#### Kubernetes クラスターへの CloudWatch エージェントのインストール
Kubernetes を実行しているクラスターに Prometheus をサポートする CloudWatch エージェントをインストールするには、次のコマンドを入力します。
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-k8s.yaml |
sed "s/{{cluster_name}}/MyCluster/;s/{{region_name}}/region/" |
kubectl apply -f -
```
*MyCluster* をクラスターの名前に置き換えます。この名前は、エージェントによって収集されたログイベントを保存するロググループ名に使用されます。また、エージェントによって収集されたメトリクスのディメンションとしても使用されます。
*region* は、メトリクスの送信先となる AWS リージョンの名前に置き換えます。例えば、**us-west-1**。
#### エージェントが実行されていることを確認する
Amazon EKS と Kubernetes クラスターの両方で、次のコマンドを入力して、エージェントが実行中であることを確認できます。
```
kubectl get pod -l "app=cwagent-prometheus" -n amazon-cloudwatch
```
結果に `Running` 状態の 1 つの CloudWatch エージェントポッドが含まれる場合、エージェントは実行中であり、Prometheus メトリクスを収集しています。デフォルトでは、CloudWatch エージェントは、App Mesh、NGINX、Memcached、Java/JMX、および HAProxy のメトリクスを毎分収集します。これらのメトリクスの詳細については、「[CloudWatch エージェントにより収集される Prometheus メトリクス](ContainerInsights-Prometheus-metrics.md)」を参照してください。CloudWatch で Prometheus メトリクスを表示する方法については「[Prometheus メトリクスの表示](ContainerInsights-Prometheus-viewmetrics.md)」を参照してください。
他の Prometheus エクスポーターからメトリクスを収集するよう CloudWatch エージェントを設定することもできます。詳細については、「[追加の Prometheus ソースのスクレイピングと、それらのメトリクスのインポート](ContainerInsights-Prometheus-Setup-configure.md)」を参照してください。
# 追加の Prometheus ソースのスクレイピングと、それらのメトリクスのインポート
Prometheus モニターリングを使用した CloudWatch エージェントは、Prometheus メトリクスをスクレイプするために 2 つの設定が必要です。1 つは標準の Prometheus 設定用で、Prometheus ドキュメントの「[](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config)」に記載されています。もう 1 つは CloudWatch エージェント設定用です。
Amazon EKS クラスターの場合、設定は `prometheus-eks.yaml` (EC2 起動タイプの場合) または `prometheus-eks-fargate.yaml` (Fargate 起動タイプの場合) で 2 つの設定マップとして定義されます。
+ `name: prometheus-config` セクションには、Prometheus のスクレイピング設定が含まれています。
+ `name: prometheus-cwagentconfig` セクションには、CloudWatch エージェントの設定が含まれています。このセクションを使用して、CloudWatch で Prometheus メトリクスを収集する方法を設定できます。例えば、どのメトリクスを CloudWatch にインポートするかを指定し、ディメンションを定義します。
Amazon EC2 インスタンスで実行されている Kubernetes クラスターの場合、設定は `prometheus-k8s.yaml` YAML ファイルで 2 つの設定マップとして定義されます。
+ `name: prometheus-config` セクションには、Prometheus のスクレイピング設定が含まれています。
+ `name: prometheus-cwagentconfig` セクションには、CloudWatch エージェントの設定が含まれています。
追加の Prometheus メトリクスソースをスクレイプし、それらのメトリクスを CloudWatch にインポートするには、Prometheus スクレイプ設定と CloudWatch エージェント設定の両方を変更し、更新された設定でエージェントを再デプロイします。
**VPC セキュリティグループの要件**
Prometheus ワークロードのセキュリティグループの受信ルールでは、Prometheus のメトリクスをプライベート IP でスクレイピングするために、CloudWatch エージェントへの Prometheus ポートを開く必要があります。
CloudWatch エージェントのセキュリティグループの出力ルールでは、CloudWatch エージェントがプライベート IP によって Prometheus ワークロードのポートに接続できるようにする必要があります。
## Prometheus スクレイプ設定
この CloudWatch エージェントは、Prometheus のドキュメントの「[](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config)」に記載されているように、標準の Prometheus スクレイプ設定をサポートしています。このセクションを編集して、このファイルに既に含まれている設定を更新したり、Prometheus スクレイピングターゲットを追加したりできます。デフォルトでは、サンプル設定ファイルに次のグローバル設定行が含まれています。
```
global:
scrape_interval: 1m
scrape_timeout: 10s
```
+ **scrape\$1interval** – ターゲットをスクレイプする頻度を定義します。
+ **scrape\$1timeout** – スクレイプリクエストがタイムアウトするまでの待機時間を定義します。
また、ジョブレベルでこれらの設定に対して異なる値を定義し、グローバル設定をオーバーライドすることもできます。
### Prometheus スクレイピングジョブ
CloudWatch エージェント YAML ファイルには、既にいくつかのデフォルトのスクレイピングジョブが設定されています。例えば、`prometheus-eks.yaml` では、デフォルトのスクレイピングジョブは、`job_name` セクションの `scrape_configs` 行で設定されています。このファイルで、次のデフォルト `kubernetes-pod-jmx` セクションは、JMX Exporter メトリクスをスクレイピングします。
```
- job_name: 'kubernetes-pod-jmx'
sample_limit: 10000
metrics_path: /metrics
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__address__]
action: keep
regex: '.*:9404$'
- action: labelmap
regex: __meta_kubernetes_pod_label_(.+)
- action: replace
source_labels:
- __meta_kubernetes_namespace
target_label: Namespace
- source_labels: [__meta_kubernetes_pod_name]
action: replace
target_label: pod_name
- action: replace
source_labels:
- __meta_kubernetes_pod_container_name
target_label: container_name
- action: replace
source_labels:
- __meta_kubernetes_pod_controller_name
target_label: pod_controller_name
- action: replace
source_labels:
- __meta_kubernetes_pod_controller_kind
target_label: pod_controller_kind
- action: replace
source_labels:
- __meta_kubernetes_pod_phase
target_label: pod_phase
```
これらのデフォルトターゲットはそれぞれスクレイピングされ、メトリクスは埋め込みメトリクス形式を使用してログイベントで CloudWatch に送信されます。詳細については、「[ログ内へのメトリクスの埋め込み](CloudWatch_Embedded_Metric_Format.md)」を参照してください。
Amazon EKS および Kubernetes クラスターからのログイベントは、CloudWatch Logs の [**/aws/containerinsights/*cluster\$1name*/prometheus**] ロググループに保存されます。Amazon ECS クラスターからのログイベントは、[**/aws/ecs/containerinsights/*cluster\$1name*/prometheus**] ロググループに保存されます。
各スクレイピングジョブは、このロググループ内の異なるログストリームに含まれています。例えば、Prometheus スクレイピングジョブ `kubernetes-pod-appmesh-envoy` が App Mesh に対して定義されています。Amazon EKS および Kubernetes クラスターのすべての App Mesh Prometheus メトリクスは、[**/aws/containerinsights/*cluster\$1name*>prometheus/kubernetes-pod-appmesh-envoy/**] という名前のログストリームに送信されます。
新しいスクレイピングターゲットを追加するには、YAML ファイルの `job_name` セクションに新しい `scrape_configs` セクションを追加し、エージェントを再起動します。このプロセスの例については、「[新しい Prometheus スクレイピングターゲットを追加するためのチュートリアル: Prometheus API サーバーメトリクス](#ContainerInsights-Prometheus-Setup-new-exporters)」を参照してください。
## Prometheus の CloudWatch エージェント設定
CloudWatch エージェント設定ファイルには、Prometheus スクレイピング設定の `prometheus` の `metrics_collected` セクションがあります。これには、次の設定オプションが含まれます。
+ **cluster\$1name** – ログイベントのラベルとして追加されるクラスター名を指定します。このフィールドはオプションです。これを省略すると、エージェントは Amazon EKS または Kubernetes クラスター名を検出できます。
+ **log\$1group\$1name** – スクレイプされた Prometheus メトリクスのロググループ名を指定します。このフィールドはオプションです。これを省略すると、CloudWatch では Amazon EKS および Kubernetes クラスターからのログに **/aws/containerinsights/*cluster\$1name*/prometheus** が使用されます。
+ **prometheus\$1config\$1path** – Prometheus スクレイプ設定ファイルパスを指定します。このフィールドの値が `env:` で始まる場合、Prometheus スクレイプ設定ファイルの内容は、コンテナの環境変数から取得されます。このフィールドは変更しないでください。
+ **ecs\$1service\$1discovery** – Amazon ECS Prometheus サービス検出の設定を指定するセクションです。詳細については、「[Amazon ECS クラスターでの自動検出の詳細ガイド](ContainerInsights-Prometheus-Setup-autodiscovery-ecs.md)」を参照してください。
`ecs_service_discovery` セクションには、次のフィールドを含めることができます。
+ `sd_frequency` は、Prometheus エクスポーターを検出する頻度です。数値と単位サフィックスを指定します。例えば、`1m` の場合は 1 分に 1 回、`30s` の場合は 30 秒に 1 回です。有効な単位サフィックスは、`ns`、`us`、`ms`、`s`、`m`、`h` です。
このフィールドはオプションです。デフォルト値は 60 秒 (1 分) です。
+ `sd_target_cluster` は、自動検出のターゲット Amazon ECS クラスター名です。このフィールドはオプションです。デフォルトは、CloudWatch エージェントがインストールされている Amazon ECS クラスターの名前です。
+ `sd_cluster_region` は、ターゲット Amazon ECS クラスターのリージョンです。このフィールドはオプションです。デフォルトは、CloudWatch エージェントがインストールされている Amazon ECS クラスターのリージョンです。
+ `sd_result_file` は、Prometheus ターゲット結果の YAML ファイルのパスです。Prometheus スクレイプ設定は、このファイルを参照します。
+ `docker_label` は、docker のラベルベースのサービス検出の設定を指定するために使用できるオプションのセクションです。このセクションを省略すると、docker のラベルベースの検出は使用されません。このセクションには、次のフィールドを含めることができます。
+ `sd_port_label` は、Prometheus メトリクスのコンテナポートを指定するコンテナの docker ラベル名です。デフォルト値は `ECS_PROMETHEUS_EXPORTER_PORT` です。コンテナにこの docker ラベルがない場合、CloudWatch エージェントはそれをスキップします。
+ `sd_metrics_path_label` は、Prometheus メトリクスパスを指定するコンテナの docker ラベル名です。デフォルト値は `ECS_PROMETHEUS_METRICS_PATH` です。コンテナにこの docker ラベルがない場合は、エージェントはデフォルトパス `/metrics` を想定します。
+ `sd_job_name_label` は、Prometheus スクレイプジョブ名を指定するコンテナの docker ラベル名です。デフォルト値は `job` です。コンテナにこの docker ラベルがない場合、CloudWatch エージェントは Prometheus スクレイプ設定でジョブ名を使用します。
+ `task_definition_list` は、タスク定義ベースのサービス検出の設定を指定するために使用できるオプションのセクションです。このセクションを省略すると、タスク定義ベースの検出は使用されません。このセクションには、次のフィールドを含めることができます。
+ `sd_task_definition_arn_pattern` は、検出する Amazon ECS タスク定義を指定するために使用するパターンです。これは正規表現です。
+ `sd_metrics_ports` に、Prometheus メトリクスの containerPort を示します。containerPort はセミコロンで区切ります。
+ `sd_container_name_pattern` は、Amazon ECS タスクコンテナ名を指定します。これは正規表現です。
+ `sd_metrics_path` は、Prometheus のメトリクスパスを指定します。これを省略すると、エージェントはデフォルトのパス `/metrics` を引き受けます。
+ `sd_job_name` Prometheus スクレイプジョブ名を指定します。このフィールドを省略すると、CloudWatch エージェントは Prometheus スクレイプ設定のジョブ名を使用します。
+ **metric\$1declaration** – 生成されるメトリクス形式が埋め込まれたログの配列を指定するセクションです。CloudWatch エージェントがインポートする各 Prometheus ソースには、デフォルトで `metric_declaration` セクションがあります。これらの各セクションには、次のフィールドが含まれています。
+ `label_matcher` は、 `source_labels` に表示されているラベルの値をチェックする正規表現です。一致するメトリクスは、CloudWatch に送信される埋め込みメトリクス形式に含めることができます。
`source_labels` で複数のラベルを指定する場合は、`^` の正規表現に `$` や `label_matcher` 文字を使用しないことをお勧めします。
+ `source_labels` は、`label_matcher` 行によってチェックされるラベルの値を指定します。
+ `label_separator` は、複数の ` label_matcher` が指定されている場合に、`source_labels` 行で使用するセパレータを指定します。デフォルト: `;`。このデフォルトは、次の例の `label_matcher` 行で使用されています。
+ `metric_selectors` は、収集され、CloudWatch に送信されるメトリクスを指定する正規表現です。
+ `dimensions` は、選択した各メトリクスの CloudWatch ディメンションとして使用されるラベルのリストです。
次の `metric_declaration` の例を参照してください。
```
"metric_declaration": [
{
"source_labels":[ "Service", "Namespace"],
"label_matcher":"(.*node-exporter.*|.*kube-dns.*);kube-system",
"dimensions":[
["Service", "Namespace"]
],
"metric_selectors":[
"^coredns_dns_request_type_count_total$"
]
}
]
```
この例では、次の条件が満たされた場合にログイベントとして送信される埋め込みメトリクス形式セクションを設定します。
+ `Service` の値には `node-exporter` または `kube-dns` が含まれます。
+ `Namespace` の値は `kube-system` です。
+ Prometheus メトリクス `coredns_dns_request_type_count_total` には、`Service` ラベルおよび `Namespace` ラベルの両方が含まれます。
送信されるログイベントには、次の強調表示されたセクションが含まれます。
```
{
"CloudWatchMetrics":[
{
"Metrics":[
{
"Name":"coredns_dns_request_type_count_total"
}
],
"Dimensions":[
[
"Namespace",
"Service"
]
],
"Namespace":"ContainerInsights/Prometheus"
}
],
"Namespace":"kube-system",
"Service":"kube-dns",
"coredns_dns_request_type_count_total":2562,
"eks_amazonaws_com_component":"kube-dns",
"instance":"192.168.61.254:9153",
"job":"kubernetes-service-endpoints",
...
}
```
## 新しい Prometheus スクレイピングターゲットを追加するためのチュートリアル: Prometheus API サーバーメトリクス
Kubernetes API サーバーは、デフォルトでエンドポイントで Prometheus メトリクスを公開します。Kubernetes API サーバーのスクレイピング設定に関する公式のサンプルは、[GitHub](https://github.com/prometheus/prometheus/blob/main/documentation/examples/prometheus-kubernetes.yml) で入手できます。
次のチュートリアルでは、次のステップを実行して Kubernetes API サーバーメトリクスを CloudWatch にインポートする方法を示します。
+ CloudWatch エージェントの YAML ファイルに、Kubernetes API サーバーの Prometheus スクレイピング設定を追加します。
+ CloudWatch エージェントの YAML ファイルに埋め込まれたメトリクス形式のメトリクス定義を設定します。
+ (オプション) Kubernetes API サーバーメトリクスの CloudWatch ダッシュボードを作成します。
**注記**
Kubernetes API サーバーは、ゲージ、カウンター、ヒストグラム、およびサマリーメトリクスを公開します。このリリースの Prometheus メトリクスサポートでは、CloudWatch はゲージ、カウンター、およびサマリータイプのメトリクスのみをインポートします。
**CloudWatch で Kubernetes API サーバー Prometheus メトリクスの収集を開始するには**
1. 次のコマンドのいずれかを入力して、最新バージョンの `prometheus-eks.yaml`、`prometheus-eks-fargate.yaml`、または `prometheus-k8s.yaml` ファイルをダウンロードします。
EC2 起動タイプの Amazon EKS クラスターの場合は、次のコマンドを入力します。
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-eks.yaml
```
Fargate 起動タイプの Amazon EKS クラスターの場合は、次のコマンドを入力します。
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-eks-fargate.yaml
```
Amazon EC2 インスタンスで実行されている Kubernetes クラスターの場合は、次のコマンドを入力します。
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-k8s.yaml
```
1. テキストエディタでファイルを開き、`prometheus-config` セクションを見つけ、そのセクション内に次のセクションを追加します。次に、変更を保存します。
```
# Scrape config for API servers
- job_name: 'kubernetes-apiservers'
kubernetes_sd_configs:
- role: endpoints
namespaces:
names:
- default
scheme: https
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
insecure_skip_verify: true
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
relabel_configs:
- source_labels: [__meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
action: keep
regex: kubernetes;https
- action: replace
source_labels:
- __meta_kubernetes_namespace
target_label: Namespace
- action: replace
source_labels:
- __meta_kubernetes_service_name
target_label: Service
```
1. テキストエディタで YAML ファイルを開いている間に、`cwagentconfig.json` セクションを見つけます。次のサブセクションを追加し、変更を保存します。このセクションでは、API サーバーメトリクスを CloudWatch エージェント許可リストに追加します。次の 3 種類の API サーバーメトリクスを許可リストに追加します。
+ etcd オブジェクト数
+ API サーバー登録コントローラーメトリクス
+ API サーバー要求メトリクス
```
{"source_labels": ["job", "resource"],
"label_matcher": "^kubernetes-apiservers;(services|daemonsets.apps|deployments.apps|configmaps|endpoints|secrets|serviceaccounts|replicasets.apps)",
"dimensions": [["ClusterName","Service","resource"]],
"metric_selectors": [
"^etcd_object_counts$"
]
},
{"source_labels": ["job", "name"],
"label_matcher": "^kubernetes-apiservers;APIServiceRegistrationController$",
"dimensions": [["ClusterName","Service","name"]],
"metric_selectors": [
"^workqueue_depth$",
"^workqueue_adds_total$",
"^workqueue_retries_total$"
]
},
{"source_labels": ["job","code"],
"label_matcher": "^kubernetes-apiservers;2[0-9]{2}$",
"dimensions": [["ClusterName","Service","code"]],
"metric_selectors": [
"^apiserver_request_total$"
]
},
{"source_labels": ["job"],
"label_matcher": "^kubernetes-apiservers",
"dimensions": [["ClusterName","Service"]],
"metric_selectors": [
"^apiserver_request_total$"
]
},
```
1. Prometheus をサポートする CloudWatch エージェントが既にクラスタにデプロイされている場合は、次のコマンドを入力してエージェントを削除する必要があります。
```
kubectl delete deployment cwagent-prometheus -n amazon-cloudwatch
```
1. 次のいずれかのコマンドを入力して、更新した設定で CloudWatch エージェントをデプロイします。EC2 起動タイプの Amazon EKS クラスターの場合は、次を入力します:
```
kubectl apply -f prometheus-eks.yaml
```
Fargate 起動タイプの Amazon EKS クラスターの場合は、次のコマンドを入力します。*MyCluster* および *region* を、デプロイに合った値に置き換えます。
```
cat prometheus-eks-fargate.yaml \
| sed "s/{{cluster_name}}/MyCluster/;s/{{region_name}}/region/" \
| kubectl apply -f -
```
Kubernetes クラスターの場合は、次のコマンドを入力します。*MyCluster* および *region* を、デプロイに合った値に置き換えます。
```
cat prometheus-k8s.yaml \
| sed "s/{{cluster_name}}/MyCluster/;s/{{region_name}}/region/" \
| kubectl apply -f -
```
これを行うと、[**/aws/containerinsights/*cluster\$1name*/prometheus**] ロググループに [**kubernetes-apiservers**] という名前の新しいログストリームが表示されます。このログストリームには、次のような埋め込みメトリクス形式の定義を持つログイベントを含める必要があります。
```
{
"CloudWatchMetrics":[
{
"Metrics":[
{
"Name":"apiserver_request_total"
}
],
"Dimensions":[
[
"ClusterName",
"Service"
]
],
"Namespace":"ContainerInsights/Prometheus"
}
],
"ClusterName":"my-cluster-name",
"Namespace":"default",
"Service":"kubernetes",
"Timestamp":"1592267020339",
"Version":"0",
"apiserver_request_count":0,
"apiserver_request_total":0,
"code":"0",
"component":"apiserver",
"contentType":"application/json",
"instance":"192.0.2.0:443",
"job":"kubernetes-apiservers",
"prom_metric_type":"counter",
"resource":"pods",
"scope":"namespace",
"verb":"WATCH",
"version":"v1"
}
```
CloudWatch コンソールで [**ContainerInsights/Prometheus**] 名前空間のメトリクスを表示できます。オプションで、Prometheus Kubernetes API サーバーメトリクスの CloudWatch ダッシュボードを作成することもできます。
### (オプション) Kubernetes API サーバーメトリクスのダッシュボードの作成
ダッシュボードに Kubernetes API サーバーメトリクスを表示するには、前のセクションのステップをまず完了して、CloudWatch でこれらのメトリクスの収集を開始する必要があります。
**Kubernetes API サーバーメトリクスのダッシュボードを作成するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. 正しい AWS リージョンが選択されていることを確認します。
1. ナビゲーションペインで、**ダッシュボード**を選択します。
1. [**ダッシュボードの作成**] を選択します。新しいダッシュボードの名前を入力し、[**ダッシュボードの作成**] を選択します。
1. [**このダッシュボードに追加**] で、[**キャンセル**] を選択します。
1. [**アクション**]、[**ソースの表示/編集**] を選択します。
1. JSON ファイル [Kubernetes API ダッシュボードソース](https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_cloudwatch_dashboards/kubernetes_api_server/cw_dashboard_kubernetes_api_server.json)をダウンロードします。
1. ダウンロードした JSON ファイルをテキストエディタで開き、次の変更を加えます。
+ すべての `{{YOUR_CLUSTER_NAME}}` 文字列をクラスターの正確な名前に置き換えます。テキストの前後に空白を追加しないようにしてください。
+ すべての `{{YOUR_AWS_REGION}}` 文字列を、メトリクスを収集するリージョンの名前に置き換えます。例: `us-west-2`。テキストの前後に空白を追加しないようにしてください。
1. JSON BLOB 全体をコピーし、CloudWatch コンソールのテキストボックスに貼り付けて、ボックスに既に入力されている内容を置き換えます。
1. [**更新**]、[**ダッシュボードの保存**] の順に選択します。
# (オプション) Prometheus メトリクスのテストのためにコンテナ化された Amazon EKS サンプルワークロードを設定する
CloudWatch Container Insights で Prometheus メトリクスのサポートをテストするには、次のコンテナ化されたワークロードを 1 つ以上設定できます。Prometheus をサポートする CloudWatch エージェントは、これらの各ワークロードからメトリクスを自動的に収集します。デフォルトで収集されるメトリクスを表示する方法については、「[CloudWatch エージェントにより収集される Prometheus メトリクス](ContainerInsights-Prometheus-metrics.md)」を参照してください。
これらのワークロードをインストールする前に、次のコマンドを入力して Helm 3.x をインストールする必要があります。
```
brew install helm
```
詳細については、「[Helm](https://helm.sh)」を参照してください。
**Topics**
+ [Amazon EKS および Kubernetes の AWS App Mesh サンプルワークロードを設定する](ContainerInsights-Prometheus-Sample-Workloads-appmesh.md)
+ [サンプルトラフィックを使用して、Amazon EKS および Kubernetes で NGINX をセットアップする](ContainerInsights-Prometheus-Sample-Workloads-nginx.md)
+ [メトリクスエクスポーターを使用して、Amazon EKS および Kubernetes で memcached をセットアップする](ContainerInsights-Prometheus-Sample-Workloads-memcached.md)
+ [Amazon EKS および Kubernetes で Java/JMX サンプルワークロードをセットアップする](ContainerInsights-Prometheus-Sample-Workloads-javajmx.md)
+ [メトリクスエクスポーターを使用して、Amazon EKS および Kubernetes で HAProxy をセットアップする](ContainerInsights-Prometheus-Sample-Workloads-haproxy.md)
+ [Prometheus スクレイピングの新しいターゲットの追加に関するチュートリアル: Amazon EKS クラスターと Kubernetes クラスター上の Redis OSS](ContainerInsights-Prometheus-Setup-redis-eks.md)
# Amazon EKS および Kubernetes の AWS App Mesh サンプルワークロードを設定する
CloudWatch Container Insights での Prometheus サポートでは、 がサポートされていますAWS App Mesh 次のセクションでは、App Mesh の設定方法について説明します。
**Topics**
+ [EC2 起動タイプの Amazon EKS クラスターまたは Kubernetes クラスターで AWS App Mesh サンプルワークロードを設定する](ContainerInsights-Prometheus-Sample-Workloads-appmesh-EKS.md)
+ [Fargate 起動タイプの Amazon EKS クラスターで AWS App Mesh サンプルワークロードを設定する](ContainerInsights-Prometheus-Sample-Workloads-appmesh-Fargate.md)
# EC2 起動タイプの Amazon EKS クラスターまたは Kubernetes クラスターで AWS App Mesh サンプルワークロードを設定する
EC2 起動タイプの Amazon EKS を実行しているクラスターまたは Kubernetes クラスターで App Mesh を設定する場合は、以下の手順を使用します。
## IAM 許可を設定する
Amazon EKS または Kubernetes ノードグループの IAM ロールに **AWSAppMeshFullAccess** ポリシーを追加する必要があります。Amazon EKS の場合、このノードグループ名は `eksctl-integ-test-eks-prometheus-NodeInstanceRole-ABCDEFHIJKL` のようになります。Kubernetes の場合は、`nodes.integ-test-kops-prometheus.k8s.local` のようになることもあります。
## App Mesh のインストール
App Mesh Kubernetes コントローラーをインストールするには、「[App Mesh コントローラー](https://github.com/aws/eks-charts/tree/master/stable/appmesh-controller#app-mesh-controller)」の手順に従います。
## サンプルアプリケーションをインストールする
「[aws-app-mesh-examples](https://github.com/aws/aws-app-mesh-examples)」には、複数の Kubernetes App Mesh チュートリアルが含まれています。このチュートリアルでは、http ルートがヘッダーを使用して着信リクエストを照合する方法を示すサンプルカラーアプリケーションをインストールします。
**App Mesh サンプルアプリケーションを使用して Container Insights をテストするには**
1. 「[https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-k8s-http-headers](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-k8s-http-headers)」の手順に従ってアプリケーションをインストールします。
1. curler ポッドを起動してトラフィックを生成します。
```
kubectl -n default run -it curler --image=tutum/curl /bin/bash
```
1. HTTP ヘッダーを変更し、異なるエンドポイントに対して curl を使用します。次のように curl コマンドを複数回実行します。
```
curl -H "color_header: blue" front.howto-k8s-http-headers.svc.cluster.local:8080/; echo;
curl -H "color_header: red" front.howto-k8s-http-headers.svc.cluster.local:8080/; echo;
curl -H "color_header: yellow" front.howto-k8s-http-headers.svc.cluster.local:8080/; echo;
```
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. クラスターが実行されている AWS リージョンで、ナビゲーションペインから [**Metrics**] (メトリクス) を選択します。このメトリクスは、[**ContainerInsights/Prometheus**] 名前空間にあります。
1. CloudWatch Logs イベントを表示するには、ナビゲーションペインで [**Log Groups (ロググループ)**] を選択します。イベントは、ログストリーム ` /aws/containerinsights/your_cluster_name/prometheus ` のロググループ `kubernetes-pod-appmesh-envoy` にあります 。
## App Mesh テスト環境の削除
App Mesh とサンプルアプリケーションの使用が終了したら、次のコマンドを使用して不要なリソースを削除します。サンプルアプリケーションを削除するには、次のコマンドを入力します。
```
cd aws-app-mesh-examples/walkthroughs/howto-k8s-http-headers/
kubectl delete -f _output/manifest.yaml
```
App Mesh コントローラーを削除するには、次のコマンドを入力します。
```
helm delete appmesh-controller -n appmesh-system
```
# Fargate 起動タイプの Amazon EKS クラスターで AWS App Mesh サンプルワークロードを設定する
Fargate 起動タイプの Amazon EKS を実行しているクラスターで App Mesh を設定する場合は、以下の手順を使用します。
## IAM 許可を設定する
IAM アクセス許可を設定するには、次のコマンドを入力します。*MyCluster* をクラスターの名前に置き換えます。
```
eksctl create iamserviceaccount --cluster MyCluster \
--namespace howto-k8s-fargate \
--name appmesh-pod \
--attach-policy-arn arn:aws:iam::aws:policy/AWSAppMeshEnvoyAccess \
--attach-policy-arn arn:aws:iam::aws:policy/AWSCloudMapDiscoverInstanceAccess \
--attach-policy-arn arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess \
--attach-policy-arn arn:aws:iam::aws:policy/CloudWatchLogsFullAccess \
--attach-policy-arn arn:aws:iam::aws:policy/AWSAppMeshFullAccess \
--attach-policy-arn arn:aws:iam::aws:policy/AWSCloudMapFullAccess \
--override-existing-serviceaccounts \
--approve
```
## App Mesh のインストール
App Mesh Kubernetes コントローラーをインストールするには、「[App Mesh コントローラー](https://github.com/aws/eks-charts/tree/master/stable/appmesh-controller#app-mesh-controller)」の手順に従います。Fargate 起動タイプの Amazon EKS の指示に従ってください。
## サンプルアプリケーションをインストールする
「[aws-app-mesh-examples](https://github.com/aws/aws-app-mesh-examples)」には、複数の Kubernetes App Mesh チュートリアルが含まれています。このチュートリアルでは、Fargate 起動タイプの Amazon EKS クラスターで動作するサンプルカラーアプリケーションをインストールします。
**App Mesh サンプルアプリケーションを使用して Container Insights をテストするには**
1. 「[https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-k8s-fargate](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-k8s-fargate)」の手順に従ってアプリケーションをインストールします。
これらの手順では、正しい Fargate プロファイルを使用して新しいクラスターを作成することを前提としています。既に設定済みの Amazon EKS クラスターを使用する場合は、次のコマンドを使用して、このデモンストレーション用にそのクラスターを設定できます。*MyCluster* をクラスターの名前に置き換えます。
```
eksctl create iamserviceaccount --cluster MyCluster \
--namespace howto-k8s-fargate \
--name appmesh-pod \
--attach-policy-arn arn:aws:iam::aws:policy/AWSAppMeshEnvoyAccess \
--attach-policy-arn arn:aws:iam::aws:policy/AWSCloudMapDiscoverInstanceAccess \
--attach-policy-arn arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess \
--attach-policy-arn arn:aws:iam::aws:policy/CloudWatchLogsFullAccess \
--attach-policy-arn arn:aws:iam::aws:policy/AWSAppMeshFullAccess \
--attach-policy-arn arn:aws:iam::aws:policy/AWSCloudMapFullAccess \
--override-existing-serviceaccounts \
--approve
```
```
eksctl create fargateprofile --cluster MyCluster \
--namespace howto-k8s-fargate --name howto-k8s-fargate
```
1. フロントアプリケーションのデプロイをポート転送します。
```
kubectl -n howto-k8s-fargate port-forward deployment/front 8080:8080
```
1. フロントアプリをカールする:
```
while true; do curl -s http://localhost:8080/color; sleep 0.1; echo ; done
```
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. クラスターが実行されている AWS リージョンで、ナビゲーションペインから [**Metrics**] (メトリクス) を選択します。このメトリクスは、[**ContainerInsights/Prometheus**] 名前空間にあります。
1. CloudWatch Logs イベントを表示するには、ナビゲーションペインで [**Log Groups (ロググループ)**] を選択します。イベントは、ログストリーム ` /aws/containerinsights/your_cluster_name/prometheus ` のロググループ `kubernetes-pod-appmesh-envoy` にあります 。
## App Mesh テスト環境の削除
App Mesh とサンプルアプリケーションの使用が終了したら、次のコマンドを使用して不要なリソースを削除します。サンプルアプリケーションを削除するには、次のコマンドを入力します。
```
cd aws-app-mesh-examples/walkthroughs/howto-k8s-fargate/
kubectl delete -f _output/manifest.yaml
```
App Mesh コントローラーを削除するには、次のコマンドを入力します。
```
helm delete appmesh-controller -n appmesh-system
```
# サンプルトラフィックを使用して、Amazon EKS および Kubernetes で NGINX をセットアップする
NGINX は、ロードバランサーやリバースプロキシとしても使用できるウェブサーバーです。Kubernetes が入力に NGINX を使用する方法については、「[kubernetes/ingress-nginx](https://github.com/kubernetes/ingress-nginx)」を参照してください。
**Container Insights の Prometheus サポートをテストするために、サンプルトラフィックサービス ingress-nginx をインストールするには**
1. 次のコマンドを入力して、Helm ingress-nginx リポジトリを追加します。
```
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
```
1. 以下のコマンドを入力します。
```
kubectl create namespace nginx-ingress-sample
helm install my-nginx ingress-nginx/ingress-nginx \
--namespace nginx-ingress-sample \
--set controller.metrics.enabled=true \
--set-string controller.metrics.service.annotations."prometheus\.io/port"="10254" \
--set-string controller.metrics.service.annotations."prometheus\.io/scrape"="true"
```
1. 次のコマンドを入力して、サービスが正常に開始されたかどうかを確認します。
```
kubectl get service -n nginx-ingress-sample
```
このコマンドの出力には、`EXTERNAL-IP` 列を含む複数の列が表示されます。
1. NGINX 入力コントローラーの行の `EXTERNAL-IP` 列の値に `EXTERNAL-IP` 変数を設定します。
```
EXTERNAL_IP=your-nginx-controller-external-ip
```
1. 次のコマンドを入力して、サンプル NGINX トラフィックを開始します。
```
SAMPLE_TRAFFIC_NAMESPACE=nginx-sample-traffic
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_traffic/nginx-traffic/nginx-traffic-sample.yaml |
sed "s/{{external_ip}}/$EXTERNAL_IP/g" |
sed "s/{{namespace}}/$SAMPLE_TRAFFIC_NAMESPACE/g" |
kubectl apply -f -
```
1. 次のコマンドを入力して、3 つのポッドがすべて `Running` ステータスであることを確認します。
```
kubectl get pod -n $SAMPLE_TRAFFIC_NAMESPACE
```
ポッドが実行中の場合は、**ContainerInsights/Prometheus** 名前空間にメトリクスが表示されます。
**NGINX とサンプルトラフィックアプリケーションをアンインストールするには**
1. 次のコマンドを入力して、サンプルトラフィックサービスを削除します。
```
kubectl delete namespace $SAMPLE_TRAFFIC_NAMESPACE
```
1. Helm リリース名で NGINX egress を削除します。
```
helm uninstall my-nginx --namespace nginx-ingress-sample
kubectl delete namespace nginx-ingress-sample
```
# メトリクスエクスポーターを使用して、Amazon EKS および Kubernetes で memcached をセットアップする
memcached は、オープンソースのメモリオブジェクトキャッシュシステムです。詳細については、「[Memcached とは](https://www.memcached.org)」を参照してください。
Fargate 起動タイプのクラスターで memcached を実行している場合は、この手順の各ステップを実行する前に Fargate プロファイルを設定する必要があります。プロファイルを設定するには、次のコマンドを入力します。*MyCluster* をクラスターの名前に置き換えます。
```
eksctl create fargateprofile --cluster MyCluster \
--namespace memcached-sample --name memcached-sample
```
**メトリクスエクスポーターとともに memcached をインストールして、Container Insights の Prometheus サポートをテストするには**
1. 次のコマンドを入力して、リポジトリを追加します。
```
helm repo add bitnami https://charts.bitnami.com/bitnami
```
1. 以下のコマンドを入力して、新しい名前空間を作成します。
```
kubectl create namespace memcached-sample
```
1. 次のコマンドを入力して、Memcached をインストールします。
```
helm install my-memcached bitnami/memcached --namespace memcached-sample \
--set metrics.enabled=true \
--set-string serviceAnnotations.prometheus\\.io/port="9150" \
--set-string serviceAnnotations.prometheus\\.io/scrape="true"
```
1. 次のコマンドを入力して、実行中のサービスの注釈を確認します。
```
kubectl describe service my-memcached-metrics -n memcached-sample
```
次の 2 つの注釈が表示されます。
```
Annotations: prometheus.io/port: 9150
prometheus.io/scrape: true
```
**memcached をアンインストールするには**
+ 以下のコマンドを入力します。
```
helm uninstall my-memcached --namespace memcached-sample
kubectl delete namespace memcached-sample
```
# Amazon EKS および Kubernetes で Java/JMX サンプルワークロードをセットアップする
JMX Exporter は、Prometheus メトリクスとして JMX mBeans をスクレイプおよび公開できる公式の Prometheus エクスポーターです。詳細については、[prometheus/jmx\$1exporter](https://github.com/prometheus/jmx_exporter) を参照してください。
Container Insights は、JMX Exporter を使用して、Java 仮想マシン (JVM)、Java、および Tomcat (Catalina) から定義済みの Prometheus メトリクスを収集できます。
## デフォルトの Prometheus スクレイピング設定
デフォルトでは、Prometheus をサポートする CloudWatch エージェントは、Amazon EKS または Kubernetes クラスター内の各ポッドの `http://CLUSTER_IP:9404/metrics` から Java/JMX Prometheus メトリクスをスクレイプします。これは、Prometheus `kubernetes_sd_config` の `role: pod` 検出によって行われます。9404 は、Prometheus によって JMX Exporter に割り当てられたデフォルトのポートです。`role: pod` 検出の詳細については、「[ポッド](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#pod)」を参照してください。別のポートまたは metrics\$1path でメトリクスを公開するように JMX Exporter を設定できます。ポートまたはパスを変更する場合は、CloudWatch エージェント設定マップのデフォルトの jmx scrape\$1config を更新します。次のコマンドを実行して、現在の CloudWatch エージェント Prometheus 設定を取得します。
```
kubectl describe cm prometheus-config -n amazon-cloudwatch
```
変更するフィールドは、次の例で強調表示されているように、`/metrics` および `regex: '.*:9404$'` フィールドです。
```
job_name: 'kubernetes-jmx-pod'
sample_limit: 10000
metrics_path: /metrics
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__address__]
action: keep
regex: '.*:9404$'
- action: replace
regex: (.+)
source_labels:
```
## その他の Prometheus スクレイピング設定
Kubernetes サービスによって、Java/JMX Prometheus エクスポーターを使用して一連の Pod で実行されているアプリケーションを公開する場合、Prometheus `role: service` の `role: endpoint` 検出または `kubernetes_sd_config` を使用するように切り替えることもできます。これらの検出方法の詳細については、「[ サービス](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#service)」、「[ エンドポイント](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#endpoints)」および「[](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config)」を参照してください。
これら 2 つのサービス検出モードによって、より多くのメタラベルが提供されるため、CloudWatch メトリクスディメンションを構築するのに便利です。たとえば、`__meta_kubernetes_service_name` ラベルを `Service` ラベルに書き換えてメトリクスのディメンションに含めることができます。CloudWatch メトリクスとそのディメンションのカスタマイズの詳細については、「[Prometheus の CloudWatch エージェント設定](ContainerInsights-Prometheus-Setup-configure-ECS.md#ContainerInsights-Prometheus-Setup-cw-agent-config)」を参照してください。
## JMX Exporter を使用した Docker イメージ
次に、Docker イメージを構築します。次のセクションでは、Dockerfile の例を 2 つ示します。
イメージを構築したら、Amazon EKS または Kubernetes にロードし、次のコマンドを実行して Prometheus メトリクスがポート 9404 で `JMX_EXPORTER` によって公開されていることを確認します。*\$1JAR\$1SAMPLE\$1TRAFFIC\$1POD* を実行中のポッド名に置き換え、*\$1JAR\$1SAMPLE\$1TRAFFIC\$1NAMESPACE* をアプリケーション名前空間に置き換えます。
Fargate 起動タイプのクラスターで JMX Exporter を実行している場合は、この手順の各ステップを実行する前に Fargate プロファイルも設定する必要があります。プロファイルを設定するには、次のコマンドを入力します。*MyCluster* をクラスターの名前に置き換えます。
```
eksctl create fargateprofile --cluster MyCluster \
--namespace $JAR_SAMPLE_TRAFFIC_NAMESPACE\
--name $JAR_SAMPLE_TRAFFIC_NAMESPACE
```
```
kubectl exec $JAR_SAMPLE_TRAFFIC_POD -n $JARCAT_SAMPLE_TRAFFIC_NAMESPACE -- curl http://localhost:9404
```
## 例: Prometheus メトリクスを使用した Apache Tomcat Docker イメージ
Apache Tomcat サーバーは、デフォルトで JMX mBeans を公開します。JMX Exporter と Tomcat を統合して、JMX mBeans を Prometheus メトリクスとして公開できます。次の例の Dockerfile は、テスト用イメージを構築するステップを示しています。
```
# From Tomcat 9.0 JDK8 OpenJDK
FROM tomcat:9.0-jdk8-openjdk
RUN mkdir -p /opt/jmx_exporter
COPY ./jmx_prometheus_javaagent-0.12.0.jar /opt/jmx_exporter
COPY ./config.yaml /opt/jmx_exporter
COPY ./setenv.sh /usr/local/tomcat/bin
COPY your web application.war /usr/local/tomcat/webapps/
RUN chmod o+x /usr/local/tomcat/bin/setenv.sh
ENTRYPOINT ["catalina.sh", "run"]
```
次のリストでは、この Dockerfile の 4 つの `COPY` 行について説明します。
+ [https://github.com/prometheus/jmx\$1exporter](https://github.com/prometheus/jmx_exporter) から最新の JMX Exporter jar ファイルをダウンロードします。
+ `config.yaml` は JMX Exporter 設定ファイルです。詳細については、[https://github.com/prometheus/jmx\$1exporter\$1Configuration](https://github.com/prometheus/jmx_exporter#Configuration ) を参照してください。
Java と Tomcat の設定ファイルのサンプルを次に示します。
```
lowercaseOutputName: true
lowercaseOutputLabelNames: true
rules:
- pattern: 'java.lang<>(FreePhysicalMemorySize|TotalPhysicalMemorySize|FreeSwapSpaceSize|TotalSwapSpaceSize|SystemCpuLoad|ProcessCpuLoad|OpenFileDescriptorCount|AvailableProcessors)'
name: java_lang_OperatingSystem_$1
type: GAUGE
- pattern: 'java.lang<>(TotalStartedThreadCount|ThreadCount)'
name: java_lang_threading_$1
type: GAUGE
- pattern: 'Catalina<>(\w+)'
name: catalina_globalrequestprocessor_$3_total
labels:
port: "$2"
protocol: "$1"
help: Catalina global $3
type: COUNTER
- pattern: 'Catalina<>(requestCount|maxTime|processingTime|errorCount)'
name: catalina_servlet_$3_total
labels:
module: "$1"
servlet: "$2"
help: Catalina servlet $3 total
type: COUNTER
- pattern: 'Catalina<>(currentThreadCount|currentThreadsBusy|keepAliveCount|pollerThreadCount|connectionCount)'
name: catalina_threadpool_$3
labels:
port: "$2"
protocol: "$1"
help: Catalina threadpool $3
type: GAUGE
- pattern: 'Catalina<>(processingTime|sessionCounter|rejectedSessions|expiredSessions)'
name: catalina_session_$3_total
labels:
context: "$2"
host: "$1"
help: Catalina session $3 total
type: COUNTER
- pattern: ".*"
```
+ `setenv.sh` は、Tomcat とともに JMX Exporter を起動し、ローカルホストのポート 9404 で Prometheus メトリクスを公開する Tomcat 起動スクリプトです。また、`config.yaml` ファイルパスを JMX Exporter に提供します。
```
$ cat setenv.sh
export JAVA_OPTS="-javaagent:/opt/jmx_exporter/jmx_prometheus_javaagent-0.12.0.jar=9404:/opt/jmx_exporter/config.yaml $JAVA_OPTS"
```
+ ウェブアプリケーション.war は、Tomcat によってロードされるウェブアプリケーション `war` ファイルです。
この設定で Docker イメージを構築し、イメージリポジトリにアップロードします。
## 例: Prometheus メトリクスを使用した Java Jar アプリケーション Docker イメージ
次の例の Dockerfile は、テスト用イメージを構築するステップを示しています。
```
# Alpine Linux with OpenJDK JRE
FROM openjdk:8-jre-alpine
RUN mkdir -p /opt/jmx_exporter
COPY ./jmx_prometheus_javaagent-0.12.0.jar /opt/jmx_exporter
COPY ./SampleJavaApplication-1.0-SNAPSHOT.jar /opt/jmx_exporter
COPY ./start_exporter_example.sh /opt/jmx_exporter
COPY ./config.yaml /opt/jmx_exporter
RUN chmod -R o+x /opt/jmx_exporter
RUN apk add curl
ENTRYPOINT exec /opt/jmx_exporter/start_exporter_example.sh
```
次のリストでは、この Dockerfile の 4 つの `COPY` 行について説明します。
+ [https://github.com/prometheus/jmx\$1exporter](https://github.com/prometheus/jmx_exporter) から最新の JMX Exporter jar ファイルをダウンロードします。
+ `config.yaml` は JMX Exporter 設定ファイルです。詳細については、[https://github.com/prometheus/jmx\$1exporter\$1Configuration](https://github.com/prometheus/jmx_exporter#Configuration ) を参照してください。
Java と Tomcat の設定ファイルのサンプルを次に示します。
```
lowercaseOutputName: true
lowercaseOutputLabelNames: true
rules:
- pattern: 'java.lang<>(FreePhysicalMemorySize|TotalPhysicalMemorySize|FreeSwapSpaceSize|TotalSwapSpaceSize|SystemCpuLoad|ProcessCpuLoad|OpenFileDescriptorCount|AvailableProcessors)'
name: java_lang_OperatingSystem_$1
type: GAUGE
- pattern: 'java.lang<>(TotalStartedThreadCount|ThreadCount)'
name: java_lang_threading_$1
type: GAUGE
- pattern: 'Catalina<>(\w+)'
name: catalina_globalrequestprocessor_$3_total
labels:
port: "$2"
protocol: "$1"
help: Catalina global $3
type: COUNTER
- pattern: 'Catalina<>(requestCount|maxTime|processingTime|errorCount)'
name: catalina_servlet_$3_total
labels:
module: "$1"
servlet: "$2"
help: Catalina servlet $3 total
type: COUNTER
- pattern: 'Catalina<>(currentThreadCount|currentThreadsBusy|keepAliveCount|pollerThreadCount|connectionCount)'
name: catalina_threadpool_$3
labels:
port: "$2"
protocol: "$1"
help: Catalina threadpool $3
type: GAUGE
- pattern: 'Catalina<>(processingTime|sessionCounter|rejectedSessions|expiredSessions)'
name: catalina_session_$3_total
labels:
context: "$2"
host: "$1"
help: Catalina session $3 total
type: COUNTER
- pattern: ".*"
```
+ `start_exporter_example.sh` は、エクスポートされた Prometheus メトリクスを使用して JAR アプリケーションを起動するスクリプトです。また、`config.yaml` ファイルパスを JMX Exporter に提供します。
```
$ cat start_exporter_example.sh
java -javaagent:/opt/jmx_exporter/jmx_prometheus_javaagent-0.12.0.jar=9404:/opt/jmx_exporter/config.yaml -cp /opt/jmx_exporter/SampleJavaApplication-1.0-SNAPSHOT.jar com.gubupt.sample.app.App
```
+ SampleJavaApplication-1.0-SNAPSHOT.jar は、Java アプリケーションのサンプル jar ファイルです。このファイルを、モニターリングする Java アプリケーションに置き換えます。
この設定で Docker イメージを構築し、イメージリポジトリにアップロードします。
# メトリクスエクスポーターを使用して、Amazon EKS および Kubernetes で HAProxy をセットアップする
HAProxy は、オープンソースのプロキシアプリケーションです。詳細については、「[HAProxy](https://www.haproxy.org)」を参照してください。
Fargate 起動タイプのクラスターで HAProxy を実行している場合は、この手順の各ステップを実行する前に Fargate プロファイルを設定する必要があります。プロファイルを設定するには、次のコマンドを入力します。*MyCluster* をクラスターの名前に置き換えます。
```
eksctl create fargateprofile --cluster MyCluster \
--namespace haproxy-ingress-sample --name haproxy-ingress-sample
```
**メトリクスエクスポーターとともに HAProxy をインストールして、Container Insights の Prometheus サポートをテストするには**
1. 次のコマンドを入力して、Helm インキュベーターレポジトリを追加します。
```
helm repo add haproxy-ingress https://haproxy-ingress.github.io/charts
```
1. 以下のコマンドを入力して、新しい名前空間を作成します。
```
kubectl create namespace haproxy-ingress-sample
```
1. 次のコマンドを入力して、HAProxy をインストールします。
```
helm install haproxy haproxy-ingress/haproxy-ingress \
--namespace haproxy-ingress-sample \
--set defaultBackend.enabled=true \
--set controller.stats.enabled=true \
--set controller.metrics.enabled=true \
--set-string controller.metrics.service.annotations."prometheus\.io/port"="9101" \
--set-string controller.metrics.service.annotations."prometheus\.io/scrape"="true"
```
1. 次のコマンドを入力して、サービスの注釈を確認します。
```
kubectl describe service haproxy-haproxy-ingress-metrics -n haproxy-ingress-sample
```
次の注釈が表示されます。
```
Annotations: prometheus.io/port: 9101
prometheus.io/scrape: true
```
**HAProxy をアンインストールするには**
+ 以下のコマンドを入力します。
```
helm uninstall haproxy --namespace haproxy-ingress-sample
kubectl delete namespace haproxy-ingress-sample
```
# Prometheus スクレイピングの新しいターゲットの追加に関するチュートリアル: Amazon EKS クラスターと Kubernetes クラスター上の Redis OSS
このチュートリアルでは、Amazon EKS および Kubernetes 上のサンプル Redis OSS アプリケーションにおける Prometheus メトリクスをスクレイピングする方法を実践的に説明します。Redis OSS (https://redis.io/) は、オープンソース (BSD ライセンス適用) のインメモリ型のデータ構造ストアで、データベース、キャッシュ、メッセージブローカーとして使用されます。詳細については、「[redis](https://redis.io/)」を参照してください。
redis\$1exporter (MIT ライセンス適用) は、指定されたポート (デフォルト: 0.0.0.0:9121) で Redis OSS Prometheus メトリクスを公開するために使用します。詳細については、「[redis\$1exporter](https://github.com/oliver006/redis_exporter)」を参照してください。
このチュートリアルでは、次の 2 つの Docker ハブリポジトリの Docker イメージを使用します。
+ [redis](https://hub.docker.com/_/redis?tab=description)
+ [redis\$1exporter](https://hub.docker.com/r/oliver006/redis_exporter)
**Prometheus メトリクスを公開するサンプル Redis OSS ワークロードをインストールするには**
1. サンプル Redis OSS ワークロードの名前空間を設定します。
```
REDIS_NAMESPACE=redis-sample
```
1. Fargate 起動タイプのクラスター上で Redis OSS を実行している場合は、Fargate プロファイルを設定する必要があります。プロファイルを設定するには、次のコマンドを入力します。*MyCluster* をクラスターの名前に置き換えます。
```
eksctl create fargateprofile --cluster MyCluster \
--namespace $REDIS_NAMESPACE --name $REDIS_NAMESPACE
```
1. 次のコマンドを入力して、サンプル Redis OSS ワークロードをインストールします。
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_traffic/redis/redis-traffic-sample.yaml \
| sed "s/{{namespace}}/$REDIS_NAMESPACE/g" \
| kubectl apply -f -
```
1. インストールには、ポート 9121 で Redis OSS Prometheus メトリクスを公開する、`my-redis-metrics` という名前のサービスが含まれています。サービスの詳細を取得するには、次のコマンドを入力します。
```
kubectl describe service/my-redis-metrics -n $REDIS_NAMESPACE
```
結果の `Annotations` セクションには、CloudWatch エージェントの Prometheus スクレイプ設定に一致する 2 つの注釈が表示されます。これにより、ワークロードを自動検出できます。
```
prometheus.io/port: 9121
prometheus.io/scrape: true
```
関連する Prometheus スクレイプの設定は、`- job_name: kubernetes-service-endpoints` または `kubernetes-eks.yaml` の `kubernetes-k8s.yaml` のセクションに記載されています。
**CloudWatch で Redis OSS Prometheus メトリクスの収集を開始するには**
1. 次のコマンドのいずれかを入力して、最新バージョンの `kubernetes-eks.yaml` または `kubernetes-k8s.yaml` ファイルをダウンロードします。EC2 起動タイプの Amazon EKS クラスターの場合は、次のコマンドを入力します。
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-eks.yaml
```
Fargate 起動タイプの Amazon EKS クラスターの場合は、次のコマンドを入力します。
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-eks-fargate.yaml
```
Amazon EC2 インスタンスで実行されている Kubernetes クラスターの場合は、このコマンドを入力します。
```
curl -O https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/prometheus-k8s.yaml
```
1. テキストエディタでファイルを開き、`cwagentconfig.json` セクションを見つけます。次のサブセクションを追加し、変更を保存します。インデントが既存のパターンに従っていることを確認してください。
```
{
"source_labels": ["pod_name"],
"label_matcher": "^redis-instance$",
"dimensions": [["Namespace","ClusterName"]],
"metric_selectors": [
"^redis_net_(in|out)put_bytes_total$",
"^redis_(expired|evicted)_keys_total$",
"^redis_keyspace_(hits|misses)_total$",
"^redis_memory_used_bytes$",
"^redis_connected_clients$"
]
},
{
"source_labels": ["pod_name"],
"label_matcher": "^redis-instance$",
"dimensions": [["Namespace","ClusterName","cmd"]],
"metric_selectors": [
"^redis_commands_total$"
]
},
{
"source_labels": ["pod_name"],
"label_matcher": "^redis-instance$",
"dimensions": [["Namespace","ClusterName","db"]],
"metric_selectors": [
"^redis_db_keys$"
]
},
```
セクションの追加により、Redis OSS メトリクスが CloudWatch エージェントの許可リストに配置されます。これらのメトリクスのリストについては、次のセクションを参照してください。
1. Prometheus をサポートする CloudWatch エージェントが既にこのクラスターにデプロイされている場合は、次のコマンドを入力してエージェントを削除する必要があります。
```
kubectl delete deployment cwagent-prometheus -n amazon-cloudwatch
```
1. 次のいずれかのコマンドを入力して、更新した設定で CloudWatch エージェントをデプロイします。*MyCluster* と *リージョン*を設定に合わせて置き換えます。
EC2 起動タイプの Amazon EKS クラスターの場合は、次のコマンドを入力します。
```
kubectl apply -f prometheus-eks.yaml
```
Fargate 起動タイプの Amazon EKS クラスターの場合は、次のコマンドを入力します。
```
cat prometheus-eks-fargate.yaml \
| sed "s/{{cluster_name}}/MyCluster/;s/{{region_name}}/region/" \
| kubectl apply -f -
```
Kubernetes クラスターの場合は、このコマンドを入力します。
```
cat prometheus-k8s.yaml \
| sed "s/{{cluster_name}}/MyCluster/;s/{{region_name}}/region/" \
| kubectl apply -f -
```
## Redis OSS Prometheus メトリクスの表示
このチュートリアルでは、次のメトリクスを CloudWatch の **ContainerInsights/Prometheus** 名前空間に送信します。CloudWatch コンソールを使用して、その名前空間のメトリクスを表示できます。
| メトリクス名 | ディメンション |
| --- | --- |
| `redis_net_input_bytes_total` | ClusterName、`Namespace` |
| `redis_net_output_bytes_total` | ClusterName、`Namespace` |
| `redis_expired_keys_total` | ClusterName、`Namespace` |
| `redis_evicted_keys_total` | ClusterName、`Namespace` |
| `redis_keyspace_hits_total` | ClusterName、`Namespace` |
| `redis_keyspace_misses_total` | ClusterName、`Namespace` |
| `redis_memory_used_bytes` | ClusterName、`Namespace` |
| `redis_connected_clients` | ClusterName、`Namespace` |
| `redis_commands_total` | ClusterName、`Namespace`、cmd |
| `redis_db_keys` | ClusterName、`Namespace`、db |
**注記**
**cmd** ディメンションの値には `append`、`client`、`command`、`config`、`dbsize`、`flushall`、`get`、`incr`、`info`、`latency`、または `slowlog` を指定できます。
**db** ディメンションの値は `db0` から `db15` に指定できます。
また、Redis OSS Prometheus メトリクスの CloudWatch ダッシュボードを作成することもできます。
**Redis OSS Prometheus メトリクスのダッシュボードを作成するには**
1. 環境変数を作成し、以下の値をデプロイに合わせて置き換えます。
```
DASHBOARD_NAME=your_cw_dashboard_name
REGION_NAME=your_metric_region_such_as_us-east-1
CLUSTER_NAME=your_k8s_cluster_name_here
NAMESPACE=your_redis_service_namespace_here
```
1. 次のコマンドを入力して、ダッシュボードを作成します。
```
curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_cloudwatch_dashboards/redis/cw_dashboard_redis.json \
| sed "s/{{YOUR_AWS_REGION}}/${REGION_NAME}/g" \
| sed "s/{{YOUR_CLUSTER_NAME}}/${CLUSTER_NAME}/g" \
| sed "s/{{YOUR_NAMESPACE}}/${NAMESPACE}/g" \
```
# CloudWatch エージェントによる Prometheus メトリクスタイプの変換
Prometheus クライアントライブラリには、次の 4 つのコアメトリクスタイプがあります。
+ Counter
+ Gauge
+ 概要
+ Histogram
CloudWatch エージェントは、カウンター、ゲージ、サマリーメトリクスタイプをサポートします。
サポートされていないヒストグラムメトリクスタイプの Prometheus メトリクスは、CloudWatch エージェントによって除外されます。詳細については、「[削除された Prometheus メトリクスのログ記録](ContainerInsights-Prometheus-troubleshooting-EKS.md#ContainerInsights-Prometheus-troubleshooting-droppedmetrics)」を参照してください。
**ゲージメトリクス**
プロメテウスゲージメトリクス (Prometheus gauge metric) とは、任意に上下できる単一の数値を表すメトリクスです。CloudWatch エージェントはゲージメトリクスをスクレイプし、これらの値を直接送信します。
**カウンターメトリクス**
Prometheus カウンターメトリクスは、値を増加またはゼロにリセットすることができる単一の単調増加カウンターを表す累積メトリクスです。CloudWatch エージェントは、前回のスクレイプからデルタを計算し、ログイベントのメトリクス値としてデルタ値を送信します。したがって、CloudWatch エージェントは 2 回目のスクレイプから 1 つのログイベントを生成し始め、後続のスクラップがあれば続行します。
**サマリーメトリクス**
Prometheus サマリーメトリクスは、複数のデータポイントによって表される複雑なメトリクスタイプです。これは、観測値の合計数とすべての観測値の合計を提供します。スライドのタイムウィンドウで設定可能な分位数を計算します。
サマリーメトリクスの合計とカウントは累積されますが、分位数は累積されません。次の例は、分位数の分散を示しています。
```
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 7.123e-06
go_gc_duration_seconds{quantile="0.25"} 9.204e-06
go_gc_duration_seconds{quantile="0.5"} 1.1065e-05
go_gc_duration_seconds{quantile="0.75"} 2.8731e-05
go_gc_duration_seconds{quantile="1"} 0.003841496
go_gc_duration_seconds_sum 0.37630427
go_gc_duration_seconds_count 9774
```
前のセクションで説明したように、CloudWatch エージェントはカウンターメトリクスを処理するのと同じ方法で、サマリーメトリクスの合計とカウントを処理します。CloudWatch エージェントは、最初に報告された分位数の値を保持します。
# CloudWatch エージェントにより収集される Prometheus メトリクス
Prometheus をサポートする CloudWatch エージェントは、複数のサービスとワークロードからメトリクスを自動的に収集します。デフォルトで収集されるメトリクスは、次のセクションに表示されます。これらのサービスから収集するメトリクスを増やし、他のアプリケーションやサービスから Prometheus メトリクスを収集するようにエージェントを設定することもできます。追加メトリクスの収集の詳細については、「[Prometheus の CloudWatch エージェント設定](ContainerInsights-Prometheus-Setup-configure-ECS.md#ContainerInsights-Prometheus-Setup-cw-agent-config)」を参照してください。
Amazon EKS および Kubernetes クラスターから収集された Prometheus メトリクスは、[**ContainerInsights/Prometheus**] 名前空間にあります。Amazon ECS クラスターから収集された Prometheus メトリクスは、 [**ECS/ContainerInsights/Prometheus**] 名前空間にあります。
**Topics**
+ [App Mesh の Prometheus メトリクス](#ContainerInsights-Prometheus-metrics-appmesh)
+ [NGINX の Prometheus メトリクス](#ContainerInsights-Prometheus-metrics-nginx)
+ [memcached の Prometheus メトリクス](#ContainerInsights-Prometheus-metrics-memcached)
+ [Java/JMX の Prometheus メトリクス](#ContainerInsights-Prometheus-metrics-jmx)
+ [HAProxy の Prometheus メトリクス](#ContainerInsights-Prometheus-metrics-haproxy)
## App Mesh の Prometheus メトリクス
次のメトリクスは App Mesh から自動的に収集されます。
**Amazon EKS クラスターおよび Kubernetes クラスターでの App Mesh の Prometheus メトリクス**
| メトリクス名 | ディメンション |
| --- | --- |
| `envoy_http_downstream_rq_total` | ClusterName、`Namespace` |
| `envoy_http_downstream_rq_xx` | ClusterName、`Namespace` ClusterName、`Namespace`、envoy\$1http\$1conn\$1manager\$1prefix、envoy\$1response\$1code\$1class |
| `envoy_cluster_upstream_cx_rx_bytes_total` | ClusterName、`Namespace` |
| `envoy_cluster_upstream_cx_tx_bytes_total` | ClusterName、`Namespace` |
| `envoy_cluster_membership_healthy` | ClusterName、`Namespace` |
| `envoy_cluster_membership_total` | ClusterName、`Namespace` |
| `envoy_server_memory_heap_size` | ClusterName、`Namespace` |
| `envoy_server_memory_allocated` | ClusterName、`Namespace` |
| `envoy_cluster_upstream_cx_connect_timeout` | ClusterName、`Namespace` |
| `envoy_cluster_upstream_rq_pending_failure_eject` | ClusterName、`Namespace` |
| `envoy_cluster_upstream_rq_pending_overflow` | ClusterName、`Namespace` |
| `envoy_cluster_upstream_rq_timeout` | ClusterName、`Namespace` |
| `envoy_cluster_upstream_rq_try_per_timeout` | ClusterName、`Namespace` |
| `envoy_cluster_upstream_rq_rx_reset` | ClusterName、`Namespace` |
| `envoy_cluster_upstream_cx_destroy_local_with_active_rq` | ClusterName、`Namespace` |
| `envoy_cluster_upstream_cx_destroy_remote_active_rq` | ClusterName、`Namespace` |
| `envoy_cluster_upstream_rq_maintenance_mode` | ClusterName、`Namespace` |
| `envoy_cluster_upstream_flow_control_paused_reading_total` | ClusterName、`Namespace` |
| `envoy_cluster_upstream_flow_control_resumed_reading_total` | ClusterName、`Namespace` |
| `envoy_cluster_upstream_flow_control_backed_up_total` | ClusterName、`Namespace` |
| `envoy_cluster_upstream_flow_control_drained_total` | ClusterName、`Namespace` |
| `envoy_cluster_upstream_rq_retry` | ClusterName、`Namespace` |
| `envoy_cluster_upstream_rq_retry_success` | ClusterName、`Namespace` |
| `envoy_cluster_upstream_rq_retry_overflow` | ClusterName、`Namespace` |
| `envoy_server_live` | ClusterName、`Namespace` |
| `envoy_server_uptime` | ClusterName、`Namespace` |
**Amazon ECS クラスターでの App Mesh の Prometheus メトリクス**
| メトリクス名 | ディメンション |
| --- | --- |
| `envoy_http_downstream_rq_total` | ClusterName、`TaskDefinitionFamily` |
| `envoy_http_downstream_rq_xx` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_upstream_cx_rx_bytes_total` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_upstream_cx_tx_bytes_total` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_membership_healthy` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_membership_total` | ClusterName、`TaskDefinitionFamily` |
| `envoy_server_memory_heap_size` | ClusterName、`TaskDefinitionFamily` |
| `envoy_server_memory_allocated` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_upstream_cx_connect_timeout` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_upstream_rq_pending_failure_eject` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_upstream_rq_pending_overflow` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_upstream_rq_timeout` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_upstream_rq_try_per_timeout` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_upstream_rq_rx_reset` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_upstream_cx_destroy_local_with_active_rq` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_upstream_cx_destroy_remote_active_rq` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_upstream_rq_maintenance_mode` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_upstream_flow_control_paused_reading_total` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_upstream_flow_control_resumed_reading_total` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_upstream_flow_control_backed_up_total` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_upstream_flow_control_drained_total` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_upstream_rq_retry` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_upstream_rq_retry_success` | ClusterName、`TaskDefinitionFamily` |
| `envoy_cluster_upstream_rq_retry_overflow` | ClusterName、`TaskDefinitionFamily` |
| `envoy_server_live` | ClusterName、`TaskDefinitionFamily` |
| `envoy_server_uptime` | ClusterName、`TaskDefinitionFamily` |
| `envoy_http_downstream_rq_xx` | ClusterName, TaskDefinitionFamily, envoy\$1http\$1conn\$1manager\$1prefix, envoy\$1response\$1code\$1class ClusterName, TaskDefinitionFamily, envoy\$1response\$1code\$1class |
**注記**
`TaskDefinitionFamily` は、メッシュの Kubernetes 名前空間です。
`envoy_http_conn_manager_prefix` の値は、`ingress`、`egress`、または `admin` のいずれかです。
`envoy_response_code_class` の値は、 `1` (`1xx` を意味する)、`2` (`2xx` を意味する)、`3` (`3xx` を意味する)、 `4` (`4xx` を意味する)、 `5` (`5xx` を意味する) のいずれかです。
## NGINX の Prometheus メトリクス
次のメトリクスは、Amazon EKS および Kubernetes クラスターの NGINX から自動的に収集されます。
| メトリクス名 | ディメンション |
| --- | --- |
| `nginx_ingress_controller_nginx_process_cpu_seconds_total` | ClusterName、`Namespace`、Service |
| `nginx_ingress_controller_success` | ClusterName、`Namespace`、Service |
| `nginx_ingress_controller_requests` | ClusterName、`Namespace`、Service |
| `nginx_ingress_controller_nginx_process_connections` | ClusterName、`Namespace`、Service |
| `nginx_ingress_controller_nginx_process_connections_total` | ClusterName、`Namespace`、Service |
| `nginx_ingress_controller_nginx_process_resident_memory_bytes` | ClusterName、`Namespace`、Service |
| `nginx_ingress_controller_config_last_reload_successful` | ClusterName、`Namespace`、Service |
| `nginx_ingress_controller_requests` | ClusterName、`Namespace`、Service、ステータス |
## memcached の Prometheus メトリクス
以下のメトリクスは、Amazon EKS および Kubernetes クラスターの memcached から自動的に収集されます。
| メトリクス名 | ディメンション |
| --- | --- |
| `memcached_current_items` | ClusterName、`Namespace`、Service |
| `memcached_current_connections` | ClusterName、`Namespace`、Service |
| `memcached_limit_bytes` | ClusterName、`Namespace`、Service |
| `memcached_current_bytes` | ClusterName、`Namespace`、Service |
| `memcached_written_bytes_total` | ClusterName、`Namespace`、Service |
| `memcached_read_bytes_total` | ClusterName、`Namespace`、Service |
| `memcached_items_evicted_total` | ClusterName、`Namespace`、Service |
| `memcached_items_reclaimed_total` | ClusterName、`Namespace`、Service |
| `memcached_commands_total` | ClusterName、`Namespace`、Service ClusterName、`Namespace`、Service、コマンド ClusterName、`Namespace`、Service、ステータス、コマンド |
## Java/JMX の Prometheus メトリクス
**Amazon EKS および Kubernetes クラスターで収集されたメトリクス**
Container Insights は、Amazon EKS および Kubernetes クラスターで JMX Exporter を使用して、Java 仮想マシン (JVM)、Java、Tomcat (Catalina) から、次の定義済みの Prometheus メトリクスを収集できます。詳細については、Github の [prometheus/jmx\$1exporter](https://github.com/prometheus/jmx_exporter) を参照してください。
**Amazon EKS クラスターおよび Kubernetes クラスターでの Java/JMX**
| メトリクス名 | ディメンション |
| --- | --- |
| `jvm_classes_loaded` | `ClusterName`, `Namespace` |
| `jvm_threads_current` | `ClusterName`, `Namespace` |
| `jvm_threads_daemon` | `ClusterName`, `Namespace` |
| `java_lang_operatingsystem_totalswapspacesize` | `ClusterName`, `Namespace` |
| `java_lang_operatingsystem_systemcpuload` | `ClusterName`, `Namespace` |
| `java_lang_operatingsystem_processcpuload` | `ClusterName`, `Namespace` |
| `java_lang_operatingsystem_freeswapspacesize` | `ClusterName`, `Namespace` |
| `java_lang_operatingsystem_totalphysicalmemorysize` | `ClusterName`, `Namespace` |
| `java_lang_operatingsystem_freephysicalmemorysize` | `ClusterName`, `Namespace` |
| `java_lang_operatingsystem_openfiledescriptorcount` | `ClusterName`, `Namespace` |
| `java_lang_operatingsystem_availableprocessors` | `ClusterName`, `Namespace` |
| `jvm_memory_bytes_used` | `ClusterName`、`Namespace`、エリア |
| `jvm_memory_pool_bytes_used` | `ClusterName`、`Namespace`、プール |
**注記**
`area` ディメンションの値は、`heap` または `nonheap` になります。
`pool` ディメンションの値は `Tenured Gen`、`Compress Class Space`、`Survivor Space`、`Eden Space`、`Code Cache`、または `Metaspace` のいずれかです。
**Amazon EKS および Kubernetes クラスター上の TomCAT/JMX**
前の表の Java/JMX メトリクスに加えて、Tomcat ワークロードに対して次のメトリクスも収集されます。
| メトリクス名 | ディメンション |
| --- | --- |
| `catalina_manager_activesessions` | `ClusterName`, `Namespace` |
| `catalina_manager_rejectedsessions` | `ClusterName`, `Namespace` |
| `catalina_globalrequestprocessor_bytesreceived` | `ClusterName`, `Namespace` |
| `catalina_globalrequestprocessor_bytessent` | `ClusterName`, `Namespace` |
| `catalina_globalrequestprocessor_requestcount` | `ClusterName`, `Namespace` |
| `catalina_globalrequestprocessor_errorcount` | `ClusterName`, `Namespace` |
| `catalina_globalrequestprocessor_processingtime` | `ClusterName`, `Namespace` |
**Amazon ECS クラスターの Java/JMX**
| メトリクス名 | ディメンション |
| --- | --- |
| `jvm_classes_loaded` | `ClusterName`, `TaskDefinitionFamily` |
| `jvm_threads_current` | `ClusterName`, `TaskDefinitionFamily` |
| `jvm_threads_daemon` | `ClusterName`, `TaskDefinitionFamily` |
| `java_lang_operatingsystem_totalswapspacesize` | `ClusterName`, `TaskDefinitionFamily` |
| `java_lang_operatingsystem_systemcpuload` | `ClusterName`, `TaskDefinitionFamily` |
| `java_lang_operatingsystem_processcpuload` | `ClusterName`, `TaskDefinitionFamily` |
| `java_lang_operatingsystem_freeswapspacesize` | `ClusterName`, `TaskDefinitionFamily` |
| `java_lang_operatingsystem_totalphysicalmemorysize` | `ClusterName`, `TaskDefinitionFamily` |
| `java_lang_operatingsystem_freephysicalmemorysize` | `ClusterName`, `TaskDefinitionFamily` |
| `java_lang_operatingsystem_openfiledescriptorcount` | `ClusterName`, `TaskDefinitionFamily` |
| `java_lang_operatingsystem_availableprocessors` | `ClusterName`, `TaskDefinitionFamily` |
| `jvm_memory_bytes_used` | `ClusterName`、TaskDefinitionFamily、エリア |
| `jvm_memory_pool_bytes_used` | `ClusterName`、TaskDefinitionFamily、プール |
**注記**
`area` ディメンションの値は、`heap` または `nonheap` になります。
`pool` ディメンションの値は `Tenured Gen`、`Compress Class Space`、`Survivor Space`、`Eden Space`、`Code Cache`、または `Metaspace` のいずれかです。
**Amazon ECS クラスターでの Tomcat/JMX**
前の表の Java/JMX メトリクスに加えて、Amazon ECS クラスターの Tomcat ワークロードに対して次のメトリクスも収集されます。
| メトリクス名 | ディメンション |
| --- | --- |
| `catalina_manager_activesessions` | `ClusterName`, `TaskDefinitionFamily` |
| `catalina_manager_rejectedsessions` | `ClusterName`, `TaskDefinitionFamily` |
| `catalina_globalrequestprocessor_bytesreceived` | `ClusterName`, `TaskDefinitionFamily` |
| `catalina_globalrequestprocessor_bytessent` | `ClusterName`, `TaskDefinitionFamily` |
| `catalina_globalrequestprocessor_requestcount` | `ClusterName`, `TaskDefinitionFamily` |
| `catalina_globalrequestprocessor_errorcount` | `ClusterName`, `TaskDefinitionFamily` |
| `catalina_globalrequestprocessor_processingtime` | `ClusterName`, `TaskDefinitionFamily` |
## HAProxy の Prometheus メトリクス
次のメトリクスは、Amazon EKS および Kubernetes クラスターの HAProxy から自動的に収集されます。
収集されるメトリクスは、使用している HAProxy Ingress のバージョンによって異なります。HAProxy Ingress とそのバージョンの詳細については、「[haproxy-ingress](https://artifacthub.io/packages/helm/haproxy-ingress/haproxy-ingress)」をご参照ください。
| メトリクス名 | ディメンション | 利用可能な状況 |
| --- | --- | --- |
| `haproxy_backend_bytes_in_total` | `ClusterName`、`Namespace`、Service | HAProxy Ingress のすべてのバージョン |
| `haproxy_backend_bytes_out_total` | `ClusterName`、`Namespace`、Service | HAProxy Ingress のすべてのバージョン |
| `haproxy_backend_connection_errors_total` | `ClusterName`、`Namespace`、Service | HAProxy Ingress のすべてのバージョン |
| `haproxy_backend_connections_total` | `ClusterName`、`Namespace`、Service | HAProxy Ingress のすべてのバージョン |
| `haproxy_backend_current_sessions` | `ClusterName`、`Namespace`、Service | HAProxy Ingress のすべてのバージョン |
| `haproxy_backend_http_responses_total` | `ClusterName`、`Namespace`、Service、コード、バックエンド | HAProxy Ingress のすべてのバージョン |
| `haproxy_backend_status` | `ClusterName`、`Namespace`、Service | HAProxy Ingress のバージョン 0.10 以降のみ |
| `haproxy_backend_up` | `ClusterName`、`Namespace`、Service | 0.10 より前のバージョンの HAProxy Ingress のみ |
| `haproxy_frontend_bytes_in_total` | `ClusterName`、`Namespace`、Service | HAProxy Ingress のすべてのバージョン |
| `haproxy_frontend_bytes_out_total` | `ClusterName`、`Namespace`、Service | HAProxy Ingress のすべてのバージョン |
| `haproxy_frontend_connections_total` | `ClusterName`、`Namespace`、Service | HAProxy Ingress のすべてのバージョン |
| `haproxy_frontend_current_sessions` | `ClusterName`、`Namespace`、Service | HAProxy Ingress のすべてのバージョン |
| `haproxy_frontend_http_requests_total` | `ClusterName`、`Namespace`、Service | HAProxy Ingress のすべてのバージョン |
| `haproxy_frontend_http_responses_total` | `ClusterName`、`Namespace`、Service、コード、フロントエンド | HAProxy Ingress のすべてのバージョン |
| `haproxy_frontend_request_errors_total` | `ClusterName`、`Namespace`、Service | HAProxy Ingress のすべてのバージョン |
| `haproxy_frontend_requests_denied_total` | `ClusterName`、`Namespace`、Service | HAProxy Ingress のすべてのバージョン |
**注記**
`code` ディメンションの値は `1xx`、`2xx`、`3xx`、`4xx`、`5xx`、または `other` のいずれかです。
`backend` ディメンションの値は次とすることができます:
HAProxy Ingress バージョン 0.0.27 以前用の `http-default-backend`、`http-shared-backend`、または `httpsback-shared-backend`。
`_default_backend`0.0.27 より後のバージョンの HAProxy Ingress の 。
`frontend` ディメンションの値は次とすることができます:
HAProxy Ingress バージョン 0.0.27 以前用の `httpfront-default-backend`、`httpfront-shared-frontend`、または `httpfronts`。
0.0.27 より後のバージョンの HAProxy Ingress の `_front_http` または `_front_https`。
# Prometheus メトリクスの表示
App Mesh、NGINX、Java/JMX、Memcached、HAProxy、およびユーザーが追加した手動設定の他の Prometheus エクスポーターから選別された事前集計メトリクスを含む、すべての Prometheus メトリクスについてモニターリングし、アラームを受けることができます。他の Prometheus エクスポーターからのメトリクス収集の詳細については、「[新しい Prometheus スクレイピングターゲットを追加するためのチュートリアル: Prometheus API サーバーメトリクス](ContainerInsights-Prometheus-Setup-configure.md#ContainerInsights-Prometheus-Setup-new-exporters)」を参照してください。
CloudWatch コンソールでは、Container Insights は次の事前作成済みのレポートを提供します。
+ Amazon EKS および Kubernetes クラスターの場合、App Mesh、NGINX、HAProxy、Memcached、Java/JMX 用の事前作成済みのレポートが提供されます。
+ Amazon ECS クラスターの場合、App Mesh と Java/JMX 用の事前作成済みレポートが提供されます。
また、Container Insights は、Container Insights が厳選したメトリクスを収集するワークロードごとにカスタムダッシュボードを提供します。これらのダッシュボードは GitHub からダウンロードすることができます
**Prometheus メトリクスをすべて表示するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで [**Metrics (メトリクス)**] を選択してください。
1. 名前空間のリストで、[**ContainerInsights/Prometheus**] または [**ECS/ContainerInsights/Prometheus**] を選択します。
1. 次のリストで、ディメンションのセットの 1 つを選択します。次に、表示するメトリクスの横にあるチェックボックスを選択します。
**Prometheus メトリクスに関する事前作成済みのレポートを表示するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、[**パフォーマンスのモニターリング**] を選択します。
1. ページの上部近くのドロップダウンボックスで、Prometheus オプションのいずれかを選択します。
もう 1 つのドロップダウンボックスで、表示するクラスターを選択します。
また、NGINX、App Mesh、Memcached、HAProxy、Java/JMX 用のカスタムダッシュボードも用意されています。
**Amazon が用意したカスタムダッシュボードを使用するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、**ダッシュボード**を選択します。
1. [**ダッシュボードの作成**] を選択します。新しいダッシュボードの名前を入力し、[**ダッシュボードの作成**] を選択します。
1. [**このダッシュボードに追加**] で、[**キャンセル**] を選択します。
1. [**アクション**]、[**ソースの表示/編集**] を選択します。
1. 次の JSON ファイルのいずれかをダウンロードします。
+ [ Github の NGINX カスタムダッシュボードソース](https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_cloudwatch_dashboards/nginx-ingress/cw_dashboard_nginx_ingress_controller.json)。
+ [Github の App Mesh カスタムダッシュボードソース](https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_cloudwatch_dashboards/appmesh/cw_dashboard_awsappmesh.json)。
+ [ Github の Memcached カスタムダッシュボードソース](https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_cloudwatch_dashboards/memcached/cw_dashboard_memcached.json)。
+ [ Github の HAProxy-Ingress カスタムダッシュボードソース](https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_cloudwatch_dashboards/haproxy-ingress/cw_dashboard_haproxy_ingress.json)
+ [ Github の Java/JMX カスタムダッシュボードソース](https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/service/cwagent-prometheus/sample_cloudwatch_dashboards/javajmx/cw_dashboard_javajmx.json)。
1. ダウンロードした JSON ファイルをテキストエディタで開き、次の変更を加えます。
+ すべての `{{YOUR_CLUSTER_NAME}}` 文字列をクラスターの正確な名前に置き換えます。テキストの前後に空白を追加しないようにしてください。
+ すべての `{{YOUR_REGION}}` 文字列を、クラスターが実行されている AWS リージョンに置き換えます。例えば、**us-west-1** テキストの前後に空白を追加しないようにしてください。
+ すべての `{{YOUR_NAMESPACE}}` 文字列を、ワークロードとまったく同じ名前空間に置き換えます。
+ すべての `{{YOUR_SERVICE_NAME}}` 文字列を、ワークロードとまったく同じサービス名に置き換えます。例: **haproxy-haproxy-ingress-controller-metrics**
1. JSON BLOB 全体をコピーし、CloudWatch コンソールのテキストボックスに貼り付けて、ボックスに既に入力されている内容を置き換えます。
1. [**更新**]、[**ダッシュボードの保存**] の順に選択します。
# Prometheus メトリクスのトラブルシューティング
このセクションでは、Prometheus メトリクス設定のトラブルシューティングに役立つ情報を提供します。
**Topics**
+ [Amazon ECS での Prometheus メトリクスのトラブルシューティング](ContainerInsights-Prometheus-troubleshooting-ECS.md)
+ [Amazon EKS および Kubernetes クラスターでの Prometheus メトリクスのトラブルシューティング](ContainerInsights-Prometheus-troubleshooting-EKS.md)
# Amazon ECS での Prometheus メトリクスのトラブルシューティング
このセクションでは、クラスターの Amazon ECS での Prometheus メトリクス設定のトラブルシューティングに役立つ情報を提供します。
## CloudWatch Logs に送信された Prometheus メトリクスが表示されません
Prometheus メトリクスをロググループ **/aws/ecs/containerinsights/cluster-name/Prometheus** にログイベントとして取り込む必要があります。ロググループが作成されていない場合、または Prometheus メトリクスがロググループに送信されない場合は、Prometheus ターゲットが CloudWatch エージェントによって正常に検出されているかどうかを確認する必要があります。次に、CloudWatch エージェントのセキュリティグループとアクセス許可設定を確認します。次のステップは、デバッグを実行するためのガイドです。
**ステップ 1: CloudWatch エージェントのデバッグモードを有効にする**
最初に、CloudFormation テンプレートファイル、`cwagent-ecs-prometheus-metric-for-bridge-host.yaml` または `cwagent-ecs-prometheus-metric-for-awsvpc.yaml` に次の太字行を追加して、CloudWatch エージェントをデバッグモードに変更します。その後、ファイルを保存します。
```
cwagentconfig.json: |
{
"agent": {
"debug": true
},
"logs": {
"metrics_collected": {
```
既存のスタックに対して新しい CloudFormation 変更セットを作成します。変更セットの他のパラメータを、既存の CloudFormation スタックと同じ値に設定します。次の例は、EC2 起動タイプとブリッジネットワークモードを使用して Amazon ECS クラスターにインストールされた CloudWatch エージェントです。
```
ECS_NETWORK_MODE=bridge
CREATE_IAM_ROLES=True
ECS_TASK_ROLE_NAME=your_selected_ecs_task_role_name
ECS_EXECUTION_ROLE_NAME=your_selected_ecs_execution_role_name
NEW_CHANGESET_NAME=your_selected_ecs_execution_role_name
aws cloudformation create-change-set --stack-name CWAgent-Prometheus-ECS-${ECS_CLUSTER_NAME}-EC2-${ECS_NETWORK_MODE} \
--template-body file://cwagent-ecs-prometheus-metric-for-bridge-host.yaml \
--parameters ParameterKey=ECSClusterName,ParameterValue=$ECS_CLUSTER_NAME \
ParameterKey=CreateIAMRoles,ParameterValue=$CREATE_IAM_ROLES \
ParameterKey=ECSNetworkMode,ParameterValue=$ECS_NETWORK_MODE \
ParameterKey=TaskRoleName,ParameterValue=$ECS_TASK_ROLE_NAME \
ParameterKey=ExecutionRoleName,ParameterValue=$ECS_EXECUTION_ROLE_NAME \
--capabilities CAPABILITY_NAMED_IAM \
--region $AWS_REGION \
--change-set-name $NEW_CHANGESET_NAME
```
CloudFormation コンソールに移動して、新しい変更セット、`$NEW_CHANGESET_NAME` を確認します。**CWAgentConfigSSMParameter** リソースには、1 つの変更が適用されている必要があります。次のコマンドを入力して、変更セットを実行し、CloudWatch エージェントタスクを再起動します。
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 0 \
--service your_service_name_here \
--region $AWS_REGION
```
10 秒ほど待ってから、次のコマンドを入力します。
```
aws ecs update-service --cluster $ECS_CLUSTER_NAME \
--desired-count 1 \
--service your_service_name_here \
--region $AWS_REGION
```
**ステップ 2: ECS サービス検出ログを確認する**
CloudWatch エージェントの ECS タスク定義では、以下のセクションのログがデフォルトで有効になります。ログは、ロググループ **/ecs/ecs-cwagent-prometheus** の CloudWatch Logs に送信されます。
```
LogConfiguration:
LogDriver: awslogs
Options:
awslogs-create-group: 'True'
awslogs-group: "/ecs/ecs-cwagent-prometheus"
awslogs-region: !Ref AWS::Region
awslogs-stream-prefix: !Sub 'ecs-${ECSLaunchType}-awsvpc'
```
次の例に示すように、文字列 `ECS_SD_Stats` でログをフィルタリングして、ECS サービスの検出に関連するメトリクスを取得します。
```
2020-09-1T01:53:14Z D! ECS_SD_Stats: AWSCLI_DescribeContainerInstances: 1
2020-09-1T01:53:14Z D! ECS_SD_Stats: AWSCLI_DescribeInstancesRequest: 1
2020-09-1T01:53:14Z D! ECS_SD_Stats: AWSCLI_DescribeTaskDefinition: 2
2020-09-1T01:53:14Z D! ECS_SD_Stats: AWSCLI_DescribeTasks: 1
2020-09-1T01:53:14Z D! ECS_SD_Stats: AWSCLI_ListTasks: 1
2020-09-1T01:53:14Z D! ECS_SD_Stats: Exporter_DiscoveredTargetCount: 1
2020-09-1T01:53:14Z D! ECS_SD_Stats: LRUCache_Get_EC2MetaData: 1
2020-09-1T01:53:14Z D! ECS_SD_Stats: LRUCache_Get_TaskDefinition: 2
2020-09-1T01:53:14Z D! ECS_SD_Stats: LRUCache_Size_ContainerInstance: 1
2020-09-1T01:53:14Z D! ECS_SD_Stats: LRUCache_Size_TaskDefinition: 2
2020-09-1T01:53:14Z D! ECS_SD_Stats: Latency: 43.399783ms
```
特定の ECS サービス検出サイクルの各メトリクスの意味は次のとおりです。
+ **AWSCLI\$1DescribeContainerInstances** – 実行された `ECS::DescribeContainerInstances` API 呼び出しの数。
+ **AWSCLI\$1DescribeInstancesRequest** – 実行された `ECS::DescribeInstancesRequest` API 呼び出しの数。
+ **AWSCLI\$1DescribeTaskDefinition** – 実行された `ECS::DescribeTaskDefinition` API 呼び出しの数。
+ **AWSCLI\$1DescribeTasks** – 実行された `ECS::DescribeTasks` API 呼び出しの数。
+ **AWSCLI\$1ListTasks** – 実行された `ECS::ListTasks` API 呼び出しの数。
+ **ExporterDiscoveredTargetCount** – 検出され、コンテナ内のターゲット結果ファイルに正常にエクスポートされた Prometheus ターゲットの数。
+ **LRUCache\$1Get\$1EC2MetaData** – コンテナインスタンスのメタデータがキャッシュから取得された回数。
+ **LRUCache\$1Get\$1TaskDefinition** – ECS タスク定義メタデータがキャッシュから取得された回数。
+ **LRUCache\$1Size\$1ContainerInstance** – メモリにキャッシュされた一意のコンテナインスタンスのメタデータの数。
+ **LRUCache\$1Size\$1TaskDefinition** – メモリにキャッシュされた一意の ECS タスク定義の数。
+ **レイテンシー** – サービス検出サイクルに要する待ち時間。
`ExporterDiscoveredTargetCount` の値をチェックして、検出された Prometheus のターゲットが期待と一致しているかどうかを確認します。そうでない場合、考えられる理由は次のとおりです。
+ ECS サービス検出の設定が、アプリケーションの設定と一致していない可能性があります。Docker ラベルベースのサービス検出では、ターゲットコンテナに自動検出するために必要な Docker ラベルが CloudWatch エージェントで構成されていない可能性があります。ECS タスク定義 ARN 正規表現ベースのサービス検出の場合、CloudWatch エージェントの regex 設定がアプリケーションのタスク定義と一致していないことがあります。
+ CloudWatch エージェントの ECS タスクロールに、ECS タスクのメタデータを取得するアクセス許可がない可能性があります。CloudWatch エージェントに次の読み取り専用アクセス許可が付与されていることを確認します。
+ `ec2:DescribeInstances`
+ `ecs:ListTasks`
+ `ecs:DescribeContainerInstances`
+ `ecs:DescribeTasks`
+ `ecs:DescribeTaskDefinition`
**ステップ 3: ネットワーク接続と ECS タスクのロールポリシーを確認する**
`Exporter_DiscoveredTargetCount` の値が Prometheus ターゲットが検出されたことを示しているにもかかわらず、ターゲット CloudWatch Logs ロググループに送信されるログイベントがない場合は、次のいずれかが原因で発生している可能性があります。
+ CloudWatch エージェントが Prometheus ターゲットポートに接続できない可能性があります。CloudWatch エージェントの背後にあるセキュリティグループ設定を確認します。プライベート IP は、CloudWatch エージェントが Prometheus エクスポーターポートに接続できるようにする必要があります。
+ CloudWatch エージェントの ECS タスクロールに **CloudWatchAgentServerPolicy** マネージドポリシーがない可能性があります。Prometheus メトリクスをログイベントとして送信できるようにするには、CloudWatch エージェントの ECS タスクロールにこのポリシーが必要です。サンプル CloudFormation テンプレートを使用して IAM ロールを自動的に作成した場合、ECS タスクロールと ECS 実行ロールの両方に、Prometheus モニターリングを実行するための最小権限が付与されます。
# Amazon EKS および Kubernetes クラスターでの Prometheus メトリクスのトラブルシューティング
このセクションでは、Amazon EKS および Kubernetes クラスターでの Prometheus メトリクス設定のトラブルシューティングに役立つ情報を提供します。
## Amazon EKS の一般的なトラブルシューティングステップ
CloudWatch エージェントが実行中であることを確認するには、次のコマンドを使用します。
```
kubectl get pod -n amazon-cloudwatch
```
出力には、`cwagent-prometheus-id` 列の `NAME` と、`Running` の `STATUS column.` の行を含める必要があります。
実行中のポッドの詳細を表示するには、次のコマンドを入力します。*pod-name* は、`cw-agent-prometheus` で始まる名前を持つポッドの完全名に置き換えます。
```
kubectl describe pod pod-name -n amazon-cloudwatch
```
CloudWatch Container Insights がインストールされている場合は、CloudWatch Logs Insights を使用して、Prometheus メトリクスを収集する CloudWatch エージェントからログをクエリできます。
**アプリケーションログをクエリするには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、[**CloudWatch Logs Insights**] を選択します。
1. アプリケーションログのロググループ **/aws/containerinsights/*cluster-name*/application** を選択します。
1. 検索クエリ式を次のクエリに置き換え、[**クエリの実行**] を選択します。
```
fields ispresent(kubernetes.pod_name) as haskubernetes_pod_name, stream, kubernetes.pod_name, log |
filter haskubernetes_pod_name and kubernetes.pod_name like /cwagent-prometheus
```
また、Prometheus メトリクスとメタデータが CloudWatch Logs イベントとして取り込まれていることを確認できます。
**Prometheus のデータが取り込まれていることを確認するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、[**CloudWatch Logs Insights**] を選択します。
1. [**/aws/containerinsights/*cluster-name*/prometheus**] を選択します。
1. 検索クエリ式を次のクエリに置き換え、[**クエリの実行**] を選択します。
```
fields @timestamp, @message | sort @timestamp desc | limit 20
```
## 削除された Prometheus メトリクスのログ記録
このリリースでは、ヒストグラムタイプの Prometheus メトリクスは収集されません。CloudWatch エージェントを使用して、Prometheus メトリクスがヒストグラムメトリクスであるために削除されているかどうかを確認できます。また、ヒストグラムメトリクスであるために、削除されて CloudWatch に送信されない最初の 500 個の Prometheus メトリクスのリストを記録することもできます。
メトリクスが削除されているかどうかを確認するには、次のコマンドを入力します。
```
kubectl logs -l "app=cwagent-prometheus" -n amazon-cloudwatch --tail=-1
```
メトリクスが削除されている場合は、`/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log` ファイルに次の行が表示されます。
```
I! Drop Prometheus metrics with unsupported types. Only Gauge, Counter and Summary are supported.
I! Please enable CWAgent debug mode to view the first 500 dropped metrics
```
これらの行が表示されている場合に、どのメトリクスが削除されているかを確認するには、次のステップを実行します。
**削除された Prometheus メトリクスのリストを記録するには**
1. `prometheus-eks.yaml` または `prometheus-k8s.yaml` ファイルに次の太字行を追加して、CloudWatch エージェントをデバッグモードに変更し、ファイルを保存します。
```
{
"agent": {
"debug": true
},
```
ファイルのこのセクションは、次のようになります。
```
cwagentconfig.json: |
{
"agent": {
"debug": true
},
"logs": {
"metrics_collected": {
```
1. 次のコマンドを入力して、CloudWatch エージェントを再インストールしてデバッグモードを有効にします。
```
kubectl delete deployment cwagent-prometheus -n amazon-cloudwatch
kubectl apply -f prometheus.yaml
```
削除されたメトリクスは、CloudWatch エージェントポッドに記録されます。
1. CloudWatch エージェントポッドからログを取得するには、次のコマンドを入力します。
```
kubectl logs -l "app=cwagent-prometheus" -n amazon-cloudwatch --tail=-1
```
または、Container Insights Fluentd ログ記録がインストールされている場合、ログは CloudWatch Logs ロググループ **/aws/containerinsights/*cluster\$1name*/application** にも保存されます。
これらのログをクエリするには、「[Amazon EKS の一般的なトラブルシューティングステップ](#ContainerInsights-Prometheus-troubleshooting-general)」のアプリケーションログをクエリするステップに従います。
## Prometheus メトリクスが CloudWatch Logs ログイベントとして取り込まれる場所
CloudWatch エージェントは、Prometheus スクレイプジョブ設定ごとにログストリームを作成します。例えば、`prometheus-eks.yaml` および `prometheus-k8s.yaml` ファイルでは、`job_name: 'kubernetes-pod-appmesh-envoy'` 行が App Mesh メトリクスをスクレイプします。Prometheus ターゲットは `kubernetes-pod-appmesh-envoy` と定義されます。したがって、すべての App Mesh Prometheus メトリクスは、**/aws/containerinsights/cluster-name/Prometheus** という名前のロググループの下のログストリーム **kubernetes-pod-appmesh-envoy** に CloudWatch Logs イベントとして取り込まれます。
## CloudWatch メトリクスに Amazon EKS または Kubernetes Prometheus メトリクスが表示されない
まず、Prometheus メトリクスがロググループ **/aws/containerinsights/cluster-name/Prometheus** にログイベントとして取り込まれることを確認します。「[Prometheus メトリクスが CloudWatch Logs ログイベントとして取り込まれる場所](#ContainerInsights-Prometheus-troubleshooting-metrics_ingested)」の情報を使用して、ターゲットログストリームを確認します。ログストリームが作成されない場合、またはログストリームに新しいログイベントがない場合は、次の点を確認します。
+ Prometheus メトリクスエクスポーターのエンドポイントが正しく設定されていることを確認します。
+ CloudWatch エージェント YAML ファイルの `config map: cwagent-prometheus` セクションにある Prometheus スクレイピング設定が正しいことを確認します。この設定は、Prometheus 設定ファイルと同じになります。詳細については、Prometheus ドキュメントの「[](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config)」を参照してください。
Prometheus メトリクスがログイベントとして正しく取り込まれる場合は、埋め込みメトリクス形式設定がログイベントに追加され、CloudWatch メトリクスを生成することを確認します。
```
"CloudWatchMetrics":[
{
"Metrics":[
{
"Name":"envoy_http_downstream_cx_destroy_remote_active_rq"
}
],
"Dimensions":[
[
"ClusterName",
"Namespace"
]
],
"Namespace":"ContainerInsights/Prometheus"
}
],
```
埋め込みメトリックフォーマットの詳細については、「[仕様: 埋め込みメトリクスフォーマット](CloudWatch_Embedded_Metric_Format_Specification.md)」を参照してください。
ログイベントにメトリクス形式が埋め込まれていない場合は、CloudWatch エージェントインストール YAML ファイルの `config map: prometheus-cwagentconfig` セクションで、`metric_declaration` セクションが正しく設定されていることを確認してください。(詳細については、[新しい Prometheus スクレイピングターゲットを追加するためのチュートリアル: Prometheus API サーバーメトリクス](ContainerInsights-Prometheus-Setup-configure.md#ContainerInsights-Prometheus-Setup-new-exporters) を参照してください)。
# Application Insights との統合
Amazon CloudWatch Application Insights は、アプリケーションのモニターリングに役立ち、アプリケーションリソースとテクノロジースタック全体の主要なメトリクス、ログ、アラームを識別して設定します。詳細については、「[CloudWatch Application Insights を使用したアプリケーションの一般的な問題の検出](cloudwatch-application-insights.md)」を参照してください。
Application Insights を有効にして、コンテナ化されたアプリケーションとマイクロサービスの追加データを収集できます。まだ有効にしていない場合は、Container Insights ダッシュボードのパフォーマンスビューの下にある **[Auto-configure Application Insights]** (Application Insights の自動設定) を選択して有効にできます。
コンテナ化されたアプリケーションをモニターリングするように CloudWatch Application Insights を既に設定している場合は、Container Insights ダッシュボードの下に Application Insights ダッシュボードが表示されます。
Application Insights とコンテナ化されたアプリケーションの詳細については、「[Amazon ECS および Amazon EKS リソースのモニターリングで Application Insights を有効にする](appinsights-setting-up-console.md#appinsights-container-insights)」を参照してください。
# Container Insights 内での Amazon ECS ライフサイクルイベントの表示
Amazon ECS ライフサイクルイベントは、Container Insights のコンソールで表示できます。これにより、コンテナのメトリクス、ログ、およびイベントを単一のビュー内で関連付けることができ、運用上の可視性がより完全なものになります。
イベントには、コンテナインスタンスの状態変更イベント、タスク状態変更イベント、サービスアクションイベントなどがあります。これらは Amazon ECS によって Amazon EventBridge に自動的に送信され、CloudWatch にもイベントログ形式で収集されます。これらのイベントの詳細については、「[Amazon ECS イベント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)」を参照してください。
Amazon ECS ライフサイクルイベントには、標準の Container Insights 料金が適用されます。詳細については、「[Amazon CloudWatch 料金表](https://aws.amazon.com/cloudwatch/pricing/)」をご覧ください。
ライフサイクルイベントのテーブルを設定し、クラスターのルールを作成するには、`events:PutRule`、`events:PutTargets`、および `logs:CreateLogGroup` のアクセス許可が必要です。また、EventBridge がログストリームを作成して CloudWatch Logs にログを送信できるリソースベースポリシーがあることを確認する必要があります。リソースポリシーが存在しない場合は、次のコマンドを入力して作成できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Principal": {
"Service": ["events.amazonaws.com", "delivery.logs.amazonaws.com"]
},
"Resource": "arn:aws:logs:us-east-1:111122223333:log-group:/aws/events/ecs/containerinsights/*:*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:events:us-east-1:111122223333:rule/eventsToLog*"
}
},
"Sid": "TrustEventBridgeToStoreECSLifecycleLogEvents"
}
]
}
```
------
次のコマンドを使用して、このポリシーが既に存在しているかどうかを確認し、正しくアタッチされたかどうかを確認できます。
```
aws logs describe-resource-policies --region region --output json
```
ライフサイクルイベントのテーブルを表示するには、`events:DescribeRule`、`events:ListTargetsByRule`、および `logs:DescribeLogGroups` のアクセス許可が必要です。
**CloudWatch Container Insights のコンソールで Amazon ECS ライフサイクルイベントを表示するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. **[Insights]** (インサイト)、**[Container Insights]** を選択します。
1. **[パフォーマンスダッシュボードの表示]** を選択します。
1. 次のドロップダウンで、**[ECS Clusters]** (ECS クラスター)、**[ECS Services]** (ECS サービス)、または **[ECS Tasks]** (ECS タスク) のいずれかを選択します。
1. 前のステップで **[ECS Services]** (ECS サービス) または **[ECS Tasks]** (ECS タスク) を選択した場合は、**[Lifecycle events]** (ライフサイクルイベント) タブを選択します。
1. ページの下部に **[Configure lifecycle events]** (ライフサイクルイベントの設定) が表示されている場合は、これを選択してクラスターの EventBridge ルールを作成します。
これらのイベントは、Container Insights ペインの下と Application Insights セクションの上に表示されます。これらのイベントに対して追加の分析を実行し、追加のビジュアライゼーションを作成するには、ライフサイクルイベントテーブルで **[View in Logs Insights]** (Logs Insights で表示) を選択します。
# Container Insights のトラブルシューティング
以下のセクションは、Container Insights で問題が発生している場合に役立ちます。
## Amazon EKS または Kubernetes でのデプロイに失敗しました
エージェントが Kubernetes クラスターに正しくデプロイされない場合は、以下を試してください。
+ 次のコマンドを実行して、ポッドのリストを取得します。
```
kubectl get pods -n amazon-cloudwatch
```
+ 次のコマンドを実行して、出力の下部にあるイベントを確認します。
```
kubectl describe pod pod-name -n amazon-cloudwatch
```
+ 次のコマンドを実行して、ログを確認します。
```
kubectl logs pod-name -n amazon-cloudwatch
```
## 無許可パニック: kubelet から cadvisor データを取得できない
デプロイがエラー `Unauthorized panic: Cannot retrieve cadvisor data from kubelet` で失敗する場合は、kubelet で Webhook 認可モードが有効になっていない可能性があります。このモードでは、Container Insights に必要です。詳細については、「[CloudWatch での Container Insights の前提条件の検証](Container-Insights-prerequisites.md)」を参照してください。
## Amazon ECS 上の削除および再作成されたクラスターへの Container Insights のデプロイ
Container Insights が有効になっていない既存の Amazon ECS クラスターを削除し、同じ名前で再作成した場合、再作成時にこの新しいクラスターで Container Insights を有効にすることはできません。再作成して有効にするには、次のコマンドを入力します。
```
aws ecs update-cluster-settings --cluster myCICluster --settings name=container Insights,value=enabled
```
## 無効なエンドポイントエラー
次のようなエラーメッセージが表示された場合は、使用しているコマンドの *cluster-name* や *region-name* などのすべてのプレースホルダを、デプロイ用の正しい情報に置き換えていることを確認します。
```
"log": "2020-04-02T08:36:16Z E! cloudwatchlogs: code: InvalidEndpointURL, message: invalid endpoint uri, original error: &url.Error{Op:\"parse\", URL:\"https://logs.{{region_name}}.amazonaws.com/\", Err:\"{\"}, &awserr.baseError{code:\"InvalidEndpointURL\", message:\"invalid endpoint uri\", errs:[]error{(*url.Error)(0xc0008723c0)}}\n",
```
## メトリクスがコンソールに表示されない
AWS マネジメントコンソール に Container Insights メトリクスが表示されない場合は、Container Insights のセットアップが完了していることを確認します。メトリクスは、Container Insights が完全にセットアップされるまで表示されません。詳細については、「[Container Insights の設定](deploy-container-insights.md)」を参照してください。
## クラスターのアップグレード後に Amazon EKS または Kubernetes でポッドメトリクスが欠けている
このセクションは、CloudWatch エージェントをデーモンセットとして新規クラスターまたはアップグレードされたクラスターにデプロイした後に、すべてまたは一部のポッドメトリクスが欠けている場合、またはメッセージ `W! No pod metric collected` のエラーログが表示される場合に役に立ちます。
これらのエラーは、containerd や docker systemd cgroup ドライバーなどのコンテナランタイムの変更によって引き起こされる可能性があります。通常は、デプロイマニフェストを更新して、ホストからの containerd ソケットがコンテナにマウントされるようにすることで、解決できます。次の例を参照してください。
```
# For full example see https://github.com/aws-samples/amazon-cloudwatch-container-insights/blob/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: cloudwatch-agent
namespace: amazon-cloudwatch
spec:
template:
spec:
containers:
- name: cloudwatch-agent
# ...
# Don't change the mountPath
volumeMounts:
# ...
- name: dockersock
mountPath: /var/run/docker.sock
readOnly: true
- name: varlibdocker
mountPath: /var/lib/docker
readOnly: true
- name: containerdsock # NEW mount
mountPath: /run/containerd/containerd.sock
readOnly: true
# ...
volumes:
# ...
- name: dockersock
hostPath:
path: /var/run/docker.sock
- name: varlibdocker
hostPath:
path: /var/lib/docker
- name: containerdsock # NEW volume
hostPath:
path: /run/containerd/containerd.sock
```
## Amazon EKS で Bottlerocket を使用する場合、ポッドメトリクスがない
Bottlerocket は Linux ベースのオープンソースのオペレーティングシステムで、コンテナを実行するために AWS によって専用に構築されています。
Bottlerocket はホスト上で異なる `containerd` パスを使用するため、ボリュームをその場所に変更する必要があります。変更しないと、`W! No pod metric collected` を含むログにエラーが表示されます。次の例を参照してください。
```
volumes:
# ...
- name: containerdsock
hostPath:
# path: /run/containerd/containerd.sock
# bottlerocket does not mount containerd sock at normal place
# https://github.com/bottlerocket-os/bottlerocket/commit/91810c85b83ff4c3660b496e243ef8b55df0973b
path: /run/dockershim.sock
```
## Amazon EKS または Kubernetes で containerd ランタイムを使用する場合、コンテナファイルシステムのメトリクスがない
これは既知の問題であり、コミュニティの貢献者が取り組んでいます。詳細については、[containerd のディスク使用量メトリクス](https://github.com/google/cadvisor/issues/2785)と[コンテナファイルシステムのメトリクスは、GitHub の containerd 用 cadvisor ではサポートされていません](https://github.com/aws/amazon-cloudwatch-agent/issues/192)を参照してください。
## Prometheus メトリクスを収集するときに CloudWatch エージェントから予期しないログボリュームが増える
これは、CloudWatch エージェントのバージョン 1.247347.6b250880 で導入された回帰です。この回帰は、より新しいバージョンのエージェントで既に修正されています。この影響は、お客様が CloudWatch エージェント自体のログを収集し、Prometheus を使用しているシナリオに限定されていました。詳細については、[[prometheus] エージェントが GitHub のログにスクレイプされたメトリクスをすべて出力している](https://github.com/aws/amazon-cloudwatch-agent/issues/209)を参照してください。
## リリースノートに記載されている最新の Docker イメージが Dockerhub から見つからない
実際のリリースを内部的に開始する前に、Github でリリースノートとタグを更新します。Github でバージョン番号を上げてから、レジストリで最新の Docker イメージが表示されるまで、通常 1～2 週間かかります。CloudWatch エージェントコンテナイメージは夜間にリリースされません。次の場所 ([https://github.com/aws/amazon-cloudwatch-agent/tree/main/amazon-cloudwatch-container-insights/cloudwatch-agent-dockerfile](https://github.com/aws/amazon-cloudwatch-agent/tree/main/amazon-cloudwatch-container-insights/cloudwatch-agent-dockerfile)) にあるソースから直接イメージを作成できます。
## CloudWatch エージェントの CrashLoopBackoff エラー
CloudWatch エージェントの `CrashLoopBackOff` のエラーが表示された場合は、IAM アクセス許可が正しく設定されていることを確認してください。詳細については、「[CloudWatch での Container Insights の前提条件の検証](Container-Insights-prerequisites.md)」を参照してください。
## CloudWatch エージェントまたは Fluentd ポッドが保留状態でスタックする
CloudWatch エージェントまたは Fluentd ポッドが `Pending` 状態でスタックしている場合、または、`FailedScheduling` エラーでスタックしている場合は、エージェントに必要なコア数と RAM の量に基づいて、ノードに十分なコンピューティングリソースがあるかどうかを確認します。以下のコマンドを使用して、ポッドを記述します。
```
kubectl describe pod cloudwatch-agent-85ppg -n amazon-cloudwatch
```
# 独自の CloudWatch エージェント Docker イメージの構築
[https://github.com/aws-samples/amazon-cloudwatch-container-insights/blob/latest/cloudwatch-agent-dockerfile/Dockerfile](https://github.com/aws-samples/amazon-cloudwatch-container-insights/blob/latest/cloudwatch-agent-dockerfile/Dockerfile) にある Dockerfile を参照することで、独自の CloudWatch エージェント Docker イメージを構築できます。
Dockerfile では、`docker buildx` を使用して直接マルチアーキテクチャイメージの作成をサポートしています。
# コンテナへの他の CloudWatch エージェント機能のデプロイ
CloudWatch エージェントを使用して、コンテナに追加のモニターリング機能をデプロイできます。主な機能は以下のとおりです。
+ **埋め込みメトリクス形式** – 詳細については、「[ログ内へのメトリクスの埋め込み](CloudWatch_Embedded_Metric_Format.md)」を参照してください。
+ **StatsD** – 詳細については、「[StatsD を使用してカスタムメトリクスを取得する](CloudWatch-Agent-custom-metrics-statsd.md)」を参照してください。
手順と必要なファイルは、GitHub の次の場所にあります。
+ Amazon ECS コンテナについては、「[Example Amazon ECS task definitions based on deployment modes](https://github.com/aws-samples/amazon-cloudwatch-container-insights/tree/latest/ecs-task-definition-templates/deployment-mode)」を参照してください。
+ Amazon EKS および Kubernetes コンテナについては、「[Example Kubernetes YAML files based on deployment modes](https://github.com/aws-samples/amazon-cloudwatch-container-insights/tree/latest/k8s-deployment-manifest-templates/deployment-mode)」を参照してください。