翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# CloudWatch を使用したダッシュボードとビジュアライゼーション
<a name="cloudwatch-dashboards-visualizations"></a>

ダッシュボードを使用すると、アプリケーションとワークロードの懸念事項にすばやく焦点を当てるのに役立ちます。CloudWatch は自動ダッシュボードを提供し、CloudWatch メトリクスを使用するダッシュボードを簡単に作成することもできます。CloudWatch ダッシュボードは、複数のメトリクスを関連づけ、傾向を特定するのに役立つため、メトリクスを単独で表示するよりも多くのインサイトを提供します。たとえば、受信した注文、メモリ、CPU 使用率、データベース接続を含むダッシュボードは、注文数が増減している間に、複数の AWS リソース間でワークロードメトリクスの変化を関連付けるのに役立ちます。

ワークロードとアプリケーションをモニタリングするには、アカウントおよびアプリケーションレベルでダッシュボードを作成する必要があります。サービス固有のメトリクスで事前構成された AWS サービスレベルダッシュボードである、CloudWatch 自動ダッシュボードを使用して開始できます。自動サービスダッシュボードには、サービスのデフォルトの CloudWatch メトリクスがすべて表示されます。自動ダッシュボードは、各サービスメトリクスに使用されているすべてのリソースをグラフ化し、アカウント全体の異常値のリソースをすばやく特定するのに役立ちます。これにより、使用率の高いリソースと使用率の低いリソースを特定し、コストの最適化に役立ちます。

## クロスサービスダッシュボードを作成する
<a name="cross-service-dashboard"></a>

クロスサービスダッシュボードを作成するには、 AWS サービスの自動サービスレベルダッシュボードを表示し、**アクション**メニューから**ダッシュボードに追加**オプションを使用します。その後、他の自動ダッシュボードのメトリクスを新しいダッシュボードに追加し、メトリクスを削除してダッシュボードの焦点を絞り込むことができます。また、独自のカスタムメトリクスを追加して、主要な観測データを追跡する必要があります (例えば、受取注文や秒あたりの取引など)。独自のカスタムクロスサービスダッシュボードを作成すると、ワークロードに最も関連性の高いメトリクスに集中できます。キーメトリクスをカバーし、アカウント内のすべてのワークロードを表示するアカウントレベルのクロスサービスダッシュボードを作成することを推奨します。

クラウドオペレーションチーム用のセントラルオフィススペースまたは共用エリアがある場合、CloudWatch ダッシュボードを大型テレビモニターにフルスクリーンモードで表示し、自動更新できます。

## アプリケーションまたはワークロード固有のダッシュボードを作成する
<a name="application-workload-dashboards"></a>

本番環境のすべての重要なアプリケーションまたはワークロードに関するキーメトリクスとリソースに焦点を当てた、アプリケーションおよびワークロード固有のダッシュボードを作成することをお勧めします。アプリケーションおよびワークロード固有のダッシュボードは、カスタムアプリケーションまたはワークロードメトリクスと、パフォーマンスに影響を与える重要な AWS リソースメトリクスに焦点を当てています。

インシデント発生後にキーメトリクスを追跡するために、CloudWatch アプリケーションまたはワークロードダッシュボードを定期的に評価してカスタマイズする必要があります。また、機能が導入または使用停止されたときに、アプリケーションまたはワークロード固有のダッシュボードを更新する必要があります。ワークロードおよびアプリケーション固有のダッシュボードの更新は、ロギングとモニタリングに加えて、品質を継続的に改善するために必要なアクティビティでなければなりません。

## クロスアカウントまたはクロスリージョンダッシュボードを作成する
<a name="cross-account-region-dashboards"></a>

AWS リソースは主にリージョン別であり、メトリクス、アラーム、ダッシュボードはリソースがデプロイされているリージョンに固有です。このため、リージョンを変更して、クロスリージョンワークロードおよびアプリケーションのメトリクス、ダッシュボード、アラームを表示する必要があります。アプリケーションとワークロードを複数のアカウントに分割する場合は、再認証と各アカウントへのサインインが必要になる場合があります。ただし、CloudWatch では、単一のアカウントからのクロスアカウントおよびクロスリージョンデータの表示がサポートされています。つまり、単一のアカウントとリージョンでメトリクス、アラーム、ダッシュボード、ログウィジェットを表示できます。これは、ロギングおよびモニタリングアカウントを一元管理している場合に非常に便利です。

アカウント所有者とアプリケーションチームの所有者は、アカウント固有のクロスリージョンアプリケーション用のダッシュボードを作成して、キーメトリクスを一元的にモニタリングする必要があります。CloudWatch ダッシュボードは、クロスリージョンウィジェットを自動的にサポートします。つまり、追加の設定を行わずに、複数のリージョンのメトリクスを含むダッシュボードを作成できます。

重要な例外は CloudWatch Logs インサイトウィジェットです。ログデータは、現在ログインしているアカウントとリージョンにのみ表示できるためです。メトリクスフィルターを使用してログからリージョン固有のメトリクスを作成でき、これらのメトリクスはクロスリージョンダッシュボードに表示できます。その後、それらのログをさらに分析する必要がある場合は、特定のリージョンに切り替えることができます。

オペレーションチームは、重要なクロスアカウントおよびクロスリージョンメトリクスをモニタリングする一元化されたダッシュボードを作成する必要があります。例えば、各アカウントとリージョンの CPU 使用率の合計 CPU 使用率を含むクロスアカウントダッシュボードを作成できます。また、[Metric Math](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/using-metric-math.html) を使用し、複数のアカウントおよびリージョンにわたるデータを集約およびダッシュボードに表示できます。

## Metric Math を使用してオブザーバビリティとアラームを微調整する
<a name="use-metric-math"></a>

Metric Math を使用すると、ワークロードに関連する形式と数式でメトリクスを計算できます。計算されたメトリクスは、追跡目的でダッシュボードに保存および表示できます。例えば、デフォルトの Amazon EBS ボリュームメトリクスでは、特定の期間にわたって実行される読み取りオペレーション (`VolumeReadOps`) と書き込みオペレーション (`VolumeWriteOps`) の回数を示します。

ただし、 は IOPS での Amazon EBS ボリュームのパフォーマンスに関するガイドライン AWS を提供します。Amazon EBS ボリュームの IOPS を Metric Math でグラフ化して計算するには、`VolumeReadOps` と `VolumeWriteOps` を足して、次にそのメトリクスに選択した期間で割ります。

この例では、期間の IOPS を合計し、期間の長さで割って IOPS を取得します。次に、このメトリクスの数式に対してアラームを設定して、ボリュームの IOPS がボリュームタイプの最大容量に近づいたときに警告することができます。メトリクス計算を使用して CloudWatch メトリクスで Amazon Elastic File System (Amazon EFS) ファイルシステムをモニタリングする方法の詳細と例については、 AWS ブログの[Amazon CloudWatch メトリクス計算は Amazon EFS ファイルシステムのほぼリアルタイムのモニタリングを簡素化する](https://aws.amazon.com//blogs/mt/amazon-cloudwatch-metric-math-simplifies-near-real-time-monitoring-of-your-amazon-efs-file-systems-and-more/)」を参照してください。

## CloudWatchContainer インサイトと CloudWatch Lambda インサイトで、Amazon ECS、Amazon EKS、および Lambda 自動ダッシュボードを使用する
<a name="use-automatic-dashboards"></a>

CloudWatch コンテナインサイトは、Amazon ECS および Amazon EKS で実行されるコンテナワークロードの動的な自動ダッシュボードを作成します。コンテナインサイトを有効にして、CPU、メモリ、ディスク、ネットワーク、およびコンテナの再起動失敗などの診断情報をモニタリングできるようにする必要があります。コンテナインサイトは、クラスター、コンテナインスタンスまたはノード、サービス、タスク、ポッド、および個々のコンテナレベルですばやくフィルタリングできる動的なダッシュボードを生成します。コンテナインサイトは、 AWS サービスに応じて、[クラスター、ノード、またはコンテナインスタンスレベルで構成されます](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/deploy-container-insights.html)。

コンテナインサイトと同様に、CloudWatch Lambda インサイトは、Lambda 関数用の動的な自動ダッシュボードを作成します。このソリューションでは、CPU 時間、メモリ、ディスク、ネットワークなどのシステムレベルのメトリクスが収集、集約、要約されます。また、コールドスタートや Lambda ワーカーシャットダウンなどの診断情報が収集、集約、要約されるため、Lambda 関数に関する問題を特定し、迅速に解決できます。Lambda は関数レベルで有効であり、エージェントを必要としません。

コンテナインサイトと Lambda インサイトは、アプリケーションまたはパフォーマンスログ、X-Ray トレース、およびサービスマップにすばやく切り替えて、コンテナのワークロードを可視化するのに役立ちます。両方とも CloudWatch の組み込みメトリクス形式を使用して CloudWatch メトリクスとパフォーマンスログをキャプチャします。

コンテナインサイトと Lambda インサイトによってキャプチャされたメトリクスを使用するワークロードの共有 CloudWatch ダッシュボードを作成できます。これを行うには、CloudWatch コンテナインサイトを使用して自動ダッシュボードをフィルタリングして表示し、**ダッシュボードに追加** オプションを選択して、デフォルトの CloudWatch ダッシュボードに表示されるメトリクスを追加することができます。その後、メトリクスを削除またはカスタマイズし、ワークロードを正しく表すために他のメトリクスを追加できます。