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

# モニタリングの仕組み
<a name="how-monitoring-works"></a>

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

次の図は、**AMS マルチアカウントランディングゾーン**と **AMS シングルアカウントランディングゾーン**のモニタリングワークフローの概要を示しています。

![\[AMS マルチアカウントランディングゾーンのモニタリングアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/userguide/images/monitoringNew3.png)

+ 生成: アカウントのオンボーディング時に、AMS はマネージドアカウントで作成されたすべてのリソースのベースラインモニタリング (CloudWatch (CW) アラームと CW イベントルールの組み合わせ) を設定します。ベースラインモニタリング設定は、CW アラームがトリガーされたとき、または CW イベントが生成されたときにアラートを生成します。
+ 集計：
  + **マルチアカウントランディングゾーン**: アラートは、アプリケーションおよびコア組織単位アカウント内のリソースによって生成され、セキュリティアカウントを通じて AMS モニタリングシステムに送信されます。
  + **単一アカウントランディングゾーン**: リソースによって生成されたすべてのアラートは、アカウントの SNS トピックに誘導することで AMS モニタリングシステムに送信されます。
  + AMS が EC2 アラートをグループ化する方法を設定することもできます。AMS は、同じ EC2 インスタンスに関連するすべてのアラートを 1 つのインシデントにグループ化するか、必要に応じてアラートごとに 1 つのインシデントを作成します。この設定は、Cloud Service Delivery Manager または Cloud Architect を使用していつでも変更できます。これは、マルチアカウントランディングゾーンとシングルアカウントランディングゾーンのどちらを使用している場合でも同じように機能します。
+ 処理: AMS はアラートを分析し、影響の可能性に基づいてアラートを処理します。アラートは次に示すように処理されます。
  + 既知の顧客への影響があるアラート: 新しいインシデントレポートと AMS の作成は、インシデント管理プロセスに従います。インシデント管理の詳細については、「」を参照してください[AMS インシデント対応](sec-incident-response.md)。

    アラートの例: 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 インスタンスグループ化通知
<a name="how-monitoring-works-alert-notes-grouping"></a>

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

1. **スコープ**: **アカウント全体**または**タグベース**のいずれかを選択します。
   + そのアカウントのすべての EC2 インスタンスに適用される設定を指定するには、スコープ = **アカウント全体**を選択します。
   + 特定のタグを持つそのアカウントの EC2 インスタンスにのみ適用される設定を指定するには、スコープ = **タグベース**を選択します。

1. **グループ化ルール**: **クラシック**または**インスタンス**を選択します。
   + アカウント内のすべてのリソースに対してインスタンスレベルのグループ化を設定するには、スコープ = **アカウント全体**、グループ化ルール = **インスタンス**を選択します。
   + インスタンスレベルのグループ化を使用するようにアカウント内の特定のリソースを設定するには、それらのインスタンスにタグを付け、スコープ = **タグベース**、グループ化ルール = **インスタンス**レベルを選択します。
   + アカウントのアラートにインスタンスグループ化を使用しないには、グループ化ルール = **クラシック**を選択します。

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

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

### アラート通知
<a name="how-mon-works-alert-notes"></a>

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

## タグベースのアラート通知
<a name="how-mon-works-alert-notes-tags"></a>

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

タグベースのアラート通知を使用すると、次のことができます。
+ **特定の E メールアドレスにアラートを送信する**: `key = OwnerTeamEmail`、 を使用して、特定の E メールアドレスに送信する必要があるアラートを含むリソースにタグ付けします`value = EMAIL_ADDRESS`。
+ **複数の E メールアドレスにアラートを送信する**: 複数の E メールアドレスを使用するには、値のカンマ区切りリストを指定します。例えば、`key = OwnerTeamEmail` や `value = EMAIL_ADDRESS_1, EMAIL_ADDRESS_2, EMAIL_ADDRESS_3, ...` などです。値フィールドの合計文字数は 260 を超えることはできません。
+ **カスタムタグキー**を使用する: カスタムタグキーを使用するには、タグベースの通信の自動通知をアクティブ化することを明示的に同意する E メールで CSDM にカスタムタグキー名を指定します。すべてのインスタンスとリソースで問い合わせタグに同じタグ付け戦略を使用するのがベストプラクティスです。

**注記**  
*OwnerTeamEmail* のキー値はキャメルケースである必要はありません。ただし、タグでは大文字と小文字が区別されるため、推奨形式を使用することをお勧めします。  
ローカル部分をドメインから分離するには、E メールアドレスを「アットマーク」 (@) で完全に指定する必要があります。無効な E メールアドレスの例: *Team.AppATabc.xyz* または *john.doe*。タグ付け戦略の一般的なガイダンスについては、「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。タグに個人を特定できる情報 (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。