翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AMS Accelerate での Amazon EKS のモニタリングとインシデント管理
Amazon EKS のモニタリングとインシデント管理は、Amazon EKS リソースの障害、パフォーマンスの低下、セキュリティの問題を監視します。AMS Accelerate は、Amazon Managed Service for Prometheus アラートマネージャールールを設定およびデプロイし、アラートをモニタリングしてから、これらのアラートがトリガーされたときにインシデント管理を実行します。Amazon EKS のモニタリングとインシデント管理は AMS Alarm Manager に依存し、[Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/grafana/latest/userguide/prometheus-data-source.html)、[Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html)、[Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html)、[AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)、 などのネイティブ AWS サービスを活用します[AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)。
**注記**
Amazon EKS のモニタリングとインシデント管理は AWS GovCloud (US)、、Windows ノード、または Windows コンテナをサポートしていません。
# AMS Accelerate での Amazon EKS のモニタリングとインシデント管理とは
Amazon EKS のモニタリングとインシデント管理には、次の機能があります。
+ 選択した Amazon EKS クラスターのマネージドアカウント全体でモニターとポリシーを作成、管理、デプロイするデフォルト設定。
+ Amazon EKS クラスターに他のモニタリングを設定していない場合でも、Amazon EKS ワークロードの可用性を向上させるためのモニタリングベースライン。詳細については、「[AMS Accelerate での Amazon EKS のモニタリングとインシデント管理のベースラインアラート](acc-baseline-eks-alerts.md)」を参照してください。
+ Amazon EKS クラスター用に設定されたベースラインモニタリングによって生成される通知。これらの通知はアラートと呼ばれます。アラートは、差し迫った障害、進行中の障害、回復中の障害、潜在的な障害、パフォーマンスの低下、またはセキュリティの問題が発生した場合に生成されます。アラートの例としては、Prometheus アラート、イベント、Amazon GuardDuty などの AWS サービスからの検出結果などがあります。
+ 実行できる適切な修復アクションに関するガイダンスとともに、調査をアラートします。詳細については、[「AMS Accelerate でのインシデントレポートとサービスリクエスト](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-supp-ex.html)」を参照してください。
+ AMS オペレーションによるアラートとインシデントの修復は、アプリケーションへの影響を防止または軽減するために、可能な場合はお客様の承認を得て行います。詳細については、[「AMS Accelerate でのインシデントレポートとサービスリクエスト](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-supp-ex.html)」を参照してください。
+ リソース使用率、パフォーマンス、CoreDNS の正常性、アクティブなアラート、以前に解決されたアラートを可視化するオプションの定義済み Amazon Managed Grafana ダッシュボード。AMS が提供するテンプレートを使用して Amazon Managed Grafana を設定する場合は、Amazon Managed Grafana コンソールを開いて、Amazon EKS クラスターのメトリクスとアラートを表示できます。
# AMS Accelerate での Amazon EKS のモニタリングとインシデント管理の仕組み
**生成：** EKS のオンボーディングモニタリングとインシデント管理の一環として、AMS はマネージドアカウントで選択した Amazon EKS クラスターのベースラインモニタリングを設定します。AMS は、Amazon Managed Service for Prometheus アラートマネージャールールと Amazon CloudWatch イベントルールを組み合わせて、ベースラインモニタリングを設定します。クラスター内の AMS 設定の Prometheus サーバーは、Prometheus メトリクスをスクレイプし、同じリージョン内の Amazon Managed Service for Prometheus エンドポイントにリモート書き込みます。ベースラインモニタリング設定は、Prometheus アラートマネージャールールがトリガーされるか、CloudWatch イベントが生成されるとアラートを生成します。
**集約：** AMS は、リソースが生成するすべてのアラートを AMS によって管理される Amazon Simple Notification Service トピックに送信することで、AMS モニタリングシステムに送信します。
**処理と影響の分析：** AMS はアラートを分析し、影響の可能性に基づいてアラートを処理します。AMS はアラートを次のように分類します。
+ **既知の顧客への影響があるアラート：** これらのアラートの場合、AMS はインシデント[管理プロセスを使用して新しいインシデント](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-manage-incidents.html)レポートを作成します。
+ **顧客への影響が不明なアラート：** これらのアラートの場合、AMS はインシデントレポートを送信します。多くの場合、これらのアラートでは、AMS がアクションを実行する前に影響を確認するように求められます。このようなアラートの場合、AMS は詳細を含む[アラート通知](acc-baseline-eks-alerts.md#acc-alerts-and-actions)を送信し、アラートに緩和アクションが必要かどうかを確認します。AMS には、通知内のアクションを軽減するためのオプションが用意されています。返信でアラートがインシデントであることを確認した場合、AMS は新しいインシデントレポートの作成をトリガーし、インシデント管理プロセスを開始します。「顧客への影響なし」または 3 日間応答をまったく受信しないサービス通知は、解決済みとしてマークされます。また、対応するアラートは解決済みとしてマークされます。
+ **顧客への影響がないアラート：** 評価後、AMS がアラートに顧客への影響がないと判断した場合、アラートは閉じられます。
## AMS 責任マトリックス (RACI)
AMS 責任、説明責任、相談、情報、または RACI マトリックスは、さまざまなアクティビティについて顧客または AMS に主な責任を割り当てます。次の表は、Amazon EKS のモニタリングとインシデント管理を使用するアプリケーションにおけるアクティビティに関する顧客と AMS の責任の概要を示しています。
+ **R** は、タスクを達成するために作業を行う責任者を表します。
+ **** は、説明責任を負う当事者を表します。
+ **C** は、相談された当事者、通常は対象分野の専門家として意見を求める当事者、二国間通信を行う当事者を指します。
+ **多くの場合**、タスクまたは成果物の完了時にのみ、進行状況が通知される当事者である、情報に基づく当事者です。
| アクティビティ | お客様 | AMS |
| --- | --- | --- |
| Discovery for AMS の要件 | I | R |
| クラスターアクセスの AMS アクセス許可 (RBAC) を有効にする | R | C |
| ワーカーノードに Amazon EC2 Systems Manager Agent がまだ存在しない場合はインストールする | R | C |
| 必要に応じて、Prometheus、Prometheus Node Exporter、kube-state-metrics などのクラスター上の AMS コンポーネントを AMS 名前空間にデプロイします。 | C | R |
| AMS コントロールプレーンで Amazon Managed Service for Prometheus をプロビジョニングする | I | R |
| AMS コントロールプレーンで Prometheus アラートマネージャーを設定する | I | R |
| Amazon Managed Grafana テンプレートを提供し、設定を支援する | C | R |
| GuardDuty EKS 監査ログのモニタリングを有効にする | C | R |
| Amazon EKS コントロールプレーンのログ記録を有効にする | I | R |
| Amazon EKS コントロールプレーンの状態とパフォーマンスをモニタリングする | I | R |
| Amazon EKS クラスター (クラスター、ノード、ワークロード、ポッド、API Server、CoreDNS) の状態とパフォーマンスをモニタリングする | I | R |
| アラートをトリアージし、Amazon EKS のインシデント対応を提供する | I | R |
| インシデント中に診断コマンドを実行する | I | R |
| インシデント中のログを分析する (コントロールプレーンとポッドログ） | I | R |
| AWS ネットワーク問題のインシデント対応 | I | R |
| GuardDuty EKS 監査ログのモニタリング結果への対応 | I | R |
| 可能であれば、インシデントを修正するためのアクションについて顧客ガイダンスを提供する | I | R |
# AMS Accelerate での Amazon EKS のモニタリングとインシデント管理のベースラインアラート
アラートを確認した後、AMS は Amazon EKS に対して次のアラートを有効にし、選択した Amazon EKS クラスターのモニタリングとインシデント管理を行います。応答時間サービスレベルアグリーメント (SLAs) とサービスレベル目標 (SLOs) は、選択したアカウントサービス階層 (Plus、Premium) によって異なります。詳細については、[「AMS Accelerate でのインシデントレポートとサービスリクエスト](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-supp-ex.html)」を参照してください。
## アラートとアクション
次の表に、Amazon EKS アラートと、AMS が実行する各アクションを示します。
| アラート | しきい値 | アクション |
| --- | --- | --- |
| コンテナ OOM が強制終了されました | 過去 10 分以内にコンテナを再起動した合計数は 1 回以上で、ポッド内の Kubernetes コンテナは過去 10 分以内にOOMKilled」という理由で終了しています。 | AMS は、OOM の強制終了の原因がコンテナ制限またはメモリ制限のオーバーコミットに達したかどうかを調査し、是正措置についてアドバイスします。 |
| ポッドジョブ失敗 | Kubernetes ジョブの完了に失敗します。失敗は、少なくとも 1 つの失敗したジョブステータスの存在によって示されます。 | AMS は、Kubernetes ジョブまたは対応する cron ジョブが失敗した理由を調査し、是正措置についてアドバイスします。 |
| StatefulSetダウン | トラフィックを処理する準備ができているレプリカの数が、少なくとも 1 分間、StatefulSetあたりの既存のレプリカの現在の数と一致しません。 | AMS は、ポッドイベントのエラーメッセージとポッドログのエラーログスニペットを確認することで、ポッドの準備が整っていない理由を判断し、是正措置についてアドバイスします。 |
| HPA スケーリング機能 | ステータス条件AbleToScale」が少なくとも 2 分間 false であるため、Horizontal Pod Autoscaler (HPA) はスケーリングできません。 | AMS は、デプロイやStatefulSetなど、後続のワークロードリソースのポッドをスケーリングできない Kubernetes Horizontal Pod Autoscaler (HPA) を決定します。 |
| HPA メトリクスの可用性 | Horizontal Pod Autoscaler (HPA) は、ステータス条件ScalingActive」が少なくとも 2 分間 false であるため、メトリクスを収集できません。 | AMS は、サーバー設定の問題や RBAC 認可の問題に関連するメトリクスなど、HPA がメトリクスを収集できない理由を決定します。 |
| ポッドの準備中 | Kubernetes ポッドは、15 分以上実行されていない状態 (保留中、不明、失敗など) のままになります。 | AMS は、影響を受けるポッド (複数可) の詳細を調査し、ポッドログに関連するエラーやイベントを確認し、是正措置についてアドバイスします。 |
| ポッドクラッシュループ | ポッドコンテナは、少なくとも 15 分ごとに 1 時間再起動します。 | AMS は、リソースの不足、別のコンテナによってロックされたファイル、別のコンテナによってロックされたデータベース、サービスの依存関係の失敗、外部サービスの DNS 問題、設定ミスなど、ポッドが起動しない理由を調査します。 |
| デーモンセットのスケジュールミス | 10 分間に 1 つ以上の Kubernetes Daemonset ポッドが誤ってスケジュールされています。 | AMS は、実行すべきではないノードでデーモンセットがスケジュールされている理由を決定します。これは、間違ったポッドnodeSelector/taints/affinitiesがデーモンセットポッドに適用された場合、またはノード (ノードプール) がテイントされ、既存のポッドがエビクション用にスケジュールされていない場合に発生する可能性があります。 |
| Kubernetes API エラー | Kubernetes API サーバーのエラー率が 2 分間で 3% を超えています。 | AMS はコントロールプレーンログを分析して、このアラートの原因となっているエラーの量とタイプを判断し、マスターノードまたは etcd 自動スケーリンググループのリソース競合の問題を特定します。API サーバーが復旧しない場合、AMS は Amazon EKS サービスチームを関与させます。 |
| Kubernetes API レイテンシー | Kubernetes API サーバーへのリクエストの 99 パーセンタイルレイテンシーは、2 分間で 1 秒を超えています。 | AMS はコントロールプレーンログを分析して、レイテンシーの原因となっているエラーの量とタイプを判断し、マスターノードまたは etcd 自動スケーリンググループのリソース競合の問題を特定します。API サーバーが復旧しない場合、AMS は Amazon EKS サービスチームを関与させます。 |
| Kubernetes クライアント証明書の有効期限切れ | Kubernetes API サーバーへの認証に使用されるクライアント証明書は、24 時間以内に期限切れになります。 | AMS はこの通知を送信して、クラスター証明書が 24 時間後に期限切れになることを通知します。 |
| ノードが準備中 | Node の「準備完了」条件ステータスが少なくとも 10 分間 false です。 | AMS は、API サーバーへの kubelet アクセスを妨げるネットワークの問題などのノード条件とイベントを調査します。 |
| ノード高 CPU | CPU 負荷が 5 分間で 80% を超えています。 | AMS は、1 つ以上のポッドが異常に大量の CPU を消費しているかどうかを決定します。次に、AMS はリクエスト、制限、ポッドアクティビティが想定どおりであることを確認します。 |
| ノード OOM の強制終了が検出されました | 4 分間にノードによって少なくとも 1 つのホスト OOM 強制終了が報告されています。 | AMS は、OOM の強制終了の原因がコンテナの制限に達したか、ノードのオーバーコミットであるかを判断します。アプリケーションアクティビティが正常である場合、AMS はオーバーコミットとポッド制限の改訂のリクエストと制限についてアドバイスします。 |
| ノード Conntrack の制限 | 接続追跡エントリの現在の数と最大制限の比率が 5 分間で 80% を超えています。 | AMS は、コアあたりの推奨 conntrack 値についてアドバイスします。Kubernetes ノードは、ノードの合計メモリ容量に比例して conntrack 最大値を設定します。高負荷アプリケーション、特に小さなノードでは、conntrack の最大値を簡単に超えるため、接続のリセットとタイムアウトが発生する可能性があります。 |
| ノードクロックが同期されていません | 2 分間の最小同期ステータスは 0 で、秒単位の最大エラーは 16 以上です。 | AMS は、Network Time Protocol (NTP) がインストールされ、正常に機能しているかどうかを判断します。 |
| Pod 高 CPU | コンテナの CPU 使用率が 3 分間のレートで 80% を最低 2 分間超える。 | AMS はポッドログを調査して、大量の CPU を消費するポッドタスクを決定します。 |
| ポッドハイメモリ | コンテナのメモリ使用量が 2 分間で指定されたメモリ制限の 80% を超えています。 | AMS はポッドログを調査して、大量のメモリを消費するポッドタスクを決定します。 |
| CoreDNS ダウン | CoreDNS が Prometheus ターゲット検出から 15 分以上消えました。 | これは、内部または外部のクラスターサービスのドメイン名解決が停止したことを示す重要なアラートです。AMS は CoreDNS ポッドのステータスをチェックし、CoreDNS 設定を検証し、CoreDNS ポッドをCoreDNS エンドポイントを検証し、CoreDNS 制限を検証し、承認があれば CoreDNS デバッグログ記録を有効にします。 |
| CoreDNS エラー | CoreDNS は、10 分間に DNS リクエストの 3% 以上について SERVFAIL エラーを返します。 | このアラートは、アプリケーションの問題や設定ミスを示している可能性があります。AMS は CoreDNS ポッドのステータスをチェックし、CoreDNS 設定を検証し、CoreDNS ポッドをCoreDNS エンドポイントを検証し、CoreDNS 制限を検証し、承認があれば CoreDNS デバッグログ記録を有効にします。 |
| CoreDNS レイテンシー | DNS リクエスト期間の 99 パーセンタイルが 10 分間 4 秒を超えています。 | このアラート CoreDNS が過負荷になっている可能性があることを示します。AMS は CoreDNS ポッドのステータスをチェックし、CoreDNS 設定を検証し、CoreDNS ポッドをポイントする DNS エンドポイントを検証し、CoreDNS 制限を検証し、お客様の承認により CoreDNS デバッグログ記録を有効にします。 |
| CoreDNS 転送レイテンシー | kube-dns への CoreDNS 転送リクエストの応答時間の 99 パーセンタイルが 10 分間で 4 秒を超えています。 | CoreDNS が権威サーバーでない場合、またはドマニン名のキャッシュエントリがない場合、CoreDNS は DNS リクエストをアップストリーム DNS サーバーに転送します。このアラートは、CoreDNS が過負荷になっているか、アップストリーム DNS サーバーに問題がある可能性があることを示します。AMS は CoreDNS ポッドのステータスをチェックし、CoreDNS 設定を検証し、CoreDNS ポッドをCoreDNS エンドポイントを検証し、CoreDNS 制限を検証し、お客様の承認により CoreDNS デバッグログ記録を有効にします。 |
| CoreDNS 転送エラー | DNS クエリの 3% 以上が 5 分間失敗しています。 | CoreDNS が権威サーバーでない場合、またはドマニン名のキャッシュエントリがない場合、CoreDNS は DNS リクエストをアップストリーム DNS サーバーに転送します。このアラートは、設定ミスの可能性やアップストリーム DNS サーバーの問題を示します。AMS は CoreDNS ポッドのステータスをチェックし、CoreDNS 設定を検証し、CoreDNS ポッドをCoreDNS エンドポイントを検証し、CoreDNS 制限を検証し、お客様の承認により CoreDNS デバッグログ記録を有効にします。 |
# AMS Accelerate での Amazon EKS のモニタリングとインシデント管理の要件
これらは、Amazon EKS for AMS Accelerate のモニタリングとインシデント管理にサポートおよび/または必要なリソースです。
+ **サポートされている Kubernetes バージョン：**[「Amazon EKS ユーザーガイド」の「Amazon EKS Kubernetes バージョン](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)」を参照してください。 ****
+ **ノードタイプ：** Amazon EKS マネージドノードがサポートされています。Windows ノードとコンテナはサポートされていません。
+ **Kubernetes クラスターアクセス：** AMS には system:masters RBAC クラスターロールとクラスターユーザーが必要です。
+ **Amazon EC2 ノードの SSM エージェント：** Bottle Rocket と Amazon EKS AMIsに SSM Agent がプリインストールされています。SSM Agent がカスタム AMIs と Amazon EC2 ノードにインストールされていることを確認します。
+ **Service Quotas** 詳細については、Amazon [Managed Service for Prometheus ](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP_quotas.html)および Amazon [Managed Grafana ](https://docs.aws.amazon.com/grafana/latest/userguide/AMG_quotas.html)のサービスクォータを参照してください。
+ **サポートされている AWS リージョン：**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/accelerate-guide/acc-requirements.html)
**注記**
アフリカ (ケープタウン) の af-south-1 とアジアパシフィック (香港) の ap-east-1 の Amazon EKS クラスターのメトリクスは AWS リージョン、それぞれ同じ の AMS モニタリングサービスにエクスポートされます。これらのメトリクス AWS リージョン は、AMS モニタリングサービス内で処理および保存される異なるリージョンに転送されます。AMS モニタリングサービスがメトリクスの保存に使用するリージョンについては、前の表を参照してください。
# AMS Accelerate で Amazon EKS のモニタリングとインシデント管理にオンボードする
Amazon EKS のモニタリングとインシデント管理にオンボードするには、次の手順を実行します。
1. **Amazon EKS コスト最適化タグを有効にする：**[「Amazon EKS ユーザーガイド」の「請求用のリソースのタグ付け](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html#tag-resources-for-billing)」を参照してください。 * ***
1. **EKS のモニタリングとインシデント管理のオンボーディングを開始する：** オンボーディングするアカウント IDs とクラスター名を使用して Cloud Service Delivery Manager (CSDM) にお問い合わせください。
1. **要件の検証：** Cloud Architect (CA) は、オンボーディングを開始する前にすべての[要件](acc-requirements.md)が満たされていることを検証します。
1. **Kubernetes ロールベースのアクセスコントロール (RBAC):** AMS は、これらの変更を実装するための`eksctl`コマンドを共有します。これらの変更を確認してからデプロイできます。AMS がユーザーに代わってコマンドを実行するアクセス許可を持つように、RBAC 更新をデプロイする必要があります。これらの更新には、AMS IAM ロールの Kubernetes ユーザーへのマッピング、AMS 用の新しい Kubernetes クラスターロールの作成、AMS Kubernetes クラスターロールのユーザーへのバインドが含まれます。
1. **クラスターコンポーネントのデプロイ：** AMS は、クラスターの AMS マネージド名前空間に次のコンポーネントをデプロイします。
+ Prometheus サーバー
+ Prometheus ノードエクスポーター (該当なし AWS Fargate）
+ kube-state-metrics
1. **Prometheus 設定の更新を実行する：** AMS はメトリクスのリモート書き込みを有効にするように Prometheus を設定します。
1. **（オプション) ダッシュボードを設定する：** CA は、アカウントで Amazon Managed Grafana ダッシュボードを設定するのに役立ちます。
**注記**
Amazon EKS クラスターがオンボーディングされると、AMS はアラートシグナルを分析し、ベースライン評価を実行してクラスター内の既存の問題を特定します。ベースライン評価が完了すると、AMS は Trusted Advisor とクラスター内の問題に対処するために使用できるサービスリクエストを通じて検出結果と修復の推奨事項を共有します。評価から、AMS はアカウントレベルのアラームしきい値を調整して、EKS クラスターに固有の Amazon EKS モニタリングベースラインを作成します。これらの結果に対する重複する AMS レスポンスを排除するために、これらのアラートシグナルを除外するようにモニタリングを調整します。CSDM から根本的な問題が修正されたことが通知されたら、シグナルを含めるようにモニタリングを再調整します。
# AMS Accelerate での Amazon EKS のモニタリングとインシデント管理からのオフボード
アカウント IDs とクラスター名を Cloud Service Delivery Manager (CSDM) に通知し、オフボーディングプロセスを開始します。オフボード後、アラート処理、メトリクスストレージ、メトリクスクエリは停止され、メトリクスはデフォルトの [ Amazon Managed Service for Prometheus データ保持ポリシー](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP_quotas.html)に従って削除されます。
AMS は、次のオフボーディングステップを実行します。
1. AMS は、ユーザーおよび AMS オペレーションに送信されるアラートを無効にします。
1. AMS は、Amazon EKS クラスターから Prometheus インスタンスを削除します。
1. AMS は、IAM ロールや AWS Config ルールなど、アカウントにインストールされている他の AWS リソースを削除します。
これらのステップが完了したら、以下のオフボーディングステップを完了する必要があります。
1. `eksctl` を使用して、 から Kubernetes RBAC `aws-auth` アクセス許可を削除します`ConfigMap`。
1. 以前にインストールした場合は、AMS に接続するように設定した Amazon Managed Grafana インスタンスを削除します。