Amazon CloudWatch のよくある質問

最新情報については、料金ページをご覧ください。

すべての Amazon EC2 インスタンスタイプは、キーの正常性とパフォーマンスメトリックを無料で CloudWatch に自動送信します。EC2 の詳細モニタリングを有効にすると、インスタンスの CloudWatch に送信されたメトリックの数に基づいてカスタムメトリックの料金が発生します。インスタンスに送信されるメトリクスの数は、インスタンスタイプによって異なります。詳細については、「インスタンスで利用可能な CloudWatch メトリクス」をご覧ください。

別途記載がない限り、表示される料金には VAT、売上税その他取引に対して適用される一切の税金等および関税は含まれません。詳細はこちら。

2017 年 7 月以前は、AWS 請求書、ならびにコストと使用状況のレポートにおいて、CloudWatch の料金は 2 つの異なるセクションに分かれていました。これまでの経緯から、CloudWatch Alarms、CloudWatch Metrics、CloudWatch API の使用料金はお客様の請求書の「Elastic Compute Cloud」(EC2) 詳細セクションでレポートされる一方、CloudWatch Logs および CloudWatch Dashboards の料金は「CloudWatch」詳細セクションでレポートされていました。お客様の毎月の AWS CloudWatch 使用状況および請求につきまして、統合と簡素化を推進するため、CloudWatch Metrics、Alarms、API の使用料金はお客様の請求書の「EC2」セクションから「CloudWatch」セクションに移動され、お客様の CloudWatch モニタリング料金はすべて「CloudWatch」セクションに統合されることになります。これはお客様の AWS 請求総額には影響しません。お客様の請求書、ならびにコストと使用状況のレポートにおいて、CloudWatch の料金が 1 つのセクションに表示されるよう簡素化が図られました。

さらに、CloudWatch には「Estimated Charges」(見積料金) という名前の請求メトリクスがありますが、これは「Total Estimated Charge」(合計見積料金) として、または「By Service」(サービス別) に細分化して確認できます。「Total Estimated Charge」(合計見積料金) メトリクスは変動しません。ただし、ServiceName が「AmazonEC2」であるディメンション、ならびに ServiceName が「AmazonCloudWatch」であるディメンションにつきましては、サービス別に細分化した「EstimatedCharges」(見積料金) メトリクスは変動します。請求の統合により、お客様の AmazonEC2 請求メトリクスが減少し AmazonCloudWatch 請求メトリクスが増加する場合がありますが、これは使用料金および請求額が EC2 から CloudWatch に移動したことに伴うものです。

Logs Insights の料金はクエリ単位です。クエリでスキャンされて取り込まれたログデータの量に基づいて課金されます。料金の詳細については、CloudWatch の料金をご覧ください。

はい。手動でクエリをキャンセルした場合、クエリをキャンセルした時点までにスキャンされ取り込まれたログデータの量に対して課金されます。

いいえ。クエリが失敗した場合は課金されません。

CloudWatch のクロスアカウントオブザーバビリティにより、リージョン内の複数のアカウントにまたがるアプリケーションのモニタリングやトラブルシューティングを行うことができます。クロスアカウントオブザーバビリティを使用すれば、アカウントの境界を気にすることなく、シームレスにメトリクス、ログ、トレースを検索、可視化、分析することができます。アプリケーションのクロスアカウント集計ビューから始めて、エラーが発生しているリソースを視覚的に特定し、関連するトレース、メトリクス、ログを深く掘り下げて、問題の根本原因を突き止めることができます。クロスアカウントモニタリングによって可能になるシームレスなクロスアカウントデータアクセスとナビゲーションは、問題のトラブルシューティングに必要な手作業を減らし、解決のための貴重な時間を節約するのに役立ちます。クロスアカウントオブザーバビリティは CloudWatch の統合されたオブザーバビリティ機能の追加機能です。

クロスアカウントオブザーバビリティは、2 つの新しいアカウント概念を導入しています。「モニタリングアカウント」は、他のアカウント間で生成されたオブザーバビリティデータを表示し、やりとりできる中央の AWS アカウントです。「ソースアカウント」は、その中に存在するリソースのオブザーバビリティデータを生成する個々の AWS アカウントです。モニタリングアカウントとソースアカウントを特定したら、モニタリングアカウントと共有するテレメトリデータを選択して、クロスアカウントモニタリングの設定を完了します。数分で簡単にセントラルモニタリングアカウントを設定でき、そこから多くの関連アカウントまたは AWS 組織全体にデプロイされたアプリケーションのヘルスとパフォーマンスを完全に把握することができます。CloudWatch のクロスアカウントオブザーバビリティにより、サービスの可用性に影響を与える可能性のあるアプリケーション間の依存関係を俯瞰することができ、問題をプロアクティブに特定し、解決までの平均時間を短縮してトラブルシューティングすることができます。

クロスアカウントオブザーバビリティを使用すれば、複数アカウントにわたって保存されたロググループを中央のビューから検索したり、複数のアカウントで Logs Insights クエリを実行したり、Live Tail 分析を実行したり、ログエントリを生成している上位 N 人の貢献者を特定するためにアカウント間で貢献者インサイトルールを作成したりできます。メトリクス検索を利用して、多くのアカウントのメトリクスを統合ビューに可視化したり、他のアカウントのメトリクスを評価するアラームを作成して異常やトレンドを形成する問題を通知したり、集中ダッシュボードで可視化したりすることができます。また、この機能を使用して、AWS リージョン内の複数の AWS アカウントにまたがるメトリクスを含む、単一のクロスアカウントメトリクスストリームを設定することもできます。クロスアカウントオブザーバビリティにより、ServiceLens を使用してクロスアカウントアプリケーションのインタラクティブマップを表示し、関連するメトリクス、ログ、トレースへワンステップでドリルダウンすることも可能です。

CloudWatch のクロスアカウントモニタリングとクロスアカウントクロスリージョン機能は、どちらも CloudWatch コンソールで利用できるようになります。CloudWatch でクロスアカウントの観測性を設定すると、クロスアカウント、クロスリージョンのドロップダウンメニューはコンソールから削除されます。CloudWatch のクロスアカウントオブザーバビリティエクスペリエンスは、一度に 1 つのリージョン内で利用可能であることに注意してください。クロスアカウント、クロスリージョン機能は、IAM ロールを通して組織全体のテレメトリにアクセスすることができます。CloudWatch のクロスアカウントオブザーバビリティは、アクセスポリシーを定義するために Observability Access Manager API を使用します。詳細については、ドキュメントを参照してください。

Amazon CloudWatch アプリケーションシグナル [プレビュー] は、標準化されたアプリケーションメトリックスと CloudWatch 用 AWS マネジメントコンソールのアプリケーション中心のオブザーバビリティビューにより、Amazon CloudWatch を拡張します。カスタムインストゥルメンテーションを作成しなくても開始できます。新しいビューでは、アプリケーションの状態の概要が示され、ビジネスへの影響の判断や優先順位付けに役立ち、さらにドリルダウンして根本原因を迅速に特定できます。

アプリケーションシグナルは、CloudWatch 用 AWS マネジメントコンソールで有効にするか、Amazon EKS クラスターなどの AWS リソースで CloudWatch を有効にするときに有効にできます。アプリケーションインストルメンテーションは Amazon CloudWatch エージェントに含まれています。アプリケーションサービス、その API、および依存関係は、概要ビューとサービスマップで検出および視覚化されます。ビジネスへの影響と重要性を反映するために、数回クリックするだけで、標準アプリケーションメトリクス、リアルユーザーモニター、または合成モニターでサービスレベル目標 (SLO) を作成できます。コンソールの「Enable more APM」ビューには、監視対象リソースと監視対象外リソースが表示されます。これにより、お客様はアプリケーションの可視性を徐々に高めることができます。CloudWatch の設定を使用して、重要なサービスのトレースサンプリングを増やし、支払い注文などの重要なトランザクションの例をより多くキャプチャできます。外部の可用性モニタリングまたはUIワークフローを追加するには、合成カナリアを追加し、クライアントの可視性を追加するには、WebアプリケーションでRUMテレメトリを有効にします。

Amazon CloudWatch Application Signals [Preview] は、EKS で実行されている住宅ローン支払いプロセッサなどのアプリケーションサービスを検出し、API のボリューム、レイテンシー、エラー、障害 (ユーザーの追加、注文、支払いなど) および依存関係 (アプリケーションサービス間、AWS サービス、または外部エンドポイントへの呼び出しなど) に関する標準アプリケーションメトリックセットを生成します。お客様は、サービスレベル目標を定義することで、アプリケーションサービス、API、依存関係のビジネスへの影響と重要性を反映できます。CloudWatch 用 AWS Management Console の新しいアプリケーション中心のオブザーバビリティビューは、SLO に対するアプリケーションの状態を要約し、根本原因を迅速に特定するためのドリルダウン機能を提供します。

Application Signalsを使用すると、統合されたアプリケーションパフォーマンス監視が可能になります。統合監視により、ビジネスクリティカルなアプリケーションに優先順位を付けながら、アプリケーションテレメトリを自動的に収集して関連付けることができます。また、アラーム、トレース、イベントデータを活用して自動アクションを実行し、問題からの回復にかかる時間 (MTTR) を短縮することもできます。Amazon EKS、Amazon EC2、Amazon ECS、データベース、コンポーネント、またはオンプレミスリソースで実行されているアプリケーションをモニタリングしたい。モニタリングするリソースを指定し、手動設定なしで CloudWatch コンソールで Amazon EKS のアプリケーションシグナルを有効にするだけです。その他すべてのアプリケーション環境では、CloudWatch Agent を迅速にデプロイして、アプリケーションのモニタリングを開始できます。アプリケーションシグナルを使用すると、ビジネスと運用のKPIに合わせたSLOを作成、測定、追跡できます。SLOは、重要なアプリケーションの管理、可用性の向上、ダウンタイムの短縮、一貫した顧客体験の実現に不可欠です。すべてのアプリケーションを包括的に把握し、アプリケーションのパフォーマンスを管理できる機能が必要です。すべてのアプリケーション、サービス、テレメトリデータとともに、あらかじめ構築され、標準化された自動ダッシュボードを活用できます。これらの視覚化機能により、ボリューム、可用性、レイテンシー、アプリケーションに影響を与えるエラーなどのメトリックをすばやくスキャンしてアクセスできます。Application Signals サービスマップを使用すると、トレース、API、コンピューティングリソースを詳しく調べて、アプリケーションの問題の根本原因を包括的に把握できます。Amazon CloudWatch RUM と Amazon CloudWatch Synthetics をアプリケーションシグナルに統合することで、ユーザーデータをリアルタイムで表示し、カナリアデータを 1 つのビューに表示できます。これは、エンドユーザーに影響を与える前に、コード、依存関係、またはホスティング環境の根本原因を迅速に特定する必要がある場合に重要です。

CloudWatch アプリケーションインサイトは、Amazon EC2 インスタンスと他のアプリケーションリソースを使用するアプリケーションをモニタリングするのに役立ちます。アプリケーションリソースとテクノロジースタック (Microsoft SQL Server データベース、Web (IIS)、アプリケーションサーバー、OS、ロードバランサー、キューなど) 全体の主要なメトリックス、ログ、アラームを識別して設定します。メトリクスとログを継続的に監視して、異常とエラーを検出して関連付けます。エラーや異常が検出されると、アプリケーションインサイトは、通知の設定やアクションの実行に使用できる CloudWatch イベントを生成します。トラブルシューティングに役立つように、検出された問題に関する自動ダッシュボードを作成します。ダッシュボードには、相関関係のある指標の異常やログエラーが含まれ、潜在的な根本原因を特定するための追加の洞察も得られます。

CloudWatch Container Insights は、コンテナ化されたアプリケーションとマイクロサービスのモニタリング、トラブルシューティング、アラーム発信を行う機能です。Container Insights では、コンテナ環境に影響するパフォーマンスの問題を簡単に特定および分析できます。DevOps エンジニアとシステムエンジニアは、CloudWatch コンソールの自動ダッシュボードにアクセスできます。これにより、メトリクス、ログ、分散されたトレースの運用上のエンドツーエンドの可視性が提供され、Amazon Elastic Container Service for Kubernetes (EKS)、Amazon Elastic Container Service (ECS)、AWS Fargate、Kubernetes のクラスターのパフォーマンスと状態が、ポッド/タスク、コンテナ、サービス別に要約されます。

Amazon Elastic Kubernetes Service (EKS) のオブザーバビリティが強化されたコンテナインサイトにより、EKS コンテナレイヤーを視覚的に掘り下げることができ、個々のコンテナのメモリリークなどの問題を簡単に特定できるため、解決までの平均時間を短縮できます。コントロールプレーンのメトリクスを使用すると、自動スケーリングの状態を監視し、自動テスト機能でテストクラスターのライフサイクルを計画して、運用効率を向上させることができます。EKSの強化されたオブザーバビリティにより、クラスター、ノード、およびワークロードをリソース消費量別にソートして異常をすばやく特定し、独自のアラームを設定して綿密に監視し、エンドユーザーエクスペリエンスに影響が及ぶ前に積極的にリスクを軽減できるようになりました。

はい。Amazon Elastic Kubernetes Service (EKS) のオブザーバビリティが強化されたコンテナインサイトを使用すると、コントロールプレーンのステータスをモニタリングできます。これを使用して、自動スケーリングの状態を把握し、自動テスト機能などでテストクラスターのライフサイクルを計画できます。

Amazon CloudWatch Container Insights において、Amazon Elastic Kubernetes Service (EKS) のオブザーバビリティが強化され、稼働状況とパフォーマンスに関する詳細なメトリクスを設定なしですぐに利用できるようになりました。これにより、コンテナレベルの EKS パフォーマンスメトリクス、Kube-state メトリクス、EKS コントロールプレーンメトリクスなどを利用できるようになり、より迅速に問題を分離してトラブルシューティングできるようになりました。オブザーバビリティが強化されたことで、さまざまなコンテナレイヤーを視覚的にドリルアップおよびドリルダウンできるようになるとともに、コンテナ単位のメモリリークといった問題を簡単に特定することが可能となり、問題解決までの平均時間が短縮されます。コントロールプレーンのメトリクスを使用することで、自動スケーリングの状態の監視が可能となり、自動テスト機能でテストクラスターのライフサイクルプランを立てることが可能となるため、運用効率が向上します。オブザーバビリティの強化により、お客様はクラスタ、ノード、およびワークロードをリソース消費量別にソートして異常をすばやく特定し、独自のアラームを設定して綿密に監視し、エンドユーザーエクスペリエンスに影響が及ぶ前に積極的にリスクを軽減できるようになりました。オブザーバビリティの強化はオプション機能です。オブザーバビリティが強化されていないContainer Insightsは、クラスターレベルとサービスレベルの集約メトリクスを提供します。

はい。Container Insights は、クラスターごとにオブザーバビリティの強化の有無にかかわらず使用できます。クラスター情報ビューの [アドオン] タブを使用してクラスターを作成した後に、EKS 用 CloudWatch Observability アドオンをインストールすることで、クラスターのオブザーバビリティを強化できます。EKS のオブザーバビリティを強化するために CloudWatch エージェントを設定する方法については、CloudWatch コンテナインサイトのドキュメントをご覧ください。

オブザーバビリティが強化されたコンテナインサイトは、Amazon EKS をサポートします。

数回クリックするだけで、コンテナやクラスターから詳細なパフォーマンスメトリクス、ログ、メタデータの収集を開始したり、CloudWatch Observability アドオンを有効にしてオブザーバビリティを強化したりできます。Container Insights の利用を開始するには、Amazon CloudWatch Container Insights のドキュメントに記載されている手順に従ってください。

コンテナインサイトの料金の詳細については、 CloudWatch 料金表ページをご覧ください。

いいえ。現在サポートされているメトリックタイプはゲージとカウンターです。ヒストグラムおよび概要メトリックは、今後リリース予定です。

Prometheusは、クラウドネイティブコンピューティング財団（CNCF）の一部である、人気のあるオープンソースの監視プロジェクトです。オープンソースコミュニティは 150 以上のプラグインを構築し、DevOps チームがアプリケーションからプルベースのアプローチを使って収集されるカスタムメトリックを公開するために使用できるフレームワークを定義しました。この新機能により、 DevOpsチームはAWSアプリケーションメッシュ、NGINX、Java/JMXなどのコンテナ化されたワークロードのサービスを自動的に検出できます。次に、それらのサービスでカスタムメトリックを公開し、CloudWatch でメトリックを取り込みます。CloudWatch ユーザーは、Prometheus メトリックの収集と集計を管理することにより、必要なモニタリングツールの数を減らしながら、アプリケーションのパフォーマンスの低下と障害をより迅速にモニタリング、トラブルシューティング、および警告できます。

Prometheus メトリクスは、CloudWatch カスタムメトリクスとして自動的に取り込まれます。保持期間は、自動ロールアップを使用したメトリクスデータポイントあたり 15 か月になります (60 秒未満は 3 時間利用可能、1 分は 15 日間利用可能、5 分は 63 日間利用可能、1 時間は 15 か月利用可能)。詳細については、CloudWatch メトリクスの保持に関するドキュメントをご覧ください。

はい。各 Kubernetes (k8s) クラスターには、設定可能な独自の保持期間が設定されたイベント向けの独自のロググループ (/aws/containerinsights//prometheus など) があります。詳細については、ロググループの保持に関するドキュメントをご覧ください。

いいえ。すべてのメトリックは CloudWatch Logs イベントとして取り込まれ、CloudWatch Logs Insights クエリを使用してクエリできます。詳細については、CloudWatch Logs Insights の検索言語構文に関するドキュメントをご覧ください。

(1) ギガバイト (GB) 単位で取り込まれた CloudWatch Logs、(2) 保存された CloudWatch Logs、および (3) CloudWatch カスタムメトリックに使用した分に対してお支払いいただきます。AWS リージョンの料金については、CloudWatch の料金ページをご覧ください。

Amazon CloudWatch Internet Monitor は、AWS でホストされるアプリケーションとアプリケーションエンドユーザー間のインターネットの可用性やパフォーマンスメトリクスを継続的にモニタリングするのに役立ちます。Internet Monitor を使用すると、問題の影響を迅速に可視化して影響を受ける場所やプロバイダーを特定できます。これにより、エンドユーザーのネットワークエクスペリエンスの向上を図ることができます。トラフィックパターンとヘルスイベントをグローバルに把握し、さまざまな地理的詳細レベルでイベントに関する情報を掘り下げることが可能です。問題の原因が AWS ネットワークにある場合は、AWS Health Dashboard に、AWS が行う問題緩和のためのステップに関する通知が届きます。Internet Monitor が提供するインサイトと推奨事項を確認して他の AWS サービスを活用すれば、より良いユーザー体験を顧客に提供することも可能です。

Internet Monitor を使用するには、モニターを作成し、アプリケーションのリソースを Internet Monitor、Amazon Virtual Private Cloud (VPC)、CloudFront ディストリビューション、または WorkSpaces ディレクトリと関連付け、Internet Monitor がアプリケーションのインターネットトラフィックがどこにあるかを把握できるようにします。そして、Internet Monitor は、アプリケーションと通信する場所やネットワークに特化したインターネット測定値を AWS から提供します。

その後、CloudWatch ダッシュボードを使用して、ヘルスイベントについて学び、パフォーマンスと可用性のスコアを表示し、さまざまな地理的詳細レベルでアプリケーションの履歴データを探索し、エンドユーザーのパフォーマンスを改善するためにアプリケーションを設定する方法に関するインサイトを得ることができます。

Internet Monitor はインターネットの測定値を CloudWatch Logs と CloudWatch Metrics にパブリッシュするので、CloudWatch ツールを使用して、簡単に、アプリケーションに固有の地理とネットワークにおけるアプリケーションの正常性をより良く理解することができます。Internet Monitor では、Amazon EventBridge にヘルスイベントを送信するため、通知の設定も可能です。

Internet Monitor を探求する際に、サービス内で参照されるコンポーネントや概念に精通しておくと便利です。Internet Monitor は、Monitor、CloudWatch Logs、CloudWatch メトリクス、都市ネットワーク、ヘルスイベント、AS 番号 (ASN)、モニタリング対象リソース、インターネット測定、ラウンドトリップ時間、転送されるバイト、パフォーマンスと可用性のスコアを使用または参照します。

これらのコンポーネントの簡単な説明は、ドキュメントでお読みください。

Internet Monitor の料金には、以下のコンポーネントがあります。モニタリング対象リソースごとの料金、都市ネットワークごとの料金、CloudWatch Logs にパブリッシュされる診断ログの料金です。詳細については、Amazon CloudWatch Internet Monitor の料金のページをご覧ください。

Internet Monitor の場合、リージョンのサポートは、モニターに追加するリソースの種類に依存します。Amazon CloudFront ディストリビューションと Amazon WorkSpaces ディレクトリの場合、Internet Monitor はサポートされているすべてのリージョンで利用可能です。Amazon Virtual Private Cloud (VPC) の場合、オプトインリージョンからの VPC は、同じリージョンで作成されたモニターにのみ追加することができます。サポートされている AWS リージョンの詳細なリストについては、「Amazon CloudWatch Internet Monitor のエンドポイント」をご覧ください。

CloudWatch Lambda Insights は Lambda 関数のパフォーマンスとコストをモニタリング、トラブルシューティング、および最適化する機能です。Lambda Insights では、Lambda 環境に影響するパフォーマンスの問題を簡単に分離および分析できます。DevOps やシステムエンジニアは CloudWatch コンソールの自動ダッシュボードにアクセスして、AWS Lambda 関数のパフォーマンスと状態を要約したメトリクス、ログ、トレースの運用をエンドツーエンドで可視化できます。

CloudWatch Lambda Insights のドキュメントにある手順に従うと、Lambda 関数から詳細なパフォーマンスのメトリクス、ログ、メタデータを収集できるようになります。

CloudWatch Lambda Insights は、お客様の Lambda 環境から CloudWatch Logs として取り込まれたパフォーマンスイベントから自動でカスタムメトリクスを収集します。料金の詳細については、CloudWatch の料金ページをご覧ください。

Network Monitor は、AWS でホストされているアプリケーションをオンプレミスの宛先に接続するネットワークのパフォーマンスと可視性を提供します。Network Monitor を利用すると、ハイブリッドネットワーク接続のパケット損失とレイテンシーの視覚化、アラートとしきい値の設定、およびエンドユーザーのネットワークエクスペリエンスを改善するための措置の実行を迅速に行うことができます。ハイブリッドネットワーク接続が AWS Direct Connect 経由である場合、Network Monitor を利用することで、ネットワークパフォーマンスの低下の原因を数分以内に特定できます。

Network Monitor は、モニターで設定されている各プローブの往復レイテンシーとパケット損失に関する情報を提供します。さらに、AWS Direct Connect 経由のハイブリッドネットワーク接続の場合、Network Monitor は AWS Network Health Indicator のメトリクスを提供します。これらのメトリクスは、VPC サブネットごとおよび宛先エンドポイントごとに集計され、Amazon CloudWatch に発行されます。その後、Network Monitor コンソール内から CloudWatch ダッシュボードにアクセスして、これらのメトリクスを表示したり、アラームを設定したりできるほか、AWS ネットワークの正常性ステータスを表示して、ネットワークの問題がいつパフォーマンスに影響したかを確認できます。記録されたメトリクスの 30 日間の履歴を観察することによって、パケット損失と往復レイテンシーをベンチマーキングしたり、ネットワークイベントについて通知されるようにアラームを設定したりすることもできます。

Network Monitor の料金は、モニタリング対象リソースごとの料金と、CloudWatch に発行されるメトリクスの料金から構成されます。詳細については、「Amazon CloudWatch 料金表」を参照し、[Network Monitor] タブに移動してください。

Network Monitor を利用するには、モニターを作成し、アプリケーションのリソースをそのモニターに関連付けます。Amazon Virtual Private Cloud (VPC) に属する送信元サブネットを選択し、オンプレミスネットワーク内の宛先 IP アドレスを選択します。Network Monitor は、単一のモニター内に、送信元と宛先の可能な組み合わせのメッシュ (各組み合わせはプローブと呼ばれます) を作成します。Network Monitor の作成は AWS によって完全に管理されており、モニターを設定してから数分以内にリアルタイムのメトリクスを表示できるようになります。Network Monitor は、これらのリアルタイムメトリクスを CloudWatch Metrics に提供するため、CloudWatch のツールを簡単に使用して、ネットワークに固有の AWS リージョンのネットワークの正常性をより深く理解できるようになります。詳細な設定手順については、CloudWatch のドキュメントをご覧ください。

Amazon CloudWatch DEM を使用すると、エンドユーザーがアプリケーションをどのように体験するか (パフォーマンス、アベイラビリティ、ユーザビリティなど) をモニタリングできます。 

断続的な問題を発見し、ユーザートラフィックがない場合でも通知を受け取り、CloudWatch Synthetic Canary を使用してエンドポイントと UI をモニタリングします。CloudWatch RUM で合成モニタリングを補完して、エンドユーザーへの影響を理解し、デジタルエクスペリエンスの可視性を高めます。CloudWatch を使用すると、新しい設計や機能を実験して検証することで、エンドユーザーのデジタルエクスペリエンスを向上させることができます。 

Amazon CloudWatch RUM は、アプリケーションのクライアント側のパフォーマンスを可視化して、解決までの平均時間 (MTTR) を短縮するのに役立つリアルタイムのユーザーモニタリング機能です。CloudWatch RUM を使用すると、ウェブアプリケーションのパフォーマンスに関するクライアント側のデータをリアルタイムで収集して、問題を特定してデバッグできます。CloudWatch Synthetics データを補完して、エンドユーザーのデジタルエクスペリエンスの可視性を高めます。パフォーマンスの異常を視覚化し、関連するデバッグデータ (エラーメッセージ、スタックトレース、ユーザーセッションなど) を使用して、パフォーマンスの問題 (JavaScript エラー、クラッシュ、待ち時間など) を修正できます。また、セッション数、位置情報、ブラウザなど、エンドユーザーへの影響の範囲を理解することもできます。CloudWatch RUM は、アプリケーションを介したユーザージャーニーに関するデータを集約します。これは、起動する機能と優先するバグ修正を決定するのに役立ちます。

CloudWatch RUM でアプリモニターを作成し、アプリケーションの HTML ヘッダーに Lightweight ウェブクライアントを追加します。次に、CloudWatch RUM のダッシュボードの使用を開始して、さまざまな位置情報、デバイス、プラットフォーム、ブラウザからユーザーインサイトを受け取ります。 

Amazon CloudWatch Evidently では、実験を行い、新機能を一般的な利用のためにロールアウトする前に意図しない結果を特定できるようにすることで、新機能のロールアウトに関連するリスクを軽減します。 Evidently により、リリース前にアプリケーションスタック全体で新機能を検証できるため、より安全なリリースが可能になります。 新機能をリリースするときは、小規模なユーザーベースに公開し、ページのロード時間やコンバージョンなどの主要なメトリクスをモニタリングしてから、トラフィックをダイヤルアップできます。また Evidently を使用すると、デベロッパーはさまざまな設計を試したり、ユーザーデータを収集したり、本番環境で最も効果的な設計をリリースしたりすることもできます。高度な統計知識を必要とせずに、実験結果を解釈し行動できるように支援します。Evidently の統計エンジンによってもたらされるインサイト (時間を問わない p 値や信頼区間など) を使用して、実験の進行中に意思決定を行うことができます。

CloudWatch RUM JavaScript コードスニペットを使用して、クライアント側のユーザージャーニーとパフォーマンスメトリクスを収集できます。必要に応じて、Evidently API を使用してコンバージョンなどのカスタムメトリクスを追加することもできます。次に、テストする新機能を CloudWatch Evidently SDK に搭載できます。これにより、ユーザーが新機能にアクセスする方法を制御できます。これで、AWS コンソールまたは CLI のいずれかを使用して、起動と実験を実行できます。 

Amazon CloudWatch Synthetics で、アプリケーションのエンドポイントのモニタリングが簡単になります。CloudWatch Synthetics は 24 時間 365 日、エンドポイントでテストを実行し、アプリケーションエンドポイントで予期しない動作を発見した場合にはすぐに警告します。これらのテストには、可用性、レイテンシー、トランザクション、壊れているか途切れたリンク、タスクのステップごとの完了、ページロードエラー、UI アセットのロードレイテンシー、複雑なウィザードのフロー、アプリケーションでのチェックアウトフローなどをモニタリングするようにカスタマイズできます。また、CloudWatch Synthetics を、警告を発しているアプリケーションエンドポイントの分離のために使う事もでき、インフラストラクチャの下層にある問題と照らし合わせて、解決のための平均時間を削減できます。

CloudWatch Synthetics は簡単に使用を開始できます。数分で最初のパス Canary を作成できます。詳細については、Amazon CloudWatch Synthetics のドキュメントをご覧ください。

2 つのサービスは別々に使用できますが、一緒に使用するとさらに便利です。

AppConfig は、AWS Systems Manager の機能であり、機能フラグやその他のアプリケーション設定を作成、管理、およびデプロイするために使用できます。新しい機能を開発するときは、AppConfig を使用して新しい機能を本番環境にデプロイできますが、フラグトグルの背後に隠れています。起動する準備ができたら、設定を更新するだけで、機能を即座にまたは段階的にリリースできます。

より高度な機能管理と実験のために、Amazon CloudWatch の新機能である Evidently を使用できます。Evidently を使うと、訪問期間や収益などのビジネスメトリクスをモニタリングしながら、さまざまな機能バリエーションでテストを実行してベースラインと比較したり、予定に従い機能バリエーションを起動したりできます。また、Evidently は、クライアント側のアプリケーションパフォーマンスモニタリングを行う CloudWatch RUM とも統合されているため、RUM メトリクスを Evidently で直接使用できます。

CloudWatch Metrics Insights は、運用メトリクスをリアルタイムで細かく分析し、標準 SQL クエリを使用してその場で集計を作成できる高性能クエリエンジンです。Metrics Insights は、メトリクスを大規模に分析する機能を利用して、アプリケーションの正常性とパフォーマンスのステータスを理解するのに役立ちます。CloudWatch ダッシュボードと統合されているため、クエリをヘルスダッシュボードとパフォーマンスダッシュボードに保存して、問題をプロアクティブに監視して迅速に特定できます。

使用開始するには、CloudWatch コンソールの [メトリクス] タブをクリックするだけで、追加費用なしで [クエリ] タブの下に組み込みのクエリエンジンとして Metrics Insights が表示されます。Metrics Insights には、標準の SQL 言語が付属していますが、ビジュアルクエリビルダーを使用して Metrics Insights の使用を開始することもできます。クエリビルダーを使用するには、対象のメトリクス、名前空間、ディメンションを視覚的に選択します。選択内容に基づいて、コンソールが自動的に SQL クエリを構築します。クエリエディタを使用して、生 SQL クエリをいつでも入力して、問題を詳細に掘り下げて特定し、さらに詳細な内容を検討することができます。Metrics Insights には、アプリケーションのパフォーマンスのモニタリングと調査を即座に開始するのに役立つ、すぐに使えるサンプルクエリのセットも付属しています。Metrics Insights は、CloudFormation、AWS SDK、および CLI を介してプログラムで利用することもできます。

Amazon CloudWatch では、AWS のクラウドリソースや、お客様が AWS で実行するアプリケーションのモニタリングを行うことができます。AWS の多数の製品とサービスについて、メトリクスが自動的に生成されます。これに該当するものとしては、Amazon EC2 インスタンス、EBS ボリューム、Elastic Load Balancing、Auto Scaling グループ、EMR ジョブフロー、RDS DB インスタンス、DynamoDB テーブル、ElastiCache クラスター、RedShift クラスター、OpsWorks スタック、Route 53 ヘルスチェック、SNS トピック、SQS キュー、SWF ワークフロー、Storage Gateway があります。お客様自身のアプリケーションやサービスで生成されたカスタムメトリクスをモニタリングすることもできます。

カスタムメトリクスをパブリッシュして 1 秒の解像度まで保存できます。2016 年 11 月 1 日にメトリクス保存期間の延長が開始され、以前は 14 日間でしたが、お客様のすべてのメトリクスを 15 か月保存できるようになりました。CloudWatch では、次のようにメトリクスデータを保持します。

期間が 60 秒未満のデータポイントは 3 時間使用できます。このようなデータポイントが高分解能カスタムメトリクスです。

期間が 60 秒 (1 分) のデータポイントは、15 日間使用できます。

期間が 300 秒 (5 分) のデータポイントは、63 日間使用できます。 

期間が 3600 秒 (1 時間) のデータポイントは、455 日 (15 か月) 間使用できます。

当初、短い期間でパブリッシュされるデータポイントは、長期の保存のために集約されます。例えば、1 分の期間でデータを収集する場合、そのデータは 15 日間、1 分の分解能で使用できる状態で残されます。15 日後、このデータはまだ使用できますが、集約されるので、5 分の分解能でのみ取得できます。63 日後、データはさらに集約されて、1 時間の分解能で使用できます。これらの期間より長くメトリクスを利用する必要がある場合は、GetMetricStatistics API を使用して、データポイントをオフラインまたは異なるストレージに取得することができます。

この機能は現在、米国東部 (北バージニア)、米国西部 (オレゴン)、米国西部 (北カリフォルニア)、欧州 (アイルランド)、欧州 (フランクフルト)、南米 (サンパウロ)、アジアパシフィック (シンガポール)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (ムンバイ)、アジアパシフィック (シドニー)、欧州 (ロンドン)、カナダ (中部)、米国東部 (オハイオ)、中国 (北京) の各リージョンで利用できます。

CloudWatch でサポートされる最小の分解能は 1 秒のデータポイントで、これが高分解能のメトリクスです。または、1 分の粒度でもメトリクスを保存できます。CloudWatch によって受信されるメトリクスは、3 分間隔や 5 分間隔など、さまざまな間隔の場合があります。PutMetricData API リクエストで StorageResolution フィールドを設定して、メトリクスが高分解能であると指定しない場合、CloudWatch はデフォルトで、メトリクスを 1 分の分解能で集約して保存します。

リクエストされたデータの経過時間に応じて異なりますが、メトリクスは上記保存期間スケジュールで定義された分解能で利用できます。例えば、10 日前の 1 日について 1 分間隔のデータをリクエストした場合、1440 のデータポイントを受信することになります。ただし、5 か月さかのぼって 1 分間隔のデータをリクエストすると、UI によって自動的に粒度が 1 時間に変更され、GetMetricStatistics API から出力は返されません。

CloudWatch ではメトリクスの削除はサポートされません。メトリクスは上記の保存期間スケジュールに基づいて有効期間が切れます。

はい。Amazon CloudWatch は複数のソースからのデータのクエリをサポートしているため、AWS、オンプレミス、その他のクラウドでメトリックスをモニタリングできます。重要なイベントを数時間ではなく数分でトラブルシューティングできるようになり、アプリケーションの状態を可視化して、より迅速に洞察を得てシームレスな運用を実現できます。すべての監視ツールにわたるクエリ、視覚化、および警告を 1 か所にまとめます。

いいえ。すべての Amazon EC2 インスタンスのメトリクスデータは、上記の保存期間スケジュールに基づいて常に取得できます。ただし、CloudWatch コンソールでのメトリクスの検索は、メトリクスが最後に取り込まれてから 2 週間に制限され、名前空間で最新のインスタンスが表示されるようにします。

はい。Amazon CloudWatch は、終了した Amazon EC2 インスタンスまたは削除された Elastic Load Balancing のメトリクスを 15 か月間格納します。

はじめに、Amazon CloudWatch コンソールのメトリクスクエリビルダーに移動し、データソースセレクターを開きます。セレクターを使用すると、ウィザードを起動して、クエリやアラームの対象となる新しいデータソースを追加できます。クエリするデータソースを選択し、URL やパス、認証情報などのアクセス詳細を指定します。詳細については、ドキュメントを参照してください。

同じ時間範囲で表示したグラフを5分と1分の間隔で見ると、データポイントがグラフの異なる位置にあるのが分かります。Amazon CloudWatch は、グラフで指定した期間に対して利用可能なすべてのデータポイントを見つけて、その期間を代表する1つの集合点を計算します。5分間の場合は、1つのデータポイントが5分の期間の最初に配置されます。1分の場合は、1つのデータポイントが1分の箇所に配置されます。トラブルシューティングの場合、および正確な時間間隔のグラフを表示したい場合は 1 分の期間を使ってください。

Amazon CloudWatch を使用すると、お客様自身のアプリケーション、スクリプト、サービスで生成されたデータをモニタリングできます。カスタムメトリクスとは、Amazon CloudWatch でモニタリングするためにお客様自身が用意するメトリクスのことです。カスタムメトリクスを使用してモニタリングできるものの例としては、ウェブページのロードに要する時間、リクエストエラー率、インスタンス上のプロセスやスレッドの数、アプリケーションで実行された作業の量などがあります。カスタムメトリクスを使用するには、PutMetricData API を使用します。Windows および Linux 向けのモニタリングスクリプトのサンプル、CloudWatch プラグイン集が用意されているほか、AWS パートナーからも多数のアプリケーションやツールが提供されています。

カスタムメトリクスの分解能は次のいずれかになります。

標準分解能 (データの粒度は 1 分)

高分解能 (データの粒度は 1 秒)

デフォルトでは、メトリクスは 1 分の分解能で CloudWatch に保存されます。PutMetricData API リクエストで StorageResolution パラメータを 1 に設定すると、メトリクスを高分解能として定義できます。オプションの StorageResolution パラメータを設定しないと、CloudWatch はデフォルトで、メトリクスを 1 分の分解能で保存します。

高分解能のメトリクスをパブリッシュすると、CloudWatch はそれを 1 秒の分解能で保存します。ユーザーは、1 秒、5 秒、10 秒、30 秒、または 60 秒の倍数の期間でメトリクスを読み取り、取得できます。

カスタムメトリクスは、上記と同じ保存期間スケジュールに従います。

現在、CloudWatch にパブリッシュしたカスタムメトリクスのみ、高分解能でも利用できます。高分解能カスタムメトリクスは、1 秒の分解能で CloudWatch に保存されます。高分解能は、PutMetricData API リクエストの StorageResolution パラメータで、値として 1 を指定して定義されます。これは必須フィールドではありません。オプションの StorageResolution フィールドに値の指定がないと、CloudWatch はデフォルトで、カスタムメトリクスを 1 分の分解能で保存します。

いいえ、高分解能カスタムメトリクスの料金は、標準の 1 分のカスタムメトリクスと同じです。

お客様自身のデータのモニタリングには、カスタムメトリクスと CloudWatch Logs の一方を使用することも、両方を使用することもできます。データがログ形式で生成されるとは限らない場合、例えばオペレーティングシステムのプロセスやパフォーマンスの測定値の場合は、カスタムメトリクスをお勧めします。または、お客様自身でアプリケーションやスクリプトをプログラミングするか、AWS パートナーから提供されているものを利用することをお勧めします。個々の測定値を付随情報とともに保存する必要がある場合は、CloudWatch ログの使用をお勧めします。

Amazon CloudWatch メトリクスの次の統計値を取得およびグラフ化したり、それらの値に対してアラームを設定したりできます: [平均]、[合計]、[最小]、[最大]、[サンプル数]。統計は、1 分または 60 秒のいずれかの倍数の時間間隔で計算できます。高分解能カスタムメトリクスの場合、統計値は 1 秒以上 3 時間以下の期間について計算できます。

Amazon CloudWatch Application Insights for .NET and SQL Server は .NET および SQL Server アプリケーションを簡単にモニタリングできるようにする機能です。稼働状況の可視化は、主要メトリクスを特定および設定したり、アプリケーションリソースおよびテクノロジースタック (データベース、ウェブ (IIS)、アプリケーションサーバー、OS、ロードバランサー、キューなど) 全体でログを作成したりするのに役立ちます。この製品は異常やエラーを検出および関連付けしたり、アプリケーションで発生しているすべての問題を通知したりするためにこれらのテレメトリデータを継続的にモニタリングします。トラブルシューティングの円滑化を図るため、自動ダッシュボードを作成し、相関したメトリクスの異常やログのエラーなどの検出された問題や潜在的な根本的原因を示唆する追加的な詳細情報をを可視化します。

アプリケーションのメトリクスとログを自動的に認識: アプリケーションリソースをスキャンして、モニタリングすることが推奨されるメトリクスとログのリストを提供し、自動的に設定します。これにより、アプリケーションのモニタリングをより簡単に設定できます。 

インテリジェントな問題検出: 組み込みのルールと機械学習アルゴリズムを使用して、アプリケーションスタック全体の問題の症状を動的にモニタリングおよび分析し、アプリケーションの問題を検出します。個々のメトリクスの急激な増加、イベント、またはログの例外を処理するオーバーヘッドを減らし、代わりに、実際の問題とともに、これらの問題の背後にある情報を合わせた通知を得るにの役立ちます。

より迅速なトラブルシューティング: 検出した問題を評価して、検出した問題の潜在的な根本原因、および問題が原因となって影響を受けたメトリクスとログのリストなど、検出した問題に関するインサイトを提供します。生成したインサイトにフィードバックを提供することで、ユースケースに固有の問題検出エンジンを作成します。

アプリケーションのオンボーディング: アプリケーションに関連付けられた AWS リソースグループを選択し、モニタリングするアプリケーションを指定します。

アプリケーションコンポーネントの特定: アプリケーションリソースを分析して、アプリケーションコンポーネント (スタンドアロンリソース、または Auto Scaling グループやロードバランサーグループなどの関連リソースのグループ) を特定します。より良いインサイトと容易なオンボーディングを達成するために、リソースをグループ化することで、コンポーネントをカスタマイズすることもできます。

モニタリングの有効化: アプリケーションコンポーネントのために、IIS フロントエンド、.NET ワーカー層など、テクノロジー層を指定できます。選択内容に応じて、ニーズごとにカスタマイズが可能なメトリクスやログの推奨セットを提供します。これらの「モニター」が保存できたら、Application Insights for .NET and SQL Server はユーザーに代わりこれらを収集するために CloudWatch を設定します。

オンボードが済むと、Application Insights for .NET and SQL Server は事前組み込みのルールと機械学習モデルの組み合わせを使用して、アプリケーションに存在する問題の特定を始めます。CloudWatch に自動ダッシュボードを作成し、検出された問題のリストと、それらの問題に関連する異常やエラーについての詳細なビューを表示します。

CloudWatch Metric Streams は、最小限のセットアップと設定だけで、ユーザーが希望する送信先に対し、CloudWatch メトリクスを継続的にストリーミングすることを可能にする機能です。このソリューションは完全マネージド型で、使用にあたって、コードの記述やインフラストラクチャーの維持は一切必要ありません。Amazon Simple Storage Service (S3) などの送信先に対するメトリクスストリームを、数クリックのみで設定できます。また、選択したサードパーティサービスプロバイダーにメトリクスを送信することも可能で、運用ダッシュボードを常に最新に保てます。

Metric Streams により、CloudWatch からのメトリクスデータの取得について、API をポーリングする必要がない代替的な手法が提供されます。メトリクスのストリームを数クリックだけで作成し、選択した送信先へのメトリクスデータの伝達を開始できますAmazon S3 などの、AWS 上でのデータレイクへのメトリクスの転送も簡単です。例えば Amazon Athena のようなツールを使用すれば、利用率やパフォーマンスの分析を開始できます。さらに Metrics Streams では、Amazon Kinesis Data Firehose の HTTP エンドポイントを使用している一般的なサードパーティサービスプロバイダーへの、CloudWatch メトリクスの送信がより簡単に行えます。お客様は、最新の CloudWatch メトリクスデータを含む、継続的でスケーラブルなストリームを作成できます。このストリームにより、ダッシュボードやアラーム、その他のツールで、正確かつタイムリーなメトリクスデータが活用できるようになります。

Metric Streams の作成と管理は、CloudWatch コンソールから行えます。あるいは、CloudWatch API、AWS SDK、AWS CLI からプログラム的に行うことも可能です。他には、AWS CloudFormation により Metric Streams をプロビジョニングし設定することもできます。さらに、サードパーティーのサービスプロバイダーが提供する AWS CloudFormation テンプレートを使用して、AWS 外部の送信先に対する Metric Streams の配信をセットアップすることもできます。詳細については、 CloudWatch メトリックスストリームに関するドキュメントを参照してください。

はい。デフォルトを選択すれば、すべてのメトリクスが送信されるようにできますが、名前空間 (例、AWS/EC2) でメトリクスのグループを定義して、それらを送信に含めたり除外するフィルタリングルールを作成することも可能です。Metric Streams により、フィルタリングルールに適合した新しいメトリクスが自動的に検出され、最新のメトリクスがストリームの中に埋め込まれます。リソースが終了されると、Metric Streams は、非アクティブになったメトリクスの送信を自動的に停止します。

Metric Streams の出力には、OpenTelemetry もしくは JSON形式のどちらかが使用されます。出力形式は、Metric Streams を作成もしくは管理する際に選択することができます。

はい。Metric Streams コンソールページのモニタリングセクションから行えます。自動ダッシュボードでは、更新されるメトリクスのデータ量を時間経過とともに目視することができますこれらのメトリクスは、AWS/CloudWatch 名前空間の下でも利用できます。これにより、データ量に通常にはないスパイクが生じた場合に通知を送信するためのアラームを作成できます。

「CloudWatch ログ」とは、お客様のシステムやアプリケーションのモニタリングとトラブルシューティングを、お客様がすでにお持ちのログファイル (システム、アプリケーション、カスタム) を使用して行うための機能です。

CloudWatch Logs を利用すると、お客様のログをほぼリアルタイムでモニタリングして特定の語句、値、パターンを見つけることができます。例えば、システムログに存在するエラーの数についてアラームを設定することや、ウェブリクエストのレイテンシーのグラフをアプリケーションログから作成できます。元のログデータを調べると、問題の発生源がわかります。ログデータは、お客様が指定した期間が経過するまで、高耐久性かつ低コストのストレージに保存されるので、ハードドライブの領域不足について心配する必要はありません。

Amazon CloudWatch の Vended Logs は、本来、お客様の代わりに AWS のサービスが発行するログです。VPC Flow Logs は、この階層モデルを利用できる最初の Vended ログタイプです。とはいえ、今後 AWS のさらに多くのサービスのログタイプが Vended ログタイプに追加されル予定です。

CloudWatch Logs サービスのリージョン別の可用性の詳細については、「製品およびサービス一覧 (リージョン別)」をご覧ください。

最新情報については、料金ページをご覧ください。

CloudWatch Logs では、お客様のログのモニタリングと保存が可能であり、システムとアプリケーションの状態をより良く理解して適切に運用するのに役立ちます。CloudWatch Logs をお客様のログとともに使用するときは、既存のログデータを使用してモニタリングができるので、コードの変更は不要です。Amazon CloudWatch とお客様のログを使用してできることの例を 2 つご紹介します。

アプリケーションとシステムのリアルタイムモニタリング: CloudWatch ログの特徴は、ログデータを使用してほぼリアルタイムでアプリケーションやシステムのモニタリングができることです。例えば、CloudWatch Logs では、アプリケーションログに存在するエラーの数がトラッキングされ、エラー率が指定のしきい値を超えたときに管理者に通知が送信されます。お客様のログデータが Amazon CloudWatch によるモニタリングに使用されるので、コードの変更は不要です。

ログの長期保存:CloudWatch Logs を使用すると、ハードドライブの容量不足を心配することなく、耐久性が高く費用対効果の高いストレージに、必要なだけログデータを保存できます。CloudWatch Logs エージェントをインストールしておくと、ローテーションするログファイルもそうでないログファイルも、ホストから CloudWatch Logs のストレージに簡単に移動できます。これで、生のログイベントデータに、必要なときにアクセスできるようになります。

さまざまなデータやログファイルを CloudWatch に送信するよう EC2Config サービスを設定できます。カスタムテキストログ、イベント (アプリケーション、カスタム、セキュリティ、システム) ログ、イベントトレース (ETW) ログ、パフォーマンスカウンタ (PCW) データなどを送信できます。EC2Config サービスの詳細については、こちらをご覧ください。

CloudWatch ログエージェントからログデータが送信される間隔は、デフォルトでは 5 秒です。この値はお客様が設定できます。

CloudWatch ログでは、テキストベースの一般的なログデータ形式または JSON 形式のログであればどれでも、取り込み、集計、モニタリングが可能です。

テキストではないログデータを報告するように CloudWatch Logs エージェントが設定されている場合は、エラーが記録されます。このエラーは、/var/logs/awslogs.log に記録されます。

メトリクスフィルタを作成して、CloudWatch Logs に送信されるログイベントをモニタリングできます。メトリクスフィルタによってログデータが Amazon CloudWatch のメトリクスに変換されて、グラフやアラームに使用できるようになります。メトリクスフィルタは、コンソールまたは CLI で作成します。メトリクスフィルタで指定されたものに一致する語句や値が、ログイベントの中で検索されます。一致する語句や値がログイベントの中で見つかったときは、選択された Amazon CloudWatch メトリクスでその数がカウントされます。例えば、「Error」という単語をログイベントの中で検索して出現回数を数えるようにメトリクスフィルタを作成します。メトリクスフィルタには、スペースで区切られたログイベントから値を抽出する機能もあります。例えば、ウェブリクエストのレイテンシーです。条件演算子やワイルドカードを使用して完全一致を見つけることもできます。Amazon CloudWatch コンソールには、メトリクスフィルタを作成する前にパターンをテストする機能があります。

メトリクスフィルタのパターンの内容は、検索語か、一般的なログまたは JSON イベント形式の指定です。

例えば、「Error」という単語を検索する場合は、「Error」がそのままメトリクスフィルタのパターンとなります。複数の検索語を指定して複数の単語を検索することもできます。例えば、「Error」と「Exception」という単語が含まれるイベントの数を数えるには、「Error Exception」というパターンを使用します。「Error Exception」という語句を見つけるには、検索語を二重引用符で囲んで "Error Exception" と指定します。指定する検索語の数に制限はありません。

CloudWatch Logs を使用して、一般的なログまたは JSON 形式のログイベントから値を抽出することもできます。例えば、転送されたバイトの数を Apache アクセスログで調べることができます。また、条件演算子やワイルドカードを使用して目的のデータを見つけて抽出することもできます。メトリクスフィルタによる抽出の機能を使用するには、ログイベントがスペースで区切られていることと、フィールドが二重引用符 " " または角かっこ [ ] で囲まれている必要があります。または、JSON 形式のログイベントを使うこともできます。詳しい説明と構文および例については、「デベロッパーガイド」の「メトリクスフィルターの説明」をご覧ください。

CloudWatch Logs には、メトリクスフィルタを作成する前にメトリクスフィルタのパターンをテストする機能があります。パターンのテストは、すでに CloudWatch Logs にあるログデータに対して行うことも、テスト用に用意したログイベントに対して行うこともできます。パターンをテストすると、どのログイベントがメトリクスフィルタのパターンに一致したかがわかります。値を抽出する場合は、テストデータの中のどの値が抽出されたかもわかります。メトリクスフィルタのテストは、コンソールまたは CLI で行います。

Amazon CloudWatch のメトリクスフィルタでは、正規表現はサポートされていません。正規表現を使ってログデータを処理するには、Amazon Kinesis を使用してストリームと正規表現処理エンジンを接続することを検討してください。

ログデータを取り出すには、CloudWatch Logs のコンソールを使用するか、CloudWatch Logs の CLI を使用します。ログイベントの取り出しは、ロググループ、ログストリーム、これらに関連付けられた時刻に基づいて行われます。ログイベントを取り出すための CloudWatch ログ API は GetLogEvents です。

CLI を使用してログイベントを取り出してから、コマンドライン grep などの検索機能を使用して検索してください。

ログデータを CloudWatch Logs に保管できる期間について、特に制限はありません。CloudWatch Logs のデフォルトでは、ログデータが無期限に保管されます。各ロググループの保管期間は、いつでも変更できます。

Amazon CloudWatch ログスタンダードは、CloudWatch が提供する 2 つのログクラスのうちの 1 つです。Logs Standardは、リアルタイム監視と、ライブテール、メトリック抽出、アラーム、データ保護などの高度な分析機能を目的とした包括的なログ管理を提供します。特定のフレーズ、値、パターンについて、ほぼリアルタイムでログを監視できます。例えば、システムログに存在するエラーの数についてアラームを設定することや、ウェブリクエストのレイテンシーのグラフをアプリケーションログから作成できます。元のログデータを調べると、問題の発生源がわかります。

Amazon CloudWatch ログ低頻度アクセス (Logs-IA) は、CloudWatch が提供する 2 つのログクラスのうちの 1 つです。Logs-IA は、すべてのログを AWS にネイティブに統合することを目的として設計されています。CloudWatch Logs Standard のマネージドインジェスト、クロスアカウントログ分析、暗号化を、GB あたりの低価格で提供します。このようにカスタマイズされた機能と低コストの組み合わせにより、CloudWatch Logs-IA はアドホッククエリや事後のフォレンジック分析に最適です。ログデータは、耐久性が高くコストの低いストレージに無期限に保存され、アクセスできるので、ハードドライブの領域不足について心配する必要はありません。

Amazon CloudWatch ログ低頻度アクセス (Logs-IA) は、CloudWatch ログが利用可能なすべての AWS リージョンでご利用いただけます。コンソールから始めることも、AWS CLI や API を使用してプログラム的に開始することもできます。

Logs Insights にアクセスするには、IAM ポリシーに logs:DescribeLogGroups および logs:FilterLogEvents のアクセス権限が含まれている必要があります。

Logs Insights を使用すると、CloudWatch に送信されているすべてのログにクエリを実行できます。Logs Insights は自動的に Lambda、CloudTrail、Route53、VPC Flow Logs といった AWS のサービスから、また JSON 形式でログイベントを生成するあらゆるアプリケーションログから、ログフィールドを発見します。さらに、すべてのログタイプに対し、CloudWatch に送信されるすべてのログついて @message、@logStream、@timestamp という 3 つのシステムフィールドを生成します。@message には解析されていない未加工のログイベントが、@logStream にはログイベントを生成したソースの名前が、@timestamp にはログイベントが CloudWatch に追加された時間が含まれます。

Logs Insights はログ処理に新たな専用クエリ言語を導入しています。このクエリ言語は、シンプルでありながら強力なクエリコマンドをいくつかサポートしています。コマンドを記述して、テキストベースのログから 1 つ以上のログフィールドを取得し、1 つ以上の検索条件と一致するログイベントを見つけ、ログデータを集約し、一時的なフィールドを抽出することができます。クエリ言語は覚えやすく、また Logs Insights でも、サンプルクエリ、コマンド記述、クエリのオートコンプリート機能という形で使用開始時に役立つ製品内ヘルプを提供しています。クエリ言語に関する詳細は、こちらをご覧ください。

サービスの制限はこちらに記載されています。

Logs Insights は、米国西部 (オレゴン)、米国西部 (北カリフォルニア)、米国東部 (オハイオ)、米国東部 (バージニア北部)、アジアパシフィック (ムンバイ)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、南米 (サンパウロ) の各リージョンで利用できます。

集計、フィルタ、正規表現、テキスト検索を含むクエリを記述できます。ログイベントからデータを抽出して、一時的なフィールドを作成することも可能です。これをクエリ言語でさらに処理して、探している情報へのアクセスに役立てることができます。クエリ言語は、concat、strlen、trim、log、sqrt など、文字列、数値、数学関数をサポートしています。また、ブール型や論理型の表現や、最小、最大、合計、平均、パーセンタイルなどの集計関数も使用できます。クエリ言語とサポートしている関数の詳細については、こちらをご覧ください。

クエリコマンドの一覧は、こちらで確認してください。サポートしている関数の一覧は、こちらでご確認ください。

ログで経時的に発生するトレンドやパターンを特定するために、可視化を利用することができます。Logs Insights は、線グラフと積み上げ面グラフを使用したデータの可視化をサポートしています。1 つ以上の集計関数を含むすべてのクエリについて可視化を実現し、bin() 関数で指定した時間間隔でデータをグループ化します。時系列データの可視化に関する詳細は、こちらをご覧ください。

Logs Insights では Java スタイルの正規表現を使用できます。正規表現は、フィルタコマンドで使用できます。正規表現を使用したクエリの例は、製品内ヘルプまたはこちらをご覧ください。

バッククォートを使用すると特殊文字を避けることができます。アルファベット文字、@、. 以外の文字を含むログフィールド名は、バッククォートで避ける必要があります。

Logs Insights が生成したシステムフィールドは、@ で始まります。Logs Insights は現在、CloudWatch に送られた時に解析されていない未加工のログイベントを含む @message、ログイベントを生成したソースの名前を含む @logStream、ログイベントが CloudWatch に追加された時間を含む @timestamp という、3 つのシステムフィールドを生成します。

Logs Insights では、2018 年 11 月 5 日以降に CloudWatch Logs に追加されたログデータにクエリを実行することができます。

特定のログストリームからログイベントを検索するには、クエリコマンド filter @logStream = "log_stream_name" をログクエリに追加します。

CloudWatch Logs はすでに、Amazon Kinesis、Amazon Kinesis Data Firehose、Amazon Elasticsearch などの他の AWS のサービスとの統合オプション、ならびに Splunk、Sumo Logic、DataDog を初めとする AWS パートナー ISV ソリューションとの統合オプションをサポートしています。あらゆる環境での選択肢と柔軟性を提供し、お客様独自のログ処理、強化、分析、可視化のニーズに対応しています。さらに、CloudWatch Logs Insights のクエリ機能には、AWS SDK を介してプログラムでアクセスすることが可能です。そのため、AWS ISV パートナーはより深い統合、高度な分析、そして付加価値を CloudWatch Logs Insights 上で構築できるようになっています。

ISV パートナーと CloudWatch Logs Insights との統合により、ログデータを 1 か所にまとめ、選択したツールやフレームワークを使用した分析を行うことが可能になります。大量のデータを移動させる必要なしに、高性能でコスト効率の高い方法をとることができます。また、この統合は、関連するデータ転送のレイテンシーを取り除くことでログへの迅速なアクセスを実現し、特定のデータ転送を設定し管理する上での運用の複雑さも解消します。

AI/ML を搭載した Amazon CloudWatch Logs Anomaly Detection は自動ログ分析機能で、関連するログをクラスター化してログの調査を迅速化し、ログを時系列で比較して重要な洞察を導き出し、ログをモニタリングして異常な動作が発生した場合は通知して修正を迅速化します。CloudWatch は高度なアルゴリズムを使用して、アプリケーションログの異常なパターンや変化を自動的に検出し、潜在的な問題を警告します。ログが変更されるたびにクエリやフィルターを更新する必要がなくなりました。Logs Anomaly Detection を使用すると、発生しつつあるエラーやログメッセージの急増を影響を受ける前に早期に検出し、詳細を事前に知らなくても新しい問題を特定し、パラメータを設定しなくても異常なアクティビティについてアラートを受け取り、最も重要なログを継続的に監視できます。CloudWatch Logs Anomaly Detection は、潜在的な問題を事前に明らかにすることで、問題を未然に防ぎ、信頼できるパフォーマンスを実現するのに役立ちます。
 

Amazon CloudWatch ログ異常検出は、アプリケーションログ内の異常な動作を自動的に検出するのに役立ちます。メトリックスフィルターなどのツールを使用すると、特定の既知の変数を監視できますが、異常検出では、ログに新たに発生したエラーコードや特定のログメッセージの急激な増加など、これまで知られていなかった状態を特定できます。Logs Anomaly Detection は、時間の経過と共にアプリケーションログに合わせて柔軟に進化するため、クエリやフィルター構文などの複雑な構成パラメーターを定義する必要がありません。ログ異常検出は、最も重要なアプリケーションロググループの保証をさらに強化します。

Amazon CloudWatch ログ異常検出が機能するためには、特定の形式のログは必要ありません。この機能は機械学習を使用してログを柔軟に解析します。CloudWatch Logs Anomaly Detection は、EC2、EKS、ECS、Lambda、およびアプリケーションコードを実行するためのその他のリソースで実行されるアプリケーションコードから生成されるようなアプリケーションログに最も適しています。

Amazon DevOps Guru には、Lambda などの特定のアプリケーションソース向けに設計された異常検出機能が備わっています。Amazon CloudWatch ログ異常検知は、どのアプリケーションログでも機能するソリューションです。CloudWatch ログ異常検出は CloudWatch コンソール内で利用できます。

Amazon CloudWatch Logs Live Tail は、受信ログをリアルタイムで表示できる新しいインタラクティブ分析機能です。Live Tail を使用すると、問題をすばやくトラブルシューティングできます。デベロッパーはログのストリーミングビューを利用してコードをデバッグでき、IT エンジニアはデプロイのステータスを確実に監視できます。Live Tail は、関連するイベントのコンテキストでログをリアルタイムでインタラクティブに表示するため、検出までの平均時間を短縮し、ひいては解決までの平均時間を短縮できます。

ネイティブの AWS Observability ツール内のアプリケーションやデプロイの問題をすぐに検出するには、インタラクティブな CloudWatch Live Tail 機能を使用する必要があります。Live Tail を使用すると、DevOps チームは、複数のツールを切り替えることなく、開発環境内から重要なアプリケーションログとデバッグコードを詳細に可視化できます。Live Tail を使用してデプロイの状態と状態をモニタリングすることで、IT エンジニア、運用サポート、中央セキュリティチームはサービスとアプリケーションを効率的に監視して、根本原因の分析を迅速化し、解決までの平均時間を短縮できます。

Live Tail は、カスタムアプリケーションログに Live Tail 機能を提供するだけでなく、Amazon Virtual Private Cloud、Amazon Route53、AWS Lambda、Amazon Elastic Kubernetes Service、Amazon Elastic Container Service などの AWS サービスによるログに関する深いインサイトを顧客が得るのにも役立ちます。 Live Tail ウィジェットを使用すると、AWS サービスは同じインタラクティブなライブテーリング体験をコンソールに組み込むことができます。さらに、他のサービス (Amazon Managed Grafana、AWS Thinkbox など) で直接統合を実装して、独自のコンソール内やログイベントを生成する任意のアプリケーションログから同じ詳細な分析機能を提供することもできます。

この機能を意図したとおりに動作させるには、次の操作をユーザーに許可する必要があります。Live Tail セッションを開始する際、管理者ロールに含まれていない場合や、logs:* を含むポリシーをお持ちの場合は、ポリシーステートメントに次のアクション (logs:StartLiveTail および logs:StopLiveTail) を追加してください。

Live Tail サービスの制限について詳しくは、こちらをご覧ください。

Live Tail は、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、および南米 (サンパウロ) のリージョンでご利用いただけます。

Log Groups、Log Streams に基づいてフィルタリングしたり、キーワードでフィルタリングしたりできます。ロググループの選択では、モニタリングアカウントでの複数のアカウントにわたる複数の選択が可能です (クロスアカウントオブザーバビリティ)。ログストリームの選択では、名前またはプレフィックスに基づいて複数の選択を行うことができます。キーワードによる絞り込みでは大文字と小文字が区別されます。1 つ以上のキーワード (エラー、例外、障害など) を入力して、検索対象をさらに絞り込むことができます。キーワードを入力するか、情報パネルにあるサンプルからコピーして貼り付けることができます。フィルターパターンの詳細をご覧ください。

いいえ。Live Tail では、CloudWatch によって収集されたログデータをリアルタイムで表示できます。履歴ログについては、Logs Insights と Log Groups 機能を参照してください。

データ保護は、CloudWatch Logs の機能で、システムやアプリケーションから収集されたログ内の機密データを自動的に検出し、マスクするための独自のルールやポリシーを定義することができます。これは、機械学習 (ML) とパターンマッチングを使用して行われます。データは、高い Identity and Access Management (IAM) 権限があれば、マスクされていない状態で閲覧することができます。

機密データをログに残さないために、お客様は手作業で点検したり、短いログ保持ポリシーを設定してログを削除することがありますが、これは、貴重な運用ログを失うリスクを生じます。CloudWatch Logs のデータ保護は、ログにアクセスすることなく、パターンマッチングと機械学習を使用してログ内の機密情報を自動的に識別し、マスキングします。この機能は、個人情報が保存されないようにする必要がある厳しい規制下の業界において役に立ちます。また、多くの個人情報や機密情報を必要とする決済サービスや認証サービスを構築するお客様は、この新機能を利用することで、不要な情報がログに保存される確率を減らすことができます。

CloudWatch Logs でデータ保護ポリシーを作成する際に、保護したいデータを指定することができます。メールアドレス、各国の運転免許証、クレジットカード番号、住所など、多くのデータ識別子を選択することができます。さまざまなターゲットデータ識別子により、柔軟に、アプリケーションで使用する機密データを選択し、簡単にアクセスする必要のない機密データをマスクすることができます。どのような情報がアプリケーションにとって重要であるかを決定し、ユースケースに関連する識別子を選択することが重要です。

作成するアラームでは、お客様のアカウント内の、任意の Amazon CloudWatch メトリクスをモニタリングできます。例えば、Amazon EC2 インスタンスの CPU 使用率、Amazon ELB リクエストのレイテンシー、Amazon DynamoDB テーブルのスループット、Amazon SQS キューの長さ、AWS の料金請求額などについてアラームを作成できます。

カスタムのアプリケーションまたはインフラストラクチャに特有のカスタムメトリクスについてアラームを作成することもできます。カスタムメトリクスが高分解能メトリクスである場合は、10 秒または 30 秒という短い期間で警告を出す高分解能のアラームを作成することもできます。

複合アラームでは、アラームの階層構造の内部で、複数のアラームを組み合わせることが可能です。この機能により、複数のアラームが同時に起動したときでも、トリガーを一度だけにすることでアラームのノイズを低減できます。アプリケーション、AWS リージョン、アベイラビリティーゾーンなど、各リソースのグループ化の全体的な状態を提供できます。

詳細については、CloudWatch の料金ページをご覧ください。

アラームを作成するときに、自動アクションを設定できます。このアクションは、モニタリングするメトリクスがユーザー定義のしきい値を超えたときに実行されます。アラームから実行できることの例としては、メールを送信する、SQS キューに発行する、Amazon EC2 インスタンスを停止または終了させる、Auto Scaling ポリシーを実行する、などがあります。Amazon CloudWatch のアラームは Amazon Simple Notification Service (SNS) と統合されており、SNS でサポートされている通知タイプをすべて使用できます。 AWS Systems Manager の OpsCenter アクションを使用すれば、いずれかのアラームでステータスが ALARM に変わった時点で、自動的に OpsItem を作成させることも可能です。この機能により、単一のコンソールを使用しながら、AWS リソースでの問題の診断と修復を素早く実施できるようになります。

アラームを作成するときは最初に、どの Amazon CloudWatch メトリクスをモニタリングするかを選択します。次に、評価期間 (5 分、1 時間など) と、計算する統計値 (平均、最大など) を選択します。しきい値を設定するには、目標値を設定し、どの状態のときにアラームをトリガーするかを選択します。状態とは、値がその目標値よりも大きい（>）、目標値以上である（>=）、目標値よりも小さい（<）、目標値以下である（<=）、のいずれかです。

選択されたしきい値に対するメトリクスの評価は絶えず行われ、アラームがトリガーされた後でも行われます。これは、アラームの最新の状態がいつでもわかるようにするためです。時には、アラームが長時間 ALARM 状態のままになることもあります。メトリクスの値がしきい値を超えている場合は、しきい値を下回るまで、アラームは ALARM 状態のままになります。これは正常な動作です。その値が正常として扱われるようにするには、アラームのしきい値を調整してください。

参照できるアラーム履歴は 14 日分です。アラーム履歴を参照するには、AWS マネジメントコンソールで CloudWatch にログインし、左のメニューで [Alarms] を選択し、アラームを選択し、下のパネルにある [History] タブをクリックします。ここには、そのアラームの状態変化の履歴が表示され、アラーム設定が変更された場合はそのことも表示されます。

Amazon CloudWatch ダッシュボードにより、AWS リソースとカスタムメトリクスのグラフを作成、カスタマイズ、およびグラフとのやり取りや保存が可能です。

使用を開始するには、Amazon CloudWatch コンソールで [Dashboards] を選択します。[Create Dashboard] ボタンをクリックします。 [Option]、[Add to Dashboard] の順にクリックして、自動ダッシュボードから必要なビューをコピーすることもできます。

自動ダッシュボードは、AWS のサービスが推奨するベストプラクティスにあらかじめ構築済みであり、リソースを認識したまま、動的に更新して重要なパフォーマンスメトリクスの最新の状態を反映します。AWS のリソースの最新状態を反映するためにコードを追加することなく、特定のビューのフィルタリングとトラブルシューティングを行うことが可能になりました。パフォーマンスの問題を引き起こす根本原因を特定できれば、AWS リソースに直接アクセスし、迅速に対応することができます。

はい。ダッシュボードを開いている間、自動更新されます。

はい。ダッシュボードはそのダッシュボードのアカウントの正しいアクセス権限をお持ちのどなたでも利用可能です。

Amazon CloudWatch Events (CWE) は、AWS リソースの変更を説明するシステムイベントストリームです。このイベントストリームは CloudWatch のメトリクスやログの既存のストリームを補足するもので、アプリケーションの状態をより総合的に表示します。お客様は宣言型のルールを記述して、目的のイベントと自動的に実行するアクションを関連付けます。

現在、Amazon EC2、Auto Scaling、AWS CloudTrail がサポートされています。AWS CloudTrail を使用すると、サービス全体でミューテートしている API 呼び出し (つまり、Describe*、List*、および Get* 以外のすべての呼び出し) を CloudWatch Events で表示できます。

システムで作成したルールにイベントが一致した場合、AWS Lambda 機能を呼び出すこと、イベントを Amazon Kinesis ストリームに中継すること、Amazon SNS トピックを通知すること、組み込みのワークフローを呼び出すことなどを自動的に実行できます。

はい。PutEvents API を使用することにより、お客様の個別のニーズに適したペイロードのカスタムイベントをアプリケーションから出力できます。

CloudWatch Events では、Unix の一般的な cron 構文を使用することにより、設定したスケジュールに沿ってイベントを生成できます。このようなイベントをモニタリングすることによって、スケジュールされたアプリケーションを実装できます。

CloudWatch Events は、AWS リソースの変更を説明する、ほぼリアルタイムのシステムイベントストリームです。CloudWatch Events を使うと、特定のイベントをモニタリングし、自動的にアクションを実行するルールを定義できます。AWS CloudTrail は、お客様の AWS アカウントの API 呼び出しを記録し、API 呼び出しを含むログファイルを Amazon S3 のバケットや CloudWatch Logs のロググループに配信するサービスです。AWS CloudTrail を使うと、AWS リソースの作成、削除、および変更に関連する API アクティビティの履歴を参照し、オペレーションやセキュリティの問題をトラブルシューティングできます。

AWS Config は、セキュリティとガバナンスのためのフルマネージド型のサービスであり、ご利用の AWS リソースのインベントリ、構成履歴、構成変更通知の機能を備えています。Config のルールは、設定の変更がポリシーに準拠しているかどうかを判断するのに役立ちます。CloudWatch Events は、リソースの状態の変更にほぼリアルタイムで反応するために使用します。その変更がポリシーに準拠しているかどうか判断することや、Config や Config のルールのように詳細な履歴を表示することはできません。CloudWatch Events は汎用のイベントストリームです。