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