# インフラストラクチャのモニタリング
このセクションのトピックでは、AWS リソースに関するオペレーションの可視性を高めるのに役立つ CloudWatch の機能について説明します。
**Topics**
+ [
# Container Insights
](ContainerInsights.md)
+ [
# Lambda Insights
](Lambda-Insights.md)
+ [
# CloudWatch Database Insights
](Database-Insights.md)
+ [
# Contributor Insights を使用して高カーディナリティデータを分析する
](ContributorInsights.md)
+ [
# CloudWatch Application Insights を使用したアプリケーションの一般的な問題の検出
](cloudwatch-application-insights.md)
+ [
# CloudWatch コンソールのリソースのヘルスビューの使用
](servicelens_resource_health.md)
# 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)」を参照してください。
# Lambda Insights
CloudWatch Lambda Insights は、AWS Lambda で実行されているサーバーレスアプリケーション用のモニタリングおよびトラブルシューティングソリューションです。このソリューションでは、CPU 時間、メモリ、ディスク、ネットワークなどのシステムレベルのメトリクスが収集、集約、要約されます。また、コールドスタートや Lambda ワーカーシャットダウンなどの診断情報が収集、集約、要約されるため、Lambda 関数に関する問題を特定し、迅速に解決できます。
Lambda Insights は、Lambda レイヤーとして提供される新しい CloudWatch Lambda 拡張機能を使用します。この拡張機能を Lambda 関数にインストールすると、システムレベルのメトリクスを収集し、その Lambda 関数の呼び出しごとに 1 つのパフォーマンスログイベントが発生します。CloudWatch は、埋め込みメトリクスフォーマットを使用して、ログイベントからメトリクスを抽出します。
**注記**
Lambda Insights エージェントは、Amazon Linux 2 および Amazon Linux 2023 を使用する Lambda ランタイムでのみサポートされます。
Lambda 拡張機能の詳細については、「[AWS Lambda 拡張機能を使用する](https://docs.aws.amazon.com/lambda/latest/dg/using-extensions.html)」を参照してください。埋め込みメトリックフォーマットの詳細については、「[ログ内へのメトリクスの埋め込み](CloudWatch_Embedded_Metric_Format.md)」を参照してください。
Lambda Insights は、Lambda 拡張機能をサポートする Lambda ランタイムを使用する任意の Lambda 関数で使用できます。これらのランタイムの一覧については、「[Lambda 拡張機能 API](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html)」を参照してください。
**料金**
Lambda Insights に対して有効になっている各 Lambda 関数の料金は、メトリクスとログに使用した分に対してのみ発生します。料金の例については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」を参照してください。
料金は、Lambda 拡張機能の実行時間 (1 ミリ秒単位) に対して課金されます。Lambda の料金の詳細については、「[AWS Lambda の料金](https://aws.amazon.com/lambda/pricing/)」を参照してください。
# Lambda Insights の使用を開始する
Lambda 関数で Lambda Insights を有効にするには、Lambda コンソールでワンクリックトグルを使用できます。または、AWS CLI、CloudFormation、AWS Serverless Application Model CLI、または AWS Cloud Development Kit (AWS CDK)を使用できます。
以下のセクションでは、これらのステップを完了するための詳細な手順について説明します。
**Topics**
+ [
# Lambda Insights 拡張機能の利用可能なバージョン
](Lambda-Insights-extension-versions.md)
+ [
# コンソールを使用して既存の Lambda 関数で Lambda Insights を有効にする
](Lambda-Insights-Getting-Started-console.md)
+ [
# 既存の Lambda 関数で Lambda Insights を有効にするために AWS CLI を使用する
](Lambda-Insights-Getting-Started-cli.md)
+ [
# 既存の Lambda 関数で Lambda Insights を有効にするために AWS SAM CLI を使用する
](Lambda-Insights-Getting-Started-SAM-CLI.md)
+ [
# 既存の Lambda 関数で Lambda Insights を有効にするために CloudFormation を使用する
](Lambda-Insights-Getting-Started-cloudformation.md)
+ [
# 既存の Lambda 関数で Lambda Insights を有効にするために AWS CDK を使用する
](Lambda-Insights-Getting-Started-clouddevelopmentkit.md)
+ [
# Serverless Framework を使用して、既存の Lambda 関数で Lambda Insights を有効にする
](Lambda-Insights-Getting-Started-serverless.md)
+ [
# Lambda コンテナイメージをデプロイして Lambda Insights を有効化する
](Lambda-Insights-Getting-Started-docker.md)
+ [
# 関数の Lambda Insights 拡張機能バージョンを更新する
](Lambda-Insights-Update-Extension.md)
# Lambda Insights 拡張機能の利用可能なバージョン
このセクションでは、Lambda Insights 拡張機能のバージョンと、各 AWS リージョンでこれらの拡張機能に使用する ARN の一覧を示します。
**Topics**
+ [
# x86-64 プラットフォーム
](Lambda-Insights-extension-versionsx86-64.md)
+ [
# ARM64 プラットフォーム
](Lambda-Insights-extension-versionsARM.md)
# x86-64 プラットフォーム
このセクションでは、x86-64 プラットフォーム向け Lambda Insights 拡張機能のバージョンと、これらの拡張機能が各 AWS リージョンで使用する ARN の一覧を示します。
**重要**
Lambda Insights の拡張機能、1.0.317.0 以降は、Amazon Linux 1 をサポートしていません。
## 1.0.660.0
バージョン 1.0.660.0 には、Lambda マネージドインスタンスで実行されている Lambda 関数に対する Lambda Insights 拡張機能のサポートが含まれています。Lambda マネージドインスタンスで実行されている関数の場合、拡張機能は EMF ログイベントを 1 分に 1 回送信し、1 分単位で 12 個の CloudWatch メトリクスを作成します。
**バージョン 1.0.660.0 の ARN**
次の表に、利用可能な各 AWS リージョンでこのバージョンの拡張機能で使用する ARN の一覧を示します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:64` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension:64` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:64` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension:64` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension:56` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension:56` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension:38` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension:40` |
| アジアパシフィック (マレーシア) | `arn:aws:lambda:ap-southeast-5:590183865173:layer:LambdaInsightsExtension:13` |
| アジアパシフィック (メルボルン) | `arn:aws:lambda:ap-southeast-4:158895979263:layer:LambdaInsightsExtension:33` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:62` |
| アジアパシフィック (ニュージーランド) | `arn:aws:lambda:ap-southeast-6:727646510379:layer:LambdaInsightsExtension:6` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension:45` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension:63` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension:64` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension:64` |
| アジアパシフィック (台北) | `arn:aws:lambda:ap-east-2:145023102084:layer:LambdaInsightsExtension:13` |
| アジアパシフィック (タイ) | `arn:aws:lambda:ap-southeast-7:761018874580:layer:LambdaInsightsExtension:13` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension:91` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension:63` |
| カナダ西部 (カルガリー) | `arn:aws:lambda:ca-west-1:946466191631:layer:LambdaInsightsExtension:25` |
| 中国 (北京) | `arn:aws-cn:lambda:cn-north-1:488211338238:layer:LambdaInsightsExtension:51` |
| 中国 (寧夏) | `arn:aws-cn:lambda:cn-northwest-1:488211338238:layer:LambdaInsightsExtension:51` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension:64` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:64` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension:64` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension:56` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension:63` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension:40` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension:61` |
| 欧州 (チューリッヒ) | `arn:aws:lambda:eu-central-2:033019950311:layer:LambdaInsightsExtension:39` |
| イスラエル (テルアビブ) | `arn:aws:lambda:il-central-1:459530977127:layer:LambdaInsightsExtension:33` |
| メキシコ (中部) | `arn:aws:lambda:mx-central-1:879381266642:layer:LambdaInsightsExtension:13` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension:56` |
| 中東 (UAE) | `arn:aws:lambda:me-central-1:732604637566:layer:LambdaInsightsExtension:39` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension:63` |
| AWS GovCloud (米国東部) | `arn:aws-us-gov:lambda:us-gov-east-1:122132214140:layer:LambdaInsightsExtension:24` |
| AWS GovCloud (米国西部) | `arn:aws-us-gov:lambda:us-gov-west-1:751350123760:layer:LambdaInsightsExtension:24` |
## 1.0.498.0
バージョン 1.0.498.0 には、バグ修正とパフォーマンスの向上が含まれています。
**バージョン 1.0.498.0 の ARN**
次の表に、利用可能な各 AWS リージョンでこのバージョンの拡張機能で使用する ARN の一覧を示します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:60` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension:60` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:60` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension:60` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension:52` |
| アジアパシフィック (タイ) | `arn:aws:lambda:ap-southeast-7:761018874580:layer:LambdaInsightsExtension:8` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension:52` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension:34` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension:36` |
| アジアパシフィック (マレーシア) | `arn:aws:lambda:ap-southeast-5:590183865173:layer:LambdaInsightsExtension:9` |
| アジアパシフィック (メルボルン) | `arn:aws:lambda:ap-southeast-4:158895979263:layer:LambdaInsightsExtension:29` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:58` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension:41` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension:59` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension:60` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension:60` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension:87` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension:59` |
| カナダ西部 (カルガリー) | `arn:aws:lambda:ca-west-1:946466191631:layer:LambdaInsightsExtension:21` |
| 中国 (北京) | `arn:aws-cn:lambda:cn-north-1:488211338238:layer:LambdaInsightsExtension:48` |
| 中国 (寧夏) | `arn:aws-cn:lambda:cn-northwest-1:488211338238:layer:LambdaInsightsExtension:48` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension:60` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:60` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension:60` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension:52` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension:59` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension:36` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension:57` |
| 欧州 (チューリッヒ) | `arn:aws:lambda:eu-central-2:033019950311:layer:LambdaInsightsExtension:35` |
| イスラエル (テルアビブ) | `arn:aws:lambda:il-central-1:459530977127:layer:LambdaInsightsExtension:29` |
| メキシコ (中部) | `arn:aws:lambda:mx-central-1:879381266642:layer:LambdaInsightsExtension:8` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension:52` |
| 中東 (UAE) | `arn:aws:lambda:me-central-1:732604637566:layer:LambdaInsightsExtension:35` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension:59` |
| AWS GovCloud (米国東部) | `arn:aws-us-gov:lambda:us-gov-east-1:122132214140:layer:LambdaInsightsExtension:24` |
| AWS GovCloud (米国西部) | `arn:aws-us-gov:lambda:us-gov-west-1:751350123760:layer:LambdaInsightsExtension:24` |
| アジアパシフィック (ニュージーランド) | `arn:aws:lambda:ap-southeast-6:727646510379:layer:LambdaInsightsExtension:1` |
| アジアパシフィック (台北) | `arn:aws:lambda:ap-east-2:145023102084:layer:LambdaInsightsExtension:8` |
## 1.0.404.0
バージョン 1.0.404.0 では、Lambda Insights 拡張機能のバイナリサイズが約 10 MB から約 6 MB に縮小され、それに続いて Lambda Insights 拡張機能レイヤーの zip サイズが約 4 MB から約 2.7 MB に縮小されています。また、エージェントの全体的なメモリ消費量が約 10 MB から約 7 MB に削減されます。
**バージョン 1.0.404.0 の ARN**
次の表に、利用可能な各 AWS リージョンでこのバージョンの拡張機能で使用する ARN の一覧を示します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:56` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension:56` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:56` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension:56` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension:47` |
| アジアパシフィック (タイ) | `arn:aws:lambda:ap-southeast-7:761018874580:layer:LambdaInsightsExtension:3` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension:47` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension:29` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension:33` |
| アジアパシフィック (マレーシア) | `arn:aws:lambda:ap-southeast-5:590183865173:layer:LambdaInsightsExtension:4` |
| アジアパシフィック (メルボルン) | `arn:aws:lambda:ap-southeast-4:158895979263:layer:LambdaInsightsExtension:24` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:54` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension:37` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension:55` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension:56` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension:56` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension:83` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension:55` |
| カナダ西部 (カルガリー) | `arn:aws:lambda:ca-west-1:946466191631:layer:LambdaInsightsExtension:16` |
| 中国 (北京) | `arn:aws-cn:lambda:cn-north-1:488211338238:layer:LambdaInsightsExtension:46` |
| 中国 (寧夏) | `arn:aws-cn:lambda:cn-northwest-1:488211338238:layer:LambdaInsightsExtension:46` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension:56` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:56` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension:56` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension:47` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension:55` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension:31` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension:53` |
| 欧州 (チューリッヒ) | `arn:aws:lambda:eu-central-2:033019950311:layer:LambdaInsightsExtension:30` |
| イスラエル (テルアビブ) | `arn:aws:lambda:il-central-1:459530977127:layer:LambdaInsightsExtension:23` |
| メキシコ (中部) | `arn:aws:lambda:mx-central-1:879381266642:layer:LambdaInsightsExtension:3` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension:47` |
| 中東 (UAE) | `arn:aws:lambda:me-central-1:732604637566:layer:LambdaInsightsExtension:30` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension:55` |
| AWS GovCloud (米国東部) | `arn:aws-us-gov:lambda:us-gov-east-1:122132214140:layer:LambdaInsightsExtension:24` |
| AWS GovCloud (米国西部) | `arn:aws-us-gov:lambda:us-gov-west-1:751350123760:layer:LambdaInsightsExtension:24` |
## 1.0.391.0
**重要**
バージョン 1.0.391.0 では、Lambda Insights がスレッドの使用状況を収集してレポートする方法が変更されています。以前のバージョンの 拡張機能では、 `threads_max` メトリクスは、プロセス ID が 1 のプロセスで実行されているスレッドの最大数を報告しました。バージョン 1.0.391.0 以降の場合、このメトリクスは、実行環境内のすべてのプロセスで、関数の実行中に任意の時点で実行されていたスレッドの最大数を報告します。これには、Lambda 関数のプロセス、拡張機能のプロセス、システム/ランタイム固有のプロセスなどが含まれます。これにより、`threads_max` メトリクスは、ユーザーが利用できる残りのスレッド数を評価する上で、より包括的なものになります。スレッドクォータとプロセスクォータの詳細については、「[Lambda クォータ](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)」を参照してください。
バージョン 1.0.391.0 は、アジアパシフィック (タイ) およびメキシコ (中部) リージョンでも利用可能になりました。
**バージョン 1.0.391.0 の ARN**
次の表に、利用可能な各 AWS リージョンでこのバージョンの拡張機能で使用する ARN の一覧を示します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:55` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension:55` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:55` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension:55` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension:46` |
| アジアパシフィック (タイ) | `arn:aws:lambda:ap-southeast-7:761018874580:layer:LambdaInsightsExtension:2` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension:46` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension:28` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension:32` |
| アジアパシフィック (マレーシア) | `arn:aws:lambda:ap-southeast-5:590183865173:layer:LambdaInsightsExtension:3` |
| アジアパシフィック (メルボルン) | `arn:aws:lambda:ap-southeast-4:158895979263:layer:LambdaInsightsExtension:23` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:53` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension:36` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension:54` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension:55` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension:55` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension:82` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension:54` |
| カナダ西部 (カルガリー) | `arn:aws:lambda:ca-west-1:946466191631:layer:LambdaInsightsExtension:15` |
| 中国 (北京) | `arn:aws-cn:lambda:cn-north-1:488211338238:layer:LambdaInsightsExtension:45` |
| 中国 (寧夏) | `arn:aws-cn:lambda:cn-northwest-1:488211338238:layer:LambdaInsightsExtension:45` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension:55` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:55` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension:55` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension:46` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension:54` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension:30` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension:52` |
| 欧州 (チューリッヒ) | `arn:aws:lambda:eu-central-2:033019950311:layer:LambdaInsightsExtension:29` |
| イスラエル (テルアビブ) | `arn:aws:lambda:il-central-1:459530977127:layer:LambdaInsightsExtension:23` |
| メキシコ (中部) | `arn:aws:lambda:mx-central-1:879381266642:layer:LambdaInsightsExtension:2` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension:46` |
| 中東 (UAE) | `arn:aws:lambda:me-central-1:732604637566:layer:LambdaInsightsExtension:29` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension:54` |
| AWS GovCloud (米国東部) | `arn:aws-us-gov:lambda:us-gov-east-1:122132214140:layer:LambdaInsightsExtension:23` |
| AWS GovCloud (米国西部) | `arn:aws-us-gov:lambda:us-gov-west-1:751350123760:layer:LambdaInsightsExtension:23` |
## 1.0.333.0
バージョン 1.0.333.0 にはバグ修正が含まれています。
**バージョン 1.0.333.0 の ARN**
次の表に、利用可能な各 AWS リージョンでこのバージョンの拡張機能で使用する ARN の一覧を示します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:53` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension:53` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:53` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension:53` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension:44` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension:44` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension:26` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension:30` |
| アジアパシフィック (マレーシア) | `arn:aws:lambda:ap-southeast-5:590183865173:layer:LambdaInsightsExtension:1` |
| アジアパシフィック (メルボルン) | `arn:aws:lambda:ap-southeast-4:158895979263:layer:LambdaInsightsExtension:21` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:51` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension:34` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension:52` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension:53` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension:53` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension:80` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension:52` |
| カナダ西部 (カルガリー) | `arn:aws:lambda:ca-west-1:946466191631:layer:LambdaInsightsExtension:13` |
| 中国 (北京) | `arn:aws-cn:lambda:cn-north-1:488211338238:layer:LambdaInsightsExtension:43` |
| 中国 (寧夏) | `arn:aws-cn:lambda:cn-northwest-1:488211338238:layer:LambdaInsightsExtension:43` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension:53` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:53` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension:53` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension:44` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension:52` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension:28` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension:50` |
| 欧州 (チューリッヒ) | `arn:aws:lambda:eu-central-2:033019950311:layer:LambdaInsightsExtension:27` |
| イスラエル (テルアビブ) | `arn:aws:lambda:il-central-1:459530977127:layer:LambdaInsightsExtension:21` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension:44` |
| 中東 (UAE) | `arn:aws:lambda:me-central-1:732604637566:layer:LambdaInsightsExtension:27` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension:52` |
| AWS GovCloud (米国東部) | `arn:aws-us-gov:lambda:us-gov-east-1:122132214140:layer:LambdaInsightsExtension:21` |
| AWS GovCloud (米国西部) | `arn:aws-us-gov:lambda:us-gov-west-1:751350123760:layer:LambdaInsightsExtension:21` |
## 1.0.317.0
バージョン 1.0.317.0 には、Amazon Linux 1 プラットフォームのサポートの削除とバグ修正が含まれています。AWS GovCloud (US) リージョンのサポートも含まれています。
**バージョン 1.0.317.0 の ARN**
次の表に、利用可能な各 AWS リージョンでこのバージョンの拡張機能で使用する ARN の一覧を示します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:52` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension:52` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:52` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension:52` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension:43` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension:43` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension:25` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension:29` |
| アジアパシフィック (メルボルン) | `arn:aws:lambda:ap-southeast-4:158895979263:layer:LambdaInsightsExtension:20` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:50` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension:33` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension:51` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension:52` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension:52` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension:79` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension:51` |
| カナダ西部 (カルガリー) | `arn:aws:lambda:ca-west-1:946466191631:layer:LambdaInsightsExtension:12` |
| 中国 (北京) | `arn:aws-cn:lambda:cn-north-1:488211338238:layer:LambdaInsightsExtension:42` |
| 中国 (寧夏) | `arn:aws-cn:lambda:cn-northwest-1:488211338238:layer:LambdaInsightsExtension:42` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension:52` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:52` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension:52` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension:43` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension:51` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension:27` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension:49` |
| 欧州 (チューリッヒ) | `arn:aws:lambda:eu-central-2:033019950311:layer:LambdaInsightsExtension:26` |
| イスラエル (テルアビブ) | `arn:aws:lambda:il-central-1:459530977127:layer:LambdaInsightsExtension:20` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension:43` |
| 中東 (UAE) | `arn:aws:lambda:me-central-1:732604637566:layer:LambdaInsightsExtension:26` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension:51` |
| AWS GovCloud (米国東部) | `arn:aws-us-gov:lambda:us-gov-east-1:122132214140:layer:LambdaInsightsExtension:19` |
| AWS GovCloud (米国西部) | `arn:aws-us-gov:lambda:us-gov-west-1:751350123760:layer:LambdaInsightsExtension:19` |
## 1.0.295.0
バージョン 1.0.295.0 には、互換性のあるすべてのランタイム用の依存関係の更新が含まれています。
**バージョン 1.0.295.0 の ARN**
次の表に、利用可能な各 AWS リージョンでこのバージョンの拡張機能で使用する ARN の一覧を示します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:51` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension:51` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:51` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension:51` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension:42` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension:42` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension:24` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension:28` |
| アジアパシフィック (メルボルン) | `arn:aws:lambda:ap-southeast-4:158895979263:layer:LambdaInsightsExtension:19` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:49` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension:32` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension:50` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension:51` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension:51` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension:78` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension:50` |
| カナダ西部 (カルガリー) | `arn:aws:lambda:ca-west-1:946466191631:layer:LambdaInsightsExtension:11` |
| 中国 (北京) | `arn:aws-cn:lambda:cn-north-1:488211338238:layer:LambdaInsightsExtension:41` |
| 中国 (寧夏) | `arn:aws-cn:lambda:cn-northwest-1:488211338238:layer:LambdaInsightsExtension:41` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension:51` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:51` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension:51` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension:42` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension:50` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension:26` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension:48` |
| 欧州 (チューリッヒ) | `arn:aws:lambda:eu-central-2:033019950311:layer:LambdaInsightsExtension:25` |
| イスラエル (テルアビブ) | `arn:aws:lambda:il-central-1:459530977127:layer:LambdaInsightsExtension:19` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension:42` |
| 中東 (UAE) | `arn:aws:lambda:me-central-1:732604637566:layer:LambdaInsightsExtension:25` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension:50` |
## 1.0.275.0
バージョン 1.0.275.0 には、互換性のあるすべてのランタイム用の重要な依存関係の更新が含まれています。
**バージョン 1.0.275.0 の ARN**
次の表に、利用可能な各 AWS リージョンでこのバージョンの拡張機能で使用する ARN の一覧を示します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:49` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension:49` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:49` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension:49` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension:40` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension:40` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension:22` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension:26` |
| アジアパシフィック (メルボルン) | `arn:aws:lambda:ap-southeast-4:158895979263:layer:LambdaInsightsExtension:17` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:47` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension:30` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension:48` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension:49` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension:49` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension:76` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension:48` |
| カナダ西部 (カルガリー) | `arn:aws:lambda:ca-west-1:946466191631:layer:LambdaInsightsExtension:9` |
| 中国 (北京) | `arn:aws-cn:lambda:cn-north-1:488211338238:layer:LambdaInsightsExtension:39` |
| 中国 (寧夏) | `arn:aws-cn:lambda:cn-northwest-1:488211338238:layer:LambdaInsightsExtension:39` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension:49` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:49` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension:49` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension:40` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension:48` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension:24` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension:46` |
| 欧州 (チューリッヒ) | `arn:aws:lambda:eu-central-2:033019950311:layer:LambdaInsightsExtension:23` |
| イスラエル (テルアビブ) | `arn:aws:lambda:il-central-1:459530977127:layer:LambdaInsightsExtension:17` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension:40` |
| 中東 (UAE) | `arn:aws:lambda:me-central-1:732604637566:layer:LambdaInsightsExtension:23` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension:48` |
## 1.0.273.0
バージョン 1.0.273.0 では、互換性のあるすべてのランタイムに対して重要なバグ修正を行っているほか、カナダ西部 (カルガリー) リージョンのサポートを追加しています。
**バージョン 1.0.273.0 の ARN**
次の表に、利用可能な各 AWS リージョンでこのバージョンの拡張機能で使用する ARN の一覧を示します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:45` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension:45` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:45` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension:45` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension:35` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension:35` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension:17` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension:21` |
| アジアパシフィック (メルボルン) | `arn:aws:lambda:ap-southeast-4:158895979263:layer:LambdaInsightsExtension:12` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:43` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension:26` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension:44` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension:45` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension:45` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension:72` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension:44` |
| カナダ西部 (カルガリー) | `arn:aws:lambda:ca-west-1:946466191631:layer:LambdaInsightsExtension:4` |
| 中国 (北京) | `arn:aws-cn:lambda:cn-north-1:488211338238:layer:LambdaInsightsExtension:36` |
| 中国 (寧夏) | `arn:aws-cn:lambda:cn-northwest-1:488211338238:layer:LambdaInsightsExtension:36` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension:45` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:45` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension:45` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension:35` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension:44` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension:19` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension:42` |
| 欧州 (チューリッヒ) | `arn:aws:lambda:eu-central-2:033019950311:layer:LambdaInsightsExtension:17` |
| イスラエル (テルアビブ) | `arn:aws:lambda:il-central-1:459530977127:layer:LambdaInsightsExtension:12` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension:35` |
| 中東 (UAE) | `arn:aws:lambda:me-central-1:732604637566:layer:LambdaInsightsExtension:18` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension:44` |
## 1.0.229.0
バージョン 1.0.229.0 では、互換性のあるすべてのランタイムに対して重要なバグ修正を行っているほか、イスラエル (テルアビブ) リージョンのサポートを追加しています。
**バージョン 1.0.229.0 の ARN**
次の表に、利用可能な各 AWS リージョンでこのバージョンの拡張機能で使用する ARN の一覧を示します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:38` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension:38` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:38` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension:38` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension:28` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension:28` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension:10` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension:14` |
| アジアパシフィック (メルボルン) | `arn:aws:lambda:ap-southeast-4:158895979263:layer:LambdaInsightsExtension:5` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:36` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension:19` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension:37` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension:38` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension:38` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension:60` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension:37` |
| 中国 (北京) | `arn:aws-cn:lambda:cn-north-1:488211338238:layer:LambdaInsightsExtension:29` |
| 中国 (寧夏) | `arn:aws-cn:lambda:cn-northwest-1:488211338238:layer:LambdaInsightsExtension:29` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension:38` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:38` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension:38` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension:28` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension:37` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension:12` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension:35` |
| 欧州 (チューリッヒ) | `arn:aws:lambda:eu-central-2:033019950311:layer:LambdaInsightsExtension:11` |
| イスラエル (テルアビブ) | `arn:aws:lambda:il-central-1:459530977127:layer:LambdaInsightsExtension:5` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension:28` |
| 中東 (UAE) | `arn:aws:lambda:me-central-1:732604637566:layer:LambdaInsightsExtension:11` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension:37` |
## 1.0.178.0
バージョン 1.0.178.0 では、以下の AWS リージョンのサポートが追加されています。
+ アジアパシフィック (ハイデラバード)
+ アジアパシフィック (ジャカルタ)
+ 欧州 (スペイン)
+ 欧州 (チューリッヒ)
+ 中東 (UAE)
**バージョン 1.0.178.0 の ARN**
次の表に、利用可能な各 AWS リージョンでこのバージョンの拡張機能で使用する ARN の一覧を示します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:35` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension:33` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:33` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension:33` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension:25` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension:25` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension:8` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension:11` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:31` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension:2` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension:32` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension:33` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension:33` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension:50` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension:32` |
| 中国 (北京) | `arn:aws-cn:lambda:cn-north-1:488211338238:layer:LambdaInsightsExtension:26` |
| 中国 (寧夏) | `arn:aws-cn:lambda:cn-northwest-1:488211338238:layer:LambdaInsightsExtension:26` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension:35` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:33` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension:33` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension:25` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension:32` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension:10` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension:30` |
| 欧州 (チューリッヒ) | `arn:aws:lambda:eu-central-2:033019950311:layer:LambdaInsightsExtension:7` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension:25` |
| 中東 (UAE) | `arn:aws:lambda:me-central-1:732604637566:layer:LambdaInsightsExtension:9` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension:32` |
## 1.0.143.0
バージョン 1.0.143.0 には、Python 3.7 および Go 1.x との互換性に関するバグ修正が含まれています。Python 3.6 Lambda ランタイムは廃止されています。詳細については、「[Lambda runtimes](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html)」 (Lambda ランタイム) を参照してください。
**バージョン 1.0.143.0 の ARN**
次の表に、利用可能な各 AWS リージョンでこのバージョンの拡張機能で使用する ARN の一覧を示します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:21` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension:21` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:20` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension:21` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension:13` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension:13` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:21` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension:2` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension:20` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension:21` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension:21` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension:32` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension:20` |
| 中国 (北京) | `arn:aws-cn:lambda:cn-north-1:488211338238:layer:LambdaInsightsExtension:14` |
| 中国 (寧夏) | `arn:aws-cn:lambda:cn-northwest-1:488211338238:layer:LambdaInsightsExtension:14` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension:21` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:21` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension:21` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension:13` |
| ヨーロッパ (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension:20` |
| ヨーロッパ (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension:20` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension:13` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension:20` |
## 1.0.135.0
バージョン 1.0.135.0 には、Lambda Insights でのディスクとファイル記述子の使用量の収集とレポートの方法に関するバグ修正が含まれています。拡張機能の以前のバージョンでは、関数を実行中の `/tmp` ディレクトリの最大空き領域は `tmp_free` メトリクスによって報告されていました。このバージョンでは、代わりに最小値をレポートするようにメトリクスが変更されており、ディスク使用量を評価する上でさらに便利になっています。`tmp` ディレクトリのストレージクォータの詳細については、[Lambda クォータ](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)を参照してください。
また、バージョン 1.0.135.0 では、オペレーティングシステムレベルではなく、プロセス全体の最大値としてファイル記述子の使用量 (`fd_use` および `fd_max`) が報告されるようになりました。
**バージョン 1.0.135.0 の ARN**
次の表に、利用可能な各 AWS リージョンでこのバージョンの拡張機能で使用する ARN の一覧を示します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:18` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension:18` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:18` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension:18` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension:11` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension:11` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:18` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension:1` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension:18` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension:18` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension:18` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension:25` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension:18` |
| 中国 (北京) | `arn:aws-cn:lambda:cn-north-1:488211338238:layer:LambdaInsightsExtension:11` |
| 中国 (寧夏) | `arn:aws-cn:lambda:cn-northwest-1:488211338238:layer:LambdaInsightsExtension:11` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension:18` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:18` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension:18` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension:11` |
| ヨーロッパ (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension:18` |
| ヨーロッパ (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension:18` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension:11` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension:18` |
## 1.0.119.0
**バージョン 1.0.119.0 の ARN**
次の表に、利用可能な各 AWS リージョンでこのバージョンの拡張機能で使用する ARN の一覧を示します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:16` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension:16` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:16` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension:16` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension:9` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension:9` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:16` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension:16` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension:16` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension:16` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension:23` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension:16` |
| 中国 (北京) | `arn:aws-cn:lambda:cn-north-1:488211338238:layer:LambdaInsightsExtension:9` |
| 中国 (寧夏) | `arn:aws-cn:lambda:cn-northwest-1:488211338238:layer:LambdaInsightsExtension:9` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension:16` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:16` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension:16` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension:9` |
| ヨーロッパ (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension:16` |
| ヨーロッパ (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension:16` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension:9` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension:16` |
## 1.0.98.0
このバージョンでは、不要なログが削除され、AWS Serverless Application Model CLI ローカルコールの問題も解決されています。この問題の詳細については、「[Adding LambdaInsightsExtension results in timeout with 'sam local invoke'](https://github.com/aws/aws-sam-cli/issues/2469)」をご参照ください。
**バージョン 1.0.98.0 の ARN**
次の表に、利用可能な各 AWS リージョンでこのバージョンの拡張機能で使用する ARN の一覧を示します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:14` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension:14` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:14` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension:14` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension:8` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension:8` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:14` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension:14` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension:14` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension:14` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension:14` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension:14` |
| 中国 (北京) | `arn:aws-cn:lambda:cn-north-1:488211338238:layer:LambdaInsightsExtension:8` |
| 中国 (寧夏) | `arn:aws-cn:lambda:cn-northwest-1:488211338238:layer:LambdaInsightsExtension:8` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension:14` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:14` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension:14` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension:8` |
| ヨーロッパ (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension:14` |
| ヨーロッパ (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension:14` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension:8` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension:14` |
## 1.0.89.0
このバージョンでは、常に関数の呼び出しの開始を表すように、パフォーマンスイベントタイムスタンプが修正されます。
**バージョン 1.0.89.0 の ARN**
次の表に、利用可能な各 AWS リージョンでこのバージョンの拡張機能で使用する ARN の一覧を示します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:12` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension:12` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:12` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension:12` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:12` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension:12` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension:12` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension:12` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension:12` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension:12` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension:12` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:12` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension:12` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension:12` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension:12` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension:12` |
## 1.0.86.0
拡張機能のバージョン 1.0.54.0 では、メモリメトリクスが誤って報告され、100% より高くなることがありました。バージョン 1.0.86.0 では、Lambda プラットフォームメトリクスと同じイベントデータを使用して、メモリ測定の問題が修正されています。これは、記録されたメモリメトリクス値が劇的に変化することを意味します。これは、新しい Lambda Logs API を使用して実現されます。これにより、Lambda サンドボックスのメモリ使用量をより正確に測定できます。ただし、関数サンドボックスがタイムアウトし、その後スピンダウンされた場合、Lambda Logs API はプラットフォームレポートイベントを配信できないことに注意が必要です。この場合、Lambda Insights は呼び出しメトリクスを記録できません。Lambda Logs API の詳細については、「[AWS Lambda Logs API](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-logs-api.html)」を参照してください。
**バージョン 1.0.86.0 の新機能**
+ Lambda Logs API を使用してメモリメトリクスを修正します。これにより、メモリ統計が 100% を超えるという以前の問題が解決されました。
+ 新しい CloudWatch メトリクスとして `Init Duration` をご紹介します。
+ 呼び出し ARN を使用して、エイリアスおよび呼び出されたバージョンの**バージョン**ディメンションを追加します。Lambda エイリアスまたはバージョンを使用して増分デプロイ (グリーン/ブルーデプロイなど) を実現する場合は、呼び出されたエイリアスに基づいてメトリクスを表示できます。関数でエイリアスまたはバージョンを使用しない場合、**バージョン**ディメンションは適用されません。詳細については、「[Lambda 関数エイリアス](https://docs.aws.amazon.com/lambda/latest/dg/configuration-aliases.html)」を参照してください。
+ パフォーマンスイベントに `billed_mb_ms field` を追加し、呼び出しあたりのコストを表示します。これは、プロビジョニングされた同時実行に関連するコストを考慮しません。
+ パフォーマンスイベントに `billed_duration` および `duration` フィールドを追加します。
**バージョン 1.0.86.0 の ARN**
次の表に、利用可能な各 AWS リージョンでこのバージョンの拡張機能で使用する ARN の一覧を示します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:11` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension:11` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:11` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension:11` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:11` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension:11` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension:11` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension:11` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension:11` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension:11` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension:11` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:11` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension:11` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension:11` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension:11` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension:11` |
## 1.0.54.0
バージョン 1.0.54.0 は、Lambda Insights 拡張機能の初回リリースでした。
**バージョン 1.0.54.0 の ARN**
次の表に、利用可能な各 AWS リージョンでこのバージョンの拡張機能で使用する ARN の一覧を示します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:2` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension:2` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:2` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension:2` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:2` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension:2` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension:2` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension:2` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension:2` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension:2` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension:2` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:2` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension:2` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension:2` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension:2` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension:2` |
# ARM64 プラットフォーム
このセクションでは、ARM64 プラットフォーム向け Lambda Insights 拡張機能のバージョンと、これらの拡張機能が各 AWS リージョンで使用する ARN の一覧を示します。
**重要**
Lambda Insights の拡張機能、1.0.317.0 以降は、Amazon Linux 1 をサポートしていません。
## 1.0.660.0
バージョン 1.0.660.0 には、Lambda マネージドインスタンスで実行されている Lambda 関数に対する Lambda Insights 拡張機能のサポートが含まれています。Lambda マネージドインスタンスで実行されている関数の場合、拡張機能は EMF ログイベントを 1 分に 1 回送信し、1 分単位で 12 個の CloudWatch メトリクスを作成します。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:31` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension-Arm64:33` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:29` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:31` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension-Arm64:30` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension-Arm64:30` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension-Arm64:18` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension-Arm64:30` |
| アジアパシフィック (マレーシア) | `arn:aws:lambda:ap-southeast-5:590183865173:layer:LambdaInsightsExtension-Arm64:7` |
| アジアパシフィック (メルボルン) | `arn:aws:lambda:ap-southeast-4:158895979263:layer:LambdaInsightsExtension-Arm64:7` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension-Arm64:33` |
| アジアパシフィック (ニュージーランド) | `arn:aws:lambda:ap-southeast-6:727646510379:layer:LambdaInsightsExtension-Arm64:165` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension-Arm64:28` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:30` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:31` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:31` |
| アジアパシフィック (台北) | `arn:aws:lambda:ap-east-2:145023102084:layer:LambdaInsightsExtension-Arm64:7` |
| アジアパシフィック (タイ) | `arn:aws:lambda:ap-southeast-7:761018874580:layer:LambdaInsightsExtension-Arm64:7` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:42` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:29` |
| カナダ西部 (カルガリー) | `arn:aws:lambda:ca-west-1:946466191631:layer:LambdaInsightsExtension-Arm64:7` |
| 中国 (北京) | `arn:aws-cn:lambda:cn-north-1:488211338238:layer:LambdaInsightsExtension-Arm64:4` |
| 中国 (寧夏) | `arn:aws-cn:lambda:cn-northwest-1:488211338238:layer:LambdaInsightsExtension-Arm64:4` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:31` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:31` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:31` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension-Arm64:30` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension-Arm64:29` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension-Arm64:18` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension-Arm64:29` |
| 欧州 (チューリッヒ) | `arn:aws:lambda:eu-central-2:033019950311:layer:LambdaInsightsExtension-Arm64:7` |
| イスラエル (テルアビブ) | `arn:aws:lambda:il-central-1:459530977127:layer:LambdaInsightsExtension-Arm64:7` |
| メキシコ (中部) | `arn:aws:lambda:mx-central-1:879381266642:layer:LambdaInsightsExtension-Arm64:7` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension-Arm64:30` |
| 中東 (UAE) | `arn:aws:lambda:me-central-1:732604637566:layer:LambdaInsightsExtension-Arm64:7` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:29` |
| AWS GovCloud (米国東部) | `arn:aws-us-gov:lambda:us-gov-east-1:122132214140:layer:LambdaInsightsExtension-Arm64:6` |
| AWS GovCloud (米国西部) | `arn:aws-us-gov:lambda:us-gov-west-1:751350123760:layer:LambdaInsightsExtension-Arm64:6` |
## 1.0.498.0
バージョン 1.0.498.0 には、バグ修正とパフォーマンスの向上が含まれています。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:27` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension-Arm64:29` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:25` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:27` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension-Arm64:26` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension-Arm64:26` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension-Arm64:29` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension-Arm64:14` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:27` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:27` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension-Arm64:26` |
| アジアパシフィック (メルボルン) | `arn:aws:lambda:ap-southeast-4:158895979263:layer:LambdaInsightsExtension-Arm64:3` |
| アジアパシフィック (マレーシア) | `arn:aws:lambda:ap-southeast-5:590183865173:layer:LambdaInsightsExtension-Arm64:3` |
| アジアパシフィック (タイ) | `arn:aws:lambda:ap-southeast-7:761018874580:layer:LambdaInsightsExtension-Arm64:2` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:38` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:26` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension-Arm64:24` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:25` |
| カナダ西部 (カルガリー) | `arn:aws:lambda:ca-west-1:946466191631:layer:LambdaInsightsExtension-Arm64:3` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:27` |
| 欧州 (チューリッヒ) | `arn:aws:lambda:eu-central-2:033019950311:layer:LambdaInsightsExtension-Arm64:3` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:27` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:27` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension-Arm64:25` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension-Arm64:25` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension-Arm64:26` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension-Arm64:14` |
| イスラエル (テルアビブ) | `arn:aws:lambda:il-central-1:459530977127:layer:LambdaInsightsExtension-Arm64:3` |
| メキシコ (中部) | `arn:aws:lambda:mx-central-1:879381266642:layer:LambdaInsightsExtension-Arm64:2` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension-Arm64:26` |
| 中東 (UAE) | `arn:aws:lambda:me-central-1:732604637566:layer:LambdaInsightsExtension-Arm64:3` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:25` |
| 中国 (北京) | `arn:aws-cn:lambda:cn-north-1:488211338238:layer:LambdaInsightsExtension-Arm64:1` |
| 中国 (寧夏) | `arn:aws-cn:lambda:cn-northwest-1:488211338238:layer:LambdaInsightsExtension-Arm64:1` |
| AWS GovCloud (米国東部) | `arn:aws-us-gov:lambda:us-gov-east-1:122132214140:layer:LambdaInsightsExtension-Arm64:6` |
| AWS GovCloud (米国西部) | `arn:aws-us-gov:lambda:us-gov-west-1:751350123760:layer:LambdaInsightsExtension-Arm64:6` |
## 1.0.404.0
バージョン 1.0.404.0 では、Lambda Insights 拡張機能のバイナリサイズが約 9 MB から約 5 MB に縮小され、それに続いて Lambda Insights 拡張機能レイヤーの zip サイズが約 3.7 MB から約 2.5 MB に縮小されています。また、エージェントの全体的なメモリ消費量が約 11 MB から約 7 MB に削減されます。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:23` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension-Arm64:25` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:21` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:23` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension-Arm64:21` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension-Arm64:21` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension-Arm64:9` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension-Arm64:21` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension-Arm64:25` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension-Arm64:20` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:22` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:23` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:23` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:34` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:21` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:23` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:23` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:23` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension-Arm64:21` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension-Arm64:21` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension-Arm64:9` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension-Arm64:21` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension-Arm64:21` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:21` |
| AWS GovCloud (米国東部) | `arn:aws-us-gov:lambda:us-gov-east-1:122132214140:layer:LambdaInsightsExtension-Arm64:6` |
| AWS GovCloud (米国西部) | `arn:aws-us-gov:lambda:us-gov-west-1:751350123760:layer:LambdaInsightsExtension-Arm64:6` |
## 1.0.391.0
**重要**
バージョン 1.0.391.0 では、Lambda Insights がスレッドの使用状況を収集してレポートする方法が変更されています。以前のバージョンの 拡張機能では、 `threads_max` メトリクスは、プロセス ID が 1 のプロセスで実行されているスレッドの最大数を報告しました。バージョン 1.0.391.0 以降の場合、このメトリクスは、実行環境内のすべてのプロセスで、関数の実行中に任意の時点で実行されていたスレッドの最大数を報告します。これには、Lambda 関数のプロセス、拡張機能のプロセス、システム/ランタイム固有のプロセスなどが含まれます。これにより、`threads_max` メトリクスは、ユーザーが利用できる残りのスレッド数を評価する上で、より包括的なものになります。スレッドクォータとプロセスクォータの詳細については、「[Lambda クォータ](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)」を参照してください。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:22` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension-Arm64:24` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:20` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:22` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension-Arm64:20` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension-Arm64:20` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension-Arm64:8` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension-Arm64:20` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension-Arm64:24` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension-Arm64:19` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:21` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:22` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:22` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:33` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:20` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:22` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:22` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:22` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension-Arm64:20` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension-Arm64:20` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension-Arm64:8` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension-Arm64:20` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension-Arm64:20` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:20` |
| AWS GovCloud (米国東部) | `arn:aws-us-gov:lambda:us-gov-east-1:122132214140:layer:LambdaInsightsExtension-Arm64:5` |
| AWS GovCloud (米国西部) | `arn:aws-us-gov:lambda:us-gov-west-1:751350123760:layer:LambdaInsightsExtension-Arm64:5` |
## 1.0.333.0
バージョン 1.0.333.0 にはバグ修正が含まれています。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:20` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension-Arm64:22` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:18` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:20` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension-Arm64:18` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension-Arm64:18` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension-Arm64:6` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension-Arm64:18` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension-Arm64:22` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension-Arm64:17` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:19` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:20` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:20` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:31` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:18` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:20` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:20` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:20` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension-Arm64:18` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension-Arm64:18` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension-Arm64:6` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension-Arm64:18` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension-Arm64:18` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:18` |
| AWS GovCloud (米国東部) | `arn:aws-us-gov:lambda:us-gov-east-1:122132214140:layer:LambdaInsightsExtension-Arm64:3` |
| AWS GovCloud (米国西部) | `arn:aws-us-gov:lambda:us-gov-west-1:751350123760:layer:LambdaInsightsExtension-Arm64:3` |
## 1.0.317.0
バージョン 1.0.317.0 には、Amazon Linux 1 プラットフォームのサポートの削除とバグ修正が含まれています。AWS GovCloud (US) リージョンのサポートも含まれています。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:19` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension-Arm64:21` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:17` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:19` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension-Arm64:17` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension-Arm64:17` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension-Arm64:5` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension-Arm64:17` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension-Arm64:21` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension-Arm64:16` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:18` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:19` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:19` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:30` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:17` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:19` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:19` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:19` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension-Arm64:17` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension-Arm64:17` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension-Arm64:5` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension-Arm64:17` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension-Arm64:17` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:17` |
| AWS GovCloud (米国東部) | `arn:aws-us-gov:lambda:us-gov-east-1:122132214140:layer:LambdaInsightsExtension-Arm64:1` |
| AWS GovCloud (米国西部) | `arn:aws-us-gov:lambda:us-gov-west-1:751350123760:layer:LambdaInsightsExtension-Arm64:1` |
## 1.0.295.0
バージョン 1.0.295.0 には、互換性のあるすべてのランタイム用の依存関係の更新が含まれています。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:18` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension-Arm64:20` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:16` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:18` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension-Arm64:16` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension-Arm64:16` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension-Arm64:4` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension-Arm64:16` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension-Arm64:20` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension-Arm64:15` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:17` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:18` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:18` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:29` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:16` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:18` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:18` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:18` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension-Arm64:16` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension-Arm64:16` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension-Arm64:4` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension-Arm64:16` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension-Arm64:16` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:16` |
## 1.0.275.0
バージョン 1.0.275.0 には、互換性のあるすべてのランタイムのバグ修正と、欧州 (スペイン) およびアジアパシフィック (ハイデラバード) リージョンのサポートが含まれています。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:16` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension-Arm64:18` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:14` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:16` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension-Arm64:14` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension-Arm64:14` |
| アジアパシフィック (ハイデラバード) | `arn:aws:lambda:ap-south-2:891564319516:layer:LambdaInsightsExtension-Arm64:2` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension-Arm64:14` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension-Arm64:18` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension-Arm64:13` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:15` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:16` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:16` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:27` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:14` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:16` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:16` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:16` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension-Arm64:14` |
| 欧州 (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension-Arm64:14` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-2:352183217350:layer:LambdaInsightsExtension-Arm64:2` |
| 欧州 (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension-Arm64:14` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension-Arm64:14` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:14` |
## 1.0.273.0
バージョン 1.0.273.0 には、互換性のあるすべてのランタイム用のバグ修正が含まれています。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:12` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension-Arm64:14` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:9` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:12` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension-Arm64:9` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension-Arm64:9` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension-Arm64:9` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension-Arm64:14` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension-Arm64:9` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:11` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:12` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:12` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:23` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:10` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:12` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:12` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:12` |
| 欧州 (ミラノ) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension-Arm64:9` |
| ヨーロッパ (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension-Arm64:10` |
| ヨーロッパ (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension-Arm64:10` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension-Arm64:9` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:10` |
## 1.0.229.0
バージョン 1.0.229.0 には、互換性のあるすべてのランタイム用のバグ修正が含まれています。また、次のリージョン用のサポートも追加されます。
+ 米国西部 (北カリフォルニア)
+ アフリカ (ケープタウン)
+ アジアパシフィック (香港)
+ アジアパシフィック (ジャカルタ)
+ アジアパシフィック (大阪)
+ アジアパシフィック (ソウル)
+ カナダ (中部)
+ 欧州 (ミラノ)
+ ヨーロッパ (パリ)
+ ヨーロッパ (ストックホルム)
+ 中東 (バーレーン)
+ 南米 (サンパウロ)
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:5` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension-Arm64:7` |
| 米国西部 (北カリフォルニア) | `arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:3` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:5` |
| アフリカ (ケープタウン) | `arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension-Arm64:2` |
| アジアパシフィック (香港) | `arn:aws:lambda:ap-east-1:519774774795:layer:LambdaInsightsExtension-Arm64:2` |
| アジアパシフィック (ジャカルタ) | `arn:aws:lambda:ap-southeast-3:439286490199:layer:LambdaInsightsExtension-Arm64:2` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension-Arm64:7` |
| アジアパシフィック (大阪) | `arn:aws:lambda:ap-northeast-3:194566237122:layer:LambdaInsightsExtension-Arm64:2` |
| アジアパシフィック (ソウル) | `arn:aws:lambda:ap-northeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:4` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:5` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:5` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:11` |
| カナダ (中部) | `arn:aws:lambda:ca-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:3` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:5` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:5` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:5` |
| 欧州 (スペイン) | `arn:aws:lambda:eu-south-1:339249233099:layer:LambdaInsightsExtension-Arm64:2` |
| ヨーロッパ (パリ) | `arn:aws:lambda:eu-west-3:580247275435:layer:LambdaInsightsExtension-Arm64:3` |
| ヨーロッパ (ストックホルム) | `arn:aws:lambda:eu-north-1:580247275435:layer:LambdaInsightsExtension-Arm64:3` |
| 中東 (バーレーン) | `arn:aws:lambda:me-south-1:285320876703:layer:LambdaInsightsExtension-Arm64:2` |
| 南米 (サンパウロ) | `arn:aws:lambda:sa-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:3` |
## 1.0.135.0
バージョン 1.0.135.0 には、Lambda Insights でのディスクとファイル記述子の使用量の収集とレポートの方法に関するバグ修正が含まれています。拡張機能の以前のバージョンでは、関数を実行中の `/tmp` ディレクトリの最大空き領域は `tmp_free` メトリクスによって報告されていました。このバージョンでは、代わりに最小値をレポートするようにメトリクスが変更されており、ディスク使用量を評価する上でさらに便利になっています。`tmp` ディレクトリのストレージクォータの詳細については、[Lambda クォータ](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)を参照してください。
また、バージョン 1.0.135.0 では、オペレーティングシステムレベルではなく、プロセス全体の最大値としてファイル記述子の使用量 (`fd_use` および `fd_max`) が報告されるようになりました。
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:2` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension-Arm64:2` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:2` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension-Arm64:2` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:2` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:2` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:2` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:2` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:2` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:2` |
## 1.0.119.0
| リージョン | ARN |
| --- | --- |
| 米国東部 (バージニア北部) | `arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension-Arm64:1` |
| 米国東部 (オハイオ) | `arn:aws:lambda:us-east-2:580247275435:layer:LambdaInsightsExtension-Arm64:1` |
| 米国西部 (オレゴン) | `arn:aws:lambda:us-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:1` |
| アジアパシフィック (ムンバイ) | `arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension-Arm64:1` |
| アジアパシフィック (シンガポール) | `arn:aws:lambda:ap-southeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:1` |
| アジアパシフィック (シドニー) | `arn:aws:lambda:ap-southeast-2:580247275435:layer:LambdaInsightsExtension-Arm64:1` |
| アジアパシフィック (東京) | `arn:aws:lambda:ap-northeast-1:580247275435:layer:LambdaInsightsExtension-Arm64:1` |
| 欧州 (フランクフルト) | `arn:aws:lambda:eu-central-1:580247275435:layer:LambdaInsightsExtension-Arm64:1` |
| 欧州 (アイルランド) | `arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension-Arm64:1` |
| 欧州 (ロンドン) | `arn:aws:lambda:eu-west-2:580247275435:layer:LambdaInsightsExtension-Arm64:1` |
# コンソールを使用して既存の Lambda 関数で Lambda Insights を有効にする
Lambda コンソールで次の手順を使用して、既存の Lambda 関数で Lambda Insights を有効にします。
**Lambda 関数で Lambda Insights を有効にするには**
1. AWS Lambda コンソールの [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/) を開いてください。
1. 関数の名前を選択し、次の画面で **[Configuration]** (設定) タブを選択します。
1. **[設定]** タブで、左側のナビゲーションメニューから **[モニタリングおよび運用ツール]** を選択し、**[編集]** を選択します。
モニターリングツールを編集できる画面に移動します。
1. **[Lambda Insights 拡張モニタリング]** で、**[編集]** を選択します。
1. **[CloudWatch Lambda インサイト]** のセクションで **[拡張モニタリング]** を有効にして、**[保存]** を選択します。
# 既存の Lambda 関数で Lambda Insights を有効にするために AWS CLI を使用する
AWS CLI を使用して、既存の Lambda 関数で Lambda Insights を有効にするには、次の手順に従います。
**ステップ 1: 関数のアクセス許可を更新する**
**関数のアクセス許可を更新するには**
+ 次のコマンドを入力して、**CloudWatchLambdaInsightsExecutionRolePolicy** マネージド IAM ポリシーを関数の実行ロールにアタッチします。
```
aws iam attach-role-policy \
--role-name function-execution-role \
--policy-arn "arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy"
```
**ステップ 2: Lambda 拡張機能をインストールする**
Lambda 拡張機能をインストールするには、次のコマンドを入力します。`layers` パラメータの ARN 値を、使用するリージョンと拡張バージョンに一致する ARN に置き換えます。詳細については、「[Lambda Insights 拡張機能の利用可能なバージョン](Lambda-Insights-extension-versions.md)」を参照してください。
```
aws lambda update-function-configuration \
--function-name function-name \
--layers "arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:14"
```
**ステップ 3: CloudWatch Logs VPC エンドポイントを有効にする**
このステップは、インターネットにアクセスできないプライベートサブネットで実行されている関数、および CloudWatch Logs Virtual Private Cloud (VPC) エンドポイントをまだ設定していない場合にのみ必要です。
このステップを実行する必要がある場合は、次のコマンドを入力し、プレースホルダーを VPC の情報に置き換えます。
詳細については、「[インターフェイス VPC エンドポイントでの CloudWatch Logs の使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html)」を参照してください。
```
aws ec2 create-vpc-endpoint \
--vpc-id vpcId \
--vpc-endpoint-type Interface \
--service-name com.amazonaws.region.logs \
--subnet-id subnetId
--security-group-id securitygroupId
```
# 既存の Lambda 関数で Lambda Insights を有効にするために AWS SAM CLI を使用する
AWS SAM AWS CLI を使用して、既存の Lambda 関数で Lambda Insights を有効にするには、次の手順に従います。
最新バージョンの AWS SAM CLI をまだインストールしていない場合は、まずインストールまたはアップグレードする必要があります。詳細については、[AWS SAM CLI のインストール](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html)を参照してください。
**ステップ 1: レイヤーをインストールする**
Lambda Insights 拡張機能をすべての Lambda 関数で使用できるようにするには、Lambda Insights レイヤーの ARN を使用して SAM テンプレートの `Globals` セクションに `Layers` プロパティを追加します。次の例では、Lambda Insights の最初のリリースにレイヤーを使用しています。Lambda Insights 拡張レイヤーの最新リリースバージョンについては、「[Lambda Insights 拡張機能の利用可能なバージョン](Lambda-Insights-extension-versions.md)」を参照してください。
```
Globals:
Function:
Layers:
- !Sub "arn:aws:lambda:${AWS::Region}:580247275435:layer:LambdaInsightsExtension:14"
```
このレイヤーを 1 つの関数に対してのみ有効にするには、この例のように関数に `Layers` プロパティを追加します。
```
Resources:
MyFunction:
Type: AWS::Serverless::Function
Properties:
Layers:
- !Sub "arn:aws:lambda:${AWS::Region}:580247275435:layer:LambdaInsightsExtension:14"
```
**ステップ 2: マネージドポリシーを追加する**
各関数について、**CloudWatchLambdaInsightsExecutionRolePolicy** IAM ポリシーを追加します。
AWS SAM はグローバルポリシーをサポートしていないため、この例に示すように、各関数で個別に有効にする必要があります。グローバルの詳細については、「[グローバルセクション](https://github.com/aws/serverless-application-model/blob/master/docs/globals.rst)」を参照してください。
```
Resources:
MyFunction:
Type: AWS::Serverless::Function
Properties:
Policies:
- CloudWatchLambdaInsightsExecutionRolePolicy
```
**ローカルでの呼び出し**
AWS SAM CLI は Lambda 拡張機能をサポートしています。ただし、ローカルで実行されるすべての呼び出しは、ランタイム環境をリセットします。ランタイムはシャットダウンイベントなしで再起動されるため、Lambda Insights データはローカル呼び出しからは使用できません。詳細については、「[リリース 1.6.0 － AWS Lambda 拡張機能のローカルテストのサポートを追加する](https://github.com/aws/aws-sam-cli/releases/tag/v1.6.0)」を参照してください。
**トラブルシューティング**
Lambda Insights のインストールに関するトラブルシューティングを行うには、Lambda 関数に次の環境変数を追加して、デバッグログを有効にします。
```
Resources:
MyFunction:
Type: AWS::Serverless::Function
Properties:
Environment:
Variables:
LAMBDA_INSIGHTS_LOG_LEVEL: info
```
# 既存の Lambda 関数で Lambda Insights を有効にするために CloudFormation を使用する
CloudFormation を使用して、既存の Lambda 関数で Lambda Insights を有効にするには、次の手順に従います。
**ステップ 1: レイヤーをインストールする**
Lambda Insights レイヤーを Lambda Insights レイヤー ARN 内の `Layers` プロパティに追加します。次の例では、Lambda Insights の最初のリリースにレイヤーを使用しています。Lambda Insights 拡張レイヤーの最新リリースバージョンについては、「[Lambda Insights 拡張機能の利用可能なバージョン](Lambda-Insights-extension-versions.md)」を参照してください。
```
Resources:
MyFunction:
Type: AWS::Lambda::Function
Properties:
Layers:
- !Sub "arn:aws:lambda:${AWS::Region}:580247275435:layer:LambdaInsightsExtension:14"
```
**ステップ 2: マネージドポリシーを追加する**
**CloudWatchLambdaInsightsExecutionRolePolicy** IAM ポリシーを関数実行ロールに追加します。
```
Resources:
MyFunctionExecutionRole:
Type: 'AWS::IAM::Role'
Properties:
ManagedPolicyArns:
- 'arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy'
```
**ステップ 3: (オプション) VPC エンドポイントを追加する**
このステップは、インターネットにアクセスできないプライベートサブネットで実行されている関数、および CloudWatch Logs Virtual Private Cloud (VPC) エンドポイントをまだ設定していない場合にのみ必要です。詳細については、「[インターフェイス VPC エンドポイントでの CloudWatch Logs の使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html)」を参照してください。
```
Resources:
CloudWatchLogsVpcPrivateEndpoint:
Type: AWS::EC2::VPCEndpoint
Properties:
PrivateDnsEnabled: 'true'
VpcEndpointType: Interface
VpcId: !Ref: VPC
ServiceName: !Sub com.amazonaws.${AWS::Region}.logs
SecurityGroupIds:
- !Ref InterfaceVpcEndpointSecurityGroup
SubnetIds:
- !Ref PublicSubnet01
- !Ref PublicSubnet02
- !Ref PublicSubnet03
```
# 既存の Lambda 関数で Lambda Insights を有効にするために AWS CDK を使用する
AWS CDK を使用して、既存の Lambda 関数で Lambda Insights を有効にするには、次の手順に従います。これらのステップを使用するには、既に AWS CDK を使用してリソースを管理している必要があります。
このセクションのコマンドは、TypeScript で記載されています。
まず、関数のアクセス許可を更新します。
```
executionRole.addManagedPolicy(
ManagedPolicy.fromAwsManagedPolicyName('CloudWatchLambdaInsightsExecutionRolePolicy')
);
```
次に、Lambda 関数に拡張機能をインストールします。`layerArn` パラメータの ARN 値を、使用するリージョンと拡張バージョンに一致する ARN に置き換えます。詳細については、「[Lambda Insights 拡張機能の利用可能なバージョン](Lambda-Insights-extension-versions.md)」を参照してください。
```
import lambda = require('@aws-cdk/aws-lambda');
const layerArn = 'arn:aws:lambda:us-west-1:580247275435:layer:LambdaInsightsExtension:14';
const layer = lambda.LayerVersion.fromLayerVersionArn(this, 'LayerFromArn', layerArn);
```
必要に応じて、CloudWatch Logs の Virtual Private Cloud (VPC) エンドポイントを使用することもできます。このステップは、インターネットにアクセスできないプライベートサブネットで実行されている関数、および CloudWatch Logs VPC エンドポイントをまだ設定していない場合にのみ必要です。
```
const cloudWatchLogsEndpoint = vpc.addInterfaceEndpoint('cwl-gateway', {
service: InterfaceVpcEndpointAwsService.CLOUDWATCH_LOGS,
});
cloudWatchLogsEndpoint.connections.allowDefaultPortFromAnyIpv4();
```
# Serverless Framework を使用して、既存の Lambda 関数で Lambda Insights を有効にする
Serverless Framework を使用して、既存の Lambda 関数で Lambda Insights を有効にするには、次の手順に従います。Serverless Framework の詳細については、[serverless.com](https://www.serverless.com/) を参照してください。
これは、Serverless の Lambda Insights プラグインから行えます。詳細については、「[serverless-plugin-lambda-insights](https://www.npmjs.com/package/serverless-plugin-lambda-insights)」を参照してください。
最新バージョンの Serverless コマンドラインインターフェースをまだ使用していない場合は、まずインストールまたはアップグレードする必要があります。詳細については、[Serverless Framework Open Source & AWS](https://www.serverless.com/framework/docs/getting-started/) の使用開始を参照してください。
**Serverless Framework を使用して、Lambda 関数で Lambda Insights を有効化するには**
1. Serverless のディレクトリで次のコマンドを実行し、Lambda Insights 用の Serverless プラグインをインストールします。
```
npm install --save-dev serverless-plugin-lambda-insights
```
1. `serverless.yml`ファイルで、図のように `plugins` セクション内にプラグインを追加します。
```
provider:
name: aws
plugins:
- serverless-plugin-lambda-insights
```
1. Lambda Insights を有効にします。
+ 次のプロパティを serverless.yml ファイルに追加することで、関数ごとに個別に Lambda Insights を有効化できます。
```
functions:
myLambdaFunction:
handler: src/app/index.handler
lambdaInsights: true #enables Lambda Insights for this function
```
+ 次のカスタムセクションを追加すると、`serverless.yml` ファイル内にあるすべての関数に対して Lambda Insights を有効化できます。
```
custom:
lambdaInsights:
defaultLambdaInsights: true #enables Lambda Insights for all functions
```
1. 次のコマンドを入力して、Serverless サービスを再デプロイします。
```
serverless deploy
```
これにより、すべての関数が再デプロイされ、指定した関数に対し Lambda Insights が有効になります。ここでは、Lambda Insights レイヤーを追加し、`arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy` IAM ポリシーを使用して必要なアクセス許可をアタッチすることで、Lambda Insights を有効にしています。
# Lambda コンテナイメージをデプロイして Lambda Insights を有効化する
Dockerfile に行を追加し、コンテナイメージとしてデプロイされた Lambda 関数で Lambda Insights を有効にします。これらの行により、コンテナイメージに対し、Lambda Insights エージェントが拡張機能としてインストールされます。追加する行は、x86-64 コンテナと ARM64 コンテナで異なります。
**注記**
Lambda Insights エージェントは、Amazon Linux 2 および Amazon Linux 2023 を使用する Lambda ランタイムでのみサポートされます。
**Topics**
+ [
## x86-64 コンテナイメージのデプロイ
](#Lambda-Insights-Getting-Started-docker-x86-64)
+ [
## ARM64 コンテナイメージのデプロイ
](#Lambda-Insights-Getting-Started-docker-ARM64)
## x86-64 コンテナイメージのデプロイ
x86-64 コンテナ上で実行されるコンテナイメージとしてデプロイされた Lambda 関数で Lambda Insights を有効にするには、Dockerfile に次の行を追加します。これらの行により、コンテナイメージに対し、Lambda Insights エージェントが拡張機能としてインストールされます。
```
RUN curl -O https://lambda-insights-extension.s3-ap-northeast-1.amazonaws.com/amazon_linux/lambda-insights-extension.rpm && \
rpm -U lambda-insights-extension.rpm && \
rm -f lambda-insights-extension.rpm
```
Lambda 関数の作成後、**CloudWatchLambdaInsightsExecutionRolePolicy** IAM ポリシーを関数の実行ロールに割り当てると、コンテナイメージベースの Lambda 関数で Lambda Insights が有効化されます。
**注記**
Lambda Insights の拡張機能の古いバージョンを使用するには、前出のコマンドの URL を `https://lambda-insights-extension.s3-ap-northeast-1.amazonaws.com/amazon_linux/lambda-insights-extension.1.0.111.0.rpm` に置き換えます。詳細については、「[Lambda Insights 拡張機能の利用可能なバージョン](Lambda-Insights-extension-versions.md)」を参照してください。
**Linux サーバーで Lambda Insights エージェントパッケージの署名を確認するには**
1. 次のコマンドを入力して、公開キーをダウンロードします。
```
shell$ wget https://lambda-insights-extension.s3-ap-northeast-1.amazonaws.com/lambda-insights-extension.gpg
```
1. 次のコマンドを入力して、公開鍵をキーリングにインポートします。
```
shell$ gpg --import lambda-insights-extension.gpg
```
出力は以下のようになります。次のステップで必要になるため、`key` 値を書きとめておきます。この出力例では、キー値は `848ABDC8` です。
```
gpg: key 848ABDC8: public key "Amazon Lambda Insights Extension" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
```
1. 次のコマンドを入力して、フィンガープリントを検証します。`key-value` の部分は、前の手順で記録したキーの値に置き換えます。
```
shell$ gpg --fingerprint key-value
```
このコマンドの出力では、フィンガープリント文字列は `E0AF FA11 FFF3 5BD7 349E E222 479C 97A1 848A BDC8` のようになります。フィンガープリント文字列が一致しない場合は、エージェントのインストールを中止し、AWS にお問い合わせください。
1. フィンガープリントが確認できたら、それを使用して、Lambda Insights のエージェントパッケージを確認できます。次のコマンドを入力して、パッケージの署名ファイルをダウンロードします。
```
shell$ wget https://lambda-insights-extension.s3-ap-northeast-1.amazonaws.com/amazon_linux/lambda-insights-extension.rpm.sig
```
1. 次のコマンドを入力して、署名を確認します。
```
shell$ gpg --verify lambda-insights-extension.rpm.sig lambda-insights-extension.rpm
```
出力は次のようになります。
```
gpg: Signature made Thu 08 Apr 2021 06:41:00 PM UTC using RSA key ID 848ABDC8
gpg: Good signature from "Amazon Lambda Insights Extension"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: E0AF FA11 FFF3 5BD7 349E E222 479C 97A1 848A BDC8
```
このときの出力には、信頼された署名に関する警告が表示される場合があります。キーは、自分や信頼する人が署名した場合にのみ信頼できます。つまり、署名が無効であるわけではなく、パブリックキーを確認していないことになります。
出力に `BAD signature` が含まれている場合は、ここまでの手順を正しく実行したかどうかを確認します。この `BAD signature` レスポンスが引き続き出力される場合は、AWS に連絡の上、ダウンロードしたファイルの使用は中止してください。
### x86-64 の例
このセクションでは、コンテナイメージベースの Python Lambda 関数で Lambda Insights を有効にする例を示します。
**Lambda コンテナイメージで Lambda Insights を有効にする例**
1. 次のような Dockerfile を作成します。
```
FROM public.ecr.aws/lambda/python:3.8
// extra lines to install the agent here
RUN curl -O https://lambda-insights-extension.s3-ap-northeast-1.amazonaws.com/amazon_linux/lambda-insights-extension.rpm && \
rpm -U lambda-insights-extension.rpm && \
rm -f lambda-insights-extension.rpm
COPY index.py ${LAMBDA_TASK_ROOT}
CMD [ "index.handler" ]
```
1. 次のような Python ファイルを、`index.py` という名前で作成します。
```
def handler(event, context):
return {
'message': 'Hello World!'
}
```
1. Dockerfile と `index.py` を同じディレクトリに保存します。次に、保存先のディレクトリで次の手順を実行して Docker イメージをビルドし、それを Amazon ECR にアップロードします。
```
// create an ECR repository
aws ecr create-repository --repository-name test-repository
// build the docker image
docker build -t test-image .
// sign in to AWS
aws ecr get-login-password | docker login --username AWS --password-stdin "${ACCOUNT_ID}".dkr.ecr."${REGION}".amazonaws.com
// tag the image
docker tag test-image:latest "${ACCOUNT_ID}".dkr.ecr."${REGION}".amazonaws.com/test-repository:latest
// push the image to ECR
docker push "${ACCOUNT_ID}".dkr.ecr."${REGION}".amazonaws.com/test-repository:latest
```
1. 先ほど作成した Amazon ECR イメージを使用して、Lambda 関数を作成します。
1. **CloudWatchLambdaInsightsExecutionRolePolicy** IAM ポリシーを、関数の実行ロールに割り当てます。
## ARM64 コンテナイメージのデプロイ
AL2\$1aarch64 コンテナ (ARM64 アーキテクチャを使用) 上で実行されるコンテナイメージとしてデプロイされた Lambda 関数で Lambda Insights を有効にするには、Dockerfile に次の行を追加します。これらの行により、コンテナイメージに対し、Lambda Insights エージェントが拡張機能としてインストールされます。
```
RUN curl -O https://lambda-insights-extension-arm64.s3-ap-northeast-1.amazonaws.com/amazon_linux/lambda-insights-extension-arm64.rpm && \
rpm -U lambda-insights-extension-arm64.rpm && \
rm -f lambda-insights-extension-arm64.rpm
```
Lambda 関数の作成後、**CloudWatchLambdaInsightsExecutionRolePolicy** IAM ポリシーを関数の実行ロールに割り当てると、コンテナイメージベースの Lambda 関数で Lambda Insights が有効化されます。
**注記**
Lambda Insights の拡張機能の古いバージョンを使用するには、前出のコマンドの URL を `https://lambda-insights-extension-arm64.s3-ap-northeast-1.amazonaws.com/amazon_linux/lambda-insights-extension-arm64.1.0.229.0.rpm` に置き換えます。詳細については、「[Lambda Insights 拡張機能の利用可能なバージョン](Lambda-Insights-extension-versions.md)」を参照してください。
**Linux サーバーで Lambda Insights エージェントパッケージの署名を確認するには**
1. 次のコマンドを入力して、公開キーをダウンロードします。
```
shell$ wget https://lambda-insights-extension-arm64.s3-ap-northeast-1.amazonaws.com/lambda-insights-extension.gpg
```
1. 次のコマンドを入力して、公開鍵をキーリングにインポートします。
```
shell$ gpg --import lambda-insights-extension.gpg
```
出力は以下のようになります。次のステップで必要になるため、`key` 値を書きとめておきます。この出力例では、キー値は `848ABDC8` です。
```
gpg: key 848ABDC8: public key "Amazon Lambda Insights Extension" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
```
1. 次のコマンドを入力して、フィンガープリントを検証します。`key-value` の部分は、前の手順で記録したキーの値に置き換えます。
```
shell$ gpg --fingerprint key-value
```
このコマンドの出力では、フィンガープリント文字列は `E0AF FA11 FFF3 5BD7 349E E222 479C 97A1 848A BDC8` のようになります。フィンガープリント文字列が一致しない場合は、エージェントのインストールを中止し、AWS にお問い合わせください。
1. フィンガープリントが確認できたら、それを使用して、Lambda Insights のエージェントパッケージを確認できます。次のコマンドを入力して、パッケージの署名ファイルをダウンロードします。
```
shell$ wget https://lambda-insights-extension-arm64.s3-ap-northeast-1.amazonaws.com/amazon_linux/lambda-insights-extension-arm64.rpm.sig
```
1. 次のコマンドを入力して、署名を確認します。
```
shell$ gpg --verify lambda-insights-extension-arm64.rpm.sig lambda-insights-extension-arm64.rpm
```
出力は次のようになります。
```
gpg: Signature made Thu 08 Apr 2021 06:41:00 PM UTC using RSA key ID 848ABDC8
gpg: Good signature from "Amazon Lambda Insights Extension"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: E0AF FA11 FFF3 5BD7 349E E222 479C 97A1 848A BDC8
```
このときの出力には、信頼された署名に関する警告が表示される場合があります。キーは、自分や信頼する人が署名した場合にのみ信頼できます。つまり、署名が無効であるわけではなく、パブリックキーを確認していないことになります。
出力に `BAD signature` が含まれている場合は、ここまでの手順を正しく実行したかどうかを確認します。この `BAD signature` レスポンスが引き続き出力される場合は、AWS に連絡の上、ダウンロードしたファイルの使用は中止してください。
### ARM64 の例
このセクションでは、コンテナイメージベースの Python Lambda 関数で Lambda Insights を有効にする例を示します。
**Lambda コンテナイメージで Lambda Insights を有効にする例**
1. 次のような Dockerfile を作成します。
```
FROM public.ecr.aws/lambda/python:3.8
// extra lines to install the agent here
RUN curl -O https://lambda-insights-extension-arm64.s3-ap-northeast-1.amazonaws.com/amazon_linux/lambda-insights-extension-arm64.rpm && \
rpm -U lambda-insights-extension-arm64.rpm && \
rm -f lambda-insights-extension-arm64.rpm
COPY index.py ${LAMBDA_TASK_ROOT}
CMD [ "index.handler" ]
```
1. 次のような Python ファイルを、`index.py` という名前で作成します。
```
def handler(event, context):
return {
'message': 'Hello World!'
}
```
1. Dockerfile と `index.py` を同じディレクトリに保存します。次に、保存先のディレクトリで次の手順を実行して Docker イメージをビルドし、それを Amazon ECR にアップロードします。
```
// create an ECR repository
aws ecr create-repository --repository-name test-repository
// build the docker image
docker build -t test-image .
// sign in to AWS
aws ecr get-login-password | docker login --username AWS --password-stdin "${ACCOUNT_ID}".dkr.ecr."${REGION}".amazonaws.com
// tag the image
docker tag test-image:latest "${ACCOUNT_ID}".dkr.ecr."${REGION}".amazonaws.com/test-repository:latest
// push the image to ECR
docker push "${ACCOUNT_ID}".dkr.ecr."${REGION}".amazonaws.com/test-repository:latest
```
1. 先ほど作成した Amazon ECR イメージを使用して、Lambda 関数を作成します。
1. **CloudWatchLambdaInsightsExecutionRolePolicy** IAM ポリシーを、関数の実行ロールに割り当てます。
# 関数の Lambda Insights 拡張機能バージョンを更新する
ベストプラクティスとして、Lambda Insights 拡張機能を最新バージョンに更新しておくことをお勧めします。このページのトピックでは、その方法について説明します。
**注記**
このページでは、既に Lambda Insights を使用している関数で使用される拡張機能バージョンを更新する方法について説明します。Lambda Insights の開始方法については、「[Lambda Insights の使用を開始する](Lambda-Insights-Getting-Started.md)」を参照してください。
## Lambda コンソールを使用して Lambda Insights 拡張機能バージョンを更新する
Lambda コンソールを使用して Lambda Insights 拡張機能バージョンを更新するには、次のステップに従います。
**Lambda コンソールを使用して更新するには**
1. AWS Lambda コンソールの [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/) を開いてください。
1. 関数の名前を選択します。
1. **[レイヤー]** セクションで **[編集]** を選択します。
1. レイヤーのリストで **LambdaInsightsExtension** を検索し、レイヤーのバージョンを [Lambda Insights 拡張機能の利用可能なバージョン](Lambda-Insights-extension-versions.md) にリストされている最新バージョンに変更します。
1. **[保存]** を選択します。
## AWS CLI を使用して Lambda Insights 拡張機能バージョンを更新する
AWS CLI を使用して Lambda Insights 拡張機能バージョンを更新するには、次のコマンドを入力します。レイヤーパラメータの ARN 値を、使用するリージョンと拡張バージョンに一致する ARN に置き換えます。Lambda Insights 拡張レイヤーの最新リリースバージョンについては、「[Lambda Insights 拡張機能の利用可能なバージョン](Lambda-Insights-extension-versions.md)」を参照してください。
```
aws lambda update-function-configuration \
--function-name function-name \
--layers "arn:aws:lambda:us-west-1:111122223333:layer:LambdaInsightsExtension:53"
```
## AWS SAM CLI を使用して 1 つ以上の関数の Lambda Insights 拡張機能を更新する
すべての Lambda 関数の Lambda Insights 拡張機能バージョンを更新するには、AWS サーバーレスアプリケーションモデル (SAM) テンプレートの `Globals` セクションの `Layers` プロパティを Lambda Insights レイヤーの ARN で更新します。Lambda Insights 拡張レイヤーの最新リリースバージョンについては、「[Lambda Insights 拡張機能の利用可能なバージョン](Lambda-Insights-extension-versions.md)」を参照してください。
以下は、すべての Lambda 関数を更新します。
```
Globals:
Function:
Layers:
- !Sub "arn:aws:lambda:${AWS::Region}:111122223333:layer:LambdaInsightsExtension:53"
```
以下は、1 つの関数だけを更新します。
```
Resources:
MyFunction:
Type: AWS::Serverless::Function
Properties:
Layers:
- !Sub "arn:aws:lambda:${AWS::Region}:111122223333:layer:LambdaInsightsExtension:53"
```
## CloudFormation を使用して 1 つ以上の関数の Lambda Insights 拡張機能を更新する
CloudFormation を使用して Lambda Insights 拡張機能バージョンを更新するには、次の例のように、関数の CloudFormationリソース内の `Layers` プロパティの拡張レイヤーを更新します。Lambda Insights 拡張レイヤーの最新リリースバージョンについては、「[Lambda Insights 拡張機能の利用可能なバージョン](Lambda-Insights-extension-versions.md)」を参照してください。
```
Resources:
MyFunction:
Type: AWS::Lambda::Function
Properties:
Layers:
- !Sub "arn:aws:lambda:${AWS::Region}:111122223333:layer:LambdaInsightsExtension:53"
```
## AWS CDK を使用して 1 つ以上の関数の Lambda Insights 拡張機能を更新する
`layerArn` パラメータの ARN 値を、使用するリージョンと拡張バージョンに一致する ARN に置き換えることで、Lambda 関数の拡張バージョンを更新できます。Lambda Insights 拡張レイヤーの最新リリースバージョンについては、「[Lambda Insights 拡張機能の利用可能なバージョン](Lambda-Insights-extension-versions.md)」を参照してください。
```
import lambda = require('@aws-cdk/aws-lambda');
const layerArn = 'arn:aws:lambda:us-west-1:111122223333:layer:LambdaInsightsExtension:53';
const layer = lambda.LayerVersion.fromLayerVersionArn(this, 'LayerFromArn', layerArn);
```
## Serverless Framework を使用して 1 つ以上の関数の Lambda Insights 拡張機能を更新する
Serverless Framework を使用して、既存の Lambda 関数の Lambda Insights 拡張機能バージョンを更新するには、次の手順に従います。Serverless Framework の詳細については、[Serverless Framework のドキュメント](https://serverless.com)を参照してください。
このメソッドは、Serverless の Lambda Insights プラグインを使用します。詳細については、「[serverless-plugin-lambda-insights](https://www.npmjs.com/package/serverless-plugin-lambda-insights)」を参照してください。
最新バージョンの Serverless コマンドラインインターフェイスをまだ使用していない場合は、まずインストールまたはアップグレードする必要があります。詳細については、「[Setting Up Serverless Framework With AWS](https://www.serverless.com/framework/docs/getting-started/)」を参照してください。
**Lambda コンソールを使用して更新するには**
1. Lambda Insights を更新します。まだ更新していない場合は、ファイルの最後に `custom` セクションを追加し、`lambdaInsightsVersion` プロパティ内で Lambda Insights のバージョンを指定します。
```
custom:
lambdaInsights:
lambdaInsightsVersion: 53 #specify the Layer Version
```
1. 次のコマンドを入力して、Serverless サービスを再デプロイします。
```
serverless deploy
```
## Lambda コンテナイメージをデプロイして Lambda Insights 拡張機能バージョンを更新する
Lambda コンテナイメージで Lambda Insights を更新するには、「[Lambda コンテナイメージをデプロイして Lambda Insights を有効化する](Lambda-Insights-Getting-Started-docker.md)」の手順に従って、最新バージョンの Lambda Insights でイメージを再構築します。次に、AWS CLI を使用して[関数コードを更新](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)し、コンテナイメージ URI を `--image-uri` パラメータの値として指定します。
# Lambda Insights メトリクスの表示
呼び出された Lambda 関数に Lambda Insights 拡張機能をインストールしたら、CloudWatch コンソールを使用してメトリクスを確認できます。複数の関数の概要を表示することも、1 つの関数に集中することもできます。マネージドインスタンスで実行されている Lambda 関数のメトリクスを表示することもできます。
Lambda Insights メトリクスのリストについては、「[Lambda Insights によって収集されたメトリクス](Lambda-Insights-metrics.md)」を参照してください。
**Lambda Insights メトリクスの複数の関数の概要を表示するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、**[Insights]**、**[Lambda Insights]** の順に選択します。
1. ページ上部の **[Lambda Insights ビュー]** ドロップダウンで、**[関数]** を選択します。
1. **[複数関数]** を選択します。
ページの上部には、Lambda Insights が有効になっているリージョン内のすべての Lambda 関数の集計されたメトリクスを含むグラフが表示されます。ページの下には、関数をリストした表があります。
1. 関数名でフィルターして表示される関数の数を減らすには、ページの上の方にあるボックスに関数名の一部を入力します。
1. このビューをウィジェットとしてダッシュボードに追加するには、[**Add to dashboard (ダッシュボードに追加)**] を選択します。
**1 つの関数のメトリクスを表示するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、**[Insights]**、**[Lambda Insights]** の順に選択します。
1. ページ上部の **[Lambda Insights ビュー]** ドロップダウンで、**[関数]** を選択します。
1. **単一関数**を選択します。
ページの上部に、選択した関数のメトリクスを含むグラフが表示されます。
1. X-Ray を有効にしている場合は、1 つのトレース ID を選択できます。これにより、その呼び出しの X-Ray トレースマップページを開き、そこからズームアウトして、分散トレースとその特定のトランザクションの処理に関係するその他のサービスを確認できます。X-Ray トレースマップの詳細については、「[Using the X-Ray Trace Map](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-servicemap.html)」を参照してください。
1. CloudWatch Logs Insights を開いて特定のエラーにズームインするには、ページの下部にあるテーブルで [**View logs (ログを表示する)**] を選択します。
1. このビューをウィジェットとしてダッシュボードに追加するには、[**Add to dashboard (ダッシュボードに追加)**] を選択します。
**マネージドインスタンスで実行されている Lambda 関数のメトリクスを表示するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、**[Insights]**、**[Lambda Insights]** の順に選択します。
1. ページ上部の **[Lambda Insights ビュー]** ドロップダウンで、**[マネージドインスタンス関数]** を選択します。
このページには、マネージドインスタンスで実行されている Lambda 関数のメトリクスを含むマネージドインスタンスビューが表示されます。
1. **[ビュー]** セクションで、メトリクスを表示する詳細度レベルを選択します。
+ **キャパシティープロバイダー** – キャパシティープロバイダーレベルで集計メトリクスを表示します。
+ **インスタンスタイプ** – インスタンスタイプレベルで集計メトリクスを表示します。
+ **関数** – 個々の関数レベルでメトリクスを表示します。ページの上部には、Lambda Insights が有効になっているリージョン内のすべての Lambda 関数の集計されたメトリクスを含むグラフが表示されます。ページの下には、関数をリストした表があります。関数名でフィルタリングするには、ページの上の方にあるボックスに関数名の一部を入力します。
1. **[フィルター]** セクションを使用して、キャパシティープロバイダー、インスタンスタイプ、または関数でフィルタリングします。
1. このビューをウィジェットとしてダッシュボードに追加するには、[**Add to dashboard (ダッシュボードに追加)**] を選択します。
# Application Insights との統合
Amazon CloudWatch Application Insights は、アプリケーションのモニターリングに役立ち、アプリケーションリソースとテクノロジースタック全体の主要なメトリクス、ログ、アラームを識別して設定します。詳細については、「[CloudWatch Application Insights を使用したアプリケーションの一般的な問題の検出](cloudwatch-application-insights.md)」を参照してください。
Application Insights を有効にすると Lambda 関数から追加データを収集できます。まだ有効にしていない場合は、Lambda Insights ダッシュボードのパフォーマンスビューの下にある **[Application Insights]** タブで [**Auto-configure Application Insights**] (アプリケーションインサイトの自動構成) を選択して有効にできます。
Lambda 関数をモニターリングするように CloudWatch Application Insights を既に設定している場合は、**[Application Insights]** タブの Lambda Insights ダッシュボードの下に Application Insights ダッシュボードが表示されます。
# Lambda Insights によって収集されたメトリクス
Lambda Insights は、インストールされている Lambda 関数からいくつかのメトリクスを収集します。これらのメトリクスの一部は、CloudWatch Metrics で時系列集計データとして使用できます。その他のメトリクスは、時系列データには集計されませんが、CloudWatch Logs Insights を使用して埋め込みメトリクスフォーマットのログエントリで確認できます。
**Topics**
+ [
# Lambda 関数
](Lambda-Insights-metrics-lambda-functions.md)
+ [
# マネージドインスタンスの Lambda 関数
](Lambda-Insights-metrics-managed-instances.md)
# Lambda 関数
次のメトリクスは、標準 Lambda 関数の `LambdaInsights` 名前空間の CloudWatch Metrics で時系列集計データとして使用できます。
| メトリクス名 | ディメンション | 説明 |
| --- | --- | --- |
| `cpu_total_time` | function\$1name function\$1name、バージョン | `cpu_system_time` と `cpu_user_time` の合計。 単位: ミリ秒 |
| `init_duration` | function\$1name function\$1name、バージョン | Lambda 実行環境のライフサイクルの `init` フェーズで費やされた時間。 単位: ミリ秒 |
| `memory_utilization` | function\$1name function\$1name、バージョン | 最大メモリは、関数に割り当てられたメモリのパーセンテージとして測定されます。 単位: パーセント |
| `used_memory_max` | function\$1name function\$1name、バージョン | 関数の実行環境におけるメモリ測定値。 単位: メガバイト |
| `rx_bytes` | function\$1name function\$1name、バージョン | 関数の受信バイト数。 単位: バイト |
| `tmp_free` | function\$1name function\$1name、バージョン | `/tmp` ディレクトリで使用可能な領域の量。 単位: バイト |
| `tmp_used` | function\$1name function\$1name、バージョン | `/tmp` ディレクトリ内で使用される領域の量。 単位: バイト |
| `tx_bytes` | function\$1name function\$1name、バージョン | 関数の送信バイト数。 単位: バイト |
| `total_memory` | function\$1name function\$1name、バージョン | Lambda 関数に割り当てられたメモリの量。これは関数のメモリサイズと同じです。 単位: メガバイト |
| `total_network` | function\$1name function\$1name、バージョン | `rx_bytes` と `tx_bytes` の合計。I/O タスクを実行しない関数の場合でも、Lambda ランタイムによって行われるネットワーク呼び出しのため、この値は通常 0 より大きくなります。 単位: バイト |
| `used_memory_max` | function\$1name function\$1name、バージョン | 関数サンドボックスの測定されたメモリ。 単位: メガバイト |
以下のメトリクスは、CloudWatch Logs Insights を使用して、埋め込みメトリクスフォーマットのログエントリにあります。CloudWatch Logs Insights の詳細については、「[CloudWatch Logs Insights を使用したログデータの分析](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)」を参照してください。
埋め込みメトリックフォーマットの詳細については、「[ログ内へのメトリクスの埋め込み](CloudWatch_Embedded_Metric_Format.md)」を参照してください。
| メトリクス名 | 説明 |
| --- | --- |
| `agent_version` | Lambda 関数で実行されている Lambda Insights 拡張機能エージェントの現在のバージョン。 単位: 文字列 |
| `cpu_user_time` | CPU がユーザーコードの実行に費やした時間。 単位: ミリ秒 |
| `cpu_system_time` | CPU がカーネルコードの実行に費やした時間。 単位: ミリ秒 |
| `cpu_total_time` | `cpu_system_time` と `cpu_user_time` の合計。 単位: ミリ秒 |
| `fd_use` | 現在使用中のファイル記述子。 単位: カウント |
| `fd_max` | 使用できるファイル記述子の最大数。 単位: カウント |
| `version` | 他のメトリクスが収集された Lambda 関数のバージョン。 単位: カウント |
| `agent_memory_max` | Lambda Insights 拡張機能エージェントが消費するメモリ量の最大値。 単位: バイト |
| `agent_memory_avg` | Lambda Insights 拡張機能エージェントが消費するメモリ量の平均値。 単位: バイト |
| `memory_utilization` | 実行環境に割り当てられたメモリ量に対する、実測メモリ平均値の割合。 単位: パーセント |
| `used_memory_max` | 関数の実行環境におけるメモリ測定値。 単位: メガバイト |
| `rx_bytes` | 関数の受信バイト数。 単位: バイト |
| `tx_bytes` | 関数の送信バイト数。 単位: バイト |
| `threads_max` | 関数プロセスで使用中のスレッドの数。関数の作成者は、ランタイムによって作成されたスレッドの初期数を制御しません。 単位: カウント |
| `tmp_used` | `/tmp` ディレクトリ内で使用される領域の量。 単位: バイト |
| `tmp_max` | `/tmp` ディレクトリで使用可能な領域の量。 単位: バイト |
| `total_memory` | Lambda 関数に割り当てられたメモリの量。これは関数のメモリサイズと同じです。 単位: メガバイト |
| `total_network` | `rx_bytes` と `tx_bytes` の合計。I/O タスクを実行しない関数の場合でも、Lambda ランタイムによって行われるネットワーク呼び出しのため、この値は通常 0 より大きくなります。 単位: バイト |
# マネージドインスタンスの Lambda 関数
次のメトリクスは、マネージドインスタンスで実行されている Lambda 関数の `LambdaInsights` 名前空間の CloudWatch Metrics で時系列集計データとして使用できます。
| メトリクス名 | ディメンション | 説明 |
| --- | --- | --- |
| `cpu_utilization` | function\$1name function\$1name、バージョン | 実行環境に割り当てられた vCPU に対する、平均 CPU 使用率の割合。 単位: パーセント |
| `cpu_utilization_max` | function\$1name function\$1name、バージョン | 実行環境に割り当てられた vCPU の割合として測定される最大 CPU 使用率。これは 1 秒間隔でサンプリングされます。 単位: パーセント |
| `cpu_total_time` | function\$1name function\$1name、バージョン | `cpu_system_time` と `cpu_user_time` の合計。 単位: ミリ秒 |
| `memory_utilization` | function\$1name function\$1name、バージョン | 実行環境に割り当てられたメモリ量に対する、実測メモリ平均値の割合。 単位: パーセント |
| `memory_utilization_max` | function\$1name function\$1name、バージョン | 実行環境に割り当てられたメモリの割合として測定されるメモリの最大量。これは 50 ms 間隔でサンプリングされます。 単位: パーセント |
| `used_memory_max` | function\$1name function\$1name、バージョン | 関数の実行環境におけるメモリ測定値。 単位: メガバイト |
| `rx_bytes` | function\$1name function\$1name、バージョン | 関数の受信バイト数。 単位: バイト |
| `tmp_free` | function\$1name function\$1name、バージョン | `/tmp` ディレクトリで使用可能な領域の量。 単位: バイト |
| `tmp_used` | function\$1name function\$1name、バージョン | `/tmp` ディレクトリ内で使用される領域の量。 単位: バイト |
| `tx_bytes` | function\$1name function\$1name、バージョン | 関数の送信バイト数。 単位: バイト |
| `total_memory` | function\$1name function\$1name、バージョン | Lambda 関数に割り当てられたメモリの量。これは関数のメモリサイズと同じです。 単位: メガバイト |
| `total_network` | function\$1name function\$1name、バージョン | `rx_bytes` と `tx_bytes` の合計。I/O タスクを実行しない関数の場合でも、Lambda ランタイムによって行われるネットワーク呼び出しのため、この値は通常 0 より大きくなります。 単位: バイト |
| `used_memory_max` | function\$1name function\$1name、バージョン | 関数サンドボックスの測定されたメモリ。 単位: メガバイト |
以下のメトリクスは、CloudWatch Logs Insights を使用して、埋め込みメトリクスフォーマットのログエントリにあります。CloudWatch Logs Insights の詳細については、「[CloudWatch Logs Insights を使用したログデータの分析](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)」を参照してください。
埋め込みメトリックフォーマットの詳細については、「[ログ内へのメトリクスの埋め込み](CloudWatch_Embedded_Metric_Format.md)」を参照してください。
| メトリクス名 | 説明 |
| --- | --- |
| `lambda_mode` | このログイベントが Lambda マネージドインスタンスで実行されている関数用であるかどうかを示します。このフィールドがログイベントに存在する場合、1 つの値 `managed-instance` のみを取ります。このフィールドがない場合、関数が通常の Lambda 関数だったことを示します。 単位: 文字列 |
| `agent_version` | Lambda 関数で実行されている Lambda Insights 拡張機能エージェントの現在のバージョン。 単位: 文字列 |
| `cpu_utilization` | 実行環境に割り当てられた vCPU に対する、平均 CPU 使用率の割合。 単位: パーセント |
| `cpu_utilization_max` | 実行環境に割り当てられた vCPU の割合として測定される最大 CPU 使用率。これは 1 秒間隔でサンプリングされます。 単位: パーセント |
| `cpu_user_time` | CPU がユーザーコードの実行に費やした時間。 単位: ミリ秒 |
| `cpu_system_time` | CPU がカーネルコードの実行に費やした時間。 単位: ミリ秒 |
| `cpu_total_time` | `cpu_system_time` と `cpu_user_time` の合計。 単位: ミリ秒 |
| `fd_use` | 現在使用中のファイル記述子。 単位: カウント |
| `fd_max` | 使用できるファイル記述子の最大数。 単位: カウント |
| `execution_environment_init` | この関数に対して新しい実行環境がスピンアップされたかどうかを示すブール値。 単位: ブール |
| `version` | 他のメトリクスが収集された Lambda 関数のバージョン。 単位: カウント |
| `agent_memory_max` | Lambda Insights 拡張機能エージェントが消費するメモリ量の最大値。 単位: バイト |
| `agent_memory_avg` | Lambda Insights 拡張機能エージェントが消費するメモリ量の平均値。 単位: バイト |
| `memory_utilization` | 実行環境に割り当てられたメモリ量に対する、実測メモリ平均値の割合。 単位: パーセント |
| `memory_utilization_max` | 実行環境に割り当てられたメモリの割合として測定されるメモリの最大量。これは 50 ms 間隔でサンプリングされます。 単位: パーセント |
| `used_memory_max` | 関数の実行環境におけるメモリ測定値。 単位: メガバイト |
| `rx_bytes` | 関数の受信バイト数。 単位: バイト |
| `tx_bytes` | 関数の送信バイト数。 単位: バイト |
| `threads_max` | 関数プロセスで使用中のスレッドの数。関数の作成者は、ランタイムによって作成されたスレッドの初期数を制御しません。 単位: カウント |
| `tmp_free` | `/tmp` ディレクトリで使用可能な領域の量。 単位: バイト |
| `tmp_used` | `/tmp` ディレクトリ内で使用される領域の量。 単位: バイト |
| `tmp_max` | `/tmp` ディレクトリで使用可能な領域の量。 単位: バイト |
| `total_memory` | Lambda 関数に割り当てられたメモリの量。これは関数のメモリサイズと同じです。 単位: メガバイト |
| `total_network` | `rx_bytes` と `tx_bytes` の合計。I/O タスクを実行しない関数の場合でも、Lambda ランタイムによって行われるネットワーク呼び出しのため、この値は通常 0 より大きくなります。 単位: バイト |
# CloudWatch Lambda Insights のトラブルシューティングと既知の問題
問題をトラブルシューティングする最初のステップは、Lambda Insights 拡張機能でデバッグログを有効にすることです。これを行うには、Lambda 関数に環境変数 `LAMBDA_INSIGHTS_LOG_LEVEL=info` を設定します。詳細については、[AWS Lambda 環境変数の使用](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html)を参照してください。
拡張機能は、関数と同じロググループ (`/aws/lambda/function-name)`) にログを放出します。これらのログを確認して、エラーがセットアップの問題に関連しているかどうかを確認します。
## Lambda Insights からのメトリクスが表示されません
表示されるべき Lambda Insights メトリクスが表示されない場合は、次の可能性をチェックしてください。
+ **メトリクスが遅れている** – 関数がまだ呼び出されていない場合、またはデータがまだフラッシュされていない場合は、メトリクスは CloudWatch に表示されません。詳細については、このセクションの後半の「**既知の問題**」をご参照ください。
+ **Lambda 関数が正しいアクセス許可を持っていることを確認する** – **CloudWatchLambdaInsightsExecutionRolePolicy** IAM ポリシーが関数の実行ロールに割り当てられていることを確認します。
+ **Lambda ランタイムの確認** – Lambda Insights は特定の Lambda ランタイムのみをサポートします。サポートされているランタイムのリストについては、「[Lambda Insights](Lambda-Insights.md)」を参照してください。
例えば、Java 8 で Lambda Insights を使用するには、`java8` ランタイムではなく `java8.al2` ランタイムを使用する必要があります。
+ **ネットワークアクセスを確認する** – この Lambda 関数は、インターネットにアクセスできない VPC プライベートサブネット上にあり、CloudWatch Logs のために VPC エンドポイントがに設定されていない可能性があります。この問題のデバッグに役立てるために、環境変数 `LAMBDA_INSIGHTS_LOG_LEVEL=info` を設定できます。
## 既知の問題
最長データ遅延は 20 分です。関数ハンドラーが完了すると、Lambda はサンドボックスをフリーズし、Lambda Insights 拡張機能もフリーズします。関数の実行中は、関数 TPS に基づくアダプティブバッチ戦略を使用してデータを出力します。ただし、関数が長期間呼び出されなくなり、バッファにイベントデータが残っている場合は、Lambda がアイドル状態のサンドボックスをシャットダウンするまでこのデータを遅延させることができます。Lambda がサンドボックスをシャットダウンすると、バッファされたデータはフラッシュされます。
# CloudWatch Lambda Insights のテレメトリイベントの例
Lambda Insights が有効になっている Lambda 関数の呼び出しごとに、`/aws/lambda-insights` ロググループに 1 つのログイベントが書き込まれます。各ログイベントには、埋め込みメトリックフォーマットにメトリクスが含まれます。埋め込みメトリックフォーマットの詳細については、「[ログ内へのメトリクスの埋め込み](CloudWatch_Embedded_Metric_Format.md)」を参照してください。
これらのログイベントを分析するには、以下の方法を使用できます。
+ CloudWatch コンソールの Lambda Insights セクション (「[Lambda Insights メトリクスの表示](Lambda-Insights-view-metrics.md)」を参照)。
+ CloudWatch Logs Insights を使用してイベントクエリをログに記録します。詳細については、[Analyzing Log Data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) を参照してください。
+ `LambdaInsights` 名前空間で収集されるメトリクス。これは、CloudWatch メトリクスを使用してグラフ化します。
以下は、埋め込みメトリクスフォーマットの Lambda Insights ログイベントの例です。
```
{
"_aws": {
"Timestamp": 1605034324256,
"CloudWatchMetrics": [
{
"Namespace": "LambdaInsights",
"Dimensions": [
[ "function_name" ],
[ "function_name", "version" ]
],
"Metrics": [
{ "Name": "memory_utilization", "Unit": "Percent" },
{ "Name": "total_memory", "Unit": "Megabytes" },
{ "Name": "used_memory_max", "Unit": "Megabytes" },
{ "Name": "cpu_total_time", "Unit": "Milliseconds" },
{ "Name": "tx_bytes", "Unit": "Bytes" },
{ "Name": "rx_bytes", "Unit": "Bytes" },
{ "Name": "total_network", "Unit": "Bytes" },
{ "Name": "init_duration", "Unit": "Milliseconds" }
]
}
],
"LambdaInsights": {
"ShareTelemetry": true
}
},
"event_type": "performance",
"function_name": "cpu-intensive",
"version": "Blue",
"request_id": "12345678-8bcc-42f7-b1de-123456789012",
"trace_id": "1-5faae118-12345678901234567890",
"duration": 45191,
"billed_duration": 45200,
"billed_mb_ms": 11571200,
"cold_start": true,
"init_duration": 130,
"tmp_free": 538329088,
"tmp_max": 551346176,
"threads_max": 11,
"used_memory_max": 63,
"total_memory": 256,
"memory_utilization": 24,
"cpu_user_time": 6640,
"cpu_system_time": 50,
"cpu_total_time": 6690,
"fd_use": 416,
"fd_max": 32642,
"tx_bytes": 4434,
"rx_bytes": 6911,
"timeout": true,
"shutdown_reason": "Timeout",
"total_network": 11345,
"agent_version": "1.0.72.0",
"agent_memory_avg": 10,
"agent_memory_max": 10
}
```
以下は、Lambda マネージドインスタンスで実行されている Lambda 関数の Lambda Insights ログイベントの例です。
```
{
"total_network": 16443,
"tmp_free": 531492864,
"total_memory": 2048,
"fd_use": 85,
"tmp_used": 11984896,
"execution_environment_init": false,
"version": "3",
"event_type": "performance",
"agent_memory_max": 6,
"fd_max": 1024,
"function_name": "cpu-intensive",
"tx_bytes": 8404,
"memory_utilization": 3,
"used_memory_max": 73,
"memory_utilization_max": 3,
"cpu_system_time": 541,
"threads_max": 49,
"tmp_max": 543477760,
"cpu_utilization_max": 2,
"agent_memory_avg": 6,
"cpu_total_time": 815,
"rx_bytes": 8039,
"lambda_mode": "managed-instance",
"agent_version": "1.0.660.0",
"_aws": {
"CloudWatchMetrics": [
{
"Namespace": "LambdaInsights",
"Dimensions": [
[
"function_name"
],
[
"function_name",
"version"
]
],
"Metrics": [
{
"Name": "cpu_total_time",
"Unit": "Milliseconds"
},
{
"Name": "cpu_utilization",
"Unit": "Percent"
},
{
"Name": "cpu_utilization_max",
"Unit": "Percent"
},
{
"Name": "tx_bytes",
"Unit": "Bytes"
},
{
"Name": "rx_bytes",
"Unit": "Bytes"
},
{
"Name": "total_network",
"Unit": "Bytes"
},
{
"Name": "used_memory_max",
"Unit": "Megabytes"
},
{
"Name": "memory_utilization",
"Unit": "Percent"
},
{
"Name": "memory_utilization_max",
"Unit": "Percent"
},
{
"Name": "total_memory",
"Unit": "Megabytes"
},
{
"Name": "tmp_used",
"Unit": "Bytes"
},
{
"Name": "tmp_free",
"Unit": "Bytes"
}
]
}
],
"Timestamp": 1764164871353,
"LambdaInsights": {
"ShareTelemetry": true
}
},
"cpu_utilization": 1,
"cpu_user_time": 273
}
```
# CloudWatch Database Insights
CloudWatch Database Insights を使用して、Amazon Aurora MySQL、Amazon Aurora PostgreSQL、Amazon Aurora PostgreSQL Limitless、Amazon RDS for SQL Server、RDS for MySQL、RDS for PostgreSQL、RDS for Oracle、RDS for MariaDB データベースを大規模にモニタリングおよびトラブルシューティングします。
Database Insights を使用すると、事前に構築された独自ダッシュボードでデータベースフリートをモニタリングできます。フリートのパフォーマンスの分析を支援するため、Database Insights ダッシュボードにはキュレートされたメトリクスおよび視覚化機能が表示されます。これらのダッシュボードはカスタマイズが可能です。フリートのすべてのデータベースに 1 つのダッシュボードにメトリクスを表示することにより、Database Insights はデータベースを同時にモニタリングできるようにします。
例えば、 Database Insights を使用して、数百のデータベースインスタンスのフリート内でパフォーマンスが低いデータベースを見つけることができます。その後、そのインスタンスを選択し、Database Insights を使用して問題のトラブルシューティングを行うことができます。
エンジン、AWS リージョン、インスタンスクラスのサポートについては、「[Aurora DB エンジン、リージョン、インスタンスクラスの Database Insights のサポート](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_DatabaseInsights.Engines.html)」および「[Amazon RDS DB engine, Region, and instance class support for Database Insights](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DatabaseInsights.Engines.html)」を参照してください。
Database Insights は、複数のアカウントとリージョンのワークロードのモニタリングをサポートしています。Database Insights のクロスアカウントクロスリージョンモニタリング機能の詳細については、「[CloudWatch Database Insights のクロスアカウントクロスリージョンモニタリングの設定](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Cross-Account-Cross-Region.html)」を参照してください。
Database Insights の使用を開始するには、次のトピックを参照してください。
**トピック**
+ [CloudWatch Database Insights の使用を開始する](Database-Insights-Get-Started.md)
+ [CloudWatch Database Insights の Fleet Health Dashboard の表示](Database-Insights-Fleet-Health-Dashboard.md)
+ [CloudWatch Database Insights のデータベースインスタンスダッシュボードの表示](Database-Insights-Database-Instance-Dashboard.md)
+ [CloudWatch Database Insights のトラブルシューティング](Database-Insights-Troubleshooting.md)
## Database Insights のモード
Database Insights にはアドバンストモードおよびスタンダードモードがあります。スタンダードモードは Database Insights のデフォルトであり、データベースのアドバンストモードを有効にできます。
次の表では、CloudWatch が Database Insights のアドバンストモードおよびスタンダードモードでサポートする機能が示されます。
| 機能 | スタンダードモード | アドバンストモード |
| --- | --- | --- |
| DB Load の上位の寄与要因をディメンション別で分析する | サポート対象 | サポート |
| 最大 7 日間の保持期間を持つデータベースメトリクスにクエリ、グラフ、アラーム設定をする | サポート対象 | サポート |
| きめ細かなアクセスコントロールポリシーを定義し、SQL テキストなどの機密性の高いディメンションへのアクセス権を制限する | サポート対象 | サポート |
| 実行中のプロセスごとに詳細なメトリクスを使用して、データベースで発生しているオペレーティングシステムのプロセスを分析する この機能を使用するには、[Amazon RDS 拡張モニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights_Counters.html)が必要です。 | サポート外 | サポート |
| フリート全体のモニタリングビューを定義して保存し、データベースの状態を大規模に評価する | サポート外 | サポート |
| 15 ヶ月の保持期間とガイド付き UX の環境で SQL ロックを分析する | サポートされていません | Aurora PostgreSQL でのみサポート |
| 15 か月間の保持とガイド付き UX の環境で SQL 実行プランを分析する | サポートされていません | Aurora PostgreSQL、RDS for Oracle、および RDS for SQL Server でのみ対応 |
| クエリごとの統計を視覚化する | サポート外 | サポート |
| 遅い SQL クエリを分析するこの機能を使用するには、データベースログを CloudWatch Logs にエクスポートする必要があります。 | サポート外 | サポート |
| CloudWatch Application Signals を使用して通話サービスを表示する | サポート外 | サポート |
| メトリクス、ログ、イベント、アプリケーションを含め、すべてのデータベーステレメトリの統合ダッシュボードを表示するDatabase Insights コンソールでデータベースログを表示するには、CloudWatch Logs へのデータベースログのエクスポートが必要です。 | サポート外 | サポート |
| Performance Insights のカウンターメトリクスを CloudWatch に自動的にインポートする | サポート外 | サポート |
| CloudWatch で Amazon RDS イベントを表示する | サポート外 | サポート |
| オンデマンド分析を使用し、選択した期間のデータベースのパフォーマンスを分析する | サポート外 | サポート |
**注記**
Database Insights 機能の可用性は、すべての AWS リージョンで利用できるわけではなく、リージョンごとに異なります。
## データ保持
Database Insights のアドバンストモードは、Performance Insights によって収集された 15 ヶ月分のメトリクスを保持します。
Performance Insights がスタンダードモードで有効になっている場合、Amazon RDS は 7 日分の Performance Insights カウンターメトリクスを保持します。
Performance Insights のカウンターメトリクスの詳細については、「[Performance Insights カウンターメトリクス](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights_Counters.html)」を参照してください。
Database Insights によって収集された CloudWatch メトリクスの保持期間の詳細については、次のトピックを参照してください。
+ *Amazon Aurora ユーザーガイド*の [Amazon Aurora の Amazon CloudWatch メトリクス](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMonitoring.Metrics.html)
+ 「*Amazon RDS ユーザーガイド*」の「[Amazon Relational Database Service の Amazon CloudWatch メトリクス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-metrics.html)」
+ 「*Amazon Aurora ユーザーガイド*」の[Amazon RDS Performance Insights の Amazon CloudWatch メトリクス](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Cloudwatch.html)
+ 「*Amazon Aurora ユーザーガイド*」の[Amazon RDS Performance Insights の Amazon CloudWatch メトリクス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.Cloudwatch.html)
## Database Insights と Performance Insights の統合方法
Performance Insights はデータベースパフォーマンスのモニタリングサービスです。
Database Insights は、Performance Insights の機能を構築して拡張します。Database Insights はモニタリング、分析、最適化の機能を追加します。
Database Insights のアドバンストモードを有効にするには、Performance Insights を有効にする必要があります。
Database Insights は、Performance Insights カウンターメトリクスを自動的に CloudWatch にインポートします。Database Insights のアドバンストモードは、Performance Insights メトリクスや CloudWatch メトリクスなど、 Database Insights によって収集されたすべてのメトリクスを 15 か月自動的に保持します。これは、インスタンスでアドバンストモードを有効にしたときに自動的に行われます。それ以上の設定は必要ありません。Performance Insights カウンターメトリクスの詳細については、「*Amazon Aurora ユーザーガイド*」の「[Performance Insights カウンターメトリクス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights_Counters.html)」を参照してください。
## 料金
料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」を参照してください。
# CloudWatch Database Insights の使用を開始する
Database Insights の標準モードは、Amazon RDS データベースと Aurora データベースに対してデフォルトで有効になっています。Database Insights の詳細モードの使用を開始するには、新しいデータベースを作成するか、データベースを変更します。
Amazon RDS データベースの Database Insights の詳細モードまたは標準モードを有効にする方法については、以下のトピックを参照してください。
+ 「*Amazon RDS ユーザーガイド*」の「[Amazon RDS の Database Insights の詳細モードを有効にする](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DatabaseInsights.TurningOnAdvanced.html)」
+ 「*Amazon RDS ユーザーガイド*」の「[Amazon RDS の Database Insights の標準モードを有効にする](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DatabaseInsights.TurningOnStandard.html)」
+ 「*Amazon RDS ユーザーガイド*」の「[Amazon RDS の DB インスタンスまたはマルチ AZ DB クラスターの作成時に CloudWatch Database Insights をオンまたはオフにする](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DatabaseInsights.TurnOnCreateDatabase.html)」
Amazon Aurora データベースの Database Insights の詳細モードまたは標準モードを有効にする方法については、以下のトピックを参照してください。
+ 「*Amazon Aurora ユーザーガイド*」の「[Amazon Aurora の Database Insights の詳細モードを有効にする](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_DatabaseInsights.TurningOnAdvanced.html)」
+ 「*Amazon Aurora ユーザーガイド*」の「[Amazon Aurora の Database Insights の標準モードを有効にする](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_DatabaseInsights.TurningOnStandard.html)」
Aurora PostgreSQL Limitless Database の Database Insights の詳細モードまたは標準モードを有効にする方法については、以下のトピックを参照してください。
+ 「*Amazon Aurora ユーザーガイド*」の「[Aurora PostgreSQL Limitless Database の Database Insights のアドバンストモードを有効にする](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/limitless-monitoring.cwdbi.advanced.html)」
+ 「*Amazon Aurora ユーザーガイド*」の「[Aurora PostgreSQL Limitless Database の Database Insights のスタンダードモードを有効にする](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/limitless-monitoring.cwdbi.standard.html)」
## Database Insights に必要なアクセス許可
Database Insights を使用するには、特定の IAM アクセス許可が必要です。Database Insights には、CloudWatch、CloudWatch Logs、Amazon RDS、および Amazon RDS Performance Insights のアクセス許可が必要です。より広範なアクセス許可がある場合は、これらのアクセス許可をユーザーまたはロールに提供する必要がない場合があります。
Database Insights を使用するには、次の CloudWatch アクセス許可が必要です。
+ `cloudwatch:BatchGetServiceLevelIndicatorReport`
+ `cloudwatch:DescribeAlarms`
+ `cloudwatch:GetDashboard`
+ `cloudwatch:GetMetricData`
+ `cloudwatch:ListMetrics`
+ `cloudwatch:PutDashboard`
Database Insights を使用するには、次の CloudWatch Logs アクセス許可が必要です。
+ `logs:DescribeLogGroups`
+ `logs:GetQueryResults`
+ `logs:StartQuery`
+ `logs:StopQuery`
Database Insights を使用するには、次の Amazon RDS アクセス許可が必要です。
+ `rds:DescribeDBClusters`
+ `rds:DescribeDBInstances`
+ `rds:DescribeEvents`
+ `rds:DescribeDBShardGroups` (Aurora PostgreSQL Limitless Databases をモニタリングしている場合)
Database Insights を使用するには、次の Performance Insights アクセス許可が必要です。
+ `pi:ListAvailableResourceMetrics`
+ `pi:ListAvailableResourceDimensions`
+ `pi:DescribeDimensionKeys`
+ `pi:GetDimensionKeyDetails`
+ `pi:GetResourceMetrics`
+ `pi:ListPerformanceAnalysisReports`
+ `pi:GetResourceMetadata`
+ `pi:GetPerformanceAnalysisReport`
+ `pi:CreatePerformanceAnalysisReport`
+ `pi:DeletePerformanceAnalysisReport`
+ `pi:ListTagsForResource`
+ `pi:TagResource`
+ `pi:UntagResource`
次のサンプルポリシーには、Database Insights へのフルアクセスに必要なアクセス許可が含まれています。
### フルアクセスのサンプルポリシー
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect" : "Allow",
"Action" : [
"cloudwatch:BatchGetServiceLevelIndicatorReport",
"cloudwatch:DescribeAlarms",
"cloudwatch:GetMetricStatistics",
"cloudwatch:GetMetricData",
"cloudwatch:ListMetrics",
"cloudwatch:PutDashboard"
],
"Resource" : "*"
},
{
"Effect" : "Allow",
"Action" : [
"logs:DescribeLogGroups",
"logs:GetQueryResults",
"logs:StartQuery",
"logs:StopQuery"
],
"Resource" : "*"
},
{
"Effect" : "Allow",
"Action" : [
"pi:DescribeDimensionKeys",
"pi:GetDimensionKeyDetails",
"pi:GetResourceMetadata",
"pi:GetResourceMetrics",
"pi:ListAvailableResourceDimensions",
"pi:ListAvailableResourceMetrics",
"pi:CreatePerformanceAnalysisReport",
"pi:GetPerformanceAnalysisReport",
"pi:ListPerformanceAnalysisReports",
"pi:DeletePerformanceAnalysisReport",
"pi:TagResource",
"pi:UntagResource",
"pi:ListTagsForResource"
],
"Resource" : "arn:aws:pi:*:*:*/rds/*"
},
{
"Effect" : "Allow",
"Action" : [
"rds:DescribeDBInstances",
"rds:DescribeDBClusters",
"rds:DescribeEvents"
],
"Resource" : "*"
}
]
}
```
------
# CloudWatch Database Insights のクロスアカウントクロスリージョンのモニタリングを設定する
CloudWatch Database Insights は、クロスアカウントおよびクロスリージョンデータベースフリートのモニタリングをサポートし、データベース AWS インフラストラクチャ全体で一元的なオブザーバビリティを実現します。これにより、単一の統合コンソールエクスペリエンスから、複数の AWS アカウントやリージョンにまたがるデータベースをモニタリング、トラブルシューティング、最適化できます。
**Topics**
+ [
## 前提条件
](#Database-Insights-Cross-Account-Cross-Region-Prereq)
+ [
## Database Insights クロスアカウントアクセスのモニタリングアカウントとソースアカウントを設定する
](#Database-Insights-Cross-Account-Cross-Region-MonitoringSourceAccountSetup)
+ [
## クロスアカウントクロスリージョンコンソール用の Database Insights を設定する
](#Database-Insights-Cross-Account-Cross-Region-setup)
+ [
## Database Insights クロスアカウントクロスリージョンダッシュボードの使用
](#Database-Insights-Cross-Account-Cross-Region-Using)
## 前提条件
+ Database Insights クロスアカウントクロスリージョンでは、**CloudWatch クロスアカウントオブザーバビリティ**と**クロスアカウントクロスリージョン CloudWatch コンソール**の両方を最初に設定する必要があります。両方を有効にする方法については、以下の手順を参照してください。
+ 既に有効にしている場合でも、環境内のアカウントやリージョン間で Database Insights が機能するように、追加のデータ共有を設定する必要がある場合があります。以下の手順を参照して、適切なデータ共有設定が選択されていることを確認してください。
## Database Insights クロスアカウントアクセスのモニタリングアカウントとソースアカウントを設定する
1. [CloudWatch クロスアカウントオブザーバビリティ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account-Setup.html)のステップバイステップガイドに従います。Infrastructure as Code デプロイ用に CloudFormation テンプレートが提供されています。
1. **ステップ 1: モニタリングアカウントの設定**では、Database Insights がアカウントとリージョンをまたいで動作するように、少なくとも次のデータタイプを選択してモニタリングアカウントと共有する必要があります: **ログ**、**メトリクス**、**トレース**、**アプリケーションシグナル - サービス、サービスレベル目標 (SLO)**。
1. このプロセスは、Database Insights をクロスアカウントクロスリージョンサポートで設定する**すべてのリージョン**で実行する必要があります。
## クロスアカウントクロスリージョンコンソール用の Database Insights を設定する
1. [クロスアカウントクロスリージョン CloudWatch コンソール](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cross-Account-Cross-Region.html)のステップバイステップガイドに従います。
1. **ステップ 5: アクセス許可**では、少なくとも次のデータタイプを選択してモニタリングアカウントと共有する必要があります: **CloudWatch 自動ダッシュボードを含める**、および **Database Insights の読み取り専用アクセスを含める。**その代わりに、**アカウント内のすべてへのフル読み取り専用アクセス**を選択することもできます。これにより、利用可能なすべてのデータソースが含まれます。
1. CloudWatch クロスリージョンコンソールはグローバル設定であるため、このステップは 1 回だけ必要で、すべてのリージョンに作用します。
## Database Insights クロスアカウントクロスリージョンダッシュボードの使用
クロスアカウントクロスリージョンサポート用に Database Insights を設定したら、**[データベースビュー]** のすぐ下にある左側のパネルの **[フィルター]** セクションで「クロスアカウントクロスリージョンモード」を有効にできます。以下のスクリーンショットのように、左上隅にトグルボタンが表示されます。
![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/database-insights-enable-cross-account-toggle.png)
クロスアカウントクロスリージョンモードを有効にすると、新しいフィルターが利用可能になります。これにより、複数のリージョンを選択し、AWS アカウントの ID とラベル、データベースリソースタイプ、データベースリソース識別子でフィルタリングできます。
デフォルトでは、現在のリージョンとすべてのアカウントが選択されます。リージョンとアカウントの選択を変更すると、フリートヘルスダッシュボードは自動的に更新され、選択したリージョンとアカウントフィルターに一致するリソースが表示されます。
フリートヘルスダッシュボードから、他の AWS アカウントやリージョンに属するインスタンスのデータベースインスタンスダッシュボードに簡単に移動できます。
Database Insights のクロスアカウントクロスリージョンモニタリングを使用する際は、次のようにいくつかの点を考慮する必要があります。
+ アラームは、モニタリングアカウントでのみ作成する必要があります。アラームはソースアカウントからのメトリクスに設定できますが、モニタリングアカウントで作成する必要があります。
+ フリートモニタリングビューは、モニタリングアカウントでのみ定義して保存する必要があります。
+ Database Insights インスタンスダッシュボードのカスタムメトリクスダッシュボードは、モニタリングアカウントでのみカスタマイズする必要があります。
+ 特定の時点で Database Insights フリートヘルスダッシュボードで許可されるリージョンの最大数は 3 です。
+ モニタリングアカウントからは読み取りオペレーションのみが許可されます。つまり、モニタリングアカウントからパフォーマンス分析レポートを作成することはできません。
+ フリートヘルスダッシュボードでクロスアカウントクロスリージョンモードが有効になっている場合、AWS リソースタグとリソースプロパティによるフィルタリングは使用できません。
# CloudWatch Database Insights の Fleet Health Dashboard の表示
Fleet Health Dashboard を使用して、データベースフリートの状態のスナップショットを表示できます。
![\[Fleet Health Dashboard\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_fhd.png)
## フリートヘルスビュー
Database Insights の*データベースフリート*は、モニタリングするデータベースのグループです。**[フィルター]** コンポーネントでフィルターを選択することで、データベースフリートのモニタリングビューを作成できます。このコンポーネントを使用すると、クラスターやインスタンス名、タグなどのプロパティにフィルターを適用できます。Fleet Health Dashboard で、CloudWatch はフリートヘルスビューのフィルター条件の少なくとも 1 つに一致するデータベースを表示します。
![\[プロパティとタグでフィルタリングする\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_filter.png)
データベースフリートのビューを作成、変更、または削除するには、以下のトピックの手順を使用します。
+ [CloudWatch Database Insights のフリートヘルスビューを作成する](Database-Insights-fleet-views-create.md)
+ [CloudWatch Database Insights のフリートヘルスビューを編集する](Database-Insights-fleet-views-edit.md)
+ [CloudWatch Database Insights のフリートヘルスビューを削除する](Database-Insights-fleet-views-delete.md)
## RDS インスタンスの概要テーブル
**[RDS インスタンスの概要]**テーブルを使用して、フリート内の各インスタンスのアラーム状態、最大 DB ロード率、および最終状態更新時刻を表示します。
![\[Amazon RDS リソーステーブル\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_fhd-resources.png)
## インスタンス状態の概要
**[インスタンス状態の概要]** を使用して、フリート内のすべてのインスタンスの状態を表示します。インスタンス状態の概要には、**[アラーム]**と DB ロードメトリクスに基づく 2 つのビューが表示されます。デフォルトでは、CloudWatch は **[アラーム]** ビューを表示します。
![\[インスタンス状態の概要\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_iss.png)
Honeycomb の各ノードはインスタンスを表します。インスタンスの詳細については、対応するノードを選択し、**[このインスタンスによるフィルター表示]** を選択します。
![\[選択したインスタンスの状態の概要\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_iss-selected.png)
Honeycomb コンポーネントは、フリート内のインスタンスのアラーム状態を、各状態のノード数とともに、Honeycomb の上部にまとめます。CloudWatch は、Honeycomb に表示されたデータの最終更新時刻を表示します。
**[DB ロード]**ビューに切り替えると、DB ロードメトリクスの観点からフリートの全体的な状態を確認できます。データベースロード (DB ロード) は、データベース内のアクティブなセッション数を測定します。DB ロードは Database Insights の主要なメトリクスであり、毎秒収集されます。CloudWatch は、DB インスタンスを DB ロードのしきい値に基づいて次の状態に分類します。
+ 高
+ 警告
+ Ok
+ アイドル状態
対応する状態アイコンを選択すると、DB ロードのしきい値を確認できます。
Amazon RDS の DB ロードに関する詳細については、「*Amazon RDS ユーザーガイド*」の「[データベース負荷](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.ActiveSessions.html)」を参照してください。Amazon Aurora の DB ロードに関する詳細については、「*Amazon Aurora ユーザーガイド*」の「[データベースロード](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Overview.ActiveSessions.html)」を参照してください。
デフォルトでは、CloudWatch は平均 DB ロードを表示します。**[Max]** を選択して、各インスタンスの最大 DB ロードをモニタリングします。
インスタンス状態の概要からノードを選択すると、インスタンスのアラームと DB ロードが表示されます。
## 上位 10 個のグラフ
DB ロードが最も高い 10 個のインスタンスの DB ロードの経時的な傾向を表示するには、**[相対 DB ロードあたりの上位 10 個のインスタンス]** を使用します。このグラフには、DB ロードが最も高いインスタンスの上位クエリと上位待機イベントも表示されます。
![\[DB ロードグラフ別の上位 10 個のインスタンス\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_top10.png)
**[メトリクスグラフあたりの上位 10 個のインスタンス]**を使用して、フリート内の上位 10 個のインスタンスの 2 つの主要なメトリクスを比較します。次のメトリクスを選択することができます。
+ CPU 使用率 (%)
+ 解放可能なメモリ (%)
+ DB 接続 (%)
+ ネットワークスループット
+ 読み取り IOPS
+ 書き込み IOPS
+ 読み取りレイテンシー
+ 書き込みレイテンシー
![\[メトリクスグラフあたりの上位 10 個のインスタンス\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_fhd-top10per.png)
## Amazon RDS イベント
**[イベント]** の概要とテーブルを使用して、フリート内のインスタンスの RDS イベントを表示します。
![\[イベントの概要\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_events.png)
**[イベント]**テーブルを表示するには、**[詳細]** を選択します。
![\[イベントの詳細\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_events-details.png)
Amazon RDS と Amazon Aurora のイベントのリストについては、以下のトピックを参照してください。
+ 「*Amazon Aurora ユーザーガイド*」の「[Amazon RDS イベントカテゴリと Aurora のイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_Events.Messages.html)」
+ 「*Amazon RDS ユーザーガイド*」の「[Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Messages.html)」
## 呼び出しサービステーブル
**[呼び出しサービス]**テーブルを使用して、データベースエンドポイントを呼び出している CloudWatch Application Signals サービス、およびレイテンシーやエラーなどの関連するアプリケーションレベルのメトリクスを表示します。
![\[呼び出しサービステーブル\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_fhd-calling.png)
Database Insights には、DB ロードによって上位 10 個のインスタンスを呼び出しているサービスが表示されます。別のインスタンスの呼び出しサービスを表示するには、データベースインスタンスダッシュボードでインスタンスを選択します。
アプリケーションによって呼び出されるエンドポイントが Aurora クラスターの場合、 Database Insights は個々のデータベースインスタンスではなく、**[呼び出しサービス]** テーブルに Aurora クラスターのライターまたはリーダーエンドポイントを表示します。ただし、アプリケーションによって呼び出されるエンドポイントが Amazon RDS クラスターの場合、Database Insights には、アプリケーションが Amazon RDS クラスター内で呼び出す特定のデータベースインスタンスが表示されます。
CloudWatch Application Signals の詳細については、「[Application Signals](CloudWatch-Application-Monitoring-Sections.md)」を参照してください。
# CloudWatch Database Insights のフリートヘルスビューを作成する
フリートヘルスビューを作成するには、次の手順を使用します。
**フリートヘルスビューを作成するには**
1. AWS マネジメントコンソール にサインインして、CloudWatch コンソール ([https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)) を開きます。
1. **[Insights]** を選択します。
1. **[Database Insights]** を選択します。
1. モニタリングするデータベースのフリートのフィルターを選択します。
1. **[フィルターをフリートとして保存]** を選択します。
1. **[フィルターセットの保存 (フリート)]** ウィンドウで、フリートの名前を入力します。
1. **[保存]** ボタンを選択します。
保存したフリートにアクセスするには、**[保存したフリート]** ドロップダウンを選択します。次に、フリートを選択します。
# CloudWatch Database Insights のフリートヘルスビューを編集する
フリートのヘルスビューを編集するには、次の手順を使用します。
**フリートのヘルスビューを編集するには**
1. AWS マネジメントコンソール にサインインして、CloudWatch コンソール ([https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)) を開きます。
1. **[Insights]** を選択します。
1. **[Database Insights]** を選択します。
1. **[保存済みフリート]** ドロップダウンを選択します。
1. 編集するフリートヘルスビューの縦三点リーダーを選択します。
1. **[フィルターセット (フリート) の編集]** ウィンドウで、フリートの名前とフリートのフィルターを編集できます。
1. **[保存]** ボタンを選択します。
# CloudWatch Database Insights のフリートヘルスビューを削除する
フリートヘルスビューを削除するには、次の手順を使用します。
**フリートヘルスビューを削除するには**
1. AWS マネジメントコンソール にサインインして、CloudWatch コンソール ([https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)) を開きます。
1. **[Insights]** を選択します。
1. **[Database Insights]** を選択します。
1. **[保存済みフリート]** ドロップダウンを選択します。
1. 削除するフリートヘルスビューの縦三点リーダーを選択します。
1. **[フィルターセットの削除 (フリート)]** ウィンドウで、**[削除]** ボタンを選択します。
# CloudWatch Database Insights のデータベースインスタンスダッシュボードの表示
データベースインスタンスダッシュボードを使用して、DB インスタンスの正常性のスナップショットを表示します。
Amazon Aurora PostgreSQL のロックツリーと実行プランを分析するには、以下のトピックを参照してください。
**トピック**
+ [CloudWatch Database Insights を使用した Amazon Aurora PostgreSQL と Amazon RDS for PostgreSQL のロックツリーの分析](Database-Insights-Lock-Analysis.md)
+ [CloudWatch Database Insights を使用した実行プランの分析](Database-Insights-Execution-Plans.md)
## データベースロードのグラフ
*データベースロード (DB ロード)* は、データベース内のセッションアクティビティのレベルを測定します。DB ロードは Database Insights の主要なメトリクスであり、Database Insights は毎秒 DB ロードを収集します。
![\[データベースインスタンスダッシュボード\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_did.png)
詳細については、「*Amazon RDS ユーザーガイド*」の「[データベース負荷](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.ActiveSessions.html)」および「*Amazon Aurora ユーザーガイド*」の「[データベース負荷](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Overview.ActiveSessions.html)」を参照してください。
**[データベース負荷]** チャートを使用して、サポートされているすべてのデータベース・エンジンの DB ロードを以下のディメンションで分類（グループ化）して表示します。
+ オブジェクトのブロック ([database engines that support locking analysis](Database-Insights-Lock-Analysis.md)のみ）
+ セッションのブロック ([database engines that support locking analysis](Database-Insights-Lock-Analysis.md)のみ）
+ SQL のブロック ([database engines that support locking analysis](Database-Insights-Lock-Analysis.md)のみ）
+ データベース
+ ホスト
+ SQL
+ ユーザー
+ 待機
+ アプリケーション (Amazon Aurora PostgreSQL のみ)
+ 計画 ([database engines that support execution plan capture](Database-Insights-Execution-Plans.md)のみ）
+ セッションタイプ (Amazon Aurora PostgreSQL のみ)
**注記**
Amazon RDS での Oracle PDB 負荷の分析については、**「Amazon RDS ユーザーガイド」の「[Oracle PDB の上位負荷の分析](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.TopPDB.html)」を参照してください。
![\[データベースインスタンスダッシュボードの DB ロード\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_did-dbload.png)
デフォルトでは、CloudWatch は棒グラフで DB ロードを表示します。積み上げ折れ線グラフで DB ロードを表示するには、**[ライン]** を選択します。
![\[データベースインスタンスダッシュボードの DB ロードの折れ線グラフ\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_did-dbload-line.png)
## DB ロード分析タブ
**[DB ロード分析]** タブを使用して、以下の各ディメンションの DB ロードの上位の寄与要因をモニタリングします。
+ データベース
+ ホスト
+ SQL
+ ユーザー
+ 待機
+ ロック分析 ([database engines that support locking analysis](Database-Insights-Lock-Analysis.md)のみ）
+ アプリケーション (Amazon Aurora PostgreSQL のみ)
+ セッションタイプ (Amazon Aurora PostgreSQL のみ)
![\[DB 負荷分析タブを示すダッシュボード\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_lat.png)
## クエリの統計を分析する
DB ロードが高いクエリの統計を分析することができます。クエリの統計を分析するには、次の手順を使用します。
**クエリの統計を分析するには**
1. AWS マネジメントコンソール にサインインして、CloudWatch コンソール ([https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)) を開きます。
1. **[Insights]** を選択します。
1. **[Database Insights]** を選択します。
1. **[データベースインスタンス]** ビューを選択します。
1. DB インスタンスを選択します。
1. **[上位の SQL]** タブを選択します。
1. クエリの統計を表示するには、クエリを選択します。
![\[トップ SQL タブに表示されるテーブル。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/DBInsights_LoadTopSQL.png)
## [データベーステレメトリ] タブ
**[Database telemetry]** タブを使用して、選択したインスタンスのメトリクス、ログ、イベント、スロークエリを表示します。
### データベーステレメトリのメトリクスセクション
**[メトリクス]** セクションには、エンジンタイプごとにカスタマイズされたデフォルトメトリクスダッシュボードが表示されます。
このダッシュボードは、OS メトリクス、データベースカウンターメトリクス、CloudWatch メトリクスを追加することによってカスタマイズできます。ダッシュボードからメトリクスを削除することもできます。アカウントのリージョンで、エンジンタイプごとに 1 つのダッシュボードをカスタマイズできます。したがって、同じアカウントのそのリージョンにある特定のエンジンタイプのすべてのインスタンスに同じメトリクスダッシュボードが存在することになります。
アカウントのダッシュボードの編集アクセス許可を持つユーザーは、任意のエンジンのダッシュボードを編集できます。
ダッシュボードに加えた変更は自動的に保存され、そのリージョンとアカウントのデータベースエンジンのすべてのインスタンスに適用されます。
![\[さまざまなタイプのデータベースメトリクスの例を示すダッシュボード。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_dbmetrics.png)
**エンジンタイプの [データベーステレメトリ] タブでダッシュボードをカスタマイズするには**
1. AWS マネジメントコンソール にサインインして、CloudWatch コンソール ([https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)) を開きます。
1. **[インサイト]**、**[データベースインサイト]** を選択します。
1. **[データベースビュー]** で **[データベースインスタンス]** を選択します。
1. **[フィルター]** セクションで、メトリクスを表示するデータベースインスタンスを見つけて選択します。
1. **[データベーステレメトリ]** タブを選択し、**[メトリクス]** タブを選択します。
デフォルトのデータベースインスタンスダッシュボードが表示されます。
1. 表示にウィジェットを追加するには、次の手順を実行します。
1. **[ウィジェットの作成]** を選択します。
1. **[ウィジェットの作成]** ポップアップで、追加するメトリクスを見つけて、各メトリクスのチェックボックスを選択します。このステップで複数のメトリクスを選択すると、選択したすべてのメトリクスはダッシュボード上の同じ新しいウィジェットに表示されます。**[ウィジェットの作成]** を選択します。
このダッシュボードに加えた変更は、アカウントの当該リージョンの当該エンジンタイプのすべての Database Insights ダッシュボードに適用されます。
1. ダッシュボードからグラフを削除するには、縦の省略記号をウィジェットで選択して **[削除]** を選択します。
1. ダッシュボード内の既存のウィジェットにメトリクスを追加するか、そのタイトルを変更するには、縦の省略記号をウィジェットで選択して **[編集]** を選択します。次に、**[ウィジェットの更新]** ポップアップで、追加するメトリクスのチェックボックスをオンにして、**[ウィジェットの更新]** を選択します。ウィジェットのタイトルを変更することもできます。
1. カスタマイズしたダッシュボードは、**[Reset Dashboard]** を選択して元のデフォルト状態にリセットできます。
### データベーステレメトリのログセクション
**[ログ]** セクションには、選択した DB インスタンスの CloudWatch Logs にエクスポートされたデータベースログが表示されます。
![\[データベースインスタンスダッシュボードのデータベーステレメトリ\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_did-telemetry-logs.png)
Amazon RDS の CloudWatch Logs へのログの発行については、「*Amazon RDS ユーザーガイド*」の「[Amazon CloudWatch Logs へのデータベースログの発行](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Procedural.UploadtoCloudWatch.html)」を参照してください。Amazon Aurora の CloudWatch Logs へのログのパブリッシュについては、「*Amazon Aurora ユーザーガイド*」の「[データベースログを Amazon CloudWatch Logs に発行](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.Procedural.UploadtoCloudWatch.html)」を参照してください。
Aurora PostgreSQL Limitless Databases の場合、ログは自動的に CloudWatch Logs に発行され、Database Insights コンソールで検出できます。
### OS がデータベーステレメトリのデータを処理する
**[データベーステレメトリ]** タブ内の **[OS プロセス]** タブを使用して、DB インスタンスが実行されるオペレーティングシステム (OS) のメトリクスを表示できます。メトリクスは、特定のタイムスタンプに対してデータベースで実行されている OS プロセスのスナップショットや、実行中の各プロセスのメモリや CPU 使用率などの主要なメトリクスを提供します。Database Insights は、これらのメトリクスをデータベースロードチャートのメトリクスと関連付けます。これにより、データベースロードチャートのデータポイントを選択すると、OS は同じタイムスタンプからテレメトリを表示するようにデータを更新します。
データポイントを選択すると、 Database Insights は、ページ全体で選択した時間範囲に応じて、表示する期間を自動的に選択します。実行できる最も遠い時間は、`RDSOSMetrics` ロググループに設定した保持時間によって異なります。
タイムスタンプを選択していない場合、デフォルトでは、最新のタイムスタンプのテレメトリがテーブルに入力されます。
**注記**
OS プロセス情報は、[[Amazon RDS 拡張モニタリング]](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights_Counters.html) が有効になっている場合にのみ使用できます。拡張モニタリングには追加料金が発生します。詳細については、「[拡張モニタリングのコスト](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_Monitoring.OS.html#USER_Monitoring.OS.cost)」を参照してください。Aurora PostgreSQL Limitless Databases では、拡張モニタリングが自動的に有効になります。
![\[イベントテーブル\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbinsights-osprocesses.png)
**[OS プロセス]** ビューには、プロセスごとに次のデータが表示されます。
+ **プロセス ID** – このプロセスの ID。
+ **仮想メモリ** – プロセスに割り当てられた仮想メモリの量 (キビバイト単位) を表示します。
+ **残差アドレス** – プロセスが使用する実際の物理メモリを表示します。
+ **CPU %** – プロセスが使用する合計 CPU 帯域幅のパーセンテージを表示します。
+ **メモリ %**] – プロセスが使用する合計メモリのパーセンテージを表示します。
+ **VM 制限** – プロセスに割り当てることができる仮想メモリの最大量を表示します。
この列の値が 0 の場合、VM の制限はそのプロセスには適用されません。
表示するモニタリングデータは、Amazon CloudWatch Logs から取得されます。これらのメトリクスは、CloudWatch Logs のログストリームから直接取得することもできます。詳細については、「[CloudWatch Logs を使用した OS メトリクスの表示](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.CloudWatchLogs.html)」を参照してください
以下の場合、OS プロセスメトリクスは返されません。
+ データベースインスタンスのフェイルオーバー。
+ データベースインスタンスのインスタンスクラスの変更 (コンピューティングのスケール)。
データベース インスタンスの再起動中に OS プロセスメトリックが返されます。これはデータベースエンジンのみが再起動するためです。オペレーティングシステムのメトリクスは、引き続き報告されます。
### データベーステレメトリのスロー SQL クエリセクション
スロー SQL クエリとクエリパターンを表示するには、CloudWatch Logs へのログエクスポートを有効にし、データベースの DB パラメータを設定する必要があります。
CloudWatch Logs への Amazon RDS ログの発行については、「*Amazon RDS ユーザーガイド*」の「[Amazon CloudWatch Logs へのデータベースログの発行](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Procedural.UploadtoCloudWatch.html)」を参照してください。
CloudWatch Logs への Aurora のログの公開については、「*Amazon Aurora ユーザーガイド*」の「[Amazon CloudWatch Logs へのデータベースログの発行](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.Procedural.UploadtoCloudWatch.html)」を参照してください。
Amazon RDS のデータベースの DB パラメータの設定については、「*Amazon RDS ユーザーガイド*」の「[Configuring your database to monitor slow SQL queries with Database Insights for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DatabaseInsights.SlowSQL.html)」を参照してください。
Amazon Aurora のデータベースの DB パラメータの設定については、「*Amazon Aurora ユーザーガイド*」の「[Configuring your database to monitor slow SQL queries with Database Insights for Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_DatabaseInsights.SlowSQL.html)」を参照してください。
**[スロー SQL クエリ]** セクションには、頻度でソートされたスロークエリパターンのリストが表示されます。パターンを選択すると、選択したパターンに一致するスロークエリのリストを表示できます。スロークエリのリストを使用して、DB インスタンスに影響を与えるスロークエリを特定できます。
Database Insights では、スロークエリの統計が表示されます。統計は、設定されたスロークエリ期間のしきい値を超えるクエリのみを表します。
![\[スロー SQL クエリの例に関する詳細を表示します\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_slowsql.png)
**重要**
スロークエリには機密データが含まれている可能性があります。CloudWatch Logs で機密データをマスクします。ログデータのマスキングの詳細については、「*Amazon CloudWatch Logs ユーザーガイド*」の「[機密性の高いログデータをマスキングで保護する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/mask-sensitive-log-data.html)」を参照してください。
### イベントテーブル
**[イベント]** テーブルを使用して、DB インスタンスの RDS イベントを表示します。Amazon Aurora のイベントのリストについては、「*Amazon Aurora ユーザーガイド*」の「[Amazon RDS イベントカテゴリと Aurora のイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_Events.Messages.html)」を参照してください。Amazon Relational Database Service のイベントのリストについては、「*Amazon RDS ユーザーガイド*」の「[Aurora の Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_Events.Messages.html)」を参照してください。
![\[イベントテーブル\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_did-events.png)
## サービスタブの呼び出し
Database Insights には、インスタンスを呼び出しているサービスとオペレーションが表示されます。Database Insights は CloudWatch Application Signals と統合され、可用性、レイテンシー、エラー、ボリュームなど、各サービスとオペレーションのメトリクスを提供します。
アプリケーションによって呼び出されるエンドポイントが Aurora クラスターの場合、 Database Insights は個々のデータベースインスタンスではなく、**[呼び出しサービス]** テーブルに Aurora クラスターのライターまたはリーダーエンドポイントを表示します。ただし、アプリケーションによって呼び出されるエンドポイントが Amazon RDS クラスターの場合、 Database Insights には、アプリケーションが Amazon RDS クラスター内で呼び出す特定のデータベースインスタンスが表示されます。」
![\[サービスタブの呼び出し\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_did-calling.png)
## CloudWatch Database Insights を使用してデータベースのパフォーマンスをオンデマンドで分析する
CloudWatch Database Insights を使用して Amazon RDS データベースのオンデマンド分析でデータベースのパフォーマンスを分析します。
**[データベースロード]** チャートの右上隅にある **[パフォーマンスを分析]** を選択すると、オンデマンドのパフォーマンス分析を実行できます。選択した期間、レポートが実行されます。**[パフォーマンス分析]** タブを使用して、フリート内のデータベースのパフォーマンス分析レポートを表示します。
![\[パフォーマンス分析タブ\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_dl-perfanalysis.png)
Amazon Aurora のパフォーマンス分析レポートの詳細については、「*Amazon Aurora ユーザーガイド*」の「[一定期間のデータベースパフォーマンスの分析](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.UsingDashboard.AnalyzePerformanceTimePeriod.html)」を参照してください。
## CloudWatch Database Insights と CloudWatch Application Signals の統合
CloudWatch Database Insights を CloudWatch Application Signals と統合します。
選択したインスタンスのエンドポイントを呼び出した CloudWatch Application Signals のサービスとオペレーションを表示するには、**[呼び出しサービス]** タブを使用します。デフォルトでは、CloudWatch はテーブルを障害率でソートします。**[サービス]**、**[オペレーション]**、または **[エンドポイントのアドレス]** の列の値を選択して、CloudWatch Application Signals コンソールで対応するリソースを表示します。
CloudWatch Application Signals でサポートされているシステムの詳細については、「[サポートされているシステム](CloudWatch-Application-Signals-supportmatrix.md)」を参照してください。
# CloudWatch Database Insights を使用した Amazon Aurora PostgreSQL と Amazon RDS for PostgreSQL のロックツリーの分析
ロックによるパフォーマンスの問題をトラブルシューティングするには、以下を使用して CloudWatch Database Insights で Amazon Aurora PostgreSQL と Amazon RDS for PostgreSQL のデータベースのロックツリーを分析できます。
+ **[分類方法]** ドロップダウン – **データベース負荷**チャートで**ブロッキングオブジェクト**、**ブロッキングセッション**、または**ブロッキング SQL** ディメンションを選択すると、時間の経過とともに上位のブロッカーが DB 負荷にどのように影響するかが表示されます。DB 負荷チャートを使用すると、上位のブロッカーが一定であるか、頻繁に変化するかを分析できます。その後、ブロッカーのトラブルシューティングを行うことができます。
![\[[分類方法]ドロップダウンでブロックセッションが選択された[上位 SQL] テーブル\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/DBInsights_TopSQLBlocking.png)
+ **[ロック分析]** タブ – **[DB 負荷分析]** を選択し、**[ロック分析]** タブを選択して、データベース内のロック競合に関する情報を表示します。
![\[データベースロードダッシュボードの [ロックツリー] テーブル\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/DBInsights_LoadLockAnalysis.png)
**注記**
CloudWatch Database Insights は、すべての Aurora PostgreSQL バージョンのロック分析をサポートしています。ロックツリーを分析するには、 Database Insights アドバンスモードが有効になっている必要があります。アドバンストモードを有効にする方法については、「[Amazon Aurora で Database Insights のアドバンストモードを有効にする](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_DatabaseInsights.TurningOnAdvanced.html)」および「[Turning on the Advanced mode of Database Insights for Amazon Relational Database Service](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DatabaseInsights.TurningOnAdvanced.html)」を参照してください
[ロック分析] タブには、データベースのロック競合に関する情報が表示されます。ロックツリーの視覚化では、異なるセッションからのロックリクエスト間の関係と依存関係が表示されます。
Database Insights は 15 秒ごとにスナップショットをキャプチャします。スナップショットには、特定の時点でのデータベースのロックデータが表示されます。
**注記**
CloudWatch がハイロックを検出すると、CloudWatch は **[ロック分析]** タブの **[ハイロック検出]** バナーを表示します。CloudWatch は、15 秒ごとにロックのスナップショットを 15 分間連続して取得すると、高ロック状態と判断します。
ツリー内の各ノードは、特定のセッションを表します。親ノードは、子ノードをブロックしているセッションです。
ロックツリーを分析するには、次の手順を使用します。
**ロックツリーを分析するには**
1. AWS マネジメントコンソール にサインインして、CloudWatch コンソール ([https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)) を開きます。
1. **[Insights]** を選択します。
1. **[Database Insights]** を選択します。
1. **[データベースインスタンス]** ビューを選択します。
1. DB インスタンスを選択します。
1. **[DB 負荷分析]** タブを選択します。
1. **[ロック分析]** タブを選択します。
DB インスタンスのロックデータを表示するには、1 日以下の期間を選択します。
1. スナップショットウィンドウを選択します。デフォルトでは、Database Insights はブロックされたセッションが最も多いスナップショットウィンドウを選択します。
![\[ロック分析テーブル\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_lock-analysis.png)
1. スナップショットのロックデータを表示するには、 Database Insights がスナップショットを作成した時間を選択します。
1. ロックツリーを展開するには、セッション ID の横にある矢印を選択します。
![\[ロックツリーが展開されました\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_lock-analysis-expand.png)
## スナップショットデータのロック
Database Insights は、ロックリクエストごとに次の情報を提供します。デフォルトで有効になっていない列を表示するには、**ロックツリー**テーブルの **[設定]** アイコンを選択し、他の列を有効にします。
| 列名 | 定義 | デフォルト列 | 注意事項 |
| --- | --- | --- | --- |
| `session_id` | 一意のセッション識別子。 | あり | `session_id` は `HEX(pg_stat_activity.backend_start).HEX(pg_locks.pid)` から派生します。 |
| `pid` | このバックエンドの PID。 | あり | `pg_locks.pid` |
| `blocked_sessions_count` | このロックによってブロックされたセッションの数。 | あり | `blocked_sessions_count` は、このロックによってブロックされたセッション ID の数から算出されます。 |
| `last_query_executed` | このセッションで最後に実行されたクエリ。ブロッカーの場合、ブロッキングロックを保持しているのはクエリではない可能性があります。 | あり | `pg_stat_activity.query` |
| `wait_event` | バックエンドが現在待機中の場合は待機イベント名、それ以外の場合は値は NULL になります。 | あり | `pg_stat_activity.wait_event` |
| `blocking_time_(In Seconds)` | このロックの開始からの時間 (秒単位）。 | あり | `blocking_time_(In Seconds)` は、最初のウェーターの待機トランザクション (`pg_locks.waitstart`) の開始時刻から算出されます。 |
| `blocking_mode` | ブロッキングセッションによって保持されるロックモード。 | いいえ | `pg_locks.mode` |
| `waiting_mode` | 待機中のセッションによってリクエストされたロックモード。 | いいえ | `pg_locks.mode` |
| `application` | このバックエンドに接続されたアプリケーションの名前。 | いいえ | `pg_stat_activity.application_name` |
| `blocking_txn_start_time` | ブロッキングトランザクションの開始時刻、またはアクティブなトランザクションがない場合は null。 | いいえ | `pg_stat_activity.xact_start` |
| `waiting_start_time` | 待機中のユーザーセッションがこのロックの待機を開始した時刻、またはロックが保持されている場合は null 。 | いいえ | `pg_locks.waitstart` |
| `session_start_time` | ユーザー セッションが開始された時刻。 | いいえ | `pg_stat_activity.backend_start` |
| `state` | バックエンドの状態。 | いいえ | `pg_stat_activity.state` |
| `wait_event_type` | このセッションが待機している待機イベントタイプ。 | いいえ | `pg_stat_activity.wait_event_type` |
| `last_query_exec_time` | 最後のクエリが開始された時刻。 | いいえ | `pg_stat_activity.query_start` |
| `user` | このバックエンドにログインしたユーザー名。 | いいえ | `pg_stat_activity.usename` |
| `host` | 接続されたクライアントのホスト名 (`client_addr` の逆引き DNS 参照によって報告されたもの) このフィールドは、IP 接続かつ [log\$1hostname](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-HOSTNAME) が有効な場合にのみ非 null になります。 | いいえ | `pg_stat_activity.client_hostname` |
| `port` | クライアントがこのバックエンドとの通信に使用している TCP ポート番号。Unix ソケットを使用している場合は `-1`。このフィールドが null の場合は、これが内部サーバープロセスであることを示します。 | いいえ | `pg_stat_activity.client_port` |
| `client_address` | このバックエンドに接続されているクライアントの IP アドレス。このフィールドが null の場合、クライアントがサーバーマシンの Unix ソケットを介して接続されているか、autovacuum などの内部プロセスであることを示します。 | いいえ | `pg_stat_activity.client_addr` |
| `granted` | この値は、ロックが保持されている場合は true、ロックが待機している場合は false です。 | いいえ | `pg_locks.granted` |
| `waiting_tuple` | ページ内のロックの対象となるタプル番号。ターゲットがタプルでない場合は null。 | いいえ | `pg_locks.tuple` |
| `waiting_page` | リレーション内のロックの対象となるページ番号。ターゲットがリレーションページまたはタプルでない場合は null。 | いいえ | `pg_locks.page` |
| `waiting_transaction_id` | ロックの対象となるトランザクションの ID。ターゲットがトランザクション ID でない場合は null。 | いいえ | `pg_locks.transactionid` |
| `waiting_relation` | ロックの対象となるリレーションの OID。ターゲットがリレーションまたはリレーションの一部でない場合は null。 | いいえ | `pg_locks.relation` |
| `waiting_object_id` | システムカタログ内のロックターゲットの OID。ターゲットが一般的なデータベースオブジェクトでない場合は null。 | いいえ | `pg_locks.objid` |
| `waiting_database_id` | ロックターゲットが存在するデータベースの OID。ターゲットが共有オブジェクトの場合は 0、ターゲットがトランザクション ID の場合は null。 | いいえ | `pg_locks.database` |
| `waiting_database_name` | ロックターゲットが存在するデータベースの名前。 | いいえ | `pg_stat_activity.datname` |
| `waiting_locktype` | ロック可能なオブジェクトの種類: relation、extend、frozenid、page、tuple、transactionid、virtualxid、spectoken、object、userlock、advisory、applytransaction。 | いいえ | `pg_locks.locktype` |
| `is_fastpath` | この値は、ロックが高速パスで取得された場合は true、メインロックテーブルから取得された場合は false です。 | いいえ | `pg_locks.fastpath` |
`pg_stat_activity` および `pg_locks` ビューの値の詳細については、PostgreSQL ドキュメントの以下のトピックを参照してください。
+ [pg\$1locks](https://www.postgresql.org/docs/current/view-pg-locks.html)
+ [pg\$1stat\$1activity](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW)
# CloudWatch Database Insights を使用した実行プランの分析
Amazon Aurora PostgreSQL、RDS for Microsoft SQL Server、RDS for Oracle データベースの実行計画は、次の方法を使用して分析できます。
+ **分類方法**ドロップダウン- **[データベースロード]** チャートの **[プラン]** ディメンションを選択すると、時間の経過とともにさまざまなプランが DB 負荷にどのように影響するかが表示されます。
+ **[トップ SQL]** タブ – **[DB 負荷分析]** を選択し、**[トップ SQL]** タブを選択して、各ダイジェストクエリのプランの数を表示します。
ダイジェストクエリの実行プランを分析するには、クエリを選択し、**[プラン]** タブを選択します。詳細については、以下の手順を参照してください。
## 前提条件
実行計画を分析するには、Database Insights のアドバンストモードを使用する必要があります。アドバンストモードを有効にする方法については、「[Amazon Aurora で Database Insights のアドバンストモードを有効にする](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_DatabaseInsights.TurningOnAdvanced.html)」および「[Turning on the Advanced mode of Database Insights for Amazon Relational Database Service](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DatabaseInsights.TurningOnAdvanced.html)」を参照してください。
Aurora PostgreSQL を使用している場合は、次の前提条件もあります:
+ DB インスタンスでは、Aurora PostgreSQL バージョン 14.10、15.5、およびそれ以降のバージョンを使用する必要があります。Aurora PostgreSQL DB クラスターのアップグレードについては、「*Amazon Aurora ユーザーガイド*」の「[Amazon Aurora PostgreSQL DB クラスターのアップグレード](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.PostgreSQL.html)」を参照してください。
+ 次のいずれかのオプションを使用して パラメータ `aurora_compute_plan_id` を `on` に設定することで、実行プランを分析するように DB クラスターを設定する必要があります。
+ 「*Amazon Aurora ユーザーガイド*」の「[Amazon Aurora での DB クラスターパラメータグループの作成](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_WorkingWithParamGroups.CreatingCluster.html)」
+ 「*Amazon Aurora ユーザーガイド*」の「[Amazon Aurora の DB クラスターパラメータグループのパラメータの変更](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_WorkingWithParamGroups.ModifyingCluster.html)」
## 実行プランを分析する
実行プランを分析するには、次の手順に従います。
**実行プランを分析するには**
1. AWS マネジメントコンソール にサインインして、CloudWatch コンソール ([https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)) を開きます。
1. **[Insights]** を選択します。
1. **[Database Insights]** を選択します。
1. **[データベースインスタンス]** ビューを選択します。
1. DB インスタンスを選択します。
1. **[上位の SQL]** タブを選択します。**[プランカウント]** 列には、ダイジェストクエリごとに収集されたプランの数が表示されます。
1. （オプション) **[Plans Count]** 列が表示されない場合は、**[上位 SQL]** テーブルの **[設定]** アイコンを選択して、列の可視性と順序をカスタマイズします。
![\[プラン詳細テーブルの設定\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/DBInsights2.png)
1. ダイジェストクエリを選択して、そのコンポーネントステートメントに展開します。
![\[クエリをコンポーネントステートメントに展開する\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_did-dbload-expand.png)
1. 下にスクロールして SQL テキストを表示します。次に、**[プラン]** タブを選択します。
既定では、CloudWatch は推定される実行プランを表示します。Aurora PostgreSQL の場合、実際の実行プランを表示するには、DB インスタンスの `aurora_stat_plans.with_analyze` パラメータを有効にします。パラメータ `aurora_stat_plans.with_analyze` の詳細については、「*Amazon Aurora ユーザーガイド*」の「[Aurora PostgreSQL のクエリ実行計画とピークメモリのモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Monitoring.Query.Plans.html#aurora.with_analyze)」を参照してください。
1. 同じダイジェストクエリのプランを比較するには、**[ダイジェストクエリのプラン]** リストから 2 つの**プラン**を選択します。
1 つのクエリについて、一度に 1 つまたは 2 つのプランを表示できます。次のスクリーンショット例では、両方のプランが Aurora PostgreSQL 用です。
![\[プランを比較する\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_did-plans.png)
1. DBLoad チャートの **[分類方法]** ドロップダウンで **[プラン]** を選択することで、各プランが経時的に DBLoad にどのように貢献しているかを確認することもできます。
![\[Database load chart showing active sessions over time with plans contribution highlighted.\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/DBInsights_OverTime.png)
# Database Insights による Aurora Limitless データベースのモニタリング
Database Insights は、フリートレベルとインスタンスレベルの両方で [Aurora PostgreSQL Limitless Databases](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_DatabaseInsights.Engines.html) のモニタリングをサポートしています。Aurora PostgreSQL Limitless Databases は、データベースインスタンスダッシュボードと Fleet Health Dashboard の両方で検出できます。
Aurora PostgreSQL Limitless Databases は*シャードグループ*を使用します。各シャードグループは、分散ワークロードを処理するために連携する複数のデータベースインスタンスで構成されます。Database Insights は、シャードグループ内のインスタンス間の負荷分散を理解するのに役立ちます。
Fleet Health Dashboard では、Database Insights は Limitless シャードグループと、データベースフリートを構成する残りのデータベースのモニタリングを提供します。Limitless シャードグループのヘルスと DBLoad 使用率について、フリート内の他のデータベースと同じように、独自のビューを取得できます。インスタンスダッシュボードでは、Database Insights は、シャードグループレベルとグループ内の個々のインスタンスの両方でのモニタリングを提供します。Database Insights には、シャードグループごとに新しいビューが用意されており、シャードグループのインスタンス全体に分散されたデータベース負荷を確認できます。そこから、シャードグループ内の特定のインスタンスダッシュボードに移動できます。
## Aurora Limitless で利用可能な機能
次の表は、Aurora PostgreSQL Limitless データベースで使用できる機能を示しています。各機能が標準および高度なモニタリングモードでサポートされているかどうか、シャードグループレベル、インスタンスレベルで使用できるかどうか、および Database Insights の Fleet またはインスタンスダッシュボードで使用できるかどうかを示します。
| 機能 | スタンダード | アドバンスト | ShardGroup | インスタンス | Database Insights ダッシュボード |
| --- | --- | --- | --- | --- | --- |
| DB Load の上位の寄与要因をディメンション別で分析する | サポート対象 | サポート | あり | はい | インスタンス |
| 最大 7 日間の保持期間を持つデータベースメトリクスにクエリ、グラフ、アラーム設定をする | サポート対象 | サポート | あり | はい | インスタンス |
| きめ細かなアクセスコントロールポリシーを定義し、SQL テキストなどの機密性の高いディメンションへのアクセス権を制限する | サポート対象 | サポート | あり | はい | インスタンス |
| Load Distribution コンポーネントを使用して、同じシャードグループ内のインスタンス間の負荷分散を分析する | サポート対象 | サポート | はい | いいえ | インスタンス |
| 実行中のプロセスごとに詳細なメトリクスを使用して、データベースで発生しているオペレーティングシステムのプロセスを分析する この機能を使用するには、[Amazon RDS 拡張モニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights_Counters.html)が必要です。 | サポート外 | サポート | いいえ | あり | インスタンス |
| フリート全体のモニタリングビューを作成して保存し、何百ものデータベースの健全性を評価する | サポート外 | サポート | はい | なし | Fleet |
| 15 ヶ月の保持期間とガイド付き UX の環境で SQL ロックを分析する | サポートされません | サポートされません | いいえ | いいえ | インスタンス |
| 15 か月間の保持とガイド付き UX の環境で SQL 実行プランを分析する | サポートされません | サポートされません | いいえ | いいえ | インスタンス |
| クエリごとの統計を視覚化する | サポート外 | サポート | いいえ | あり | インスタンス |
| 遅い SQL クエリを分析する この機能を使用するには、データベースログを CloudWatch Logs にエクスポートする必要があります。 | サポート外 | サポート | いいえ | あり | インスタンス |
| CloudWatch Application Signals を使用して通話サービスを表示する | サポート外 | サポート | はい | なし | [Both] (両方) |
| メトリクス、ログ、イベント、アプリケーションを含め、すべてのデータベーステレメトリの統合ダッシュボードを表示するDatabase Insights コンソールでデータベースログを表示するには、CloudWatch Logs へのデータベースログのエクスポートが必要です。 | サポート外 | サポート | いいえ | あり | インスタンス |
| Performance Insights のカウンターメトリクスを CloudWatch に自動的にインポートする | サポート外 | サポート | 該当なし | 該当なし | インスタンス |
| CloudWatch で Amazon RDS イベントを表示する | サポート外 | サポート | はい | なし | [Both] (両方) |
| オンデマンド分析を使用し、選択した期間のデータベースのパフォーマンスを分析する | サポートされません | サポートされません | いいえ | いいえ | インスタンス |
**注記**
Aurora PostgreSQL Limitless Databases では、拡張モニタリングが自動的に有効になります。拡張モニタリングには追加料金が発生します。詳細については、「[拡張モニタリングのコスト](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_Monitoring.OS.html#USER_Monitoring.OS.cost)」を参照してください。
Aurora PostgreSQL Limitless Databases の場合、ログは自動的に CloudWatch Logs に発行され、Database Insights コンソールで検出できます。これには、標準の CloudWatch Logs 料金に従って追加料金が発生します。CloudWatch Logs と Database Insights の料金設定の詳細と料金例については、「[Amazon CloudWatch 料金表](https://aws.amazon.com/cloudwatch/pricing/?nc1=h_ls)」を参照してください。
## Fleet Health Dashboard での Aurora Limitless シャードグループのモニタリング
Database Insights は、Fleet Health Dashboard での Aurora Limitless シャードグループのモニタリングをサポートしています。
このビューでは、Limitless シャードグループと、データベースフリートを構成する他のデータベースを確認できます。Fleet Health Dashboard は、フリート内の他のデータベースの情報を表示する方法と同様に、Limitless シャードグループのヘルスと DBLoad 使用率に関する独自のビューを提供します。
![\[Database Insights Fleet Health Dashboard。メインパネルには、データベースインスタンスを表す六角形のグリッドが表示され、そのうちの 1 つが「shardgroup2」として強調表示されています。ルーターとシャードの DB 負荷使用率が表示されています。右上には、「DB 負荷使用率あたりの上位 10 インスタンス」の経時的なグラフが表示されています。以下は、上位クエリや待機イベントを含む「db-microsoftsqlserver-enterprise-1-dbi-advanced」の詳細です。下部のセクションには、重要なイベントや呼び出しサービスが表示されていません。左側のサイドバーは、合計 44 のインスタンス (そのうち 2 つがアラーム状態) があり、平均 DB 負荷使用率が 25.1% であることを示しています。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_fhd.png)
Fleet Health Dashboard で Aurora Limitless データベースを表示する場合:
+ 個々のインスタンスではなく、シャードグループのみが表示されます
+ シャードグループは、以下のウィジェットに表示されます。
+ Honeycomb グラフ
+ DBLoad に基づく上位 10
+ Events
+ 呼び出しサービス
+ テーブルリスト
+ DBLoad 使用率は、ルーターとシャードの両方について提供されます
このフリートレベルのビューを使用すると、Aurora Limitless シャードグループのパフォーマンスをモニタリングしてフリート内の他のデータベースと比較し、データベースフリート全体を包括的に概観できます。
![\[データベースインスタンスのリストを示す Database Insights ダッシュボード。このテーブルには、DB 識別子、アラーム状態、エンジンタイプ、DB 負荷使用率、最終状態の更新、データベースバージョンを含む 7 つのインスタンスが表示されます。エンジンには、PostgreSQL、SQL Server Enterprise、Oracle Standard、Aurora MySQL、Aurora PostgreSQL などがあります。SQL Server インスタンスの最大負荷は 25.21% です。2 つの Aurora PostgreSQL インスタンスには「Limitless」というラベルが付けられ、シャードとルーターについて個別の使用率が表示されています。インターフェイスには、フィルタリング、ソート、および追加の詳細の表示のオプションが含まれています。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_fhd-limitless-list-view.png)
## インスタンスダッシュボードでの Aurora PostgreSQL Limitless Database のモニタリング
Database Insights は、Aurora PostgreSQL Limitless Database でも、標準の Aurora DB クラスターと同様に機能します。ただし、Aurora PostgreSQL Limitless Database ではシャードグループレベルでメトリクスを追跡します。追跡する 2 つの主要なメトリクスは次のとおりです。
+ **データベース負荷** – データベース内のアクティビティのレベルを測定します。キーメトリクスは `DBLoad` で、毎秒収集されます。`DBLoad` メトリクスの単位は、平均アクティブセッション (AAS) です。平均アクティブセッションを取得するため、Database Insights はクエリを同時に実行しているセッションの数をサンプリングします。AAS は、特定期間の総セッション数を総サンプル数で割った値です。
+ **最大 CPU** — データベースで使用できる最大計算能力。アクティブなセッションが最大 CPU を超えているかどうかを確認するには、`Max vCPU` 行との関係を調べます。`Max vCPU` 値は、DB インスタンスの vCPU (仮想 CPU) のコア数によって決まります。
`DBLoad` メトリクスをディメンションに「スライス」することもできます。ディメンションは、メトリクスのサブカテゴリです。最も有用なディメンションは次のとおりです。
+ **上位のインスタンス** — インスタンス (シャードとルーター) の相対的な DB 負荷を降順に表示します。
+ **待機イベント** – SQL ステートメントが特定のイベントが発生するまで待機してから、実行を続行するようにします。待機イベントは、作業が妨げられる場所を示します。
+ **上位の SQL** — DB の負荷に最も寄与しているクエリを示します。
![\[データベースパフォーマンスメトリクスを示す Database Insights ダッシュボード。上部のセクションには、7 月 14 日の 12:00 から 14:45 までのデータベースアクティビティを追跡する折れ線グラフが表示されています。その下にある DB 負荷分析タブには、4 つのデータベースインスタンス (DTR-3-757、DTR-2-903, DAS-4-112、DAS-5-992) とその負荷使用率メトリクスを一覧表示する「上位インスタンス」ビューが表示され、すべて 0.01 AAS (平均アクティブセッション) 未満の値が表示されています。インターフェイスには、アラーム状態、フィルター、およびさまざまな分析ビューのオプションが含まれています。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_limitless-top-instances.png)
## Database Insights を使用して Aurora PostgreSQL Limitless Databases の DB 負荷を分析する
Database Insights を使用して、Aurora PostgreSQL Limitless Database のメトリクスをシャードグループレベルとインスタンスレベルで追跡できます。Aurora PostgreSQL Limitless Database の DB 負荷を分析するときは、各シャードとルーターの DB 負荷を最大 vCPU と比較することが必要になります。
[絶対] ビューには、平均アクティブセッション (AAS) の数と推定 vCPU が表示されます。[相対] ビューには、推定 vCPU に対する AAS の比率が表示されます。
![\[shardgroup1 Aurora PostgreSQL クラスターのデータベース負荷分散を示す Database Insights ダッシュボード。インターフェイスには、平均アクティブセッション (AAS) の時系列グラフと、5 つのデータベースインスタンス間の負荷分散を示す円グラフが表示されています。円グラフは、合計 261 の AAS を示し、そのパーセンテージは DTR-2-103、DTR-3-650、DAS-4-659、DAS-5-784、DAS-6-336 の各インスタンス間で分割されています。ダッシュボードには、フィルター、アラーム状態、データベーステレメトリオプションが含まれています。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/dbi_limitless-doughnut.png)
### Database Insights ダッシュボードを使用して相対的な DB 負荷を分析する
相対的な DB 負荷を追跡することで、Aurora PostgreSQL Limitless Database のパフォーマンスを向上させることができます。Aurora PostgreSQL Limitless Database の相対的な DB 負荷をインスタンス別に分析するには、次の手順を使用します。
**コンソールを使用して相対的な DB 負荷を分析するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、[データベースインサイト] を選択します。
1. Aurora PostgreSQL Limitless Database を選択します。その Aurora PostgreSQL Limitless Database の Database Insights ダッシュボードが表示されます。
1. [データベース負荷 (DB 負荷)] セクションの *[分類方法]* で *[インスタンス]* を選択します。Aurora PostgreSQL Limitless Database のすべてのインスタンスの vCPU コアに対する平均アクティブセッション (AAS) の比率を確認するには、*[表示]* で *[相対]* を選択します。
平均アクティブセッションのグラフに、Aurora PostgreSQL Limitless Database のインスタンスの DB 負荷が表示されます。
1. 上位インスタンスを表示するには、*[上位のインスタンス]* タブを選択します。
1. (オプション) Aurora PostgreSQL Limitless Database のインスタンスの DB 負荷を分析するには、*[インスタンス]* 列でインスタンス名を選択します。
### Database Insights ダッシュボードを使用して待機別の DB 負荷を分析する
待機イベントを追跡することで、Aurora PostgreSQL Limitless Database のパフォーマンスを向上させることができます。Aurora PostgreSQL Limitless Database の DB 負荷を待機イベント別に分析するには、次の手順を使用します。
**コンソールを使用して Aurora PostgreSQL Limitless Database の DB 負荷を待機イベント別に分析するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、[データベースインサイト] を選択します。
1. Aurora PostgreSQL Limitless Database を選択します。その Aurora PostgreSQL Limitless Database の Database Insights ダッシュボードが表示されます。
1. [データベース負荷 (DB 負荷)] セクションの *[分類方法]* で *[待機]* を選択します。AAS の数と推定 vCPU を表示するには、*[表示]* で *[絶対]* を選択します。
平均アクティブセッションのグラフに、Aurora PostgreSQL Limitless Database のインスタンスの DB 負荷が表示されます。
1. 下部にある [*トップ SQL*] タブまでスクロールします。
1. SQL ステートメントを選択して展開し、コンポーネントステートメントを表示します。
### Database Insights ダッシュボードを使用して負荷分散を分析する
Aurora PostgreSQL Limitless Database でインスタンスの負荷分散のバランスを取ることができます。Aurora PostgreSQL Limitless Database のインスタンスの負荷分散を分析するには、次の手順を使用します。
**コンソールを使用して Aurora PostgreSQL Limitless Database のインスタンスの負荷分散を分析するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、[データベースインサイト] を選択します。
1. Aurora PostgreSQL Limitless Database を選択します。その Aurora PostgreSQL Limitless Database の Database Insights ダッシュボードが表示されます。
1. [データベース負荷 (DB 負荷)] セクションの *[分類方法]* で *[インスタンス]* を選択します。Aurora PostgreSQL Limitless Database のすべてのインスタンスの AAS の数と推定 vCPU を表示するには、*[表示]* で *[絶対]* を選択します。
平均アクティブセッションのグラフに、Aurora PostgreSQL Limitless Database のインスタンスの DB 負荷が表示されます。
1. Aurora PostgreSQL Limitless Database のインスタンスの負荷分散を示すグラフを表示するには、*[負荷分散]* タブを選択します。
# CloudWatch Database Insights のトラブルシューティング
次の情報を使用して、CloudWatch Database Insights の問題をトラブルシューティングします。
## Amazon RDS リソースへのタグの適用
データベースにタグを適用するには、Amazon RDS API、AWS CLI、または Amazon RDS コンソールを使用します。詳細については、以下のトピックを参照してください。
+ 「*Amazon RDS API リファレンス*」の [AddTagsToResource](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_AddTagsToResource.html)
+ 「*Amazon RDS コマンドラインリファレンス*」の [add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/rds/add-tags-to-resource.html)
+ 「*Amazon Aurora ユーザーガイド*」の [Amazon Aurora および Amazon RDS リソースのタグ付け](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_Tagging.html)
## フリートの最大 DB インスタンス
データベースフリート内で監視できる DB インスタンスは最大 500 個です。フィルターを使用して、500 未満の DB インスタンスを持つフリートヘルスビューを作成できます。
# Contributor Insights を使用して高カーディナリティデータを分析する
Contributor Insights を使用して、ログデータを分析し、コントリビューターデータを表示する時系列を作成できます。トップ N コントリビューター、一意のコントリビューターの合計数、およびそれらの使用状況に関するメトリクスを確認できます。これを使用して、トップのトーカーを確認し、システムのパフォーマンスに影響を与えている人や物を判断できます。たとえば、不良ホストを検出したり、最も重いネットワークユーザーを特定したり、エラーを最も多く生成する URL を検索したりできます。
ルールは最初から構築するか、AWS マネジメントコンソール で作成済みのサンプルルールを AWS コンソールで利用することができます。ルールは、`IpAddress` などのコントリビューターの定義に使用するログフィールドを定義します。また、ログデータをフィルタリングして、個別のコントリビューターの動作を見つけて分析できます。
CloudWatch はさらに、他の AWS サービスのメトリクスを分析するために使用できる組み込みルールを提供します。
すべてのルールが受信データをリアルタイムで分析します。
CloudWatch のクロスアカウントオブザーバビリティでモニターリングアカウントとして設定されたアカウントにサインインしている場合、そのモニターリングアカウントで、ソースアカウントとモニターリングアカウントのロググループを分析する Contributor Insights ルールを作成できます。複数のアカウントのロググループを分析する単一のルールを作成することもできます。詳細については、「[CloudWatch のクロスアカウントオブザーバビリティ](CloudWatch-Unified-Cross-Account.md)」を参照してください。
Contributor Insights を使用すると、ルールに一致するログイベントが発生するたびに課金されます。詳細については、「[Amazon CloudWatch 料金表](https://aws.amazon.com/cloudwatch/pricing/)」をご覧ください。
**注記**
Contributor Insights は、ルールが参照する数値が -1e9～1e9 の場合にのみログエントリに一致する可能性があります。ログエントリの値がこの範囲外の場合、Contributor Insights はそのログエントリをスキップします。
**Topics**
+ [
# CloudWatch で Contributor Insights ルールを作成する
](ContributorInsights-CreateRule.md)
+ [
# CloudWatch の Contributor Insights ルール構文
](ContributorInsights-RuleSyntax.md)
+ [
# CloudWatch Contributor Insights ルールの例
](ContributorInsights-Rule-Examples.md)
+ [
# CloudWatch での Contributor Insights レポートの表示
](ContributorInsights-ViewReports.md)
+ [
# CloudWatch のルールによって生成されたメトリクスのグラフ化
](ContributorInsights-GraphReportData.md)
+ [
# CloudWatch での Contributor Insights 組み込みルールの使用
](ContributorInsights-BuiltInRules.md)
# CloudWatch で Contributor Insights ルールを作成する
ルールを作成してログデータを分析できます。JSON または Common Log Format (CLF) のログはすべて評価できます。これらの形式のいずれかに従うカスタムログと、Amazon VPC フローログ、Amazon Route 53 DNS クエリログ、Amazon ECS コンテナログ、AWS CloudTrail のログ、Amazon SageMaker AI のログ、Amazon RDS のログ、AWS AppSync のログ、API Gateway のログなど、AWS サービスのログが含まれます。
ルールでは、フィールド名または値を指定する場合、すべてのマッチングで大文字と小文字が区別されます。
組み込みのサンプルルールを使用してルールを作成したり、独自のルールを最初から作成したりできます。Contributor Insights には、次の種類のログのサンプルルールが含まれています。
+ Amazon API Gateway ログ
+ Amazon Route 53 パブリック DNS クエリログ
+ Amazon Route 53 Resolver クエリログ
+ CloudWatch Container Insights ログ
+ VPC フローログ
CloudWatch のクロスアカウントオブザーバビリティでモニターリングアカウントとして設定されているアカウントにサインインしている場合は、モニターリングアカウントのロググループに対するルールを作成できるだけでなく、このモニターリングアカウントにリンクされているソースアカウントのロググループに対しても Contributor Insights ルールを作成できます。単一のルールを設定して、異なるアカウントのロググループをモニターリングすることもできます。詳細については、「[CloudWatch のクロスアカウントオブザーバビリティ](CloudWatch-Unified-Cross-Account.md)」を参照してください。
**重要**
ユーザーに `cloudwatch:PutInsightRule` アクセス許可を付与すると、デフォルトでは、そのユーザーは CloudWatch Logs 内の任意のロググループを評価するルールを作成できます。特定のロググループを含める、および除外するユーザーのアクセス許可を制限する IAM ポリシー条件を追加できます。詳細については、「」を参照してください[Contributor Insights のユーザーのロググループへのアクセスを制限するための条件キーの使用](iam-cw-condition-keys-contributor.md)
**組み込みのサンプルルールを使用してルールを作成するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、**[ログ]**、**[Contributor Insights]** を選択します。
1. [**Create rule**] を選択してください。
1. **[Select log group(s)]** (ロググループを選択) で、ルールでモニターリングするロググループを選択します。ロググループは 20 個まで選択できます。CloudWatch のクロスアカウントオブザーバビリティのために設定されたモニターリングアカウントにサインインしている場合は、ソースアカウントのロググループを選択できるだけでなく、単一のルールを設定して異なるアカウントのロググループを分析することもできます。
1. (オプション) 名前が特定の文字列で始まるすべてのロググループを選択するには、**[Select by prefix match]** (プレフィックスの一致による選択) ドロップダウンを選択し、プレフィックスを入力します。これがモニターリングアカウントの場合は、必要に応じて検索対象のアカウントを選択できます。そうでない場合は、すべてのアカウントが選択されます。
**注記**
ルールと一致するログイベントごとに料金が発生します。**[Select by prefix match]** (プレフィックスの一致による選択) ドロップダウンを選択する場合、プレフィクスが一致する可能性があるロググループの数に注意してください。意図したより多くのロググループを検索すると、想定外の料金が発生することがあります。詳細については、「[Amazon CloudWatch 料金表](https://aws.amazon.com/cloudwatch/pricing)」をご覧ください。
1. **[Rule type]** (ルールタイプ) で、**[Sample rule]** (サンプルルール) を選択します。次に、**[Select sample rule]** (サンプルルールの選択) を選択し、ルールを選択します。
1. **[ログの形式]** には、ルールが評価するログの形式を選択します。
1. **[トランスフォーマー]** で、**[トランスフォーマーの Contributor Insights を有効にする]** を選択して、[CloudWatch Logs ログ変換](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatch-Logs-Transformation.html.html)によって変換されたログイベントをルールで評価できるようにします。これを有効にすることを選択した場合:
+ ルールがトランスフォーマーを持つロググループを評価する場合、ルールは変換されたバージョンのログに適用されます。
+ ルールがトランスフォーマーを持たないロググループを評価する場合、ルールはログの元のバージョンに適用されます。
これを選択しない場合、ログ変換を使用するロググループであっても、すべてのロググループで元のログイベントが評価されます。
**注記**
ロググループにトランスフォーマーがあり、一部のログイベントで変換が失敗した場合、それらのログイベントは Contributor Insights によって評価されません。ログ変換の失敗の調査については、「[変換メトリクスとエラー](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Transformation-Errors-Metrics.html)」を参照してください。
1. 選択したサンプルルールでは、**[ログの形式]**、**[コントリビューション]**、**[フィルター]**、および **[集計]** の各フィールドが入力済みです。これらの値は、必要に応じて調整できます。
1. [**次へ**] を選択します。
1. [**Rule name**] に名前を入力します。有効な文字は、A～Z、a～z、0～9、(ハイフン)、(アンダースコア)、(ピリオド) です。
1. ルールを無効状態で作成するか有効状態で作成するかを選択します。ルールを有効にすると、即座にデータの分析が開始されます。有効にしたルールを実行すると、コストが発生します。詳細については、[Amazon CloudWatch 料金表](https://aws.amazon.com/cloudwatch/pricing/)をご覧ください。
Contributor Insights は、ルールが作成されたあとに新しいログイベントのみを分析します。ルールは、以前に CloudWatch Logs によって処理されたログイベントは処理できません。
1. (オプション) **[Tags]** (タグ) で、このルールのタグとする 1 つまたは複数のキーと値のペアを追加します。タグを使用すると、AWS リソースを識別して整理したり、AWS コストを追跡したりしやすくなります。詳細については、「[Amazon CloudWatch リソースにタグを付ける](CloudWatch-Tagging.md)」を参照してください。
1. **[作成]** を選択します。
**ルールを最初から作成するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、**[ログ]**、**[Contributor Insights]** を選択します。
1. [**Create rule**] を選択してください。
1. **[Select log group(s)]** (ロググループを選択) で、ルールでモニターリングするロググループを選択します。ロググループは 20 個まで選択できます。CloudWatch のクロスアカウントオブザーバビリティのために設定されたモニターリングアカウントにサインインしている場合は、ソースアカウントのロググループを選択できるだけでなく、単一のルールを設定して異なるアカウントのロググループを分析することもできます。
1. (オプション) 名前が特定の文字列で始まるすべてのロググループを選択するには、**[Select by prefix match]** (プレフィックスの一致による選択) ドロップダウンを選択し、プレフィックスを入力します。
**注記**
ルールと一致するログイベントごとに料金が発生します。**[Select by prefix match]** (プレフィックスの一致による選択) ドロップダウンを選択する場合、プレフィクスが一致する可能性があるロググループの数に注意してください。意図したより多くのロググループを検索すると、想定外の料金が発生することがあります。詳細については、「[Amazon CloudWatch 料金表](https://aws.amazon.com/cloudwatch/pricing)」をご覧ください。
1. **[Rule type]** (ルールタイプ) で **[Custom rule]** (カスタムルール) を選択します。
1. [**Log Format**] で、[**JSON**] または [**CLF**] を選択します。
1. **[トランスフォーマー]** で、**[トランスフォーマーの Contributor Insights を有効にする]** を選択して、[CloudWatch Logs ログ変換](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatch-Logs-Transformation.html.html)によって変換されたログイベントをルールで評価できるようにします。これを有効にすることを選択した場合:
+ ルールがトランスフォーマーを持つロググループを評価する場合、ルールは変換されたバージョンのログに適用されます。
+ ルールがトランスフォーマーを持たないロググループを評価する場合、ルールはログの元のバージョンに適用されます。
これを選択しない場合、ログ変換を使用するロググループであっても、すべてのロググループで元のログイベントが評価されます。
**注記**
ロググループにトランスフォーマーがあり、一部のログイベントで変換が失敗した場合、それらのログイベントは Contributor Insights によって評価されません。ログ変換の失敗の調査については、「[変換メトリクスとエラー](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Transformation-Errors-Metrics.html)」を参照してください。
1. ルールの作成を完了するには、ウィザードを使用するか、[**Syntax**] タブを選択して手動でルール構文を指定します。
ウィザードの使用を続けるには、次の操作を実行します。
1. [**Contribution**]、[**Key**] に、レポート対象のコントリビュータータイプを入力します。このコントリビュータータイプのトップ N の値がレポートに表示されます。
値を持つログフィールドが有効なエントリです。例には、**requestId**、**sourceIPaddress**、**containerID** が含まれます。
特定のロググループに属するログのログフィールド名を検索する方法については、「[ログフィールドの検索](#finding_log_fields)」を参照してください。
1 KB 以上のキーは切り捨てられ、1 KB になります。
1. (オプション) **[Add new key]** (新しいキーを追加) を選択して、キーを追加します。ルールには、最大 4 つのキーを含められます。複数のキーを入力すると、レポートのコントリビューターは、これらのキーの一意な値の組み合わせで定義されます。たとえば、3 つのキーを指定した場合、3 つのキーの一意の値の組み合わせそれぞれが、一意のコントリビューターとしてカウントされます。
1. (オプション) 結果の範囲を狭めるフィルターを追加する場合は、**[Add filter]** (フィルターを追加) を選択します。**[Match]** (一致) で、フィルタリングするログフィールドの名前を入力します。**[Condition]** (条件) で、比較演算子を選択し、フィルタリングする値を入力します。
ルールには、最大 4 つのフィルターを追加できます。複数のフィルターは AND ロジックで結合されるため、すべてのフィルターに一致するログイベントのみが評価されます。
**注記**
`In`、`NotIn`、`StartsWith` などの比較演算子に続く配列には、最大 10 個の文字列値を含めることができます。Contributor Insights ルールの構文の詳細については、「[CloudWatch の Contributor Insights ルール構文](ContributorInsights-RuleSyntax.md)」を参照してください。
1. [**Aggregate on**] (集計) で、[**Count**] (カウント) または [**Sum**] (合計) を選択します。[**Count**] (カウント) を選択すると、コントリビューターランキングが出現回数に基づきます。[**Sum**] (合計) を選択すると、ランキングは [**Contribution**] (コントリビューション)、[**Value**] (値) に指定したフィールドの値を集約した合計に基づきます。
1. ウィザードを使用する代わりにルールを JSON オブジェクトとして入力するには、次の手順を実行します。
1. [**Syntax**] タブを選択します。
1. [**Rule body**] に、ルールの JSON オブジェクトを入力します。ルール構文の詳細については、「[CloudWatch の Contributor Insights ルール構文](ContributorInsights-RuleSyntax.md)」を参照してください。
1. [**次へ**] を選択します。
1. [**Rule name**] に名前を入力します。有効な文字は、A ～ Z、a ～ z、0 ～ 9、-（ハイフン）、\$1（アンダースコア）、.（ピリオド）です。
1. ルールを無効状態で作成するか有効状態で作成するかを選択します。ルールを有効にすると、即座にデータの分析が開始されます。有効にしたルールを実行すると、コストが発生します。詳細については、[Amazon CloudWatch 料金表](https://aws.amazon.com/cloudwatch/pricing/)をご覧ください。
Contributor Insights は、ルールが作成されたあとに新しいログイベントのみを分析します。ルールは、以前に CloudWatch Logs によって処理されたログイベントは処理できません。
1. (オプション) **[Tags]** (タグ) で、このルールのタグとする 1 つまたは複数のキーと値のペアを追加します。タグを使用すると、AWS リソースを識別して整理したり、AWS コストを追跡したりしやすくなります。詳細については、「[Amazon CloudWatch リソースにタグを付ける](CloudWatch-Tagging.md)」を参照してください。
1. **[Next]** (次へ) を選択します。
1. 入力した設定を確認し、**[Create rule]** (ルールの作成) を選択します。
作成したルールは、無効化、有効化、または削除できます。
**Contributor Insights のルールを有効化、無効化、または削除するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、**[ログ]**、**[Contributor Insights]** を選択します。
1. ルールのリストで、1 つのルールの横にあるチェックボックスをオンにします。
組み込みルールは AWS サービスによって作成され、編集、無効化、または削除できません。
1. [**アクション**] を選択し、必要なオプションを選択します。
**ログフィールドの検索**
ルールを作成するときは、ロググループのログエントリのフィールド名を知っている必要があります。
**ロググループでログフィールドを検索するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインの [**ログ**] で、[**Insights**] を選択します。
1. クエリエディタの上で、クエリするロググループを 1 つ以上選択します。
ロググループを選択すると、CloudWatch Logs Insights はロググループのデータのフィールドを自動的に検出して、[**Discovered fields**] の右側のペインに表示します。
# CloudWatch の Contributor Insights ルール構文
このセクションでは、Contributor Insights ルールの構文について説明します。この構文は、JSON ブロックを入力してルールを作成するときのみ使用します。ウィザードを使ってルールを作成する場合は、構文を知る必要はありません。ウィザードを使ってルールを作成する詳しい方法については、「[CloudWatch で Contributor Insights ルールを作成する](ContributorInsights-CreateRule.md)」を参照してください。
ログイベントフィールド名および値に対するルールのすべのマッチングでは、大文字と小文字が区別されます。
次の例は JSON ログの構文を説明します。
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"LogGroupNames": [
"API-Gateway-Access-Logs*",
"Log-group-name2"
],
"LogFormat": "JSON",
"Contribution": {
"Keys": [
"$.ip"
],
"ValueOf": "$.requestBytes",
"Filters": [
{
"Match": "$.httpMethod",
"In": [
"PUT"
]
}
]
},
"AggregateOn": "Sum"
}
```Contributor Insights ルールのフィールド
Schema
CloudWatch Logs データを分析するルールの `Schema` の値は、常に `{"Name": "CloudWatchLogRule", "Version": 1}` である必要があります。
LogGroupNames
文字列の配列です。配列の各要素で、必要に応じて文字列の最後に `*` を使用して、そのプレフィックスで始まる名前を持つすべてのロググループを含めることができます。
ロググループ名でワイルドカードを使用するときはご注意ください。ルールと一致するログイベントごとに料金が発生します。誤って意図したより多くのロググループを検索すると、予期しない料金が発生することがあります。詳細については、[Amazon CloudWatch 料金表](https://aws.amazon.com/cloudwatch/pricing)をご覧ください。
LogGroupARNs
CloudWatch のクロスアカウントオブザーバビリティモニターリングアカウントでこのルールを作成する場合、`LogGroupARNs` を使用して、モニターリングアカウントにリンクされているソースアカウントのロググループを指定したり、モニターリングアカウント自体のログループを指定したりできます。ルール内で `LogGroupNames` または `LogGroupARNs` を指定する必要があります。ただし、両方を指定することはできません。
`LogGroupARNs` は文字列の配列です。配列の各要素で、特定の状況においては、必要に応じて `*` をワイルドカードとして使用できます。例えば、`arn:aws:logs:us-west-1:*:log-group/MyLogGroupName2` を指定すると、米国西部 (北カリフォルニア) リージョン内のすべてのソースアカウントとモニターリングアカウントで `MyLogGroupName2` という名前のロググループを指定できます。また、`arn:aws:logs:us-west-1:111122223333:log-group/GroupNamePrefix*` を指定すると、名前が `GroupNamePrefix` で始まる米国西部 (北カリフォルニア) 内の 111122223333 のロググループすべてを指定することもできます。
AWS アカウント ID の一部を、ワイルドカードが付いたプレフィックスとして指定することはできません。
ロググループ ARN でワイルドカードを使用するときはご注意ください。ルールと一致するログイベントごとに料金が発生します。誤って意図したより多くのロググループを検索すると、予期しない料金が発生することがあります。詳細については、[Amazon CloudWatch 料金表](https://aws.amazon.com/cloudwatch/pricing)をご覧ください。
LogFormat
有効な値は、`JSON` および `CLF` です。
寄与度
このオブジェクトには、最大で 4 つのメンバーがある `Keys` 配列、オプションで 1 つの `ValueOf`、およびオプションで最大 4 つの `Filters` がある配列が含まれます。
キー
最大 4 つのログフィールドの配列であり、コントリビューターを分類するためのディメンションとして使用されます。複数のキーを入力すると、これらのキーの一意な値の組み合わせごとに一意のコントリビューターとしてカウントされます。フィールドは、JSON プロパティフォーマット表記を使用して指定する必要があります。
ValueOf
(オプション) `Sum` を `AggregateOn` の値として指定する場合のみこれを指定します。`ValueOf` は数値を持つログフィールドを指定します。このタイプのルールでは、コントリビューターはログエントリでの出現回数ではなく、このフィールドの値の合計によってランク付けされます。たとえば、コントリビューターを特定期間にわたる合計 `BytesSent` でソートする場合は、`ValueOf` を `BytesSent` に設定し、`Sum` を `AggregateOn` に指定します。
フィルター
最大 4 つのフィルターの配列を指定し、レポートに含まれるログイベントを絞り込みます。複数のフィルターを指定した場合、Contributor Insights は論理 AND 演算子で評価します。これを使用して、検索から無関係なログイベントを除外したり、1 つのコントリビューターを選択して動作を分析したりできます。
配列内の各メンバーは、`Match` フィールドと、使用する一致する演算子のタイプを示すフィールドを含める必要があります。
`Match` フィールドは、フィルターで評価するログフィールドを指定します。ログフィールドは JSON プロパティフォーマット表記を使用して指定されます。
一致する演算子フィールドは、`In`、`NotIn`、`StartsWith`、`GreaterThan`、`LessThan`、`EqualTo`、`NotEqualTo`、または `IsPresent` のいずれかである必要があります。演算子フィールドが`In`、`NotIn`、または `StartsWith` である場合、チェックする文字列値の配列が続きます。Contributor Insights は文字列値の配列を OR 演算子で評価します。配列には最大で 10 個の文字列値を含めることができます。
演算子フィールドが `GreaterThan`、`LessThan`、`EqualTo`、または `NotEqualTo` である場合、比較する 1 つの数値が続きます。
演算子フィールドが `IsPresent` である場合、`true` または `false` が続きます。この演算子は、指定したログフィールドがログイベント内にあるかどうかに基づいて、ログイベントを照合します。`isPresent` は JSON プロパティの葉ノードの値に対してのみ機能します。たとえば、`c-count` との一致を検索するフィルターは、`details.c-count.c1` を値とするログイベントを評価しません。
次の 4 つのフィルターの例を参照してください。
```
{"Match": "$.httpMethod", "In": [ "PUT", ] }
{"Match": "$.StatusCode", "EqualTo": 200 }
{"Match": "$.BytesReceived", "GreaterThan": 10000}
{"Match": "$.eventSource", "StartsWith": [ "ec2", "ecs" ] }
```
AggregateOn
有効な値は、`Count` および `Sum` です。出現回数に基づいてレポートを集計するか、`ValueOf` フィールドで指定されたフィールドの値の合計に基づいてレポートを集計するかを指定します。
**JSON プロパティフォーマット表記**
`Keys`、`ValueOf`、および `Match` フィールドはドット表記の JSON プロパティフォーマットに従い、`$` は JSON オブジェクトのルートを表します。このあとにはピリオドと、サブプロパティの名前を含む英数字の文字列が続きます。複数のプロパティレベルがサポートされています。
文字列の最初の文字は A-Z または a-z だけです。文字列の次の文字は、A～Z、a～z、0～9 のいずれでもかまいません。
次のリストは、JSON プロパティフォーマットの有効な例を示しています。
```
$.userAgent
$.endpoints[0]
$.users[1].name
$.requestParameters.instanceId
```
**CLF ログのルールの追加フィールド**
Common Log Format (CLF) ログイベントには、JSON にはあるようなフィールドの名前はありません。Contributor Insights ルールで使用するフィールドを提供するために、CLF ログイベントを `1` で始まるインデックスを持つ配列として扱うことができます。最初のフィールドを **"1"** として指定し、2 番目のフィールドを **"2"** として指定できます。以下同様です。
CLF ログのルールを読みやすくするには、`Fields` を使用できます。これにより、CLF フィールドの位置の命名エイリアスを提供することができます。たとえば、位置「4」が IP アドレスであることを指定できます。指定すると、`IpAddress` をルールで `Keys`、`ValueOf`、および `Filters` のプロパティとして使用できます。
次の例は、`Fields` フィールドを使用する CLF ログのルールを示しています。
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"LogGroupNames": [
"API-Gateway-Access-Logs*"
],
"LogFormat": "CLF",
"Fields": {
"4": "IpAddress",
"7": "StatusCode"
},
"Contribution": {
"Keys": [
"IpAddress"
],
"Filters": [
{
"Match": "StatusCode",
"EqualTo": 200
}
]
},
"AggregateOn": "Count"
}
```
# CloudWatch Contributor Insights ルールの例
このセクションには、Contributor Insights ルールのユースケースを示す例が含まれています。
**VPC フローログ: 送信元 IP アドレスおよび送信先 IP アドレスごとのバイト転送**
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"LogGroupNames": [
"/aws/containerinsights/sample-cluster-name/flowlogs"
],
"LogFormat": "CLF",
"Fields": {
"4": "srcaddr",
"5": "dstaddr",
"10": "bytes"
},
"Contribution": {
"Keys": [
"srcaddr",
"dstaddr"
],
"ValueOf": "bytes",
"Filters": []
},
"AggregateOn": "Sum"
}
```
**VPC フローログ: HTTPS リクエストの最高数**
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"LogGroupNames": [
"/aws/containerinsights/sample-cluster-name/flowlogs"
],
"LogFormat": "CLF",
"Fields": {
"5": "destination address",
"7": "destination port",
"9": "packet count"
},
"Contribution": {
"Keys": [
"destination address"
],
"ValueOf": "packet count",
"Filters": [
{
"Match": "destination port",
"EqualTo": 443
}
]
},
"AggregateOn": "Sum"
}
```
**VPC フローログ: 拒否された TCP 接続**
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"LogGroupNames": [
"/aws/containerinsights/sample-cluster-name/flowlogs"
],
"LogFormat": "CLF",
"Fields": {
"3": "interfaceID",
"4": "sourceAddress",
"8": "protocol",
"13": "action"
},
"Contribution": {
"Keys": [
"interfaceID",
"sourceAddress"
],
"Filters": [
{
"Match": "protocol",
"EqualTo": 6
},
{
"Match": "action",
"In": [
"REJECT"
]
}
]
},
"AggregateOn": "Sum"
}
```
**送信元アドレスによる Route 53 NXDomain 応答**
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"AggregateOn": "Count",
"Contribution": {
"Filters": [
{
"Match": "$.rcode",
"StartsWith": [
"NXDOMAIN"
]
}
],
"Keys": [
"$.srcaddr"
]
},
"LogFormat": "JSON",
"LogGroupNames": [
""
]
}
```
**ドメイン名による Route 53 Resolver クエリ**
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"AggregateOn": "Count",
"Contribution": {
"Filters": [],
"Keys": [
"$.query_name"
]
},
"LogFormat": "JSON",
"LogGroupNames": [
""
]
}
```
**クエリタイプと送信元アドレスによる Route 53 Resolver クエリ**
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"AggregateOn": "Count",
"Contribution": {
"Filters": [],
"Keys": [
"$.query_type",
"$.srcaddr"
]
},
"LogFormat": "JSON",
"LogGroupNames": [
""
]
}
```
# CloudWatch での Contributor Insights レポートの表示
レポートデータのグラフや、ルールによって見つかったコントリビューターのランク付けリストを表示するには、次の手順を実行します。
**ルールレポートを表示するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、**[ログ]**、**[Contributor Insights]** を選択します。
1. ルールのリストで、ルールの名前を選択します。
グラフには、過去 3 時間のルールの結果が表示されます。グラフの下にある表には、トップ 10 コントリビューターを表示します。
1. 表に表示されるコントリビューターの数を変更するには、表の上部にある [**Top 10 contributors**] を選択します。
1. 表に単一のコントリビューターの結果のみを表示するようフィルタリングするには、表の凡例でそのコントリビューターを選択します。再びすべてのコントリビューターを表示するには、凡例で同じコントリビューターを再び選択します。
1. レポートに表示される時間範囲を変更するには、表の上部で **[15m]** (15 分)、**[30m]** (30 分)、**[1h]** (1 時間)、**[2h]** (2 時間)、**[3h]** (3 時間)、または **[custom]** (カスタム) を選択します。
レポートの最大時間範囲は 24 時間ですが、最大 15 日前に発生した 24 時間の時間窓を選択できます。過去の時間窓を選択するには、[**custom**]、[**absolute**] を選択し、時間窓を指定します。
1. コントリビューターの集計とランク付けに使用する期間を変更するには、表の上部で [**period**] を選択します。より長い期間を表示すると、大抵の場合スパイクが少ない滑らかなレポートが表示されます。短い期間を選択すると、スパイクが表示される可能性が高くなります。
1. このグラフを CloudWatch ダッシュボードに追加するには、[**ダッシュボードに追加**] を選択します。
1. CloudWatch Logs Insights クエリウィンドウを開くには、このレポートのロググループがクエリボックスにロード済みの状態で、[**ログの表示**] を選択します。
1. レポートデータをクリップボードまたは CSV ファイルにエクスポートするには、[**Export**] を選択します。
# CloudWatch のルールによって生成されたメトリクスのグラフ化
Contributor Insights にはメトリクス数学関数、`INSIGHT_RULE_METRIC` があります。この関数を使用して、Contributor Insights レポートのデータを、CloudWatch コンソールの [**メトリクス**] タブにあるグラフに追加できます。また、この数学関数に基づいてアラームを設定することもできます。メトリクス数学関数の詳細については、「[CloudWatch メトリクスでの数式の使用](using-metric-math.md)」を参照してください。
このメトリクス数学関数を使用するには、`cloudwatch:GetMetricData` アクセス許可と `cloudwatch:GetInsightRuleReport` アクセス許可の両方を持つアカウントにサインインしている必要があります。
構文は `INSIGHT_RULE_METRIC(ruleName, metricName)` です。[*ruleName*] は Contributor Insights ルールの名前です。[*metricName*] は次のリストにある値の 1 つです。[*metricName*] の値は、math 関数が返すデータのタイプを決定します。
+ `UniqueContributors` – 各データポイントの一意のコントリビューターの数です。
+ `MaxContributorValue` – 各データポイントのトップコントリビューターの値です。コントリビューターの ID は、グラフのデータポイントごとに変わる場合があります。
このルールを `Count` によって集計する場合、各データポイントのトップコントリビューターはその期間中に最も多く出現したコントリビューターです。ルールを `Sum` によって集計する場合、トップコントリビューターはその期間中にルールの `Value` によって指定されたログフィールドで最大合計を持つコントリビューターです。
+ `SampleCount` – ルールと一致するデータポイントの数です。
+ `Sum` – そのデータポイントによって表される期間中のすべてのコントリビューターの値の合計です。
+ `Minimum` – そのデータポイントによって表される期間中の単一の観測値の最小値です。
+ `Maximum` – そのデータポイントによって表される期間中の単一の観測値の最大値です。
+ `Average` – そのデータポイントによって表される期間中のすべてのコントリビューターの平均値です。
## Contributor Insights メトリクスデータでのアラームの設定
この関数 `INSIGHT_RULE_METRIC` を使用すると、Contributor Insights が生成するメトリクスにアラームを設定できます。例えば、拒否された Transmission Control Protocol (TCP) 接続の割合に基づくアラームを作成できます。このタイプのアラームの使用を開始するために、次の 2 つの例に示すようなルールを作成できます。
**ルールの例:「RejectedConnectionsRule」**
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"LogGroupNames": [
"/aws/containerinsights/sample-cluster-name/flowlogs"
],
"LogFormat": "CLF",
"Fields": {
"3": "interfaceID",
"4": "sourceAddress",
"8": "protocol",
"13": "action"
},
"Contribution": {
"Keys": [
"interfaceID",
"sourceAddress"
],
"Filters": [
{
"Match": "protocol",
"EqualTo": 6
},
{
"Match": "action",
"In": [
"REJECT"
]
}
]
},
"AggregateOn": "Sum"
}
```
**ルールの例:「TotalConnectionsRule」**
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"LogGroupNames": [
"/aws/containerinsights/sample-cluster-name/flowlogs"
],
"LogFormat": "CLF",
"Fields": {
"3": "interfaceID",
"4": "sourceAddress",
"8": "protocol",
"13": "action"
},
"Contribution": {
"Keys": [
"interfaceID",
"sourceAddress"
],
"Filters": [{
"Match": "protocol",
"EqualTo": 6
}],
"AggregateOn": "Sum"
}
}
```
ルールを作成したら、CloudWatch コンソールで **[Metrics]** (メトリクス) タブを選択できます。このタブでは、次のメトリクス数式の例を使用して、Contributor Insights がレポートするデータをグラフ化できます。
**例: メトリクス数式**
```
e1 INSIGHT_RULE_METRIC("RejectedConnectionsRule", "Sum")
e2 INSIGHT_RULE_METRIC("TotalConnectionsRule", "Sum")
e3 (e1/e2)*100
```
この例では、メトリクス数式 `e3` は、拒否されたすべての TCP 接続を返します。TCP 接続の 20% が拒否されたときに通知を受け取りたい場合は、しきい値を `100` から `20` に変更して式を変更できます。
**注記**
**[Metrics]** (メトリクス) セクションから、モニターリングしているメトリクスにアラームを設定できます。**[Graphed metrics]** (グラフ化されたメトリクス) タブで、**[Actions]** (アクション) 列の下にある **[Create alarm]** (アラームを作成) アイコンを選択できます。**[Create alarm]** (アラームを作成) アイコンはベルのような見た目です。
表メトリクスと Metric Math 関数の使用に関する詳細については、「[CloudWatch グラフに数式を追加する](using-metric-math.md#adding-metrics-expression-console)」のセクションを参照してください。
# CloudWatch での Contributor Insights 組み込みルールの使用
Contributor Insights 組み込みルールを使用して、他の AWS サービスからメトリクスを分析できます。次のサービスでは組み込みルールをサポートします。
+ Amazon DynamoDB 開発者ガイドの「[Amazon DynamoDB の Contributor Insights」](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/contributorinsights.html)。
+ AWS PrivateLink ガイドの「[組み込み Contributor Insights ルールを使用する](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-cloudwatch-metrics.html#privatelink-contributor-insights)」。
# CloudWatch Application Insights を使用したアプリケーションの一般的な問題の検出
Amazon CloudWatch Application Insights を使用すると、アプリケーションの問題を検出できます。CloudWatch Application Insights は、アプリケーションおよびその基盤となる AWS のリソースに対するオブザーバビリティを高めます。アプリケーションのリソースを監視する最適な条件を設定し、データを継続的に分析してアプリケーションの問題の徴候を検出できます。Application Insights は、[SageMaker](https://docs.aws.amazon.com/sagemaker/latest/dg/wahtis.html) などの AWS テクノロジーを基盤とし、アプリケーションをモニターリングして検出した潜在的な問題を自動ダッシュボードに表示します。これにより、アプリケーションやインフラストラクチャで進行中の問題をすばやく特定できます。Application Insights が提供するアプリケーションの正常性に関する強化された可視性は、アプリケーションの問題のトラブルシューティングに要する平均修復時間 (MTTR) を低減するのに役立ちます。
Amazon CloudWatch Application Insights にアプリケーションを追加すると、アプリケーションのリソースがスキャンされて、アプリケーションコンポーネントに対して推奨されるメトリクスとログが [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) に設定されます。アプリケーションコンポーネントの例には、SQS Server バックエンドデータベースと Microsoft IIS/Web 層があります。Application Insights は、履歴データを使用してメトリクスのパターンを分析し、異常を検出します。また、アプリケーション、オペレーティングシステム、インフラストラクチャログからエラーや例外を継続的に検出します。これらの監視結果は、分類アルゴリズムと組み込みルールの組み合わせを使用して相互に関連付けられます。その後、自動作成されるダッシュボードに表示されるモニターリング結果と問題の重大度に関する情報に基づいて、対処するアクションの優先順位を決定できます。.NET および SQL アプリケーションスタックの一般的な問題 (アプリケーションのレイテンシー、SQL Server のバックアップの失敗、メモリリーク、大きな HTTP リクエスト、I/O オペレーションのキャンセルなど) については、根本原因を示唆する追加のインサイトと解決の手順が示されます。組み込まれている [AWS SSM OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) との統合により、関連する Systems Manager Automation ドキュメントを実行して問題を解決できます。
**Topics**
+ [Amazon CloudWatch Application Insights とは](appinsights-what-is.md)
+ [Application Insights の仕組み](appinsights-how-works.md)
+ [前提条件、IAM ポリシー、およびアクセス許可](appinsights-accessing.md)
+ [モニタリングするようにアプリケーションを設定する](appinsights-setting-up.md)
+ [
# アプリケーションインサイトのクロスアカウントオブザーバビリティ
](appinsights-cross-account.md)
+ [コンポーネント設定の作業](component-config.md)
+ [CloudFormation テンプレートの使用](appinsights-cloudformation.md)
+ [
# チュートリアル: SAP ASE のモニタリングをセットアップする
](appinsights-tutorial-sap-ase.md)
+ [チュートリアル: SAP HANA のモニターリングを設定する](appinsights-tutorial-sap-hana.md)
+ [
# チュートリアル: SAP NetWeaver のモニターリングを設定する
](appinsights-tutorial-sap-netweaver.md)
+ [Application Insights の表示とトラブルシューティング](appinsights-troubleshooting.md)
+ [サポートされているログとメトリクス](appinsights-logs-and-metrics.md)
# Amazon CloudWatch Application Insights とは
CloudWatch Application Insights は、他の[アプリケーションリソース](#appinsights-components)とともに Amazon EC2 インスタンスを使用するアプリケーションをモニターリングするのに役立ちます。アプリケーションのリソース全体およびテクノロジースタック (Microsoft SQL Server データベース、ウェブ (IIS) サーバー、アプリケーションサーバー、OS、ロードバランサー、キューなど) で主要なメトリクス、ログ、およびアラームを特定して設定します。メトリクスとログを継続的にモニターリングし、異常やエラーを検出して相互に関連付けます。エラーや異常が検出されると、Application Insights は [CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) を生成します。これを使用して、通知を設定したり、アクションを実行したりできます。トラブルシューティングに役立てるために、検出した問題の自動ダッシュボードを作成します。このダッシュボードには、相互に関連付けられた異常とログエラー、さらに根本原因を示唆する追加のインサイトが示されます。自動ダッシュボードを使用すると、是正措置を簡単に実行してアプリケーションを正常な状態に保ち、アプリケーションのエンドユーザーへの影響を防止できます。OpsItems も作成されるため、[AWS SSM OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) を使用して問題を解決できます。
ミラーリングされた書き込みトランザクション/秒、リカバリキューの長さ、トランザクション遅延などの重要なカウンター、CloudWatch での Windows イベントログを設定できます。SQL HA ワークロードでフェイルオーバーイベントや問題 (ターゲットデータベースのクエリに対するアクセスの制限など) が発生した場合、CloudWatch Application Insights は自動化されたインサイトを提供します。
CloudWatch Application Insights は [AWS Launch Wizard](https://docs.aws.amazon.com/launchwizard/latest/userguide/what-is-launch-wizard.html) との統合により、SQL Server HA ワークロードを AWS にデプロイするためのモニターリングを 1 回のクリック操作で設定できます。[Launch Wizard コンソール](https://console.aws.amazon.com/launchwizard)の Application Insights でモニターリングおよびインサイトを設定するオプションを選択すると、CloudWatch Application Insights は関連するメトリクス、ログ、アラームを CloudWatch で自動的に設定し、新しくデプロイされたワークロードのモニターリングを開始します。自動化されたインサイトと検出された問題は、SQL Server HA ワークロードのヘルスとともに CloudWatch コンソールで確認できます。
**Topics**
+ [
## 機能
](#appinsights-features)
+ [
## 概念
](#appinsights-concepts)
+ [
## 料金
](#appinsights-pricing)
+ [
## 関連する のサービス
](#appinsights-related-services)
+ [
## サポートされるアプリケーションコンポーネント
](#appinsights-components)
+ [
## サポートされるテクノロジースタック
](#appinsights-stack)
## 機能
Application Insights には、次の機能があります。
**アプリケーションリソースのモニターリングの自動設定**
CloudWatch Application Insights を使用すると、アプリケーションのモニターリングの設定にかかる時間が短縮されます。CloudWatch Application Insights for.NET and SQL Server は、アプリケーションリソースをスキャンして推奨されるメトリクスとログのリスト (カスタマイズ可能) を提供し、CloudWatch でこのメトリクスやログを設定することで、Amazon EC2 および Elastic Load Balancing (ELB) などのアプリケーションリソースに必要な可視性を提供します。また、モニターリングしたメトリクスに対して動的なアラームを設定します。アラームは、過去 2 週間に検出された異常に基づいて自動的に更新されます。
**問題の検出と通知**
CloudWatch Application Insights は、メトリクスの異常やログエラーなど、アプリケーションの潜在的な問題の兆候を検出します。これらの監視結果を相互に関連付けることで、アプリケーションの潜在的な問題を表面化させます。次に、CloudWatch Events を生成します。[これらのイベントは、通知を送信するか、アクションを実行するように設定できます](appinsights-cloudwatch-events.md)。これにより、メトリクスやログエラーごとに個別のアラームを作成する必要がなくなります。さらに、検出された問題のアラートを受信するように[Amazon SNS 通知を設定](appinsights-problem-notifications.md)できます。
**トラブルシューティング**
CloudWatch Application Insights は、検出された問題用の CloudWatch 自動ダッシュボードを作成します。このダッシュボードには、問題に関する詳細として、トラブルシューティングに役立つ関連メトリクスの異常やログエラーなどが表示されます。また、異常やエラーの根本原因を示唆する追加のインサイトも示されます。
## 概念
以下の概念は、Application Insights によるアプリケーションのモニターリング方法を理解するうえで重要です。
**コンポーネント**
アプリケーションを構成する類似リソースの自動グループ化、スタンドアロン、またはカスタムグループ化。モニターリングを向上させるために、類似したリソースをカスタムコンポーネントとしてグループ化することをお勧めします。
**監視結果**
アプリケーションやアプリケーションリソースで検出された個別のイベント (メトリクスの異常、ログエラー、または例外)。
**問題**
問題は、関連する監視結果の相互関連付け、分類、およびグループ化によって検出されます。
CloudWatch Application Insights に関する他の主要な概念の定義については、「[ Amazon CloudWatch の概念](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html)」を参照してください。
## 料金
CloudWatch Application Insights は、検出した問題を通知するために CloudWatch メトリクス、CloudWatch Logs、および CloudWatch Events を使用して、選択したアプリケーションリソースに推奨されるメトリクスとログを設定します。これらの機能は、[CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing)に基づいて AWS アカウントに請求されます。検出した問題については、Application Insights によって [SSM OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-working-with-OpsItems.html) も作成され、ユーザーはその問題に関する通知を受け取ることができます。さらに、Application Insights は、[SSM パラメータストアのパラメータ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)を作成して、インスタンスで CloudWatch エージェントを設定します。Amazon EC2 Systems Manager の機能は [SSM の料金](https://aws.amazon.com/systems-manager/pricing/)に従って課金されます。セットアップの支援、モニターリング、データ分析、または問題の検出には料金がかかりません。
### CloudWatch Application Insights のコスト
Amazon EC2 のコストには、次の機能の使用が含まれます。
+ CloudWatch エージェント
+ CloudWatch エージェントロググループ
+ CloudWatch エージェントメトリクス
+ Prometheus ロググループ (JMX ワークロード用)
すべてのリソースのコストには、次の機能の使用が含まれます。
+ CloudWatch アラーム (大部分のコスト)
+ SSM OpsItems (最低コスト)
### コスト計算例
この例のコストは、次のシナリオに従って考慮されます。
次を含むリソースグループが作成されました。
+ SQL Server がインストールされている Amazon EC2 インスタンス。
+ アタッチされた Amazon EBS ボリューム。
このリソースグループに CloudWatch Application Insights をオンボードすると、Amazon EC2 インスタンスにインストールされている SQL Server ワークロードが検出されます。CloudWatch Application Insights は、次のメトリクスのモニターリングを開始します。
SQL Server インスタンスでは、次のメトリクスがモニターリングされます。
+ CPUUtilization
+ StatusCheckFailed
+ Memory % Committed Bytes In Use
+ Memory Available Mbytes
+ Network Interface Bytes Total/sec
+ Paging File % Usage
+ Physical Disk % Disk Time
+ Processor % Processor Time
+ SQLServer:Buffer Manager cache hit ratio
+ SQLServer:Buffer Manager life expectancy
+ SQLServer:General Statistics Processes blocked
+ SQLServer:General Statistics User Connections
+ SQLServer:Locks Number of Deadlocks/sec
+ SQLServer:SQL Statistics Batch Requests/sec
+ System Processor Queue Length
SQL Server インスタンスにアタッチされたボリュームについては、以下のメトリクスがモニターリングされます。
+ VolumeReadBytes
+ VolumeWriteBytes
+ VolumeReadOps
+ VolumeWriteOps
+ VolumeTotalReadTime
+ VolumeTotalWriteTime
+ VolumeIdleTime
+ VolumeQueueLength
+ VolumeThroughputPercentage
+ VolumeConsumedReadWriteOps
+ BurstBalance
このシナリオでは、コストは [CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)ページと [SSM の料金](https://aws.amazon.com/systems-manager/pricing/)ページに従って計算されます。
+ カスタムメトリクス
このシナリオでは、CloudWatch エージェントを使用して、上記のメトリクスのうち 13 個が CloudWatch に発行されます。これらのメトリクスは、カスタムメトリクスとして処理されます。各カスタムメトリクスの月額コストは 0.3 USD です。これらのカスタムメトリクスの合計コストは、13 個 x 0.3 USD = 3.90 USD/月です。
+ **アラーム**
このシナリオでは、CloudWatch Application Insights は合計 26 個のメトリクスをモニターリングし、26 個のアラームが作成されます。各アラームの月額コストは 0.1 USD です。アラームの合計コストは、26 個 x 0.1 USD = 2.60 USD/月です。
+ **データインジェストとエラーログ**
データインジェストのコストは 1 GB あたり 0.05 USD で、SQL Server エラーログ用ストレージのコストは 1 GB あたり 0.03 USD です。データインジェストとエラーログの合計コストは、1 GB あたり 0.08 USD (0.05 USD \$1 0.03 USD) です。
+ **Amazon EC2 Systems Manager OpsItems**
SSM OpsItem は、CloudWatch Application Insights が検出した問題ごとに作成されます。アプリケーションの問題が n 件発生した場合、合計月額コストは 0.00267 USD x n で求めることができます。
## 関連する のサービス
CloudWatch Application Insights は以下のサービスと併用されます。
**関連 AWS サービス**
+ **Amazon CloudWatch**。リソースの使用状況、アプリケーションのパフォーマンス、および運用状態についてシステム全体の可視性を提供します。メトリクスの収集と追跡、アラーム通知の送信、定義したルールに基づくモニターリング対象リソースの自動更新を行います。また、ユーザー独自のカスタムメトリクスもモニターリングできます。CloudWatch Application Insights は、CloudWatch (具体的には CloudWatch のデフォルトのオペレーションダッシュボード内) から開始します。詳細については、[https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)を参照してください。
+ **CloudWatch Container Insights** は、コンテナ化されたアプリケーションおよびマイクロサービスのメトリクスとログを収集、集約、要約します。Container Insights を使用して、Amazon EC2 の Kubernetes プラットフォーム、Amazon Elastic Kubernetes Service、Amazon ECS をモニターリングできます。Container Insights または Application Insights コンソールで Application Insights が有効になっている場合、Application Insights により、検出された問題が Container Insights ダッシュボードに表示されます。詳細については、「[Container Insights](ContainerInsights.md)」を参照してください。
+ **Amazon DynamoDB** はフルマネージド型の NoSQL データベースサービスです。これを使用すると、分散データベースの運用とスケーリングに伴う管理作業をまかせることができるため、ハードウェアのプロビジョニング、設定と構成、レプリケーション、ソフトウェアパッチ適用、クラスタースケーリングなどを自分で行う必要はなくなります。また、DynamoDB も保管時の暗号化を提供し、機密データの保護における負担と複雑な作業を解消します。
+ **Amazon EC2** は、AWS クラウド内でスケーラブルなコンピューティング性能を提供します。Amazon EC2 を使用すると、必要な数 (またはそれ以下) の仮想サーバーを起動して、セキュリティおよびネットワーキングを構成し、ストレージを管理できます。要件の変更や需要増に対応してスケールアップまたはスケールダウンできるため、トラフィック予測を軽減できます。詳細については、[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html)または [https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/concepts.html](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/concepts.html)を参照してください。
+ **Amazon Elastic Block Store (Amazon EBS)** は、Amazon EC2 インスタンスで使用するためのブロックレベルのストレージボリュームを提供します。Amazon EBS ボリュームの動作は、未初期化のブロックデバイスに似ています。これらのボリュームは、デバイスとしてインスタンスにマウントできます。インスタンスにアタッチした Amazon EBS ボリュームは、インスタンスの有効期間とは無関係に存続するストレージボリュームとして公開されます。これらのボリューム上にファイルシステムを構築できます。または、これらのボリュームをブロックデバイス (ハードドライブなど) を使用する場合と同じ方法で使用できます。インスタンスにアタッチされているボリュームの設定は動的に変更できます。詳細は、[Amazon EBS ユーザーガイド](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)をご覧ください。
+ **Amazon EC2 Auto Scaling** は、アプリケーションの負荷を処理するために適切な数の Amazon EC2 インスタンスを利用できるようにします。詳細については、[https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)を参照してください。
+ **Elastic Load Balancing** は、受信したアプリケーションまたはネットワークトラフィックを複数のアベイラビリティーゾーンの複数のターゲット (EC2 インスタンス、コンテナ、IP アドレスなど) に分散させます。詳細については、[https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)を参照してください。
+ **IAM** は、AWS リソースへのユーザーアクセスを安全に管理するウェブサービスです。IAM を使用して、どのユーザーがお客様の AWS リソースを使用できるか (認証)、それらのユーザーがどのリソースをどのような方法で使用できるか (認可) をコントロールできます。詳細については、「[Amazon CloudWatch に対する認証とアクセスコントロール](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/auth-and-access-control-cw.html)」を参照してください。
+ **AWS Lambda** を使用すると、イベントによってトリガーされる関数で構成されたサーバーレスアプリケーションを構築し、これらを CodePipeline や AWS CodeBuild を使用して自動的にデプロイできます。詳細については、「[AWS Lambda アプリケーション](https://docs.aws.amazon.com/lambda/latest/dg/deploying-lambda-apps.html)」をご参照ください。
+ **AWS Launch Wizard for SQL Server** は、SQL Server 高可用性ソリューションをクラウドにデプロイする所要時間を短縮します。パフォーマンス、ノード数、サービスコンソールの接続を含むアプリケーションの要件を入力すると、AWS Launch Wizard は、SQL Server Always On アプリケーションをデプロイおよび実行するための適切な AWS リソースを識別します。
+ **AWSResource Groups**は、アプリケーションを構成するリソースを整理するのに役立ちます。Resource Groups を使用すると、大量のリソースのタスクを一度に管理および自動化できます。アプリケーションごとに登録できるリソースグループは 1 つだけです。詳細については、[https://docs.aws.amazon.com/ARG/latest/userguide/welcome.html](https://docs.aws.amazon.com/ARG/latest/userguide/welcome.html)を参照してください。
+ **Amazon SQS**。分散されたソフトウェアシステムとコンポーネントを統合および分離できる、安全性、耐久性、可用性に優れたホストされたキューを提供します。詳細については、[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)を参照してください。
+ **AWS Step Functions** はサーバーレス関数作成ツールであり、AWS 関数を含むさまざまな AWS Lambda のサービスとリソースを、構造化された視覚的なワークフローに順序付けすることができます。詳細については、[AWS Step Functions ユーザーガイド](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)をご参照ください。
+ **AWS SSM OpsCenter** では、各 OpsItem、関連する OpsItems、関連リソースに関するコンテキスト調査データを提供しながら、サービス全体で OpsItems を集約および標準化します。OpsCenter には Systems Manager Automation ドキュメント (ランブック) も用意されており、問題をすばやく解決できます。検索可能なカスタムデータを OpsItem ごとに指定することができます。OpsItems に関する自動的に生成された概要レポートは、ステータスおよびソース別に表示することもできます。詳細については、[https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)を参照してください。
+ **Amazon API Gateway** は、あらゆる規模の REST、HTTP、および WebSocket API を作成、公開、維持、モニターリング、およびセキュア化するための AWS サービスです。API 開発者は、AWS または他のウェブサービス、AWS クラウドに保存されているデータにアクセスする API を作成できます。詳細については、[Amazon API Gateway ユーザーガイド](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)を参照してください。
**注記**
Application Insights は REST API プロトコル (API Gateway サービスの v1) のみをサポートします。
+ **Amazon Elastic Container Service (Amazon ECS)** は、フルマネージド型のコンテナオーケストレーションサービスです。Amazon ECS を使用して、最も機密性の高いミッションクリティカルなアプリケーションを実行できます。詳細については、[Amazon Elastic Container Service デベロッパーガイド](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)を参照してください。
+ **Amazon Elastic Kubernetes Service (Amazon EKS)** は、お客様独自の Kubernetes コントロールプレーンまたはノードをインストール、運用、保守管理することなく、AWS で Kubernetes を実行できるマネージドサービスです。Kubernetes は、コンテナ化されたアプリケーションのデプロイ、スケーリング、および管理を自動化するためのオープンソースシステムです。詳細については、[Amazon EKS ユーザーガイド](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)をご覧ください。
+ **Kubernetes on Amazon EC2**。Kubernetes は、コンテナ化アプリケーションを大規模にデプロイおよび管理するのを支援するオープンソースソフトウェアです。Kubernetes では、デプロイ、メンテナンス、スケーリングのプロセスにより、Amazon EC2 コンピューティングインスタンスのクラスターを管理し、これらのインスタンスでコンテナを実行します。Kubernetes では、同じツールセットを使用して、オンプレミスやクラウド上で、すべてのタイプのコンテナ化アプリケーションを実行できます。詳細については、「[Kubernetes ドキュメント：開始方法](https://kubernetes.io/docs/setup/)」を参照してください。
+ **Amazon FSx**は、AWS によって完全に管理される一般的なファイルシステムの起動と実行に役立ちます。Amazon FSx を使用すると、一般的なオープンソースおよび商用ライセンスのファイルシステムの機能セットとパフォーマンスを活用して、時間のかかる管理タスクを回避できます。詳細については、「[Amazon FSx のドキュメント](https://docs.aws.amazon.com/fsx/)」参照してください。
+ **Amazon Simple Notification Service (SNS)** は、アプリケーション間およびアプリケーションと人間の通信の両方に対応するフルマネージド型のメッセージングサービスです。Amazon SNS は、Application Insights によるモニターリング用に設定できます。Amazon SNS がモニターリング用のリソースとして設定されている場合、Application Insights は SNS のメトリクスを追跡して、SNS メッセージにおける問題の発生や失敗の理由を判定するのに役立ちます。
+ **Amazon Elastic File System (Amazon EFS)** は、AWS クラウド のサービスやオンプレミスのリソースで使用できるフルマネージド型の伸縮性の高い NFS ファイルシステムです。アプリケーションを中断することなく、必要に応じてペタバイト規模まで拡張することを目的に構築されています。ファイルの追加や削除に応じて自動的に拡張/縮小されるため、拡張に対応するための容量のプロビジョニングや管理は不要になります。詳細については、[Amazon Elastic File System のドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)を参照してください。
**関連するサードパーティーのサービス**
+ Application Insights でモニターリングされるいくつかのワークロードとアプリケーションについては、**Prometheus JMX Exporter** は AWS Systems Manager Distributor を使用してインストールされるため、CloudWatch Application Insights は Java 固有のメトリクスを取得できます。Java アプリケーションのモニターリングを選択すると、Application Insights によって Prometheus JMX Exporter が自動的にインストールされます。
## サポートされるアプリケーションコンポーネント
CloudWatch Application Insights は、リソースグループをスキャンしてアプリケーションコンポーネントを識別します。コンポーネントは、スタンドアロン、自動グループ化 (Auto Scaling グループ内のインスタンスやロードバランサーの背後のインスタンスなど)、またはカスタム (個々の Amazon EC2 インスタンスのグループ化) のいずれかになります。
CloudWatch Application Insights でサポートされるコンポーネントは以下のとおりです。
**AWS コンポーネント**
+ Amazon EC2
+ Amazon EBS
+ Amazon RDS
+ Elastic Load Balancing: Application Load Balancer と Classic Load Balancer (これらのロードバランサーのすべてのターゲットインスタンスが特定および設定されます)。
+ Amazon EC2 Auto Scaling グループ: AWS Auto Scaling (Auto Scaling グループは、すべてのターゲットインスタンスに対して動的に設定されます。アプリケーションがスケールアップすると、CloudWatch Application Insights は新しいインスタンスを自動的に設定します)。Auto Scaling グループは、CloudFormation のスタックベースのリソースグループではサポートされません。
+ AWS Lambda
+ Amazon Simple Queue Service (Amazon SQS)
+ Amazon DynamoDB テーブル
+ Amazon S3 バケットメトリクス
+ AWS Step Functions
+ Amazon API Gateway REST API ステージ
+ Amazon Elastic Container Service (Amazon ECS): クラスター、サービス、およびタスク
+ Amazon Elastic Kubernetes Service (Amazon EKS): クラスター
+ Amazon EC2 での Kubernetes: EC2 で実行されている Kubernetes クラスター
+ Amazon SNS トピック
その他すべてのコンポーネントタイプのリソースは、現在 CloudWatch Application Insights によって追跡されていません。サポートされているコンポーネントタイプが Application Insights アプリケーションに表示されない場合、そのコンポーネントは登録済みで、お客様が所有する別のアプリケーションで管理され、Application Insights によってモニターリングされている可能性があります。
## サポートされるテクノロジースタック
CloudWatch Application Insights を使用して、以下のいずれかのテクノロジーについて、アプリケーション層ドロップダウンメニューオプションを選択すると、Windows Server および Linux オペレーティングシステムで実行されているアプリケーションをモニターリングできます。
+ フロントエンド: Microsoft Internet Information Services (IIS) ウェブサーバー
+ ワーカー層:
+ .NET Framework
+ .NET Core
+ アプリケーション:
+ Java
+ SAP NetWeaver の標準、分散型、および高可用性デプロイ
+ Active Directory
+ SharePoint
+ データベース:
+ Amazon RDS または Amazon EC2 で実行されている Microsoft SQL Server (SQL Server High Availability の設定を含みます。[コンポーネント設定の例](component-configuration-examples.md) を参照してください。)
+ Amazon RDS、Amazon Aurora、Amazon EC2 上で実行されている MySQL
+ Amazon RDS または Amazon EC2 上で実行されている PostgreSQL
+ Amazon DynamoDB テーブル
+ Amazon RDS または Amazon EC2 上で実行されている Oracle
+ 単一の Amazon EC2 インスタンスおよび複数の EC2 インスタンス上の SAP HANA データベース
+ クロス AZ SAP HANA データベースの高可用性セットアップ。
+ 単一の Amazon EC2 インスタンス上のSAP Sybase ASE データベース。
+ クロス AZ SAP Sybase ASE データベースの高可用性セットアップ。
上に示したテクノロジースタックのいずれもアプリケーションリソースに該当しない場合は、[**Manage Monitoring**] ページのアプリケーション層のドロップダウンメニューから [**Custom**] を選択して、アプリケーションスタックをモニターリングできます。
# Amazon CloudWatch Application Insights の仕組み
CloudWatch Application Insights では、アプリケーションリソースをモニタリングできます。以下では、Application Insights の仕組みについて説明します。
**Topics**
+ [
## Application Insights がアプリケーションをモニターリングする方法
](#appinsights-how-works-sub)
+ [
## データ保持期間
](#appinsights-retention)
+ [
## クォータ
](#appinsights-limits)
+ [
# AWSCloudWatch Application Insights で使用される Systems Manager (SSM) パッケージ
](appinsights-ssm-packages.md)
+ [
# CloudWatch Application Insights で使用される AWS Systems Manager (SSM) ドキュメント
](appinsights-ssm-documents.md)
## Application Insights がアプリケーションをモニターリングする方法
以下では、Application Insights がどのようにアプリケーションをモニタリングするかについて説明します。
**アプリケーションの検出と設定**
CloudWatch Application Insights にアプリケーションを初めて追加すると、アプリケーションコンポーネントがスキャンされ、アプリケーションでモニターリングする主要なメトリクス、ログ、その他のデータソースが推奨されます。これらの推奨内容に基づいて、アプリケーションを設定できます。
**データの前処理**
CloudWatch Application Insights は、アプリケーションリソース全体でモニターリングされているデータソースを継続的に分析し、メトリクスの異常やログエラー (監視結果) を検出します。
**問題のインテリジェントな検出**
CloudWatch Application Insights エンジンは、分類アルゴリズムと組み込みルールを使用して監視結果を関連付けることで、アプリケーションの問題を検出します。トラブルシューティングを支援するために CloudWatch ダッシュボードが自動的に作成され、問題に関するコンテキスト情報が表示されます。
**アラートとアクション**
CloudWatch Application Insights は、アプリケーションの問題を検出すると、CloudWatch Events を生成して問題をユーザーに通知します。これらのイベントをセットアップする方法の詳細については、「[検出された問題の Application Insights CloudWatch Events](appinsights-cloudwatch-events.md)」を参照してください。さらに、検出された問題のアラートを受信するように[Amazon SNS 通知を設定](appinsights-problem-notifications.md)できます。
**シナリオの例**
SQL Server データベースを基盤とする ASP .NET アプリケーションがあります。メモリ負担が高いため、突然、データベースの誤動作が始まります。これに伴って、アプリケーションのパフォーマンスが低下し、ウェブサーバーやロードバランサーで HTTP 500 エラーが発生する可能性があります。
CloudWatch Application Insights とそのインテリジェントな分析により、動的に作成されるダッシュボードに関連メトリクスやログファイルのスニペットが表示されます。これを確認することで、問題を起こしているアプリケーション層を特定できます。この場合、問題は SQL データベース層にある可能性があります。
## データ保持期間
CloudWatch Application Insights は、問題を 55 日間、監視結果を 60 日間保持します。
## クォータ
CloudWatch Application Insights のデフォルトクォータについては、「[Amazon CloudWatch Application Insights エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/applicationinsights.html)」を参照してください。特に明記しない限り、各クォータは AWS リージョン単位です。サービスのクォータの引き上げをリクエストする場合は、[AWS Support](https://console.aws.amazon.com/support/home#/case/create?issueType=technical) にお問い合わせください。多くのサービスには、変更することができないクォータが含まれています。特定のサービスに対するクォータの詳細については、そのサービスのドキュメントを参照してください。
# AWSCloudWatch Application Insights で使用される Systems Manager (SSM) パッケージ
このセクションに記載されているパッケージは Application Insights で使用されており、AWS Systems Manager Distributor で個別に管理およびデプロイできます。SSM Distributor の詳細については、*AWS Systems Manager ユーザーガイド*の [AWS Systems Manager Distributor](https://docs.aws.amazon.com/systems-manager/latest/userguide/distributor.html) を参照してください。
**Topics**
+ [
## `AWSObservabilityExporter-JMXExporterInstallAndConfigure`
](#configure-java)
+ [
## `AWSObservabilityExporter-SAP-HANADBExporterInstallAndConfigure`
](#appinsights-ssm-sap-prometheus)
+ [
## `AWSObservabilityExporter-HAClusterExporterInstallAndConfigure`
](#appinsights-ssm-sap-prometheus-ha)
+ [
## `AWSObservabilityExporter-SAP-SAPHostExporterInstallAndConfigure`
](#appinsights-ssm-sap-host-exporter)
+ [
## `AWSObservabilityExporter-SQLExporterInstallAndConfigure`
](#appinsights-ssm-sql-prometheus)
## `AWSObservabilityExporter-JMXExporterInstallAndConfigure`
Application Insights の [Prometheus JMX Exporter](https://prometheus.io/docs/instrumenting/exporters/#third-party-exporters) からワークロード固有の Java メトリクスを取得して、アラームを設定およびモニターリングできます。Application Insights コンソールの [**Manage monitoring**] (モニターリングの管理) ページで、[**Application tier**] (アプリケーション層) ドロップダウンから [**JAVA application**] (JAVA アプリケーション) を選択します。その後、[**JAVA Prometheus exporter configuration**] (JAVA Prometheus エクスポーター設定) で、[**Collection method**] (収集方法) と [**JMX port number**] (JMX ポート番号) を選択します。
[AWS Systems Manager Distributor](https://docs.aws.amazon.com/systems-manager/latest/userguide/distributor.html) を使用して AWS が提供する Prometheus JMX Exporter パッケージを Application Insights とは別にパッケージ化、インストール、および設定するには、次の手順を実行します。
**Prometheus JMX Exporter SSM パッケージを使用するための前提条件**
+ SSM エージェントバージョン 2.3.1550.0 以降がインストールされている
+ JAVA\$1HOME 環境変数が設定されている
**`AWSObservabilityExporter-JMXExporterInstallAndConfigure` パッケージをインストールして設定する**
`AWSObservabilityExporter-JMXExporterInstallAndConfigure` パッケージは、[Prometheus JMX Exporter](https://github.com/prometheus/jmx_exporter) のインストールおよび設定に使用できる SSM Distributor パッケージです。Prometheus JMX Exporter によって Java メトリクスが送信されると、CloudWatch サービスのメトリクスを取得するように CloudWatch エージェントを設定できます。
1. ご自身の好みに基づいて、Prometheus GitHub リポジトリにある [Prometheus JMX Exporter の YAML 設定ファイル](https://github.com/prometheus/jmx_exporter#configuration)を準備します。設定例とオプションの説明を参考にしてください。
1. Base64 としてエンコードされた Prometheus JMX Exporter の YAML 設定ファイルを、[SSM Parameter Store](https://console.aws.amazon.com/systems-manager/parameters) の新しい SSM パラメータにコピーします。
1. [SSM Distributor](https://console.aws.amazon.com/systems-manager/distributor) コンソールに移動し、**[Owned by Amazon]** (Amazon 所有) タブを開きます。[**AWSObservabilityExporter-JMXExporterInstallAndConfigure**] を選択し、[**Install one time**] (1 回限りのインストール) を選択します。
1. 「Additional Arguments」を次のように置き換えて、最初のステップで作成した SSM パラメータを更新します。
```
{
"SSM_EXPORTER_CONFIGURATION": "{{ssm:}}",
"SSM_EXPOSITION_PORT": "9404"
}
```
**注記**
ポート 9404 は、Prometheus JMX メトリクスの送信に使用されるデフォルトのポートです。このポートは更新できます。
**例: Java メトリクスを取得するための CloudWatch エージェントの設定**
1. 前の手順で説明したように、Prometheus JMX Exporter をインストールします。その後、ポートのステータスをチェックして、インスタンスに正しくインストールされていることを確認します。
Windows インスタンスでの正常なインストール例
```
PS C:\> curl http://localhost:9404 (http://localhost:9404/)
StatusCode : 200
StatusDescription : OK
Content : # HELP jvm_info JVM version info
```
Linux インスタンスでの正常なインストール例
```
$ curl localhost:9404
# HELP jmx_config_reload_failure_total Number of times configuration have failed to be reloaded.
# TYPE jmx_config_reload_failure_total counter
jmx_config_reload_failure_total 0.0
```
1. Prometheus サービスの検出 YAML ファイルを作成します。次のサンプルのサービス検出ファイルは、次の処理を実行します。
+ Prometheus JMX Exporter ホストポートを `localhost: 9404` として指定します。
+ メトリクスにラベル (`Application`、`ComponentName`、および `InstanceId`) をアタッチします。これは、CloudWatch メトリクスディメンションとして設定できます。
```
$ cat prometheus_sd_jmx.yaml
- targets:
- 127.0.0.1:9404
labels:
Application: myApp
ComponentName: arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/sampl-Appli-MMZW8E3GH4H2/aac36d7fea2a6e5b
InstanceId: i-12345678901234567
```
1. Prometheus JMX Exporter 設定 YAML ファイルを作成します。次の設定ファイルの例では、次の項目を指定します。
+ メトリクスの取得ジョブ間隔とタイムアウト期間。
+ スクレイピングとも呼ばれるメトリクスの取得ジョブ (`jmx` および `sap`)。これには、ジョブ名、一度に返される最大時系列、およびサービス検出のファイルパスが含まれます。
```
$ cat prometheus.yaml
global:
scrape_interval: 1m
scrape_timeout: 10s
scrape_configs:
- job_name: jmx
sample_limit: 10000
file_sd_configs:
- files: ["/tmp/prometheus_sd_jmx.yaml"]
- job_name: sap
sample_limit: 10000
file_sd_configs:
- files: ["/tmp/prometheus_sd_sap.yaml"]
```
1. CloudWatch エージェントが Amazon EC2 インスタンスにインストールされ、バージョンが 1.247346.1b249759 以降であることを検証します。EC2 インスタンスに CloudWatch エージェントをインストールするには、「[CloudWatch エージェントのインストール](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html)」を参照してください。バージョンを確認するには、「[CloudWatch エージェントのバージョンについての情報の検索](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/troubleshooting-CloudWatch-Agent.html#CloudWatch-Agent-troubleshooting-agent-version)」をご参照ください。
1. CloudWatch エージェントを設定します。CloudWatch エージェント設定ファイルの設定方法の詳細については、「[CloudWatch エージェント設定ファイルを手動で作成または編集する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html)」を参照してください。次の CloudWatch エージェント設定ファイルの例は、次の処理を実行します。
+ Prometheus JMX Exporter 設定ファイルパスを指定します。
+ EMF メトリクスログを発行するターゲットロググループを指定します。
+ メトリクス名ごとに 2 つのディメンションセットを指定します。
+ 8 個 (4 個のメトリクス名 \$1 メトリクス名ごとに 2 セットのディメンション) の CloudWatch メトリクスを送信します。
```
{
"logs":{
"logs_collected":{
....
},
"metrics_collected":{
"prometheus":{
"cluster_name":"prometheus-test-cluster",
"log_group_name":"prometheus-test",
"prometheus_config_path":"/tmp/prometheus.yaml",
"emf_processor":{
"metric_declaration_dedup":true,
"metric_namespace":"CWAgent",
"metric_unit":{
"jvm_threads_current":"Count",
"jvm_gc_collection_seconds_sum":"Second",
"jvm_memory_bytes_used":"Bytes"
},
"metric_declaration":[
{
"source_labels":[
"job"
],
"label_matcher":"^jmx$",
"dimensions":[
[
"InstanceId",
"ComponentName"
],
[
"ComponentName"
]
],
"metric_selectors":[
"^java_lang_threading_threadcount$",
"^java_lang_memory_heapmemoryusage_used$",
"^java_lang_memory_heapmemoryusage_committed$"
]
}
]
}
}
}
},
"metrics":{
....
}
}
```
## `AWSObservabilityExporter-SAP-HANADBExporterInstallAndConfigure`
Application Insights の [Prometheus HANA データベースエクスポーター](https://prometheus.io/docs/instrumenting/exporters/#third-party-exporters) からワークロード固有の SAP HANA メトリクスを取得して、アラームを設定およびモニターリングできます。詳細については、このガイドの「[SAP HANA データベースをモニターリング用に設定する](appinsights-tutorial-sap-hana.md#appinsights-tutorial-sap-hana-set-up)」を参照してください。
[AWS Systems Manager Distributor](https://docs.aws.amazon.com/systems-manager/latest/userguide/distributor.html) を使用して、AWS が提供する Prometheus HANA データベースエクスポーターパッケージを Application Insights とは別にパッケージ化、インストール、設定するには、次の手順を完了します。
**Prometheus HANA データベース Exporter SSM パッケージを使用するための前提条件**
+ SSM エージェントバージョン 2.3.1550.0 以降がインストールされている
+ SAP HANA データベース
+ Linux オペレーティングシステム (SUSE Linux、RedHat Linux)
+ AWS Secrets Manager を使用しており、SAP HANA データベースのモニタリング認証情報を持つシークレット。キーと値のペアの形式を使用してシークレットを作成し、キーのユーザー名を指定して、値にデータベースユーザーを入力します。2 番目のキーのパスワードを追加して、値にパスワードを入力します。シークレットを作成する方法については、*AWS Secrets Manager ユーザーガイド*の「[シークレットを作成する](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html)」を参照してください。シークレットは、次のようにフォーマットする必要があります。
```
{
"username": "",
"password": ""
}
```
**`AWSObservabilityExporter-SAP-HANADBExporterInstallAndConfigure` パッケージをインストールして設定する**
`AWSObservabilityExporter-SAP-HANADBExporterInstallAndConfigure` パッケージは、[Prometheus HANA データベース Exporter](https://github.com/prometheus/jmx_exporter) のインストールおよび設定に使用できる SSM Distributor パッケージです。Prometheus HANA データベース Exporter によって HANA データベースのメトリクスが送信されると、CloudWatch サービスのメトリクスを取得するように CloudWatch エージェントを設定できます。
1. [SSM パラメータストア](https://console.aws.amazon.com/systems-manager/parameters)で SSM パラメータを作成して、Exporter の設定を保存します。パラメータ値の例を次に示します。
```
{\"exposition_port\":9668,\"multi_tenant\":true,\"timeout\":600,\"hana\":{\"host\":\"localhost\",\"port\":30013,\"aws_secret_name\":\"HANA_DB_CREDS\",\"scale_out_mode\":true}}
```
**注記**
この例では、エクスポートはアクティブな `SYSTEM` データベースがある Amazon EC2 インスタンスでのみ実行されます。また、メトリクスの重複を避けるため、他の EC2 インスタンスはアイドル状態のままになります。エクスポーターでは、`SYSTEM` データベースからのすべてのテナント情報を取得できます。
1. [SSM パラメータストア](https://console.aws.amazon.com/systems-manager/parameters)で SSM パラメータを作成して、Exporter メトリクスのクエリを保存します。パッケージでは、複数のメトリクスパラメータが受け入れ可能です。各パラメータには、有効な JSON オブジェクトの形式が必要です。パラメータの値の例を次に示します。
```
{\"SELECT MAX(TIMESTAMP) TIMESTAMP, HOST, MEASURED_ELEMENT_NAME CORE, SUM(MAP(CAPTION, 'User Time', TO_NUMBER(VALUE), 0)) USER_PCT, SUM(MAP(CAPTION, 'System Time', TO_NUMBER(VALUE), 0)) SYSTEM_PCT, SUM(MAP(CAPTION, 'Wait Time', TO_NUMBER(VALUE), 0)) WAITIO_PCT, SUM(MAP(CAPTION, 'Idle Time', 0, TO_NUMBER(VALUE))) BUSY_PCT, SUM(MAP(CAPTION, 'Idle Time', TO_NUMBER(VALUE), 0)) IDLE_PCT FROM sys.M_HOST_AGENT_METRICS WHERE MEASURED_ELEMENT_TYPE = 'Processor' GROUP BY HOST, MEASURED_ELEMENT_NAME;\":{\"enabled\":true,\"metrics\":[{\"name\":\"hanadb_cpu_user\",\"description\":\"Percentage of CPU time spent by HANA DB in user space, over the last minute (in seconds)\",\"labels\":[\"HOST\",\"CORE\"],\"value\":\"USER_PCT\",\"unit\":\"percent\",\"type\":\"gauge\"},{\"name\":\"hanadb_cpu_system\",\"description\":\"Percentage of CPU time spent by HANA DB in Kernel space, over the last minute (in seconds)\",\"labels\":[\"HOST\",\"CORE\"],\"value\":\"SYSTEM_PCT\",\"unit\":\"percent\",\"type\":\"gauge\"},{\"name\":\"hanadb_cpu_waitio\",\"description\":\"Percentage of CPU time spent by HANA DB in IO mode, over the last minute (in seconds)\",\"labels\":[\"HOST\",\"CORE\"],\"value\":\"WAITIO_PCT\",\"unit\":\"percent\",\"type\":\"gauge\"},{\"name\":\"hanadb_cpu_busy\",\"description\":\"Percentage of CPU time spent by HANA DB, over the last minute (in seconds)\",\"labels\":[\"HOST\",\"CORE\"],\"value\":\"BUSY_PCT\",\"unit\":\"percent\",\"type\":\"gauge\"},{\"name\":\"hanadb_cpu_idle\",\"description\":\"Percentage of CPU time not spent by HANA DB, over the last minute (in seconds)\",\"labels\":[\"HOST\",\"CORE\"],\"value\":\"IDLE_PCT\",\"unit\":\"percent\",\"type\":\"gauge\"}]}}
```
メトリクスのクエリについての詳細は、GitHub の「[https://github.com/SUSE/hanadb_exporter/blob/master/metrics.json](https://github.com/SUSE/hanadb_exporter/blob/master/metrics.json) repo」を参照してください。
1. [SSM Distributor](https://console.aws.amazon.com/systems-manager/distributor) コンソールに移動し、**[Owned by Amazon]** (Amazon 所有) タブを開きます。**[AWSObservabilityExporter-SAP-HANADBExporterInstallAndConfigure\$1]** を選択し、**[Install one time]** (1 回限りのインストール) を選択します。
1. 「Additional Arguments」を次のように置き換えて、最初のステップで作成した SSM パラメータを更新します。
```
{
"SSM_EXPORTER_CONFIG": "{{ssm:<*SSM_CONFIGURATIONS_PARAMETER_STORE_NAME>*}}",
"SSM_SID": "",
"SSM_EXPORTER_METRICS_1": "{{ssm:}}",
"SSM_EXPORTER_METRICS_2": "{{ssm:}}"
}
```
1. SAP HANA データベースを持つ Amazon EC2 インスタンスを選択し、**[Run]** (実行) をクリックします。
## `AWSObservabilityExporter-HAClusterExporterInstallAndConfigure`
[Prometheus HANA クラスターエクスポーター](https://prometheus.io/docs/instrumenting/exporters/#third-party-exporters) から Application Insights 用に ワークロード固有の High Availability (HA) クラスターメトリクスを取得して、SAP HANA データベースの High Availability セットアップ用のアラームを設定およびモニターリングできます。詳細については、このガイドの「[SAP HANA データベースをモニターリング用に設定する](appinsights-tutorial-sap-hana.md#appinsights-tutorial-sap-hana-set-up)」を参照してください。
[AWS Systems Manager Distributor](https://docs.aws.amazon.com/systems-manager/latest/userguide/distributor.html) を使用して、AWS が提供する Prometheus HA クラスター Exporter のパッケージを Application Insights とは別にパッケージ化、インストール、設定するには、次の手順を完了します。
**Prometheus HA クラスター Exporter SSM パッケージを使用するための前提条件**
+ SSM エージェントバージョン 2.3.1550.0 以降がインストールされている
+ Pacemaker、Corosync、SBD、DRBD 用の HA クラスター
+ Linux オペレーティングシステム (SUSE Linux、RedHat Linux)
**`AWSObservabilityExporter-HAClusterExporterInstallAndConfigure` パッケージをインストールして設定する**
`AWSObservabilityExporter-HAClusterExporterInstallAndConfigure` パッケージは、Prometheus HA クラスター Exporter のインストールおよび設定に使用できる SSM Distributor のパッケージです。Prometheus HANA データベース Exporter によってクラスターメトリクスが送信されると、CloudWatch サービスのメトリクスを取得するように CloudWatch エージェントを設定できます。
1. [SSM パラメータストア](https://console.aws.amazon.com/systems-manager/parameters)で SSM パラメータを作成して、Exporter の設定を JSON 形式で保存します。パラメータ値の例を次に示します。
```
{\"port\":\"9664\",\"address\":\"0.0.0.0\",\"log-level\":\"info\",\"crm-mon-path\":\"/usr/sbin/crm_mon\",\"cibadmin-path\":\"/usr/sbin/cibadmin\",\"corosync-cfgtoolpath-path\":\"/usr/sbin/corosync-cfgtool\",\"corosync-quorumtool-path\":\"/usr/sbin/corosync-quorumtool\",\"sbd-path\":\"/usr/sbin/sbd\",\"sbd-config-path\":\"/etc/sysconfig/sbd\",\"drbdsetup-path\":\"/sbin/drbdsetup\",\"enable-timestamps\":false}
```
エクスポーターの設定についての詳細は、GitHub の「[https://github.com/ClusterLabs/ha_cluster_exporter/blob/master/ha_cluster_exporter.yaml](https://github.com/ClusterLabs/ha_cluster_exporter/blob/master/ha_cluster_exporter.yaml) repo」を参照してください。
1. [SSM Distributor](https://console.aws.amazon.com/systems-manager/distributor) コンソールに移動し、**[Owned by Amazon]** (Amazon 所有) タブを開きます。**[AWSObservabilityExporter-HAClusterExporterInstallAndConfigure\$1]** を選択し、**[Install one time]** (1 回限りのインストール) を選択します。
1. 「Additional Arguments」を次のように置き換えて、最初のステップで作成した SSM パラメータを更新します。
```
{
"SSM_EXPORTER_CONFIG": "{{ssm:<*SSM_CONFIGURATIONS_PARAMETER_STORE_NAME>*}}"
}
```
1. SAP HANA データベースを持つ Amazon EC2 インスタンスを選択し、**[Run]** (実行) をクリックします。
## `AWSObservabilityExporter-SAP-SAPHostExporterInstallAndConfigure`
Application Insights の [Prometheus SAP ホストエクスポーター](https://prometheus.io/docs/instrumenting/exporters/#third-party-exporters)からワークロード固有の SAP NetWeaver メトリクスを取得して、SAP NetWeaver Distributed and High Availability デプロイ用のアラームを設定およびモニターリングできます。
[AWS Systems Manager Distributor](https://docs.aws.amazon.com/systems-manager/latest/userguide/distributor.html) を使用して、SAP ホストエクスポーターパッケージを Application Insights とは別にパッケージ化、インストール、および設定するには、次の手順を実行します。
**Prometheus SAP ホストエクスポーター SSM パッケージを使用するための前提条件**
+ SSM エージェントバージョン 2.3.1550.0 以降がインストールされている
+ SAP NetWeaver アプリケーションサーバー
+ Linux オペレーティングシステム (SUSE Linux、RedHat Linux)
**`AWSObservabilityExporter-SAP-SAPHostExporterInstallAndConfigure` パッケージをインストールして設定する**
`AWSObservabilityExporter-SAP-SAPHostExporterInstallAndConfigure` パッケージは、SAP NetWeaver Prometheus メトリクスエクスポーターのインストールおよび設定に使用できる SSM Distributor パッケージです。Prometheus エクスポーターによって SAP NetWeaver メトリクスが送信されると、CloudWatch サービスのメトリクスを取得するように CloudWatch エージェントを設定できます。
1. [SSM パラメータストア](https://console.aws.amazon.com/systems-manager/parameters)で SSM パラメータを作成して、Exporter の設定を JSON 形式で保存します。パラメータ値の例を次に示します。
```
{\"address\":\"0.0.0.0\",\"port\":\"9680\",\"log-level\":\"info\",\"is-HA\":false}
```
+ **address**
Prometheus メトリクスの送信先となるターゲットアドレス。デフォルト値は `localhost` です。
+ **port**
Prometheus メトリクスの送信先となるターゲットポート。デフォルト値は `9680` です。
+ **is-HA**
SAP NetWeaver High Availability のデプロイでは [`true`]。他のすべてのデプロイで、値は `false` です。
1. [SSM Distributor](https://console.aws.amazon.com/systems-manager/distributor) コンソールに移動し、**[Owned by Amazon]** (Amazon 所有) タブを開きます。**AWSObservabilityExporter-SAP-SAPHostExporterInstallAndConfigure** を選択し、**[Install one time]** (1 回限りのインストール) を選択します。
1. 「Additional Arguments」を次のように置き換えて、最初のステップで作成した SSM パラメータを更新します。
```
{
"SSM_EXPORTER_CONFIG": "{{ssm:}}",
"SSM_SID": "",
"SSM_INSTANCES_NUM": ""
}
```
**例**
```
{
"SSM_EXPORTER_CONFIG": "{{ssm:exporter_config_paramter}}",
"SSM_INSTANCES_NUM": "11,12,10",
"SSM_SID": "PR1"
}
```
1. SAP NetWeaver アプリケーションを含む Amazon EC2 インスタンスを選択し、**[Run]** (実行) を選択します。
**注記**
Prometheus エクスポーターは、ローカルエンドポイントで SAP NetWeaver メトリクスを処理します。ローカルエンドポイントには Amazon EC2 インスタンスのオペレーティングシステムユーザーのみがアクセスできます。そのため、エクスポーターパッケージをインストールすると、すべてのオペレーティングシステムユーザーがメトリクスを利用できるようになります。デフォルトのローカルエンドポイントは `localhost:9680/metrics` です。
## `AWSObservabilityExporter-SQLExporterInstallAndConfigure`
Application Insights の [Prometheus SQL エクスポーター](https://prometheus.io/docs/instrumenting/exporters/#third-party-exporters)からワークロード固有の SQL Server メトリクスを取得して、主要なメトリクスをモニタリングできます。
[AWS Systems Manager Distributor](https://docs.aws.amazon.com/systems-manager/latest/userguide/distributor.html) を使用して、SQL エクスポーターパッケージを Application Insights とは別にパッケージ化、インストール、および設定するには、次のステップを実行します。
**Prometheus SQL エクスポーター SSM パッケージを使用するための前提条件**
+ SSM エージェントバージョン 2.3.1550.0 以降がインストールされている
+ SQL Server ユーザー認証が有効になっている Windows 上で SQL Server を実行している Amazon EC2 インスタンス。
+ 次の許可を持つ SQL Server ユーザー:
```
GRANT VIEW ANY DEFINITION TO
```
```
GRANT VIEW SERVER STATE TO
```
+ AWS Secrets Manager を使用したデータベース接続文字列を含むシークレット。シークレットを作成する方法については、*AWS Secrets Manager ユーザーガイド*の「[シークレットを作成する](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html)」を参照してください。シークレットは、次のようにフォーマットする必要があります。
```
{
"data_source_name":"sqlserver://:@localhost:1433"
}
```
**注記**
パスワードまたはユーザー名に特殊文字が含まれている場合は、データベースに正常に接続できるように特殊文字をパーセントエンコーディングする必要があります。
**`AWSObservabilityExporter-SQLExporterInstallAndConfigure` パッケージをインストールして設定する**
`AWSObservabilityExporter-SQLExporterInstallAndConfigure` パッケージは、SQL Prometheus メトリクスエクスポーターのインストールおよび設定に使用できる SSM Distributor パッケージです。Prometheus エクスポーターによってメトリクスが送信されると、CloudWatch サービスのメトリクスを取得するように CloudWatch エージェントを設定できます。
1. 任意で、SQL エクスポーター YAML 設定を準備します。次のサンプル設定では、単一のメトリクスが設定されています。[設定例](https://github.com/burningalchemist/sql_exporter/blob/master/examples/sql_exporter.yml)を使用して、追加のメトリクスで設定を更新するか、または独自の設定を作成します。
```
---
global:
scrape_timeout_offset: 500ms
min_interval: 0s
max_connections: 3
max_idle_connections: 3
target:
aws_secret_name:
collectors:
- mssql_standard
collectors:
- collector_name: mssql_standard
metrics:
- metric_name: mssql_batch_requests
type: counter
help: 'Number of command batches received.'
values: [cntr_value]
query: |
SELECT cntr_value
FROM sys.dm_os_performance_counters WITH (NOLOCK)
WHERE counter_name = 'Batch Requests/sec'
```
1. Base64 としてエンコードされた Prometheus SQL エクスポーターの YAML 設定ファイルを、[SSM Parameter Store](https://console.aws.amazon.com/systems-manager/parameters) の新しい SSM パラメータにコピーします。
1. [SSM Distributor](https://console.aws.amazon.com/systems-manager/distributor) コンソールに移動し、**[Owned by Amazon]** (Amazon 所有) タブを開きます。**AWSObservabilityExporter-SQLExporterInstallAndConfigure** を選択し、**[1 回限りのインストール]** を選択します。
1. 「Additional Arguments」を次の情報に置き換えます。`SSM_PARAMETER_NAME` は、ステップ 2 で作成したパラメータの名前です。
```
{
"SSM_EXPORTER_CONFIGURATION":
"{{ssm:}}",
"SSM_PROMETHEUS_PORT": "9399",
"SSM_WORKLOAD_NAME": "SQL"
}
```
1. SQL Server データベースを含む Amazon EC2 インスタンスを選択し、[実行] を選択します。
# CloudWatch Application Insights で使用される AWS Systems Manager (SSM) ドキュメント
Application Insights は、このセクションに記載されている SSM ドキュメントを使用して、AWS Systems Manager がマネージドインスタンスで実行するアクションを定義します。これらのドキュメントでは、Systems Manager の `Run Command` 機能を使用して、Application Insights のモニタリング機能の実行に必要なタスクを自動化しています。これらのドキュメントの実行スケジュールは、Application Insights によって管理されており、変更することはできません。
SSM ドキュメントの詳細については、「AWS Systems Manager ユーザーガイド」の「[AWS Systems Manager ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html)」を参照してください。
## CloudWatch Application Insights によって管理されるドキュメント
次の表は、Application Insights によって管理される SSM ドキュメントの一覧です。
| ドキュメント名 | 説明 | 実行スケジュール |
| --- | --- | --- |
| `AWSEC2-DetectWorkload` | Application Insights によるモニタリング対象として設定できるアプリケーション環境で実行されているアプリケーションを自動検出します。 | このドキュメントはアプリケーション環境で 1 時間ごとに実行され、アプリケーションに関する最新の詳細情報を取得します。 |
| `AWSEC2-CheckPerformanceCounterSets` | Amazon EC2 Windows インスタンスでパフォーマンスカウンターの名前空間が有効になっているかどうかを確認します。 | このドキュメントはアプリケーション環境で 1 時間ごとに実行され、対応する名前空間が有効になっている場合にのみパフォーマンスカウンターのメトリクスをモニタリングします。 |
| `AWSEC2-ApplicationInsightsCloudwatchAgentInstallAndConfigure` | アプリケーションコンポーネントのモニタリング設定に基づいて、CloudWatch エージェントをインストールして設定します。 | このドキュメントは 30 分ごとに実行され、CloudWatch エージェントの設定が常に正確で最新の状態になるようにします。また、このドキュメントは、メトリクスの追加や削除、ログ設定の更新など、アプリケーションのモニタリング設定に変更が加えられた直後にも実行されます。 |
## AWS Systems Manager によって管理されるドキュメント
次のドキュメントは、CloudWatch Application Insights によって使用され、Systems Manager によって管理されます。
**`AWS-ConfigureAWSPackage`**
Application Insights はこのドキュメントを使用して、Prometheus エクスポーターディストリビューターパッケージのインストールとアンインストールを行い、ワークロード固有のメトリクスを収集し、顧客の Amazon EC2 インスタンスでワークロードを包括的にモニタリングできるようにします。CloudWatch Application Insights は、相関関係のあるターゲットワークロードがインスタンスで実行されている場合にのみ、Prometheus エクスポーターディストリビューターパッケージをインストールします。
次の表は、Prometheus エクスポーターディストリビューターパッケージと、相関関係のあるターゲットワークロードの一覧です。
| Prometheus エクスポーターディストリビューターパッケージ名 | ターゲットワークロード |
| --- | --- |
| `AWSObservabilityExporter-HAClusterExporterInstallAndConfigure` | SAP HANA HA |
| `AWSObservabilityExporter-JMXExporterInstallAndConfigure` | Java/JMX |
| `AWSObservabilityExporter-SAP-HANADBExporterInstallAndConfigure` | SAP HANA |
| `AWSObservabilityExporter-SAP-SAPHostExporterInstallAndConfigure` | NetWeaver |
| `AWSObservabilityExporter-SQLExporterInstallAndConfigure` | SQL サーバー (Windows) と SAP ASE (Linux) |
**`AmazonCloudWatch-ManageAgent`**
Application Insights はこのドキュメントを使用して、インスタンスで CloudWatch エージェントのステータスと設定を管理し、オペレーティングシステム全体で Amazon EC2 インスタンスから内部システムレベルのメトリクスとログを収集します。
# CloudWatch Application Insights にアクセスするために必要な前提条件、IAM ポリシー、およびアクセス許可
CloudWatch Application Insights の使用を開始するには、次の前提条件を満たしていること、IAM ポリシーを作成していること、必要に応じてアクセス許可をアタッチしていることを確認します。
**Topics**
+ [
# モニタリングできるようにアプリケーションを設定するための前提条件
](appinsights-prereqs.md)
+ [
# CloudWatch Application Insights の IAM ポリシー
](appinsights-iam.md)
+ [
# アカウントベースのアプリケーションのオンボーディングに対する IAM ロールのアクセス許可
](appinsights-account-based-onboarding-permissions.md)
# モニタリングできるようにアプリケーションを設定するための前提条件
CloudWatch Application Insights でアプリケーションを設定するには、以下の前提条件を満たす必要があります。
+ **AWS Systems Manager の有効化** – Amazon EC2 インスタンスに Systems Manager Agent (SSM Agent) をインストールし、インスタンスを SSM に対して有効にします。SSM Agent のインストール方法についての詳細は、「AWS Systems Manager ユーザーガイド」の「[AWS Systems Manager のセットアップ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up.html)」を参照してください。
+ **EC2 インスタンスロール** – Systems Manager を有効にするには、次の Amazon EC2 インスタンスロールをアタッチする必要があります。
+ Systems Manager を有効にする `AmazonSSMManagedInstanceCore` ロールをアタッチする必要があります。詳細については、「[AWS Systems Manager アイデンティティベースのポリシーの例](https://docs.aws.amazon.com/systems-manager/latest/userguide/auth-and-access-control-iam-identity-based-access-control.html)」を参照してください。
+ インスタンスメトリクスとログが CloudWatch を介して出力されるように `CloudWatchAgentServerPolicy` ポリシーをアタッチする必要があります。詳細については、「[CloudWatch エージェントで使用する IAM ロールとユーザーを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-iam-roles-for-cloudwatch-agent.html)」を参照してください
+ **AWS リソースグループ** – アプリケーションを CloudWatch Application Insights にオンボードするには、アプリケーションスタックで使用されるすべての関連する AWS リソースが含まれるリソースグループを作成する必要があります。これには、Application Load Balancer、IIS とウェブフロントエンドを実行する Amazon EC2 インスタンス、.NET ワーカー階層、および SQL Server データベースが含まれます。Application Insights がサポートするアプリケーションコンポーネントとテクノロジースタックの詳細については、「[サポートされるアプリケーションコンポーネント](appinsights-what-is.md#appinsights-components)」を参照してください。CloudWatch Application Insights では、同じタグを使用する Auto Scaling グループまたは CloudFormation スタックがリソースグループとして自動的に包含されます。Auto Scaling グループは CloudFormation リソースグループでサポートされていないためです。詳細については、「[AWS Resource Groups の開始方法](https://docs.aws.amazon.com/ARG/latest/userguide/gettingstarted.html)」を参照してください。
+ **IAM アクセス許可** – 管理アクセスが許可されていないユーザーについては、Application Insights でサービスにリンクされたロールを作成できる AWS Identity and Access Management (IAM) ポリシーを作成し、ユーザーの ID にアタッチする必要があります。IAM ポリシーを作成する方法については、「[CloudWatch Application Insights の IAM ポリシー](appinsights-iam.md)」を参照してください。
+ **サービスにリンクされたロール** – Application Insights は AWS Identity and Access Management (IAM) サービスにリンクされたロールを使用します。Application Insights コンソールで新しい Application Insights アプリケーションを作成する際、サービスにリンクされたロールが作成されます。詳細については、「[CloudWatch Application Insights のサービスにリンクされたロールの使用](CHAP_using-service-linked-roles-appinsights.md)」を参照してください。
+ **EC2 Windows インスタンスに対するパフォーマンスカウンタメトリクスのサポート** – Amazon EC2 Windows インスタンスでパフォーマンスカウンタメトリクスをモニターリングするには、パフォーマンスカウンタがインスタンスにインストールされている必要があります。パフォーマンスカウンタのメトリクスと対応するパフォーマンスカウンタセット名については、「[パフォーマンスカウンタのメトリクス](application-insights-performance-counter.md)」を参照してください。パフォーマンスカウンタの詳細については、「[パフォーマンスカウンタ](https://docs.microsoft.com/en-us/windows/win32/perfctrs/performance-counters-portal)」を参照してください。
+ **Amazon CloudWatch エージェント** – Application Insights は、CloudWatch エージェントをインストールして設定します。CloudWatch エージェントがインストールされている場合、Application Insights は設定をそのまま維持します。マージ競合を避けるため、既存の CloudWatch エージェント設定ファイルから、Application Insights で使用するリソースの設定を削除してください。詳細については、「[CloudWatch エージェント設定ファイルを手動で作成または編集する](CloudWatch-Agent-Configuration-File-Details.md)」を参照してください。
# CloudWatch Application Insights の IAM ポリシー
CloudWatch Application Insights を使用するには、[AWS Identity and Access Management (IAM) ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)を作成し、ユーザー、グループ、またはロールにアタッチする必要があります。ユーザー、グループ、ロールの詳細については、「[IAM ID (ユーザー、ユーザーグループ、ロール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)」を参照してください。IAM ポリシーは、ユーザーのアクセス許可を定義します。
**コンソールを使用して IAM ポリシーを作成するには**
IAM コンソールを使用して IAM ポリシーを作成するには、次の手順を実行します。
1. [IAM コンソール](https://console.aws.amazon.com/iam/home)に移動します。左のナビゲーションペインで [**ポリシー**] を選択します。
1. ページの上部で [**ポリシーの作成**] を選択します。
1. [**JSON**] タブを選択します。
1. 次の JSON ドキュメントをコピーして、[**JSON**] タブの下に貼り付けます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"applicationinsights:*",
"iam:CreateServiceLinkedRole",
"iam:ListRoles",
"resource-groups:ListGroups"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
1. [**ポリシーの確認**] をクリックします。
1. [**名前**] にポリシー名を入力します (「AppInsightsPolicy」など)。必要に応じて [**説明**] に説明を入力します。
1. [**ポリシーの作成**] を選択します。
1. 左側にあるナビゲーションペインで、**[ユーザーグループ]**、**[ユーザー]**、または **[ロール]** を選択します。
1. ポリシーのアタッチ先とするユーザー名、グループ名、ロール名を選択します。
1. [**Add permissions (アクセス許可の追加)**] を選択します。
1. [**Attach existing policies directly (既存のポリシーを直接アタッチ)**] を選択します。
1. 先ほど作成したポリシーを検索し、ポリシー名の左側にあるチェックボックスをオンにします。
1. 次に、[**次へ: 確認**] を選択します。
1. 適切なポリシーが表示されていることを確認し、 [**Add permissions (アクセス許可の追加)**] を選択します。
1. CloudWatch Application Insights を使用する際は、先ほど作成したポリシーを関連付けたユーザーとしてログインします。
**AWS CLI を使用して IAM ポリシーを作成するには**
AWS CLI を使用して IAM ポリシーを作成するには、上記の JSON ドキュメントを現在のフォルダ内のファイルとして使用して、コマンドラインから [create-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/create-policy.html) オペレーションを実行します。
**AWS Tools for Windows PowerShell を使用して IAM ポリシーを作成するには**
AWS Tools for Windows PowerShell を使用して IAM ポリシーを作成するには、上記の JSON ドキュメントを現在のフォルダ内のファイルとして使用して [New-IAMPolicy](https://docs.aws.amazon.com/powershell/latest/reference/items/New-IAMPolicy.html) cmdlt を実行します。
# アカウントベースのアプリケーションのオンボーディングに対する IAM ロールのアクセス許可
アカウント内のすべてのリソースをオンボードし、Application Insights の機能にフルアクセスするための [Application Insights 管理ポリシー](security-iam-awsmanpol-appinsights.md)を使用しない場合、Application Insights がアカウント内のすべてのリソースを検出できるように、IAM ロールに次のアクセス許可をアタッチする必要があります。
```
"ec2:DescribeInstances"
"ec2:DescribeNatGateways"
"ec2:DescribeVolumes"
"ec2:DescribeVPCs"
"rds:DescribeDBInstances"
"rds:DescribeDBClusters"
"sqs:ListQueues"
"elasticloadbalancing:DescribeLoadBalancers"
"autoscaling:DescribeAutoScalingGroups"
"lambda:ListFunctions"
"dynamodb:ListTables"
"s3:ListAllMyBuckets"
"sns:ListTopics"
"states:ListStateMachines"
"apigateway:GET"
"ecs:ListClusters"
"ecs:DescribeTaskDefinition"
"ecs:ListServices"
"ecs:ListTasks"
"eks:ListClusters"
"eks:ListNodegroups"
"fsx:DescribeFileSystems"
"route53:ListHealthChecks"
"route53:ListHostedZones"
"route53:ListQueryLoggingConfigs"
"route53resolver:ListFirewallRuleGroups"
"route53resolver:ListFirewallRuleGroupAssociations"
"route53resolver:ListResolverEndpoints"
"route53resolver:ListResolverQueryLogConfigs"
"route53resolver:ListResolverQueryLogConfigAssociations"
"logs:DescribeLogGroups"
"resource-explorer:ListResources"
```
# AWS マネジメントコンソールを使用してモニタリングするようにアプリケーションを設定する
このセクションでは、コンソール、AWS CLI、AWS Tools for Windows PowerShell を使用して、CloudWatch Application Insights アプリケーションをセットアップ、設定、管理する手順を説明します。
**Topics**
+ [コンソールの手順](appinsights-setting-up-console.md)
+ [コマンドラインを使用したステップ](appinsights-setting-up-command.md)
+ [Events](appinsights-cloudwatch-events.md)
+ [通知](appinsights-problem-notifications.md)
# CloudWatch コンソールからモニターリングするアプリケーションをセットアップ、設定、管理する
このセクションでは、CloudWatch コンソールからモニターリングするアプリケーションをセットアップ、設定、管理する手順を説明します。
**Topics**
+ [
## アプリケーションの追加と設定
](#appinsights-add-configure)
+ [
## Amazon ECS および Amazon EKS リソースのモニターリングで Application Insights を有効にする
](#appinsights-container-insights)
+ [
## アプリケーションコンポーネントのモニターリングの無効化
](#appinsights-disable-monitoring)
+ [
## アプリケーションの削除
](#appinsights-delete-app)
## アプリケーションの追加と設定
**CloudWatch コンソールからアプリケーションを追加および設定する**
CloudWatch コンソールから CloudWatch Application Insights の使用を開始するには、次の手順を実行します。
1. **起動します。**[CloudWatch コンソールのランディングページ](https://console.aws.amazon.com/cloudwatch)を開きます。左側のナビゲーションペインで、**[Insights]** の下にある **[Application Insights]** を選択します。ページには、CloudWatch Application Insights でモニターリングするアプリケーションのリストと、モニターリングのステータスが表示されます。
1. **アプリケーションを追加します。**アプリケーションのモニターリングを設定するには、**[Add an application]** (アプリケーションの追加) を選択します。**[Add an application]** (アプリケーションの追加) を選択すると、**[Choose Application Type]** (アプリケーションタイプを選択してください) というプロンプトが表示されます。
+ **リソースグループベースのアプリケーション**。このオプションを選択すると、このアカウント内でモニターリングするリソースグループを選択できます。コンポーネントで複数のアプリケーションを使用するには、リソースグループベースのモニタリングを使用する必要があります。
+ **アカウントベースのアプリケーション**。このオプションを選択すると、このアカウント内のすべてのリソースをモニターリングできます。このオプションでは、アプリケーションのオンボーディングプロセスが高速になるため、アカウント内のすべてのリソースをモニターリングする場合、リソースグループベースのオプションよりもこのオプションを使用することをお勧めします。
**注記**
Application Insights を使用して、リソースグループベースのモニターリングとアカウントベースのモニターリングを組み合わせることはできません。アプリケーションのタイプを変更するには、モニターリング対象のすべてのアプリケーションを削除して、**アプリケーションタイプを選択**する必要があります。
モニターリングする最初のアプリケーションを追加すると、CloudWatch Application Insights によってサービスにリンクされたロールがアカウントに作成されます。これにより、お客様に代わって他の AWS サービスを呼び出すアクセス許可が Application Insights に与えられます。Application Insights によってアカウントに作成されるサービスにリンクされたロールについての詳細は、「[CloudWatch Application Insights のサービスにリンクされたロールの使用](CHAP_using-service-linked-roles-appinsights.md)」を参照してください。
1.
------
#### [ Resource-based application monitoring ]
1. **アプリケーションまたはリソースグループを選択します。****[Specify application details]** (アプリケーションの詳細の指定) ページで、ドロップダウンリストからアプリケーションリソースを含む AWS リソースグループを選択します。これらのリソースには、フロントエンドサーバー、ロードバランサー、Auto Scaling グループ、データベースサーバーが含まれます。
アプリケーション用のリソースグループをまだ作成していない場合は、**[Create new resource group]** (新しいリソースグループの作成) を選択して作成できます。リソースグループの作成についての詳細は、[https://docs.aws.amazon.com/ARG/latest/userguide/welcome.html](https://docs.aws.amazon.com/ARG/latest/userguide/welcome.html)を参照してください。
1. **問題の分析情報の通知。**選択したアプリケーションで問題が検出された場合に通知を表示するには、[Amazon SNS 通知] または [Systems Manager の OpsCenter Opsitems] を選択します。
1. **Amazon SNS 通知を設定します (推奨）。****[既存のトピックの選択]** または **[トピックの新規作成]** を選択します。
1. **AWS Systems Manager OpsCenter との統合。****[詳細設定]** で、**[修正アクションの Systems Manager OpsCenter OpsItems の生成]** チェックボックスをオンにします。AWS リソースに関連するオペレーション作業項目 (OpsItems) を解決するために実行されたオペレーションを追跡するには、Amazon SNS トピックの ARN を指定します。
1. **CloudWatch Events のモニターリング**。CloudWatch Events と Application Insights のモニターリングを統合できるチェックボックスをオンにすると、Amazon EBS、Amazon EC2、AWS CodeDeploy、Amazon ECS、AWS Health APIs And Notifications、Amazon RDS、Amazon S3、および AWS Step Functions からのインサイトを取得できます。
1. **タグ ― オプション**。CloudWatch Application Insights は、タグベースのリソースグループと CloudFormation ベースのリソースグループ (Auto Scaling グループを除く) の両方をサポートしています。詳細については、「[タグエディタの使用](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html)」を参照してください。
1. [**次へ**] を選択します。
[ARN](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) は、アプリケーション用に次のフォーマットで生成されます。
```
arn:partition:applicationinsights:region:account-id:application/resource-group/resource-group-name
```
例
```
arn:aws:applicationinsights:us-east-1:123456789012:application/resource-group/my-resource-group
```
1. **[検出されたコンポーネントを確認]** ページの **[モニタリング用のコンポーネントを確認]** の下の表には、検出されたコンポーネントとそれに関連して検出されたワークロードが一覧表示されます。
**注記**
複数のカスタマイズされたワークロードをサポートするコンポーネントでは、コンポーネントごとに最大 5 つのワークロードをモニタリングできます。これらのワークロードはコンポーネントとは別にモニタリングされます。
![\[CloudWatch Application Insights コンソールの検出されたコンポーネントのセクション: 検出されたコンポーネントと関連付けられたワークロードの概要。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-multiapp-review-component.png)
ワークロードがリストされていない場合、**[関連付けられたワークロード]** にいくつかのメッセージが表示される可能性があります。
+ **ワークロードを検出できませんでした** — ワークロードを検出しようとしたときに問題が発生しました。[モニタリングできるようにアプリケーションを設定するための前提条件](appinsights-prereqs.md) が完了していることを確認してください。ワークロードを追加する必要がある場合は、**[コンポーネントを編集]** を選択します。
+ **ワークロードは検出されませんでした** — ワークロードは検出されませんでした。ワークロードを追加する必要がある場合があります。そのためには、**[コンポーネントを編集]** を選択します。
+ **該当なし** — コンポーネントは、カスタマイズされたワークロードをサポートしていないため、デフォルトのメトリクス、アラーム、ログでモニタリングされます。これらのコンポーネントにはワークロードを追加できません。
1. コンポーネントを編集するには、コンポーネントを選択し、**[コンポーネントを編集]** を選択します。サイドパネルが開き、コンポーネントで検出されたワークロードが表示されます。このパネルでは、コンポーネントの詳細を編集したり、新しいワークロードを追加したりできます。
![\[CloudWatch Application Insights コンソールの検出されたコンポーネントの確認セクション: 関連付けられたワークロードは編集可能です。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-multiapp-edit-component.png)
+ ワークロードのタイプまたは名前を編集するには、ドロップダウンリストを使用します。
![\[CloudWatch Application Insights コンソールのコンポーネント編集セクション: ワークロードタイプのドロップダウンリスト。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-multiapp-edit-name-type.png)
+ コンポーネントにワークロードを追加するには、**[新しいワークロードを追加]** を選択します。
![\[CloudWatch Application Insights コンソールのコンポーネント編集セクション: 左下のボタンをクリックすると、新しいワークロードを追加できます。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-multiapp-add-workload.png)
+ **[新しいワークロードを追加]** が表示されない場合は、このコンポーネントは複数のワークロードをサポートしていません。
+ 「**関連付けられたワークロード**」という見出しが表示されない場合、このコンポーネントはカスタマイズされたワークロードをサポートしていません。
+ ワークロードを削除するには、モニタリングから削除するワークロードの横にある **[削除]** を選択します。
![\[CloudWatch Application Insights コンソールの編集コンポーネントセクション: ワークロードを削除します。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-multiapp-remove-workload.png)
+ コンポーネント全体のモニタリングを無効にするには、**[モニタリング]** チェックボックスをオフにします。
![\[モニタリングを無効にするための [CloudWatch Application Insights] チェックボックスのコンポーネント編集セクション。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-multiapp-disable-monitoring.png)
+ コンポーネントの編集が完了したら、右下隅の **[変更を保存]** を選択します。コンポーネントのワークロードに加えられた変更は、**[関連付けられたワークロード]** の下の **[モニタリング用のコンポーネントを確認]** テーブルに表示されます。
1. **[検出されたコンポーネントを確認]** ページで **[次へ]** を選択します。
1. **[コンポーネントの詳細を指定]** ページには、カスタマイズ可能な関連付けられたワークロードを持つすべてのコンポーネントが含まれています。
**注記**
コンポーネントヘッダーにオプションのタグが付いている場合、そのコンポーネントのワークロードに関する詳細を追加することはオプションになります。
このページにコンポーネントが表示されない場合、コンポーネントにはこのステップで指定できる追加の詳細情報はありません。
1. [**次へ**] を選択します。
1. **[確認して送信]** ページで、モニタリング対象のすべてのコンポーネントとワークロードの詳細を確認します。
1. [**Submit**] を選択してください。
------
#### [ Account-based application monitoring ]
1. **アプリケーション名**。アカウントベースのアプリケーションの名前を入力します。
1. **新しいリソースの自動モニターリング**。デフォルトでは、Application Insights では推奨設定が使用され、アプリケーションのオンボーディング後にアカウントに追加されるリソースコンポーネントのモニターリングが設定されます。チェックボックスをオフにすると、アプリケーションのオンボーディング後に追加されるリソースのモニターリングを除外できます。
1. **CloudWatch Events のモニターリング**。CloudWatch Events と Application Insights のモニターリングを統合できるチェックボックスをオンにすると、Amazon EBS、Amazon EC2、AWS CodeDeploy、Amazon ECS、AWS Health APIs And Notifications、Amazon RDS、Amazon S3、および AWS Step Functions からのインサイトを取得できます。
1. **AWS Systems Manager OpsCenter との統合。**選択したアプリケーションで問題が検出された場合に通知を表示するには、**[Generate Systems Manager OpsCenter OpsItems for remedial actions]** (Systems Manager の OpsCenter OpsItems を生成して修復アクションを行う) チェックボックスをオンにします。AWS リソースに関連するオペレーション作業項目 (OpsItems) を解決するために実行されたオペレーションを追跡するには、SNS トピックの ARN を指定します。
1. **タグ ― オプション**。CloudWatch Application Insights は、タグベースのリソースグループと CloudFormation ベースのリソースグループ (Auto Scaling グループを除く) の両方をサポートしています。詳細については、「[タグエディタの使用](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html)」を参照してください。
1. **検出されるリソース**。アカウント内で検出されるすべてのリソースがこのリストに追加されます。Application Insights がアカウント内のリソースをすべて検出できない場合、ページ上部にエラーメッセージが表示されます。このメッセージには、[必要なアクセス許可を追加する方法についてのドキュメント](appinsights-account-based-onboarding-permissions.md)へのリンクが含まれます。
1. [**次へ**] を選択します。
[ARN](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) は、アプリケーション用に次のフォーマットで生成されます。
```
arn:partition:applicationinsights:region:account-id:application/TBD/application-name
```
例
```
arn:aws:applicationinsights:us-east-1:123456789012:application/TBD/my-application
```
------
1. アプリケーションのモニターリング設定を送信すると、アプリケーションの詳細ページが表示され、[**Application summary**] (アプリケーションの概要)、[**Monitored components**] (モニターリングされているコンポーネント) そして [**Unmonitored components**] (モニターリングされていないコンポーネント) のリストを確認できます。また、[**Components**] (コンポーネント) の横にあるタブを選択すると、[**Configuration history**] (設定履歴)、[**Log patterns**] (ログのパターン)、適応した [**Tags**] (タグ) を確認できます。
アプリケーションのインサイトを表示するには、**[View Insights]** (インサイトを表示する) をクリックします。
**[Edit]** (編集)を選択すると、CloudWatch Events のモニターリングおよび AWS Systems Manager OpsCenter との統合に関する選択内容を更新できます。
**[Components]** (コンポーネント) の **[Actions]** (アクション) メニューを選択して、インスタンスグループを作成、変更、またはグループ解除できます。
コンポーネントの横にある箇条書きから **[Manage monitoring]** (モニターリングの管理) を選択して、アプリケーション層、ロググループ、イベントログ、メトリクス、カスタムアラームなどのコンポーネントのモニターリングを管理できます。
## Amazon ECS および Amazon EKS リソースのモニターリングで Application Insights を有効にする
Application Insights を有効にして、コンテナ化されたアプリケーションとマイクロサービスを Container Insights コンソールからモニターリングできます。Application Insights は、次のリソースのモニターリングをサポートしています。
+ Amazon ECS クラスター
+ Amazon ECS サービス
+ Amazon ECS タスク
+ Amazon EKS クラスター
Application Insights を有効にすると、推奨されるメトリクスとログが提供され、潜在的な問題が検出され、CloudWatch Events が生成されます。また、コンテナ化されたアプリケーションとマイクロサービスの自動ダッシュボードが作成されます。
コンテナ化されたリソースの Application Insights は、Container Insights コンソールまたは Application Insights コンソールから有効にできます。
**Container Insights コンソールから Application Insights を有効にする**
Container Insights コンソール、Container Insights の **[Performance monitoring]** (パフォーマンスのモニターリング) ダッシュボードで、**[Auto-configure Application Insights]** (アプリケーションインサイトの自動設定) を選択します。Application Insights を有効にすると、検出された問題の詳細が表示されます。
**Application Insights コンソールから Application Insights を有効にする**
ECS クラスターがコンポーネントリストに表示されると、Application Insights では Container Insights によるコンテナのモニターリングが追加で自動的に有効になります。
EKS クラスターでは、Container Insights によるモニターリングを追加で有効にできます。これによりコンテナにおける再起動の失敗などの診断情報が提供され、問題の特定と解決に役立てることができます。EKS 用に Container Insights を設定するには、追加の手順が必要です。詳細については「[Amazon EKS と Kubernetes での Container Insights のセットアップ](deploy-container-insights-EKS.md)」を参照して、EKS で Container Insights を設定する手順をご覧ください。
Container Insights を使用した EKS での追加のモニターリングは、EKS を持つ Linux インスタンスでサポートされています。
ECS および EKS クラスター向けの Container Insights のサポートについての詳細は、「[Container Insights](ContainerInsights.md)」を参照してください。
## アプリケーションコンポーネントのモニターリングの無効化
アプリケーションコンポーネントのモニターリングを無効にするには、アプリケーションの詳細ページから、モニターリングを無効にするコンポーネントを選択します。**[Actions]** (アクション)、**[Remove from monitoring]** (モニターリングから削除) の順に選択します。
## アプリケーションの削除
アプリケーションを削除するには、CloudWatch ダッシュボードの左側のナビゲーションペインで、[**Insights**] の下にある [**Application Insights**] を選択します。削除するアプリケーションを選択します。**[Actions]** (アクション) から、**[Delete application]** (アプリケーションの削除) を選択します。これにより、モニターリングが削除され、アプリケーションコンポーネントのすべての保存済みモニターリングが削除されます。アプリケーションリソースは削除されません。
# コマンドラインを使用してモニターリングするアプリケーションをセットアップ、設定、管理する
このセクションでは、AWS CLI および AWS Tools for Windows PowerShell を使用して、モニターリング用アプリケーションをセットアップ、設定、管理する手順について説明します。
**Topics**
+ [
## アプリケーションの追加と管理
](#appinsights-config-app-command)
+ [
## モニターリングの管理と更新
](#appinsights-monitoring)
+ [
## SQL Always On 可用性グループのモニターリングを設定する
](#configure-sql)
+ [
## MySQL RDS のモニターリングを設定する
](#configure-mysql-rds)
+ [
## MySQL EC2 のモニターリングを設定する
](#configure-mysql-ec2)
+ [
## PostgreSQL RDS のモニターリングを設定する
](#configure-postgresql-rds)
+ [
## PostgreSQL EC2 のモニターリングを設定する
](#configure-postgresql-ec2)
+ [
## Oracle RDS のモニターリングを設定する
](#configure-oracle-rds)
+ [
## Oracle EC2 のモニターリングを設定する
](#configure-oracle-ec2)
## アプリケーションの追加と管理
コマンドラインを使用して、Application Insights アプリケーションの追加、情報の取得、管理、設定を行うことができます。
**Topics**
+ [
### アプリケーションを追加する
](#appinsights-add-app)
+ [
### アプリケーションを記述する
](#appinsights-describe-app)
+ [
### アプリケーションのコンポーネントをリスト化する
](#appinsights-list-components)
+ [
### コンポーネントを記述する
](#appinsights-describe-components)
+ [
### 類似したリソースをカスタムコンポーネントとしてグループ化する
](#appinsights-group-resources-components)
+ [
### カスタムコンポーネントをグループ解除する
](#appinsights-ungroup-resources-components)
+ [
### アプリケーションを更新する
](#appinsights-update-app)
+ [
### カスタムコンポーネントを更新する
](#appinsights-update-component)
### アプリケーションを追加する
**AWS CLI を使用してアプリケーションを追加する**
AWS CLI を使用して、リソースグループ名が `my-resource-group` のアプリケーションを追加し、作成された opsItem が SNS トピック (ARN ` arn:aws:sns:us-east-1:123456789012:MyTopic`) に対し配信されるように OpsCenter を有効化するには、次のコマンドを使用します。
```
aws application-insights create-application --resource-group-name my-resource-group --ops-center-enabled --ops-item-sns-topic-arn arn:aws:sns:us-east-1:123456789012:MyTopic
```
**AWS Tools for Windows PowerShell を使用してアプリケーションを追加する**
AWS Tools for Windows PowerShell を使用して、リソースグループ名が `my-resource-group` のアプリケーションを追加し、作成された opsItem が SNS トピック ARN `arn:aws:sns:us-east-1:123456789012:MyTopic` に配信されるように OpsCenter を有効化するには、次のコマンドを使用します。
```
New-CWAIApplication -ResourceGroupName my-resource-group -OpsCenterEnabled true -OpsItemSNSTopicArn arn:aws:sns:us-east-1:123456789012:MyTopic
```
### アプリケーションを記述する
**AWS CLI を使用してアプリケーションを記述する**
AWS CLI を使用して、`my-resource-group` というリソースグループに作成されたアプリケーションを記述するには、次のコマンドを使用します。
```
aws application-insights describe-application --resource-group-name my-resource-group
```
**AWS Tools for Windows PowerShell を使用してアプリケーションを記述する**
AWS Tools for Windows PowerShell を使用して、`my-resource-group` というリソースグループに作成されたアプリケーションを記述するには、次のコマンドを使用します。
```
Get-CWAIApplication -ResourceGroupName my-resource-group
```
### アプリケーションのコンポーネントをリスト化する
**AWS CLI を使用してアプリケーションのコンポーネントを一覧表示する**
AWS CLI を使用して、`my-resource-group` というリソースグループで作成されたコンポーネントを一覧表示するには、次のコマンドを使用します。
```
aws application-insights list-components --resource-group-name my-resource-group
```
**AWS Tools for Windows PowerShell を使用してアプリケーションのコンポーネントを一覧表示する**
AWS Tools for Windows PowerShell を使用して、`my-resource-group` というリソースグループで作成されたコンポーネントを一覧表示するには、次のコマンドを使用します。
```
Get-CWAIComponentList -ResourceGroupName my-resource-group
```
### コンポーネントを記述する
**AWS CLI を使用してコンポーネントを記述する**
次の AWS CLI コマンドを使用して、`my-resource-group` というリソースグループで作成されたアプリケーションに属する `my-component` というコンポーネントを記述できます。
```
aws application-insights describe-component --resource-group-name my-resource-group --component-name my-component
```
**AWS Tools for Windows PowerShell を使用してコンポーネントを記述する**
次の AWS Tools for Windows PowerShell コマンドを使用して、`my-resource-group` というリソースグループで作成されたアプリケーションに属する `my-component` というコンポーネントを記述できます。
```
Get-CWAIComponent -ComponentName my-component -ResourceGroupName my-resource-group
```
### 類似したリソースをカスタムコンポーネントとしてグループ化する
類似したリソース (.NET ウェブサーバーインスタンスなど) をカスタムコンポーネントとしてグループ化することをお勧めします。これにより、オンボーディングが容易になり、モニタリングとインサイトが向上します。CloudWatch Application Insights は EC2 インスタンスのカスタムグループをサポートしています。
**AWS CLI を使用してリソースをカスタムコンポーネントとしてグループ化するには**
AWS CLI を使用して 3 つのインスタンス (`arn:aws:ec2:us-east-1:123456789012:instance/i-11111`、`arn:aws:ec2:us-east-1:123456789012:instance/i-22222` および `arn:aws:ec2:us-east-1:123456789012:instance/i-33333`) をグループ化し、リソースグループ名 `my-component` で作成されたアプリケーション用としてカスタムコンポーネント `my-resource-group` に含めるには、次のコマンドを使用します。
```
aws application-insights create-component --resource-group-name my-resource-group --component-name my-component --resource-list arn:aws:ec2:us-east-1:123456789012:instance/i-11111 arn:aws:ec2:us-east-1:123456789012:instance/i-22222 arn:aws:ec2:us-east-1:123456789012:instance/i-33333
```
**AWS Tools for Windows PowerShell を使用してリソースをカスタムコンポーネントとしてグループ化するには**
AWS Tools for Windows PowerShell を使用して 3 つのインスタンス (`arn:aws:ec2:us-east-1:123456789012:instance/i-11111`、`arn:aws:ec2:us-east-1:123456789012:instance/i-22222`、および `arn:aws:ec2:us-east-1:123456789012:instance/i-33333`) をまとめて、`my-component` というリソースグループ用に作成されたアプリケーションに対して `my-resource-group` というカスタムコンポーネントとしてグループ化するには、次のコマンドを使用します。
```
New-CWAIComponent -ResourceGroupName my-resource-group -ComponentName my-component -ResourceList arn:aws:ec2:us-east-1:123456789012:instance/i-11111,arn:aws:ec2:us-east-1:123456789012:instance/i-22222,arn:aws:ec2:us-east-1:123456789012:instance/i-33333
```
### カスタムコンポーネントをグループ解除する
**AWS CLI を使用してカスタムコンポーネントのグループ化を解除するには**
AWS CLI を使用して、リソースグループ `my-resource-group` で作成したアプリケーションの `my-component` という名前のカスタムコンポーネントのグループを解除するには、次のコマンドを使用します。
```
aws application-insights delete-component --resource-group-name my-resource-group --component-name my-new-component
```
**AWS Tools for Windows PowerShell を使用してカスタムコンポーネントのグループ化を解除するには**
AWS Tools for Windows PowerShell を使用して、リソースグループ `my-resource-group` で作成したアプリケーションの `my-component` という名前のカスタムコンポーネントのグループを解除するには、次のコマンドを使用します。
```
Remove-CWAIComponent -ComponentName my-component -ResourceGroupName my-resource-group
```
### アプリケーションを更新する
**AWS CLI を使用してアプリケーションを更新する**
AWS CLI を使用してアプリケーションを更新し、そのアプリケーションで検出された問題について AWS Systems Manager OpsCenter の OpsItems を生成し、作成された OpsItems を SNS トピック `arn:aws:sns:us-east-1:123456789012:MyTopic` に関連付けるには、次のコマンドを使用します。
```
aws application-insights update-application --resource-group-name my-resource-group --ops-center-enabled --ops-item-sns-topic-arn arn:aws:sns:us-east-1:123456789012:MyTopic
```
**AWS Tools for Windows PowerShell を使用してアプリケーションを更新する**
AWS Tools for Windows PowerShell を使用してアプリケーションを更新し、そのアプリケーションで検出された問題について AWS SSM OpsCenter の OpsItems を生成し、作成された OpsItems を SNS トピック `arn:aws:sns:us-east-1:123456789012:MyTopic` に関連付けるには、次のコマンドを使用します。
```
Update-CWAIApplication -ResourceGroupName my-resource-group -OpsCenterEnabled true -OpsItemSNSTopicArn arn:aws:sns:us-east-1:123456789012:MyTopic
```
### カスタムコンポーネントを更新する
**AWS CLI を使用してカスタムコンポーネントを更新する**
AWS CLI を使用して、`my-component` という名前のカスタムコンポーネントを、新しいコンポーネント名 `my-new-component` およびインスタンスの更新されたグループで更新するには、次のコマンドを使用します。
```
aws application-insights update-component --resource-group-name my-resource-group --component-name my-component --new-component-name my-new-component --resource-list arn:aws:ec2:us-east-1:123456789012:instance/i-44444 arn:aws:ec2:us-east-1:123456789012:instance/i-55555
```
**AWS Tools for Windows PowerShell を使用したカスタムコンポーネントを更新する**
AWS Tools for Windows PowerShell を使用して、`my-component` という名前のカスタムコンポーネントを、新しいコンポーネント名 `my-new-component` およびインスタンスの更新されたグループで更新するには、次のコマンドを使用します。
```
Update-CWAIComponent -ComponentName my-component -NewComponentName my-new-component -ResourceGroupName my-resource-group -ResourceList arn:aws:ec2:us-east-1:123456789012:instance/i-44444,arn:aws:ec2:us-east-1:123456789012:instance/i-55555
```
## モニターリングの管理と更新
コマンドラインを使用して Application Insights アプリケーションのモニターリングを管理および更新できます。
**Topics**
+ [
### アプリケーションの問題をリスト化する
](#appinsights-list-problems-monitoring)
+ [
### アプリケーションの問題を記述する
](#appinsights-describe-app-problem)
+ [
### 問題に関連する異常やエラーを記述する
](#appinsights-describe-anomalies)
+ [
### アプリケーションの異常やエラーを記述する
](#appinsights-describe-anomalies)
+ [
### コンポーネントのモニターリング設定を記述する
](#appinsights-describe-monitoring)
+ [
### コンポーネントの推奨されるモニターリング設定を記述する
](#appinsights-describe-rec-monitoring)
+ [
### コンポーネントのモニターリング設定を更新する
](#update-monitoring)
+ [
### 指定したリソースグループを Application Insights のモニターリングから削除する
](#update-monitoring)
### アプリケーションの問題をリスト化する
**AWS CLI を使用してアプリケーションに関する問題を一覧表示する**
AWS CLI を使用して、`my-resource-group` というリソースグループで作成されたアプリケーションの Unix エポックから 1,000～10,000 ミリ秒の間で検出されたアプリケーションの問題をリストするには、次のコマンドを使用します。
```
aws application-insights list-problems --resource-group-name my-resource-group --start-time 1000 --end-time 10000
```
**AWS Tools for Windows PowerShell を使用してアプリケーションに関する問題をリストする**
AWS Tools for Windows PowerShell を使用して、`my-resource-group` というリソースグループで作成されたアプリケーションの Unix エポックから 1,000～10,000 ミリ秒の間で検出されたアプリケーションの問題をリストするには、次のコマンドを使用します。
```
$startDate = "8/6/2019 3:33:00"
$endDate = "8/6/2019 3:34:00"
Get-CWAIProblemList -ResourceGroupName my-resource-group -StartTime $startDate -EndTime $endDate
```
### アプリケーションの問題を記述する
**AWS CLI を使用してアプリケーションの問題を説明する**
AWS CLI を使用して問題 ID `p-1234567890` の問題を記述するには、次のコマンドを使用します。
```
aws application-insights describe-problem —problem-id p-1234567890
```
**AWS Tools for Windows PowerShell を使用してアプリケーションの問題を説明する**
AWS Tools for Windows PowerShell を使用して問題 ID `p-1234567890` の問題を記述するには、次のコマンドを使用します。
```
Get-CWAIProblem -ProblemId p-1234567890
```
### 問題に関連する異常やエラーを記述する
**AWS CLI を使用して問題に関連する異常またはエラーを記述する**
AWS CLI を使用して、問題 ID `p-1234567890` を持つ問題に関連する異常またはエラーを記述するには、次のコマンドを使用します。
```
aws application-insights describe-problem-observations --problem-id -1234567890
```
**AWS Tools for Windows PowerShell を使用して、問題に関連する異常またはエラーを記述する**
AWS Tools for Windows PowerShell を使用して、問題 ID `p-1234567890` を持つ問題に関連する異常またはエラーを記述するには、次のコマンドを使用します。
```
Get-CWAIProblemObservation -ProblemId p-1234567890
```
### アプリケーションの異常やエラーを記述する
**AWS CLI を使用してアプリケーションの異常またはエラーを記述する**
AWS CLI を使用して、監視 ID `o-1234567890` を持つアプリケーションの異常またはエラーを記述するには、次のコマンドを使用します。
```
aws application-insights describe-observation —observation-id o-1234567890
```
**AWS Tools for Windows PowerShell を使用して、アプリケーションの異常またはエラーを記述する**
AWS Tools for Windows PowerShell を使用して、監視 ID `o-1234567890` を持つアプリケーションの異常またはエラーを記述するには、次のコマンドを使用します。
```
Get-CWAIObservation -ObservationId o-1234567890
```
### コンポーネントのモニターリング設定を記述する
**AWS CLI を使用してコンポーネントのモニターリング設定を記述する**
AWS CLI を使用して、リソースグループ `my-resource-group` で作成されたアプリケーションの `my-component` というコンポーネントのモニターリング設定を記述するには、次のコマンドを使用します。
```
aws application-insights describe-component-configuration —resource-group-name my-resource-group —component-name my-component
```
**AWS Tools for Windows PowerShell を使用して、コンポーネントのモニターリング設定を記述する**
AWS Tools for Windows PowerShell を使用して、リソースグループ `my-resource-group` で作成されたアプリケーションの `my-component` というコンポーネントのモニターリング設定を記述するには、次のコマンドを使用します。
```
Get-CWAIComponentConfiguration -ComponentName my-component -ResourceGroupName my-resource-group
```
コンポーネント設定の詳細と JSON ファイルの例についての詳細は、「[コンポーネント設定の作業](component-config.md)」を参照してください。
### コンポーネントの推奨されるモニターリング設定を記述する
**AWS CLI を使用して、コンポーネントの推奨モニターリング設定について記述する**
コンポーネントが .NET ワーカーアプリケーションの一部である場合、AWS CLI を使用して、リソースグループ `my-resource-group` で作成されたアプリケーションの `my-component` というコンポーネントの推奨モニターリング設定を記述するには、次のコマンドを使用します。
```
aws application-insights describe-component-configuration-recommendation --resource-group-name my-resource-group --component-name my-component --tier DOT_NET_WORKER
```
**AWS Tools for Windows PowerShell を使用してコンポーネントの推奨モニターリング設定について記述する**
コンポーネントが .NET ワーカーアプリケーションの一部である場合、AWS Tools for Windows PowerShell を使用して、リソースグループ `my-resource-group` で作成されたアプリケーションの `my-component` というコンポーネントの推奨モニターリング設定を記述するには、次のコマンドを使用します。
```
Get-CWAIComponentConfigurationRecommendation -ComponentName my-component -ResourceGroupName my-resource-group -Tier DOT_NET_WORKER
```
コンポーネント設定の詳細と JSON ファイルの例についての詳細は、「[コンポーネント設定の作業](component-config.md)」を参照してください。
### コンポーネントのモニターリング設定を更新する
**AWS CLI を使用してコンポーネントのモニターリング設定を更新する**
AWS CLI を使用して、`my-component` というリソースグループで作成されたアプリケーションの `my-resource-group` というコンポーネントを更新するには、次のコマンドを使用します。コマンドには、以下のアクションが含まれます。
1. コンポーネントのモニターリングを有効にします。
1. コンポーネントの階層を `.NET Worker` に設定します。
1. コンポーネントの JSON 設定を更新して、ローカルファイル `configuration.txt` から読み取ります。
```
aws application-insights update-component-configuration --resource-group-name my-resource-group --component-name my-component --tier DOT_NET_WORKER --monitor --component-configuration "file://configuration.txt"
```
**AWS Tools for Windows PowerShell を使用してコンポーネントのモニターリング設定を更新する**
AWS Tools for Windows PowerShell を使用して、`my-component` というリソースグループで作成されたアプリケーションの `my-resource-group` というコンポーネントを更新するには、次のコマンドを使用します。コマンドには、以下のアクションが含まれます。
1. コンポーネントのモニターリングを有効にします。
1. コンポーネントの階層を `.NET Worker` に設定します。
1. コンポーネントの JSON 設定を更新して、ローカルファイル `configuration.txt` から読み取ります。
```
[string]$config = Get-Content -Path configuration.txt
Update-CWAIComponentConfiguration -ComponentName my-component -ResourceGroupName my-resource-group -Tier DOT_NET_WORKER -Monitor 1 -ComponentConfiguration $config
```
コンポーネント設定の詳細と JSON ファイルの例についての詳細は、「[コンポーネント設定の作業](component-config.md)」を参照してください。
### 指定したリソースグループを Application Insights のモニターリングから削除する
**AWS CLI を使用して指定されたリソースグループを Application Insights のモニターリングから削除する**
AWS CLI を使用して、`my-resource-group` というリソースグループで作成されたアプリケーションをモニターリングから削除するには、次のコマンドを使用します。
```
aws application-insights delete-application --resource-group-name my-resource-group
```
**AWS Tools for Windows PowerShell を使用して指定されたリソースグループを Application Insights のモニターリングから削除する**
AWS Tools for Windows PowerShell を使用して、`my-resource-group` というリソースグループで作成されたアプリケーションをモニターリングから削除するには、次のコマンドを使用します。
```
Remove-CWAIApplication -ResourceGroupName my-resource-group
```
## SQL Always On 可用性グループのモニターリングを設定する
1. SQL HA EC2 インスタンスを使用して、リソースグループのアプリケーションを作成します。
```
aws application-insights create-application ‐-region ‐-resource-group-name
```
1. 新しいアプリケーションコンポーネントを作成して、SQL HA クラスターを表す EC2 インスタンスを定義します。
```
aws application-insights create-component ‐-resource-group-name "" ‐-component-name SQL_HA_CLUSTER ‐-resource-list "arn:aws:ec2:::instance/" "arn:aws:ec2:::instance/
```
1. SQL HA コンポーネントを設定します。
```
aws application-insights update-component-configuration ‐-resource-group-name "" ‐-region ‐-component-name "SQL_HA_CLUSTER" ‐-monitor ‐-tier SQL_SERVER_ALWAYSON_AVAILABILITY_GROUP ‐-monitor ‐-component-configuration '{
"subComponents" : [ {
"subComponentType" : "AWS::EC2::Instance",
"alarmMetrics" : [ {
"alarmMetricName" : "CPUUtilization",
"monitor" : true
}, {
"alarmMetricName" : "StatusCheckFailed",
"monitor" : true
}, {
"alarmMetricName" : "Processor % Processor Time",
"monitor" : true
}, {
"alarmMetricName" : "Memory % Committed Bytes In Use",
"monitor" : true
}, {
"alarmMetricName" : "Memory Available Mbytes",
"monitor" : true
}, {
"alarmMetricName" : "Paging File % Usage",
"monitor" : true
}, {
"alarmMetricName" : "System Processor Queue Length",
"monitor" : true
}, {
"alarmMetricName" : "Network Interface Bytes Total/sec",
"monitor" : true
}, {
"alarmMetricName" : "PhysicalDisk % Disk Time",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Buffer Manager Buffer cache hit ratio",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Buffer Manager Page life expectancy",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:General Statistics Processes blocked",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:General Statistics User Connections",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Locks Number of Deadlocks/sec",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:SQL Statistics Batch Requests/sec",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica File Bytes Received/sec",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica Log Bytes Received/sec",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica Log remaining for undo",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica Log Send Queue",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica Mirrored Write Transaction/sec",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica Recovery Queue",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica Redo Bytes Remaining",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica Redone Bytes/sec",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica Total Log requiring undo",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica Transaction Delay",
"monitor" : true
} ],
"windowsEvents" : [ {
"logGroupName" : "WINDOWS_EVENTS-Application-",
"eventName" : "Application",
"eventLevels" : [ "WARNING", "ERROR", "CRITICAL", "INFORMATION" ],
"monitor" : true
}, {
"logGroupName" : "WINDOWS_EVENTS-System-",
"eventName" : "System",
"eventLevels" : [ "WARNING", "ERROR", "CRITICAL" ],
"monitor" : true
}, {
"logGroupName" : "WINDOWS_EVENTS-Security-",
"eventName" : "Security",
"eventLevels" : [ "WARNING", "ERROR", "CRITICAL" ],
"monitor" : true
} ],
"logs" : [ {
"logGroupName" : "SQL_SERVER_ALWAYSON_AVAILABILITY_GROUP-",
"logPath" : "C:\\Program Files\\Microsoft SQL Server\\MSSQL**.MSSQLSERVER\\MSSQL\\Log\\ERRORLOG",
"logType" : "SQL_SERVER",
"monitor" : true,
"encoding" : "utf-8"
} ]
}, {
"subComponentType" : "AWS::EC2::Volume",
"alarmMetrics" : [ {
"alarmMetricName" : "VolumeReadBytes",
"monitor" : true
}, {
"alarmMetricName" : "VolumeWriteBytes",
"monitor" : true
}, {
"alarmMetricName" : "VolumeReadOps",
"monitor" : true
}, {
"alarmMetricName" : "VolumeWriteOps",
"monitor" : true
}, {
"alarmMetricName" : "VolumeQueueLength",
"monitor" : true
}, {
"alarmMetricName" : "VolumeThroughputPercentage",
"monitor" : true
}, {
"alarmMetricName" : "BurstBalance",
"monitor" : true
} ]
} ]
}'
```
**注記**
Application Insights は、フェイルオーバーなどのクラスターアクティビティを検出するために、アプリケーションイベントログ (情報レベル) を取り込む必要があります。
## MySQL RDS のモニターリングを設定する
1. RDS MySQL データベースインスタンスを使用して、リソースグループのアプリケーションを作成します。
```
aws application-insights create-application ‐-region ‐-resource-group-name
```
1. エラーログはデフォルトで有効になります。スロークエリログは、データパラメータグループを使用して有効にできます。詳細については、「[MySQL スロークエリと一般ログにアクセスする](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.MySQL.html#USER_LogAccess.MySQL.Generallog)」を参照してください。
+ `set slow_query_log = 1`
+ `set log_output = FILE`
1. モニターリングするログを CloudWatch Logs にエクスポートします。詳細については、「[CloudWatch Logs への MySQL ログの発行](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.MySQL.html#USER_LogAccess.MySQLDB.PublishtoCloudWatchLogs)」を参照してください。
1. MySQL RDS コンポーネントを設定します。
```
aws application-insights update-component-configuration ‐-resource-group-name "" ‐-region ‐-component-name "" ‐-monitor ‐-tier DEFAULT ‐-monitor ‐-component-configuration "{\"alarmMetrics\":[{\"alarmMetricName\":\"CPUUtilization\",\"monitor\":true}],\"logs\":[{\"logType\":\"MYSQL\",\"monitor\":true},{\"logType\": \"MYSQL_SLOW_QUERY\",\"monitor\":false}]}"
```
## MySQL EC2 のモニターリングを設定する
1. SQL HA EC2 インスタンスを使用して、リソースグループのアプリケーションを作成します。
```
aws application-insights create-application ‐-region ‐-resource-group-name
```
1. エラーログはデフォルトで有効になります。スロークエリログは、データパラメータグループを使用して有効にできます。詳細については、「[MySQL スロークエリと一般ログにアクセスする](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.MySQL.html#USER_LogAccess.MySQL.Generallog)」を参照してください。
+ `set slow_query_log = 1`
+ `set log_output = FILE`
1. MySQL EC2 コンポーネントを設定します。
```
aws application-insights update-component-configuration ‐-resource-group-name "" ‐-region ‐-component-name "" ‐-monitor ‐-tier MYSQL ‐-monitor ‐-component-configuration "{\"alarmMetrics\":[{\"alarmMetricName\":\"CPUUtilization\",\"monitor\":true}],\"logs\":[{\"logGroupName\":\"\",\"logPath\":\"C:\\\\ProgramData\\\\MySQL\\\\MySQL Server **\\\\Data\\\\.err\",\"logType\":\"MYSQL\",\"monitor\":true,\"encoding\":\"utf-8\"}]}"
```
## PostgreSQL RDS のモニターリングを設定する
1. PostgreSQL RDS データベースインスタンスを使用して、リソースグループのアプリケーションを作成します。
```
aws application-insights create-application ‐-region ‐-resource-group-name
```
1. CloudWatch への PostgreSQL ログの公開は、デフォルトでは有効になっていません。モニターリングを有効にするには、RDS コンソールを開き、モニターリングするデータベースを選択します。右上隅にある **[Modify]** (変更) を選択し、**[PostgreSQL]** ログというラベルの付いたチェックボックスをオンにします。[**Continue (続行)**] を選択してこの設定を保存します。
1. PostgreSQL のログが CloudWatch にエクスポートされます。
1. PostgreSQL RDS コンポーネントを設定します。
```
aws application-insights update-component-configuration --region --resource-group-name --component-name --monitor --tier DEFAULT --component-configuration
"{
\"alarmMetrics\":[
{
\"alarmMetricName\": \"CPUUtilization\",
\"monitor\": true
}
],
\"logs\":[
{
\"logType\": \"POSTGRESQL\",
\"monitor\": true
}
]
}"
```
## PostgreSQL EC2 のモニターリングを設定する
1. PostgreSQL EC2 インスタンスを使用して、リソースグループのアプリケーションを作成します。
```
aws application-insights create-application ‐-region ‐-resource-group-name
```
1. PostgreSQL EC2 コンポーネントを設定します。
```
aws application-insights update-component-configuration ‐-region ‐-resource-group-name ‐-component-name ‐-monitor ‐-tier POSTGRESQL ‐-component-configuration
"{
\"alarmMetrics\":[
{
\"alarmMetricName\":\"CPUUtilization\",
\"monitor\":true
}
],
\"logs\":[
{
\"logGroupName\":\"\",
\"logPath\":\"/var/lib/pgsql/data/log/\",
\"logType\":\"POSTGRESQL\",
\"monitor\":true,
\"encoding\":\"utf-8\"
}
]
}"
```
## Oracle RDS のモニターリングを設定する
1. Oracle RDS データベースインスタンスを使用して、リソースグループのアプリケーションを作成します。
```
aws application-insights create-application ‐-region ‐-resource-group-name
```
1. CloudWatch への Oracle ログの発行は、デフォルトでは有効になっていません。モニターリングを有効にするには、RDS コンソールを開き、モニターリングするデータベースを選択します。右上隅にある **[Modify]** (変更) を選択し、**[Alert]** (アラート) ログと **[Listener]** (リスナー) ログというラベルの付いたチェックボックスをオンにします。[**Continue (続行)**] を選択してこの設定を保存します。
1. Oracle ログは CloudWatch にエクスポートされます。
1. Oracle RDS コンポーネントを設定します。
```
aws application-insights update-component-configuration --region --resource-group-name --component-name --monitor --tier DEFAULT --component-configuration
"{
\"alarmMetrics\":[
{
\"alarmMetricName\": \"CPUUtilization\",
\"monitor\": true
}
],
\"logs\":[
{
\"logType\": \"ORACLE_ALERT\",
\"monitor\": true
},
{
\"logType\": \"ORACLE_LISTENER\",
\"monitor\": true
}
]
}"
```
## Oracle EC2 のモニターリングを設定する
1. Oracle EC2 インスタンスを使用して、リソースグループのアプリケーションを作成します。
```
aws application-insights create-application ‐-region ‐-resource-group-name
```
1. Oracle EC2 コンポーネントを設定します。
```
aws application-insights update-component-configuration ‐-region ‐-resource-group-name ‐-component-name ‐-monitor ‐-tier ORACLE ‐-component-configuration
"{
\"alarmMetrics\":[
{
\"alarmMetricName\":\"CPUUtilization\",
\"monitor\":true
}
],
\"logs\":[
{
\"logGroupName\":\"\",
\"logPath\":\"/opt/oracle/diag/rdbms/*/*/trace\",
\"logType\":\"ORACLE_ALERT\",
\"monitor\":true,
},
{
\"logGroupName\":\"\",
\"logPath\":\"/opt/oracle/diag/tnslsnr/$HOSTNAME/listener/trace/\",
\"logType\":\"ORACLE_ALERT\",
\"monitor\":true,
}
]
}"
```
# 検出された問題の Application Insights CloudWatch Events
CloudWatch Application Insights に追加したアプリケーションごとに、CloudWatch イベントがベストエフォートベースで以下のイベントに対して発行されます。
+ **問題の作成。**CloudWatch Application Insights が新しい問題を検出したときに発行されます。
+ 詳細タイプ: ** 「Application Insights 問題が検出されました」**
+ 詳細:
+ `problemId`: 検出された問題 ID。
+ `region`: 問題が作成された AWS リージョン。
+ `resourceGroupName`: 問題が検出された登録済みアプリケーションのリソースグループ。
+ `status`: 問題のステータス。指定できるステータスと定義は次のとおりです。
+ `In progress`: 新しい問題が確認されました。問題に関する監視結果を受信中です。
+ `Recovering`: この問題は安定化されています。この状態になると、手動で問題を解決できます。
+ `Resolved`: この問題は解決されました。この問題に関する新たな監視結果はありません。
+ `Recurring`: この問題は過去 24 時間以内に解決されました。追加監視の結果、再開しました。
+ `severity`: 問題の重大度。
+ `problemUrl`: 問題のコンソール URL。
+ **問題の更新。**問題が新しい監視結果で更新されたとき、または既存の監視結果が更新されて問題が後で更新されたときに発行されます。更新には、問題の解決や終了が含まれます。
+ 詳細タイプ: ** 「Application Insights の問題が更新されました」**
+ 詳細:
+ `problemId`: 作成された問題 ID
+ `region`: 問題が作成された AWS リージョン。
+ `resourceGroupName`: 問題が検出された登録済みアプリケーションのリソースグループ。
+ `status`: 問題のステータス。
+ `severity`: 問題の重大度。
+ `problemUrl`: 問題のコンソール URL。
# 検出された問題の通知を受け取る
Amazon SNS 通知、Systems Manager OpsCenter 、または CloudWatch Events を使用して、アプリケーションで検出された問題に関する通知を受信できます。
**検出された問題の CloudWatch Application Insights Amazon SNS 通知**
AWS マネジメントコンソールまたは AWS CLI を使用して Amazon SNS 通知を設定できます。AWS マネジメントコンソールを使用して通知を設定するには、次の例に示すように、必須の Amazon SNS アクセス許可が必要です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sns:ListTopics",
"sns:Subscribe",
"sns:CreateTopic"
],
"Resource": [
"*"
]
}
]
}
```
------
Amazon SNS 通知を設定すると、問題が作成または解決されたときに E メール通知が送信されます。また、新しい観測値が既存の問題に追加されると通知を受け取ります。
次の例は、E メール通知の内容を示しています。
```
You are receiving this email because Problem "p-1234567" has been CREATED by Amazon CloudWatch Application Insights
Problem Details:
Problem URL: https:////console.aws.amazon.com/cloudwatch/home?region=us-east-1#settings:AppInsightsSettings/problemDetails?problemId=p-1234567
Problem Summary: Title of the problem
Severity: HIGH
Insights: Something specific is broken
Status : RESOLVED
AffectedResource: arn:aws:ec2:us-east-1:555555555555:host/testResource
Region: us-east-1
RecurringCount: 0
StartTime: 2019-03-23T10:42:57.777Z
LastUpdatedTime: 2019-03-23T21:49:37.777Z
LastRecurrenceTime:
StopTime: 2019-03-23T21:49:37.777Z
Recent Issues
- TelemetryArn:alarm1
StartTime: 2024-08-15T22:12:46.007Z
StopTime:
- TelemetryArn:log-group1
StartTime: 2024-08-15T22:12:46.007Z
StopTime: 2024-08-15T22:12:46.007Z
```
**Systems Manager を使用して問題の通知を受信する方法**
**AWS Systems Manager を通じたアクション。**CloudWatch Application Insights には、Systems Manager OpsCenter との統合が組み込まれています。アプリケーションにこの統合を使用する場合、アプリケーションで検出された問題ごとに OpsCenter コンソールに OpsItem が作成されます。OpsCenter コンソールから、CloudWatch Application Insights で検出された問題に関する要約情報を表示し、Systems Manager Automation ランブックを選択して修復アクションを実行したり、アプリケーションでリソースの問題を引き起こしている Windows プロセスをさらに特定したりできます。
**CloudWatch Events を使用して問題の通知を受信する方法**
CloudWatch コンソールの左側のナビゲーションペインで、[**イベント**] の下の [**ルール**] を選択します。[**ルール**] ページで、[**ルールの作成**] を選択します。[**サービス名**] ドロップダウンリストから [**Amazon CloudWatch Application Insights**] を選択し、[**イベントタイプ**] を選択します。次に、[**ターゲットの追加**] を選択し、ターゲットとパラメータ (**SNS トピック**や **Lambda 関数**など) を選択します。
# アプリケーションインサイトのクロスアカウントオブザーバビリティ
CloudWatch Application Insights のクロスアカウントオブザーバビリティを使用すると、単一リージョン内の複数の AWS アカウントにまたがるアプリケーションをモニタリングし、トラブルシューティングすることができます。
Amazon CloudWatch オブザーバビリティアクセスマネージャーを使用して、1 つ以上の AWS アカウントをモニタリングアカウントとして設定できます。モニタリングアカウントにシンクを作成することで、モニタリングアカウントにソースアカウントのデータを表示する機能を持たせます。シンクを使用して、ソースアカウントからモニタリングアカウントへのリンクを作成します。詳細については、「[CloudWatch のクロスアカウントオブザーバビリティ](CloudWatch-Unified-Cross-Account.md)」を参照してください。
**必要なリソース**
CloudWatch Application Insights のクロスアカウントオブザーバビリティが適切に機能するためには、以下のテレメトリータイプが CloudWatch Observability Access Manager を通じて共有されていることを確認してください。
+ CloudWatch Application Insights のアプリケーション
+ Amazon CloudWatch のメトリクス
+ Amazon CloudWatch Logs のロググループ
+ [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) のトレース
# コンポーネント設定の作業
コンポーネント設定は、コンポーネントの設定を記述する JSON 形式のテキストファイルです。このセクションでは、テンプレートフラグメントの例、コンポーネント設定セクションの説明、コンポーネント設定例を示します。
**Topics**
+ [テンプレートフラグメント](component-config-json.md)
+ [セクション](component-config-sections.md)
+ [関連サービスの設定例](component-configuration-examples.md)
# コンポーネント設定テンプレートのフラグメント
次の例では、JSON 形式のテンプレートのフラグメントを示しています。
```
{
"alarmMetrics" : [
list of alarm metrics
],
"logs" : [
list of logs
],
"processes" : [
list of processes
],
"windowsEvents" : [
list of windows events channels configurations
],
"alarms" : [
list of CloudWatch alarms
],
"jmxPrometheusExporter": {
JMX Prometheus Exporter configuration
},
"hanaPrometheusExporter": {
SAP HANA Prometheus Exporter configuration
},
"haClusterPrometheusExporter": {
HA Cluster Prometheus Exporter configuration
},
"netWeaverPrometheusExporter": {
SAP NetWeaver Prometheus Exporter configuration
},
"subComponents" : [
{
"subComponentType" : "AWS::EC2::Instance" ...
component nested instances configuration
},
{
"subComponentType" : "AWS::EC2::Volume" ...
component nested volumes configuration
}
]
}
```
# コンポーネント設定セクション
コンポーネントの設定には、いくつかの主要なセクションがあります。コンポーネント設定のセクションは、任意の順序でリストできます。
+ **alarmMetrics (オプション)**
コンポーネントでモニターリングする[メトリクス](#component-config-metric)のリスト。すべてのコンポーネントタイプに alarmMetrics セクションを設定できます。
+ **logs (オプション)**
コンポーネントでモニターリングする[ログ](#component-configuration-log)のリスト。logs セクションは EC2 インスタンスのみに設定できます。
+ **プロセス (オプション)**
コンポーネントでモニターリングする[プロセス](#component-configuration-process)のリスト。プロセスセクションは EC2 インスタンスのみに設定できます。
+ **subComponents (オプション)**
コンポーネントのネストされたインスタンスおよびボリューム subComponent 設定。次のタイプのコンポーネントには、ネストされたインスタンスと subComponents セクションを含めることができます。ELB、ASG、カスタムグループ化された EC2 インスタンス、および EC2 インスタンス。
+ **アラーム（オプション）**
コンポーネントでモニターリングする[アラーム](#component-configuration-alarms)のリスト。すべてのコンポーネントタイプにアラームセクションを設定できます。
+ **windowsEvents (オプション)**
コンポーネントでモニターリングする [Windows イベント](#windows-events)のリスト。EC2 インスタンスの Windows にのみ `windowsEvents` セクションがあります。
+ **JMXPrometheusExporter (オプション)**
JMXPrometheus Exporter の設定。
+ **hanaPrometheusExporter (オプション)**
SAP HANA Prometheus Exporter の設定。
+ **haClusterPrometheusExporter (オプション)**
HA Cluster Prometheus Exporter の設定。
+ **netWeaverPrometheusExporter (オプション)**
SAP NetWeaver Prometheus Exporter の設定。
+ **sapAsePrometheusExporter (オプション)**
SAP ASE Prometheus Exporter の設定。
次の例は、JSON 形式の **subComponents セクションフラグメント**の構文を示しています。
```
[
{
"subComponentType" : "AWS::EC2::Instance",
"alarmMetrics" : [
list of alarm metrics
],
"logs" : [
list of logs
],
"processes": [
list of processes
],
"windowsEvents" : [
list of windows events channels configurations
]
},
{
"subComponentType" : "AWS::EC2::Volume",
"alarmMetrics" : [
list of alarm metrics
]
}
]
```
## コンポーネント設定セクションのプロパティ
このセクションでは、各コンポーネント設定セクションのプロパティについて説明します。
**Topics**
+ [
### メトリクス
](#component-config-metric)
+ [
### Log
](#component-configuration-log)
+ [
### プロセス
](#component-configuration-process)
+ [
### JMX Prometheus Exporter
](#component-configuration-prometheus)
+ [
### HANA Prometheus Exporter
](#component-configuration-hana-prometheus)
+ [
### HA Cluster Prometheus Exporter
](#component-configuration-ha-cluster-prometheus)
+ [
### NetWeaver Prometheus Exporter
](#component-configuration-netweaver-prometheus)
+ [
### SAP ASE Prometheus Exporter
](#component-configuration-sap-ase-prometheus)
+ [
### Windows イベント
](#windows-events)
+ [
### アラーム
](#component-configuration-alarms)
### メトリクス
コンポーネントでモニターリングするメトリクスを定義します。
**JSON**
```
{
"alarmMetricName" : "monitoredMetricName",
"monitor" : true/false
}
```
**プロパティ**
+ **alarmMetricName (必須)**
コンポーネントでモニターリングされるメトリクスの名前。Application Insights でサポートされるメトリクスについては、「[Amazon CloudWatch Application Insights でサポートされるログとメトリクス](appinsights-logs-and-metrics.md)」を参照してください。
+ **monitor (オプション)**
メトリクスをモニターリングするかどうかを示すブール値。デフォルト値は `true` です。
### Log
コンポーネントでモニターリングするログを定義します。
**JSON**
```
{
"logGroupName" : "logGroupName",
"logPath" : "logPath",
"logType" : "logType",
"encoding" : "encodingType",
"monitor" : true/false
}
```
**プロパティ**
+ **logGroupName (必須)**
モニターリングされたログに関連付けられる CloudWatch Logs グループ名。ロググループ名の制約については、「[CreateLogGroup](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html)」を参照してください。
+ **logPath (EC2 インスタンスのコンポーネントでは必須、AWS Lambda などの CloudWatch エージェントを使用しないコンポーネントでは不要)**
モニターリングするログのパス。ログパスは、Windows システムファイルの絶対パスである必要があります。詳細については、「[CloudWatch エージェント設定ファイル: ログセクション](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html#CloudWatch-Agent-Configuration-File-Logssection)」を参照してください。
+ **logType (必須)**
ログタイプは、Application Insights がログを分析するログパターンを決定します。ログの種類は以下から選択します。
+ `SQL_SERVER`
+ `MYSQL`
+ `MYSQL_SLOW_QUERY`
+ `POSTGRESQL`
+ `ORACLE_ALERT`
+ `ORACLE_LISTENER`
+ `IIS`
+ `APPLICATION`
+ `WINDOWS_EVENTS`
+ `WINDOWS_EVENTS_ACTIVE_DIRECTORY`
+ `WINDOWS_EVENTS_DNS`
+ `WINDOWS_EVENTS_IIS`
+ `WINDOWS_EVENTS_SHAREPOINT`
+ `SQL_SERVER_ALWAYSON_AVAILABILITY_GROUP`
+ `SQL_SERVER_FAILOVER_CLUSTER_INSTANCE`
+ `DEFAULT`
+ `CUSTOM`
+ `STEP_FUNCTION`
+ `API_GATEWAY_ACCESS`
+ `API_GATEWAY_EXECUTION`
+ `SAP_HANA_LOGS`
+ `SAP_HANA_TRACE`
+ `SAP_HANA_HIGH_AVAILABILITY`
+ `SAP_NETWEAVER_DEV_TRACE_LOGS`
+ `PACEMAKER_HIGH_AVAILABILITY`
+ **encoding (オプション)**
モニターリングするログのエンコードのタイプ。指定するエンコードは、[CloudWatch エージェントでサポートされているエンコード](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AgentReference.html)のリストに含まれている必要があります。指定しない場合、CloudWatch Application Insights は、以下を除き、デフォルトのエンコーディング タイプ utf-8 を使用します。
+ `SQL_SERVER`: UTF-16 エンコード
+ `IIS`: ASCII エンコード
+ **monitor (オプション)**
ログをモニターリングするかどうかを示すブール値。デフォルト値は `true` です。
### プロセス
コンポーネントでモニターリングするプロセスを定義します。
**JSON**
```
{
"processName" : "monitoredProcessName",
"alarmMetrics" : [
list of alarm metrics
]
}
```
**プロパティ**
+ **processName (必須)**
コンポーネントでモニターリングされるプロセスの名前。プロセスの名前には、`sqlservr` または `sqlservr.exe` のようなプロセスステムを含めることはできません。
+ **alarmMetric (必須)**
このプロセスをモニターする[メトリクス](#component-config-metric)のリスト。CloudWatch Application Insights でサポートされるプロセスメトリクスを表示するには、「[Amazon Elastic Compute Cloud (EC2)](appinsights-metrics-ec2.md)」を参照してください。
### JMX Prometheus Exporter
JMX Prometheus Exporter の設定を定義します。
**JSON**
```
"JMXPrometheusExporter": {
"jmxURL" : "JMX URL",
"hostPort" : "The host and port",
"prometheusPort" : "Target port to emit Prometheus metrics"
}
```
**プロパティ**
+ **jmxURL (オプション)**
接続する完全な JMX URL。
+ **hostPort (オプション)**
リモート JMX 経由で接続するホストとポート。`jmxURL` と `hostPort` のいずれかのみを指定できます。
+ **prometheusPort (オプション)**
Prometheus メトリクスを送信するターゲットポート。指定しない場合は、デフォルトのポート 9404 が使用されます。
### HANA Prometheus Exporter
HANA Prometheus Exporter の設定を定義します。
**JSON**
```
"hanaPrometheusExporter": {
"hanaSid": "SAP HANA SID",
"hanaPort": "HANA database port",
"hanaSecretName": "HANA secret name",
"prometheusPort": "Target port to emit Prometheus metrics"
}
```
**プロパティ**
+ **hanaSid**
SAP HANA システムの 3 文字の SAP システム ID (SID)。
+ **hanaPort**
エクスポーターが HANA メトリクスをクエリするために使用する HANA データベースのポート。
+ **hanaSecretName**
HANA のモニターリングにおけるユーザー認証情報を格納する AWS Secrets Manager シークレット。HANA Prometheus Exporter では、これらの認証情報を使用してデータベースに接続し、HANA メトリクスをクエリします。
+ **prometheusPort (オプション)**
Prometheus によるメトリクスの送信先となるターゲットポート。指定しない場合は、デフォルトのポート 9668 が使用されます。
### HA Cluster Prometheus Exporter
HA Cluster Prometheus Exporter の設定を定義します。
**JSON**
```
"haClusterPrometheusExporter": {
"prometheusPort": "Target port to emit Prometheus metrics"
}
```
**プロパティ**
+ **prometheusPort (オプション)**
Prometheus によるメトリクスの送信先となるターゲットポート。指定しない場合は、デフォルトのポート 9664 が使用されます。
### NetWeaver Prometheus Exporter
NetWeaver Prometheus Exporter の設定を定義します。
**JSON**
```
"netWeaverPrometheusExporter": {
"sapSid": "SAP NetWeaver SID",
"instanceNumbers": [ "Array of instance Numbers of SAP NetWeaver system "],
"prometheusPort": "Target port to emit Prometheus metrics"
}
```
**プロパティ**
+ **sapSid**
SAP Netweaver システムの 3 文字の SAP システム ID (SID)。
+ **instanceNumbers**
SAP NetWeaver システムのインスタンス番号の配列。
**例: **`"instanceNumbers": [ "00", "01"]`
+ **prometheusPort (オプション)**
Prometheus メトリクスの送信先となるターゲットポート。指定しない場合、デフォルトのポート `9680` が使用されます。
### SAP ASE Prometheus Exporter
SAP ASE Prometheus Exporter の設定を定義します。
**JSON**
```
"sapASEPrometheusExporter": {
"sapAseSid": "SAP ASE SID",
"sapAsePort": "SAP ASE database port",
"sapAseSecretName": "SAP ASE secret name",
"prometheusPort": "Target port to emit Prometheus metrics",
"agreeToEnableASEMonitoring": true
}
```
**プロパティ**
+ **sapAseSid**
SAP ASE システムの 3 文字の SAP システム ID (SID)。
+ **sapAsePort**
エクスポーターが ASE メトリクスをクエリするために使用する SAP ASE データベースのポート。
+ **sapAseSecretName**
ASE のモニタリングにおけるユーザー認証情報を格納する AWS Secrets Manager シークレット。SAP ASE Prometheus Exporter では、これらの認証情報を使用してデータベースに接続し、ASE メトリクスをクエリします。
+ **prometheusPort (オプション)**
Prometheus によるメトリクスの送信先となるターゲットポート。指定しない場合は、デフォルトのポート 9399 が使用されます。デフォルトのポートを使用している別の ASE DB がある場合は、9499 を使用します。
### Windows イベント
ログに記録する Windows イベントを定義します。
**JSON**
```
{
"logGroupName" : "logGroupName",
"eventName" : "eventName",
"eventLevels" : ["ERROR","WARNING","CRITICAL","INFORMATION","VERBOSE"],
"monitor" : true/false
}
```
**プロパティ**
+ **logGroupName (必須)**
モニターリングされたログに関連付けられる CloudWatch Logs グループ名。ロググループ名の制約については、「[CreateLogGroup](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html)」を参照してください。
+ **eventName (必須)**
ログ記録する Windows イベントのタイプ。これは Windows イベントログのチャネル名と同等です。たとえば、System、Security、CustomEventName などです。このフィールドは、ログ記録する Windows イベントのタイプごとに必要です。
+ **eventLevels (必須)**
ログ記録するイベントのレベル。ログ記録する各レベルを指定する必要があります。指定できる値には、`INFORMATION`、`WARNING`、`ERROR`、`CRITICAL`および `VERBOSE` などがあります。このフィールドは、ログ記録する Windows イベントのタイプごとに必要です。
+ **monitor (オプション)**
ログをモニターリングするかどうかを示すブール値。デフォルト値は `true` です。
### アラーム
コンポーネントでモニターリングする CloudWatch アラームを定義します。
**JSON**
```
{
"alarmName" : "monitoredAlarmName",
"severity" : HIGH/MEDIUM/LOW
}
```
**プロパティ**
+ **alarmName（必須）**
コンポーネントでモニターリングする CloudWatch アラームの名前。
+ **重大度（オプション）**
アラームが鳴ったときの停止の程度を示します。
# コンポーネント設定の例
以下の例は、関連するサービスの JSON 形式のコンポーネント設定を示しています。
**Topics**
+ [
# Amazon DynamoDB テーブル
](component-configuration-examples-dynamo.md)
+ [
# Amazon EC2 Auto Scaling (ASG)
](component-configuration-examples-asg.md)
+ [
# Amazon EKS クラスター
](component-configuration-examples-eks-cluster.md)
+ [
# Amazon Elastic Compute Cloud (EC2) インスタンス
](component-configuration-examples-ec2.md)
+ [
# Amazon Elastic Container Service (Amazon ECS)
](component-configuration-examples-ecs.md)
+ [
# Amazon ECS サービス
](component-configuration-examples-ecs-service.md)
+ [
# Amazon ECS タスク
](component-configuration-examples-ecs-task.md)
+ [
# Amazon Elastic File System (Amazon EFS)
](component-configuration-examples-efs.md)
+ [
# Amazon FSx
](component-configuration-examples-fsx.md)
+ [
# Amazon Relational Database Service (RDS) Aurora MySQL
](component-configuration-examples-rds-aurora.md)
+ [
# Amazon Relational Database Service (RDS) インスタンス
](component-configuration-examples-rds.md)
+ [
# Amazon Route 53 ヘルスチェック
](component-configuration-examples-health-check.md)
+ [
# Amazon Route 53 ホストゾーン
](component-configuration-examples-hosted-zone.md)
+ [
# Amazon Route 53 Resolver エンドポイント
](component-configuration-examples-resolver-endpoint.md)
+ [
# Amazon Route 53 Resolver クエリログ記録の設定
](component-configuration-examples-resolver-query-logging.md)
+ [
# Amazon S3 バケット
](component-configuration-examples-s3.md)
+ [
# Amazon Simple Queue Service (SQS)
](component-configuration-examples-sqs.md)
+ [
# Amazon SNS トピック
](component-configuration-examples-sns.md)
+ [
# Amazon Virtual Private Cloud (Amazon VPC)
](component-configuration-examples-vpc.md)
+ [
# Amazon VPC ネットワークアドレス変換 (NAT) ゲートウェイ
](component-configuration-examples-nat-gateway.md)
+ [
# API Gateway REST API ステージ
](component-configuration-examples-api-gateway.md)
+ [
# Application Elastic Load Balancing
](component-configuration-examples-application-elb.md)
+ [
# AWS Lambda 関数
](component-configuration-examples-lambda.md)
+ [
# AWS Network Firewall ルールグループ
](component-configuration-examples-firewall-rule-group.md)
+ [
# AWS Network Firewall ルールグループ関連付け
](component-configuration-examples-firewall-rule-group-assoc.md)
+ [
# AWS Step Functions
](component-configuration-examples-step-functions.md)
+ [
# カスタマーグループ化された Amazon EC2 インスタンス
](component-configuration-examples-grouped-ec2.md)
+ [
# Elastic Load Balancing
](component-configuration-examples-elb.md)
+ [
# Java
](component-configuration-examples-java.md)
+ [
# Amazon EC2 での Kubernetes
](component-configuration-examples-kubernetes-ec2.md)
+ [
# RDS MariaDB と RDS MySQL
](component-configuration-examples-mysql.md)
+ [
# RDS Oracle
](component-configuration-examples-oracle.md)
+ [
# RDS PostgreSQL
](component-configuration-examples-rds-postgre-sql.md)
+ [
# Amazon EC2 での SAP ASE
](component-configuration-examples-sap-ase.md)
+ [
# Amazon EC2 での SAP ASE High Availability
](component-configuration-examples-sap-ase-ha.md)
+ [
# Amazon EC2 での SAP HANA
](component-configuration-examples-hana.md)
+ [
# Amazon EC2 での SAP HANA High Availability
](component-configuration-examples-hana-ha.md)
+ [
# Amazon EC2 での SAP NetWeaver
](component-configuration-examples-netweaver.md)
+ [
# Amazon EC2 での SAP Netweaver High Availability
](component-configuration-examples-netweaver-ha.md)
+ [
# SQL Always On 可用性グループ
](component-configuration-examples-sql.md)
+ [
# SQL フェイルオーバークラスターインスタンス
](component-configuration-examples-sql-failover-cluster.md)
# Amazon DynamoDB テーブル
次の例は、Amazon DynamoDB テーブル用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "SystemErrors",
"monitor": false
},
{
"alarmMetricName": "UserErrors",
"monitor": false
},
{
"alarmMetricName": "ConsumedReadCapacityUnits",
"monitor": false
},
{
"alarmMetricName": "ConsumedWriteCapacityUnits",
"monitor": false
},
{
"alarmMetricName": "ReadThrottleEvents",
"monitor": false
},
{
"alarmMetricName": "WriteThrottleEvents",
"monitor": false
},
{
"alarmMetricName": "ConditionalCheckFailedRequests",
"monitor": false
},
{
"alarmMetricName": "TransactionConflict",
"monitor": false
}
],
"logs": []
}
```
# Amazon EC2 Auto Scaling (ASG)
次の例は、Amazon EC2 Auto Scaling (ASG) 用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics" : [
{
"alarmMetricName" : "CPUCreditBalance"
}, {
"alarmMetricName" : "EBSIOBalance%"
}
],
"subComponents" : [
{
"subComponentType" : "AWS::EC2::Instance",
"alarmMetrics" : [
{
"alarmMetricName" : "CPUUtilization"
}, {
"alarmMetricName" : "StatusCheckFailed"
}
],
"logs" : [
{
"logGroupName" : "my_log_group",
"logPath" : "C:\\LogFolder\\*",
"logType" : "APPLICATION"
}
],
"processes" : [
{
"processName" : "my_process",
"alarmMetrics" : [
{
"alarmMetricName" : "procstat cpu_usage",
"monitor" : true
}, {
"alarmMetricName" : "procstat memory_rss",
"monitor" : true
}
]
}
],
"windowsEvents" : [
{
"logGroupName" : "my_log_group_2",
"eventName" : "Application",
"eventLevels" : [ "ERROR", "WARNING", "CRITICAL" ]
}
]
}, {
"subComponentType" : "AWS::EC2::Volume",
"alarmMetrics" : [
{
"alarmMetricName" : "VolumeQueueLength"
}, {
"alarmMetricName" : "BurstBalance"
}
]
}
],
"alarms" : [
{
"alarmName" : "my_asg_alarm",
"severity" : "LOW"
}
]
}
```
# Amazon EKS クラスター
次の例は、Amazon EKS クラスター用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics":[
{
"alarmMetricName": "cluster_failed_node_count",
"monitor":true
},
{
"alarmMetricName": "node_cpu_reserved_capacity",
"monitor":true
},
{
"alarmMetricName": "node_cpu_utilization",
"monitor":true
},
{
"alarmMetricName": "node_filesystem_utilization",
"monitor":true
},
{
"alarmMetricName": "node_memory_reserved_capacity",
"monitor":true
},
{
"alarmMetricName": "node_memory_utilization",
"monitor":true
},
{
"alarmMetricName": "node_network_total_bytes",
"monitor":true
},
{
"alarmMetricName": "pod_cpu_reserved_capacity",
"monitor":true
},
{
"alarmMetricName": "pod_cpu_utilization",
"monitor":true
},
{
"alarmMetricName": "pod_cpu_utilization_over_pod_limit",
"monitor":true
},
{
"alarmMetricName": "pod_memory_reserved_capacity",
"monitor":true
},
{
"alarmMetricName": "pod_memory_utilization",
"monitor":true
},
{
"alarmMetricName": "pod_memory_utilization_over_pod_limit",
"monitor":true
},
{
"alarmMetricName": "pod_network_rx_bytes",
"monitor":true
},
{
"alarmMetricName": "pod_network_tx_bytes",
"monitor":true
}
],
"logs":[
{
"logGroupName": "/aws/containerinsights/kubernetes/application",
"logType":"APPLICATION",
"monitor":true,
"encoding":"utf-8"
}
],
"subComponents":[
{
"subComponentType":"AWS::EC2::Instance",
"alarmMetrics":[
{
"alarmMetricName":"CPUUtilization",
"monitor":true
},
{
"alarmMetricName":"StatusCheckFailed",
"monitor":true
},
{
"alarmMetricName":"disk_used_percent",
"monitor":true
},
{
"alarmMetricName":"mem_used_percent",
"monitor":true
}
],
"logs":[
{
"logGroupName":"APPLICATION-KubernetesClusterOnEC2-IAD",
"logPath":"",
"logType":"APPLICATION",
"monitor":true,
"encoding":"utf-8"
}
],
"processes" : [
{
"processName" : "my_process",
"alarmMetrics" : [
{
"alarmMetricName" : "procstat cpu_usage",
"monitor" : true
}, {
"alarmMetricName" : "procstat memory_rss",
"monitor" : true
}
]
}
],
"windowsEvents":[
{
"logGroupName":"my_log_group_2",
"eventName":"Application",
"eventLevels":[
"ERROR",
"WARNING",
"CRITICAL"
],
"monitor":true
}
]
},
{
"subComponentType":"AWS::AutoScaling::AutoScalingGroup",
"alarmMetrics":[
{
"alarmMetricName":"CPUCreditBalance",
"monitor":true
},
{
"alarmMetricName":"EBSIOBalance%",
"monitor":true
}
]
},
{
"subComponentType":"AWS::EC2::Volume",
"alarmMetrics":[
{
"alarmMetricName":"VolumeReadBytes",
"monitor":true
},
{
"alarmMetricName":"VolumeWriteBytes",
"monitor":true
},
{
"alarmMetricName":"VolumeReadOps",
"monitor":true
},
{
"alarmMetricName":"VolumeWriteOps",
"monitor":true
},
{
"alarmMetricName":"VolumeQueueLength",
"monitor":true
},
{
"alarmMetricName":"BurstBalance",
"monitor":true
}
]
}
]
}
```
**注記**
`AWS::EC2::Instance`、`AWS::EC2::Volume`、`AWS::AutoScaling::AutoScalingGroup` の `subComponents` セクションは、EC2 起動タイプで実行されている Amazon EKS クラスターにのみ適用されます。
`subComponents` の `AWS::EC2::Instance` の `windowsEvents` セクションは、Amazon EC2 インスタンスで実行されている Windows にのみ適用されます。
# Amazon Elastic Compute Cloud (EC2) インスタンス
次の例は、Amazon EC2 インスタンス用の JSON 形式のコンポーネント設定を示しています。
**重要**
Amazon EC2 インスタンスが `stopped` 状態になった場合、モニターリングから削除されます。`running` 状態に戻ったら、CloudWatch Application Insights コンソールの **[Application details]** (アプリケーションの詳細) ページの **[Unmonitored components]** (モニターリング対象ではないコンポーネント) リストに追加されます。アプリケーションで新しいリソースの自動モニターリングが有効になっている場合、インスタンスは **[Monitored components]** (モニターリング対象コンポーネント) に追加されます。ただし、ログとメトリクスは、ワークロードのデフォルトに設定されます。以前のログとメトリクスの設定は保存されません。
```
{
"alarmMetrics" : [
{
"alarmMetricName" : "CPUUtilization",
"monitor" : true
}, {
"alarmMetricName" : "StatusCheckFailed"
}
],
"logs" : [
{
"logGroupName" : "my_log_group",
"logPath" : "C:\\LogFolder\\*",
"logType" : "APPLICATION",
"monitor" : true
},
{
"logGroupName" : "my_log_group_2",
"logPath" : "C:\\LogFolder2\\*",
"logType" : "IIS",
"encoding" : "utf-8"
}
],
"processes" : [
{
"processName" : "my_process",
"alarmMetrics" : [
{
"alarmMetricName" : "procstat cpu_usage",
"monitor" : true
}, {
"alarmMetricName" : "procstat memory_rss",
"monitor" : true
}
]
}
],
"windowsEvents" : [
{
"logGroupName" : "my_log_group_3",
"eventName" : "Application",
"eventLevels" : [ "ERROR", "WARNING", "CRITICAL" ],
"monitor" : true
}, {
"logGroupName" : "my_log_group_4",
"eventName" : "System",
"eventLevels" : [ "ERROR", "WARNING", "CRITICAL" ],
"monitor" : true
}],
"alarms" : [
{
"alarmName" : "my_instance_alarm_1",
"severity" : "HIGH"
},
{
"alarmName" : "my_instance_alarm_2",
"severity" : "LOW"
}
],
"subComponents" : [
{
"subComponentType" : "AWS::EC2::Volume",
"alarmMetrics" : [
{
"alarmMetricName" : "VolumeQueueLength",
"monitor" : "true"
},
{
"alarmMetricName" : "VolumeThroughputPercentage",
"monitor" : "true"
},
{
"alarmMetricName" : "BurstBalance",
"monitor" : "true"
}]
}]
}
```
# Amazon Elastic Container Service (Amazon ECS)
次の例は、Amazon Elastic Container Service (Amazon ECS) 用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics":[
{
"alarmMetricName":"CpuUtilized",
"monitor":true
},
{
"alarmMetricName":"MemoryUtilized",
"monitor":true
},
{
"alarmMetricName":"NetworkRxBytes",
"monitor":true
},
{
"alarmMetricName":"NetworkTxBytes",
"monitor":true
},
{
"alarmMetricName":"RunningTaskCount",
"monitor":true
},
{
"alarmMetricName":"PendingTaskCount",
"monitor":true
},
{
"alarmMetricName":"StorageReadBytes",
"monitor":true
},
{
"alarmMetricName":"StorageWriteBytes",
"monitor":true
}
],
"logs":[
{
"logGroupName":"/ecs/my-task-definition",
"logType":"APPLICATION",
"monitor":true
}
],
"subComponents":[
{
"subComponentType":"AWS::ElasticLoadBalancing::LoadBalancer",
"alarmMetrics":[
{
"alarmMetricName":"HTTPCode_Backend_4XX",
"monitor":true
},
{
"alarmMetricName":"HTTPCode_Backend_5XX",
"monitor":true
},
{
"alarmMetricName":"Latency",
"monitor":true
},
{
"alarmMetricName":"SurgeQueueLength",
"monitor":true
},
{
"alarmMetricName":"UnHealthyHostCount",
"monitor":true
}
]
},
{
"subComponentType":"AWS::ElasticLoadBalancingV2::LoadBalancer",
"alarmMetrics":[
{
"alarmMetricName":"HTTPCode_Target_4XX_Count",
"monitor":true
},
{
"alarmMetricName":"HTTPCode_Target_5XX_Count",
"monitor":true
},
{
"alarmMetricName":"TargetResponseTime",
"monitor":true
},
{
"alarmMetricName":"UnHealthyHostCount",
"monitor":true
}
]
},
{
"subComponentType":"AWS::EC2::Instance",
"alarmMetrics":[
{
"alarmMetricName":"CPUUtilization",
"monitor":true
},
{
"alarmMetricName":"StatusCheckFailed",
"monitor":true
},
{
"alarmMetricName":"disk_used_percent",
"monitor":true
},
{
"alarmMetricName":"mem_used_percent",
"monitor":true
}
],
"logs":[
{
"logGroupName":"my_log_group",
"logPath":"/mylog/path",
"logType":"APPLICATION",
"monitor":true
}
],
"processes" : [
{
"processName" : "my_process",
"alarmMetrics" : [
{
"alarmMetricName" : "procstat cpu_usage",
"monitor" : true
}, {
"alarmMetricName" : "procstat memory_rss",
"monitor" : true
}
]
}
],
"windowsEvents":[
{
"logGroupName":"my_log_group_2",
"eventName":"Application",
"eventLevels":[
"ERROR",
"WARNING",
"CRITICAL"
],
"monitor":true
}
]
},
{
"subComponentType":"AWS::EC2::Volume",
"alarmMetrics":[
{
"alarmMetricName":"VolumeQueueLength",
"monitor":"true"
},
{
"alarmMetricName":"VolumeThroughputPercentage",
"monitor":"true"
},
{
"alarmMetricName":"BurstBalance",
"monitor":"true"
}
]
}
]
}
```
**注記**
`AWS::EC2::Instance` および `AWS::EC2::Volume`の `subComponents` セクションは、EC2 起動タイプで実行されている ECS サービスまたは ECS タスクを持つ Amazon ECS クラスターにのみ適用されます。
`subComponents` の `AWS::EC2::Instance` の `windowsEvents` セクションは、Amazon EC2 インスタンスで実行されている Windows にのみ適用されます。
# Amazon ECS サービス
次の例は、Amazon ECS サービス用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics":[
{
"alarmMetricName":"CPUUtilization",
"monitor":true
},
{
"alarmMetricName":"MemoryUtilization",
"monitor":true
},
{
"alarmMetricName":"CpuUtilized",
"monitor":true
},
{
"alarmMetricName":"MemoryUtilized",
"monitor":true
},
{
"alarmMetricName":"NetworkRxBytes",
"monitor":true
},
{
"alarmMetricName":"NetworkTxBytes",
"monitor":true
},
{
"alarmMetricName":"RunningTaskCount",
"monitor":true
},
{
"alarmMetricName":"PendingTaskCount",
"monitor":true
},
{
"alarmMetricName":"StorageReadBytes",
"monitor":true
},
{
"alarmMetricName":"StorageWriteBytes",
"monitor":true
}
],
"logs":[
{
"logGroupName":"/ecs/my-task-definition",
"logType":"APPLICATION",
"monitor":true
}
],
"subComponents":[
{
"subComponentType":"AWS::ElasticLoadBalancing::LoadBalancer",
"alarmMetrics":[
{
"alarmMetricName":"HTTPCode_Backend_4XX",
"monitor":true
},
{
"alarmMetricName":"HTTPCode_Backend_5XX",
"monitor":true
},
{
"alarmMetricName":"Latency",
"monitor":true
},
{
"alarmMetricName":"SurgeQueueLength",
"monitor":true
},
{
"alarmMetricName":"UnHealthyHostCount",
"monitor":true
}
]
},
{
"subComponentType":"AWS::ElasticLoadBalancingV2::LoadBalancer",
"alarmMetrics":[
{
"alarmMetricName":"HTTPCode_Target_4XX_Count",
"monitor":true
},
{
"alarmMetricName":"HTTPCode_Target_5XX_Count",
"monitor":true
},
{
"alarmMetricName":"TargetResponseTime",
"monitor":true
},
{
"alarmMetricName":"UnHealthyHostCount",
"monitor":true
}
]
},
{
"subComponentType":"AWS::EC2::Instance",
"alarmMetrics":[
{
"alarmMetricName":"CPUUtilization",
"monitor":true
},
{
"alarmMetricName":"StatusCheckFailed",
"monitor":true
},
{
"alarmMetricName":"disk_used_percent",
"monitor":true
},
{
"alarmMetricName":"mem_used_percent",
"monitor":true
}
],
"logs":[
{
"logGroupName":"my_log_group",
"logPath":"/mylog/path",
"logType":"APPLICATION",
"monitor":true
}
],
"processes" : [
{
"processName" : "my_process",
"alarmMetrics" : [
{
"alarmMetricName" : "procstat cpu_usage",
"monitor" : true
}, {
"alarmMetricName" : "procstat memory_rss",
"monitor" : true
}
]
}
],
"windowsEvents":[
{
"logGroupName":"my_log_group_2",
"eventName":"Application",
"eventLevels":[
"ERROR",
"WARNING",
"CRITICAL"
],
"monitor":true
}
]
},
{
"subComponentType":"AWS::EC2::Volume",
"alarmMetrics":[
{
"alarmMetricName":"VolumeQueueLength",
"monitor":"true"
},
{
"alarmMetricName":"VolumeThroughputPercentage",
"monitor":"true"
},
{
"alarmMetricName":"BurstBalance",
"monitor":"true"
}
]
}
]
}
```
**注記**
`AWS::EC2::Instance` および `AWS::EC2::Volume` の `subComponents` セクションは、EC2 起動タイプで実行されている Amazon ECS にのみ適用されます。
`subComponents` の `AWS::EC2::Instance` の `windowsEvents` セクションは、Amazon EC2 インスタンスで実行されている Windows にのみ適用されます。
# Amazon ECS タスク
次の例は、Amazon ECS タスク用の JSON 形式のコンポーネント設定を示しています。
```
{
"logs":[
{
"logGroupName":"/ecs/my-task-definition",
"logType":"APPLICATION",
"monitor":true
}
],
"processes" : [
{
"processName" : "my_process",
"alarmMetrics" : [
{
"alarmMetricName" : "procstat cpu_usage",
"monitor" : true
}, {
"alarmMetricName" : "procstat memory_rss",
"monitor" : true
}
]
}
]
}
```
# Amazon Elastic File System (Amazon EFS)
次の例は、Amazon EFS 用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "BurstCreditBalance",
"monitor": true
},
{
"alarmMetricName": "PercentIOLimit",
"monitor": true
},
{
"alarmMetricName": "PermittedThroughput",
"monitor": true
},
{
"alarmMetricName": "MeteredIOBytes",
"monitor": true
},
{
"alarmMetricName": "TotalIOBytes",
"monitor": true
},
{
"alarmMetricName": "DataWriteIOBytes",
"monitor": true
},
{
"alarmMetricName": "DataReadIOBytes",
"monitor": true
},
{
"alarmMetricName": "MetadataIOBytes",
"monitor": true
},
{
"alarmMetricName": "ClientConnections",
"monitor": true
},
{
"alarmMetricName": "TimeSinceLastSync",
"monitor": true
},
{
"alarmMetricName": "Throughput",
"monitor": true
},
{
"alarmMetricName": "PercentageOfPermittedThroughputUtilization",
"monitor": true
},
{
"alarmMetricName": "ThroughputIOPS",
"monitor": true
},
{
"alarmMetricName": "PercentThroughputDataReadIOBytes",
"monitor": true
},
{
"alarmMetricName": "PercentThroughputDataWriteIOBytes",
"monitor": true
},
{
"alarmMetricName": "PercentageOfIOPSDataReadIOBytes",
"monitor": true
},
{
"alarmMetricName": "PercentageOfIOPSDataWriteIOBytes",
"monitor": true
},
{
"alarmMetricName": "AverageDataReadIOBytesSize",
"monitor": true
},
{
"alarmMetricName": "AverageDataWriteIOBytesSize",
"monitor": true
}
],
"logs": [
{
"logGroupName": "/aws/efs/utils",
"logType": "EFS_MOUNT_STATUS",
"monitor": true,
}
]
}
```
# Amazon FSx
次の例は、Amazon FSx 用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "DataReadBytes",
"monitor": true
},
{
"alarmMetricName": "DataWriteBytes",
"monitor": true
},
{
"alarmMetricName": "DataReadOperations",
"monitor": true
},
{
"alarmMetricName": "DataWriteOperations",
"monitor": true
},
{
"alarmMetricName": "MetadataOperations",
"monitor": true
},
{
"alarmMetricName": "FreeStorageCapacity",
"monitor": true
}
]
}
```
# Amazon Relational Database Service (RDS) Aurora MySQL
次の例は、Amazon RDS Aurora MySQL 用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "CPUUtilization",
"monitor": true
},
{
"alarmMetricName": "CommitLatency",
"monitor": true
}
],
"logs": [
{
"logType": "MYSQL",
"monitor": true,
},
{
"logType": "MYSQL_SLOW_QUERY",
"monitor": false
}
]
}
```
# Amazon Relational Database Service (RDS) インスタンス
次の例は、Amazon RDS インスタンス用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics" : [
{
"alarmMetricName" : "BurstBalance",
"monitor" : true
}, {
"alarmMetricName" : "WriteThroughput",
"monitor" : false
}
],
"alarms" : [
{
"alarmName" : "my_rds_instance_alarm",
"severity" : "MEDIUM"
}
]
}
```
# Amazon Route 53 ヘルスチェック
次の例は、Amazon Route 53 ヘルスチェック用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "ChildHealthCheckHealthyCount",
"monitor": true
},
{
"alarmMetricName": "ConnectionTime",
"monitor": true
},
{
"alarmMetricName": "HealthCheckPercentageHealthy",
"monitor": true
},
{
"alarmMetricName": "HealthCheckStatus",
"monitor": true
},
{
"alarmMetricName": "SSLHandshakeTime",
"monitor": true
},
{
"alarmMetricName": "TimeToFirstByte",
"monitor": true
}
]
}
```
# Amazon Route 53 ホストゾーン
次の例は、Amazon Route 53 ホストゾーン用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "DNSQueries",
"monitor": true
},
{
"alarmMetricName": "DNSSECInternalFailure",
"monitor": true
},
{
"alarmMetricName": "DNSSECKeySigningKeysNeedingAction",
"monitor": true
},
{
"alarmMetricName": "DNSSECKeySigningKeyMaxNeedingActionAge",
"monitor": true
},
{
"alarmMetricName": "DNSSECKeySigningKeyAge",
"monitor": true
}
],
"logs": [
{
"logGroupName":"/hosted-zone/logs",
"logType": "ROUTE53_DNS_PUBLIC_QUERY_LOGS",
"monitor": true
}
]
}
```
# Amazon Route 53 Resolver エンドポイント
次の例は、Amazon Route 53 Resolver エンドポイント用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "EndpointHealthyENICount",
"monitor": true
},
{
"alarmMetricName": "EndpointUnHealthyENICount",
"monitor": true
},
{
"alarmMetricName": "InboundQueryVolume",
"monitor": true
},
{
"alarmMetricName": "OutboundQueryVolume",
"monitor": true
},
{
"alarmMetricName": "OutboundQueryAggregateVolume",
"monitor": true
}
]
}
```
# Amazon Route 53 Resolver クエリログ記録の設定
次の例は、Amazon Route 53 Resolver クエリログ記録設定用の JSON 形式のコンポーネント設定を示しています。
```
{
"logs": [
{
"logGroupName": "/resolver-query-log-config/logs",
"logType": "ROUTE53_RESOLVER_QUERY_LOGS",
"monitor": true
}
]
}
```
# Amazon S3 バケット
次の例は、Amazon S3 バケット用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics" : [
{
"alarmMetricName" : "ReplicationLatency",
"monitor" : true
}, {
"alarmMetricName" : "5xxErrors",
"monitor" : true
}, {
"alarmMetricName" : "BytesDownloaded"
"monitor" : true
}
]
}
```
# Amazon Simple Queue Service (SQS)
次の例は、Amazon Simple Queue Service 用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics" : [
{
"alarmMetricName" : "ApproximateAgeOfOldestMessage"
}, {
"alarmMetricName" : "NumberOfEmptyReceives"
}
],
"alarms" : [
{
"alarmName" : "my_sqs_alarm",
"severity" : "MEDIUM"
}
]
}
```
# Amazon SNS トピック
次の例は、Amazon SNS トピック用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "NumberOfNotificationsFailed",
"monitor": true
},
{
"alarmMetricName": "NumberOfNotificationsFilteredOut-InvalidAttributes",
"monitor": true
},
{
"alarmMetricName": "NumberOfNotificationsFilteredOut-NoMessageAttributes",
"monitor": true
},
{
"alarmMetricName": "NumberOfNotificationsFailedToRedriveToDlq",
"monitor": true
}
]
}
```
# Amazon Virtual Private Cloud (Amazon VPC)
次の例は、Amazon VPC 用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "NetworkAddressUsage",
"monitor": true
},
{
"alarmMetricName": "NetworkAddressUsagePeered",
"monitor": true
},
{
"alarmMetricName": "VPCFirewallQueryVolume",
"monitor": true
}
]
}
```
# Amazon VPC ネットワークアドレス変換 (NAT) ゲートウェイ
次の例は、NAT ゲートウェイ用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "ErrorPortAllocation",
"monitor": true
},
{
"alarmMetricName": "IdleTimeoutCount",
"monitor": true
}
]
}
```
# API Gateway REST API ステージ
次の例は、API Gateway REST API ステージ用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics" : [
{
"alarmMetricName" : "4XXError",
"monitor" : true
},
{
"alarmMetricName" : "5XXError",
"monitor" : true
}
],
"logs" : [
{
"logType" : "API_GATEWAY_EXECUTION",
"monitor" : true
},
{
"logType" : "API_GATEWAY_ACCESS",
"monitor" : true
}
]
}
```
# Application Elastic Load Balancing
次の例は、Application Elastic Load Balancing 用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "ActiveConnectionCount",
}, {
"alarmMetricName": "TargetResponseTime"
}
],
"subComponents": [
{
"subComponentType": "AWS::EC2::Instance",
"alarmMetrics": [
{
"alarmMetricName": "CPUUtilization",
}, {
"alarmMetricName": "StatusCheckFailed"
}
],
"logs": [
{
"logGroupName": "my_log_group",
"logPath": "C:\\LogFolder\\*",
"logType": "APPLICATION",
}
],
"windowsEvents": [
{
"logGroupName": "my_log_group_2",
"eventName": "Application",
"eventLevels": [ "ERROR", "WARNING", "CRITICAL" ]
}
]
}, {
"subComponentType": "AWS::EC2::Volume",
"alarmMetrics": [
{
"alarmMetricName": "VolumeQueueLength",
}, {
"alarmMetricName": "BurstBalance"
}
]
}
],
"alarms": [
{
"alarmName": "my_alb_alarm",
"severity": "LOW"
}
]
}
```
# AWS Lambda 関数
次の例は、AWS Lambda 機能用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "Errors",
"monitor": true
},
{
"alarmMetricName": "Throttles",
"monitor": true
},
{
"alarmMetricName": "IteratorAge",
"monitor": true
},
{
"alarmMetricName": "Duration",
"monitor": true
}
],
"logs": [
{
"logType": "DEFAULT",
"monitor": true
}
]
}
```
# AWS Network Firewall ルールグループ
次の例は、AWS Network Firewall ルールグループ用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "FirewallRuleGroupQueryVolume",
"monitor": true
}
]
}
```
# AWS Network Firewall ルールグループ関連付け
次の例は、AWS Network Firewall ルールグループ関連付け用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "FirewallRuleGroupQueryVolume",
"monitor": true
}
]
}
```
# AWS Step Functions
次の例は、AWS Step Functions 用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "ExecutionsFailed",
"monitor": true
},
{
"alarmMetricName": "LambdaFunctionsFailed",
"monitor": true
},
{
"alarmMetricName": "ProvisionedRefillRate",
"monitor": true
}
],
"logs": [
{
"logGroupName": "/aws/states/HelloWorld-Logs",
"logType": "STEP_FUNCTION",
"monitor": true,
}
]
}
```
# カスタマーグループ化された Amazon EC2 インスタンス
次の例は、カスタマーグループ化された Amazon EC2 インスタンス用の JSON 形式のコンポーネント設定を示しています。
```
{
"subComponents": [
{
"subComponentType": "AWS::EC2::Instance",
"alarmMetrics": [
{
"alarmMetricName": "CPUUtilization",
},
{
"alarmMetricName": "StatusCheckFailed"
}
],
"logs": [
{
"logGroupName": "my_log_group",
"logPath": "C:\\LogFolder\\*",
"logType": "APPLICATION",
}
],
"processes": [
{
"processName": "my_process",
"alarmMetrics": [
{
"alarmMetricName": "procstat cpu_usage",
"monitor": true
}, {
"alarmMetricName": "procstat memory_rss",
"monitor": true
}
]
}
],
"windowsEvents": [
{
"logGroupName": "my_log_group_2",
"eventName": "Application",
"eventLevels": [ "ERROR", "WARNING", "CRITICAL" ]
}
]
}, {
"subComponentType": "AWS::EC2::Volume",
"alarmMetrics": [
{
"alarmMetricName": "VolumeQueueLength",
}, {
"alarmMetricName": "BurstBalance"
}
]
}
],
"alarms": [
{
"alarmName": "my_alarm",
"severity": "MEDIUM"
}
]
}
```
# Elastic Load Balancing
次の例は、Elastic Load Balancing 用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "EstimatedALBActiveConnectionCount"
}, {
"alarmMetricName": "HTTPCode_Backend_5XX"
}
],
"subComponents": [
{
"subComponentType": "AWS::EC2::Instance",
"alarmMetrics": [
{
"alarmMetricName": "CPUUtilization"
}, {
"alarmMetricName": "StatusCheckFailed"
}
],
"logs": [
{
"logGroupName": "my_log_group",
"logPath": "C:\\LogFolder\\*",
"logType": "APPLICATION"
}
],
"processes": [
{
"processName": "my_process",
"alarmMetrics": [
{
"alarmMetricName": "procstat cpu_usage",
"monitor": true
}, {
"alarmMetricName": "procstat memory_rss",
"monitor": true
}
]
}
],
"windowsEvents": [
{
"logGroupName": "my_log_group_2",
"eventName": "Application",
"eventLevels": [ "ERROR", "WARNING", "CRITICAL" ],
"monitor": true
}
]
}, {
"subComponentType": "AWS::EC2::Volume",
"alarmMetrics": [
{
"alarmMetricName": "VolumeQueueLength"
}, {
"alarmMetricName": "BurstBalance"
}
]
}
],
"alarms": [
{
"alarmName": "my_elb_alarm",
"severity": "HIGH"
}
]
}
```
# Java
次の例は、Java 用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [ {
"alarmMetricName": "java_lang_threading_threadcount",
"monitor": true
},
{
"alarmMetricName": "java_lang_memory_heapmemoryusage_used",
"monitor": true
},
{
"alarmMetricName": "java_lang_memory_heapmemoryusage_committed",
"monitor": true
}],
"logs": [ ],
"JMXPrometheusExporter": {
"hostPort": "8686",
"prometheusPort": "9404"
}
}
```
**注記**
Application Insights は、Prometheus JMX Exporter の認証の設定をサポートしていません。認証の設定方法については、[Prometheus JMX Exporter の設定例](https://github.com/prometheus/jmx_exporter#configuration)をご参照ください。
# Amazon EC2 での Kubernetes
次の例は、Amazon EC2 での Kubernetes 用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics":[
{
"alarmMetricName":"cluster_failed_node_count",
"monitor":true
},
{
"alarmMetricName":"node_cpu_reserved_capacity",
"monitor":true
},
{
"alarmMetricName":"node_cpu_utilization",
"monitor":true
},
{
"alarmMetricName":"node_filesystem_utilization",
"monitor":true
},
{
"alarmMetricName":"node_memory_reserved_capacity",
"monitor":true
},
{
"alarmMetricName":"node_memory_utilization",
"monitor":true
},
{
"alarmMetricName":"node_network_total_bytes",
"monitor":true
},
{
"alarmMetricName":"pod_cpu_reserved_capacity",
"monitor":true
},
{
"alarmMetricName":"pod_cpu_utilization",
"monitor":true
},
{
"alarmMetricName":"pod_cpu_utilization_over_pod_limit",
"monitor":true
},
{
"alarmMetricName":"pod_memory_reserved_capacity",
"monitor":true
},
{
"alarmMetricName":"pod_memory_utilization",
"monitor":true
},
{
"alarmMetricName":"pod_memory_utilization_over_pod_limit",
"monitor":true
},
{
"alarmMetricName":"pod_network_rx_bytes",
"monitor":true
},
{
"alarmMetricName":"pod_network_tx_bytes",
"monitor":true
}
],
"logs":[
{
"logGroupName":"/aws/containerinsights/kubernetes/application",
"logType":"APPLICATION",
"monitor":true,
"encoding":"utf-8"
}
],
"subComponents":[
{
"subComponentType":"AWS::EC2::Instance",
"alarmMetrics":[
{
"alarmMetricName":"CPUUtilization",
"monitor":true
},
{
"alarmMetricName":"StatusCheckFailed",
"monitor":true
},
{
"alarmMetricName":"disk_used_percent",
"monitor":true
},
{
"alarmMetricName":"mem_used_percent",
"monitor":true
}
],
"logs":[
{
"logGroupName":"APPLICATION-KubernetesClusterOnEC2-IAD",
"logPath":"",
"logType":"APPLICATION",
"monitor":true,
"encoding":"utf-8"
}
],
"processes" : [
{
"processName" : "my_process",
"alarmMetrics" : [
{
"alarmMetricName" : "procstat cpu_usage",
"monitor" : true
}, {
"alarmMetricName" : "procstat memory_rss",
"monitor" : true
}
]
}
]
},
{
"subComponentType":"AWS::EC2::Volume",
"alarmMetrics":[
{
"alarmMetricName":"VolumeReadBytes",
"monitor":true
},
{
"alarmMetricName":"VolumeWriteBytes",
"monitor":true
},
{
"alarmMetricName":"VolumeReadOps",
"monitor":true
},
{
"alarmMetricName":"VolumeWriteOps",
"monitor":true
},
{
"alarmMetricName":"VolumeQueueLength",
"monitor":true
},
{
"alarmMetricName":"BurstBalance",
"monitor":true
}
]
}
]
}
```
# RDS MariaDB と RDS MySQL
次の例は、RDS MariaDB と RDS MySQL 用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "CPUUtilization",
"monitor": true
}
],
"logs": [
{
"logType": "MYSQL",
"monitor": true,
},
{
"logType": "MYSQL_SLOW_QUERY",
"monitor": false
}
]
}
```
# RDS Oracle
次の例は、RDS Oracle 用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "CPUUtilization",
"monitor": true
}
],
"logs": [
{
"logType": "ORACLE_ALERT",
"monitor": true,
},
{
"logType": "ORACLE_LISTENER",
"monitor": false
}
]
}
```
# RDS PostgreSQL
次の例は、RDS PostgreSQL 用の JSON 形式のコンポーネント設定を示しています。
```
{
"alarmMetrics": [
{
"alarmMetricName": "CPUUtilization",
"monitor": true
}
],
"logs": [
{
"logType": "POSTGRESQL",
"monitor": true
}
]
}
```
# Amazon EC2 での SAP ASE
次の例は、Amazon EC2 での SAP ASE 用の JSON 形式のコンポーネント設定を示しています。
```
{
"subComponents": [
{
"subComponentType": "AWS::EC2::Instance",
"alarmMetrics": [
{
"alarmMetricName": "asedb_database_availability",
"monitor": true
},
{
"alarmMetricName": "asedb_trunc_log_on_chkpt_enabled",
"monitor": true
},
{
"alarmMetricName": "asedb_last_db_backup_age_in_days",
"monitor": true
},
{
"alarmMetricName": "asedb_last_transaction_log_backup_age_in_hours",
"monitor": true
},
{
"alarmMetricName": "asedb_suspected_database",
"monitor": true
},
{
"alarmMetricName": "asedb_db_space_usage_percent",
"monitor": true
},
{
"alarmMetricName": "asedb_db_log_space_usage_percent",
"monitor": true
},
{
"alarmMetricName": "asedb_locked_login",
"monitor": true
},
{
"alarmMetricName": "asedb_data_cache_hit_ratio",
"monitor": true
}
],
"logs": [
{
"logGroupName": "SAP_ASE_SERVER_LOGS-my-resource-group",
"logPath": "/sybase/SY2/ASE-*/install/SY2.log",
"logType": "SAP_ASE_SERVER_LOGS",
"monitor": true,
"encoding": "utf-8"
},
{
"logGroupName": "SAP_ASE_BACKUP_SERVER_LOGS-my-resource-group",
"logPath": "/sybase/SY2/ASE-*/install/SY2_BS.log",
"logType": "SAP_ASE_BACKUP_SERVER_LOGS",
"monitor": true,
"encoding": "utf-8"
}
],
"sapAsePrometheusExporter": {
"sapAseSid": "ASE",
"sapAsePort": "4901",
"sapAseSecretName": "ASE_DB_CREDS",
"prometheusPort": "9399",
"agreeToEnableASEMonitoring": true
}
```
# Amazon EC2 での SAP ASE High Availability
次の例は、Amazon EC2 での SAP ASE High Availability 用の JSON 形式のコンポーネント設定を示しています。
```
{
"subComponents": [
{
"subComponentType": "AWS::EC2::Instance",
"alarmMetrics": [
{
"alarmMetricName": "asedb_database_availability",
"monitor": true
},
{
"alarmMetricName": "asedb_trunc_log_on_chkpt_enabled",
"monitor": true
},
{
"alarmMetricName": "asedb_last_db_backup_age_in_days",
"monitor": true
},
{
"alarmMetricName": "asedb_last_transaction_log_backup_age_in_hours",
"monitor": true
},
{
"alarmMetricName": "asedb_suspected_database",
"monitor": true
},
{
"alarmMetricName": "asedb_db_space_usage_percent",
"monitor": true
},
{
"alarmMetricName": "asedb_ha_replication_state",
"monitor": true
},
{
"alarmMetricName": "asedb_ha_replication_mode",
"monitor": true
},
{
"alarmMetricName": "asedb_ha_replication_latency_in_minutes",
"monitor": true
}
],
"logs": [
{
"logGroupName": "SAP_ASE_SERVER_LOGS-my-resource-group",
"logPath": "/sybase/SY2/ASE-*/install/SY2.log",
"logType": "SAP_ASE_SERVER_LOGS",
"monitor": true,
"encoding": "utf-8"
},
{
"logGroupName": "SAP_ASE_BACKUP_SERVER_LOGS-my-resource-group",
"logPath": "/sybase/SY2/ASE-*/install/SY2_BS.log",
"logType": "SAP_ASE_BACKUP_SERVER_LOGS",
"monitor": true,
"encoding": "utf-8"
},
{
"logGroupName": "SAP_ASE_REP_SERVER_LOGS-my-resource-group",
"logPath": "/sybase/SY2/DM/repservername/repservername.log",
"logType": "SAP_ASE_REP_SERVER_LOGS",
"monitor": true,
"encoding": "utf-8"
},
{
"logGroupName": "SAP_ASE_RMA_AGENT_LOGS-my-resource-group",
"logPath": "/sybase/SY2/DM/RMA-*/instances/AgentContainer/logs/",
"logType": "SAP_ASE_RMA_AGENT_LOGS",
"monitor": true,
"encoding": "utf-8"
},
{
"logGroupName": "SAP_ASE_FAULT_MANAGER_LOGS-my-resource-group",
"logPath": "/opt/sap/FaultManager/dev_sybdbfm",
"logType": "SAP_ASE_FAULT_MANAGER_LOGS",
"monitor": true,
"encoding": "utf-8"
}
],
"sapAsePrometheusExporter": {
"sapAseSid": "ASE",
"sapAsePort": "4901",
"sapAseSecretName": "ASE_DB_CREDS",
"prometheusPort": "9399",
"agreeToEnableASEMonitoring": true
}
```
# Amazon EC2 での SAP HANA
次の例は、Amazon EC2 での SAP HANA 用の JSON 形式のコンポーネント設定を示しています。
```
{
"subComponents": [
{
"subComponentType": "AWS::EC2::Instance",
"alarmMetrics": [
{
"alarmMetricName": "hanadb_server_startup_time_variations_seconds",
"monitor": true
},
{
"alarmMetricName": "hanadb_level_5_alerts_count",
"monitor": true
},
{
"alarmMetricName": "hanadb_level_4_alerts_count",
"monitor": true
},
{
"alarmMetricName": "hanadb_out_of_memory_events_count",
"monitor": true
},
{
"alarmMetricName": "hanadb_max_trigger_read_ratio_percent",
"monitor": true
},
{
"alarmMetricName": "hanadb_table_allocation_limit_used_percent",
"monitor": true
},
{
"alarmMetricName": "hanadb_cpu_usage_percent",
"monitor": true
},
{
"alarmMetricName": "hanadb_plan_cache_hit_ratio_percent",
"monitor": true
},
{
"alarmMetricName": "hanadb_last_data_backup_age_days",
"monitor": true
}
],
"logs": [
{
"logGroupName": "SAP_HANA_TRACE-my-resourge-group",
"logPath": "/usr/sap/HDB/HDB00/*/trace/*.trc",
"logType": "SAP_HANA_TRACE",
"monitor": true,
"encoding": "utf-8"
},
{
"logGroupName": "SAP_HANA_LOGS-my-resource-group",
"logPath": "/usr/sap/HDB/HDB00/*/trace/*.log",
"logType": "SAP_HANA_LOGS",
"monitor": true,
"encoding": "utf-8"
}
]
}
],
"hanaPrometheusExporter": {
"hanaSid": "HDB",
"hanaPort": "30013",
"hanaSecretName": "HANA_DB_CREDS",
"prometheusPort": "9668"
}
}
```
# Amazon EC2 での SAP HANA High Availability
次の例は、Amazon EC2 での SAP HANA High Availability 用の JSON 形式のコンポーネント設定を示しています。
```
{
"subComponents": [
{
"subComponentType": "AWS::EC2::Instance",
"alarmMetrics": [
{
"alarmMetricName": "hanadb_server_startup_time_variations_seconds",
"monitor": true
},
{
"alarmMetricName": "hanadb_level_5_alerts_count",
"monitor": true
},
{
"alarmMetricName": "hanadb_level_4_alerts_count",
"monitor": true
},
{
"alarmMetricName": "hanadb_out_of_memory_events_count",
"monitor": true
},
{
"alarmMetricName": "ha_cluster_pacemaker_stonith_enabled",
"monitor": true
}
],
"logs": [
{
"logGroupName": "SAP_HANA_TRACE-my-resourge-group",
"logPath": "/usr/sap/HDB/HDB00/*/trace/*.trc",
"logType": "SAP_HANA_TRACE",
"monitor": true,
"encoding": "utf-8"
},
{
"logGroupName": "SAP_HANA_HIGH_AVAILABILITY-my-resource-group",
"logPath": "/var/log/pacemaker/pacemaker.log",
"logType": "SAP_HANA_HIGH_AVAILABILITY",
"monitor": true,
"encoding": "utf-8"
}
]
}
],
"hanaPrometheusExporter": {
"hanaSid": "HDB",
"hanaPort": "30013",
"hanaSecretName": "HANA_DB_CREDS",
"prometheusPort": "9668"
},
"haClusterPrometheusExporter": {
"prometheusPort": "9664"
}
}
```
# Amazon EC2 での SAP NetWeaver
次の例は、Amazon EC2 での SAP Netweaver 用の JSON 形式のコンポーネント設定を示しています。
```
{
"subComponents": [
{
"subComponentType": "AWS::EC2::Instance",
"alarmMetrics": [
{
"alarmMetricName": "CPUUtilization",
"monitor": true
},
{
"alarmMetricName": "StatusCheckFailed",
"monitor": true
},
{
"alarmMetricName": "disk_used_percent",
"monitor": true
},
{
"alarmMetricName": "mem_used_percent",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_ResponseTime",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_ResponseTimeDialog",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_ResponseTimeDialogRFC",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_DBRequestTime",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_LongRunners",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_AbortedJobs",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_BasisSystem",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_Database",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_Security",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_System",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_QueueTime",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_Availability",
"monitor": true
},
{
"alarmMetricName": "sap_start_service_processes",
"monitor": true
},
{
"alarmMetricName": "sap_dispatcher_queue_now",
"monitor": true
},
{
"alarmMetricName": "sap_dispatcher_queue_max",
"monitor": true
},
{
"alarmMetricName": "sap_enqueue_server_locks_max",
"monitor": true
},
{
"alarmMetricName": "sap_enqueue_server_locks_now",
"monitor": true
},
{
"alarmMetricName": "sap_enqueue_server_locks_state",
"monitor": true
},
{
"alarmMetricName": "sap_enqueue_server_replication_state",
"monitor": true
}
],
"logs": [
{
"logGroupName": "SAP_NETWEAVER_DEV_TRACE_LOGS-NetWeaver-ML4",
"logPath": "/usr/sap/ML4/*/work/dev_w*",
"logType": "SAP_NETWEAVER_DEV_TRACE_LOGS",
"monitor": true,
"encoding": "utf-8"
}
]
}
],
"netWeaverPrometheusExporter": {
"sapSid": "ML4",
"instanceNumbers": [
"00",
"11"
],
"prometheusPort": "9680"
}
}
```
# Amazon EC2 での SAP Netweaver High Availability
次の例は、Amazon EC2 での SAP Netweaver High Availability 用の JSON 形式のコンポーネント設定を示しています。
```
{
"subComponents": [
{
"subComponentType": "AWS::EC2::Instance",
"alarmMetrics": [
{
"alarmMetricName": "ha_cluster_corosync_ring_errors",
"monitor": true
},
{
"alarmMetricName": "ha_cluster_pacemaker_fail_count",
"monitor": true
},
{
"alarmMetricName": "sap_HA_check_failover_config_state",
"monitor": true
},
{
"alarmMetricName": "sap_HA_get_failover_config_HAActive",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_AbortedJobs",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_Availability",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_BasisSystem",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_DBRequestTime",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_Database",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_FrontendResponseTime",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_LongRunners",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_QueueTime",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_ResponseTime",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_ResponseTimeDialog",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_ResponseTimeDialogRFC",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_Security",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_Shortdumps",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_SqlError",
"monitor": true
},
{
"alarmMetricName": "sap_alerts_System",
"monitor": true
},
{
"alarmMetricName": "sap_enqueue_server_replication_state",
"monitor": true
},
{
"alarmMetricName": "sap_start_service_processes",
"monitor": true
}
],
"logs": [
{
"logGroupName": "SAP_NETWEAVER_DEV_TRACE_LOGS-NetWeaver-PR1",
"logPath": "/usr/sap//D*/work/dev_w*",
"logType": "SAP_NETWEAVER_DEV_TRACE_LOGS",
"monitor": true,
"encoding": "utf-8"
}
]
}
],
"haClusterPrometheusExporter": {
"prometheusPort": "9664"
},
"netWeaverPrometheusExporter": {
"sapSid": "PR1",
"instanceNumbers": [
"11",
"12"
],
"prometheusPort": "9680"
}
}
```
# SQL Always On 可用性グループ
次の例は、SQL Always On 可用性グループ用の JSON 形式のコンポーネント設定を示しています。
```
{
"subComponents" : [ {
"subComponentType" : "AWS::EC2::Instance",
"alarmMetrics" : [ {
"alarmMetricName" : "CPUUtilization",
"monitor" : true
}, {
"alarmMetricName" : "StatusCheckFailed",
"monitor" : true
}, {
"alarmMetricName" : "Processor % Processor Time",
"monitor" : true
}, {
"alarmMetricName" : "Memory % Committed Bytes In Use",
"monitor" : true
}, {
"alarmMetricName" : "Memory Available Mbytes",
"monitor" : true
}, {
"alarmMetricName" : "Paging File % Usage",
"monitor" : true
}, {
"alarmMetricName" : "System Processor Queue Length",
"monitor" : true
}, {
"alarmMetricName" : "Network Interface Bytes Total/sec",
"monitor" : true
}, {
"alarmMetricName" : "PhysicalDisk % Disk Time",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Buffer Manager Buffer cache hit ratio",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Buffer Manager Page life expectancy",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:General Statistics Processes blocked",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:General Statistics User Connections",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Locks Number of Deadlocks/sec",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:SQL Statistics Batch Requests/sec",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica File Bytes Received/sec",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica Log Bytes Received/sec",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica Log remaining for undo",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica Log Send Queue",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica Mirrored Write Transaction/sec",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica Recovery Queue",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica Redo Bytes Remaining",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica Redone Bytes/sec",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica Total Log requiring undo",
"monitor" : true
}, {
"alarmMetricName" : "SQLServer:Database Replica Transaction Delay",
"monitor" : true
} ],
"windowsEvents" : [ {
"logGroupName" : "WINDOWS_EVENTS-Application-",
"eventName" : "Application",
"eventLevels" : [ "WARNING", "ERROR", "CRITICAL", "INFORMATION" ],
"monitor" : true
}, {
"logGroupName" : "WINDOWS_EVENTS-System-",
"eventName" : "System",
"eventLevels" : [ "WARNING", "ERROR", "CRITICAL" ],
"monitor" : true
}, {
"logGroupName" : "WINDOWS_EVENTS-Security-",
"eventName" : "Security",
"eventLevels" : [ "WARNING", "ERROR", "CRITICAL" ],
"monitor" : true
} ],
"logs" : [ {
"logGroupName" : "SQL_SERVER_ALWAYSON_AVAILABILITY_GROUP-",
"logPath" : "C:\\Program Files\\Microsoft SQL Server\\MSSQL**.MSSQLSERVER\\MSSQL\\Log\\ERRORLOG",
"logType" : "SQL_SERVER",
"monitor" : true,
"encoding" : "utf-8"
} ]
}, {
"subComponentType" : "AWS::EC2::Volume",
"alarmMetrics" : [ {
"alarmMetricName" : "VolumeReadBytes",
"monitor" : true
}, {
"alarmMetricName" : "VolumeWriteBytes",
"monitor" : true
}, {
"alarmMetricName" : "VolumeReadOps",
"monitor" : true
}, {
"alarmMetricName" : "VolumeWriteOps",
"monitor" : true
}, {
"alarmMetricName" : "VolumeQueueLength",
"monitor" : true
}, {
"alarmMetricName" : "VolumeThroughputPercentage",
"monitor" : true
}, {
"alarmMetricName" : "BurstBalance",
"monitor" : true
} ]
} ]
}
```
# SQL フェイルオーバークラスターインスタンス
次の例は、SQL フェールオーバークラスターインスタンス用の JSON 形式のコンポーネント設定を示しています。
```
{
"subComponents" : [ {
"subComponentType" : "AWS::EC2::Instance",
"alarmMetrics" : [ {
"alarmMetricName" : "CPUUtilization",
"monitor" : true
}, {
"alarmMetricName" : "StatusCheckFailed",
"monitor" : true
}, {
"alarmMetricName" : "Processor % Processor Time",
"monitor" : true
}, {
"alarmMetricName" : "Memory % Committed Bytes In Use",
"monitor" : true
}, {
"alarmMetricName" : "Memory Available Mbytes",
"monitor" : true
}, {
"alarmMetricName" : "Paging File % Usage",
"monitor" : true
}, {
"alarmMetricName" : "System Processor Queue Length",
"monitor" : true
}, {
"alarmMetricName" : "Network Interface Bytes Total/sec",
"monitor" : true
}, {
"alarmMetricName" : "PhysicalDisk % Disk Time",
"monitor" : true
}, {
"alarmMetricName" : "Bytes Received/sec",
"monitor" : true
}, {
"alarmMetricName" : "Normal Messages Queue Length/sec",
"monitor" : true
}, {
"alarmMetricName" : "Urgent Message Queue Length/se",
"monitor" : true
}, {
"alarmMetricName" : "Reconnect Count",
"monitor" : true
}, {
"alarmMetricName" : "Unacknowledged Message Queue Length/sec",
"monitor" : true
}, {
"alarmMetricName" : "Messages Outstanding",
"monitor" : true
}, {
"alarmMetricName" : "Messages Sent/sec",
"monitor" : true
}, {
"alarmMetricName" : "Database Update Messages/sec",
"monitor" : true
}, {
"alarmMetricName" : "Update Messages/sec",
"monitor" : true
}, {
"alarmMetricName" : "Flushes/sec",
"monitor" : true
}, {
"alarmMetricName" : "Crypto Checkpoints Saved/sec",
"monitor" : true
}, {
"alarmMetricName" : "Crypto Checkpoints Restored/sec",
"monitor" : true
}, {
"alarmMetricName" : "Registry Checkpoints Restored/sec",
"monitor" : true
}, {
"alarmMetricName" : "Registry Checkpoints Saved/sec",
"monitor" : true
}, {
"alarmMetricName" : "Cluster API Calls/sec",
"monitor" : true
}, {
"alarmMetricName" : "Resource API Calls/sec",
"monitor" : true
}, {
"alarmMetricName" : "Cluster Handles/sec",
"monitor" : true
}, {
"alarmMetricName" : "Resource Handles/sec",
"monitor" : true
} ],
"windowsEvents" : [ {
"logGroupName" : "WINDOWS_EVENTS-Application-",
"eventName" : "Application",
"eventLevels" : [ "WARNING", "ERROR", "CRITICAL"],
"monitor" : true
}, {
"logGroupName" : "WINDOWS_EVENTS-System-",
"eventName" : "System",
"eventLevels" : [ "WARNING", "ERROR", "CRITICAL", "INFORMATION" ],
"monitor" : true
}, {
"logGroupName" : "WINDOWS_EVENTS-Security-",
"eventName" : "Security",
"eventLevels" : [ "WARNING", "ERROR", "CRITICAL" ],
"monitor" : true
} ],
"logs" : [ {
"logGroupName" : "SQL_SERVER_FAILOVER_CLUSTER_INSTANCE-",
"logPath" : "\\\\amznfsxjmzbykwn.mydomain.aws\\SQLDB\\MSSQL**.MSSQLSERVER\\MSSQL\\Log\\ERRORLOG",
"logType" : "SQL_SERVER",
"monitor" : true,
"encoding" : "utf-8"
} ]
}, {
"subComponentType" : "AWS::EC2::Volume",
"alarmMetrics" : [ {
"alarmMetricName" : "VolumeReadBytes",
"monitor" : true
}, {
"alarmMetricName" : "VolumeWriteBytes",
"monitor" : true
}, {
"alarmMetricName" : "VolumeReadOps",
"monitor" : true
}, {
"alarmMetricName" : "VolumeWriteOps",
"monitor" : true
}, {
"alarmMetricName" : "VolumeQueueLength",
"monitor" : true
}, {
"alarmMetricName" : "VolumeThroughputPercentage",
"monitor" : true
}, {
"alarmMetricName" : "BurstBalance",
"monitor" : true
} ]
} ]
}
```
# CloudFormation テンプレートを使用して CloudWatch Application Insights モニターリングを作成および設定する
AWS CloudFormation テンプレートから、主要メトリクスやテレメトリを含む Application Insights モニターリングをアプリケーション、データベース、ウェブサーバーに追加できます。
このセクションでは、Application Insights モニターリングの作成および設定に役立つサンプル CloudFormation テンプレートを JSON 形式と YAML 形式の両方で提供しています。
*CloudFormation ユーザーガイド*の Application Insights リソースとプロパティのリファレンスを表示するには、[ApplicationInsights リソースタイプのリファレンス](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ApplicationInsights.html)を参照してください。
**Topics**
+ [
## CloudFormation スタック全体の Application Insights アプリケーションを作成する
](#appinsights-cloudformation-apply-to-stack)
+ [
## 詳細な設定を使用した Application Insights アプリケーションの作成
](#appinsights-cloudformation-apply-detailed)
+ [
## `CUSTOM` モードのコンポーネント設定を使用した Application Insights アプリケーションの作成
](#appinsights-cloudformation-custom)
+ [
## `DEFAULT` モードのコンポーネント設定を使用した Application Insights アプリケーションの作成
](#appinsights-cloudformation-default)
+ [
## `DEFAULT_WITH_OVERWRITE` モードのコンポーネント設定を使用した Application Insights アプリケーションの作成
](#appinsights-cloudformation-default-with-overwrite)
## CloudFormation スタック全体の Application Insights アプリケーションを作成する
次のテンプレートを適用するには、AWS リソースと、それらのリソースをモニターリングする Application Insights アプリケーションの作成元となる 1 つ以上の Resource Groups を作成する必要があります。詳細については、「[AWS Resource Groups の開始方法](https://docs.aws.amazon.com/ARG/latest/userguide/gettingstarted.html)」を参照してください。
次のテンプレートの最初の 2 つの部分は、リソースとリソースグループを指定します。テンプレートの最後の部分では、リソースグループの Application Insights アプリケーションを作成しますが、アプリケーションの設定やモニターリングの適用は行いません。詳細については、*Amazon CloudWatch Application Insights API リファレンス*の [CreateApplication](https://docs.aws.amazon.com/cloudwatch/latest/APIReference/API_CreateApplication.html) コマンドの詳細を参照してください。
**JSON 形式のテンプレート**
```
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "Test Resource Group stack",
"Resources": {
"EC2Instance": {
"Type": "AWS::EC2::Instance",
"Properties": {
"ImageId" : "ami-abcd1234efgh5678i",
"SecurityGroupIds" : ["sg-abcd1234"]
}
},
...
"ResourceGroup": {
"Type": "AWS::ResourceGroups::Group",
"Properties": {
"Name": "my_resource_group"
}
},
"AppInsightsApp": {
"Type": "AWS::ApplicationInsights::Application",
"Properties": {
"ResourceGroupName": "my_resource_group"
},
"DependsOn" : "ResourceGroup"
}
}
}
```
**YAML 形式のテンプレート**
```
---
AWSTemplateFormatVersion: '2010-09-09'
Description: Test Resource Group stack
Resources:
EC2Instance:
Type: AWS::EC2::Instance
Properties:
ImageId: ami-abcd1234efgh5678i
SecurityGroupIds:
- sg-abcd1234
...
ResourceGroup:
Type: AWS::ResourceGroups::Group
Properties:
Name: my_resource_group
AppInsightsApp:
Type: AWS::ApplicationInsights::Application
Properties:
ResourceGroupName: my_resource_group
DependsOn: ResourceGroup
```
次のテンプレートセクションでは、デフォルトのモニターリング設定を Application Insights アプリケーションに適用します。詳細については、*Amazon CloudWatch Application Insights API リファレンス*の [CreateApplication](https://docs.aws.amazon.com/cloudwatch/latest/APIReference/API_CreateApplication.html) コマンドの詳細を参照してください。
`AutoConfigurationEnabled` を `true` に設定すると、アプリケーションのすべてのコンポーネントが、`DEFAULT` アプリケーション層の推奨モニターリング設定を使用して設定されます。これらの設定と層の詳細については、*Amazon CloudWatch Application Insights API リファレンス*の「[DescribeComponentConfigurationRecommendation](https://docs.aws.amazon.com/cloudwatch/latest/APIReference/API_DescribeComponentConfigurationRecommendation.html)」と「[UpdateComponentConfiguration](https://docs.aws.amazon.com/cloudwatch/latest/APIReference/API_UpdateComponentConfiguration.html)」を参照してください。
**JSON 形式のテンプレート**
```
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "Test Application Insights Application stack",
"Resources": {
"AppInsightsApp": {
"Type": "AWS::ApplicationInsights::Application",
"Properties": {
"ResourceGroupName": "my_resource_group",
"AutoConfigurationEnabled": true
}
}
}
}
```
**YAML 形式のテンプレート**
```
---
AWSTemplateFormatVersion: '2010-09-09'
Description: Test Application Insights Application stack
Resources:
AppInsightsApp:
Type: AWS::ApplicationInsights::Application
Properties:
ResourceGroupName: my_resource_group
AutoConfigurationEnabled: true
```
## 詳細な設定を使用した Application Insights アプリケーションの作成
次のテンプレートは、これらのアクションを実行します。
+ CloudWatch Events 通知と OpsCenter が有効な Application Insights アプリケーションを作成します。詳細については、*Amazon CloudWatch Application Insights API リファレンス*の [CreateApplication](https://docs.aws.amazon.com/cloudwatch/latest/APIReference/API_CreateApplication.html) コマンドの詳細を参照してください。
+ アプリケーションに 2 つのタグを付けます。そのうちの 1 つにはタグ値がありません。詳細については、*Amazon CloudWatch Application Insights API リファレンス*の「[TagResource](https://docs.aws.amazon.com/cloudwatch/latest/APIReference/API_TagResource.html)」を参照してください。
+ 2 つのカスタムインスタンスグループコンポーネントを作成します。詳細については、*Amazon CloudWatch Application Insights API リファレンス*の「[CreateComponent](https://docs.aws.amazon.com/cloudwatch/latest/APIReference/API_CreateComponent.html)」を参照してください。
+ 2 つのログパターンセットを作成します。詳細については、*Amazon CloudWatch Application Insights API リファレンス*の「[CreateLogPattern](https://docs.aws.amazon.com/cloudwatch/latest/APIReference/API_CreateLogPattern.html)」を参照してください。
+ `AutoConfigurationEnabled` を `true` に設定します。これにより、アプリケーションのすべてのコンポーネントが、`DEFAULT` 層で推奨されるモニターリング設定で構成されます。詳細については、*Amazon CloudWatch Application Insights API リファレンス*の「[DescribeComponentConfigurationRecommendation](https://docs.aws.amazon.com/cloudwatch/latest/APIReference/API_DescribeComponentConfigurationRecommendation.html)」を参照してください。
**JSON 形式のテンプレート **
```
{
"Type": "AWS::ApplicationInsights::Application",
"Properties": {
"ResourceGroupName": "my_resource_group",
"CWEMonitorEnabled": true,
"OpsCenterEnabled": true,
"OpsItemSNSTopicArn": "arn:aws:sns:us-east-1:123456789012:my_topic",
"AutoConfigurationEnabled": true,
"Tags": [
{
"Key": "key1",
"Value": "value1"
},
{
"Key": "key2",
"Value": ""
}
],
"CustomComponents": [
{
"ComponentName": "test_component_1",
"ResourceList": [
"arn:aws:ec2:us-east-1:123456789012:instance/i-abcd1234efgh5678i"
]
},
{
"ComponentName": "test_component_2",
"ResourceList": [
"arn:aws:ec2:us-east-1:123456789012:instance/i-abcd1234efgh5678i",
"arn:aws:ec2:us-east-1:123456789012:instance/i-abcd1234efgh5678i"
]
}
],
"LogPatternSets": [
{
"PatternSetName": "pattern_set_1",
"LogPatterns": [
{
"PatternName": "deadlock_pattern",
"Pattern": ".*\\sDeadlocked\\sSchedulers(([^\\w].*)|($))",
"Rank": 1
}
]
},
{
"PatternSetName": "pattern_set_2",
"LogPatterns": [
{
"PatternName": "error_pattern",
"Pattern": ".*[\\s\\[]ERROR[\\s\\]].*",
"Rank": 1
},
{
"PatternName": "warning_pattern",
"Pattern": ".*[\\s\\[]WARN(ING)?[\\s\\]].*",
"Rank": 10
}
]
}
]
}
}
```
**YAML 形式のテンプレート**
```
---
Type: AWS::ApplicationInsights::Application
Properties:
ResourceGroupName: my_resource_group
CWEMonitorEnabled: true
OpsCenterEnabled: true
OpsItemSNSTopicArn: arn:aws:sns:us-east-1:123456789012:my_topic
AutoConfigurationEnabled: true
Tags:
- Key: key1
Value: value1
- Key: key2
Value: ''
CustomComponents:
- ComponentName: test_component_1
ResourceList:
- arn:aws:ec2:us-east-1:123456789012:instance/i-abcd1234efgh5678i
- ComponentName: test_component_2
ResourceList:
- arn:aws:ec2:us-east-1:123456789012:instance/i-abcd1234efgh5678i
- arn:aws:ec2:us-east-1:123456789012:instance/i-abcd1234efgh5678i
LogPatternSets:
- PatternSetName: pattern_set_1
LogPatterns:
- PatternName: deadlock_pattern
Pattern: ".*\\sDeadlocked\\sSchedulers(([^\\w].*)|($))"
Rank: 1
- PatternSetName: pattern_set_2
LogPatterns:
- PatternName: error_pattern
Pattern: ".*[\\s\\[]ERROR[\\s\\]].*"
Rank: 1
- PatternName: warning_pattern
Pattern: ".*[\\s\\[]WARN(ING)?[\\s\\]].*"
Rank: 10
```
## `CUSTOM` モードのコンポーネント設定を使用した Application Insights アプリケーションの作成
次のテンプレートは、これらのアクションを実行します。
+ Application Insights アプリケーションを作成します。詳細については、*Amazon CloudWatch Application Insights API リファレンス*の「[CreateApplication](https://docs.aws.amazon.com/cloudwatch/latest/APIReference/API_CreateApplication.html)」を参照してください。
+ Component `my_component` は `ComponentConfigurationMode` を `CUSTOM` に設定します。これにより、このコンポーネントは `CustomComponentConfiguration` で指定された設定で設定されます。詳細については、*Amazon CloudWatch Application Insights API リファレンス*の「[UpdateComponentConfiguration](https://docs.aws.amazon.com/cloudwatch/latest/APIReference/API_UpdateComponentConfiguration.html)」を参照してください。
**JSON 形式のテンプレート**
```
{
"Type": "AWS::ApplicationInsights::Application",
"Properties": {
"ResourceGroupName": "my_resource_group,
"ComponentMonitoringSettings": [
{
"ComponentARN": "my_component",
"Tier": "SQL_SERVER",
"ComponentConfigurationMode": "CUSTOM",
"CustomComponentConfiguration": {
"ConfigurationDetails": {
"AlarmMetrics": [
{
"AlarmMetricName": "StatusCheckFailed"
},
...
],
"Logs": [
{
"LogGroupName": "my_log_group_1",
"LogPath": "C:\\LogFolder_1\\*",
"LogType": "DOT_NET_CORE",
"Encoding": "utf-8",
"PatternSet": "my_pattern_set_1"
},
...
],
"WindowsEvents": [
{
"LogGroupName": "my_windows_event_log_group_1",
"EventName": "Application",
"EventLevels": [
"ERROR",
"WARNING",
...
],
"Encoding": "utf-8",
"PatternSet": "my_pattern_set_2"
},
...
],
"Alarms": [
{
"AlarmName": "my_alarm_name",
"Severity": "HIGH"
},
...
]
},
"SubComponentTypeConfigurations": [
{
"SubComponentType": "EC2_INSTANCE",
"SubComponentConfigurationDetails": {
"AlarmMetrics": [
{
"AlarmMetricName": "DiskReadOps"
},
...
],
"Logs": [
{
"LogGroupName": "my_log_group_2",
"LogPath": "C:\\LogFolder_2\\*",
"LogType": "IIS",
"Encoding": "utf-8",
"PatternSet": "my_pattern_set_3"
},
...
],
"processes" : [
{
"processName" : "my_process",
"alarmMetrics" : [
{
"alarmMetricName" : "procstat cpu_usage",
"monitor" : true
}, {
"alarmMetricName" : "procstat memory_rss",
"monitor" : true
}
]
}
],
"WindowsEvents": [
{
"LogGroupName": "my_windows_event_log_group_2",
"EventName": "Application",
"EventLevels": [
"ERROR",
"WARNING",
...
],
"Encoding": "utf-8",
"PatternSet": "my_pattern_set_4"
},
...
]
}
}
]
}
}
]
}
}
```
**YAML 形式のテンプレート**
```
---
Type: AWS::ApplicationInsights::Application
Properties:
ResourceGroupName: my_resource_group
ComponentMonitoringSettings:
- ComponentARN: my_component
Tier: SQL_SERVER
ComponentConfigurationMode: CUSTOM
CustomComponentConfiguration:
ConfigurationDetails:
AlarmMetrics:
- AlarmMetricName: StatusCheckFailed
...
Logs:
- LogGroupName: my_log_group_1
LogPath: C:\LogFolder_1\*
LogType: DOT_NET_CORE
Encoding: utf-8
PatternSet: my_pattern_set_1
...
WindowsEvents:
- LogGroupName: my_windows_event_log_group_1
EventName: Application
EventLevels:
- ERROR
- WARNING
...
Encoding: utf-8
PatternSet: my_pattern_set_2
...
Alarms:
- AlarmName: my_alarm_name
Severity: HIGH
...
SubComponentTypeConfigurations:
- SubComponentType: EC2_INSTANCE
SubComponentConfigurationDetails:
AlarmMetrics:
- AlarmMetricName: DiskReadOps
...
Logs:
- LogGroupName: my_log_group_2
LogPath: C:\LogFolder_2\*
LogType: IIS
Encoding: utf-8
PatternSet: my_pattern_set_3
...
Processes:
- ProcessName: my_process
AlarmMetrics:
- AlarmMetricName: procstat cpu_usage
...
...
WindowsEvents:
- LogGroupName: my_windows_event_log_group_2
EventName: Application
EventLevels:
- ERROR
- WARNING
...
Encoding: utf-8
PatternSet: my_pattern_set_4
...
```
## `DEFAULT` モードのコンポーネント設定を使用した Application Insights アプリケーションの作成
次のテンプレートは、これらのアクションを実行します。
+ Application Insights アプリケーションを作成します。詳細については、*Amazon CloudWatch Application Insights API リファレンス*の「[CreateApplication](https://docs.aws.amazon.com/cloudwatch/latest/APIReference/API_CreateApplication.html)」を参照してください。
+ コンポーネント `my_component` は、`ComponentConfigurationMode` を `DEFAULT` に設定し、`Tier` を `SQL_SERVER` に設定します。これにより、このコンポーネントは、Application Insights が `SQL_Server` 層の推奨される構成設定を使用して構成されます。詳細については、*Amazon CloudWatch Application Insights API リファレンス*の「[DescribeComponentConfiguration](https://docs.aws.amazon.com/cloudwatch/latest/APIReference/API_DescribeComponentConfiguration.html)」と「[UpdateComponentConfiguration](https://docs.aws.amazon.com/cloudwatch/latest/APIReference/API_UpdateComponentConfiguration.html)」を参照してください。
**JSON 形式のテンプレート**
```
{
"Type": "AWS::ApplicationInsights::Application",
"Properties": {
"ResourceGroupName": "my_resource_group",
"ComponentMonitoringSettings": [
{
"ComponentARN": "my_component",
"Tier": "SQL_SERVER",
"ComponentConfigurationMode": "DEFAULT"
}
]
}
}
```
**YAML 形式のテンプレート**
```
---
Type: AWS::ApplicationInsights::Application
Properties:
ResourceGroupName: my_resource_group
ComponentMonitoringSettings:
- ComponentARN: my_component
Tier: SQL_SERVER
ComponentConfigurationMode: DEFAULT
```
## `DEFAULT_WITH_OVERWRITE` モードのコンポーネント設定を使用した Application Insights アプリケーションの作成
次のテンプレートは、これらのアクションを実行します。
+ Application Insights アプリケーションを作成します。詳細については、*Amazon CloudWatch Application Insights API リファレンス*の「[CreateApplication](https://docs.aws.amazon.com/cloudwatch/latest/APIReference/API_CreateApplication.html)」を参照してください。
+ コンポーネント `my_component` は、`ComponentConfigurationMode` を `DEFAULT_WITH_OVERWRITE` に設定し、`tier` を `DOT_NET_CORE` に設定します。これにより、このコンポーネントは、Application Insights が `DOT_NET_CORE` 層の推奨される構成設定を使用して構成されます。上書きする構成設定は、`DefaultOverwriteComponentConfiguration` で指定します。
+ コンポーネントレベルでは、`AlarmMetrics` 設定が上書きされます。
+ サブコンポーネントレベルでは、`EC2_Instance` タイプのサブコンポーネントで `Logs` 設定が上書きされます。
詳細については、*Amazon CloudWatch Application Insights API リファレンス*の「[UpdateComponentConfiguration](https://docs.aws.amazon.com/cloudwatch/latest/APIReference/API_UpdateComponentConfiguration.html)」を参照してください。
**JSON 形式のテンプレート**
```
{
"Type": "AWS::ApplicationInsights::Application",
"Properties": {
"ResourceGroupName": "my_resource_group",
"ComponentMonitoringSettings": [
{
"ComponentName": "my_component",
"Tier": "DOT_NET_CORE",
"ComponentConfigurationMode": "DEFAULT_WITH_OVERWRITE",
"DefaultOverwriteComponentConfiguration": {
"ConfigurationDetails": {
"AlarmMetrics": [
{
"AlarmMetricName": "StatusCheckFailed"
}
]
},
"SubComponentTypeConfigurations": [
{
"SubComponentType": "EC2_INSTANCE",
"SubComponentConfigurationDetails": {
"Logs": [
{
"LogGroupName": "my_log_group",
"LogPath": "C:\\LogFolder\\*",
"LogType": "IIS",
"Encoding": "utf-8",
"PatternSet": "my_pattern_set"
}
]
}
}
]
}
}
]
}
}
```
**YAML 形式のテンプレート**
```
---
Type: AWS::ApplicationInsights::Application
Properties:
ResourceGroupName: my_resource_group
ComponentMonitoringSettings:
- ComponentName: my_component
Tier: DOT_NET_CORE
ComponentConfigurationMode: DEFAULT_WITH_OVERWRITE
DefaultOverwriteComponentConfiguration:
ConfigurationDetails:
AlarmMetrics:
- AlarmMetricName: StatusCheckFailed
SubComponentTypeConfigurations:
- SubComponentType: EC2_INSTANCE
SubComponentConfigurationDetails:
Logs:
- LogGroupName: my_log_group
LogPath: C:\LogFolder\*
LogType: IIS
Encoding: utf-8
PatternSet: my_pattern_set
```
# チュートリアル: SAP ASE のモニタリングをセットアップする
このチュートリアルでは、SAP ASE データベースのモニタリングをセットアップできるよう CloudWatch Application Insights を設定する方法を説明します。CloudWatch Application Insights の自動ダッシュボードを使用して、問題の詳細を可視化し、トラブルシューティングを加速させ、SAP ASE データベースでの解決までの平均時間 (MTTR) を短縮できます。
**Topics**
+ [
## サポートされている環境
](#appinsights-tutorial-sap-ase-supported-environments)
+ [
## サポートされるオペレーティングシステム
](#appinsights-tutorial-sap-ase-supported-os)
+ [
## 機能
](#appinsights-tutorial-sap-ase-features)
+ [
## 前提条件
](#appinsights-tutorial-sap-ase-prerequisites)
+ [モニターリングの設定](#appinsights-tutorial-sap-ase-set-up)
+ [モニターリングの管理](#appinsights-tutorial-sap-ase-manage)
+ [
## アラームのしきい値を設定する
](#appinsights-tutorial-sap-hana-configure-alarm-threshold)
+ [
## Application Insights で検出された SAP ASE における問題の表示とトラブルシューティング
](#appinsights-tutorial-sap-ase-troubleshooting-problems)
+ [Application Insights のトラブルシューティング](#appinsights-tutorial-sap-ase-troubleshooting-health-dashboard)
## サポートされている環境
CloudWatch Application Insights では、次のシステムおよびパターン用に AWS リソースのデプロイがサポートされています。SAP ASE データベースソフトウェアおよびサポートされている SAP アプリケーションソフトウェアを指定してインストールします。
+ **単一の Amazon EC2 インスタンスでの 1 つ以上の SAP ASE データベース** — 単一ノードのスケールアップアーキテクチャの SAP ASE。
+ **クロス AZ SAP ASE データベースの高可用性セットアップ** — SUSE/RHEL クラスタリングにより 2 つのアベイラビリティーゾーンでの高可用性が設定されている SAP ASE。
**注記**
CloudWatch Application Insights は、単一の SAP システム ID (SID) の ASE HA 環境のみをサポートしています。複数の ASE HA SID がアタッチされている場合、最初に検出された SID に対してのみモニタリングがセットアップされます。
## サポートされるオペレーティングシステム
SAP ASE 向けの CloudWatch Application Insights は、次のオペレーティングシステム上で x86-64 アーキテクチャをサポートしています。
+ SuSE Linux 12 SP4
+ SuSE Linux 12 SP5
+ SuSE Linux 15
+ SuSE Linux 15 SP1
+ SuSE Linux 15 SP2
+ SuSE Linux 15 SP3
+ SuSE Linux 15 SP4
+ SuSE Linux 15 SP1 For SAP
+ SuSE Linux 15 SP2 For SAP
+ SuSE Linux 15 SP3 For SAP
+ SuSE Linux 15 SP4 For SAP
+ SuSE Linux 12 SP4 For SAP
+ SuSE Linux 12 SP5 For SAP
+ RedHat Linux 7.6
+ RedHat Linux 7.7
+ RedHat Linux 7.9
+ RedHat Linux 8.1
+ RedHat Linux 8.4
+ RedHat Linux 8.6
## 機能
SAP ASE 向けの CloudWatch Application Insights には、次の機能があります。
+ SAP ASE ワークロードの自動検出
+ 静的しきい値に基づく SAP ASE アラームの自動作成
+ 異常検出に基づく SAP ASE アラームの自動作成
+ SAP ASE のログパターンの自動認識
+ SAP ASE 用のヘルスダッシュボード
+ SAP ASE 用の問題ダッシュボード
## 前提条件
CloudWatch Application Insights で SAP ASE データベースを設定するには、次の前提条件を実行する必要があります。
+ **SAP ASE 設定パラメータ** — ASE データベースで、設定パラメータ `"enable monitoring"`、`"sql text pipe max messages"`、`"sql text pipe active"` を有効にする必要があります。これにより、CloudWatch Application Insights でデータベース用の完全なモニタリング機能が提供されます。ASE データベースでこれらの設定が有効になっていない場合、Application Insights ではモニタリングに必要なメトリクスを収集できるよう、これらが自動的に有効になります。
+ **SAP ASE データベースユーザー** — Application Insights のオンボーディング時に提供されるデータベースユーザーには、次にアクセスするためのアクセス許可が必要です。
+ マスターデータベースとユーザー (テナント) データベースのシステムテーブル
+ モニタリングテーブル
+ **SAPHostCtrl** — Amazon EC2 インスタンスで SAPHostCtrl をインストールおよびセットアップします。
+ **Amazon CloudWatch エージェント** — Amazon EC2 インスタンスで既存の CloudWatch エージェントが実行されていないことを確認します。CloudWatch エージェントがインストールされている場合は、マージ競合を避けるために、既存の CloudWatch エージェント設定ファイルから CloudWatch Application Insights で使用しているリソースの設定を削除するようにしてください。詳細については、「[CloudWatch エージェント設定ファイルを手動で作成または編集する](CloudWatch-Agent-Configuration-File-Details.md)」を参照してください。
+ **AWS Systems Manager の有効化** — インスタンスに SSM Agent をインストールし、SSM に対して有効なインスタンスを有効にします。SSM Agent のインストールについての詳細は、*AWS Systems Manager ユーザーガイド*の「[SSM Agent の使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html)」を参照してください。
+ **Amazon EC2 インスタンスロール** — 次の Amazon EC2 インスタンスロールをアタッチして、データベースを設定する必要があります。
+ Systems Manager を有効にする `AmazonSSMManagedInstanceCore` ロールをアタッチする必要があります。詳細については、「[AWS Systems Manager アイデンティティベースのポリシーの例](https://docs.aws.amazon.com/systems-manager/latest/userguide/auth-and-access-control-iam-identity-based-access-control.html)」を参照してください。
+ インスタンスメトリクスとログが CloudWatch を介して発行されるように `CloudWatchAgentServerPolicy` をアタッチする必要があります。詳細については、「[CloudWatch エージェントで使用する IAM ロールとユーザーを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-iam-roles-for-cloudwatch-agent.html)」を参照してください。
+ AWS Secrets Manager に保存されているパスワードを読み取るには、次の IAM インラインポリシーを Amazon EC2 インスタンスロールにアタッチする必要があります。インラインポリシーの詳細については、*AWS Identity and Access Management ユーザーガイド*の「[インラインポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": "arn:aws:secretsmanager:*:*:secret:ApplicationInsights-*"
}
]
}
```
------
+ **AWS Resource Groups** — アプリケーションを CloudWatch Application Insights にオンボードするには、アプリケーションスタックで使用されるすべての関連する AWS リソースを含むリソースグループを作成する必要があります。これには、SAP ASE データベースを実行する Amazon EC2 インスタンスと Amazon EBS ボリュームが含まれます。1 つのアカウントに複数のデータベースがある場合は、各 SAP ASE データベースシステムの AWS リソースを含む 1 つのリソースグループを作成することをお勧めします。
+ **IAM アクセス許可** — 管理者以外のユーザーの場合:
+ Application Insights でサービスにリンクされたロールを作成できる AWS Identity and Access Management (IAM) ポリシーを作成し、ユーザー ID にアタッチする必要があります。ポリシーをアタッチする手順については、「[CloudWatch Application Insights の IAM ポリシー](appinsights-iam.md)」を参照してください。
+ ユーザーには、AWS Secrets Manager でシークレットを作成し、データベースのユーザー認証情報を保存するためのアクセス許可が必要です。詳細については、「[例: シークレット値を取得するアクセス許可](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples.html#auth-and-access_examples_create)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:CreateSecret"
],
"Resource": "arn:aws:secretsmanager:*:*:secret:ApplicationInsights-*"
}
]
}
```
------
+ **サービスにリンクされたロール** – Application Insights は AWS Identity and Access Management (IAM) サービスにリンクされたロールを使用します。Application Insights コンソールで新しい Application Insights アプリケーションを作成する際、サービスにリンクされたロールが作成されます。詳細については、「[CloudWatch Application Insights のサービスにリンクされたロールの使用](CHAP_using-service-linked-roles-appinsights.md)」を参照してください。
## SAP ASE データベースをモニタリング用にセットアップする
SAP ASE データベースのモニタリングをセットアップするには、次の手順を実行します。
1. [CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch)を開きます。
1. 左側のナビゲーションペインで、**[Insights]** の下にある **[Application Insights]** を選択します。
1. **[Application Insights]** ページには、Application Insights でモニターリングするアプリケーションのリストと、各アプリケーションのモニターリングのステータスが表示されます。右上隅の **[Add an application]** (アプリケーションの追加) を選択します。
1. **[アプリケーションの詳細を指定]** ページで、**[リソースグループ]** のドロップダウンリストから SAP ASE データベースのリソースを含む AWS リソースグループを選択します。アプリケーションのリソースグループを作成していない場合は、**[Resource group]** (リソースグループ) のドロップダウンから、**[Create new resource group]** (新しいリソースグループの作成) を選択して作成できます。リソースグループの作成についての詳細は、[https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html)を参照してください。
1. **[Monitor CloudWatch Events]** (CloudWatch Events のモニタリング) で、CloudWatch Events と Application Insights のモニタリングを統合できるチェックボックスをオンにすると、Amazon EBS、Amazon EC2、AWS CodeDeploy、Amazon ECS、AWS Health APIs And Notifications、Amazon RDS、Amazon S3、および AWS Step Functions からのインサイトを取得できます。
1. 選択したアプリケーションの問題が検出されたときにそれらを表示し、通知を受け取るには、**[AWS Systems Manager OpsCenter と統合する]** にある **[修正アクションのため AWS Systems Manager OpsCenter OpsItems を生成する]** 横のチェックボックスをオンにします。AWS リソースに関連する OpsItems というオペレーション作業項目を解決するために実行されたオペレーションを追跡するには、SNS トピックの ARN を指定します。
1. オプションでタグを入力して、リソースを特定し整理できます。CloudWatch Application Insights では、タグベースのリソースグループと CloudFormation スタックベースのリソースグループ (Application Auto Scaling グループを除く) の両方がサポートされています。詳細については、*AWS Resource Groups とタグユーザーガイド*の「[Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html)」を参照してください。
1. **[Next]** (次へ) を選択してモニターリングの設定を続行します。
1. **[検出されたコンポーネントを確認]** ページには、CloudWatch Application Insights によって自動的に検出されたモニターリング対象のコンポーネントとそれらのワークロードが一覧表示されます。
**注記**
検出された SAP ASE High Availability ワークロードを含むコンポーネントは、1 つのコンポーネントで 1 つのワークロードのみをサポートします。検出された SAP ASE 単一ノードワークロードを含むコンポーネントは複数のワークロードをサポートしますが、ワークロードを追加したり削除することはできません。自動的に検出されたワークロードはすべてモニタリングされます。
1. [**次へ**] を選択します。
1. **[コンポーネントの詳細を指定]** ページで、SAP ASE データベースのユーザー名とパスワードを入力します。
1. アプリケーションのモニターリング設定を確認し **[Submit]** (送信) をクリックします。
1. アプリケーション詳細ページが開き、**[アプリケーションの概要]** および **[モニタリング対象コンポーネントとワークロード]** と **[モニタリング対象ではないコンポーネントとワークロード]** のリストを表示できます。コンポーネントまたはワークロードの横にあるラジオボタンをオンにすると、**[設定履歴]**、**[ログパターン]** 、および作成した**タグ**も表示できます。設定を送信すると、アカウントで SAP ASE システムのすべてのメトリクスとアラームがデプロイされます。これには最大 2 時間かかります。
## SAP ASE データベースのモニタリングの管理
次の手順を実行して、SAP ASE データベースのユーザー認証情報、メトリクス、およびログパスを管理できます。
1. [CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch)を開きます。
1. 左側のナビゲーションペインで、**[Insights]** の下にある **[Application Insights]** を選択します。
1. **[Application Insights]** ページには、Application Insights でモニターリングするアプリケーションのリストと、各アプリケーションのモニターリングのステータスが表示されます。
1. **[Monitored components]** (モニターリングされているコンポーネント) で、コンポーネント名の横にあるラジオボタンをオンにします。次に、**[Manage monitoring]** (モニターリングの管理) を選択します。
1. **[EC2 instance group logs]** (EC2 インスタンスグループのログ) では、既存のログパス、ログパターンのセット、ロググループ名を更新できます。さらに、追加で **Application logs** (アプリケーションログ) を最大 3 つまで追加できます。
1. **[メトリクス]** では、要件に応じて SAP ASE メトリクスを選択できます。SAP ASE のメトリクス名は、`asedb` で始まります。コンポーネントごとに最大 60 個のメトリクスを追加できます。
1. **[ASE の設定]** で、SAP ASE データベースのユーザー名とパスワードを入力します。これらは、Amazon CloudWatch エージェントが SAP ASE データベースに接続するために使用するユーザー名とパスワードです。
1. **[Custom alarms]** (カスタムアラーム) では、CloudWatch Application Insights によってモニターリングするアラームを追加できます。
1. アプリケーションのモニターリング設定を確認し、**[Submit]** (送信) をクリックします。設定を送信すると、アカウントで SAP HANA システムのすべてのメトリクスとアラームが更新されます。これには最大 2 時間かかります。
## アラームのしきい値を設定する
CloudWatch Application Insights では、メトリクスのしきい値とともに監視するアラームの Amazon CloudWatch メトリクスが自動的に作成されます。指定した評価期間数にわたってメトリクスがしきい値を超えると、アラームは `ALARM ` 状態に変わります。これらの設定は、Application Insights では保持されないことに注意してください。
単一のメトリクスのアラームを編集するには、次の手順を実行します。
1. [CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch)を開きます。
1. ナビゲーションペインで、**[Alarms]** (アラーム)、**[All alarms]** (すべてのアラーム) の順に選択します。
1. CloudWatch Application Insights によって自動的に作成されたアラームの横にあるラジオボタンをオンにします。次に **[Actions]** (アクション) を選択し、ドロップダウンメニューから **[Edit]** (編集)を選択します。
1. **[Metrics]** (メトリクス) で次のパラメータを編集します。
1. **[Statistic]** (統計) で、統計または事前定義済みのパーセンタイルのいずれかを選択するか、カスタムパーセンタイルを指定します。例えば、`p95.45`。
1. **[Period]** (期間) で、アラームの評価期間を選択します。アラームを評価する際、各期間は 1 つのデータポイントに集約されます。
1. **[Conditions]** (条件) で次のパラメータを編集します。
1. メトリクスがしきい値より大きい、小さい、またはしきい値と等しいのいずれかを指定します。
1. しきい値を指定します。
1. **[Additional configuration]** (追加設定) で、次のパラメータを編集します。
1. **[Datapoints to alarm]** (アラームを実行するデータポイント) で、評価期間またはデータポイントの数を指定します。アラームを開始するため、`ALARM` 状態である必要があります。2 つの値が一致するとアラームが作成され、指定された連続する期間数を超過した場合、`ALARM` 状態に入ります。`n` 個中 `m` 個のアラームを作成するには、2 番目の値よりも小さい数字を最初の値に指定します。アラームの評価の詳細については、「[アラームの評価](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Alarms.html#alarm-evaluation)」を参照してください。
1. **[Missing data treatment]** (欠落データの処理) で、一部のデータポイントが欠落しているときのアラームの動作を選択します。欠落データの処理についての詳細は、「[CloudWatch アラームの欠落データの処理の設定](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Alarms.html#alarms-and-missing-data)」を参照してください。
1. モニターリングする統計としてパーセンタイルをアラームで使用している場合は、[**サンプル数が少ないパーセンタイル**] ボックスが表示されます。サンプル数が少ないケースを評価するか無視するかを選択します。[**無視 (アラーム状態を維持する)**] を選択すると、サンプル数が少なすぎる場合でも現在のアラーム状態が常に維持されます。サンプルが少ないパーセンタイルの詳細については、「[パーセンタイルベースのアラームおよび少数のデータサンプル](percentiles-with-low-samples.md)」を参照してください。
1. [**次へ**] を選択します。
1. [**通知**] で、アラームが `ALARM` 状態、`OK` 状態、または `INSUFFICIENT_DATA` 状態のときに通知するための SNS トピックを選択します。
1. **[Update alarm]** (アラームの更新) を選択します。
## Application Insights で検出された SAP ASE における問題の表示とトラブルシューティング
このセクションは、Application Insights で SAP ASE のモニタリングを設定する際に発生する一般的なトラブルシューティングの問題を解決するのに役立ちます。
**SAP ASE Backup Server エラー**
エラーメッセージは、動的に作成されたダッシュボードを確認することで確認できます。ダッシュボードには、SAP ASE Backup Server で報告されたエラーメッセージが表示されます。SAP ASE Backup Server ログの詳細については、SAP ドキュメントの「[Backup Server のエラーロギング](https://help.sap.com/docs/SAP_ASE/aa939a27edb34f019f71cc47b9c0fd9a/a7aeb8b1bc2b10149ccf99b95687a64c.html)」を参照してください。
**SAP ASE のトランザクションの実行時間が長い**
長時間実行されているトランザクションを特定し、停止できるのか、または実行時間が計画的なものかを確認します。詳細については、「[2180410 - How to display transaction log records for long running transactions? - SAP ASE](https://userapps.support.sap.com/sap/support/knowledge/en/2180410)」を参照してください。
**SAP ASE User 接続**
SAP ASE データベースが、データベースで実行する予定のワークロードに適したサイズになっているかどうかを確認します。詳細については、SAP ドキュメントの「[Configuring User Connections](https://help.sap.com/docs/help/061ec8a5739842df9e505d8944fae8e2/9ea258fceaaa496eb80e17d3d5694ff6.html)」を参照してください。
**SAP ASE のディスク容量**
動的に作成されるダッシュボードを確認することで、問題が起きているデータベース層を特定できます。ダッシュボードには、関連するメトリクスやログファイルのスニペットが表示されます。ディスク増大の原因を理解し、該当する場合は物理ディスクサイズ、割り当てられたディスク容量、またはその両方を増やすことが重要です。詳細については、SAP ドキュメントの「[disk resize](https://help.sap.com/docs/SAP_ASE/e0d4539d39c34f52ae9ef822c2060077/ab22db00bc2b1014ad3ce047bbf117d7.html)」を参照してください。
## SAP ASE 向けの Application Insights のトラブルシューティング
このセクションでは、Application Insights ダッシュボードから返される一般的なエラーを解決するための手順について説明します。
| エラー | 返されたエラー | 根本原因 | 解決策 |
| --- | --- | --- | --- |
| 60 を超えるモニタリングメトリクスは追加できません。 | `Component cannot have more than 60 monitored metric` | 現在のメトリクスの上限は、コンポーネントごとに 60 個です。 | 制限を守るのに必要のないメトリクスは削除してください。 |
| オンボーディングプロセスの後、SAP メトリクスやアラームは表示されません | AWS Systems Manager で `AWS-ConfigureAWSPackage` の `run` コマンドが失敗しました。出力では、次のエラーが表示されます: `CT-LIBRARY error:``ct_connect(): protocol specific layer: external error: The attempt to connect to the server failed` | ユーザー名とパスワードが間違っている可能性があります。 | ユーザー名とパスワードが有効であることを確認し、その後オンボーディングプロセスに戻ってください。 |
# チュートリアル: SAP HANA のモニターリングを設定する
このチュートリアルでは、SAP HANA データベースのモニターリングを設定できるよう CloudWatch Application Insights を設定する方法を説明します。CloudWatch Application Insights の自動ダッシュボードを使用して、問題の詳細を可視化し、トラブルシューティングを加速させ、SAP HANA データベースでの解決までの平均時間 (MTTR) を短縮できます。
**Topics**
+ [
## サポートされている環境
](#appinsights-tutorial-sap-hana-supported-environments)
+ [
## サポートされるオペレーティングシステム
](#appinsights-tutorial-sap-hana-supported-os)
+ [
## 機能
](#appinsights-tutorial-sap-hana-features)
+ [
## 前提条件
](#appinsights-tutorial-sap-hana-prerequisites)
+ [モニターリングの設定](#appinsights-tutorial-sap-hana-set-up)
+ [モニターリングの管理](#appinsights-tutorial-sap-hana-manage)
+ [検出された問題のトラブルシューティング](#appinsights-tutorial-sap-hana-troubleshooting)
+ [異常検出](#appinsights-tutorial-sap-hana-troubleshooting-anomaly-detection)
+ [Application Insights のトラブルシューティング](#appinsights-tutorial-sap-hana-troubleshooting-health-dashboard)
## サポートされている環境
CloudWatch Application Insights では、次のシステムおよびパターン用に AWS リソースのデプロイがサポートされています。SAP HANA データベースソフトウェアおよびサポートされている SAP アプリケーションソフトウェアを指定してインストールします。
+ **単一の Amazon EC2 インスタンスでの SAP HANA データベース** ― シングルノードのスケールアップアーキテクチャにおける SAP HANA で、メモリは最大 24 TB です。
+ **複数の Amazon EC2 インスタンスでの SAP HANA データベース** ― マルチノードのスケールアウトアーキテクチャにおける SAP HANA です。
+ **クロス AZ SAP HANA データベースの高可用性セットアップ** ― SUSE/RHEL クラスタリングにより 2 つのアベイラビリティーゾーンでの高可用性が設定されている SAP HANA。
**注記**
CloudWatch Application Insights は、単一の SID HANA 環境のみをサポートしています。複数の HANA SID がアタッチされている場合、最初に検出された SID に対してのみモニターリングがセットアップされます。
## サポートされるオペレーティングシステム
SAP HANA 向けの CloudWatch Application Insights は、次のオペレーティングシステム上で x86-64 アーキテクチャをサポートしています。
+ SuSE Linux 12 SP4 For SAP
+ SuSE Linux 12 SP5 For SAP
+ SuSE Linux 15
+ SuSE Linux 15 SP1
+ SuSE Linux 15 SP2
+ SuSE Linux 15 For SAP
+ SuSE Linux 15 SP1 For SAP
+ SuSE Linux 15 SP2 For SAP
+ SuSE Linux 15 SP3 For SAP
+ SuSE Linux 15 SP4 For SAP
+ SuSE Linux 15 SP5 For SAP
+ RedHat Linux 8.6 For SAP With High Availability and Update Services
+ RedHat Linux 8.5 For SAP With High Availability and Update Services
+ RedHat Linux 8.4 For SAP With High Availability and Update Services
+ RedHat Linux 8.3 For SAP With High Availability and Update Services
+ RedHat Linux 8.2 For SAP With High Availability and Update Services
+ RedHat Linux 8.1 For SAP With High Availability and Update Services
+ RedHat Linux 7.9 For SAP With High Availability and Update Services
## 機能
SAP HANA 向けの CloudWatch Application Insights には、次の機能があります。
+ SAP HANA ワークロードの自動検出
+ 静的しきい値に基づく SAP HANA アラームの自動作成
+ 異常検出に基づく SAP HANA アラームの自動作成
+ SAP HANA のログパターンの自動認識
+ SAP HANA 用のヘルスダッシュボード
+ SAP HANA 用の問題ダッシュボード
## 前提条件
CloudWatch Application Insights で SAP HANA データベースを設定するには、次の前提条件を実行する必要があります。
+ **SAP HANA** – 実行中およびアクセス可能な SAP HANA データベース 2.0 SPS05 を Amazon EC2 インスタンスにインストールします。
+ **SAP HANA データベースユーザー** – モニタリングロールを持つデータベースユーザーを、SYSTEM データベースとすべてのテナントに作成する必要があります。
**例**
次の SQL コマンドを実行して、モニターリングロールを持つユーザーを作成します。
```
su - adm
hdbsql -u SYSTEM -p -d SYSTEMDB
CREATE USER CW_HANADB_EXPORTER_USER PASSWORD NO FORCE_FIRST_PASSWORD_CHANGE;
CREATE ROLE CW_HANADB_EXPORTER_ROLE;
GRANT MONITORING TO CW_HANADB_EXPORTER_ROLE;
GRANT CW_HANADB_EXPORTER_ROLE TO CW_HANADB_EXPORTER_USER;
```
+ **Python 3.8** – オペレーティングシステムに Python 3.8 以降のバージョンをインストールします。Python の最新リリース版を使用してください。オペレーティングシステムで Python3 が検出されない場合、Python 3.6 がインストールされます。
詳細については、「[installation example](#install)」を参照してください。
**注記**
SuSE Linux 15 SP4、RedHat Linux 8.6、およびそれ以降のオペレーティングシステムには Python 3.8 以降を手動でインストールする必要があります。
+ **Pip3** – インストーラプログラム pip3 をオペレーティングシステムにインストールします。オペレーティングシステムで pip3 が検出されない場合、インストールされます。
+ **hdbclient** — CloudWatch Application Insights は、python ドライバーを使用して SAP HANA データベースに接続します。クライアントが python3 にインストールされていない場合は、hdbclient tar ファイルのバージョン `2.10 or later` が `/hana/shared/SID/hdbclient/` に存在することを確認してください。
+ **Amazon CloudWatch エージェント** — Amazon EC2 インスタンスで既存の CloudWatch エージェントが実行されていないことを確認します。CloudWatch エージェントがインストールされている場合は、マージ競合を避けるために、既存の CloudWatch エージェント設定ファイルから CloudWatch Application Insights で使用しているリソースの設定を削除するようにしてください。詳細については、「[CloudWatch エージェント設定ファイルを手動で作成または編集する](CloudWatch-Agent-Configuration-File-Details.md)」を参照してください。
+ **AWS Systems Manager の有効化** – インスタンスに SSM Agent をインストールし、インスタンスを SSM に対して有効にします。SSM Agent のインストールについての詳細は、「AWS Systems Manager ユーザーガイド」の「[SSM Agent の使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html)」を参照してください。
+ **Amazon EC2 インスタンスロール** — 次の Amazon EC2 インスタンスロールをアタッチして、データベースを設定する必要があります。
+ Systems Manager を有効にする `AmazonSSMManagedInstanceCore` ロールをアタッチする必要があります。詳細については、「[AWS Systems Manager アイデンティティベースのポリシーの例](https://docs.aws.amazon.com/systems-manager/latest/userguide/auth-and-access-control-iam-identity-based-access-control.html)」を参照してください。
+ インスタンスメトリクスとログが CloudWatch を介して発行されるように `CloudWatchAgentServerPolicy` をアタッチする必要があります。詳細については、「[CloudWatch エージェントで使用する IAM ロールとユーザーを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-iam-roles-for-cloudwatch-agent.html)」を参照してください
+ AWS Secrets Manager に保存されているパスワードを読み取るには、次の IAM インラインポリシーを Amazon EC2 インスタンスロールにアタッチする必要があります。インラインポリシーの詳細については、*AWS Identity and Access Management ユーザーガイド*の「[インラインポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": "arn:aws:secretsmanager:*:*:secret:ApplicationInsights-*"
}
]
}
```
------
+ **AWS リソースグループ** – アプリケーションを CloudWatch Application Insights にオンボードするには、アプリケーションスタックで使用されるすべての関連する AWS リソースを含むリソースグループを作成する必要があります。これには、SAP HANA データベースを実行する Amazon EC2 インスタンスと Amazon EBS ボリュームが含まれます。1 つのアカウントに複数のデータベースがある場合は、各 SAP HANA データベースシステムの AWS リソースを含む 1 つのリソースグループを作成することをお勧めします。
+ **IAM アクセス許可** — 管理者以外のユーザーの場合:
+ Application Insights でサービスにリンクされたロールを作成できる AWS Identity and Access Management (IAM) ポリシーを作成し、ユーザー ID にアタッチする必要があります。ポリシーをアタッチする手順については、「[CloudWatch Application Insights の IAM ポリシー](appinsights-iam.md)」を参照してください。
+ ユーザーには、AWS Secrets Manager でシークレットを作成し、データベースのユーザー認証情報を保存するためのアクセス許可が必要です。詳細については、「[例: シークレット値を取得するアクセス許可](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples.html#auth-and-access_examples_create)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:CreateSecret"
],
"Resource": "arn:aws:secretsmanager:*:*:secret:ApplicationInsights-*"
}
]
}
```
------
+ **サービスにリンクされたロール** – Application Insights は AWS Identity and Access Management (IAM) サービスにリンクされたロールを使用します。Application Insights コンソールで新しい Application Insights アプリケーションを作成する際、サービスにリンクされたロールが作成されます。詳細については、「[CloudWatch Application Insights のサービスにリンクされたロールの使用](CHAP_using-service-linked-roles-appinsights.md)」を参照してください。
## SAP HANA データベースをモニターリング用に設定する
SAP HANA データベースのモニターリングをセットアップするには、以下の手順を実行します。
1. [CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch)を開きます。
1. 左側のナビゲーションペインで、**[Insights]** の下にある **[Application Insights]** を選択します。
1. **[Application Insights]** ページには、Application Insights でモニターリングするアプリケーションのリストと、各アプリケーションのモニターリングのステータスが表示されます。右上隅の **[Add an application]** (アプリケーションの追加) を選択します。
1. **[Specify application details]** (アプリケーションの詳細の指定) ページで、**[Resource group]** (リソースグループ) のドロップダウンリストから SAP HANA データベースのリソースを含む AWS リソースグループを選択します。アプリケーションのリソースグループを作成していない場合は、**[Resource group]** (リソースグループ) のドロップダウンから、**[Create new resource group]** (新しいリソースグループの作成) を選択して作成できます。リソースグループの作成についての詳細は、[https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html)を参照してください。
1. **[Monitor CloudWatch Events]** (CloudWatch Events のモニタリング) で、CloudWatch Events と Application Insights のモニタリングを統合できるチェックボックスをオンにすると、Amazon EBS、Amazon EC2、AWS CodeDeploy、Amazon ECS、AWS Health APIs And Notifications、Amazon RDS、Amazon S3、および AWS Step Functions からのインサイトを取得できます。
1. 選択したアプリケーションの問題が検出されたときにそれらを表示し、通知を受け取るには、**[AWS Systems Manager OpsCenter と統合する]** にある **[修正アクションのため AWS Systems Manager OpsCenter OpsItems を生成する]** 横のチェックボックスをオンにします。AWS リソースに関連する OpsItems というオペレーション作業項目を解決するために実行されたオペレーションを追跡するには、SNS トピックの ARN を指定します。
1. オプションでタグを入力して、リソースを特定し整理できます。CloudWatch Application Insights では、タグベースのリソースグループと CloudFormation スタックベースのリソースグループ (Application Auto Scaling グループを除く) の両方がサポートされています。詳細については、*AWS Resource Groups とタグユーザーガイド*の「[Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html)」を参照してください。
1. **[Next]** (次へ) を選択してモニターリングの設定を続行します。
1. **[検出されたコンポーネントを確認]** ページには、CloudWatch Application Insights によって自動的に検出されたモニターリング対象のコンポーネントとそれらのワークロードが一覧表示されます。
1. 検出された SAP HANA 単一ノードワークロードを含むコンポーネントにワークロードを追加するには、コンポーネントを選択し **[コンポーネントを編集]** を選択します。
**注記**
検出された SAP HANA マルチノードまたは HANA 高可用性ワークロードを含むコンポーネントは、1 つのコンポーネントで 1 つのワークロードのみをサポートします。
![\[CloudWatch Application Insights コンソールのモニタリング用コンポーネントの確認ページ: 編集するコンポーネントを選択します。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-multiapp-hana-review.png)
1. 新しいワークロードを追加するには、**[新しいワークロードを追加]** を選択します。
![\[CloudWatch Application Insights コンソールのコンポーネント編集セクション: 左下のボタンを選択してワークロードを追加します。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-multiapp-hana-edit.png)
1. ワークロードの編集が完了したら、**[変更の保存]** を選択します。
1. [**次へ**] を選択します。
1. **[コンポーネントの詳細を指定]** ページで、ユーザー名とパスワードを入力します。
1. アプリケーションのモニターリング設定を確認し **[Submit]** (送信) をクリックします。
1. アプリケーション詳細ページが開き、**[アプリケーションの概要]** および **[モニタリング対象コンポーネントとワークロード]** と **[モニタリング対象ではないコンポーネントとワークロード]** のリストを表示できます。コンポーネントまたはワークロードの横にあるラジオボタンをオンにすると、**[設定履歴]**、**[ログパターン]** 、および作成した**タグ**も表示できます。設定を送信すると、アカウントで SAP HANA システムのすべてのメトリクスとアラームがデプロイされます。これには最大 2 時間かかります。
## SAP HANA データベースのモニターリングの管理
次の手順を実行して、SAP HANA データベースのユーザー認証情報、メトリクス、およびログパスを管理できます。
1. [CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch)を開きます。
1. 左側のナビゲーションペインで、**[Insights]** の下にある **[Application Insights]** を選択します。
1. **[Application Insights]** ページには、Application Insights でモニターリングするアプリケーションのリストと、各アプリケーションのモニターリングのステータスが表示されます。
1. **[Monitored components]** (モニターリングされているコンポーネント) で、コンポーネント名の横にあるラジオボタンをオンにします。次に、**[Manage monitoring]** (モニターリングの管理) を選択します。
1. **[EC2 instance group logs]** (EC2 インスタンスグループのログ) では、既存のログパス、ログパターンのセット、ロググループ名を更新できます。さらに、追加で **Application logs** (アプリケーションログ) を最大 3 つまで追加できます。
1. **[Metrics]** (メトリクス) では、要件に応じて SAP HANA メトリクスを選択できます。SAP HANA のメトリクス名は、`hanadb` で始まります。コンポーネントごとに最大 40 個のメトリクスを追加できます。
1. **[HANA configuration]** (HANA の設定) で、SAP HANA データベースのパスワードとユーザー名を入力します。これらは、Amazon CloudWatch エージェントが SAP HANA データベースに接続するために使用されるユーザー名とパスワードです。
1. **[Custom alarms]** (カスタムアラーム) では、CloudWatch Application Insights によってモニターリングするアラームを追加できます。
1. アプリケーションのモニターリング設定を確認し、**[Submit]** (送信) をクリックします。設定を送信すると、アカウントで SAP HANA システムのすべてのメトリクスとアラームが更新されます。これには最大 2 時間かかります。
## CloudWatch Application Insights で検出された SAP HANA における問題の表示とトラブルシューティング
次のセクションでは、Application Insights で SAP HANA のモニターリングを設定する際に発生する一般的なトラブルシューティングのシナリオを解決する手順について説明します。
**Topics**
+ [
### SAP HANA データベースがメモリの割り当て制限に達しました
](#appinsights-tutorial-sap-hana-troubleshooting-memory)
+ [
### ディスクに空き容量がないイベント
](#appinsights-tutorial-sap-hana-troubleshooting-disk-full)
+ [
### SAP HANA バックアップの実行が停止しました
](#appinsights-tutorial-sap-hana-troubleshooting-backup-stopped)
### SAP HANA データベースがメモリの割り当て制限に達しました
**説明**
SAP HANA データベースによりバックアップされている SAP アプリケーションが高いメモリ負荷のために正常に動作せず、アプリケーションのパフォーマンスが低下しています。
**解決策**
動的に作成されるダッシュボードを確認することで、問題を起こしているアプリケーション層を特定できます。ダッシュボードには、関連するメトリクスやログファイルのスニペットが表示されます。次の例では、SAP HANA システムにおける大きなデータロードが問題の原因である可能性があります。
![\[メモリの割り当てが超過しました。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-memory-allocation-1.png)
使用されているメモリの割り当てが、合計のメモリの割り当て制限のしきい値の 80% を超えています。
![\[メモリ不足を示すロググループ。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-memory-allocation-2.png)
ロググループに、メモリ不足のスキーム `BNR-DATA` とテーブル `IMDBMASTER_30003` が表示されます。さらに問題の正確な時刻、現在のグローバルロケーションの制限、共有メモリ、コードサイズ、OOM の予約割り当てサイズが表示されます。
![\[ロググループのテキスト。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-memory-allocation-3.png)
### ディスクに空き容量がないイベント
**説明**
SAP HANA データベースによってバックアップされている SAP アプリケーションが応答を停止し、データベースにアクセスできません。
**解決策**
動的に作成されるダッシュボードを確認することで、問題が起きているデータベース層を特定できます。ダッシュボードには、関連するメトリクスやログファイルのスニペットが表示されます。次の例では、管理者が自動ログバックアップを有効にできなかったため、sap/hana/log ディレクトリがいっぱいになったことが問題である可能性があります。
![\[メモリ不足を示すロググループ。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-disk-full-1.png)
問題のあるダッシュボードのロググループのウィジェットには、`DISKFULL` イベントが表示されます。
![\[メモリ不足を示すロググループ。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-disk-full-2.png)
### SAP HANA バックアップの実行が停止しました
**説明**
SAP HANA データベースによってバックアップされている SAP アプリケーションが停止しました。
**解決策**
動的に作成されるダッシュボードを確認することで、問題が起きているデータベース層を特定できます。ダッシュボードには、関連するメトリクスやログファイルのスニペットが表示されます。
問題のあるダッシュボードのロググループのウィジェットには、`ACCESS DENIED` イベントが表示されます。これには、S3 バケット、S3 バケットフォルダー、S3 バケットリージョンなどの追加情報が含まれます。
![\[メモリ不足を示すロググループ。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-backup-stopped-2.png)
## SAP HANA の異常検出
スレッド数など特定の SAP HANA メトリクスについては、CloudWatch により統計および機械学習アルゴリズムが適用され、しきい値が定義されます。これらのアルゴリズムにより、SAP HANA データベースのメトリクスが継続的に分析され、正常なベースラインが決定します。このため、ユーザーの介入が最小限でも異常を検出できます。アルゴリズムにより、異常検出モデルが生成されます。このモデルにより、メトリクスの正常な動作を表す想定値の範囲が生成されます。
異常検出アルゴリズムは、メトリクスの季節的な変化と傾向の変化を考慮します。季節的な変化は、次の例に示す SAP HANA の CPU 使用率のように、時間単位、日単位、週単位のいずれかになります。
![\[メモリ不足を示すロググループ。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-anomaly-detection.png)
モデルを作成した後、CloudWatch の異常検出ではモデルの継続的な評価および調整が行われ、可能な限り正確であることが確認されます。これには、メトリクス値が時間の経過とともに変化するか、または突然変化するかを調整するためのモデルの再トレーニングが含まれます。また、季節的、スパイク、スパースなメトリクスのモデルを改善するための予測変数も含まれます。
## SAP HANA 向けの Application Insights のトラブルシューティング
このセクションでは、Application Insights ダッシュボードから返される一般的なエラーを解決するための手順について説明します。
### 60 を超える監視対象メトリクスを追加できない
出力では、次のエラーが表示されます。
```
Component cannot have more than 60 monitored metrics
```
**根本原因** – 現在の監視対象メトリクスの上限は、コンポーネントごとに 60 個です。
**解決方法** – 制限を超えないように、必要のないメトリクスを削除します。
### オンボーディングプロセス後に SAP メトリクスが表示されない
次の情報を参照して、オンボーディングプロセス後に SAP メトリクスがダッシュボードに表示されない理由を特定してください。最初のステップは、Amazon EC2 インスタンスの AWS マネジメントコンソールまたはエクスポーターログを使用して、SAP メトリクスが表示されない理由をトラブルシューティングすることです。次に、エラー出力を確認して解決策を見つけます。
#### オンボーディング後に SAP メトリクスが表示されない理由をトラブルシューティングします。
Amazon EC2 インスタンスの AWS マネジメントコンソールまたはエクスポーターログをトラブルシューティングに使用できます。
------
#### [ AWS マネジメントコンソール ]
**オンボーディング後に SAP メトリクスが表示されない問題をコンソールを使用してトラブルシューティングする**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. 左側のナビゲーションペインで、**[ステートマネージャー]** を選択します。
1. **[関連付け]** で、文書 `AWSEC2-ApplicationInsightsCloudwatchAgentInstallAndConfigure` のステータスを確認します。ステータスが `Failed` の場合は、**[実行 ID]** で失敗した ID を選択し、出力を表示します。
1. **[関連付け]** で、文書 `AWS-ConfigureAWSPackage` のステータスを確認します。ステータスが `Failed` の場合は、**[実行 ID]** で失敗した ID を選択し、出力を表示します。
------
#### [ Exporter logs from Amazon EC2 instance ]
**オンボーディング後に SAP メトリクスが表示されない問題をエクスポーターログを使用してトラブルシューティングする**
1. SAP HANA データベースが実行されている Amazon EC2 インスタンスに接続します。
1. 次のコマンドを使用して、`WORKLOAD_SHORT_NAME` に使用する正しい命名規則を見つけます。この省略名は次の 2 つのステップで使用します。
```
sudo systemctl | grep exporter
```
**注記**
Application Insights は、実行中のワークロードに応じて、サービス名にサフィックス `WORKLOAD_SHORT_NAME` を追加します。SAP HANA のシングルノード、マルチノード、高可用性デプロイの省略名は `HANA_SN`、`HANA_MN`、および `HANA_HA` です。
1. エクスポーターマネージャーのサービスログにエラーがないかチェックするには、`WORKLOAD_SHORT_NAME` を [Step 2](#step-find-short-name) で見つけた省略名に置き換えて、次のコマンドを実行します。
```
sudo journalctl -e --unit=prometheus-hanadb_exporter_manager_WORKLOAD_SHORT_NAME.service
```
1. エクスポーターマネージャーのサービスログにエラーが表示されない場合は、次のコマンドを実行してエクスポーターサービスログにエラーがないか確認します。
```
sudo journalctl -e --unit=prometheus-hanadb_exporter_WORKLOAD_SHORT_NAME.service
```
------
#### オンボーディング後に SAP メトリクスが表示されない問題の一般的な根本原因を解決する
以下の例は、オンボーディング後に SAP メトリクスが表示されない問題の一般的な根本原因を解決する方法を示しています。
+ 出力では、次のエラーが表示されます。
```
Reading json config file path: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/default ...
Reading json config file path: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/ssm_AmazonCloudWatch-ApplicationInsights-SSMParameterForTESTCWEC2INSTANCEi0d88867f1f3e36285.tmp ...
2023/11/30 22:25:17 Failed to merge multiple json config files.
2023/11/30 22:25:17 Failed to merge multiple json config files.
2023/11/30 22:25:17 Under path : /metrics/append_dimensions | Error : Different values are specified for append_dimensions
2023/11/30 22:25:17 Under path : /metrics/metrics_collected/disk | Error : Different values are specified for disk
2023/11/30 22:25:17 Under path : /metrics/metrics_collected/mem | Error : Different values are specified for mem
2023/11/30 22:25:17 Configuration validation first phase failed. Agent version: 1.0. Verify the JSON input is only using features supported by this version.
```
**解決策** — Application Insights は、既存の CloudWatch エージェントの設定ファイルの一部として事前設定されているものと同じメトリクスを設定しようとしています。`/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/` にある既存のファイルを削除するか、既存の CloudWatch エージェントの設定ファイルから競合の原因となっているメトリクスを削除します。
+ 出力では、次のエラーが表示されます。
```
Unable to find a host with system database, for more info rerun using -v
```
**解決策** — ユーザー名、パスワード、またはデータベースポートが間違っている可能性があります。ユーザー名、パスワード、およびポートが有効であることを確認し、その後オンボーディングプロセスに戻ります。
+ 出力では、次のエラーが表示されます。
```
This hdbcli installer is not compatible with your Python interpreter
```
**解決策** — Python 3.6 の次の例に示すように、pip3 と wheel をアップグレードします。
```
python3.6 -m pip install --upgrade pip setuptools wheel
```
+ 出力では、次のエラーが表示されます。
```
Unable to install hdbcli using pip3. Please try to install it
```
**解決策** — `hdbclient` の前提条件に従っていることを確認するか、pip3 に `hdbclient` を手動でインストールします。
+ 出力では、次のエラーが表示されます。
```
Package 'boto3' requires a different Python: 3.6.15 not in '>= 3.7'
```
**解決策** — このオペレーティングシステムのバージョンには Python 3.8 以降が必要です。Python 3.8 の前提条件を確認してインストールしてください。
+ 出力では、次のいずれかのインストールエラーが表示されます。
```
Can not execute `setup.py` since setuptools is not available in the build environment
```
または
```
[SSL: CERTIFICATE_VERIFY_FAILED]
```
**解決策** – 次の例に示すように、SUSE Linux コマンドを使用して Python をインストールします。次の例では、最新版の [Python 3.8](https://www.python.org/downloads/) をインストールします。
```
wget https://www.python.org/ftp/python/3.8./Python-3.8..tgz
tar xf Python-3.*
cd Python-3.*/
sudo zypper install make gcc-c++ gcc automake autoconf libtool
sudo zypper install zlib-devel
sudo zypper install libopenssl-devel libffi-devel
./configure --with-ensurepip=install
sudo make
sudo make install
sudo su
python3.8 -m pip install --upgrade pip setuptools wheel
```
# チュートリアル: SAP NetWeaver のモニターリングを設定する
このチュートリアルでは、SAP NetWeaver のモニターリングを設定できるよう Amazon CloudWatch Application Insights を設定する方法を説明します。CloudWatch Application Insights の自動ダッシュボードを使用して、問題の詳細を可視化し、トラブルシューティングを加速させ、SAP NetWeaver アプリケーションサーバーでの解決までの平均時間 (MTTR) を短縮できます。
**Topics**
+ [
## サポートされている環境
](#appinsights-tutorial-sap-netweaver-supported-environments)
+ [
## サポートされるオペレーティングシステム
](#appinsights-tutorial-sap-netweaver-supported-os)
+ [
## 機能
](#appinsights-tutorial-sap-netweaver-features)
+ [
## 前提条件
](#appinsights-tutorial-sap-netweaver-prerequisites)
+ [モニターリングの設定](#appinsights-tutorial-sap-netweaver-set-up)
+ [モニターリングの管理](#appinsights-tutorial-sap-netweaver-manage)
+ [問題のトラブルシューティング](#appinsights-tutorial-sap-netweaver-troubleshooting)
+ [Application Insights のトラブルシューティング](#appinsights-tutorial-sap-netweaver-troubleshooting-health-dashboard)
## サポートされている環境
CloudWatch Application Insights では、次のシステムおよびパターン用に AWS リソースのデプロイがサポートされています。
+ **SAP NetWeaver 標準システムデプロイ**
+ **複数の Amazon EC2 インスタンスでの SAP NetWeaver Distributed デプロイ。**
+ **クロス AZ SAP Netweaver の高可用性セットアップ** – SUSE/RHEL クラスタリングにより 2 つのアベイラビリティーゾーンでの高可用性が設定されている SAP Netweaver。
## サポートされるオペレーティングシステム
SAP Netweaver 用 CloudWatch Application Insights は、次のオペレーティングシステム上でサポートされています。
+ Oracle Linux 8
+ Red Hat Enterprise Linux 7.6
+ Red Hat Enterprise Linux 7.7
+ Red Hat Enterprise Linux 7.9
+ Red Hat Enterprise Linux 8.1
+ Red Hat Enterprise Linux 8.2
+ Red Hat Enterprise Linux 8.4
+ Red Hat Enterprise Linux 8.6
+ SAP 用 SUSE Linux Enterprise Server 15
+ SAP 用 SUSE Linux Enterprise Server 15 SP1
+ SAP 用 SUSE Linux Enterprise Server 15 SP2
+ SAP 用 SUSE Linux Enterprise Server 15 SP3
+ SAP 用 SUSE Linux Enterprise Server 15 SP4
+ SAP 用 SUSE Linux Enterprise Server 12 SP4
+ SAP 用 SUSE Linux Enterprise Server 12 SP5
+ High Availability パターンを除く SUSE Linux Enterprise Server 15
+ High Availability パターンを除く SUSE Linux Enterprise Server 15 SP1
+ High Availability パターンを除く SUSE Linux Enterprise Server 15 SP2
+ High Availability パターンを除く SUSE Linux Enterprise Server 15 SP3
+ High Availability パターンを除く SUSE Linux Enterprise Server 15 SP4
+ High Availability パターンを除く SUSE Linux Enterprise Server 12 SP4
+ High Availability パターンを除く SUSE Linux Enterprise Server 12 SP5
## 機能
SAP NetWeaver 7.0x—7.5x (ABAP Platform を含む) 用の CloudWatch Application Insights には、次の機能が用意されています。
+ SAP NetWeaver ワークロードの自動検出
+ 静的しきい値に基づく SAP Netweaver アラームの自動作成
+ SAP Netweaver のログパターンの自動認識
+ SAP NetWeaver 用のヘルスダッシュボード
+ SAP NetWeaver 用の問題ダッシュボード
## 前提条件
CloudWatch Application Insights で SAP Netweaver を設定するには、以下を前もって実行する必要があります。
+ **AWS Systems Manager の有効化** – Amazon EC2 インスタンスに SSM Agent をインストールし、インスタンスを SSM に対して有効にします。SSM Agent のインストールに関する詳細については、「AWS Systems Manager ユーザーガイド」の「[AWS Systems Manager のセットアップ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up.html)」を参照してください。
+ **Amazon EC2 インスタンスロール** – SAP NetWeaver モニターリングを設定するには、次の Amazon EC2 インスタンスロールをアタッチする必要があります。
+ Systems Manager を有効にする `AmazonSSMManagedInstanceCore` ロールをアタッチする必要があります。詳細については、「[AWS Systems Manager アイデンティティベースのポリシーの例](https://docs.aws.amazon.com/systems-manager/latest/userguide/auth-and-access-control-iam-identity-based-access-control.html)」を参照してください。
+ インスタンスメトリクスとログが CloudWatch を介して出力されるように `CloudWatchAgentServerPolicy` ポリシーをアタッチする必要があります。詳細については、「[CloudWatch エージェントで使用する IAM ロールとユーザーを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-iam-roles-for-cloudwatch-agent.html)」を参照してください
+ **AWS リソースグループ** – アプリケーションを CloudWatch Application Insights にオンボードするには、アプリケーションスタックで使用されるすべての関連する AWS リソースを含むリソースグループを作成する必要があります。これには、SAP NetWeaver アプリケーションサーバーを実行する Amazon EC2 インスタンス、Amazon EFS、および Amazon EBS ボリュームが含まれます。1 つのアカウントに複数の SAP NetWeaver システムがある場合は、各 SAP Netweaver システムの AWS リソースを含む 1 つのリソースグループを作成することをお勧めします。リソースグループの作成についての詳細は、[AWS Resource Groups とタグのユーザーガイド](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html)を参照してください。
+ **IAM アクセス許可** – 管理アクセスが許可されていないユーザーについては、Application Insights でサービスにリンクされたロールを作成できる AWS Identity and Access Management (IAM) ポリシーを作成し、ユーザーの ID にアタッチする必要があります。IAM ポリシーを作成する方法については、「[IAM ポリシー](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/appinsights-iam.html)」を参照してください。
+ **サービスにリンクされたロール** – Application Insights は AWS Identity and Access Management (IAM) サービスにリンクされたロールを使用します。Application Insights コンソールで新しい Application Insights アプリケーションを作成する際、サービスにリンクされたロールが作成されます。詳細については、「[CloudWatch Application Insights のサービスにリンクされたロールの使用](CHAP_using-service-linked-roles-appinsights.md)」を参照してください。
+ **Amazon CloudWatch エージェント** – Application Insights は、CloudWatch エージェントをインストールして設定します。CloudWatch エージェントがインストールされている場合、Application Insights は設定をそのまま維持します。マージ競合を避けるため、既存の CloudWatch エージェント設定ファイルから、Application Insights で使用するリソースの設定を削除してください。詳細については、「[CloudWatch エージェント設定ファイルを手動で作成または編集する](CloudWatch-Agent-Configuration-File-Details.md)」を参照してください。
## SAP NetWeaver アプリケーションサーバーをモニターリングするように設定する
SAP NetWeaver アプリケーションサーバーのモニターリングを設定するには、次の手順に従います。
**モニターリングを設定するには**
1. [CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch)を開きます。
1. 左側のナビゲーションペインで、**[Insights]** (インサイト) の下にある **[Application Insights]** を選択します。
1. **[Application Insights]** ページには、Application Insights でモニターリングするアプリケーションのリストと、各アプリケーションのモニターリングのステータスが表示されます。右上隅の **[Add an application]** (アプリケーションの追加) を選択します。
1. **[Specify application details]** (アプリケーションの詳細の指定) ページで、**[Resource group]** (リソースグループ) のドロップダウンリストから、SAP Netweaver リソースを含む作成済みの AWS リソースグループを選択します。アプリケーションのリソースグループを作成していない場合は、**[Resource group]** (リソースグループ) のドロップダウンリストから、**[Create new resource group]** (新しいリソースグループの作成) を選択して作成できます。
1. **[Automatic monitoring of new resources]** (新しいリソースの自動モニターリング) でチェックボックスをオンにすると、オンボーディング後にアプリケーションのリソースグループに追加されたリソースが Application Insights で自動的にモニターリングされるようになります。
1. **[Monitor EventBridge events]** (EventBridge イベントのモニターリング) で、CloudWatch Events と Application Insights のモニターリングを統合できるチェックボックスをオンにすると、Amazon EBS、Amazon EC2、AWS CodeDeploy、Amazon ECS、AWS Health APIs and Notifications、Amazon RDS、Amazon S3、および AWS Step Functions からのインサイトを取得できます。
1. 選択したアプリケーションの問題が検出されたときにそれらを表示し、通知を受け取るには、**[AWS Systems Manager OpsCenter と統合する]** にある **[修正アクションのため AWS Systems Manager OpsCenter OpsItems を生成する]** 横のチェックボックスをオンにします。AWS リソースに関連する [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-getting-started-sns.html) というオペレーション作業項目を解決するために実行されたオペレーションを追跡するには、SNS トピックの ARN を指定します。
1. オプションでタグを入力して、リソースを特定し整理できます。CloudWatch Application Insights では、タグベースのリソースグループと CloudFormation スタックベースのリソースグループ (Application Auto Scaling グループを除く) の両方がサポートされています。詳細については、*AWS Resource Groups とタグユーザーガイド*の「[Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html)」を参照してください。
1. 検出されたコンポーネントを確認するには、**[次へ]** を選択します。
1. **[検出されたコンポーネントを確認]** ページには、CloudWatch Application Insights によって自動的に検出されたモニターリング対象のコンポーネントとそれらのワークロードが一覧表示されます。
1. ワークロードの種類と名前を編集するには、**[コンポーネントを編集]** を選択します。
**注記**
検出された NetWeaver Distributed ワークロードまたは NetWeaver High Availability ワークロードを含むコンポーネントは、1 つのコンポーネントで 1 つのワークロードのみをサポートします。
![\[CloudWatch Application Insights コンソールの検出されたコンポーネントの確認セクション: 編集可能なコンポーネントのリスト。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-multiapp-netweaver.png)
1. [**Next**] を選択します。
1. **[Specify component details]** (コンポーネントの詳細の指定) ページで **[Next]** (次へ) を選択します。
1. アプリケーションのモニターリング設定を確認し **[送信]** を選択します。
1. アプリケーションの詳細ページが開き、**[アプリケーションの概要]**、**[ダッシュボード]**、**[コンポーネント]** 、および **[ワークロード]** を表示できます。また、コンポーネントの横にあるラジオボタンをオンにすると、**[Configuration history]** (設定履歴)、**[Log patterns]** (ログのパターン)、および作成した **[Tags]** (タグ) を確認できます。アプリケーションを送信すると、CloudWatch Application Insights は SAP NetWeaver システムのすべてのメトリクスとアラームをデプロイします。デプロイには最大 1 時間かかります。
## SAP NetWeaver アプリケーションサーバーのモニターリングを管理する
次の手順を使用して、SAP NetWeaver アプリケーションサーバーのモニターリングを管理します。
**モニターリングを管理するには**
1. [CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch)を開きます。
1. 左側のナビゲーションペインで、**[Insights]** (インサイト) の下にある **[Application Insights]** を選択します。
1. **[List view]** (リストビュー) タブを選択します。
1. **[Application Insights]** ページには、Application Insights でモニターリングするアプリケーションのリストと、各アプリケーションのモニターリングのステータスが表示されます。
1. アプリケーションを選択します。
1. **[Components]** (コンポーネント) タブを選択します。
1. **[Monitored components]** (モニターリングされているコンポーネント) で、コンポーネント名の横にあるラジオボタンをオンにします。次に、**[Manage monitoring]** (モニターリングを管理) を選択します。
1. **[Instance logs]** (インスタンスログ) で、既存のログパス、ログパターンのセット、およびロググループ名を更新できます。さらに、追加で **Application logs** (アプリケーションログ) を最大 3 つまで追加できます。
1. **[Metrics]** (メトリクス) で、要件に応じて SAP Netweaver メトリクスを選択できます。SAP Netweaver のメトリクス名は、`sap` で始まります。コンポーネントごとに最大 40 個のメトリクスを追加できます。
1. **[Custom alarms]** (カスタムアラーム) では、CloudWatch Application Insights によってモニターリングするアラームを追加できます。
1. アプリケーションのモニターリング設定を確認し、**[Save]** (保存) を選択します。設定を送信すると、アカウントで SAP Netweaver システムのすべてのメトリクスとアラームが更新されます。
## CloudWatch Application Insights で検出された SAP Netweaver に関する問題の表示とトラブルシューティング
次のセクションでは、Application Insights で SAP Netweaver のモニターリングを設定する際に発生する一般的なトラブルシューティングのシナリオを解決する手順について説明します。
**Topics**
+ [
### SAP NetWeaver データベース接続の問題
](#appinsights-tutorial-sap-netweaver-troubleshooting-database)
+ [
### SAP NetWeaver アプリケーションの可用性に関する問題
](#appinsights-tutorial-sap-netweaver-troubleshooting-availability)
### SAP NetWeaver データベース接続の問題
**説明**
SAP NetWeaver アプリケーションにデータベース接続の問題が発生しています。
**原因**
接続の問題を特定するには、CloudWatch Application Insights コンソールに移動し、SAP NetWeaver Application Insights の問題ダッシュボードを確認します。**[Problem summary]** (問題の概要) でリンクを選択すると、特定の問題が表示されます。
![\[CloudWatch Application Insights の検出された問題用のダッシュボードでは、[Problem summary] (問題の概要) 列の [Detected problems] (検出された問題) セクションの下に詳細情報が表示されます。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-nw-database-connectivity-1.png)
次の例では、**[Problem summary]** (問題の概要) の下で「SAP: Availability」(SAP: 可用性) が問題として表示されています。
![\[CloudWatch Application Insights の [Problem summary] (問題の概要) ページの [Problem summary] (問題の概要) セクションの下に表示されます。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-nw-database-connectivity-2.png)
**[Problem summary]** (問題の概要) のすぐ後に、**[Insight]** (インサイト) セクションには、エラーに関する詳細なコンテキスト、および問題の原因に関する詳細情報を取得できる場所が表示されます。
![\[エラーの原因に関する追加情報を含む CloudWatch Application Insights の問題インサイト。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-nw-database-connectivity-3.png)
同じ問題ダッシュボードで、問題の検出によってグループ化された関連ログとメトリクスを表示すると、エラーの原因の切り分けに役立ちます。`sap_alerts_Availability` メトリクスは、SAP NetWeaver システムの可用性を経時的に追跡します。履歴追跡を使用して、メトリクスがエラー状態になったり、アラームのしきい値を超過したりした日時を関連付けることができます。次の例では、SAP NetWeaver システムに可用性の問題があります。この例では、2 つのアラームが表示されています。これは、SAP アプリケーションサーバーインスタンスが 2 つあり、インスタンスごとに 1 つのアラームが作成されているためです。
![\[エラーが発生した日時の履歴に関する追加情報を含む CloudWatch Application Insights の SAP Availability メトリクス。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-nw-database-connectivity-4.png)
各アラームの詳細については、`sap_alerts_Availability` メトリクス名にカーソルを合わせてください。
![\[エラーに関する追加の詳細を含む CloudWatch Application Insights の SAP Availability メトリクス。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-nw-database-connectivity-5.png)
次の例では、`sap_alerts_Database` メトリクスはデータベースレイヤーに問題や障害があることを示しています。このアラームは、SAP NetWeaver でデータベースへの接続やデータベースとの通信に問題が発生したことを示します。
![\[エラーが発生した日時に関する追加履歴を含む CloudWatch Application Insights の SAP Database メトリクス。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-nw-database-connectivity-6.png)
データベースは SAP NetWeaver の重要なリソースであるため、データベースに問題や障害が発生すると、関連するアラームが数多く表示されることがあります。次の例では、データベースが使用できないため、`sap_alerts_FrontendResponseTime` および `sap_alerts_LongRunners` メトリクスが開始されます。
![\[データベース障害が原因で作成された、CloudWatch Application Insights の追加の SAP Database メトリクス。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-nw-database-connectivity-7.png)
**解決方法**
Application Insights は、検出された問題を 1 時間ごとにモニターリングします。SAP NetWeaver ログファイルに新しい関連ログエントリがない場合、古いログエントリは解決済みとして処理されます。CloudWatch アラームに関連するエラー条件をすべて修正する必要があります。エラー条件が修正された後、アラームとログが復旧するとアラームが解決されます。CloudWatch ログのエラーとアラームがすべて解決されると、Application Insights はエラーの検出を停止し、問題は 1 時間以内に自動的に解決されます。問題ダッシュボードに最新の問題が表示されるように、ログのエラー条件とアラームすべてを解決することをお勧めします。
次の例では、SAP Availability の問題が解決されています。
![\[SAP Availability の問題が解決された、CloudWatch Application Insights の問題ダッシュボード。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-nw-database-connectivity-resolved.png)
### SAP NetWeaver アプリケーションの可用性に関する問題
**説明**
SAP NetWeaver High Availability Enqueue Replication が機能しなくなりました。
**原因**
接続の問題を特定するには、CloudWatch Application Insights コンソールに移動し、SAP NetWeaver Application Insights の問題ダッシュボードを確認します。**[Problem summary]** (問題の概要) でリンクを選択すると、特定の問題が表示されます。
![\[[Problem summary] (問題の概要) の下で詳細情報を表示する CloudWatch Application Insights の問題ダッシュボード。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-nw-app-availability-problem-dashboard.png)
次の例では、**[Problem summary]** (問題の概要) の下で、「High Availability Enqueue Replication」が問題として表示されています。
![\[「SAP Availability: Enqueue replication」(SAP Availability: レプリケーションをキューから削除) エラーが表示された、CloudWatch Application Insights の [Problem summary] (問題の概要)。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-nw-app-availability-1.png)
**[Problem summary]** (問題の概要) のすぐ後に、**[Insight]** (インサイト) セクションには、エラーに関する詳細なコンテキスト、および問題の原因に関する詳細情報を取得できる場所が表示されます。
![\[エラーの原因に関する追加情報を含む CloudWatch Application Insights の問題インサイト。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-nw-app-availability-2.png)
次の例は、エラーの原因の分離に役立つようにグループ化されたログとメトリクスが表示される問題ダッシュボードを示しています。`sap_enqueue_server_replication_state` メトリクスは値を経時的に追跡します。履歴追跡を使用して、メトリクスがエラー状態になったり、アラームのしきい値を超過したりした日時を関連付けることができます。
![\[エラーが発生した日時に関する追加情報を含む、サーバーレプリケーションの状態に関するメトリクスをキューに追加します。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-nw-app-availability-3.png)
次の例では、`ha_cluster_pacemaker_fail_count` メトリクスは、高可用性ペースメーカークラスターでリソース障害が発生したことを示しています。フェイルカウントが 1 以上の特定のペースメーカーリソースは、コンポーネントダッシュボードで特定されます。
![\[フェイルカウントが 1 以上のペースメーカーリソースに対する CloudWatch Application Insights のアプリケーション可用性のメトリクス。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-nw-app-availability-4.png)
次の例は、問題が検出されたときに SAP アプリケーションのパフォーマンスが低下したことを示す `sap_alerts_Shortdumps` メトリクスを示しています。
![\[CloudWatch Application Insights のアプリケーション可用性アラートショートダンプのメトリクス。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-nw-app-availability-5.png)
#### ログ
ログエントリは、問題が検出されたときに SAP NetWeaver レイヤーで発生した問題をより適切に理解するのに役立ちます。問題ダッシュボードのロググループウィジェットには、問題の具体的な発生時刻が表示されます。
![\[問題が発生した正確な時刻を示す CloudWatch Application Insights のログエントリ。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-nw-app-availability-7.png)
ログに関する詳細情報を表示するには、右上隅にある縦に並んだ 3 つのドットを選択し、**[View in CloudWatch Logs Insights]** (CloudWatch Logs Insights で表示) を選択します。
![\[[View in CloudWatch Logs Insights] (CloudWatch Logs Insights で表示) で表示される CloudWatch Application Insights の詳細。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-nw-app-availability-8.png)
次の手順を使用して、問題ダッシュボードに表示されたメトリクスとアラームに関する詳細情報を取得します。
**メトリクスとアラームに関する追加情報を取得するには**
1. [CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch)を開きます。
1. 左側のナビゲーションペインで、**[Insights]** (インサイト) の下にある **[Application Insights]** を選択します。次に、**[List view]** (リストビュー) タブを選択し、アプリケーションを選択します。
1. **[Components]** (コンポーネント) タブを選択します。次に、詳細情報を取得する SAP NetWeaver コンポーネントを選択します。
次の例は、問題ダッシュボードに表示された `ha_cluster_pacemaker_fail_count` メトリクスを含む **[HA Metrics]** (HA メトリクス) セクションを示しています。
![\[ペースメーカーリソースのフェイルカウントを示す CloudWatch Application Insights の HA メトリクス。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-nw-app-availability-9.png)
**解決方法**
Application Insights は、検出された問題を 1 時間ごとにモニターリングします。SAP NetWeaver ログファイルに新しい関連ログエントリがない場合、古いログエントリは解決済みとして処理されます。この問題に関連するエラー条件をすべて修正する必要があります。
`sap_alerts_Shortdumps` アラームについては、トランザクションコード `RZ20 → R3Abap → Shortdumps` を使用して CCMS アラートに移動し、SAP NetWeaver システム内のアラートを解決する必要があります。CCMS アラートの詳細については、「[SAP Web サイト](https://help.sap.com/docs/SAP_NETWEAVER_701/6f45651d6c4b1014a50f9ef0fc8df39d/408dc4a7c415437a9b91d2ef6caa9d7d.html)」を参照してください。Shortdumps ツリーのすべての CCMS アラートを解決します。SAP NetWeaver システムですべてのアラートが解決されると、CloudWatch はアラーム状態のメトリクスを報告しなくなります。
CloudWatch ログのエラーとアラームがすべて解決されると、Application Insights はエラーの検出を停止し、問題は 1 時間以内に自動的に解決されます。問題ダッシュボードに最新の問題が表示されるように、ログのエラー条件とアラームすべてを解決することをお勧めします。次の例では、「SAP Netweaver High Availability Enqueue Replication」の問題が解決されています。
![\[「SAP Availability: Enqueue Replication」の問題が [Resolved] (解決済み) のステータスになっていることを示す、CloudWatch Application Insights の問題ダッシュボード。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/appinsights-nw-app-availability-problem-resolved.png)
## SAP Netweaver 用 Application Insights のトラブルシューティング
このセクションでは、Application Insights ダッシュボードから返される一般的なエラーを解決するための手順について説明します。
### 60 を超えるモニターリングメトリクスを追加できない
**返されたエラー**: `Component cannot have more than 60 monitored metrics.`
**根本原因**: `The current metric limit is 60 monitor metrics per component.`
**解決方法**: 制限の準拠に必要のないメトリクスを削除します。
### オンボーディング処理後、SAP メトリクスがダッシュボードに表示されない
**根本原因**: コンポーネントダッシュボードでは、データポイントを集約するために 5 分のメトリクス期間が使用されます。
**解決方法**: 5 分後にすべてのメトリクスがダッシュボードに表示されます。
### SAP メトリクスとアラームがダッシュボードに表示されない
次の手順に従って、オンボーディング処理後に SAP メトリクスとアラームがダッシュボードに表示されない理由を特定してください。
**メトリクスとアラームの問題を特定するには**
1. [CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch)を開きます。
1. 左側のナビゲーションペインで、**[Insights]** (インサイト) の下にある **[Application Insights]** を選択します。次に、**[List view]** (リストビュー) タブを選択し、アプリケーションを選択します。
1. **[Configuration history]** (設定履歴) タブを選択します。
1. メトリクスのデータポイントが欠落している場合は、`prometheus-sap_host_exporter` に関連するエラーがないかチェックしてください。
1. 前のステップでエラーが見つからなかった場合は、[Linux インスタンスに接続します](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html)。High Availability デプロイでは、プライマリクラスターの Amazon EC2 インスタンスに接続します。
1. インスタンスで、次のコマンドを使用してエクスポーターが実行されていることを検証します。デフォルトのポート番号は `9680` です。別のポートを使用している場合は、`9680` を使用しているポート番号に置き換えてください。
```
curl localhost:9680/metrics
```
データが返されない場合、エクスポーターは起動に失敗しています。
1. 次の 2 つのステップで `WORKLOAD_SHORT_NAME` に使用する正しい命名規則を見つけるには、次のコマンドを実行します。
**注記**
Application Insights は、実行中のワークロードに応じて、サービス名にサフィックス `WORKLOAD_SHORT_NAME` を追加します。NetWeaver Distributed、Standard、High Availability デプロイの短縮名は `SAP_NWD`、`SAP_NWS`、`SAP_NWH` です。
```
sudo systemctl | grep exporter
```
1. エクスポーターのサービスログにエラーがないかチェックするには、次のコマンドを実行します。
```
sudo journalctl -e --unit=prometheus-sap_host_exporter_WORKLOAD_SHORT_NAME.service
```
1. エクスポーターマネージャーのサービスログにエラーがないかチェックするには、次のコマンドを実行します。
```
sudo journalctl -e --unit=prometheus-sap_host_exporter_manager_WORKLOAD_SHORT_NAME.service
```
**注記**
このサービスを常時起動し稼働させておく必要があります。
このコマンドでエラーが返されない場合は、次のステップに進みます。
1. エクスポーターを手動で起動するには、次のコマンドを実行します。次に、エクスポーターの出力をチェックします。
```
sudo /opt/aws/sap_host_exporter/sap_host_exporter
```
エラーをチェックしたら、エクスポーターの処理を終了できます。
**根本原因**: この問題の原因はいくつか考えられます。一般的な原因は、エクスポーターがアプリケーションサーバーインスタンスのいずれかに接続できなかったことです。
**[Resolution]** (解像度)
次の手順を使用して、エクスポーターをアプリケーションサーバーインスタンスに接続します。SAP アプリケーションインスタンスが実行中であることを確認し、SAPControl を使用してインスタンスに接続します。
**エクスポーターをアプリケーションサーバーインスタンスに接続するには**
1. Amazon EC2 インスタンスで、次のコマンドを実行して SAP アプリケーションが実行されていることを検証します。
```
sapcontrol -nr -function GetProcessList
```
1. 正常に機能する SAPControl 接続を確立する必要があります。SAPControl 接続が機能しない場合は、関連する SAP アプリケーションインスタンスで問題の根本原因を見つけてください。
1. SAPControl 接続の問題を修正した後にエクスポーターを手動で起動するには、次のコマンドを実行します。
```
sudo systemctl start prometheus-sap_host_exporter.service
```
1. SAPControl 接続の問題を解決できない場合は、一時的な修正として次の手順を使用してください。
1. [AWS Systems Manager コンソール](https://console.aws.amazon.com/systems-manager)を開きます。
1. 左側のナビゲーションペインで、**[State Manager]** (ステートマネージャー) を選択します。
1. **[Associations]** (関連付け) で、SAP NetWeaver システムの関連付けを検索します。
```
Association Name: Equal: AWS-ApplicationInsights-SSMSAPHostExporterAssociationForCUSTOMSAPNW-1
```
1. **[Association id]** (関連付け ID) を選択します。
1. **[Parameters]** (パラメータ) タブを選択し、**additionalArguments** からアプリケーションサーバー番号を削除します。
1. **[Apply association now]** (関連付けを今すぐ適用) を選択します。
**注記**
これは一時的な修正です。コンポーネントのモニターリング設定が更新されると、インスタンスは再び追加されます。
# Amazon CloudWatch Application Insights での検出された問題の表示とトラブルシューティング
このセクションのトピックでは、Application Insights で表示される検出された問題とインサイトに関する詳細情報を提供します。また、アカウントまたは設定で検出された問題の推奨される解決策も提供します。
**Topics**
+ [
## CloudWatch コンソールの概要
](#appinsights-troubleshooting-overview)
+ [
## Application Insights の問題の概要ページ
](#appinsights-troubleshooting-problem-summary)
+ [
## CloudWatch エージェントのマージ競合エラー
](#cwagent-merge-conflicts)
+ [
## CloudWatch エージェントログ処理による CPU 使用率が高い
](#cwagent-high-cpu-usage)
+ [
## アラームは作成されません。
](#alarms-not-created)
+ [
## フィードバック
](#appinsights-troubleshooting-feedback)
+ [
## 設定エラー
](#appinsights-configuration-errors)
## CloudWatch コンソールの概要
モニターリングされるアプリケーションに影響する問題の概要は、[CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch)の概要ページで、CloudWatch Application Insights ペインの下に表示されます。
CloudWatch Application Insights の概要ペインには、次が表示されます。
+ 検出された問題の重大度: 高/中/低
+ 問題の簡単な概要
+ 問題のソース
+ 問題が発生した時刻
+ 問題の解決のステータス
+ 影響を受けるリソースグループ
特定の問題の詳細を確認するには、**[Problem Summary]** (問題の概要) で、問題の説明を選択します。詳細なダッシュボードに、問題へのインサイト、関連メトリクスの異常、およびログエラーのスニペットが表示されます。インサイトが有益かどうかを選択することで、インサイトの関連度に関するフィードバックを提供できます。
新しい未設定のリソースが検出された場合は、問題の概要の説明から **[Edit configuration]** (設定の編集) ウィザードに移動して新しいリソースを設定します。詳細なダッシュボードの右上にある **[View/edit configuration]** (設定の表示/編集) を選択して、リソースグループの設定を表示または編集できます。
概要に戻るには、CloudWatch Application Insights の詳細なダッシュボードのヘッダーの横にある [**Back to overview (概要に戻る)**] を選択します。
## Application Insights の問題の概要ページ
**Application Insights の問題の概要ページ**
CloudWatch Application Insights では、問題の概要ページで検出された問題に関する次の情報が提供されます。
+ 問題の簡単な概要
+ 問題の発生日時
+ 問題の重大度: 高/中/低
+ 検出された問題のステータス: 進行中/解決済み
+ インサイト: 検出された問題と考えられる根本原因に関して自動生成されるインサイト
+ インサイトに関するフィードバック: CloudWatch Application Insights で生成されたインサイトの有益性についてユーザーが提供したフィードバック
+ 関連する監視結果: さまざまなアプリケーションコンポーネントにまたがる問題に関連するメトリクスの異常とログのエラースニペットの詳細ビュー
## CloudWatch エージェントのマージ競合エラー
CloudWatch Application Insights は、顧客のインスタンスに CloudWatch エージェントをインストールして設定します。これには、メトリクスまたはログの設定を含む CloudWatch エージェント設定ファイルの作成が含まれます。お客様のインスタンスに同じメトリックスまたはログに対して異なる設定が定義された CloudWatch エージェント設定ファイルがすでに存在する場合、マージ競合が発生する可能性があります。マージ競合を解決するには、次の手順に従います。
1. システム上の CloudWatch エージェント設定ファイルを特定します。ファイルロケーションの詳細については、「[CloudWatch エージェントファイルとロケーション](troubleshooting-CloudWatch-Agent.md#CloudWatch-Agent-files-and-locations)」を参照してください。
1. 既存の CloudWatch エージェント設定ファイルから、Application Insights で使用するリソースの設定を削除してください。Application Insights サイト設定のみを使用する場合は、既存の CloudWatch エージェント設定ファイルを削除します。
## CloudWatch エージェントログ処理による CPU 使用率が高い
CloudWatch Application Insights は、顧客のインスタンスに CloudWatch エージェントをインストールして設定します。Amazon EC2 インスタンスに大量のログデータを含むログパスが設定されている場合、CloudWatch エージェントがログを処理する間にインスタンスの CPU 使用率が増加する可能性があります。CPU 使用率を減らすには、[Amazon EC2 インスタンスコンポーネント設定](component-configuration-examples-ec2.md)のログパスを削除します。
## アラームは作成されません。
一部のメトリクスでは、Application Insights はメトリクスの以前のデータポイントに基づいてアラームのしきい値を予測します。この予測を有効にするには、次の条件を満たす必要があります。
+ **最近のデータポイント** — 過去 24 時間以内のデータポイントが 100 以上ある必要があります。データポイントは連続している必要はなく、24 時間にわたって分散していてもかまいません。
+ **履歴データ** — 現在の日付の 15 日前から 1 日前までの期間内に少なくとも 100 個のデータポイントが必要です。データポイントは連続している必要はなく、15 日間にわたって分散していてもかまいません。
**注記**
一部のメトリクスでは、Application Insights は前述の条件が満たされるまでアラームの作成を遅らせます。この場合、アラームのしきい値を設定するのに十分なデータポイントがメトリックスにないという設定履歴イベントが発生します。
## フィードバック
**フィードバック**
検出された問題への自動生成されたインサイトが有益であるかどうかを判定することで、インサイトに対するフィードバックを提供できます。インサイトに対するユーザーからのフィードバックとアプリケーションの診断結果 (メトリクスの異常とログの例外) は、今後同様の問題が発生した場合の検出を向上させるために使用されます。
## 設定エラー
CloudWatch Application Insights は、ユーザーの設定を使用してコンポーネントのモニターリングテレメトリを作成します。Application Insights は、ユーザーのアカウントや設定で問題を検出すると、アプリケーション設定の問題を解決する方法に関する情報を **[Remarks]** (解説) フィールドに表示します。
次の表は、解説ごとの推奨される解決策を示しています。
| 解説 | 推奨される解決策 | 追加のメモ |
| --- | --- | --- |
| CloudFormation のクォータにすでに達しています。 | Application Insights は、すべてのアプリケーションコンポーネントについて CloudWatch エージェントのインストールと設定を管理するために、アプリケーションごとに 1 つの ClooudFormation スタックを作成します。デフォルトでは、AWS アカウントごとに 2000 のスタックを使用できます。「[CloudFormation 制限](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cloudformation-limits.html)」をご参照ください。この問題を解決するには、CloudFormation スタックの制限を引き上げます。 | 該当なし |
| 以下のインスタンスに SSM インスタンスロールがありません。 | Application Insights でアプリケーションインスタンスに CloudWatch エージェントをインストールして設定するには、AmazonSSMManagedInstanceCore ポリシーと CloudWatchAgentServerPolicy ポリシーをインスタンスロールにアタッチする必要があります。 | Application Insights は、SSM [DescribeInstanceInformation API](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstanceInformation.html) を呼び出して、SSM アクセス許可が設定されたインスタンスのリストを取得します。ロールをインスタンスにアタッチしてから SSM がインスタンスを DescribeInstanceInformation の結果に含めるまでに時間がかかります。SSM がインスタンスを結果に含めるまでは、アプリケーションの NO\$1SSM\$1INSTANCE\$1ROLE エラーがそのまま残ります。 |
| 新しいコンポーネントは設定を必要とする場合があります。 | Application Insights は、アプリケーションのリソースグループに新しいコンポーネントがあることを検出しました。この問題を解決するには、新しいコンポーネントを適切に設定します。 | 該当なし |
# Amazon CloudWatch Application Insights でサポートされるログとメトリクス
Amazon CloudWatch Application Insights でサポートされるログとメトリクスを以下に一覧表示します。
**CloudWatch Application Insights でサポートされるログは以下のとおりです。**
+ Microsoft Internet Information Services (IIS) のログ
+ EC2 における SQL Server のエラーログ
+ .NET アプリケーションのカスタムログ (Log4Net など)
+ Windows ログ (システム、アプリケーション、セキュリティ)、アプリケーションとサービスログを含む Windows イベントログ
+ AWS Lambda の Amazon CloudWatch Logs
+ EC2 上の RDS MySQL、Aurora MySQL、MySQL のエラーログとスローログ
+ EC2 上の PostgreSQL RDS および PostgreSQL の Postgresql ログ
+ AWS Step Functions の Amazon CloudWatch Logs
+ API Gateway REST API ステージの実行ログとアクセスログ (JSON、CSV、XML、ただし、CLF を除く)
+ Prometheus JMX Exporter ログ (EMF)
+ Amazon RDS の Oracle と Amazon EC2 の Oracle のアラートログとリスナーログ
+ コンテナは、[`awslogs` ログドライバー](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_awslogs.html)を使用して Amazon ECS コンテナから CloudWatch へのルーティングを記録します。
+ コンテナは、[FireLens コンテナログルーター](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_firelens.html)を使用して Amazon ECS コンテナから CloudWatch へのルーティングを記録します。
+ コンテナは、Container Insights を含む [Fluent Bit または Fluentd ログプロセッサ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-EKS-logs.html)を使用して、Amazon EC2 で実行されている Amazon EKS または Kubernetes から CloudWatch へのルーティングを記録します。
+ SAP HANA の追跡およびエラーログ
+ HA Pacemaker ログ
+ SAP ASE サーバーログ
+ SAP ASE バックアップサーバーログ
+ SAP ASE Replication サーバーログ
+ SAP ASE RMA エージェントログ
+ SAP ASE Fault Manager ログ
+ SAP NetWeaver 開発者のトレースログ
+ [CloudWatch エージェント用の proctstat プラグイン](CloudWatch-Agent-procstat-process-metrics.md)を使用した Windows プロセスのプロセスメトリクス
+ ホストゾーンのパブリック DNS クエリログ
+ Amazon Route 53 Resolver DNS クエリログ
**CloudWatch Application Insights でサポートされるログクラスは以下のとおりです。**
+ **Standard** — Amazon CloudWatch Application Insights では、モニタリングを有効にするために、ロググループを [CloudWatch Logs Standard ログクラス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatch_Logs_Log_Classes.html)で設定する必要があります。
**Contents**
+ [
# Amazon Elastic Compute Cloud (EC2)
](appinsights-metrics-ec2.md)
+ [
## CloudWatch の組み込みメトリクス
](appinsights-metrics-ec2.md#appinsights-metrics-ec2-built-in)
+ [
## CloudWatch エージェントのメトリクス (Windows サーバー)
](appinsights-metrics-ec2.md#appinsights-metrics-ec2-windows)
+ [
## CloudWatch エージェントのプロセスメトリクス (Windows サーバー)
](appinsights-metrics-ec2.md#appinsights-metrics-procstat-ec2-windows)
+ [
## CloudWatch エージェントのメトリクス (Linux サーバー)
](appinsights-metrics-ec2.md#appinsights-metrics-ec2-linux)
+ [
# Elastic Block Store (EBS)
](appinsights-metrics-ebs.md)
+ [
# Amazon Elastic File System (Amazon EFS)
](appinsights-metrics-efs.md)
+ [
# Elastic Load Balancer (ELB)
](appinsights-metrics-elb.md)
+ [
# Application ELB
](appinsights-metrics-app-elb.md)
+ [
# Amazon EC2 Auto Scaling グループ
](appinsights-metrics-as.md)
+ [
# Amazon Simple Queue Server (SQS)
](appinsights-metrics-sqs.md)
+ [
# Amazon Relational Database Service (RDS)
](appinsights-metrics-rds.md)
+ [
## RDS データベースインスタンス
](appinsights-metrics-rds.md#appinsights-metrics-rds-instances)
+ [
## RDS データベースクラスター
](appinsights-metrics-rds.md#appinsights-metrics-rds-clusters)
+ [
# AWS Lambda 関数
](appinsights-metrics-lambda.md)
+ [
# Amazon DynamoDB テーブル
](appinsights-metrics-dyanamodb.md)
+ [
# Amazon S3 バケット
](appinsights-metrics-s3.md)
+ [
# AWS Step Functions
](appinsights-metrics-step-functions.md)
+ [
## Execution-level
](appinsights-metrics-step-functions.md#appinsights-metrics-step-functions-execution)
+ [
## アクティビティ
](appinsights-metrics-step-functions.md#appinsights-metrics-step-functions-activity)
+ [
## Lambda 関数
](appinsights-metrics-step-functions.md#appinsights-metrics-step-functions-lambda)
+ [
## サービス統合
](appinsights-metrics-step-functions.md#appinsights-metrics-step-functions-service-integration)
+ [
## Step Functions API
](appinsights-metrics-step-functions.md#appinsights-metrics-step-functions-api)
+ [
# API Gateway REST API ステージ
](appinsights-metrics-api-gateway.md)
+ [
# SAP HANA
](appinsights-metrics-sap-hana.md)
+ [
# SAP ASE
](appinsights-metrics-sap-ase.md)
+ [
# Amazon EC2 での SAP ASE High Availability
](appinsights-metrics-sap-ase-ha.md)
+ [
# SAP NetWeaver
](appinsights-metrics-sap-netweaver.md)
+ [
# HA Cluster
](appinsights-metrics-ha-cluster.md)
+ [
# Java
](appinsights-metrics-java.md)
+ [
# Amazon Elastic Container Service (Amazon ECS)
](appinsights-metrics-ecs.md)
+ [
## CloudWatch の組み込みメトリクス
](appinsights-metrics-ecs.md#appinsights-metrics-ecs-built-in-metrics)
+ [
## Container Insights のメトリクス
](appinsights-metrics-ecs.md#appinsights-metrics-ecs-container-insights-metrics)
+ [
## Container Insights Prometheus メトリクス
](appinsights-metrics-ecs.md#appinsights-metrics-ecs-container-insights-prometheus)
+ [
# AWS での Kubernetes
](appinsights-metrics-kubernetes.md)
+ [
## Container Insights のメトリクス
](appinsights-metrics-kubernetes.md#appinsights-metrics-kubernetes-container-insights-metrics)
+ [
## Container Insights Prometheus メトリクス
](appinsights-metrics-kubernetes.md#appinsights-metrics-kubernetes-container-insights-prometheus)
+ [
# Amazon FSx
](appinsights-metrics-fsx.md)
+ [
# Amazon VPC
](appinsights-metrics-vpc.md)
+ [
# Amazon VPC NAT ゲートウェイ
](appinsights-metrics-nat-gateways.md)
+ [
# Amazon Route 53 ヘルスチェック
](appinsights-metrics-health-check.md)
+ [
# Amazon Route 53 ホストゾーン
](appinsights-metrics-hosted-zone.md)
+ [
# Amazon Route 53 Resolver エンドポイント
](appinsights-metrics-resolver-endpoint.md)
+ [
# AWS Network Firewall ルールグループ
](appinsights-metrics-firewall-rule-group.md)
+ [
# AWS Network Firewall ルールグループ関連付け
](appinsights-metrics-firewall-rule-group-assoc.md)
+ [
# メトリクスのデータポイント要件
](appinsights-metrics-datapoint-requirements.md)
+ [
## AWS/ApplicationELB
](appinsights-metrics-datapoint-requirements.md#appinsights-metrics-datapoint-requirements-app-elb)
+ [
## AWS Autoscaling
](appinsights-metrics-datapoint-requirements.md#appinsights-metrics-datapoint-requirements-autoscaling)
+ [
## AWS/EC2
](appinsights-metrics-datapoint-requirements.md#appinsights-metrics-datapoint-requirements-ec2)
+ [
## Elastic Block Store (EBS)
](appinsights-metrics-datapoint-requirements.md#appinsights-metrics-datapoint-requirements-ebs)
+ [
## AWS/ELB
](appinsights-metrics-datapoint-requirements.md#appinsights-metrics-datapoint-requirements-elb)
+ [
## AWS/RDS
](appinsights-metrics-datapoint-requirements.md#appinsights-metrics-datapoint-requirements-rds)
+ [
## AWS/Lambda
](appinsights-metrics-datapoint-requirements.md#appinsights-metrics-datapoint-requirements-lambda)
+ [
## AWS/SQS
](appinsights-metrics-datapoint-requirements.md#appinsights-metrics-datapoint-requirements-sqs)
+ [
## AWS/CWAgent
](appinsights-metrics-datapoint-requirements.md#appinsights-metrics-datapoint-requirements-cwagent)
+ [
## AWS/DynamoDB
](appinsights-metrics-datapoint-requirements.md#appinsights-metrics-datapoint-requirements-dynamo)
+ [
## AWS/S3
](appinsights-metrics-datapoint-requirements.md#appinsights-metrics-datapoint-requirements-s3)
+ [
## AWS/States
](appinsights-metrics-datapoint-requirements.md#appinsights-metrics-datapoint-requirements-states)
+ [
## AWS/ApiGateway
](appinsights-metrics-datapoint-requirements.md#appinsights-metrics-datapoint-requirements-api-gateway)
+ [
## AWS/SNS
](appinsights-metrics-datapoint-requirements.md#appinsights-metrics-datapoint-requirements-sns)
+ [
# 推奨メトリクス
](application-insights-recommended-metrics.md)
+ [
# パフォーマンスカウンタのメトリクス
](application-insights-performance-counter.md)
# Amazon Elastic Compute Cloud (EC2)
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
**Topics**
+ [
## CloudWatch の組み込みメトリクス
](#appinsights-metrics-ec2-built-in)
+ [
## CloudWatch エージェントのメトリクス (Windows サーバー)
](#appinsights-metrics-ec2-windows)
+ [
## CloudWatch エージェントのプロセスメトリクス (Windows サーバー)
](#appinsights-metrics-procstat-ec2-windows)
+ [
## CloudWatch エージェントのメトリクス (Linux サーバー)
](#appinsights-metrics-ec2-linux)
## CloudWatch の組み込みメトリクス
CPUCreditBalance
CPUCreditUsage
CPUSurplusCreditBalance
CPUSurplusCreditsCharged
CPUUtilization
DiskReadBytes
DiskReadOps
DiskWriteBytes
DiskWriteOps
EBSByteBalance%
EBSIOBalance%
EBSReadBytes
EBSReadOps
EBSWriteBytes
EBSWriteOps
NetworkIn
NetworkOut
NetworkPacketsIn
NetworkPacketsOut
StatusCheckFailed
StatusCheckFailed\$1Instance
StatusCheckFailed\$1System
## CloudWatch エージェントのメトリクス (Windows サーバー)
.NET CLR Exceptions \$1 of Exceps Thrown
.NET CLR Exceptions \$1 of Exceps Thrown/Sec
.NET CLR Exceptions \$1 of Filters/sec
.NET CLR Exceptions \$1 of Finallys/sec
.NET CLR Exceptions Throw to Catch Depth/sec
.NET CLR Interop \$1 of CCWs
.NET CLR Interop \$1 of Stubs
.NET CLR Interop \$1 of TLB exports/sec
.NET CLR Interop \$1 of TLB imports/sec
.NET CLR Interop \$1 of marshaling
.NET CLR Jit % Time in Jit
.NET CLR Jit Standard Jit Failures
.NET CLR Loading % Time Loading
.NET CLR Loading Rate of Load Failures
.NET CLR LocksAndThreads Contention Rate/sec
.NET CLR LocksAndThreads Queue Length/sec
.NET CLR Memory \$1 Total Committed Bytes
.NET CLR Memory % Time in GC
.NET CLR Networking 4.0.0.0 HttpWebRequest Average Queue Time
.NET CLR Networking 4.0.0.0 HttpWebRequests Aborted/sec
.NET CLR Networking 4.0.0.0 HttpWebRequests Failed/sec
.NET CLR Networking 4.0.0.0 HttpWebRequests Queued/sec
APP\$1POOL\$1WAS Total Worker Process Ping Failures
ASP.NET Application Restarts
ASP.NET Applications % Managed Processor Time (estimated)
ASP.NET Applications Errors Total/Sec
ASP.NET Applications Errors Unhandled During Execution/sec
ASP.NET Applications Requests in Application Queue
ASP.NET Applications Requests/Sec
ASP.NET Request Wait Time
ASP.NET Requests Queued
HTTP Service Request Queues CurrentQueueSize
LogicalDisk % Free Space
Memory % Committed Bytes In Use
Memory Available Mbytes
Memory Pages/sec
Network Interface Bytes Total/sec
Paging File % Usage
PhysicalDisk % Disk Time
PhysicalDisk Avg。Disk Queue Length
PhysicalDisk Avg。Disk sec/Read
PhysicalDisk Avg。Disk sec/Write
PhysicalDisk Disk Read Bytes/sec
PhysicalDisk Disk Reads/sec
PhysicalDisk Disk Write Bytes/sec
PhysicalDisk Disk Writes/sec
Processor % Idle Time
Processor % Interrupt Time
Processor % Processor Time
Processor % User Time
SQLServer:Access Methods Forwarded Records/sec
SQLServer:Access Methods Full Scans/sec
SQLServer:Access Methods Page Splits/sec
SQLServer:Buffer Manager Buffer cache hit ratio
SQLServer:Buffer Manager Page life expectancy
SQLServer:General Statistics Processes blocked
SQLServer:General Statistics User Connections
SQLServer:Latches Average Latch Wait Time (ms)
SQLServer:Locks Average Wait Time (ms)
SQLServer:Locks Lock Timeouts/sec
SQLServer:Locks Lock Waits/sec
SQLServer:Locks Number of Deadlocks/sec
SQLServer:Memory Manager Memory Grants Pending
SQLServer:SQL Statistics Batch Requests/sec
SQLServer:SQL Statistics SQL Compilations/sec
SQLServer:SQL Statistics SQL Re-Compilations/sec
System Processor Queue Length
TCPv4 Connections Established
TCPv6 Connections Established
W3SVC\$1W3WP File Cache Flushes
W3SVC\$1W3WP File Cache Misses
W3SVC\$1W3WP Requests/Sec
W3SVC\$1W3WP URI Cache Flushes
W3SVC\$1W3WP URI Cache Misses
Web Service Bytes Received/Sec
Web Service Bytes Sent/Sec
Web Service Connection attempts/sec
Web Service Current Connections
Web Service Get Requests/sec
Web Service Post Requests/sec
受信したバイト数/秒
通常のメッセージキューの長さ/秒
緊急のメッセージキューの長さ/秒
再接続の回数
未確認のメッセージキューの長さ/秒
未処理のメッセージ
送信されたメッセージ/秒
データベース更新メッセージ/秒
更新メッセージ/秒
フラッシュ/秒
保存された暗号化のチェックポイント/秒
復元された暗号化のチェックポイント/秒
復元されたレジストリのチェックポイント/秒
保存されたレジストリのチェックポイント/秒
クラスターでの API コール/秒
リソースでの API コール/秒
クラスターでの処理/秒
リソースでの処理/秒
## CloudWatch エージェントのプロセスメトリクス (Windows サーバー)
プロセスメトリクスは、[CloudWatch エージェント procstat プラグイン](CloudWatch-Agent-procstat-process-metrics.md)を使用して収集されます。Windows ワークロードを実行する Amazon EC2 インスタンスのみがプロセスメトリクスをサポートします。
procstat cpu\$1time\$1system
procstat cpu\$1time\$1user
procstat cpu\$1usage
procstat memory\$1rss
procstat memory\$1vms
procstat read\$1bytes
procstat write\$1bytes
.procstat read\$1count
procstat write\$1count
## CloudWatch エージェントのメトリクス (Linux サーバー)
cpu\$1time\$1active
cpu\$1time\$1guest
cpu\$1time\$1guest\$1nice
cpu\$1time\$1idle
cpu\$1time\$1iowait
cpu\$1time\$1irq
cpu\$1time\$1nice
cpu\$1time\$1softirq
cpu\$1time\$1steal
cpu\$1time\$1system
cpu\$1time\$1user
cpu\$1usage\$1active
cpu\$1usage\$1guest
cpu\$1usage\$1guest\$1nice
cpu\$1usage\$1idle
cpu\$1usage\$1iowait
cpu\$1usage\$1irq
cpu\$1usage\$1nice
cpu\$1usage\$1softirq
cpu\$1usage\$1steal
cpu\$1usage\$1system
cpu\$1usage\$1user
disk\$1free
disk\$1inodes\$1free
disk\$1inodes\$1used
disk\$1used
disk\$1used\$1percent
diskio\$1io\$1time
diskio\$1iops\$1in\$1progress
diskio\$1read\$1bytes
diskio\$1read\$1time
diskio\$1reads
diskio\$1write\$1bytes
diskio\$1write\$1time
diskio\$1writes
mem\$1active
mem\$1available
mem\$1available\$1percent
mem\$1buffered
mem\$1cached
mem\$1free
mem\$1inactive
mem\$1used
mem\$1used\$1percent
net\$1bytes\$1recv
net\$1bytes\$1sent
net\$1drop\$1in
net\$1drop\$1out
net\$1err\$1in
net\$1err\$1out
net\$1packets\$1recv
net\$1packets\$1sent
netstat\$1tcp\$1close
netstat\$1tcp\$1close\$1wait
netstat\$1tcp\$1closing
netstat\$1tcp\$1established
netstat\$1tcp\$1fin\$1wait1
netstat\$1tcp\$1fin\$1wait2
netstat\$1tcp\$1last\$1ack
netstat\$1tcp\$1listen
netstat\$1tcp\$1none
netstat\$1tcp\$1syn\$1recv
netstat\$1tcp\$1syn\$1sent
netstat\$1tcp\$1time\$1wait
netstat\$1udp\$1socket
processes\$1blocked
processes\$1dead
processes\$1idle
processes\$1paging
processes\$1running
processes\$1sleeping
processes\$1stopped
processes\$1total
processes\$1total\$1threads
processes\$1wait
processes\$1zombies
swap\$1free
swap\$1used
swap\$1used\$1percent
# Elastic Block Store (EBS)
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
VolumeReadBytes
VolumeWriteBytes
VolumeReadOps
VolumeWriteOps
VolumeTotalReadTime
VolumeTotalWriteTime
VolumeIdleTime
VolumeQueueLength
VolumeThroughputPercentage
VolumeConsumedReadWriteOps
BurstBalance
# Amazon Elastic File System (Amazon EFS)
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
BurstCreditBalance
PercentIOLimit
PermittedThroughput
MeteredIOBytes
TotalIOBytes
DataWriteIOBytes
DataReadIOBytes
MetadataIOBytes
ClientConnections
TimeSinceLastSync
StorageBytes
スループット
PercentageOfPermittedThroughputUtilization
ThroughputIOPS
PercentThroughputDataReadIOByte
PercentThroughputDataWriteIOBytes
PercentageOfIOPSDataReadIOBytes
PercentageOfIOPSDataWriteIOBytes
AverageDataReadIOBytesSize
AverageDataWriteIOBytesSize
# Elastic Load Balancer (ELB)
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
EstimatedALBActiveConnectionCount
EstimatedALBConsumedLCUs
EstimatedALBNewConnectionCount
EstimatedProcessedBytes
HTTPCode\$1Backend\$14XX
HTTPCode\$1Backend\$15XX
HealthyHostCount
RequestCount
UnHealthyHostCount
# Application ELB
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
EstimatedALBActiveConnectionCount
EstimatedALBConsumedLCUs
EstimatedALBNewConnectionCount
EstimatedProcessedBytes
HTTPCode\$1Backend\$14XX
HTTPCode\$1Backend\$15XX
HealthyHostCount
レイテンシー
RequestCount
SurgeQueueLength
UnHealthyHostCount
# Amazon EC2 Auto Scaling グループ
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
CPUCreditBalance
CPUCreditUsage
CPUSurplusCreditBalance
CPUSurplusCreditsCharged
CPUUtilization
DiskReadBytes
DiskReadOps
DiskWriteBytes
DiskWriteOps
EBSByteBalance%
EBSIOBalance%
EBSReadBytes
EBSReadOps
EBSWriteBytes
EBSWriteOps
NetworkIn
NetworkOut
NetworkPacketsIn
NetworkPacketsOut
StatusCheckFailed
StatusCheckFailed\$1Instance
StatusCheckFailed\$1System
# Amazon Simple Queue Server (SQS)
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
ApproximateAgeOfOldestMessage
ApproximateNumberOfMessagesDelayed
ApproximateNumberOfMessagesNotVisible
ApproximateNumberOfMessagesVisible
NumberOfEmptyReceives
NumberOfMessagesDeleted
NumberOfMessagesReceived
NumberOfMessagesSent
# Amazon Relational Database Service (RDS)
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
**Topics**
+ [
## RDS データベースインスタンス
](#appinsights-metrics-rds-instances)
+ [
## RDS データベースクラスター
](#appinsights-metrics-rds-clusters)
## RDS データベースインスタンス
BurstBalance
CPUCreditBalance
CPUUtilization
DatabaseConnections
DiskQueueDepth
FailedSQLServerAgentJobsCount
FreeStorageSpace
FreeableMemory
NetworkReceiveThroughput
NetworkTransmitThroughput
ReadIOPS
ReadLatency
ReadThroughput
WriteIOPS
WriteLatency
WriteThroughput
## RDS データベースクラスター
ActiveTransactions
AuroraBinlogReplicaLag
AuroraReplicaLag
BackupRetentionPeriodStorageUsed
BinLogDiskUsage
BlockedTransactions
BufferCacheHitRatio
CPUUtilization
CommitLatency
CommitThroughput
DDLLatency
DDLThroughput
DMLLatency
DMLThroughput
DatabaseConnections
デッドロック
DeleteLatency
DeleteThroughput
EngineUptime
FreeLocalStorage
FreeableMemory
InsertLatency
InsertThroughput
LoginFailures
NetworkReceiveThroughput
NetworkThroughput
NetworkTransmitThroughput
クエリ
ResultSetCacheHitRatio
SelectLatency
SelectThroughput
SnapshotStorageUsed
TotalBackupStorageBilled
UpdateLatency
UpdateThroughput
VolumeBytesUsed
VolumeReadiOps
VolumeWriteIOPs
# AWS Lambda 関数
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
エラー
DeadLetterErrors
所要時間
スロットリング
IteratorAge
ProvisionedConcurrencySpilloverInvocations
# Amazon DynamoDB テーブル
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
SystemErrors
UserErrors
ConsumedReadCapacityUnits
ConsumedWriteCapacityUnits
調整イベントの読み込み
調整イベントの書き込み
TimeToLiveDeletedItemCount
条件チェックが失敗したリクエスト
TransactionConflict
ReturnedRecordsCount
PendingReplicationCount
ReplicationLatency
# Amazon S3 バケット
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
ReplicationLatency
BytesPendingReplication
OperationsPendingReplication
4xxErrors
5xxErrors
AllRequests
GetRequests
PutRequests
DeleteRequests
HeadRequests
PostRequests
SelectRequests
ListRequests
SelectScannedBytes
SelectReturnedBytes
FirstByteLatency
TotalRequestLatency
BytesDownloaded
BytesUploaded
# AWS Step Functions
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
**Topics**
+ [
## Execution-level
](#appinsights-metrics-step-functions-execution)
+ [
## アクティビティ
](#appinsights-metrics-step-functions-activity)
+ [
## Lambda 関数
](#appinsights-metrics-step-functions-lambda)
+ [
## サービス統合
](#appinsights-metrics-step-functions-service-integration)
+ [
## Step Functions API
](#appinsights-metrics-step-functions-api)
## Execution-level
ExecutionTime
ExecutionThrottled
ExecutionsFailed
ExecutionsTimedOut
ExecutionsAborted
ExecutionsSucceeded
ExecutionsStarted
## アクティビティ
ActivityRunTime
ActivityScheduleTime
ActivityTime
ActivitiesFailed
ActivitiesHeartbeatTimedOut
ActivitiesTimedOut
ActivitiesScheduled
ActivitiesSucceeded
ActivitiesStarted
## Lambda 関数
LambdaFunctionRunTime
LambdaFunctionScheduleTime
LambdaFunctionTime
LambdaFunctionsFailed
LambdaFunctionsTimedOut
LambdaFunctionsScheduled
LambdaFunctionsSucceeded
LambdaFunctionsStarted
## サービス統合
ServiceIntegrationRunTime
ServiceIntegrationScheduleTime
ServiceIntegrationTime
ServiceIntegrationsFailed
ServiceIntegrationsTimedOut
ServiceIntegrationsScheduled
ServiceIntegrationsSucceeded
ServiceIntegrationsStarted
## Step Functions API
ThrottledEvents
ProvisionedBucketSize
ProvisionedRefillRate
ConsumedCapacity
# API Gateway REST API ステージ
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
4XXError
5XXError
IntegrationLatency
レイテンシー
CacheHitCount
CacheMissCount
# SAP HANA
**注記**
CloudWatch Application Insights は、単一の SID HANA 環境のみをサポートしています。複数の HANA SID がアタッチされている場合、最初に検出された SID に対してのみモニターリングがセットアップされます。
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
hanadb\$1every\$1service\$1started\$1status
hanadb\$1daemon\$1service\$1started\$1status
hanadb\$1preprocessor\$1service\$1started\$1status
hanadb\$1webdispatcher\$1service\$1started\$1status
hanadb\$1compileserver\$1service\$1started\$1status
hanadb\$1nameserver\$1service\$1started\$1status
hanadb\$1server\$1startup\$1time\$1variations\$1seconds
hanadb\$1level\$15\$1alerts\$1count
hanadb\$1level\$14\$1alerts\$1count
hanadb\$1out\$1of\$1memory\$1events\$1count
hanadb\$1max\$1trigger\$1read\$1ratio\$1percent
hanadb\$1max\$1trigger\$1write\$1ratio\$1percent
hanadb\$1log\$1switch\$1wait\$1ratio\$1percent
hanadb\$1log\$1switch\$1race\$1ratio\$1percent
hanadb\$1time\$1since\$1last\$1savepoint\$1seconds
hanadb\$1disk\$1usage\$1highlevel\$1percent
hanadb\$1max\$1converter\$1page\$1number\$1count
hanadb\$1long\$1running\$1savepoints\$1count
hanadb\$1failed\$1io\$1reads\$1count
hanadb\$1failed\$1io\$1writes\$1count
hanadb\$1disk\$1data\$1unused\$1percent
hanadb\$1current\$1allocation\$1limit\$1used\$1percent
hanadb\$1table\$1allocation\$1limit\$1used\$1percent
hanadb\$1host\$1total\$1physical\$1memory\$1mb
hanadb\$1host\$1physical\$1memory\$1used\$1mb
hanadb\$1host\$1physical\$1memory\$1free\$1mb
hanadb\$1swap\$1memory\$1free\$1mb
hanadb\$1swap\$1memory\$1used\$1mb
hanadb\$1host\$1allocation\$1limit\$1mb
hanadb\$1host\$1total\$1memory\$1used\$1mb
hanadb\$1host\$1total\$1peak\$1memory\$1used\$1mb
hanadb\$1host\$1total\$1allocation\$1limit\$1mb
hanadb\$1host\$1code\$1size\$1mb
hanadb\$1host\$1shared\$1memory\$1allocation\$1mb
hanadb\$1cpu\$1usage\$1percent
hanadb\$1cpu\$1user\$1percent
hanadb\$1cpu\$1system\$1percent
hanadb\$1cpu\$1waitio\$1percent
hanadb\$1cpu\$1busy\$1percent
hanadb\$1cpu\$1idle\$1percent
hanadb\$1long\$1delta\$1merge\$1count
hanadb\$1unsuccessful\$1delta\$1merge\$1count
hanadb\$1successful\$1delta\$1merge\$1count
hanadb\$1row\$1store\$1allocated\$1size\$1mb
hanadb\$1row\$1store\$1free\$1size\$1mb
hanadb\$1row\$1store\$1used\$1size\$1mb
hanadb\$1temporary\$1tables\$1count
hanadb\$1large\$1non\$1compressed\$1tables\$1count
hanadb\$1total\$1non\$1compressed\$1tables\$1count
hanadb\$1longest\$1running\$1job\$1seconds
hanadb\$1average\$1commit\$1time\$1milliseconds
hanadb\$1suspended\$1sql\$1statements\$1count
hanadb\$1plan\$1cache\$1hit\$1ratio\$1percent
hanadb\$1plan\$1cache\$1lookup\$1count
hanadb\$1plan\$1cache\$1hit\$1count
hanadb\$1plan\$1cache\$1total\$1execution\$1microseconds
hanadb\$1plan\$1cache\$1cursor\$1duration\$1microseconds
hanadb\$1plan\$1cache\$1preparation\$1microseconds
hanadb\$1plan\$1cache\$1evicted\$1count
hanadb\$1plan\$1cache\$1evicted\$1microseconds
hanadb\$1plan\$1cache\$1evicted\$1preparation\$1count
hanadb\$1plan\$1cache\$1evicted\$1execution\$1count
hanadb\$1plan\$1cache\$1evicted\$1preparation\$1microseconds
hanadb\$1plan\$1cache\$1evicted\$1cursor\$1duration\$1microseconds
hanadb\$1plan\$1cache\$1evicted\$1total\$1execution\$1microseconds
hanadb\$1plan\$1cache\$1evicted\$1plan\$1size\$1mb
hanadb\$1plan\$1cache\$1count
hanadb\$1plan\$1cache\$1preparation\$1count
hanadb\$1plan\$1cache\$1execution\$1count
hanadb\$1network\$1collision\$1rate
hanadb\$1network\$1receive\$1rate
hanadb\$1network\$1transmit\$1rate
hanadb\$1network\$1packet\$1receive\$1rate
hanadb\$1network\$1packet\$1transmit\$1rate
hanadb\$1network\$1transmit\$1error\$1rate
hanadb\$1network\$1receive\$1error\$1rate
hanadb\$1time\$1until\$1license\$1expires\$1days
hanadb\$1is\$1license\$1valid\$1status
hanadb\$1local\$1running\$1connections\$1count
hanadb\$1local\$1idle\$1connections\$1count
hanadb\$1remote\$1running\$1connections\$1count
hanadb\$1remote\$1idle\$1connections\$1count
hanadb\$1last\$1full\$1data\$1backup\$1age\$1days
hanadb\$1last\$1data\$1backup\$1age\$1days
hanadb\$1last\$1log\$1backup\$1age\$1hours
hanadb\$1failed\$1data\$1backup\$1past\$17\$1days\$1count
hanadb\$1failed\$1log\$1backup\$1past\$17\$1days\$1count
hanadb\$1oldest\$1backup\$1in\$1catalog\$1age\$1days
hanadb\$1backup\$1catalog\$1size\$1mb
hanadb\$1hsr\$1replication\$1status
hanadb\$1hsr\$1log\$1shipping\$1delay\$1seconds
hanadb\$1hsr\$1secondary\$1failover\$1count
hanadb\$1hsr\$1secondary\$1reconnect\$1count
hanadb\$1hsr\$1async\$1buffer\$1used\$1mb
hanadb\$1hsr\$1secondary\$1active\$1status
hanadb\$1handle\$1count
hanadb\$1ping\$1time\$1milliseconds
hanadb\$1connection\$1count
hanadb\$1internal\$1connection\$1count
hanadb\$1external\$1connection\$1count
hanadb\$1idle\$1connection\$1count
hanadb\$1transaction\$1count
hanadb\$1internal\$1transaction\$1count
hanadb\$1external\$1transaction\$1count
hanadb\$1user\$1transaction\$1count
hanadb\$1blocked\$1transaction\$1count
hanadb\$1statement\$1count
hanadb\$1active\$1commit\$1id\$1range\$1count
hanadb\$1mvcc\$1version\$1count
hanadb\$1pending\$1session\$1count
hanadb\$1record\$1lock\$1count
hanadb\$1read\$1count
hanadb\$1write\$1count
hanadb\$1merge\$1count
hanadb\$1unload\$1count
hanadb\$1active\$1thread\$1count
hanadb\$1waiting\$1thread\$1count
hanadb\$1total\$1thread\$1count
hanadb\$1active\$1sql\$1executor\$1count
hanadb\$1waiting\$1sql\$1executor\$1count
hanadb\$1total\$1sql\$1executor\$1count
hanadb\$1data\$1write\$1size\$1mb
hanadb\$1data\$1write\$1time\$1milliseconds
hanadb\$1log\$1write\$1size\$1mb
hanadb\$1log\$1write\$1time\$1milliseconds
hanadb\$1data\$1read\$1size\$1mb
hanadb\$1data\$1read\$1time\$1milliseconds
hanadb\$1log\$1read\$1size\$1mb
hanadb\$1log\$1read\$1time\$1milliseconds
hanadb\$1data\$1backup\$1write\$1size\$1mb
hanadb\$1data\$1backup\$1write\$1time\$1milliseconds
hanadb\$1log\$1backup\$1write\$1size\$1mb
hanadb\$1log\$1backup\$1write\$1time\$1milliseconds
hanadb\$1mutex\$1collision\$1count
hanadb\$1read\$1write\$1lock\$1collision\$1count
hanadb\$1admission\$1control\$1admit\$1count
hanadb\$1admission\$1control\$1reject\$1count
hanadb\$1admission\$1control\$1queue\$1size\$1mb
hanadb\$1admission\$1control\$1wait\$1time\$1milliseconds
# SAP ASE
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
asedb\$1database\$1availability
asedb\$1trunc\$1log\$1on\$1chkpt\$1enabled
asedb\$1last\$1db\$1backup\$1age\$1in\$1days
asedb\$1last\$1transaction\$1log\$1backup\$1age\$1in\$1hours
asedb\$1suspected\$1database
asedb\$1db\$1space\$1usage\$1percent
asedb\$1db\$1log\$1space\$1usage\$1percent
asedb\$1locked\$1login
asedb\$1has\$1mixed\$1log\$1and\$1data
asedb\$1runtime\$1for\$1open\$1transactions
asedb\$1data\$1cache\$1hit\$1ratio
asedb\$1data\$1cache\$1usage
asedb\$1sql\$1cache\$1hit\$1ratio
asedb\$1cache\$1usage
asedb\$1run\$1queue\$1length
asedb\$1number\$1of\$1rollbacks
asedb\$1number\$1of\$1commits
asedb\$1number\$1of\$1transactions
asedb\$1outstanding\$1disk\$1io
asedb\$1percent\$1io\$1busy
asedb\$1percent\$1system\$1busy
asedb\$1percent\$1locks\$1active
asedb\$1scheduled\$1jobs\$1failed\$1percent
asedb\$1user\$1connections\$1percent
asedb\$1query\$1logical\$1reads
asedb\$1query\$1physical\$1reads
asedb\$1query\$1cpu\$1time
asedb\$1query\$1memory\$1usage
# Amazon EC2 での SAP ASE High Availability
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
asedb\$1ha\$1replication\$1state
asedb\$1ha\$1replication\$1mode
asedb\$1ha\$1replication\$1latency\$1in\$1minutes
# SAP NetWeaver
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
| メトリクス | 説明 |
| --- | --- |
| sap\$1alerts\$1ResponseTime | CCMS (RZ20)>R3Services>Dialog>ResponseTime からの SAP 応答時間アラート。 |
| sap\$1alerts\$1ResponseTimeDialog | CCMS (RZ20)>R3Services>Dialog> ResponseTimeDialog からの SAP 応答時間ダイアログアラート。 |
| sap\$1alerts\$1ResponseTimeDialogRFC | CCMS (RZ20)>R3Services> Dialog>ResponseTimeDialogRFC からの SAP 応答時間アラート。 |
| sap\$1alerts\$1DBRequestTime | CCMS (RZ20)>R3Services>Dialog>DBRequestTime からの SAP 応答時間アラート。 |
| sap\$1alerts\$1FrontendResponseTime | CCMS (RZ20)>R3Services > Dialog>FrontEndResponseTime からの SAP 応答時間アラート。 |
| sap\$1alerts\$1Database | SAP システムが、データベース関連のエラーをログに記録しました。SM21 または CCMS (RZ20)>R3Syslog>Database からのアラート。 |
| sap\$1alerts\$1QueueTime | CCMS (RZ20)>R3Services>Dialog>QueueTime からの SAP キュータイムアラート。 |
| sap\$1alerts\$1AbortedJobs | SAP システムのバックグラウンドジョブが失敗しました。(RZ20)>R3Services > Background>AbortedJobs からのアラート。 |
| sap\$1alerts\$1BasisSystem | SAP システムがシステムレベルのエラーをログに記録しました。SM21 または CCMS (RZ20)>R3Syslog>BasisSystem からのアラート。 |
| sap\$1alerts\$1Security | SAP システムは、セキュリティ関連のメッセージをログに記録しました。SM21 または CCMS (RZ20)>R3Syslog>Security からのアラート。 |
| sap\$1alerts\$1System | SAP システムは、セキュリティまたは監査関連のメッセージをログに記録しました。SM21 または CCMS (RZ20)>Security>System からのアラート。 |
| sap\$1alerts\$1LongRunners | SAP システムには実行時間の長いプログラムがあります。CCMS (RZ20)>R3Services > Dialog>LongRunners からのアラート。 |
| sap\$1alerts\$1SqlError | SAP データベースのクライアントレイヤーのエラーログが存在します。CCMS(RZ20)>DatabaseClient>AbapSql>SqlError からのアラート。 |
| sap\$1alerts\$1State | CCMS (RZ20)>OS Collector>State からの状態アラート。 |
| sap\$1alerts\$1Shortdumps | ST22 および CCMS (RZ20)>R3Abap>Shortdumps からのショートダンプアラート。 |
| sap\$1alerts\$1Availability | SM21、SM50、SM51、SM66、および CCMS (RZ20)>InstanceAsTask>Availability からの SAP アプリケーションサーバーインスタンスの可用性アラート。 |
| sap\$1dispatcher\$1queue\$1high | SAPControl Web サービス関数 GetQueueStatistic は、ディスパッチャキューの上限数を提供します。 |
| sap\$1dispatcher\$1queue\$1max | SAPControl Web サービス関数 GetQueueStatistic は、ディスパッチャキューの最大数を提供します。 |
| sap\$1dispatcher\$1queue\$1now | SAPControl Web サービス関数 GetQueueStatistic は、ディスパッチャキューの現在の数を提供します。 |
| sap\$1dispatcher\$1queue\$1reads | SAPControl Web サービス関数 GetQueueStatistic は、ディスパッチャキューの読み込み回数を提供します。 |
| sap\$1dispatcher\$1queue\$1writes | SAPControl Web サービス関数 GetQueueStatistic は、ディスパッチャキューの書き込み回数を提供します。 |
| sap\$1enqueue\$1server\$1arguments\$1high | SAPControl Web サービス関数 EnqGetStatistic は、高い値のエンキュー引数を提供します。 |
| sap\$1enqueue\$1server\$1arguments\$1max | SAPControl Web サービス関数 EnqGetStatistic は、最大値のエンキュー引数を提供します。 |
| sap\$1enqueue\$1server\$1arguments\$1now | SAPControl Web サービス関数 EnqGetStatistic は、現在の値のエンキュー引数を提供します。 |
| sap\$1enqueue\$1server\$1arguments\$1state | SAPControl Web サービス関数 EnqGetStatistic は、エンキュー引数の状態を提供します。 |
| sap\$1enqueue\$1server\$1backup\$1requests | SAPControl Web サービス関数 EnqGetStatistic は、エンキューのバックアップリクエスト数を提供します。 |
| sap\$1enqueue\$1server\$1cleanup\$1requests | SAPControl Web サービス関数 EnqGetStatistic は、エンキューのクリーンアップリクエスト数を提供します。 |
| sap\$1enqueue\$1server\$1dequeue\$1all\$1requests | SAPControl Web サービス関数 EnqGetStatistic は、すべてのデキューリクエスト数を提供します。 |
| sap\$1enqueue\$1server\$1dequeue\$1errors | SAPControl Web サービス関数 EnqGetStatistic は、デキューエラー数を提供します。 |
| sap\$1enqueue\$1server\$1dequeue\$1requests | SAPControl Web サービス関数 EnqGetStatistic は、デキューリクエスト数を提供します。 |
| sap\$1enqueue\$1server\$1enqueue\$1errors | SAPControl Web サービス関数 EnqGetStatistic は、エンキューエラー数を提供します。 |
| sap\$1enqueue\$1server\$1enqueue\$1rejects | SAPControl Web サービス関数 EnqGetStatistic は、エンキューが拒否された回数を提供します。 |
| sap\$1enqueue\$1server\$1enqueue\$1requests | SAPControl Web サービス関数 EnqGetStatistic は、エンキューリクエスト数を提供します。 |
| sap\$1enqueue\$1server\$1lock\$1time | SAPControl Web サービス関数 EnqGetStatistic は、エンキューロックの時刻を提供します。 |
| sap\$1enqueue\$1server\$1lock\$1wait\$1time | SAPControl Web サービス関数 EnqGetStatistic は、エンキューロックの待機時間を提供します。 |
| sap\$1enqueue\$1server\$1locks\$1high | SAPControl Web サービス関数 EnqGetStatistic は、エンキューロックの高い数値の数を提供します。 |
| sap\$1enqueue\$1server\$1locks\$1max | SAPControl Web サービス関数 EnqGetStatistic は、エンキューロックの最大数を提供します。 |
| sap\$1enqueue\$1server\$1locks\$1now | SAPControl Web サービス関数 EnqGetStatistic は、エンキューロックの現在の数を提供します。 |
| sap\$1enqueue\$1server\$1locks\$1state | SAPControl Web サービス関数 EnqGetStatistic は、エンキューロックの状態を提供します。 |
| sap\$1enqueue\$1server\$1owner\$1high | SAPControl Web サービス関数 EnqGetStatistic は、エンキュー所有者の高い数値の数を提供します。 |
| sap\$1enqueue\$1server\$1owner\$1max | SAPControl Web サービス関数 EnqGetStatistic は、エンキュー所有者の最大数を提供します。 |
| sap\$1enqueue\$1server\$1owner\$1now | SAPControl Web サービス関数 EnqGetStatistic は、エンキュー所有者の現在の数を提供します。 |
| sap\$1enqueue\$1server\$1owner\$1state | SAPControl Web サービス関数 EnqGetStatistic は、エンキュー所有者の状態を提供します。 |
| sap\$1enqueue\$1server\$1replication\$1state | SAPControl Web サービス関数 EnqGetStatistic は、エンキューのレプリケーション状態ステータスを提供します。 |
| sap\$1enqueue\$1server\$1reporting\$1requests | SAPControl Web サービス関数 EnqGetStatistic は、レポートリクエストのステータスを提供します。 |
| sap\$1enqueue\$1server\$1server\$1time | SAPControl Web サービス関数 EnqGetStatistic は、エンキューサーバー時間を提供します。 |
| sap\$1HA\$1check\$1failover\$1config\$1state | SAPControl Web サービス関数 HACheckFailoverConfig は、SAP High Availability のステータスを提供します。 |
| sap\$1HA\$1get\$1failover\$1config\$1HAActive | SAPControl Web サービス関数 HAGetFailoverConfig は、SAP High Availability クラスターの設定とステータスを提供します。 |
| sap\$1start\$1service\$1processes | SAPControl Web サービス関数 GetProcessList は、disp\$1work、IGS、gwrd、icman、メッセージサーバー、およびエンキューサーバープロセスのステータスを提供します。 |
# HA Cluster
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
ha\$1cluster\$1pacemaker\$1stonith\$1enabled
ha\$1cluster\$1corosync\$1quorate
hanadb\$1webdispatcher\$1service\$1started\$1status
ha\$1cluster\$1pacemaker\$1nodes
ha\$1cluster\$1corosync\$1ring\$1errors
ha\$1cluster\$1pacemaker\$1fail\$1count
# Java
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
java\$1lang\$1memory\$1heapmemoryusage\$1used
java\$1lang\$1memory\$1heapmemoryusage\$1committed
java\$1lang\$1operatingsystem\$1openfiledescriptorcount
java\$1lang\$1operatingsystem\$1maxfiledescriptorcount
java\$1lang\$1operatingsystem\$1freephysicalmemorysize
java\$1lang\$1operatingsystem\$1freeswapspacesize
java\$1lang\$1threading\$1threadcount
java\$1lang\$1threading\$1daemonthreadcount
java\$1lang\$1classloading\$1loadedclasscount
java\$1lang\$1garbagecollector\$1collectiontime\$1copy
java\$1lang\$1garbagecollector\$1collectiontime\$1ps\$1scavenge
java\$1lang\$1garbagecollector\$1collectiontime\$1parnew
java\$1lang\$1garbagecollector\$1collectiontime\$1marksweepcompact
java\$1lang\$1garbagecollector\$1collectiontime\$1ps\$1marksweep
java\$1lang\$1garbagecollector\$1collectiontime\$1concurrentmarksweep
java\$1lang\$1garbagecollector\$1collectiontime\$1g1\$1young\$1generation
java\$1lang\$1garbagecollector\$1collectiontime\$1g1\$1old\$1generation
java\$1lang\$1garbagecollector\$1collectiontime\$1g1\$1mixed\$1generation
java\$1lang\$1operatingsystem\$1committedvirtualmemorysize
# Amazon Elastic Container Service (Amazon ECS)
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
**Topics**
+ [
## CloudWatch の組み込みメトリクス
](#appinsights-metrics-ecs-built-in-metrics)
+ [
## Container Insights のメトリクス
](#appinsights-metrics-ecs-container-insights-metrics)
+ [
## Container Insights Prometheus メトリクス
](#appinsights-metrics-ecs-container-insights-prometheus)
## CloudWatch の組み込みメトリクス
CPUReservation
CPUUtilization
MemoryReservation
MemoryUtilization
GPUReservation
## Container Insights のメトリクス
ContainerInstanceCount
CpuUtilized
CpuReserved
DeploymentCount
DesiredTaskCount
MemoryUtilized
MemoryReserved
NetworkRxBytes
NetworkTxBytes
PendingTaskCount
RunningTaskCount
ServiceCount
StorageReadBytes
StorageWriteBytes
TaskCount
TaskSetCount
instance\$1cpu\$1limit
instance\$1cpu\$1reserved\$1capacity
instance\$1cpu\$1usage\$1total
instance\$1cpu\$1utilization
instance\$1filesystem\$1utilization
instance\$1memory\$1limit
instance\$1memory\$1reserved\$1capacity
instance\$1memory\$1utilization
instance\$1memory\$1working\$1set
instance\$1network\$1total\$1bytes
instance\$1number\$1of\$1running\$1tasks
## Container Insights Prometheus メトリクス
**Java JMX メトリクス**
java\$1lang\$1memory\$1heapmemoryusage\$1used
java\$1lang\$1memory\$1heapmemoryusage\$1committed
java\$1lang\$1operatingsystem\$1openfiledescriptorcount
java\$1lang\$1operatingsystem\$1maxfiledescriptorcount
java\$1lang\$1operatingsystem\$1freephysicalmemorysize
java\$1lang\$1operatingsystem\$1freeswapspacesize
java\$1lang\$1threading\$1threadcount
java\$1lang\$1classloading\$1loadedclasscount
java\$1lang\$1threading\$1daemonthreadcount
java\$1lang\$1garbagecollector\$1collectiontime\$1copy
java\$1lang\$1garbagecollector\$1collectiontime\$1ps\$1scavenge
java\$1lang\$1garbagecollector\$1collectiontime\$1parnew
java\$1lang\$1garbagecollector\$1collectiontime\$1marksweepcompact
java\$1lang\$1garbagecollector\$1collectiontime\$1ps\$1marksweep
java\$1lang\$1garbagecollector\$1collectiontime\$1concurrentmarksweep
java\$1lang\$1garbagecollector\$1collectiontime\$1g1\$1young\$1generation
java\$1lang\$1garbagecollector\$1collectiontime\$1g1\$1old\$1generation
java\$1lang\$1garbagecollector\$1collectiontime\$1g1\$1mixed\$1generation
java\$1lang\$1operatingsystem\$1committedvirtualmemorysize
# AWS での Kubernetes
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
**Topics**
+ [
## Container Insights のメトリクス
](#appinsights-metrics-kubernetes-container-insights-metrics)
+ [
## Container Insights Prometheus メトリクス
](#appinsights-metrics-kubernetes-container-insights-prometheus)
## Container Insights のメトリクス
cluster\$1failed\$1node\$1count
cluster\$1node\$1count
namespace\$1number\$1of\$1running\$1pods
node\$1cpu\$1limit
node\$1cpu\$1reserved\$1capacity
node\$1cpu\$1usage\$1total
node\$1cpu\$1utilization
node\$1filesystem\$1utilization
node\$1memory\$1limit
node\$1memory\$1reserved\$1capacity
node\$1memory\$1utilization
node\$1memory\$1working\$1set
node\$1network\$1total\$1bytes
node\$1number\$1of\$1running\$1containers
node\$1number\$1of\$1running\$1pods
pod\$1cpu\$1reserved\$1capacity
pod\$1cpu\$1utilization
pod\$1cpu\$1utilization\$1over\$1pod\$1limit
pod\$1memory\$1reserved\$1capacity
pod\$1memory\$1utilization
pod\$1memory\$1utilization\$1over\$1pod\$1limit
pod\$1network\$1rx\$1bytes
pod\$1network\$1tx\$1bytes
service\$1number\$1of\$1running\$1pods
## Container Insights Prometheus メトリクス
**Java JMX メトリクス**
java\$1lang\$1memory\$1heapmemoryusage\$1used
java\$1lang\$1memory\$1heapmemoryusage\$1committed
java\$1lang\$1operatingsystem\$1openfiledescriptorcount
java\$1lang\$1operatingsystem\$1maxfiledescriptorcount
java\$1lang\$1operatingsystem\$1freephysicalmemorysize
java\$1lang\$1operatingsystem\$1freeswapspacesize
java\$1lang\$1threading\$1threadcount
java\$1lang\$1classloading\$1loadedclasscount
java\$1lang\$1threading\$1daemonthreadcount
java\$1lang\$1garbagecollector\$1collectiontime\$1copy
java\$1lang\$1garbagecollector\$1collectiontime\$1ps\$1scavenge
java\$1lang\$1garbagecollector\$1collectiontime\$1parnew
java\$1lang\$1garbagecollector\$1collectiontime\$1marksweepcompact
java\$1lang\$1garbagecollector\$1collectiontime\$1ps\$1marksweep
java\$1lang\$1garbagecollector\$1collectiontime\$1concurrentmarksweep
java\$1lang\$1garbagecollector\$1collectiontime\$1g1\$1young\$1generation
java\$1lang\$1garbagecollector\$1collectiontime\$1g1\$1old\$1generation
java\$1lang\$1garbagecollector\$1collectiontime\$1g1\$1mixed\$1generation
java\$1lang\$1operatingsystem\$1committedvirtualmemorysize
# Amazon FSx
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
DataReadBytes
DataWriteBytes
DataReadOperations
DataWriteOperations
MetadataOperations
FreeStorageCapacity
FreeDataStorageCapacity
LogicalDiskUsage
PhysicalDiskUsage
# Amazon VPC
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
NetworkAddressUsage
NetworkAddressUsagePeered
VPCFirewallQueryVolume
# Amazon VPC NAT ゲートウェイ
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
ErrorPortAllocation
IdleTimeoutCount
# Amazon Route 53 ヘルスチェック
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
ChildHealthCheckHealthyCount
ConnectionTime
HealthCheckPercentageHealthy
HealthCheckStatus
SSLHandshakeTime
TimeToFirstByte
# Amazon Route 53 ホストゾーン
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
DNSQueries
DNSSECInternalFailure
DNSSECKeySigningKeysNeedingAction
DNSSECKeySigningKeyMaxNeedingActionAge
DNSSECKeySigningKeyAge
# Amazon Route 53 Resolver エンドポイント
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
EndpointHealthyENICount
EndpointUnHealthyENICount
InboundQueryVolume
OutboundQueryVolume
OutboundQueryAggregateVolume
# AWS Network Firewall ルールグループ
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
FirewallRuleGroupQueryVolume
# AWS Network Firewall ルールグループ関連付け
CloudWatch Application Insights でサポートされるメトリクスは次のとおりです。
FirewallRuleGroupVpcQueryVolume
# メトリクスのデータポイント要件
アラームを発生させるデフォルトのしきい値が明確でないメトリクスの場合、Application Insights は、アラームを発生させるしきい値を適切に予測できるだけのデータポイント数が得られるまで待機します。アラームが作成される前に CloudWatch Application Insights で確認するメトリクスのデータポイント要件は次のとおりです。
+ メトリクスのデータポイントが、過去 15 日から 2 日までの間に 100 個以上あること。
+ メトリクスのデータポイントが、最終日から 100 個以上あること。
次のメトリクスは、上記のデータポイント要件に従います。CloudWatch エージェントのメトリクスは、アラームの作成に最大 1 時間を必要とします。
**Topics**
+ [
## AWS/ApplicationELB
](#appinsights-metrics-datapoint-requirements-app-elb)
+ [
## AWS Autoscaling
](#appinsights-metrics-datapoint-requirements-autoscaling)
+ [
## AWS/EC2
](#appinsights-metrics-datapoint-requirements-ec2)
+ [
## Elastic Block Store (EBS)
](#appinsights-metrics-datapoint-requirements-ebs)
+ [
## AWS/ELB
](#appinsights-metrics-datapoint-requirements-elb)
+ [
## AWS/RDS
](#appinsights-metrics-datapoint-requirements-rds)
+ [
## AWS/Lambda
](#appinsights-metrics-datapoint-requirements-lambda)
+ [
## AWS/SQS
](#appinsights-metrics-datapoint-requirements-sqs)
+ [
## AWS/CWAgent
](#appinsights-metrics-datapoint-requirements-cwagent)
+ [
## AWS/DynamoDB
](#appinsights-metrics-datapoint-requirements-dynamo)
+ [
## AWS/S3
](#appinsights-metrics-datapoint-requirements-s3)
+ [
## AWS/States
](#appinsights-metrics-datapoint-requirements-states)
+ [
## AWS/ApiGateway
](#appinsights-metrics-datapoint-requirements-api-gateway)
+ [
## AWS/SNS
](#appinsights-metrics-datapoint-requirements-sns)
## AWS/ApplicationELB
ActiveConnectionCount
ConsumedLCUs
HTTPCode\$1ELB\$14XX\$1Count
HTTPCode\$1Target\$12XX\$1Count
HTTPCode\$1Target\$13XX\$1Count
HTTPCode\$1Target\$14XX\$1Count
HTTPCode\$1Target\$15XX\$1Count
NewConnectionCount
ProcessedBytes
TargetResponseTime
UnHealthyHostCount
## AWS Autoscaling
GroupDesiredCapacity
GroupInServiceInstances
GroupMaxSize
GroupMinSize
GroupPendingInstances
GroupStandbyInstances
GroupTerminatingInstances
GroupTotalInstances
## AWS/EC2
CPUCreditBalance
CPUCreditUsage
CPUSurplusCreditBalance
CPUSurplusCreditsCharged
CPUUtilization
DiskReadBytes
DiskReadOps
DiskWriteBytes
DiskWriteOps
EBSByteBalance%
EBSIOBalance%
EBSReadBytes
EBSReadOps
EBSWriteBytes
EBSWriteOps
NetworkIn
NetworkOut
NetworkPacketsIn
NetworkPacketsOut
## Elastic Block Store (EBS)
VolumeReadBytes
VolumeWriteBytes
VolumeReadOps
VolumeWriteOps
VolumeTotalReadTime
VolumeTotalWriteTime
VolumeIdleTime
VolumeQueueLength
VolumeThroughputPercentage
VolumeConsumedReadWriteOps
BurstBalance
## AWS/ELB
EstimatedALBActiveConnectionCount
EstimatedALBConsumedLCUs
EstimatedALBNewConnectionCount
EstimatedProcessedBytes
HTTPCode\$1Backend\$14XX
HTTPCode\$1Backend\$15XX
HealthyHostCount
レイテンシー
RequestCount
SurgeQueueLength
UnHealthyHostCount
## AWS/RDS
ActiveTransactions
AuroraBinlogReplicaLag
AuroraReplicaLag
BackupRetentionPeriodStorageUsed
BinLogDiskUsage
BlockedTransactions
CPUCreditBalance
CommitLatency
CommitThroughput
DDLLatency
DDLThroughput
DMLLatency
DMLThroughput
DatabaseConnections
デッドロック
DeleteLatency
DeleteThroughput
DiskQueueDepth
EngineUptime
FreeLocalStorage
FreeStorageSpace
FreeableMemory
InsertLatency
InsertThroughput
LoginFailures
NetworkReceiveThroughput
NetworkThroughput
NetworkTransmitThroughput
クエリ
ReadIOPS
ReadThroughput
SelectLatency
SelectThroughput
SnapshotStorageUsed
TotalBackupStorageBilled
UpdateLatency
UpdateThroughput
VolumeBytesUsed
VolumeReadiOps
VolumeWriteIOPs
WriteIOPS
WriteThroughput
## AWS/Lambda
エラー
DeadLetterErrors
所要時間
スロットリング
IteratorAge
ProvisionedConcurrencySpilloverInvocations
## AWS/SQS
ApproximateAgeOfOldestMessage
ApproximateNumberOfMessagesDelayed
ApproximateNumberOfMessagesNotVisible
ApproximateNumberOfMessagesVisible
NumberOfEmptyReceives
NumberOfMessagesDeleted
NumberOfMessagesReceived
NumberOfMessagesSent
## AWS/CWAgent
LogicalDisk % Free Space
Memory % Committed Bytes In Use
Memory Available Mbytes
Network Interface Bytes Total/sec
Paging File % Usage
PhysicalDisk % Disk Time
PhysicalDisk Avg。Disk sec/Read
PhysicalDisk Avg。Disk sec/Write
PhysicalDisk Disk Read Bytes/sec
PhysicalDisk Disk Reads/sec
PhysicalDisk Disk Write Bytes/sec
PhysicalDisk Disk Writes/sec
Processor % Idle Time
Processor % Interrupt Time
Processor % Processor Time
Processor % User Time
SQLServer:Access Methods Forwarded Records/sec
SQLServer:Access Methods Page Splits/sec
SQLServer:Buffer Manager Buffer cache hit ratio
SQLServer:Buffer Manager Page life expectancy
SQLServer:Database Replica File Bytes Received/sec
SQLServer:Database Replica Log Bytes Received/sec
SQLServer:Database Replica Log remaining for undo
SQLServer:Database Replica Log Send Queue
SQLServer:Database Replica Mirrored Write Transaction/sec
SQLServer:Database Replica Recovery Queue
SQLServer:Database Replica Redo Bytes Remaining
SQLServer:Database Replica Redone Bytes/sec
SQLServer:Database Replica Total Log requiring undo
SQLServer:Database Replica Transaction Delay
SQLServer:General Statistics Processes blocked
SQLServer:SQL Statistics Batch Requests/sec
SQLServer:SQL Statistics SQL Compilations/sec
SQLServer:SQL Statistics SQL Re-Compilations/sec
System Processor Queue Length
TCPv4 Connections Established
TCPv6 Connections Established
## AWS/DynamoDB
ConsumedReadCapacityUnits
ConsumedWriteCapacityUnits
調整イベントの読み込み
調整イベントの書き込み
TimeToLiveDeletedItemCount
条件チェックが失敗したリクエスト
TransactionConflict
ReturnedRecordsCount
PendingReplicationCount
ReplicationLatency
## AWS/S3
ReplicationLatency
BytesPendingReplication
OperationsPendingReplication
4xxErrors
5xxErrors
AllRequests
GetRequests
PutRequests
DeleteRequests
HeadRequests
PostRequests
SelectRequests
ListRequests
SelectScannedBytes
SelectReturnedBytes
FirstByteLatency
TotalRequestLatency
BytesDownloaded
BytesUploaded
## AWS/States
ActivitiesScheduled
ActivitiesStarted
ActivitiesSucceeded
ActivityScheduleTime
ActivityRuntime
ActivityTime
LambdaFunctionsScheduled
LambdaFunctionsStarted
LambdaFunctionsSucceeded
LambdaFunctionScheduleTime
LambdaFunctionRuntime
LambdaFunctionTime
ServiceIntegrationsScheduled
ServiceIntegrationsStarted
ServiceIntegrationsSucceeded
ServiceIntegrationScheduleTime
ServiceIntegrationRuntime
ServiceIntegrationTime
ProvisionedRefillRate
ProvisionedBucketSize
ConsumedCapacity
ThrottledEvents
## AWS/ApiGateway
4XXError
IntegrationLatency
レイテンシー
DataProcessed
CacheHitCount
CacheMissCount
## AWS/SNS
NumberOfNotificationsDelivered
NumberOfMessagesPublished
NumberOfNotificationsFailed
NumberOfNotificationsFilteredOut
NumberOfNotificationsFilteredOut-InvalidAttributes
NumberOfNotificationsFilteredOut-NoMessageAttributes
NumberOfNotificationsRedrivenToDlq
NumberOfNotificationsFailedToRedriveToDlq
SMSSuccessRate
# 推奨メトリクス
次の表は、コンポーネントタイプ別の推奨されるメトリクスの一覧です。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/application-insights-recommended-metrics.html)
次の表は、コンポーネントタイプ別の推奨されるプロセスとプロセスメトリクスの一覧です。CloudWatch Application Insights は、インスタンスで実行されないプロセスのプロセスのモニターリングを推奨していません。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/application-insights-recommended-metrics.html)
# パフォーマンスカウンタのメトリクス
パフォーマンスカウンタのメトリクスは、対応するパフォーマンスカウンタセットが Windows インスタンスにインストールされている場合にのみインスタンスに対して推奨されます。
| パフォーマンスカウンタのメトリクス名 | パフォーマンスカウンタセット名 |
| --- | --- |
| .NET CLR Exceptions \$1 of Exceps Thrown | .NET CLR Exceptions |
| .NET CLR Exceptions \$1 of Exceps Thrown/Sec | .NET CLR Exceptions |
| .NET CLR Exceptions \$1 of Filters/Sec | .NET CLR Exceptions |
| .NET CLR Exceptions \$1 of Finallys/Sec | .NET CLR Exceptions |
| .NET CLR Exceptions Throw to Catch Depth/Sec | .NET CLR Exceptions |
| .NET CLR Interop \$1 of CCWs | .NET CLR Interop |
| .NET CLR Interop \$1 of Stubs | .NET CLR Interop |
| .NET CLR Interop \$1 of TLB exports/Sec | .NET CLR Interop |
| .NET CLR Interop \$1 of TLB imports/Sec | .NET CLR Interop |
| .NET CLR Interop \$1 of Marshaling | .NET CLR Interop |
| .NET CLR Jit % Time in Jit | .NET CLR Jit |
| .NET CLR Jit Standard Jit Failures | .NET CLR Jit |
| .NET CLR Loading % Time Loading | .NET CLR Loading |
| .NET CLR Loading Rate of Load Failures | .NET CLR Loading |
| .NET CLR LocksAndThreads Contention Rate/Sec | .NET CLR LocksAndThreads |
| .NET CLR LocksAndThreads Queue Length/Sec | .NET CLR LocksAndThreads |
| .NET CLR Memory \$1 Total Committed Bytes | .NET CLR Memory |
| .NET CLR Memory % Time in GC | .NET CLR Memory |
| .NET CLR Networking 4.0.0.0 HttpWebRequest Average Queue Time | .NET CLR Networking 4.0.0.0 |
| .NET CLR Networking 4.0.0.0 HttpWebRequests Aborted/Sec | .NET CLR Networking 4.0.0.0 |
| .NET CLR Networking 4.0.0.0 HttpWebRequests Failed/Sec | .NET CLR Networking 4.0.0.0 |
| .NET CLR Networking 4.0.0.0 HttpWebRequests Queued/Sec | .NET CLR Networking 4.0.0.0 |
| APP\$1POOL\$1WAS Total Worker Process Ping Failures | APP\$1POOL\$1WAS |
| ASP.NET Application Restarts | ASP.NET |
| ASP.NET Requests Rejected | ASP.NET |
| ASP.NET Worker Process Restarts | ASP.NET |
| ASP.NET Applications Cache API trims | ASP.NET Applications |
| ASP.NET Applications % Managed Processor Time (estimated) | ASP.NET Applications |
| ASP.NET Applications Errors Total/Sec | ASP.NET Applications |
| ASP.NET Applications Errors Unhandled During Execution/Sec | ASP.NET Applications |
| ASP.NET Applications Requests in Application Queue | ASP.NET Applications |
| ASP.NET Applications Requests/Sec | ASP.NET Applications |
| ASP.NET Request Wait Time | ASP.NET |
| ASP.NET Requests Queued | ASP.NET |
| Database ==> Instances Database Cache % Hit | Database ==> Instances |
| Database ==> Instances I/O Database Reads Average Latency | Database ==> Instances |
| Database ==> Instances I/O Database Reads/sec | Database ==> Instances |
| Database ==> Instances I/O Log Writes Average Latency | Database ==> Instances |
| DirectoryServices DRA Pending Replication Operations | DirectoryServices |
| DirectoryServices DRA Pending Replication Synchronizations | DirectoryServices |
| DirectoryServices LDAP Bind Time | DirectoryServices |
| DNS Recursive Queries/sec | DNS |
| DNS Recursive Query Failure/sec | DNS |
| DNS TCP Query Received/sec | DNS |
| DNS Total Query Received/sec | DNS |
| Total Response Sent/sec | DNS |
| DNS UDP Query Received/sec | DNS |
| HTTP Service Request Queues CurrentQueueSize | HTTP Service Request Queues |
| LogicalDisk % Free Space | LogicalDisk |
| LogicalDisk Avg。Disk sec/Write | LogicalDisk |
| LogicalDisk Avg。Disk sec/Read | LogicalDisk |
| LogicalDisk Avg。Disk Queue Length | LogicalDisk |
| Memory % Committed Bytes In Use | メモリ |
| Memory Available Mbytes | メモリ |
| Memory Pages/Sec | メモリ |
| Memory Long-Term Average Standby Cache Lifetime (s) | メモリ |
| Network Interface Bytes Total/sec | ネットワークインターフェイス |
| Network Interface Bytes Received/sec | ネットワークインターフェイス |
| Network Interface Bytes Sent/sec | ネットワークインターフェイス |
| Network Interface Current Bandwidth | ネットワークインターフェイス |
| Paging File % Usage | Paging File |
| PhysicalDisk % Disk Time | PhysicalDisk |
| PhysicalDisk Avg。Disk Queue Length | PhysicalDisk |
| PhysicalDisk Avg。Disk Sec/Read | PhysicalDisk |
| PhysicalDisk Avg。Disk Sec/Write | PhysicalDisk |
| PhysicalDisk Disk Read Bytes/Sec | PhysicalDisk |
| PhysicalDisk Disk Reads/Sec | PhysicalDisk |
| PhysicalDisk Disk Write Bytes/Sec | PhysicalDisk |
| PhysicalDisk Disk Writes/Sec | PhysicalDisk |
| Processor % Idle Time | プロセッサ |
| Processor % Interrupt Time | プロセッサ |
| Processor % Processor Time | プロセッサ |
| Processor % User Time | プロセッサ |
| SharePoint Disk-Based Cache Blob Cache fill ratio | SharePoint Disk-Based Cache |
| SharePoint Disk-Based Cache Blob cache flushes / second | SharePoint Disk-Based Cache |
| SharePoint Disk-Based Cache Blob cache hit ratio | SharePoint Disk-Based Cache |
| SharePoint Disk-Based Cache Total number of cache compactions | SharePoint Disk-Based Cache |
| SharePoint Foundation Executing Time/Page Request | SharePoint Foundation |
| SharePoint Publishing Cache Publishing cache flushes / second | SharePoint Publishing Cache |
| Security System-Wide Statistics Kerberos Authentications | セキュリティシステム全体の統計 |
| Security System-Wide Statistics NTLM Authentications | セキュリティシステム全体の統計 |
| SQLServer:Access Methods Forwarded Records/Sec | SQLServer:Access Methods |
| SQLServer:Access Methods Full Scans/Sec | SQLServer:Access Methods |
| SQLServer:Access Methods Page Splits/Sec | SQLServer:Access Methods |
| SQLServer:Buffer Manager Buffer cache hit Ratio | SQLServer:Buffer Manager |
| SQLServer:Buffer Manager Page life Expectancy | SQLServer:Buffer Manager |
| SQLServer:Database Replica File Bytes Received/sec | SQLServer:Database Replica |
| SQLServer:Database Replica Log Bytes Received/sec | SQLServer:Database Replica |
| SQLServer:Database Replica Log remaining for undo | SQLServer:Database Replica |
| SQLServer:Database Replica Log Send Queue | SQLServer:Database Replica |
| SQLServer:Database Replica Mirrored Write Transaction/sec | SQLServer:Database Replica |
| SQLServer:Database Replica Recovery Queue | SQLServer:Database Replica |
| SQLServer:Database Replica Redo Bytes Remaining | SQLServer:Database Replica |
| SQLServer:Database Replica Redone Bytes/sec | SQLServer:Database Replica |
| SQLServer:Database Replica Total Log requiring undo | SQLServer:Database Replica |
| SQLServer:Database Replica Transaction Delay | SQLServer:Database Replica |
| SQLServer:General Statistics Processes Blocked | SQLServer:General Statistics |
| SQLServer:General Statistics User Connections | SQLServer:General Statistics |
| SQLServer:Latches Average Latch Wait Time (ms) | SQLServer:Latches |
| SQLServer:Locks Average Wait Time (ms) | SQLServer:Locks |
| SQLServer:Locks Lock Timeouts/Sec | SQLServer:Locks |
| SQLServer:Locks Lock Waits/Sec | SQLServer:Locks |
| SQLServer:Locks Number of Deadlocks/Sec | SQLServer:Locks |
| SQLServer:Memory Manager Memory Grants Pending | SQLServer:Memory Manager |
| SQLServer:SQL Statistics Batch Requests/Sec | SQLServer:SQL Statistics |
| SQLServer:SQL Statistics SQL Compilations/Sec | SQLServer:SQL Statistics |
| SQLServer:SQL Statistics SQL Re-Compilations/Sec | SQLServer:SQL Statistics |
| System Processor Queue Length | システム |
| TCPv4 Connections Established | TCPv4 |
| TCPv6 Connections Established | TCPv6 |
| W3SVC\$1W3WP File Cache Flushes | W3SVC\$1W3WP |
| W3SVC\$1W3WP File Cache Misses | W3SVC\$1W3WP |
| W3SVC\$1W3WP Requests/Sec | W3SVC\$1W3WP |
| W3SVC\$1W3WP URI Cache Flushes | W3SVC\$1W3WP |
| W3SVC\$1W3WP URI Cache Misses | W3SVC\$1W3WP |
| Web Service Bytes Received/Sec | ウェブサービス |
| Web Service Bytes Sent/Sec | ウェブサービス |
| Web Service Connection Attempts/Sec | ウェブサービス |
| Web Service Current Connections | ウェブサービス |
| Web Service Get Requests/Sec | ウェブサービス |
| Web Service Post Requests/Sec | ウェブサービス |
# CloudWatch コンソールのリソースのヘルスビューの使用
リソースのヘルスビューを使用すると、アプリケーション全体のホストのヘルスとパフォーマンスを単一のビューで自動的に検出、管理、および可視化できます。CPU やメモリなどのパフォーマンスディメンションでホストのヘルスを可視化し、フィルターを使用して数百のホストを単一のビューで詳しく分析できます。タグやユースケース (同じ Auto Scaling グループ内のホスト、または同じロードバランサーを使用するホストなど) でフィルタリングできます。
## 前提条件
リソースのヘルスビューの利点を最大限に活用するには、次の前提条件を満たしていることを確認します。
+ ホストのメモリ使用率を確認し、フィルターとして使用するには、CloudWatch エージェントをホストにインストールし、デフォルトの `CWAgent` 名前空間で CloudWatch にメモリメトリクスを送信するように設定する必要があります。Linux および macOS インスタンスでは、CloudWatch エージェントが `mem_used_percent` メトリクスを送信する必要があります。Windows インスタンスでは、エージェントは `Memory % Committed Bytes In Use` メトリクスを送信する必要があります。これらのメトリクスは、ウィザードを使用して CloudWatch エージェント設定ファイルを作成し、事前定義されたメトリクスのセットのいずれかを選択した場合に含まれます。CloudWatch エージェントによって収集されたメトリクスは、カスタムメトリクスとして請求されます。詳細については、「[CloudWatch エージェントのインストール](install-CloudWatch-Agent-on-EC2-Instance.md)」を参照してください。
CloudWatch エージェントを使用してこれらのメモリメトリクスを収集し、リソースヘルスビューで使用する場合は、CloudWatch エージェント設定ファイルに次のセクションを含める必要があります。このセクションにはデフォルトのディメンション設定が含まれており、デフォルト値で作成されるため、このセクションのどの部分も、次の例に示されているのと異なるものに変更しないでください。
```
"append_dimensions": {
"ImageId": "${aws:ImageId}",
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}",
"AutoScalingGroupName": "${aws:AutoScalingGroupName}"
},
```
+ リソースのヘルスビューで使用可能なすべての情報を表示するには、次の許可を持つアカウントにサインインする必要があります。より少ない許可でサインオンしている場合でも、リソースのヘルスビューを使用できますが、一部のパフォーマンスデータは表示されません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"autoscaling:Describe*",
"cloudwatch:Describe*",
"cloudwatch:Describe*",
"cloudwatch:Get*",
"cloudwatch:List*",
"logs:Get*",
"logs:Describe*",
"sns:Get*",
"sns:List*",
"ec2:DescribeInstances",
"ec2:DescribeInstanceStatus",
"ec2:DescribeRegions"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
**アカウントのリソースのヘルスを表示するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、**[Insights]**、**[EC2 Resource Health]** を選択します。
リソースのヘルスページが表示され、アカウント内のホストごとに四角形が表示されます。各四角形は、[**Color by**] (色分け) の設定に基づいて、そのホストの現在のステータスに基づいて色分けされます。アラーム記号が付されたホストの四角形には、現在 ALARM 状態にある 1 つ以上のアラームがあります。
1 つのビューで最大 500 のホストを表示できます。アカウントでさらにホストを有している場合は、この手順のステップ 6 のフィルター設定を使用します。
1. 各ホストのヘルスの表示に使用する条件を変更するには、[**Color by**] (色分け) の設定を選択します。[**CPU Utilization**] (CPU 使用率)、[**Memory Utilization**] (メモリ使用率)、または [**Status check**] (ステータスチェック) を選択できます。メモリ使用率のメトリクスは、CloudWatch エージェントを実行しており、メモリメトリクスを収集してデフォルトの `CWAgent` 名前空間に送信するように設定されているホストでのみ使用できます。詳細については、「[CloudWatch エージェントを使用してメトリクス、ログ、トレースを収集する](Install-CloudWatch-Agent.md)」を参照してください。
1. グリッド内のヘルスインジケータに使用されるしきい値および色を変更するには、グリッドの上にある歯車アイコンを選択します。
1. ホストグリッドにアラームを表示するかどうかを切り替えるには、[**Show alarms across all metrics**] (すべてのメトリクスでアラームを表示) をオンまたはオフにします。
1. マップ内のホストをグループに分割するには、[**Group by**] (グループ化の条件) でグループ化の条件を選択します。
1. ビューで表示されるホストを絞り込むには、[**Filter by**] (フィルター条件) でフィルター条件を選択します。タグや Auto Scaling グループ、インスタンスタイプ、セキュリティグループなどのリソースグループでフィルタリングできます。
1. ホストを並べ替えるには、[**Sort by**] (並べ替え) で並べ替え条件を選択します。ステータスチェックの結果、インスタンスの状態、CPU またはメモリ使用率、ALARM 状態にあるアラームの数でソートできます。
1. ホストの詳細を表示するには、そのホストを表す四角形を選択します。ポップアップペインが表示されます。その後、そのホストに関する情報をより詳細に確認するには、[**View dashboard**] (ダッシュボードを表示) または [**View on list**] (リストで表示) を選択します。