モニタリングの仕組み - AMS Accelerate ユーザーガイド

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

モニタリングの仕組み

AWS Managed Services (AMS) のモニタリングアーキテクチャについては、次の図を参照してください。

次の図は、AMS Accelerate のモニタリングアーキテクチャを示しています。

AMS モニタリングアーキテクチャ。

リソースが Resource Tagger を使用して定義されたポリシーに基づいてタグ付けされ、アラーム定義がデプロイされた後、次のリストで AMS モニタリングプロセスについて説明します。

  • 生成: アカウントのオンボーディング時に、AMS はマネージドアカウントで作成されたすべてのリソースのベースラインモニタリング (CloudWatch (CW) アラームと CW イベントルールの組み合わせ) を設定します。ベースラインモニタリング設定は、CW アラームがトリガーされたとき、または CW イベントが生成されたときにアラートを生成します。

  • 集約: リソースによって生成されたすべてのアラートは、アカウントの SNS トピックに誘導することで AMS モニタリングシステムに送信されます。AMS が Amazon EC2 アラートをグループ化する方法を設定することもできます。AMS は、同じ EC2 インスタンスに関連するすべてのアラートを 1 つのインシデントにグループ化するか、必要に応じてアラートごとに 1 つのインシデントを作成します。この設定は、Cloud Service Delivery Manager または Cloud Architect を使用していつでも変更できます。

  • 処理: AMS はアラートを分析し、影響の可能性に基づいてアラートを処理します。アラートは次に示すように処理されます。

    • 既知の顧客への影響があるアラート: 新しいインシデントレポートが作成され、AMS はインシデント管理プロセスに従います。

      アラートの例: Amazon EC2 インスタンスはシステムヘルスチェックに失敗し、AMS はインスタンスを停止して再起動することでインスタンスの復旧を試みます。

    • 顧客への影響が不明なアラート: これらのタイプのアラートの場合、AMS はインシデントレポートを送信します。多くの場合、AMS がアクションを実行する前に影響を検証するように求められます。ただし、インフラストラクチャ関連のチェックに合格した場合、AMS はインシデントレポートを送信しません。

      例: Amazon EC2 インスタンスでの 10 分以上の >85% CPU 使用率のアラートは、この動作が使用状況に基づいて予想される可能性があるため、すぐにインシデントとして分類することはできません。この例では、AMS Automation はリソースに対してインフラストラクチャ関連のチェックを実行します。これらのチェックに合格した場合、CPU 使用率が 99% を超えた場合でも、AMS はアラート通知を送信しません。インフラストラクチャ関連のチェックがリソースで失敗していることをオートメーションが検出した場合、AMS はアラート通知を送信し、緩和が必要かどうかを確認します。アラート通知については、このセクションで詳しく説明します。AMS は、通知で緩和オプションを提供します。アラートがインシデントであることを確認する通知に返信すると、AMS は新しいインシデントレポートを作成し、AMS インシデント管理プロセスが開始されます。「顧客への影響なし」または 3 日間応答なしの応答を受信するサービス通知は、解決済みとしてマークされ、対応するアラートは解決済みとしてマークされます。

    • 顧客への影響がないアラート: 評価後、AMS がアラートに顧客への影響がないと判断した場合、アラートはクローズされます。

      たとえば、 は置き換えが必要な EC2 インスタンス AWS Health を通知しますが、そのインスタンスはその後終了しています。

EC2 インスタンスグループ化通知

同じ EC2 インスタンスからのアラートを 1 つのインシデントにグループ化するように AMS モニタリングを設定できます。Cloud Service Delivery Manager または Cloud Architect がこれを設定できます。AMS 管理アカウントごとに設定できるパラメータは 4 つあります。

  1. スコープ: アカウント全体またはタグベースのいずれかを選択します。

    • そのアカウントのすべての EC2 インスタンスに適用される設定を指定するには、スコープ = アカウント全体を選択します。

    • 特定のタグを持つそのアカウントの EC2 インスタンスにのみ適用される設定を指定するには、スコープ = タグベースを選択します。

  2. グループ化ルール: クラシックまたはインスタンスを選択します。

    • アカウント内のすべてのリソースに対してインスタンスレベルのグループ化を設定するには、スコープ = アカウント全体、グループ化ルール = インスタンスを選択します。

    • インスタンスレベルのグループ化を使用するようにアカウント内の特定のリソースを設定するには、それらのインスタンスにタグを付け、スコープ = タグベース、グループ化ルール = インスタンスレベルを選択します。

    • アカウントのアラートにインスタンスグループ化を使用しないには、グループ化ルール = クラシックを選択します。

  3. エンゲージメントオプション: なしレポートのみ、またはデフォルトのいずれかを選択します。

    • 設定がアクティブな間、AMS がインシデントを作成したり、それらのリソースからアラームのオートメーションを実行したりしない場合は、なしを選択します。

    • 設定のアクティブ中に AMS がインシデントを作成したり、それらのリソースからアラームの自動化を実行したりせず、自動ヒーリング Systems Manager ドキュメントを実行したりせず、これらのイベントのレコードをレポートに含めるには、レポートのみを選択します。これは、やり取りするインシデントサポートケースの量を減らしたい場合や、非本番稼働用アカウントのインシデントなど、一部のリソースからのインシデントに即時の対応が必要ない場合に便利です。

    • AMS がアラートを処理し、オートメーションを実行し、必要に応じてインシデントケースを作成するには、デフォルトを選択します。

  4. 解決後: 24 時間48 時間、または 72 時間のいずれかを選択します。最後に、インシデントケースが自動的にクローズされるタイミングを設定します。最後のケースコレスポンデンスからの時間が、設定された解決後値に達すると、インシデントはクローズされます。

アラート通知

アラート処理の一環として、AWS AWS Managed Services (AMS) は影響分析に基づいてインシデントを作成し、影響を特定できる場合に、修復のためのインシデント管理プロセスを開始します。影響が判断できない場合、AMS はサービス通知を通じてアカウントに関連付けられた E メールアドレスにアラート通知を送信します。一部のシナリオでは、このアラート通知は送信されません。たとえば、インフラストラクチャ関連のチェックが CPU 使用率の高いアラートを渡す場合、アラート通知は送信されません。詳細については、 のアラート処理プロセスの AMS モニタリングアーキテクチャの図を参照してくださいモニタリングの仕組み

タグベースのアラート通知

タグを使用して、リソースのアラート通知をさまざまな E メールアドレスに送信します。1 つの E メールアドレスに送信される通知は、複数のデベロッパーチームが同じアカウントを使用する場合に混乱を引き起こす可能性があるため、タグベースのアラート通知を使用するのがベストプラクティスです。タグベースのアラート通知は、選択したEC2 インスタンスグループ化通知設定の影響を受けません。

タグベースのアラート通知を使用すると、次のことができます。

  • 特定の E メールアドレスにアラートを送信する: key = OwnerTeamEmail、 を使用して、特定の E メールアドレスに送信する必要があるアラートを含むリソースにタグ付けしますvalue = EMAIL_ADDRESS

  • 複数の E メールアドレスにアラートを送信する: 複数の E メールアドレスを使用するには、値のカンマ区切りリストを指定します。例えば、key = OwnerTeamEmailvalue = EMAIL_ADDRESS_1, EMAIL_ADDRESS_2, EMAIL_ADDRESS_3, ... などです。値フィールドの合計文字数は 260 を超えることはできません。

  • カスタムタグキーを使用する: カスタムタグキーを使用するには、タグベースの通信の自動通知を有効にすることを明示的に同意する E メールで CSDM にカスタムタグキー名を指定します。すべてのインスタンスとリソースで問い合わせタグに同じタグ付け戦略を使用するのがベストプラクティスです。

注記

OwnerTeamEmail のキー値はキャメルケースである必要はありません。ただし、タグでは大文字と小文字が区別されるため、推奨形式を使用することをお勧めします。

ローカル部分をドメインから分離するには、E メールアドレスを完全に指定し、「アットマーク」 (@) を指定する必要があります。無効な E メールアドレスの例: Team.AppATabc.xyz または john.doe。タグ付け戦略に関する一般的なガイダンスについては、「 AWS リソースのタグ付け」を参照してください。タグに個人を特定できる情報 (PII) を追加しないでください。可能な限りディストリビューションリストまたはエイリアスを使用します。

タグベースのアラート通知は、次の Amazon サービスのリソースでサポートされています。EC2、Elastic Block Store (EBS)、Elastic Load Balancing (ELB)、Application Load Balancer (ALB)、Network Load Balancer、リレーショナルデータベースサービス (RDS)、OpenSearch、Elastic File System (EFS)、FSx、Site-to-Site VPN。