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