

# REL 6 ワークロードリソースをモニタリングするにはどうすればよいですか?
<a name="w2aac19b9b9b5"></a>

ログとメトリクスは、ワークロードの状態についての洞察を得るための強力なツールです。ワークロードは、しきい値を超えたり重大なイベントが発生したりしたときに、ログとメトリクスがモニタリングされて通知が送信されるように構成できます。モニタリングにより、ワークロードは、低パフォーマンスのしきい値を超えたときや障害が発生したときにそれを認識できるため、それに応じて自動的に復旧できます。

**Topics**
+ [REL06-BP01 ワークロードのすべてのコンポーネントをモニタリングする (生成)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 メトリクスを定義および計算する (集計)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 通知を送信する (リアルタイム処理とアラーム)](rel_monitor_aws_resources_notification_monitor.md)
+ [REL06-BP04 レスポンスを自動化する (リアルタイム処理とアラーム)](rel_monitor_aws_resources_automate_response_monitor.md)
+ [REL06-BP05 分析](rel_monitor_aws_resources_storage_analytics.md)
+ [REL06-BP06 定期的にレビューを実施する](rel_monitor_aws_resources_review_monitoring.md)
+ [REL06-BP07 システムを通じたリクエストのエンドツーエンドのトレースをモニタリングする](rel_monitor_aws_resources_end_to_end.md)

# REL06-BP01 ワークロードのすべてのコンポーネントをモニタリングする (生成)
<a name="rel_monitor_aws_resources_monitor_resources"></a>

 ワークロードのコンポーネントは、Amazon CloudWatch またはサードパーティー製ツールを使用してモニタリングします。AWS サービスを AWS Health ダッシュボードでモニタリングします。 

 フロントエンド、ビジネスロジック、ストレージ層など、ワークロードのすべてのコンポーネントをモニタリングする必要があります。主要なメトリクスと、必要に応じてそれをログから抽出する方法を定義し、対応するアラームイベントを起動させるためのしきい値を設定します。メトリクスがワークロードの重要業績評価指標 (KPI) に関連していることを確認し、メトリクスとログを使用して、サービス低下の早期警告サインを識別します。例えば、1 分間に正常に処理されたオーダー数など、ビジネス成果に関するメトリクスは、CPU 使用率などの技術的メトリクスより早く、ワークロード問題を示すことができます。AWS Health ダッシュボードは、AWS リソースの基盤となる AWS のサービスのパフォーマンスと可用性をパーソナライズして表示するために使用します。 

 クラウドでのモニタリングは新しい機会をもたらします。ほとんどのクラウドプロバイダーは、カスタマイズ可能なフックを開発して、ワークロードの複数のレイヤーをモニタリングする際に役立つインサイトを提供しています。Amazon CloudWatch などの AWS サービスは、統計的な機械学習アルゴリズムを応用して、システムとアプリケーションのメトリクスを継続的に分析し、正常なベースラインを決定し、最小限のユーザー介入で異常を表面化します。異常検出アルゴリズムでは、メトリクスの季節変動とトレンドの変化が考慮されます。 

 AWS では、豊富なモニタリングおよびログ情報を公開しており、これらを使用して、ワークロード固有のメトリクスと需要変化プロセスを定義し、機械学習の知識に関わらず、機械学習技法を適応させることができます。 

 さらに、すべての外部エンドポイントをモニタリングし、それらがベースとなる実装から独立していることを確認します。このアクティブモニタリングは、合成トランザクション ( *ユーザーカナリア*と呼ばれることもありますが、canary デプロイと混同しないでください) で行うことができます。これは、ワークロードのクライアントによって実行されるアクションに相当する多数の一般的タスクを定期的に実行するというものです。これらのタスクは、短期間に保ち、テスト中にワークロードに負荷をかけすぎないようにしてください。Amazon CloudWatch Synthetics を使用すると、 [Synthetics Canary を作成して、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) エンドポイントと API をモニタリングできます。合成 Canary クライアントノードと AWS X-Ray コンソールを組み合わせて、選択した期間中にエラー、障害、スロットリング率で問題が発生している合成 Canary を特定することもできます。 

 **期待される成果:** 

 ワークロードのすべてのコンポーネントから重要なメトリクスを収集して使用し、ワークロードの信頼性と最適なユーザーエクスペリエンスを確保します。ワークロードがビジネス成果を達成していないことを検出した場合は、障害を迅速に宣言して、インシデントから復旧できます。 

 **一般的なアンチパターン:** 
+  ワークロードへの外部インターフェイスのみをモニタリングする。 
+  ワークロード固有のメトリクスを生成せず、ワークロードが使用している AWS から提供されるメトリクスにのみ依存する。 
+  ワークロードの技術的メトリクスを使用するだけで、ワークロードが貢献する非技術的な KPI に関するメトリクスをモニタリングしない。 
+  本番トラフィックとシンプルなヘルスチェックに依存して、ワークロード状態をモニタリングし、評価する。 

 **このベストプラクティスを確立するメリット:** ワークロードのすべての階層でモニタリングすることで、ワークロードを構成するコンポーネントの問題をより迅速に予測し、解決できます。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>

1.  **可能な限りログを有効にします。** ワークロードのすべてのコンポーネントからモニタリングデータを取得する必要があります。S3 Access Logs など、追加のロギングをオンにして、ワークロードがワークロード固有のデータをログに記録できるようにします。Amazon ECS、Amazon EKS、Amazon EC2、Elastic Load Balancing、AWS Auto Scaling、Amazon EMR などのサービスから、CPU、ネットワーク I/O、およびディスク I/O の平均に関するメトリクスを収集します。把握 [CloudWatch メトリクスを発行する AWS のサービス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) で、CloudWatch にメトリクスを発行する AWS のサービスのリストを確認できます。 

1.  **デフォルトのメトリクスをすべてレビューし、データ収集にギャップがないか確認します。** すべてのサービスはデフォルトのメトリクスを生成します。デフォルトのメトリクスを収集することで、ワークロードのコンポーネント間の依存関係と、コンポーネントの信頼性とパフォーマンスがワークロードに及ぼす影響をより深く理解できます。また、独自のメトリクスを [作成して、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) AWS CLI または API を使用して CloudWatch に発行することもできます。 \$1\$1\$1 please leave this segment blank since the source does not make any sense in context \$1\$1\$1 

1.  **すべてのメトリクスを評価して、ワークロード内の各 AWS サービスに対してどのメトリクスでアラートを出すかを決定します。** ワークロードの信頼性に大きな影響を持つメトリクスのサブセットを選択することもできます。重要なメトリクスとしきい値に焦点を当てることで、 [アラート](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) の数を絞り込み、偽陽性を最小化できます。 

1.  **アラートを定義し、アラートが起動された後のワークロードの復旧プロセスを定義します。** アラートを定義することで、通知とエスカレーションを迅速に行い、インシデントからの復旧に必要なステップに従い、所定の目標復旧時間 (RTO) を満たすことができます。専用のインフラストラクチャで [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) を使用すると、定義されたしきい値に基づいて自動ワークフローを起動し、回復手順を開始することができます。 

1.  **合成トランザクションを使用して、ワークロードの状態に関する関連データを収集することを検討しましょう。** 合成モニタリングは、顧客と同じルートに従って同じアクションを実行するため、ワークロードに顧客のトラフィックがない場合でも、継続的にカスタマーエクスペリエンスを検証することが可能になります。また、 [合成トランザクション](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)を使用することで、顧客より先に問題を発見できます。 

## リソース
<a name="resources"></a>

 **関連するベストプラクティス:** 
+ [REL11-BP03 すべてのレイヤーの修復を自動化する](rel_withstand_component_failures_auto_healing_system.md)

 **関連するドキュメント:** 
+  [Getting started with your AWS Health Dashboard – Your account health (AWS Health ダッシュボードの使用開始 - アカウントのヘルス)](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html) 
+  [CloudWatch メトリクスを発行する AWS のサービス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 
+  [Network Load Balancer のアクセスログ](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html) 
+  [Application Load Balancer のアクセスログ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html) 
+  [Accessing Amazon CloudWatch Logs for AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html) 
+  [Amazon S3 サーバーアクセスのログ記録](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html) 
+  [Classic Load Balancer のアクセスログの有効化](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html) 
+  [Amazon S3 へのログデータのエクスポート](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 
+  [CloudWatch エージェントを Amazon EC2 インスタンスにインストールする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html) 
+  [カスタムメトリクスの発行](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
+  [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  [Using Amazon CloudWatch Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 
+  [Canary の使用 (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
+  [Amazon CloudWatch Logs とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) 

   **ユーザーガイド:** 
+  [追跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) 
+  [Amazon EC2 Linux インスタンスのメモリとディスクのメトリクスのモニタリング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html) 
+  [コンテナインスタンスでの CloudWatch Logs の使用](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html) 
+  [VPC フローログ](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html) 
+  [Amazon DevOps Guru とは](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) 
+  [「AWS X-Ray とは何ですか。」](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 

 **関連ブログ:** 
+  [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 

 **関連する例とワークショップ:** 
+  [AWS Well-Architected ラボ: 運用上の優秀性 - 依存関係のモニタリング](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/) 
+  [The Amazon Builders' Library: 分散システムを装備して、運用の可視性を高める](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+  [Observability workshop (可観測性ワークショップ)](https://catalog.workshops.aws/observability/en-US) 

# REL06-BP02 メトリクスを定義および計算する (集計)
<a name="rel_monitor_aws_resources_notification_aggregation"></a>

 ログデータを保存し、必要に応じてフィルターを適用します。これにより、特定のログイベントのカウントや、ログイベントのタイムスタンプから計算されたレイテンシーなどのメトリクスを計算できます。 

 Amazon CloudWatch と Amazon S3 は、主要な集約レイヤーおよびストレージレイヤーとして機能します。AWS Auto Scaling や Elastic Load Balancing などの一部のサービスでは、クラスターまたはインスタンス全体の CPU 負荷または平均的なリクエストのレイテンシーについて、デフォルトのメトリクスが提供されます。VPC フローログや AWS CloudTrail などのストリーミングサービスの場合、イベントデータは CloudWatch Logs に転送されるため、メトリクスフィルターを定義して適用し、イベントデータからメトリクスを抽出する必要があります。これにより、時系列データが提供されます。これは、アラートをトリガーするために定義した CloudWatch アラームへの入力データとして機能します。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  メトリクスを定義および計算します (集計)。特定のログイベントのカウントや、ログイベントのタイムスタンプから計算されたレイテンシーなどのメトリクスを計算するため、ログデータを保存し、必要に応じてフィルターを適用する 
  +  メトリクスフィルターは、CloudWatch Logs に送信されるログデータから検索する条件とパターンを定義します。CloudWatch Logs は、これらのメトリクスフィルターを使用して、ログデータを数値の CloudWatch メトリクスに変換し、グラフ化やアラームの設定を可能にします。
    +  [ログデータの検索およびフィルタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) 
  +  信頼できるサードパーティーを使用してログを集計します。
    +  サードパーティーの指示に従います。ほとんどのサードパーティー製品は、CloudWatch および Amazon S3 と統合されています。
  +  一部の AWS のサービスでは、ログを直接 Amazon S3 に発行できます。ログを Amazon S3 に保存することが主な要件であれば、追加のインフラを設定することなく、ログを生成するサービスに直接 Amazon S3 に送信させることが簡単にできます。
    +  [Sending Logs Directly to Amazon S3 (Amazon S3 へのログの直接送信)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) 
+  [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 
+  [1 つの可観測性ワークショップ](https://observability.workshop.aws/) 
+  [ログデータの検索およびフィルタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) 
+  [Sending Logs Directly to Amazon S3 (Amazon S3 へのログの直接送信)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) 
+  [The Amazon Builders' Library: 分散システムを装備して、運用の可視性を高める](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 

# REL06-BP03 通知を送信する (リアルタイム処理とアラーム)
<a name="rel_monitor_aws_resources_notification_monitor"></a>

 重要なイベントが発生すると、把握する必要のある組織に通知が送信されます。 

 Amazon Simple Notification Service (Amazon SNS) トピックにアラートを送信し、任意の数の登録者にプッシュすることができます。例えば Amazon SNS では、E メールエイリアスにアラートを転送して、技術スタッフが対応できるようにしています。 

 **一般的なアンチパターン:** 
+  低すぎるしきい値でアラームを設定することで、多すぎる通知が送信される。 
+  今後の調査のためにアラームをアーカイブしない。 

 **このベストプラクティスを確立するメリット:** イベントの通知 (対応し、自動的に解決できるものであっても) により、イベントの記録を保持し、将来的に別の方法で対処できる場合があります。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  リアルタイムの処理とアラームを実行します。重要なイベントが発生すると、把握しておく必要のある組織が通知を受信します 
  +  Amazon CloudWatch ダッシュボードは、CloudWatch コンソール内のカスタマイズ可能なホームページであり、これを使用すると、異なるリージョンにまたがっているリソースであっても、単一のビューでリソースをモニタリングできます。
    +  [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
  +  メトリクスが制限を超える場合にアラームを作成します。
    +  [Amazon CloudWatch アラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [1 つの可観測性ワークショップ](https://observability.workshop.aws/) 
+  [The Amazon Builders' Library: 分散システムを装備して、運用の可視性を高める](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+  [Amazon CloudWatch アラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  [Using Amazon CloudWatch Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 

# REL06-BP04 レスポンスを自動化する (リアルタイム処理とアラーム)
<a name="rel_monitor_aws_resources_automate_response_monitor"></a>

 自動化を使用して、イベントが検出されたときにアクションを実行します (例えば、障害が発生したコンポーネントを交換します)。 

 アラートは、クラスターが需要の変化に対応できるように、AWS Auto Scaling イベントをトリガーします。アラートは、サードパーティチケットシステムの統合ポイントとして機能する Amazon Simple Queue Service (Amazon SQS) に送信できます。AWS Lambda は、アラートをサブスクライブして、変更に対して動的に対応する非同期サーバーレスモデルをユーザーに提供することもできます。AWS Config は AWS リソースの構成を継続的にモニタリングして記録し、 [AWS Systems Manager Automation をトリガーして](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 問題を修復できます。 

 Amazon DevOps Guru は、異常な動作についてアプリケーションリソースを自動的にモニタリングし、的を絞ったレコメンデーションを提供することにより、問題の識別を速めて修復時間を短縮します。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  Amazon DevOps Guru を使用して、自動化アクションを実行します。Amazon DevOps Guru は、異常な動作についてアプリケーションリソースを自動的にモニタリングし、的を絞ったレコメンデーションを提供することにより、問題の識別を速めて修復時間を短縮します。
  +  [「Amazon DevOps Guru とは何ですか?」](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) 
+  AWS Systems Manager を使用して、自動化アクションを実行します。AWS Config は AWS リソースの設定を継続的にモニタリングおよび記録し、AWS Systems Manager Automation をトリガーして問題を修復できます。 
  +  [AWS Systems Manager Automation をトリガーして](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
    +  Systems Manager Automation ドキュメントを作成して使用します。これらは、オートメーションプロセスの実行時に Systems Manager がマネージドインスタンスおよび他の AWS リソースに対して実行するアクションを定義します。
    +  [オートメーションドキュメント (プレイブック) の使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) 
+  Amazon CloudWatch は、状態変更イベントを Amazon EventBridge に警告します。EventBridge ルールを作成して、レスポンスを自動化します。 
  +  [AWS リソースからのイベントでトリガーする EventBridge ルールの作成](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html) 
+  応答を自動化する計画を作成して実行します。 
  +  すべてのアラート応答手順をインベントリします。タスクをランク付けする前に、アラートレスポンスを計画する必要があります。
  +  実行する必要がある特定のアクションを含むすべてのタスクをインベントリします。これらのアクションのほとんどは、ランブックに記載されています。また、予期しないイベントのアラートに対するプレイブックも必要です。
  +  すべての自動化可能なアクションについて、ランブックとプレイブックを調べます。一般に、アクションを定義できる場合は、ほとんどの場合、自動化できます。
  +  エラーが発生しやすいアクティビティや時間のかかるアクティビティを上位にランク付けます。エラーの原因を取り除き、解決までの時間を短縮することが最も有益です。
  +  オートメーションを完了する計画を立てます。自動化と、自動化を更新するためのアクティブな計画を維持します。
  +  オートメーションの機会に関する手動要件を調べます。手動プロセスの自動化機会に挑戦します。

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Systems Manager Automation をトリガーして](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  [AWS リソースからのイベントでトリガーする EventBridge ルールの作成](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html) 
+  [1 つの可観測性ワークショップ](https://observability.workshop.aws/) 
+  [The Amazon Builders' Library: 分散システムを装備して、運用の可視性を高める](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+  [「Amazon DevOps Guru とは何ですか?」](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) 
+  [オートメーションドキュメント (プレイブック) の使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) 

# REL06-BP05 分析
<a name="rel_monitor_aws_resources_storage_analytics"></a>

 ログファイルとメトリクスの履歴を収集し、これらを分析して、幅広いトレンドとワークロードの洞察が得られます。 

 Amazon CloudWatch Logs Insights は、 [シンプルかつ強力なクエリ言語をサポートし、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) ログデータの分析に使用できます。Amazon CloudWatch Logs ではさらに、シームレスにデータを Amazon S3 に送ってデータを使用したり、または Amazon Athena に送ってデータをクエリしたりできるサブスクリプションもサポートしています。豊富な種類のフォーマットのクエリがサポートされています。把握 [サポートされる SerDes とデータ形式](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html) 詳細については、Amazon Athena ユーザーガイドを参照してください。巨大なログファイルセットの分析では、Amazon EMR クラスターを実行してペタバイト規模の分析を実行できます。 

 集計、処理、保存、分析を実行できる多数のツールが AWS パートナーやサードパーティによって提供されています。このようなツールには、New Relic、Splunk、Loggly、Logstash、CloudHealth、Nagios などがあります。ただし、システムやアプリケーションログの外で行うデータ生成は各クラウドプロバイダーに固有であり、また多くの場合サービスごとに固有です。 

 モニタリングプロセスで見落とされがちな点は、データ管理です。モニタリングのためのデータ保存要件を決定し、それに応じたライフサイクルポリシーを適用する必要があります。Amazon S3 はS3 バケットレベルのライフサイクル管理をサポートしています。このライフサイクル管理には、バケット内のパスごとに異なる管理方法を適用できます。ライフサイクルの最終段階では、データを Amazon Glacier に移行して長期保存し、保存期間の終了後には期限切れにすることができます。S3 Intelligent-Tiering ストレージクラスは、パフォーマンスへの影響や運用のオーバーヘッドなしに、データを最も費用対効果の高いアクセス階層に自動的に移動することにより、コストを最適化できるように設計されています。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  CloudWatch Logs Insights を使用すると、Amazon CloudWatch Logs でログデータをインタラクティブに検索して分析できます。 
  +  [CloudWatch Logs Insights を使用したログデータの分析](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html) 
  +  [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 
+  使用できる場合は、Amazon CloudWatch Logs を使用してログを Amazon S3 に送信するか、Amazon Athena を使用してデータをクエリします。 
  +  [Athena を使用して Amazon S3 サーバーのアクセスログを分析するにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/) 
    +  サーバーアクセスログバケットの S3 ライフサイクルポリシーを作成します。ライフサイクルポリシーを設定して、定期的にログファイルを削除します。そうすることで、Athena が各クエリについて分析するデータ量が削減されます。
      +  [S3 バケットのライフサイクルポリシーを作成する方法](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) 
+  [CloudWatch Logs Insights を使用したログデータの分析](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html) 
+  [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 
+  [S3 バケットのライフサイクルポリシーを作成する方法](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html) 
+  [Athena を使用して Amazon S3 サーバーのアクセスログを分析するにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/) 
+  [1 つの可観測性ワークショップ](https://observability.workshop.aws/) 
+  [The Amazon Builders' Library: 分散システムを装備して、運用の可視性を高める](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 

# REL06-BP06 定期的にレビューを実施する
<a name="rel_monitor_aws_resources_review_monitoring"></a>

 ワークロードモニタリングがどのように実装されているかを頻繁に確認し、重要なイベントや変更に基づいて更新します。 

 効果的なモニタリングは、主要なビジネスメトリクスが原動力になります。ビジネスの優先順位が変化したときに、メトリクスがワークロードに確実に対応できるようにします。 

 モニタリングを監査することで、アプリケーションがどのタイミングで可用性の目標を満たしているかを確実に把握できます。根本原因の分析には、障害発生時に何が起こったかを発見する機能が必要です。AWS は、インシデント時にサービスの状態を追跡できるサービスを提供しています。 
+  **Amazon CloudWatch Logs:** このサービスにログを保存してその内容を調査できます。 
+  **Amazon CloudWatch Logs Insights**: 数秒で大量のログを分析できるフルマネージドサービスです。高速でインタラクティブなクエリと視覚化が行えます。  
+  **AWS Config:** さまざまな時点でどの AWS インフラストラクチャが使用されているかを確認できます。 
+  **AWS CloudTrail:** どの AWS API が、いつどのプリンシパルに呼び出されたかを確認できます。 

 AWS では、週に一度のミーティングを実施して、 [運用パフォーマンスをレビューし、](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 学んだ教訓をチーム間で共有しています。AWS には多数のチームが存在するため、 [私たちは The Wheel を作成し、](https://aws.amazon.com/blogs/opensource/the-wheel/) ワークロードをランダムに選んで確認できるようにしました。運用パフォーマンスのレビューと知識の共有を定期的に行うことで、運用チームのパフォーマンスを向上させることができます。 

 **一般的なアンチパターン:** 
+  デフォルトのメトリクスのみを収集する。 
+  モニタリング戦略を設定し、見直さない。 
+  主要な変更がデプロイされる際に、モニタリングについて話し合わない。 

 **このベストプラクティスを活用するメリット:** モニタリングを定期的にレビューすることで、予期される問題が実際に発生したときに通知に反応する代わりに、潜在的な問題を予測できるようになります。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  ワークロード用に複数のダッシュボードを作成します。主要なビジネスメトリクスと、使用状況の変化に応じて予測されるワークロードの状態に最も関連性があるものとして特定した技術メトリクスを含む最上位のダッシュボードが必要です。また、検査が可能なさまざまなアプリケーション層や依存関係のダッシュボードも必要があります。 
  +  [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  ワークロードダッシュボードの定期的なレビューをスケジュールし、実施します。ダッシュボードの定期的な検査を行います。検査する深度に応じて異なる頻度にすることができます。 
  +  メトリクスの傾向を検査します。メトリクス値と履歴値を比較して、調査が必要なものを示唆している可能性がある傾向があるかどうかを確認します。これには、レイテンシーの増加、主要なビジネス機能の減少、失敗レスポンスの増加などがあります。
  +  メトリクスの外れ値/異常を検査します。平均値または中央値は、外れ値と異常値を覆い隠すことがあります。期間中の最大値と最低値を調べ、極端なスコアの原因を調査します。これらの原因の排除を続行しながら、極値の定義を低くしていくことで、ワークロードパフォーマンスの一貫性を継続して向上させることができます。
  +  行動の急変を探します。メトリクスの数量または方向性の突然の変化は、アプリケーションに変更があったこと、または追跡するためにさらなるメトリクスを追加する必要がある外部要因があることを示唆している可能性があります。

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) 
+  [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 
+  [1 つの可観測性ワークショップ](https://observability.workshop.aws/) 
+  [The Amazon Builders' Library: 分散システムを装備して、運用の可視性を高める](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+  [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 

# REL06-BP07 システムを通じたリクエストのエンドツーエンドのトレースをモニタリングする
<a name="rel_monitor_aws_resources_end_to_end"></a>

 AWS X-Ray またはサードパーティ製のツールを使用することで、デベロッパーは分散システムの分析とデバッグをより簡単に行い、アプリケーションとその基盤となるサービスのパフォーマンスを把握できます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  システムを通じたリクエストのエンドツーエンドのトレースをモニタリングします。AWS X-Ray は、アプリケーションが処理するリクエストに関するデータを収集するサービスであり、データの表示、フィルタリング、インサイトの取得によって、問題や最適化の機会を特定するためのツールを提供します。アプリケーションへのトレースされたリクエストについて、リクエストとレスポンスだけでなく、アプリケーションがダウンストリーム AWS リソース、マイクロサービス、データベース、ウェブ API に対して行う呼び出しに関する詳細情報も確認できます。 
  +  [「AWS X-Ray とは何ですか。」](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 
  +  [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 
+  [1 つの可観測性ワークショップ](https://observability.workshop.aws/) 
+  [The Amazon Builders' Library: 分散システムを装備して、運用の可視性を高める](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+  [模擬モニタリングの使用 (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
+  [「AWS X-Ray とは何ですか。」](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 