

# REL06-BP06 モニタリングの範囲とメトリクスを定期的に確認する
<a name="rel_monitor_aws_resources_review_monitoring"></a>

 ワークロードモニタリングの実装方法を頻繁に確認し、ワークロードとそのアーキテクチャの進化に合わせて更新します。モニタリングの定期的な監査は、障害インジケータの見逃しや見落としのリスクを低減し、ワークロードが可用性の目標を達成するのに役立ちます。

 効果的なモニタリングは主要なビジネスメトリクスに根ざしており、ビジネスの優先順位が変化するにつれて進化します。監視レビュープロセスでは、サービスレベルインジケーター (SLI) を重視し、インフラストラクチャ、アプリケーション、クライアント、ユーザーからのインサイトを取り入れる必要があります。

 **期待される成果:** 効果的なモニタリング戦略があり、重要なイベントや変更の後だけでなく、定期的にレビューおよび更新されます。ワークロードとビジネス要件が進化しても、主要なアプリケーションヘルスインジケータが依然として適切であることを確認します。

 **一般的なアンチパターン:** 
+  デフォルトのメトリクスのみを収集している。
+  モニタリング戦略は設定するが、確認することはない。
+  主要な変更がデプロイされる際に、モニタリングについて話し合わない。
+  古いメトリクスを信頼して、ワークロードの状態を判断している。
+  運用チームは、古いメトリクスとしきい値が原因で誤検出アラートの対処に追われている。
+  モニタリングされていないアプリケーションコンポーネントのオブザーバビリティが不足している。
+  モニタリングでは低レベルの技術メトリクスのみに焦点を当て、ビジネスメトリクスを除外している。

 **このベストプラクティスを活用するメリット:** モニタリングを定期的に確認すると、潜在的な問題を予測し、それらを検出できることを確認できます。また、以前のレビューで見逃した可能性のある死角を発見できるため、問題を検出する能力がさらに向上します。

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

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

 [運用準備状況レビュー (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) プロセス中にモニタリングメトリクスと範囲を確認します。一貫したスケジュールで定期的な運用準備状況レビューを実行して、現在のワークロードと設定したモニタリングの間にギャップがあるかどうかを評価します。運用パフォーマンスのレビューと知識の共有を定期的に行うことで、運用チームのパフォーマンスを向上させることができます。既存のアラートのしきい値がまだ適切かどうかを検証し、運用チームが誤検出アラートを受信している状況や、モニタリングすべきアプリケーションのモニタリングされていない状況を確認します。

 [耐障害性分析フレームワーク](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html)は、プロセスの進行に役立つガイダンスを提供します。フレームワークの焦点は、潜在的な障害モードと、その影響を軽減するために使用できる予防および修正コントロールを特定することです。この知識は、モニタリングとアラートを行う適切なメトリクスとイベントを特定するのに役立ちます。

### 実装手順
<a name="implementation-steps"></a>

1.  ワークロードダッシュボードの定期的なレビューをスケジュールし、実施します。検査する深度に応じて異なる頻度にすることができます。

1.  メトリクスの傾向を検査します。メトリクス値と履歴値を比較して、調査が必要なものを示唆している可能性がある傾向があるかどうかを確認します。これには、レイテンシーの増加、主要なビジネス機能の減少、失敗レスポンスの増加などがあります。

1.  メトリクスの外れ値や異常を検査します。これは平均または中央値でマスキングできます。時間枠内の最高値と最低値を調べ、通常の境界をはるかに超えている観測結果の原因を調査します。これらの原因を引き続き削除すると、ワークロードパフォーマンスの一貫性の向上に応じて、期待されるメトリクスの境界を絞ることができます。

1.  行動の急変を探します。メトリクスの数量または方向性の突然の変化は、アプリケーションに変更があったこと、または追跡するためにさらなるメトリクスを追加する必要がある外部要因があることを示唆している可能性があります。

1.  現在のモニタリング戦略に、引き続きアプリケーションとの関連性があるかどうかを確認します。以前のインシデントの分析 (または耐障害性分析フレームワーク) に基づいて、モニタリングスコープに組み込む必要があるアプリケーションの追加の側面があるかどうかを評価します。

1.  リアルユーザーモニタリング (RUM) メトリクスを確認して、アプリケーション機能のカバレッジにギャップがないかどうかを確認します。

1.  変更管理プロセスをレビューします。必要に応じて手順を更新し、変更を承認する前に実行する必要があるモニタリング分析ステップを含めます。

1.  運用準備状況の確認とエラープロセスの修正の一環として、モニタリングレビューを実装します。

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

 **関連するベストプラクティス** 
+  [REL06-BP01 ワークロードのすべてのコンポーネントをモニタリングする (生成)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html) 
+  [REL06-BP02 メトリクスを定義および計算する (集計)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_aggregation.html) 
+  [REL06-BP07 システムを通じたリクエストのエンドツーエンドのトレースをモニタリングする](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_end_to_end.html) 
+  [REL12-BP02 インシデント後の分析を実行する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_rca_resiliency.html) 
+  [REL12-BP06 定期的にゲームデーを実施する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_game_days_resiliency.html) 

 **関連ドキュメント:** 
+  [correction of error (COE) を開発すべき理由](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/) 
+  [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  [運用を可視化するためのダッシュボードの構築](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/?did=ba_card&trk=ba_card) 
+  [マルチ AZ の高度なレジリエンスパターン - グレー障害](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) 
+  [Amazon CloudWatch Logs Insights のサンプルクエリ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) 
+  [Amazon CloudWatch Synthetics と AWS X-Ray でのデバッグ](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 
+  [つのオブザーバビリティワークショップ](https://observability.workshop.aws/) 
+  [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) 
+  [AWS Observability Best Practices](https://aws-observability.github.io/observability-best-practices/) 
+  [耐障害性分析フレームワーク](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html) 
+  [耐障害性分析フレームワーク - オブザーバビリティ](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/observability.html) 
+  [運用準備状況レビュー - ORR](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 