Amazon CloudWatch のよくある質問

Amazon CloudWatch は、クラウドリソースと AWS で実行されるアプリケーションの AWS のモニタリングサービスです。Amazon CloudWatch を使用して、メトリクスを収集/追跡し、ログファイルを収集してモニタリングし、アラームを設定できます。Amazon CloudWatch は、Amazon EC2 インスタンス、Amazon DynamoDB テーブル、Amazon RDS DB インスタンスなどの AWS リソース、アプリケーションやサービスに生成されたカスタムメトリクス、オンプレミス、ハイブリッド、別のクラウドでホストされる、アプリケーションが生成するあらゆるログファイルをモニタリングできます。Amazon CloudWatch を使用して、リソース使用率、アプリケーションパフォーマンス、オペレーションの状態においてシステム全体の可視性を得られます。これらのインサイトを使用して対応し、アプリケーションのスムーズな動作を維持できます。

モニタリングの開始には、AWS のベストプラクティスを組み込んだ自動ダッシュボードを使用できます。このダッシュボードで、アカウントとリソースに基づいたメトリクスおよびアラームの表示を確認し、パフォーマンスの問題を引き起こす根本的原因をドリルダウンにより簡単に把握することができます。

Amazon CloudWatch では、複数の方法でオペレーション、セキュリティ、コンプライアンスのデータを収集し、取り込むことができます。CloudWatch Agent を使用して、AWS、オンプレミス、マルチクラウドで実行されているホストからメトリクスとログを収集できます。CloudWatch では OpenTelemetry (OTel) がサポートされているため、任意の OTel 互換エージェントを使用してアプリケーションを設定できます。CloudWatch では、Amazon VPC フローログ、Amazon EKS クラスターログ、Amazon Bedrock AgentCore ログ、AWS CloudTrail 管理およびデータイベントなど、さまざまな AWS ソースのフルマネージド型のログ取り込み機能を提供しています。CloudWatch は、一般的なサードパーティデータソース用のマネージド型コレクターも提供しています。さらに、AWS Lambda を含む多くの AWS サービスは、CloudWatch と完全に統合されているため、オブザーバビリティに優れています。

Amazon CloudWatch には、API、コマンドラインインターフェイス、AWS SDK、AWS マネジメントコンソールからアクセスできます。

Amazon CloudWatch は、あらゆる Amazon EC2 インスタンスのメトリクスの受信と提供を行っています。したがって、現在 Amazon EC2 サービスによってサポートされている、すべてのオペレーティングシステムに対応しています。

Amazon CloudWatch は AWS Identity and Access Management (IAM) と統合されているため、AWS アカウント内のユーザーが実行できる CloudWatch のアクションを管理者が指定できます。例えば、組織内の特定のユーザーのみに GetMetricStatistics の使用を許可するように IAM ポリシーを作成するとします。そうしたユーザーはその後にアクションを使用してクラウドリソースに関するデータを取得できるようになります。

IAM を使用しても、特定のリソースに対応する CloudWatch データへのアクセスを制御することはできません。例えば、特定のインスタンスまたは特定のロードバランサーのみについて CloudWatch データへのアクセスをユーザーに許可することはできません。IAM を使用して付与されるアクセス許可の対象は、CloudWatch でモニタリングされるすべてのクラウドリソースです。また、IAM のロールを Amazon CloudWatch のコマンドラインツールで使用することはできません。

CloudWatch Logs エージェントは、Amazon Linux、Ubuntu、CentOS、Red Hat Enterprise Linux、Windows に対応しています。このエージェントをインストールすると、ホスト上の個々のログファイルをモニタリングできるようになります。

はい。CloudWatch ログエージェントは Identity and Access Management (IAM) と統合されており、アクセスキーと IAM ロールの両方がサポートされます。

Amazon CloudWatch Logs Insights とは、インタラクティブな CloudWatch Logs 用ログ分析機能です。従量課金制で利用できます。ログの検索と視覚化を可能にすることで、デベロッパー、オペレーター、システムエンジニアがアプリケーションを把握し、改善し、デバッグするのに役立ちます。Logs Insights は CloudWatch と完全に統合されており、ログの管理、調査、分析を可能にします。Logs とともに CloudWatch メトリクス、アラーム、ダッシュボードを活用し、アプリケーションの運用を完全に可視化することもできます。これにより、アプリケーションについて把握し、改良を行い、迅速に問題を見つけて修正することが可能になるため、革新を促進し続けることができます。集計、フィルター、正規表現を使用してクエリを記述し、ログから実用的なインサイトを引き出すことができます。また、時系列データを視覚化し、個別のログイベントにドリルダウンして、クエリ結果を CloudWatch ダッシュボードにエクスポートすることもできます。

今すぐ Logs Insights を使用して、CloudWatch Logs に送信されているすべてのログにクエリを実行できます。セットアップの必要はなく、インフラストラクチャの管理も不要です。Logs Insights には、AWS マネジメントコンソールか、AWS SDK を使用してプログラムしたアプリケーション経由でアクセスできます。

Amazon CloudWatch 異常検出は、機械学習アルゴリズムを適用して、システムとアプリケーションの単一の時系列を継続的に分析し、通常のベースラインを明らかにして、最小限のユーザー介入で異常を特定します。時刻、曜日の季節性、変化する傾向などの自然なメトリクスパターンに基づいて、しきい値を自動調整するアラームを作成できます。また、ダッシュボード上の異常検出バンドを使用してメトリクスを視覚化して、メトリクスの予期しない変化をモニタリング、分離、トラブルシューティングすることもできます。

異常検出の使用を開始するのは簡単です。CloudWatch コンソールで、ナビゲーションペインの [アラーム] に移動してアラームを作成するか、または [メトリクス] から開始して、メトリクスの想定値をバンドとしてグラフにオーバーレイします。AWS CLI、AWS SDK、または AWS CloudFormation テンプレートを使用して、異常検出を有効にすることもできます。詳細については、CloudWatch 異常検出のドキュメントと料金のページをご覧ください。

Amazon CloudWatch に Contributor Insights が含まれるようになりました。このため、システムパフォーマンスに最も影響を及ぼしているコントリビューターを表示する時系列データの分析が可能になりました。Contributor Insights を一度セットアップしてしまえば、それ以降ユーザーによる操作は必要なく、継続的に実行することができます。この機能により、デベロッパーや操作担当者は、オペレーションイベントの発生中に、問題の分離、診断、修正を迅速に実行できます。

CloudWatch コンソールで、ナビゲーションペインから Contributor Insights を開き、Contributor Insights ルールを作成します。AWS CLI、AWS SDK、または AWS CloudFormation テンプレートを使用して、Contributor Insights を有効にすることもできます。Contributor Insights は、すべての AWS 商用リージョンで利用可能です。詳細については、CloudWatch Contributor Insights のドキュメントをご覧ください。

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

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

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

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

別途記載がない限り、表示される料金には付加価値税、売上税などの税金および関税は一切含まれません。詳細をご覧ください。

2017 年 7 月以前、CloudWatch の料金は、AWS 請求書およびコストと使用状況のレポートで 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 は、すぐに使用できる分析機能と視覚化機能により、アプリケーションのトランザクション全体の状態とパフォーマンスに関する分析情報を即座に提供します。チームは、CloudWatch Application Signals とシームレスに統合されたこの機能を使用して、アプリケーションの監視、トラブルシューティング、最適化を簡単かつ効率的に実行できるようになります。

Application Signals を使用するには、CloudWatch 用 AWS マネジメントコンソールで有効にするか、Amazon EKS クラスターなどの AWS リソースで CloudWatch を有効にします。アプリケーションの導入は Amazon CloudWatch エージェントに含まれています。アプリケーションサービス、サービス用 API、依存関係は、概要ビューとアプリケーションマップで検出および可視化されます。アプリケーションマップは、アカウントやリージョン間の構成と関係に基づいて、監視対象アプリケーションと監視対象外アプリケーションを自動的に検出してグループ化します。ビジネスへの影響と重要性を反映するために、標準アプリケーションメトリクス、リアルユーザーモニター、または合成モニターでサービスレベル目標 (SLO) を数回のクリックで作成できます。自動運用監査と変更履歴を活用すると、トラブルシューティングが容易になります。追加料金はありません。コンソールの「Enable more APM」ビューには、監視対象リソースと監視対象外リソースが表示されます。これにより、お客様はアプリケーションの可視性を徐々に高めることができます。CloudWatch の設定を使用して、重要なサービスのトレースサンプリングを増やし、支払い注文などの重要なトランザクションの例をより多くキャプチャできます。外部の可用性モニタリングまたはUIワークフローを追加するには、合成 Canary を追加します。クライアントの可視性を追加するには、WebアプリケーションでRUMテレメトリを有効にします。アプリケーションのトランザクションスパンを完全に可視化できる Application Signals の使用を開始するには、ドキュメントを参照してください。

Amazon CloudWatch Application Signals は、EKS で実行されている住宅ローン支払い処理システムなどのアプリケーションサービスを検出し、API (ユーザーの追加、注文、支払いなど) のボリューム、レイテンシー、エラー、障害および依存関係 (アプリケーションサービス間、AWS サービス、または外部エンドポイントへの呼び出しなど) に関する標準アプリケーションメトリクスセットを生成します。お客様は、サービスレベル目標を定義することで、アプリケーションサービス、API、依存関係のビジネスへの影響と重要性を反映できます。CloudWatch 用 AWS マネジメントコンソールに導入された新しいアプリケーション中心のオブザーバビリティビューは、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 イベントを生成します。検出された問題に関する自動ダッシュボードがトラブルシューティング用に作成されます。ダッシュボードには、相関関係のある指標の異常やログエラーが含まれ、潜在的な根本原因を特定するための情報を得ることもできます。

Amazon CloudWatch Application Signals は、標準化されたアプリケーションメトリクスと、CloudWatch 用 AWS マネジメントコンソールに導入されたアプリケーション中心のオブザーバビリティビューにより、Amazon CloudWatch を拡張します。カスタム導入を記述しなくても開始できます。新しいビューでは、アプリケーションの状態の概要が示されるため、ビジネスへの影響の判断や優先順位付けに役立ちます。また、詳細を確認して根本原因を迅速に特定できます。
Application Signals をユーザーが有効にすると、アプリケーションのトランザクションスパンが完全に可視化され、あらゆる規模で高機能な検索および分析エクスペリエンスを利用できるようになります。この包括的なソリューションは、サンプリングにとどまらず、トランザクション関連のビジネスインパクトとアプリケーションのパフォーマンスを迅速に結び付けることができます。CloudWatch は、すぐに使用できる分析機能と視覚化機能により、アプリケーションのトランザクション全体の状態とパフォーマンスに関する分析情報を即座に提供します。この機能により、チームはアプリケーションのモニタリング、トラブルシューティング、最適化を簡単かつ効率的に実行できるようになります。

X-Ray トレースは、開発者による本番環境や分散アプリケーションの分析とデバッグに役立ちます。また、アプリケーションを通過するリクエストをエンドツーエンドで把握できます。

X-Ray を使用すると、以下の作業を簡単に行えます。

1. サービスマップの作成: X-Ray はリクエストを追跡して、使用中のサービスをマッピングし、アベイラビリティーゾーンまたはリージョン間の接続、依存関係ツリー、問題を表示します。

2. エラーとバグの特定: X-Ray は応答コードを分析して自動的にバグを特定し、再現させることなく簡単にデバッグできるようにします。

3. カスタム分析および視覚化アプリの構築: X-Ray のクエリ API を使用すると、記録したデータを活用するアプリを作成できます。

リクエストと同じトレース ID を共有するデータポイントのセットが、アプリケーションサービスを経由します。

• セグメント: システム定義データおよびユーザー定義データを含む、分散アプリケーションの単一コンポーネントをカプセル化するデータです。

• 注釈: セグメントに関連付けられたシステム定義のデータまたはユーザー定義のデータです。

• エラー:メッセージ、スタックトレース、ソースの詳細など、エラーが発生した呼び出しのセグメントに関するシステムの注釈です。

• サンプリング: X-Ray は、パフォーマンスと費用対効果の観点から、すべてのリクエストではなく、統計的に有意な数のリクエストのデータを収集します。

• X-Ray デーモン: トレースを収集して X-Ray に送信するサービスで、API を直接使用する場合に比べて処理が簡略化されます。

X-Ray を使い始めるには、アプリケーションに X-Ray 言語 SDK を組み込み、X-Ray デーモンをインストールします。詳細については、X-Ray ユーザーガイドを参照してください。

X-Ray では、あらゆるサイズの分散アプリケーションを使用して、同期リクエストと非同期イベントの両方を追跡してデバッグすることができます。例えば、ウェブアプリケーションに対するウェブリクエストや、 Amazon SQS キューを使用した非同期イベントなどを追跡できます。

X-Ray は、EC2、ECS、Lambda、Amazon SQS、Amazon SNS、Elastic Beanstalk で実行中のアプリケーションで使用できます。また、X-Ray SDK では、AWS SDK を使用して、AWS のサービスに対する API コールのメタデータが自動的に取得されます。さらに、X-Ray SDK には、MySQL ドライバーおよび PostgreSQL ドライバー用のアドオンも用意されています。

Elastic Beanstalk を使用している場合は、言語固有の X-Ray ライブラリをアプリケーションコードに含める必要があります。EC2 や ECS など、他の AWS サービスで実行されているアプリケーションの場合は、X-Ray デーモンをインストールし、アプリケーションコードを導入する必要があります。

はい。X-Ray にはリクエストデータの取り込み、追跡のクエリ、サービスの設定を行う API セットが用意されています。X-Ray API を使用すると、X-Ray で用意されているものに加えて、分析と可視化のためのアプリケーションを構築することができます。

はい。X-Ray はすべての API コールを管理イベントとして記録します。また、追跡される呼び出しはデータイベントとして記録されます。これには、PutTraceSegments や GetTimeSeriesServiceStatistics などの API が含まれます。データイベントはデフォルトでは記録されません。データイベントを記録するには、CloudTrail の証跡またはイベントデータストアでイベントを収集するように設定する必要があります。

CloudWatch Container Insights は、Amazon ECS、Amazon EKS、Amazon EC2 上の Kubernetes プラットフォーム、AWS Fargate (Amazon ECS と Amazon EKS 両方) で実行される、コンテナ化されたアプリケーションおよびマイクロサービス由来のメトリクスとログの収集、集計、要約を実行します。Container Insights は、CPU、メモリ、ディスク、ネットワークメトリクスなどのコンテナメトリクスを直ちに収集し、コンテナの再起動エラーなどのより詳細な診断情報を提供するため、問題の特定と迅速な解決に役立ちます。Container Insights は、自動ダッシュボードでコンテナのオブザーバビリティを提供し、アプリケーションの状態とパフォーマンスを簡単にモニタリングできるようにします。Container Insights メトリクスに CloudWatch アラームを設定して、アプリケーションのパフォーマンスに影響が生じる前に異常が通知されるようにすることもできます。

オブザーバビリティが強化された Container Insights が、EC2 の Amazon Elastic Kubernetes Service (Amazon EKS)、EC2 の Amazon Elastic Container Service (Amazon ECS)、Fargate の ECS で利用できるようになりました。オブザーバビリティが強化されたことにより、コンテナレベルの ECS および EKS のパフォーマンスメトリクス、EKS Kube 状態メトリクス、EKS コントロールプレーンメトリクスなどの詳細なメトリクスが直ちに提供され、さまざまなコンテナレイヤーの詳細を視覚的に確認して、個々のコンテナにおけるメモリリークなどの問題を簡単に特定できます。Container Insights では、リソースを大量に消費しているコンテナレイヤーのリストが表示されるようになりました。これにより、アラームをまだ設定していなくても、環境内のリスクを特定し、エンドユーザーエクスペリエンスに影響が生じる前にプロアクティブな対策を講じることができます。強化オブザーバビリティを備えた Container Insights は、簡単に利用を開始できます。EKS 用の CloudWatch Observability アドオンを使用してクラスターを自動導入するか、ECS を一度切り替えてオプトインすることで、すぐにテレメトリの取り込みを開始できます。

オブザーバビリティが強化された Container Insights により、Amazon EKS および Amazon ECS コンテナレイヤーを視覚的に掘り下げ、個々のコンテナのメモリリークなどの問題を簡単に特定できるため、解決までの平均時間を短縮できます。 オブザーバビリティが強化されているため、コンテナレベルの可視性の利点をすぐに活用できます。オブザーバビリティを強化するには、Amazon CloudWatch Container Insights のドキュメントに記載されているステップに従ってください。

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

Amazon CloudWatch Container Insights の強化されたオブザーバビリティはオプション機能です。稼働状況とパフォーマンスに関する詳細なメトリクスを、設定なしですぐに利用できるようになりました。これにより、コンテナレベルの ECS および EKS パフォーマンスメトリクス、EKS Kube-state メトリクス、EKS コントロールプレーンメトリクスなどを利用できるようになり、より迅速に問題を分離してトラブルシューティングできます。 オブサーバビリティの強化がない場合でも、Container Insightsはクラスターレベルとサービスレベルで集約メトリクスを提供します。

はい。Container Insights は、クラスターごとにオブザーバビリティの強化の有無を設定できます。EKS の場合、クラスター情報ビューの [アドオン] タブを使用してクラスターを作成した後に、CloudWatch Observability アドオンをインストールすることで、クラスターのオブザーバビリティを強化できます。ECS の場合、クラスター作成ワークフローの [監視] タブで拡張を切り替えるか、既存のクラスターを更新して同じ操作を行い、オブザーバビリティを強化した Container Insights をオンボードします。ECS のアカウントレベルで、強化されたオブザーバビリティを組み込むこともできます。これにより、そのアカウントで新たに追加されたクラスターはすべて、追加設定なしですぐにオブザーバビリティが強化された Container Insights をオンボーディングできるようになります。詳細については、CloudWatch Container Insights のドキュメントを参照してください。

CloudWatch Observability アドオンを EKS クラスターにインストールするか、ECS をクラスターまたはアカウントレベルでオプトインすることで、コンテナやクラスター由来の詳細なパフォーマンスメトリクス、ログ、メタデータの収集を開始できます。Container Insights の利用を開始するには、Amazon CloudWatch Container Insights のドキュメントに記載されている手順に従ってください。

オブザーバビリティが強化されたコンテナインサイトは、EC2 で実行されている Amazon EKS、EC2 で実行されている Amazon ECS、AWS Fargate をサポートしています。

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

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

Prometheus は、人気のあるオープンソースの監視プロジェクトで、クラウドネイティブコンピューティング財団 (CNCF) の一部となっています。オープンソースコミュニティは 150 以上のプラグインを構築し、DevOps チームがアプリケーションからプルベースのアプローチを使って収集されるカスタムメトリックを公開するために使用できるフレームワークを定義しました。この新機能により、DevOps チームは、AWS App Mesh、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 の料金ページをご覧ください。

CloudWatch Database Insights は、DevOps エンジニア、アプリケーション開発者、データベース管理者 (DBA) に精選した機能を提供するよう設計された、データベースオブザーバビリティソリューションです。データベースのトラブルシューティングを効率化し、データベースフリートの健全性に対する総合的なビューを提供します。 これは Amazon Aurora データベースと RDS データベースで利用できます。

CloudWatch Database Insights では、アプリケーションおよびデータベース、またそれらを実行するオペレーティングシステムのログとメトリクスを、コンソールの一元的なビューに統合します。DevOps エンジニアは、事前構築済みのダッシュボード、推奨アラーム、自動化されたテレメトリ収集、DVA を使用してデータベースフリートの状態を監視し、ガイド付きのトラブルシューティングエクスペリエンスで個々のインスタンスの詳細を確認し、根本原因を分析することができます。アプリケーション開発者は、データベースの依存関係による影響を、ビジネス上重要なアプリケーションのパフォーマンスおよび可用性に関連付けて把握することができます。これは、CloudWatch Application Signals のアプリケーションパフォーマンスビューの内容から、CloudWatch Database Insights の特定の依存データベースに至るまでの詳細を確認できるためです。

CloudWatch の Database Insights の使用を開始するには、Aurora クラスターおよび RDS データベースで有効化します。Database Insights では、ランディングページを通じてデータベースフリート全体の状態とパフォーマンスを可視化できるようになりました。ランディングページでは、インスタンスレベルのダッシュボードに移動してデータベースと SQL の詳細なクエリ分析を行うことができます。

Database Insights はすべてのパブリック AWS リージョンで利用でき、新しい vCPU ベースの料金が適用されます。詳細については料金表ページをご覧ください。その他の詳細については、Database Insights のドキュメントをご覧ください。

• RDS Performance Insights は、標準のデータベースパフォーマンスのチューニングと監視を行う機能です。この機能により、ユーザーは事前構築済みのダッシュボードで、一度につき 1 つのインスタンスを対象に、データベースの負荷を評価できます。
• CloudWatch Database Insights には RDS Performance Insights 機能が含まれています。これは高度で包括的なデータベースオブザーバビリティ機能で、DevOps エンジニアとデータベース管理者 (DBA) が、データベースおよび対応するアプリケーションのトラブルシューティングを大規模に実行できるよう設計されています。フリートレベルのビュー、Application Signals によるアプリケーションパフォーマンスモニタリング (APM) との統合、データベースメトリクスとログやイベントの関連付け、SQL クエリ統計の視覚化などを実行できます。

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 関数のパフォーマンスと状態を要約したメトリクス、ログ、トレースの運用状況をエンドツーエンドで可視化できます。

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

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 を使用すると、リアルユーザーモニタリングを実行し、実際のユーザーセッションによるウェブおよびモバイルアプリケーションのパフォーマンスに関するクライアント側データを、ほぼリアルタイムで収集および表示することができます。ウェブアプリケーションについては、ページの読み込み時間、クライアント側のエラー、ユーザーの動作を分析できます。モバイルアプリケーションでは、画面の読み込み時間、アプリの起動時間、ネットワークエラー、クラッシュ、プラットフォーム固有の問題 (Android の ANR (アプリケーションが応答しない)、iOS アプリのハングアップなど) をモニタリングできます。このデータ表示では、すべての集約データの他、デバイスタイプ別やオペレーティングシステム別など、アプリケーションの利用状況に合わせた特性による内訳も確認できます。

モバイルアプリケーションをモニタリングするには、モバイルプラットフォーム用に設定されたアプリケーションモニターを作成し、AWS Distro for OpenTelemetry (ADOT) SDK をアプリケーションに統合します。モバイル用 RUM は、OpenTelemetry Protocol (OTLP) を使用して、テレメトリデータを専用の OTLP エンドポイントに送信します。ウェブ用の場合は、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 EC2 インスタンスのメトリクスデータは、上記の保存期間スケジュールに基づいていつでも取得できます。ただし、CloudWatch コンソールでのメトリクスの検索は、名前空間に最新のインスタンスが表示するため、メトリクスが最後に取り込まれてから 2 週間に制限されます。

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

はい。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 により、ポーリング API を使用せずに、CloudWatch のメトリクスデータを取得することができます。メトリクスのストリームを数クリックだけで作成し、選択した送信先へのメトリクスデータの伝達を開始できます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 Metric Streams に関するドキュメントを参照してください。

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

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

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

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

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

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

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

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

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

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

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

EC2Config サービスで、さまざまなデータやログファイルを CloudWatch に送信するように設定できます。送信するデータには、カスタムテキストログ、イベント (アプリケーション、カスタム、セキュリティ、システム) ログ、イベントトレース (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 を使用したプログラムで開始することもできます。

Amazon CloudWatch には、データを分析するオプションが複数用意されています。CloudWatch Logs Insights では、コンソールで自然言語または選択した複数のクエリ言語を使用して、ログのクエリを直接実行できます。分析や視覚化に必要な抽出/変換/読み込み (ETL) 作業を一切行うことなく、データを Amazon OpenSearch Service に接続できます。CloudWatch では、高度な分析機能と新たなビジネスインサイトをご活用いただくため、Amazon S3 Tables 経由のデータを追加ストレージ料金なしで提供しています。また、お好みの Apache Iceberg 互換ツール (Amazon SageMaker Unified Studio、Amazon Quick Suite、Apache Spark など) をご利用いただけます。

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 に追加された日時が含まれます。

CloudWatch Logs Insights を使用すると、Amazon CloudWatch Logs のログデータをインタラクティブに検索し分析することが可能になります。クエリを実行すると、運用上の問題への対応を効率化し、効果を上げることができます。

CloudWatch Logs Insights は、クエリに使用できる 3 つのクエリ言語をサポートしています。

• Logs Insights 専用のクエリ言語 (Logs Insights QL) には、いくつかの高機能なコマンドが含まれています。テキストベースのログから 1 つ以上のログフィールドを取得する、1 つ以上の検索条件と一致するログイベントを見つける、ログデータを集計する、一時的なフィールドを抽出するなどの作業を実行するコマンドを記述できます。
• OpenSearch Service パイプ処理言語 (PPL)。OpenSearch PPL を使用すると、パイプ (|) で区切られた一連のコマンドでログを分析できます。PPL では、複数のコマンドをパイプで組み合わせてデータをクエリおよび分析できるため、複雑なクエリの理解と作成が容易になります。また、コマンドを使用してデータをフィルタリングおよび集計する機能や、分析用の数学関数、文字列関数、日付関数、条件関数が豊富に用意されています。
• OpenSearch Service 構造化クエリ言語 (SQL)。OpenSearch SQL クエリでは、宣言を使用してログを分析できます。OpenSearch SQL では、SELECT、FROM、WHERE、GROUP BY、HAVING などのコマンドや、その他のさまざまな Spark SQL コマンドおよび関数を使用できます。ロググループ間で JOIN を実行する、サブクエリを使用してデータを関連付ける、JSON、演算、文字列、条件などの豊富な Spark SQL 関数を使用してログを分析するといった操作ができます。

Logs Insights でも、サンプルクエリ、コマンド記述、クエリのオートコンプリート機能など、使用開始時に役立つ製品内の機能を提供しています。クエリ言語に関する詳細は、こちらをご覧ください。

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

Logs Insights QL は、CloudWatch Logs が利用可能なすべてのリージョンで利用できます。OpenSearch PPL と OpenSearch SQL は、OpenSearch ダイレクトクエリサービスが利用できるリージョンで利用できます。

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

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

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

Logs Insights のクエリの結果を可視化するだけではなく、VPC、CloudTrail、WAF などの Vended Logs 用としてすぐに使える OpenSearch ダッシュボードを作成できます。このダッシュボードは、OpenSearch インデックスに基づいています。この統合の一環として、OpenSearch Serverless インスタンスが作成され、料金が発生するため、お客様には明示的なオプトインが必要となります。
VPC フローログダッシュボード: このダッシュボードは、仮想プライベートクラウドのネットワークフローデータを取得します。お客様がネットワークトラフィックを分析し、異常なパターンを検出して、リソースの使用状況を監視できるように設計されています。現在、VPC v2 フィールド (デフォルト形式) のみがサポートされています。カスタム形式のフィールドはサポートされていません。CloudTrail ダッシュボード: このダッシュボードには、CloudTrail Logs を使用する AWS 環境内の API アクティビティの概要が表示されます。API アクティビティの監視、アクションの監査、潜在的なセキュリティまたはコンプライアンスの問題の特定に役立ちます。WAF ダッシュボード: このダッシュボードは、AWS WAF (Web アプリケーションファイアウォール) によって監視されているウェブトラフィックに関する分析情報を提供します。このダッシュボードは、特定の地域や IP からのトラフィックパターン、ブロックされたリクエスト、潜在的な脅威の特定に役立ちます。OpenSearch の料金表と無料トライアルについては、CloudWatch Logs の料金セクションをご覧ください。

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

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

Logs Insights が生成したシステムフィールドは、冒頭に @ が付きます。現在 Logs Insights では、@message (CloudWatch への送信時に解析していない未加工のログイベントを含む)、@logStream (ログイベントを生成したソース名を含む)、@timestamp (ログイベントが CloudWatch に追加された日時を含む) の 3 種のシステムフィールドを生成します。

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

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

CloudWatch Logs は、すでに他の AWS サービス (Amazon Kinesis、Amazon Kinesis Data Firehose、Amazon Elasticsearch など) および AWS パートナー ISV ソリューション (Splunk、Sumo Logic、DataDog など) との統合オプションをサポートしているため、さまざまな環境におけるログのカスタム処理、補強、分析、可視化のニーズに合わせて柔軟に対応することができます。さらに、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 異常検出は、潜在的な問題を事前に明らかにすることで、問題を未然に防止し、信頼できるパフォーマンスを実現するのに役立ちます。
 

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

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

Amazon DevOps Guru には、Lambda などの特定のアプリケーションソース向けに設計された異常検出機能が備わっています。Amazon CloudWatch ログ異常検知は、どのアプリケーションログでも機能するソリューションです。CloudWatch Logs 異常検出は 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 機能を提供するだけではなく、AWS サービス (Amazon Virtual Private Cloud、Amazon Route53、AWS Lambda、Amazon Elastic Kubernetes Service、Amazon Elastic Container Service など) のログに関する詳細なインサイトの取得にも役立ちます。 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 コンソールで [ダッシュボード] を選択します。[ダッシュボードの作成] ボタンをクリックします。 [オプション]、[ダッシュボードに追加] の順にクリックして、自動ダッシュボードから必要なビューをコピーすることもできます。

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

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

はい。ダッシュボードは、該当するダッシュボードのアカウントの適切なアクセス権限を持つすべてのユーザーが使用できます。