翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
重要なメトリクスを一度だけ自動分析することで、ワークロードに影響を与える前に問題を検出して解決できます。CloudWatch では、特定の期間に複数の統計情報を使用して、複数のメトリクスを簡単にグラフ化および比較できます。CloudWatch を使用して、必要なディメンション値を持つすべてのメトリクスを検索し、分析に必要なメトリクスを見つけることができます。
ワークロードをモニタリングするためのベースラインとして使用する、メトリクスとディメンションの初期セットを含めることで、メトリクス取得のアプローチを開始することをお勧めします。時間の経過と共に、ワークロードは成熟し、さらに分析とサポートに役立つメトリクスとディメンションを追加できます。アプリケーションまたはワークロードは複数の AWS リソースを使用し、独自のカスタムメトリクスを持つ場合があります。これらのリソースを名前空間にグループ化して、識別を容易にする必要があります。
また、特定の問題を診断するための関連するログやモニタリングデータをすばやく特定できるように、ログとモニタリングデータの相関関係を考慮する必要があります。AWS X-Ray トレースマップを使用して、問題を診断するためのトレース、メトリクス、ログ、アラームを関連付けることができます。また、システムやサービス全体の問題をすばやく検索して特定できるように、メトリクスのディメンションやワークロードのログに識別子を追加することも検討する必要があります。
CloudWatch アラームを使用したモニタリングとアラームの実行
CloudWatch アラーム を使用することで、ワークロードまたはアプリケーションでの手動でのモニタリングを減らすことができます。まず、各ワークロードコンポーネントについて取得しているメトリクスを確認し、各メトリクスの適切なしきい値を決定する必要があります。しきい値に違反した時に通知する必要のあるチームメンバーを特定してください。個々のチームメンバーではなく、ディストリビューショングループを確立してターゲットにする必要があります。
CloudWatch アラームでは、サービス管理ソリューションと統合することで、新しいチケットを自動的に作成し、オペレーションワークフローを実行できます。例えば、 は AWS Service Management Connector for ServiceNow と AWS を提供しAWS Service Management Connector、統合をすばやくセットアップできるようにします。このアプローチは、発生したアラームが認識され、これらの製品ですでに定義されている既存のオペレーションワークフローに整合させるために非常に重要です。
また、同じメトリクスに対して、異なるしきい値と評価期間を持つ複数のアラームを作成することもできます。これにより、エスカレーションプロセスの確立に役立ちます。例えば、顧客の注文を追跡する OrderQueueDepth メトリクスがある場合、平均 1 分間の短時間で低いしきい値を定義し、アプリケーションチームメンバーにメールや Slack で通知することができます。また、同じしきい値で 15 分間以上の同じメトリクスに別のアラームを定義し、それをアプリケーションチームとアプリケーションチームのリードにページ、メール、および通知することもできます。最後に、30 分間以上のハードアベレッジのしきい値に 3 番目のアラームを定義して、上層部に通知し、以前通知されたすべてのチームメンバーに通知することができます。複数のアラームを作成することで、条件ごとに異なるアクションを実行できます。簡単な通知プロセスから始めて、必要に応じて調整および改善することができます。
CloudWatch 異常検出を使用したモニタリングとアラームの実行
特定のメトリクスに適用するしきい値が不明な場合、またはアラームで観測された履歴値に基づいたしきい値を自動的に調整する場合、CloudWatch 異常検出 を使用できます。CloudWatch 異常検出は、例えば、当日配送の注文が締切時間前に増加するなど、アクティビティに定期的で予測可能な変化がある可能性のあるメトリクスに特に有効です。異常検出により、自動調整されるしきい値が有効になり、誤警報を減らすことができます。各メトリクスと統計値に対して異常検出を有効にし、異常値に基づいてアラームを発するように CloudWatch を設定できます。
例えば、CPUUtilization メトリクスと EC2 インスタンスでのAVG 統計の異常検出を可能にできます。異常検出では、最大 14 日間の履歴データを使用して、machine learning (ML) モデルを作成します。異なるしきい値を持つ複数のスタンダードアラームを作成するのと同様に、異なる異常検出帯域を持つ複数のアラームを作成し、アラームエスカレーションプロセスを確立することができます。
このセクションの詳細については、CloudWatch ドキュメント内の 異常検出に基づく CloudWatch アラームの作成 を参照してください。
複数のリージョンとアカウントにまたがるアラーム設定
アプリケーションおよびワークロードの所有者は、複数のリージョンにまたがるワークロードに対してアプリケーションレベルのアラームを作成する必要があります。ワークロードがデプロイされている各アカウントとリージョン内に個別のアラームを作成することをお勧めします。アカウントとリージョンに依存しない AWS CloudFormation StackSets とテンプレートを使用して、必要なアラームでアプリケーションリソースをデプロイすることで、このプロセスを簡素化および自動化できます。 templateYou一般的な Amazon Simple Notification Service (Amazon SNS) トピックをターゲットにするようにアラームアクションを設定できます。つまり、アカウントやリージョンに関係なく、同じ通知または修復アクションが使用されます。
マルチアカウントおよびマルチリージョン環境では、アカウントとリージョンの問題を監視するために、 AWS CloudFormation
StackSets やすべての EC2 インスタンス間の平均 CPUUtilization などの集計メトリクスを使用して、アカウントとリージョンの集約アラームを作成することをお勧めします。
また、キャプチャするスタンダード CloudWatch メトリクスとログ用に設定されたワークロードごとにスタンダードアラームを作成することも検討する必要があります。例えば、各 EC2 インスタンスに対して個別のアラームを作成すると、CPU 使用率メトリクスをモニタリングし、平均 CPU 使用率が日常的に 80% を超えると中央のオペレーションチームに通知することができます。また、日常的に 10% 未満の平均 CPU 使用率をモニタリングするスタンダードアラームを作成することもできます。これらのアラームで、中央オペレーションチームが特定のワークロードオーナーと協力して、必要に応じて EC2 インスタンスのサイズを変更することができます。
EC2 インスタンスタグを使用したアラーム作成の自動化
EC2 インスタンスのアラームのスタンダード設定を作成すると、時間がかかり、一貫性がなく、エラーが発生しやすくなります。amazon-cloudwatch-auto-alarms
