本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# AMS Accelerate 中对 Amazon EKS 进行监控和事件管理
<a name="acc-mon-inc-mgmt-eks"></a>

Amazon EKS 的监控和事件管理可监控您的 Amazon EKS 资源是否存在故障、性能下降和安全问题。AMS Accelerate 配置和部署适用于 Prometheus 的亚马逊托管服务警报管理器规则，监控警报，然后在触发这些警报时执行事件管理。[Amazon EKS 的监控和事件管理依赖 AMS Alarm Manager 并利用原生 AWS 服务，例如适用于 [Prometheus 的亚马逊托管服务](https://docs.aws.amazon.com/grafana/latest/userguide/prometheus-data-source.html)、[亚马逊托管 Grafana、亚马逊](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html)和。 GuardDuty [AWS Lambda[AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html)

**注意**  
亚马逊 EKS 的监控和事件管理不支持 AWS GovCloud (US) Windows 节点或 Windows 容器。

# AMS Accelerate 中对 Amazon EKS 的监控和事件管理是什么？
<a name="acc-what-is-mon-inc-eks"></a>

Amazon EKS 的监控和事件管理提供以下内容：
+ 一种默认配置，用于在您的托管账户中为您选择的 Amazon EKS 集群创建、管理和部署监控器和策略。
+ 即使您没有为 Amazon EKS 集群配置任何其他监控，也可让您的 Amazon EKS 工作负载提高可用性的监控基准。有关更多信息，请参阅 [AMS Accelerate 中的 Amazon EKS 监控和事件管理中的基准警报](acc-baseline-eks-alerts.md)。
+ 由为您的 Amazon EKS 集群配置的基准监控生成的通知。这些通知被称为警报。当出现即将发生的、持续的、正在消失的或潜在的故障、性能下降或安全问题时，就会生成警报。警报的示例包括 Prometheus 警报、事件或来自 AWS 服务（例如亚马逊）的发现。 GuardDuty
+ 警报调查，并提供有关您可以采取的适当补救措施的指导。有关更多信息，请参阅 [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)。
+ 可选的预定义 Amazon Managed Grafana 控制面板，可让您了解资源利用率、性能、CoreDNS 的运行状况、活动警报和之前已解决的警报。如果您使用 AMS 提供的模板配置亚马逊托管 Grafana，则可以打开亚马逊托管 Grafana 控制台来查看亚马逊 EKS 集群的指标和提醒。

# Amazon EKS 的监控和事件管理如何在 AMS Accelerate 中发挥作用
<a name="acc-how-mon-inc-mgmt-eks-works"></a>

**生成：**作为 EKS 入职监控和事件管理的一部分，AMS 会为您在托管账户中选择的 Amazon EKS 集群配置基准监控。AMS 结合使用适用于 Prometheus 的亚马逊托管服务警报管理器规则和 CloudWatch 亚马逊事件规则来配置基准监控。集群中配置了 AMS 的 Prometheus 服务器会将你的 Prometheus 指标抓取并远程写入同一地区的亚马逊托管服务 Prometheus 终端节点。当触发 Prometheus 警报管理器规则或生成事件时，基线监控配置会生成警报。 CloudWatch 

**聚合：**AMS 通过将您的资源生成的所有警报定向到由 AMS 管理的 Amazon 简单通知服务主题，将其发送到 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 就会触发创建新的事件报告并启动事件管理流程。任何收到 “对客户没有影响” 回复或三天内完全没有回复的服务通知都将被标记为已解决。此外，相应的警报也被标记为已解决。
+ **不影响客户的警报：**如果 AMS 在评估后确定该警报对客户没有任何影响，则该警报将关闭。

## AMS 责任矩阵 (RACI)
<a name="acc-raci-matrix"></a>

负责任、负责、咨询和知情的 AMS 或 RACI 矩阵将各种活动的主要责任分配给客户或 AMS。下表概述了客户和 AMS 在使用 Amazon EKS 监控和事件管理的应用程序中活动的责任。
+ **R** 代表负责完成任务的责任方。
+ **A** 代表责任方。
+ **C** 代表咨询；征求意见的一方，通常是作为主题专家征求意见的一方；以及与之进行双边沟通的一方。
+ **我**代表知情；通报进展情况的一方，通常只有在任务或可交付成果完成后才会被告知。


| 活动 | Customer | AMS | 
| --- | --- | --- | 
| 针对 AMS 要求的发现 | 我 | R | 
| 为集群访问启用 AMS 权限 (RBAC) | R | C | 
|  如果工作节点上还没有 Amazon S EC2 ystems Manager 代理，请将其安装在工作节点上  | R | C | 
|  根据需要在集群上部署 AMS 组件，例如 Prometheus、Prometheus Node Exporter 和 AMS 命名空间。 kube-state-metrics | C | R | 
|  在 AMS 控制平面中为 Prometheus 配置亚马逊托管服务 | 我 | R | 
|  在 AMS 控制平面中配置 Prometheus 警报管理器 | 我 | R | 
|  提供亚马逊托管 Grafana 模板并协助进行配置 | C | R | 
|  启用 GuardDuty EKS 审核日志监控 | C | R | 
|  启用 Amazon EKS 控制平面日志记录 | 我 | R | 
|  监控 Amazon EKS 控制平面的运行状况和性能 | 我 | R | 
|  监控 Amazon EKS 集群（集群、节点、工作负载、容器、API 服务器和 CoreDNS）的运行状况和性能 | 我 | R | 
|  为 Amazon EKS 对警报进行分类并提供事件响应 | 我 | R | 
|  在事件发生期间运行诊断命令 | 我 | R | 
|  在事件期间分析日志（控制平面和 pod 日志） | 我 | R | 
|   AWS 网络问题事件响应 | 我 | R | 
|  回应 GuardDuty EKS 审核日志监控结果 | 我 | R | 
|  尽可能为客户提供有关补救事件的行动指导 | 我 | R | 

# AMS Accelerate 中的 Amazon EKS 监控和事件管理中的基准警报
<a name="acc-baseline-eks-alerts"></a>

 验证警报后，AMS 会为 Amazon EKS 启用以下警报，然后对所选的 Amazon EKS 集群进行监控和事件管理。响应时间服务级别协议 (SLAs) 和服务级别目标 (SLOs) 取决于您选择的账户服务级别（Plus、Premium）。有关更多信息，请参阅 [AMS Accelerate 中的事件报告和服务请求](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-supp-ex.html)。

## 警报和操作
<a name="acc-alerts-and-actions"></a>

下表列出了 Amazon EKS 警报以及 AMS 采取的相应操作：


| 警报 | 阈值 | 操作 | 
| --- | --- | --- | 
|  容器 OOM 被杀 | 在过去 10 分钟内，容器重启的总次数至少为 1，Pod 中的 Kubernetes 容器在过去 10 分钟内已终止，原因为 “OOMKilled”。 | AMS 会调查 OOM 终止是由于达到容器限制还是内存限制过度使用而导致，然后建议您采取纠正措施。 | 
|  Pod Job 失败 | Kubernetes 任务无法完成。如果存在至少一个失败的任务状态，则表示失败。 |  AMS 会调查 Kubernetes 作业或相应的 cron 作业失败的原因，然后建议您采取纠正措施。 | 
|  StatefulSet 向下 | 在至少 1 分钟内，准备提供流量的副本数量与每个 StatefulSet 副本的当前数量不匹配。 |  AMS 通过查看 pod 事件中的错误消息和 pod 日志中的错误日志片段来确定 pod 未准备就绪的原因，然后建议您采取更正措施。 | 
|  HPA 扩展能力 | 由于状态条件 “AbleToScale” 在至少 2 分钟内为假，水平吊舱自动扩缩器 (HPA) 无法扩展。 |  AMS 确定哪个 Kubernetes 水平容器自动扩缩器 (HPA) 无法为其后续工作负载资源（例如部署或）扩展 pod。 StatefulSet | 
|  HPA 指标可用性 | 由于状态条件 “ScalingActive” 在至少 2 分钟内为假，水平吊舱自动扩缩器 (HPA) 无法收集指标。 |  AMS 确定 HPA 无法收集指标的原因，例如与服务器配置问题或 RBAC 授权问题相关的指标。 | 
|  吊舱未准备好 | Kubernetes Pod 处于非运行状态（例如 “待处理”、“未知” 或 “失败”）的时间超过 15 分钟。 |  AMS 会调查受影响的 pod 以获取详细信息，查看容器日志中是否存在相关的错误和事件，然后建议您采取纠正措施。 | 
|  吊舱崩溃循环 | Pod 容器至少每 15 分钟重启一次，持续 1 小时。 |  AMS 会调查 Pod 无法启动的原因，例如资源不足、文件被另一个容器锁定、数据库被另一个容器锁定、服务依赖关系失败、外部服务的 DNS 问题以及配置错误。 | 
|  Daemonset 计划错误 | 至少有一个 Kubernetes Daemonset pod 在 10 分钟内错时调度。 |  AMS 决定为何将守护进程安排在不应该运行的节点上。当将错误的 pod 应用于 Da nodeSelector/taints/affinities emonset pod 时，或者当节点（节点池）受到污染并且未安排驱逐现有 Pod 时，可能会发生这种情况。 | 
|  Kubernetes API 错误 | 在 2 分钟内，Kubernetes API 服务器的错误率超过 3%。 |  AMS 会分析控制平面日志，以确定导致此警报的错误数量和类型，并识别主节点或 etcd 自动缩放组的任何资源争用问题。如果 API 服务器无法恢复，AMS 会与 Amazon EKS 服务团队合作。 | 
|  Kubernetes API 延迟 | 在 2 分钟内，向 Kubernetes API 服务器发出的请求延迟在 99 个百分位数内超过 1 秒。 |  AMS 分析控制平面日志，以确定导致延迟的错误数量和类型，并识别主节点或 etcd 自动缩放组的任何资源争用问题。如果 API 服务器无法恢复，AMS 会与 Amazon EKS 服务团队合作。 | 
|  Kubernetes 客户端证书即将到期 | 用于向 Kubernetes API 服务器进行身份验证的客户端证书将在不到 24 小时后到期。 |  AMS 发送此通知是为了通知您，您的集群证书将在 24 小时后过期。 | 
|  节点未就绪 | 在至少 10 分钟内，节点 “就绪” 状态为假。 |  AMS 会调查阻止 kubelet 访问 API 服务器的节点状况和事件，例如网络问题。 | 
|  节点高 CPU | 在 5 分钟内，CPU 负载超过 80%。 |  AMS 会确定一个或多个 pod 消耗的 CPU 量是否异常高。然后，AMS 会与您核实您的请求、限制和 pod 活动是否符合预期。 | 
|  检测到节点 OOM 杀死 | 在 4 分钟的时间段内，该节点至少报告了一次主机 OOM 终止。 |  AMS 确定 OOM 终止是由于达到容器限制还是节点过度使用而导致。如果应用程序活动正常，AMS 会就超额提交的请求和限制以及修改 Pod 限制向您提供建议。 | 
|  节点连接限制 | 在 5 分钟内，当前连接跟踪条目数与最大限制的比率超过 80%。 |  AMS 会根据每个内核的推荐连接值为您提供建议。Kubernetes 节点将 conntrack 最大值设置为与节点的总内存容量成正比。高负载应用程序，尤其是在较小的节点上，很容易超过 conntrack 的最大值，从而导致连接重置和超时。 | 
|  节点时钟不同步 | 2 分钟内的最低同步状态为 0，以秒为单位的最大错误为 16 或更高。 |  AMS 确定网络时间协议 (NTP) 是否已安装并正常运行。 | 
|  Pod 高 CPU | 容器的 CPU 使用率在 3 分钟内超过 80%，持续至少 2 分钟。 |  AMS 会调查 pod 日志，以确定消耗大量 CPU 的 pod 任务。 | 
|  Pod 高内存 | 容器的内存使用率在 2 分钟内超过其指定内存限制的 80%。 |  AMS 会调查 pod 日志，以确定消耗大量内存的 pod 任务。 | 
|  CoreDNS 关闭 | CoreDNS 已经从 Prometheus 的目标发现中消失了超过 15 分钟。 |  这是一个严重警报，表示内部或外部群集服务的域名解析已停止。AMS 会检查 CoreDNS 容器的状态，验证 CoreDNS 配置，验证指向 CoreDNS 容器的 DNS 端点，验证 CoreDNS 限制，并在您批准后启用 CoreDNS 调试日志。 | 
|  CoreDNS 错误 | CoreDNS 会在 10 分钟内对超过 3% 的 DNS 请求返回 SERVFAIL 错误。 |  此警报可能表示应用程序存在问题或配置错误。AMS 会检查 CoreDNS 容器的状态，验证 CoreDNS 配置，验证指向 CoreDNS 容器的 DNS 端点，验证 CoreDNS 限制，并在您批准后启用 CoreDNS 调试日志。 | 
|  CoreDNS 延迟 | DNS 请求持续时间的第 99 个百分位数超过 4 秒，持续 10 分钟。 |  此警报表示 CoreDNS 可能已过载。AMS 会检查 CoreDNS 容器的状态，验证 CoreDNS 配置，验证指向 CoreDNS 容器的 DNS 端点，验证 CoreDNS 限制，并在您批准后启用 CoreDNS 调试日志。 | 
| CoreDNS 转发延迟 | CoreDNS 将请求转发到 kube-dns 的响应时间的第 99 个百分位数在 10 分钟内超过 4 秒。 |  当 CoreDNS 不是权威服务器或者没有域名的缓存条目时，CoreDNS 会将 DNS 请求转发到上游 DNS 服务器。此警报表示 CoreDNS 可能已过载或上游 DNS 服务器可能存在问题。AMS 会检查 CoreDNS 容器的状态，验证 CoreDNS 配置，验证指向 CoreDNS 容器的 DNS 端点，验证 CoreDNS 限制，并在您批准后启用 CoreDNS 调试日志。 | 
|  CoreDNS 转发错误 | 超过 3% 的 DNS 查询在 5 分钟内失败。 |  当 CoreDNS 不是权威服务器或者没有域名的缓存条目时，CoreDNS 会将 DNS 请求转发到上游 DNS 服务器。此警报表示上游 DNS 服务器可能存在配置错误或问题。AMS 会检查 CoreDNS 容器的状态，验证 CoreDNS 配置，验证指向 CoreDNS 容器的 DNS 端点，验证 CoreDNS 限制，并在您批准后启用 CoreDNS 调试日志。 | 

# 在 AMS Accelerate 中对 Amazon EKS 进行监控和事件管理的要求
<a name="acc-requirements"></a>

这些是 Amazon EKS for AMS Accelerate 监控和事件管理 and/or 所需的支持资源
+ **支持的 Kubernetes 版本：请参阅****亚马逊 EKS 用户指南中的[亚马逊 EKS Kubernetes 版本](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)。**
+ **节点类型：**支持 Amazon EKS 托管节点。不支持 Windows 节点和容器。
+ **Kubernetes 集群访问权限：AMS 需要系统:**masters RBAC 集群角色和集群用户。
+ **亚马逊 EC2 节点上的 SSM 代理：**Bottle Rocket 和 Amazon EKS AMIs 都预装了 SSM 代理。请确保在您的自定义节点 AMIs 和 Amazon EC2 节点上安装了 SSM 代理。
+ **服务配额**[有关更多信息，请参阅适用于 [Prometheus 的亚马逊托管服务和亚马逊托管 Grafana 的](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP_quotas.html)服务配额。](https://docs.aws.amazon.com/grafana/latest/userguide/AMG_quotas.html)
+ **支持的 AWS 区域：**    
<a name="available-regions-table"></a>[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/managedservices/latest/accelerate-guide/acc-requirements.html)
**注意**  
位于非洲 af-south-1（开普敦）和亚太地区（香港）ap-east-1（香港）的 Amazon EKS 集群的指标将分别导出到 AMS 监控服务。 AWS 区域然后， AWS 区域 这些指标将在 AMS 监控服务中传输到不同的区域，在那里进行处理和存储。有关 AMS 监控服务用于存储指标的区域，请参阅上表。

# 在 AMS Accelerate 中加入 Amazon EKS 的监控和事件管理
<a name="acc-mon-inc-mgmt-eks-onboarding"></a>

执行以下步骤以加入 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 的监控和事件管理入门：**请联系您的云服务交付经理 (CSDM)，提供要加入的账户 IDs 和集群名称。

1. **验证要求：**您的云架构师 (CA) 将在入职开始之前验证是否满足了所有[要求](acc-requirements.md)。

1. **更新 Kubernetes 基于角色的访问控制 (RBAC)：**AMS 共享命令来实现这些`eksctl`更改。您可以查看这些更改，然后进行部署。您必须部署 RBAC 更新，这样 AMS 才有权代表您运行命令。这些更新包括将 AMS IAM 角色映射到 Kubernetes 用户、为 AMS 创建新的 Kubernetes 集群角色以及将 AMS Kubernetes 集群角色绑定到该用户。

1. **部署集群组件：**AMS 在您的集群上的 AMS 管理的命名空间中部署以下组件：
   + Prometheus 服务器
   + Prometheus 节点导出器（不适用于） AWS Fargate
   + kube-state-metrics

1. **执行 Prometheus 配置更新：AMS 将 Prometheu** s 配置为启用指标的远程写入。

1. **（可选）配置控制面板：**您的 CA 可帮助您在账户中配置 Amazon Managed Grafana 控制面板。

**注意**  
在您的 Amazon EKS 集群加载后，AMS 会分析警报信号并执行基准评估以确定集群中存在的问题。基准评估完成后，AMS 将通过 Trusted Advisor 分享调查结果和补救建议，并提交一份服务请求，您可以使用这些请求来解决集群中的问题。根据评估，AMS 通过调整账户级别的警报阈值，创建特定于您的 EKS 集群的 Amazon EKS 监控基准。为了消除针对这些发现的重复AMS响应，我们调整了监控以排除这些警报信号。当您的CSDM通知我们潜在问题已得到修复时，我们会重新调整监控，以包括信号。

# 在 AMS Accelerate 中脱离对 Amazon EKS 的监控和事件管理
<a name="acc-mon-inc-mgmt-eks-offboarding"></a>

使用账户 IDs 和集群名称通知您的云服务交付经理 (CSDM)，开始离职流程。在您离线后，根据[适用于 Prometheus 的默认亚马逊托管服务](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP_quotas.html)数据保留政策，将暂停警报处理、指标存储和指标查询，并删除指标。

AMS 执行以下离线步骤：



1. AMS 会禁用发送给您和 AMS 运营部门的警报。

1. AMS 从您的亚马逊 EKS 集群中移除 Prometheus 实例。

1. AMS 会移除您账户中安装的其他 AWS 资源，例如 IAM 角色和 AWS Config 规则。

完成这些步骤后，您必须完成以下离职步骤：

1. 用于从中`eksctl`移除 Kubernetes RBAC 权限。`aws-auth` `ConfigMap`

1. 如果您之前安装了该实例，请删除您配置为连接到 AMS 的 Amazon 托管 Grafana 实例。