# OPS 8.組織でワークロードのオブザーバビリティを活用するにはどうすればよいでしょうか?
オブザーバビリティを活用して、ワークロードの最適な状態を確保します。関連するメトリクス、ログ、トレースを活用して、ワークロードのパフォーマンスを包括的に把握し、問題に効率的に対処します。
**Topics**
+ [OPS08-BP01 ワークロードメトリクスを分析する](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 ワークロードログを分析する](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 ワークロードのトレースを分析する](ops_workload_observability_analyze_workload_traces.md)
+ [OPS08-BP04 実践的なアラートを作成する](ops_workload_observability_create_alerts.md)
+ [OPS08-BP05 ダッシュボードを作成する](ops_workload_observability_create_dashboards.md)
# OPS08-BP01 ワークロードメトリクスを分析する
アプリケーションテレメトリーを実装したら、収集したメトリクスを定期的に分析します。レイテンシー、リクエスト、エラー、容量 (またはクォータ) はシステムパフォーマンスに関するインサイトを提供するとはいえ、ビジネス成果メトリクスの確認を優先することが不可欠です。これにより、ビジネス目標に沿ったデータ主導の意思決定を確実に行うことができます。
**期待される成果:** ワークロードのパフォーマンスを正確に把握することで、データに基づいた意思決定ができるようになり、ビジネス目標と合致させることができます。
**一般的なアンチパターン:**
+ ビジネス成果への影響を考慮せずに、メトリクスを個別に分析しています。
+ ビジネス上のメトリクスは重視せず、過度に技術メトリクスに頼っています。
+ メトリクスを見直す頻度が低く、リアルタイムの意思決定を行う機会を逃しています。
**このベストプラクティスを活用するメリット:**
+ 技術的なパフォーマンスとビジネス成果の相関関係についてより詳しく把握できます。
+ リアルタイムのデータに基づいて意思決定プロセスが改善されます。
+ ビジネス成果に影響が及ぶ前に、問題を事前に特定して軽減できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中程度
## 実装のガイダンス
Amazon CloudWatch などのツールを活用してメトリクス分析を行います。特に静的なしきい値が明らかでない場合や動作パターンがより異常検出に適している場合、AWS Cost Anomaly Detection や Amazon DevOps Guru などの AWS サービスを異常検出に使用できます。
### 実装手順
1. **分析とレビュー:** ワークロードメトリクスを定期的に見直して解析します。
1. 純粋に技術的なメトリクスよりもビジネス成果メトリクスを優先します。
1. データ内のスパイク、ドロップ、パターンの重要性を理解します。
1. **Amazon CloudWatch の利用:** Amazon CloudWatch を一元化されたビューと詳細な分析に使用します。
1. メトリクスを可視化して時系列で比較できるように CloudWatch ダッシュボードを設定します。
1. [CloudWatch のパーセンタイルを使用すると、](https://aws-observability.github.io/observability-best-practices/guides/operational/business/sla-percentile/) メトリクスの分布を明確に把握できるため、SLA の定義や外れ値を把握できます。
1. 静的なしきい値に依存せずに異常パターンを特定するように [AWS Cost Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) を設定します。
1. [CloudWatch クロスアカウントオブザーバビリティ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html) を実装して、リージョン内の複数のアカウントにわたるアプリケーションのモニタリングとトラブルシューティングを行います。
1. [CloudWatch Metric Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html) を使用して、アカウントやリージョンのメトリクスデータをクエリして分析し、傾向や異常を特定します。
1. [CloudWatch Metric Math](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) を適用すると、メトリクスの変換、集計、または計算を実行して、より深いインサイトが得られます。
1. **Amazon DevOps Guru の採用:** [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) の機械学習を強化した異常検出機能と連携して、サーバーレスアプリケーションの運用上の問題の兆候を早期に特定し、顧客に影響が及ぶ前に修正します。
1. **インサイトに基づく最適化: ** メトリクス分析を基盤に情報に基づいた意思決定を行い、ワークロードを調整して改善します。
**実装計画に必要な工数レベル:** 中程度
## リソース
**関連するベストプラクティス:**
+ [OPS04-BP01 主要業績評価指標を特定する](ops_observability_identify_kpis.md)
+ [OPS04-BP02 アプリケーションテレメトリーを実装する](ops_observability_application_telemetry.md)
**関連するドキュメント:**
+ [ The Wheel ブログ - メトリクスの継続的なレビューの重要性 ](https://aws.amazon.com/blogs/opensource/the-wheel/)
+ [ パーセンタイルは重要 ](https://aws-observability.github.io/observability-best-practices/guides/operational/business/sla-percentile/)
+ [AWS Cost Anomaly Detection の使用 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [ CloudWatch クロスアカウントオブザーバビリティ ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)
+ [ CloudWatch Metrics Insights を使用してメトリクスをクエリする ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html)
**関連動画:**
+ [ Amazon CloudWatch でクロスアカウントオブザーバビリティを有効にする ](https://www.youtube.com/watch?v=lUaDO9dqISc)
+ [ Amazon DevOps Guru の紹介 ](https://www.youtube.com/watch?v=2uA8q-8mTZY)
+ [AWS Cost Anomaly Detection を使用してメトリクスを継続的に分析する ](https://www.youtube.com/watch?v=IpQYBuay5OE)
**関連する例:**
+ [ One Observability ワークショップ ](https://catalog.workshops.aws/observability/en-US/intro)
+ [ Amazon DevOps Guru を使用した AIOps で運用上のインサイトを得る ](https://catalog.us-east-1.prod.workshops.aws/workshops/f92df379-6add-4101-8b4b-38b788e1222b/en-US)
# OPS08-BP02 ワークロードログを分析する
アプリケーションの運用面をより詳細に把握するには、ワークロードログを定期的に分析することが不可欠です。ログデータを効率的にふるい分け、可視化し、解釈することで、アプリケーションのパフォーマンスとセキュリティを継続的に最適化できます。
**期待される成果:** 詳細なログ分析から得られるアプリケーションの動作と運用に関する豊富なインサイトを利用することで、積極的な問題の検出と軽減が実現します。
**一般的なアンチパターン:**
+ 重大な問題が発生するまでログの分析を怠っている。
+ ログ分析に利用できるツールをフルセットで使用していないため、重要なインサイトを見逃してしまう。
+ 自動化やクエリ機能を活用せずに、ログの手動確認のみに依存している。
**このベストプラクティスを活用するメリット:**
+ 運用上のボトルネック、セキュリティ上の脅威、その他の潜在的な問題を事前に特定できます。
+ ログデータを効率的に利用して、アプリケーションを継続的に最適化できます。
+ アプリケーションの動作に関してより詳細に把握できるようになり、デバッグとトラブルシューティングに役立ちます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中程度
## 実装のガイダンス
[Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) はログ分析のための強力なツールです。CloudWatch Logs Insights や Contributor Insights などの統合された機能を使用して、ログから意義ある情報を導き出すプロセスが直感的かつ効率的になります。
### 実装手順
1. **CloudWatch Logs の設定:** ログを CloudWatch Logs に送信するようにアプリケーションとサービスを設定します。
1. **CloudWatch Logs Insights の設定:** [CloudWatch Logs Insights を利用して、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) ログデータをインタラクティブに検索して分析します。
1. クエリを作成してパターンを抽出し、ログデータを可視化して、実践的なインサイトを導き出します。
1. **Contributor Insights の活用** [CloudWatch Contributor Insights を使用して、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) IP アドレスやユーザーエージェントなどの高カーディナリティディメンションでトップのトーカーを特定します。
1. **CloudWatch Logs メトリクススフィルターの実装:** [CloudWatch Logs のメトリクスフィルターを設定して、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) ログデータを実践的なメトリクスに変換します。これにより、アラームを設定したり、パターンをさらに詳細に分析したりできます。
1. **定期的なレビューと改善:** ログ分析戦略を定期的に確認して、すべての関連情報を収集し、アプリケーションのパフォーマンスを継続的に最適化します。
**実装計画に必要な工数レベル:** 中程度
## リソース
**関連するベストプラクティス:**
+ [OPS04-BP01 主要業績評価指標を特定する](ops_observability_identify_kpis.md)
+ [OPS04-BP02 アプリケーションテレメトリーを実装する](ops_observability_application_telemetry.md)
+ [OPS08-BP01 ワークロードメトリクスを分析する](ops_workload_observability_analyze_workload_metrics.md)
**関連するドキュメント:**
+ [ CloudWatch Logs Insights を使用したログデータの分析 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [ CloudWatch Contributor Insights の使用 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html)
+ [ CloudWatch Logs ログのメトリクススフィルターの作成と管理 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
**関連動画:**
+ [ CloudWatch Logsインサイトを使用してログデータを分析する ](https://www.youtube.com/watch?v=2s2xcwm8QrM)
+ [ CloudWatch Contributor Insights を使用して高カーディナリティデータを分析する ](https://www.youtube.com/watch?v=ErWRBLFkjGI)
**関連する例:**
+ [ CloudWatch Logs サンプルクエリ ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [ One Observability ワークショップ ](https://catalog.workshops.aws/observability/en-US/intro)
# OPS08-BP03 ワークロードのトレースを分析する
トレースデータの分析は、アプリケーションの運用過程を包括的に把握するために不可欠です。さまざまなコンポーネント間の相互作用を可視化して把握することで、パフォーマンスを微調整し、ボトルネックを特定し、ユーザーエクスペリエンスを向上させることができます。
**期待される成果:** アプリケーションの分散された運用を明確に可視化することで、より迅速な問題解決とユーザーエクスペリエンスの向上につながります。
**一般的なアンチパターン:**
+ トレースデータを見落とし、ログとメトリクスのみに依存している。
+ トレースデータを関連するログと関連付けられていない。
+ レイテンシーや障害率など、トレースから導き出されたメトリクスを考慮していない。
**このベストプラクティスを活用するメリット:**
+ トラブルシューティングを改善し、平均解決時間 (MTTR) を短縮します。
+ 依存関係とその影響についてのインサイトが得られます。
+ パフォーマンスの問題を迅速に特定して修正できます。
+ トレースから導き出されたメトリクスを活用して、情報に基づいた意思決定を行うことができます。
+ コンポーネントのインタラクションが最適化され、ユーザーエクスペリエンスの向上につながります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中程度
## 実装のガイダンス
[AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) は、トレースデータ分析のための包括的なスイートを提供し、サービスインタラクションの全体像の把握、ユーザーアクティビティのモニタリング、パフォーマンスに関する問題の検出ができます。ServiceLens、X-Ray Insights、X-Ray Analytics、Amazon DevOps Guru などの機能により、トレースデータから導き出される実践的なインサイトが向上します。
### 実装手順
次の手順は、AWS サービスを使用してトレースデータ分析を効果的に実装するための構造化されたアプローチを提供しています。
1. **AWS X-Ray の統合:** トレースデータをキャプチャするために、X-Ray をアプリケーションと統合することが必要です。
1. **X-Ray メトリクスの分析:** サービスマップを使用してアプリケーションのヘルスをモニタリングするために、レイテンシー、リクエスト率、障害率、応答時間の分布などの X-Ray から [取得できるメトリクスを](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-servicemap.html#xray-console-servicemap-view) 詳細に確認します。
1. **ServiceLens の使用:** [ServiceLens マップを活用すると、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/servicelens_service_map.html) サービスやアプリケーションのオブザーバビリティを向上できます。これにより、トレース、メトリクス、ログ、アラーム、その他のヘルス情報を総合的に確認できます。
1. **X-Ray Insights の有効化:**
1. [X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html) のトレース内の自動異常検出を有効にします。
1. インサイトを調べてパターンを特定し、障害率の増加やレイテンシーの増大などについての根本原因を突き止めます。
1. 検出された問題を時系列で分析するには、インサイトタイムラインを参照します。
1. **X-Ray Analytics の使用:** [X-Ray Analytics](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-analytics.html) を使用すると、トレースデータを徹底的に調査してパターンを特定し、インサイトを抽出できます。
1. **X-Ray のグループの使用:** X-Ray でグループを作成して、高レイテンシーなどの条件に基づいてトレースをフィルタリングすると、より的を絞った分析につながります。
1. **Amazon DevOps Guru の統合:** [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) を採用すると、トレース内の運用上の異常を正確に特定する機械学習モデルの利点を活用できます。
1. **CloudWatch Synthetics の使用:** [CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_tracing.html) を使用して、エンドポイントとワークフローを継続的にモニタリングするための Canary を作成します。Canary は X-Ray と統合でき、テスト対象のアプリケーションを詳細に分析するためのトレースデータを提供できます。
1. **リアルユーザーモニタリング (RUM) の使用:** [AWS X-Ray と CloudWatch RUM](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-RUM.html)を使用すると、アプリケーションのエンドユーザーからダウンストリームの AWS マネージドサービスまでのリクエストパスを分析してデバッグできます。これにより、ユーザーに影響を及ぼすレイテンシーの傾向やエラーを特定できます。
1. **ログとの関連付け:** トレースデータ [を](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/servicelens_troubleshooting.html#servicelens_troubleshooting_Nologs) X-Ray トレースビュー内の関連ログと関連付けると、アプリケーションの動作を詳細に把握できます。これにより、トレース対象のトランザクションに直接関連するログイベントを確認できます。
**実装計画に必要な工数レベル:** 中程度
## リソース
**関連するベストプラクティス:**
+ [OPS08-BP01 ワークロードメトリクスを分析する](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 ワークロードログを分析する](ops_workload_observability_analyze_workload_logs.md)
**関連するドキュメント:**
+ [ ServiceLens を使用したアプリケーションのヘルスのモニターリング ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceLens.html)
+ [ X-Ray Analytics を使用したトレースデータの検索 ](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-analytics.html)
+ [ X-Ray Insights を使用したトレースの異常検出 ](https://docs.aws.amazon.com/xray/latest/devguide/xray-insights.html)
+ [ CloudWatch Synthetics を使用した継続的なモニタリング ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
**関連動画:**
+ [ Amazon CloudWatch Synthetics と AWS X-Ray を使用してアプリケーションを分析してデバッグを行う ](https://www.youtube.com/watch?v=s2WvaV2eDO4)
+ [AWS X-Ray Insights を使用する ](https://www.youtube.com/watch?v=tl8OWHl6jxw)
**関連する例:**
+ [ One Observability ワークショップ ](https://catalog.workshops.aws/observability/en-US/intro)
+ [ X-Ray を AWS Lambda と実装する ](https://docs.aws.amazon.com/lambda/latest/dg/services-xray.html)
+ [ CloudWatch Synthetics Canary テンプレート ](https://github.com/aws-samples/cloudwatch-synthetics-canary-terraform)
# OPS08-BP04 実践的なアラートを作成する
アプリケーションの動作の逸脱を迅速に検出して対応することが重要です。特に重要なのは、主要業績評価指標 (KPI) に基づく成果がリスクにさらされている場合や、予期しない異常が発生した場合を認識することです。KPI に基づいてアラートを送信することで、受信される警告が直接的に業務や運用上の影響と関連付けられるようになります。実践的なアラートに関するこのようなアプローチを採用すると、積極的な対応の促進とシステムのパフォーマンスと信頼性の維持につながります。
**期待される成果:** 特に KPI の結果がリスクにさらされている場合に、潜在的な問題を迅速に特定して緩和するために、関連性が高く、実践的なアラートをタイムリーに受信できます。
**一般的なアンチパターン:**
+ 重大ではないアラートを多数設定しすぎて、アラート疲れを引き起こしている。
+ アラートに KPI に基づく優先順位付けを行っていないため、問題が業務に及ぼす影響を把握できにくくなっている。
+ 根本原因への対処を怠っているため、同じ問題について繰り返しアラートが送信される。
**このベストプラクティスを活用するメリット:**
+ 実践的で関連性の高いアラートに重点を置くことで、アラート疲労を軽減します。
+ 問題を事前に検出して軽減することで、システムの稼働時間と信頼性が向上します。
+ 一般的なアラートツールやコミュニケーションツールと統合することで、チームのコラボレーションを強化し、問題を迅速に解決できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
効果的なアラートメカニズムを構築するには、KPI に基づく結果がリスクにさらされている場合や異常が検出された場合にフラグを立てるメトリクス、ログ、トレースデータを使用することが重要です。
### 実装手順
1. **主要業績評価指標 (KPI) を定義します。** アプリケーションの KPI を特定します。正確に業務への影響を反映するには、アラートをこのような KPI に関連付ける必要があります。
1. **異常検出の実装:**
+ **AWS Cost Anomaly Detection の使用:** [AWS Cost Anomaly Detection を](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 異常なパターンを自動的に検出し、正当な異常に対してのみアラートが生成されるように設定します。
+ **X-Ray Insights の使用:**
1. [X-Ray Insights を](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html) トレースデータの異常を検出するように設定します。
1. 問題が検出された場合に [X-Ray Insights にアラートを送信する](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html#xray-console-insight-notifications) ように通知を設定します。
+ **DevOps Guru との統合:**
1. [Amazon DevOps Guru の](https://aws.amazon.com/devops-guru/) 機械学習機能を活用して、既存のデータの運用上の異常を検出します。
1. [https://docs.aws.amazon.com/devops-guru/latest/userguide/update-notifications.html#navigate-to-notification-settings](https://docs.aws.amazon.com/devops-guru/latest/userguide/update-notifications.html#navigate-to-notification-settings) DevOps Guru の通知設定に移動して、異常アラートを設定します。
1. **実践的なアラートの実装:** すぐに行動に移せるように、適切な情報を提供するアラートを設計します。
1. **アラーム疲労の軽減:** 重大ではないアラートは最小限に抑えます。多数の重要でないアラートによりチームに負担がかかると、重大な問題の見落としにつながり、アラートメカニズムの全体的な有効性が低下する場合があります。
1. **複合アラームの設定:** [Amazon CloudWatch の複合アラームを使用して、](https://aws.amazon.com/blogs/mt/improve-monitoring-efficiency-using-amazon-cloudwatch-composite-alarms-2/) 複数のアラームを統合します。
1. **アラートツールとの統合:** [Ops Genie](https://www.atlassian.com/software/opsgenie) や [PagerDuty](https://www.pagerduty.com/)などのツールと統合します。
1. **Amazon Q Developer in chat applications との連携:** [Amazon Q Developer in chat applications](https://aws.amazon.com/chatbot/)と統合して、Chime、Microsoft Teams、Slack にアラートを中継します。
1. **ログに基づくアラート:** [https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) CloudWatch ログのメトリクスフィルターを使用して、特定のログイベントに基づくアラームを作成します。
1. **レビューと反復:** アラート設定を定期的に見直して調整します。
**実装計画に必要な工数レベル:** 中程度
## リソース
**関連するベストプラクティス:**
+ [OPS04-BP01 主要業績評価指標を特定する](ops_observability_identify_kpis.md)
+ [OPS04-BP02 アプリケーションテレメトリーを実装する](ops_observability_application_telemetry.md)
+ [OPS04-BP03 ユーザーエクスペリエンステレメトリーを実装する](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 依存関係のテレメトリーを実装する](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 分散トレースを実装する](ops_observability_dist_trace.md)
+ [OPS08-BP01 ワークロードメトリクスを分析する](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 ワークロードログを分析する](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 ワークロードのトレースを分析する](ops_workload_observability_analyze_workload_traces.md)
**関連するドキュメント:**
+ [ Amazon CloudWatch でのアラームの使用 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [ 複合アラームを作成する ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)
+ [ 異常検出に基づいて CloudWatch アラームを作成する ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html)
+ [ DevOps Guru の通知 ](https://docs.aws.amazon.com/devops-guru/latest/userguide/update-notifications.html)
+ [ X-Ray Insights の通知 ](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html#xray-console-insight-notifications)
+ [ インタラクティブな ChatOps による AWS リソースのモニタリング、運用、トラブルシューティング ](https://aws.amazon.com/chatbot/)
+ [ Amazon CloudWatch 統合ガイド \$1 PagerDuty ](https://support.pagerduty.com/docs/amazon-cloudwatch-integration-guide)
+ [ OpsGenie を Amazon CloudWatch と統合する ](https://support.atlassian.com/opsgenie/docs/integrate-opsgenie-with-amazon-cloudwatch/)
**関連動画:**
+ [ Amazon CloudWatch で複合アラームを作成する ](https://www.youtube.com/watch?v=0LMQ-Mu-ZCY)
+ [ Amazon Q Developer in chat applications の概要 ](https://www.youtube.com/watch?v=0jUSEfHbTYk)
+ [AWS on Air ft.Amazon Q Developer in chat applications の変異型コマンド ](https://www.youtube.com/watch?v=u2pkw2vxrtk)
**関連する例:**
+ [ Amazon CloudWatch を使用したクラウドでのアラーム、インシデント管理、修復 ](https://aws.amazon.com/blogs/mt/alarms-incident-management-and-remediation-in-the-cloud-with-amazon-cloudwatch/)
+ [ チュートリアル: Amazon Q Developer in chat applications に通知を送信する Amazon EventBridge ルールの作成 ](https://docs.aws.amazon.com/chatbot/latest/adminguide/create-eventbridge-rule.html)
+ [ One Observability ワークショップ ](https://catalog.workshops.aws/observability/en-US/intro)
# OPS08-BP05 ダッシュボードを作成する
ダッシュボードは、ワークロードのテレメトリーデータを理解しやすいように表示します。ダッシュボードは重要な視覚的インターフェイスを提供するとはいえ、アラートメカニズムに取って代わるものではなく、補完となるべきものです。考慮して作成することにより、システムのヘルスとパフォーマンスに関する迅速なインサイトが得られるのみでなく、ビジネス成果や問題の影響に関するリアルタイムの情報を関係者に提供できます。
**期待される成果:** 視覚的な表示を使用して、システムとビジネスのヘルスに関する明確かつ実践的なインサイトが得られます。
**一般的なアンチパターン:**
+ メトリクスが多すぎてダッシュボードが必要以上に複雑化する。
+ 以上を検出するアラートを設定せずにダッシュボードに依存している。
+ ワークロードが進化してもダッシュボードが更新されない。
**このベストプラクティスを活用するメリット:**
+ 重要なシステムメトリクスと KPI を即座に可視化します。
+ 関係者のコミュニケーションと理解が強化されます。
+ 運用上の問題の影響についてのインサイトを迅速に把握できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中程度
## 実装のガイダンス
**ビジネス視点のダッシュボード**
ビジネス KPI に応じてカスタマイズしたダッシュボードは、幅広い関係者のエンゲージメントを向上します。関係者はシステムメトリクスに関心を持つとは限りませんが、このような数値のビジネスへの影響を把握することには熱心です。ビジネス視点のダッシュボードにより、モニタリングおよび分析されるすべての技術的および運用上のメトリクスが、包括的なビジネス目標に沿っていることを確認できます。このような調整により、透明性が実現し、重要な事項とそうでない事項について、組織全体のコンセンサスが得られます。さらに、ビジネス KPI を強調表示するダッシュボードは、より実践的となる傾向があります。関係者は、業務の状態、注意が必要な領域、ビジネス成果への潜在的な影響を迅速に把握できます。
これらの点を考慮に入れて、ダッシュボード作成の際は、技術的なメトリクスとビジネス KPI のバランスが取れていることを確認します。どちらも不可欠であるとはいえ、対象者は異なります。理想的には、システムのヘルスとパフォーマンスを包括的に把握すると同時に、主要なビジネス成果とその影響を強調表示するダッシュボードが求められます。
Amazon CloudWatch ダッシュボードは、CloudWatch コンソール内のカスタマイズ可能なホームページであり、さまざまな AWS リージョン リージョンにまたがるリソースであっても、単一のビューでリソースのモニタリングができます。
### 実装手順
1. **基本的なダッシュボードの作成:** [CloudWatch で新しいダッシュボードを作成して](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_dashboard.html)、識別しやすい名前を付けます。
1. **Markdown ウィジェットの使用:** メトリクスの詳細に取り掛かる前に、 [Markdown ウィジェットを使用して、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_remove_text_dashboard.html) ダッシュボードの上部にテキストのコンテキストを追加します。これにより、ダッシュボードの内容、表示されるメトリクスの重要性を説明できます。説明には、その他のダッシュボードやトラブルシューティングツールへのリンクも記載できます。
1. **ダッシュボード変数の作成:** [必要に応じてダッシュボード変数を組み込み、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_dashboard_variables.html) 動的で柔軟なダッシュボードビューを提供します。
1. **メトリクスウィジェットの作成:** [メトリクスウィジェットを追加して、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-and-work-with-widgets.html) アプリケーションが出力するさまざまなメトリクスを可視化し、ウィジェットを調整してシステムのヘルスとビジネス成果を効果的に表示します。
1. **ログのインサイトのクエリ:** [CloudWatch Logs Insights を利用して、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_ExportQueryResults.html) ログから実践的なメトリクスを導き出し、そのインサイトをダッシュボードに表示します。
1. **アラームの設定:** [CloudWatch アラームを](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_remove_alarm_dashboard.html) ダッシュボードに統合して、しきい値を超えているメトリクスを簡単に確認できるビューを提供します。
1. **Contributor Insights の使用:** [CloudWatch Contributor Insights を組み込んで、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights-ViewReports.html) 高カーディナリティフィールドを分析し、リソースの最大の原因をより明確に把握します。
1. **カスタムウィジェットの設計:** 標準のウィジェットでは満たされない特定のニーズについて、カスタムウィジェットの作成を [検討します](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_custom_widget_dashboard.html)。カスタムウィジェットを使用すると、さまざまなデータソースからデータを引き出したり、独自の方法でデータを表示したりできます。
1. **反復と改良:** アプリケーションの進化に応じて、定期的にダッシュボードを見直し、関連性を確認します。
## リソース
**関連するベストプラクティス:**
+ [OPS04-BP01 主要業績評価指標を特定する](ops_observability_identify_kpis.md)
+ [OPS08-BP01 ワークロードメトリクスを分析する](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 ワークロードログを分析する](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 ワークロードのトレースを分析する](ops_workload_observability_analyze_workload_traces.md)
+ [OPS08-BP04 実践的なアラートを作成する](ops_workload_observability_create_alerts.md)
**関連するドキュメント:**
+ [ 運用を可視化するためのダッシュボードの構築 ](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [ Amazon CloudWatch ダッシュボードの使用 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**関連動画:**
+ [ クロスアカウントとクロスリージョンの CloudWatch ダッシュボードを作成する ](https://www.youtube.com/watch?v=eIUZdaqColg)
+ [AWS re:Invent 2021 - AWS クラウド オペレーションダッシュボードを使用してエンタープライズレベルの可視化を実現する ](https://www.youtube.com/watch?v=NfMpYiGwPGo)
**関連する例:**
+ [ One Observability ワークショップ ](https://catalog.workshops.aws/observability/en-US/intro)
+ [ Amazon CloudWatch を使用したアプリケーションモニタリング ](https://aws.amazon.com/solutions/implementations/application-monitoring-with-cloudwatch/)