添加链接
link管理
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接

维度: ApiName、Stage

警报描述: 此警报会检测高客户端错误率。这可能表明授权或客户端请求参数存在问题。这也可能意味着资源已被删除,或者客户端正在请求一个不存在的资源。请考虑启用 CloudWatch Logs 并检查是否存在任何可能导致 4XX 错误的错误。此外,可以考虑启用详细的 CloudWatch 指标,以便按资源和方法查看此指标,并缩小错误来源的范围。超出配置的节流限制也可能导致错误。如果响应和日志报告的 429 错误率很高且出人意料,请按照 本指南 排查此问题。

意图: 此警报可以检测 API Gateway 请求的高客户端错误率。

统计数据: 平均值

建议阈值: 0.05

阈值理由: 建议阈值会检测何时总请求数中超过 5% 的请求会收到 4XX 错误。但是,您可以调整阈值以适应请求的流量以及可接受的错误率。您还可以分析历史数据以确定应用程序工作负载的可接受错误率,然后相应地调整阈值。需要对经常发生的 4XX 错误发出警报。但是,将阈值设置得非常低可能会导致警报过于敏感。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

5XXError

维度: ApiName、Stage

警报描述: 此警报有助于检测高客户端错误率。这可能表明 API 后端、网络或 API 网关与后端 API 之间的集成存在问题。本 文档 可以帮助您排查 5xx 错误的原因。

意图: 此警报可以检测 API Gateway 请求的高服务器端错误率。

统计数据: 平均值

建议阈值: 0.05

阈值理由: 建议阈值会检测何时总请求数中超过 5% 的请求会收到 5XX 错误。但是,您可以调整阈值以适应请求流量和可接受的错误率。您也可以分析历史数据以确定应用程序工作负载的可接受错误率,然后相应地调整阈值。需要对经常发生的 5XX 错误发出警报。但是,将阈值设置得非常低可能会导致警报过于敏感。

时间段: 60

要发出警报的数据点数 :3

评估期: 3

比较运算符: GREATER_THAN_THRESHOLD

维度: ApiName、Stage

警报描述: 此警报有助于检测 REST API 阶段的低流量。这可能表示应用程序在调用 API 时存在问题,例如使用了错误的端点。这也可能表明 API 的配置或权限存在问题,导致客户端无法访问它。

意图: 此警报可检测 REST API 阶段的意外低流量。如果您的 API 在正常条件下收到数量可预测且一致的请求,我们建议您创建此告警。如果您已启用详细的 CloudWatch 指标,并且可以预测每个方法和资源的正常流量,我们建议您创建备用警报,以便对每种资源和方法的流量下降进行更精细的监控。对于预计流量不稳定的 API,不建议使用此告警。

统计数据: SampleCount

建议阈值: 取决于您的情况

阈值理由: 根据历史数据分析设置阈值,以确定您的 API 的预期基准请求计数是多少。将阈值设置为非常高的值,可能会导致警报在正常流量和预期较低流量的时间段过于敏感。相反,将其设置为非常低的值可能会导致警报错过流量异常小的下降。

时间段: 60

要发出警报的数据点数 :10

评估期: 10

比较运算符: LESS_THAN_THRESHOLD

维度: ApiName、Stage、Resource、Method

警报描述: 此警报有助于检测阶段中 REST API 资源和方法的低流量。这可能表示应用程序在调用 API 时存在问题,例如使用了错误的端点。这也可能表明 API 的配置或权限存在问题,导致客户端无法访问它。

意图: 此警报可检测阶段中 REST API 资源和方法的意外低流量。如果您的 API 在正常条件下收到数量可预测且一致的请求,我们建议您创建此告警。对于预计流量不稳定的 API,不建议使用此告警。

统计数据: SampleCount

建议阈值: 取决于您的情况

阈值理由: 根据历史数据分析设置阈值,以确定您的 API 的预期基准请求计数是多少。将阈值设置为非常高的值,可能会导致警报在正常流量和预期较低流量的时间段过于敏感。相反,将其设置为非常低的值可能会导致警报错过流量异常小的下降。

时间段: 60

要发出警报的数据点数 :10

评估期: 10

比较运算符: LESS_THAN_THRESHOLD

尺寸: ApilD、Stage

警报描述: 此警报有助于检测 HTTP API 阶段的低流量。这可能表示应用程序在调用 API 时存在问题,例如使用了错误的端点。这也可能表明 API 的配置或权限存在问题,导致客户端无法访问它。

意图: 此警报可检测 HTTP API 阶段的意外低流量。如果您的 API 在正常条件下收到数量可预测且一致的请求,我们建议您创建此告警。如果您已启用详细的 CloudWatch 指标,并且可以预测每个路由的正常流量,我们建议您为此创建备用警报,以便对每个路由的流量下降进行更精细的监控。对于预计流量不稳定的 API,不建议使用此告警。

统计数据: SampleCount

建议阈值: 取决于您的情况

阈值理由: 根据历史数据分析设置阈值,以确定您的 API 的预期基准请求计数是多少。将阈值设置为非常高的值,可能会导致警报在正常流量和预期较低流量的时间段过于敏感。相反,将其设置为非常低的值可能会导致警报错过流量异常小的下降。

时间段: 60

要发出警报的数据点数 :10

评估期: 10

比较运算符: LESS_THAN_THRESHOLD

维度: ApiId、Stage、Resource、Method

警报描述: 此警报有助于检测阶段中 HTTP API 路由的低流量。这可能表示应用程序在调用 API 时存在问题,例如使用了错误的端点。这也可能表明 API 的配置或权限存在问题,导致客户端无法访问它。

意图: 此警报可检测阶段中 HTTP API 路由的意外低流量。如果您的 API 在正常条件下收到数量可预测且一致的请求,我们建议您创建此告警。对于预计流量不稳定的 API,不建议使用此告警。

统计数据: SampleCount

建议阈值: 取决于您的情况

阈值理由: 根据历史数据分析设置阈值,以确定您的 API 的预期基准请求计数是多少。将阈值设置为非常高的值,可能会导致警报在正常流量和预期较低流量的时间段过于敏感。相反,将其设置为非常低的值可能会导致警报错过流量异常小的下降。

时间段: 60

要发出警报的数据点数 :10

评估期: 10

比较运算符: LESS_THAN_THRESHOLD

IntegrationLatency

尺寸: ApilD、Stage

警报描述: 此警报有助于检测阶段中 API 请求是否存在高集成延迟。您可以将 IntegrationLatency 指标值与后端的相应延迟指标(例如 Lambda 集成的 Duration 指标)相关联。这有助于您确定 API 后端是否由于性能问题而花费更多时间来处理来自客户端的请求,或者初始化或冷启动是否存在其他开销。此外,请考虑为您的 API 启用 CloudWatch Logs,并检查日志中是否存在任何可能导致高延迟问题的错误。此外,可以考虑启用详细的 CloudWatch 指标来查看每个路由的此指标,从而帮助您缩小集成延迟来源的范围。

意图: 此警报可以检测阶段中的 API Gateway 请求何时具有高集成延迟。我们建议针对 WebSocket API 设置此警报,并且认为它对于 HTTP API 来说是可选的,因为后者已经具有针对延迟指标的单独警报建议。如果您已启用详细的 CloudWatch 指标,并且每个路由的集成延迟性能要求不同,我们建议您创建备用警报,以便对每个路由的集成延迟进行更精细的监控。

统计数据: p90

建议阈值: 2000.0

阈值理由: 建议阈值并不适用于所有 API 工作负载。但是,您可以将其用作阈值的起点。然后,您可以根据工作负载以及 API 的可接受延迟、性能和 SLA 要求选择不同的阈值。如果 API 通常可以接受较高的延迟,则可以设置更高的阈值以降低警报的敏感度。但是,如果预计 API 能够提供近乎实时的响应,请设置较低的阈值。您还可以分析历史数据以确定应用程序工作负载的预期基准延迟,然后用其相应地调整阈值。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

IntegrationLatency

维度: Apild、Stage、Route

警报描述: 此警报有助于检测阶段中路由的 WebSocket API 请求是否存在高集成延迟。您可以将 IntegrationLatency 指标值与后端的相应延迟指标(例如 Lambda 集成的 Duration 指标)相关联。这有助于您确定 API 后端是否由于性能问题而花费更多时间来处理来自客户端的请求,或者初始化或冷启动是否存在其他开销。此外,请考虑为您的 API 启用 CloudWatch Logs,并检查日志中是否存在任何可能导致高延迟问题的错误。

意图: 此警报可以检测阶段中路由的 API Gateway 请求何时具有高集成延迟。

统计数据: p90

建议阈值: 2000.0

阈值理由: 建议阈值并不适用于所有 API 工作负载。但是,您可以将其用作阈值的起点。然后,您可以根据工作负载以及 API 的可接受延迟、性能和 SLA 要求选择不同的阈值。如果 API 通常可以接受较高的延迟,则可以设置更高的阈值以降低告警的敏感度。但是,如果预计 API 能够提供近乎实时的响应,请设置较低的阈值。您还可以分析历史数据以确定应用程序工作负载的预期基准延迟,然后用其相应地调整阈值。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

维度: ApiName、Stage

警报描述: 此警报会检测阶段中的高延迟。确定 IntegrationLatency 指标值以检查 API 后端延迟。如果这两个指标基本一致,则 API 后端是导致延迟更高的来源,您应该调查其中是否存在问题。另外,请考虑启用 CloudWatch Logs 并检查是否存在可能导致高延迟的错误。此外,可以考虑启用详细的 CloudWatch 指标,以便按资源和方法查看此指标,并缩小延迟来源的范围。如果适用,请参阅 如何排查与 Lambda 集成的 API Gateway 请求中的高延迟问题? 如何在 API Gateway 中解决边缘优化的 API 端点中的延迟问题? 指南。

意图: 此警报可以检测阶段中的 API Gateway 请求何时具有高延迟。如果您已启用详细的 CloudWatch 指标,并且每个方法和资源的延迟性能要求不同,我们建议您创建备用警报,以便对每个资源和方法的延迟进行更精细的监控。

统计数据: p90

建议阈值: 2500.0

阈值理由: 建议阈值并不适用于所有 API 工作负载。但是,您可以将其用作阈值的起点。然后,您可以根据工作负载以及 API 的可接受延迟、性能和 SLA 要求选择不同的阈值。如果 API 通常可以接受较高的延迟,则可以设置更高的阈值以降低告警的敏感度。但是,如果预计 API 能够提供近乎实时的响应,请设置较低的阈值。您还可以分析历史数据以确定应用程序工作负载的预期基准延迟,然后相应地调整阈值。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

维度: ApiName、Stage、Resource、Method

警报描述: 此警报会检测阶段中资源和方法的高延迟。确定 IntegrationLatency 指标值以检查 API 后端延迟。如果这两个指标基本一致,则 API 后端是导致延迟更高的来源,您应该调查其中是否存在性能问题。另外,请考虑启用 CloudWatch Logs 并检查是否存在任何可能导致高延迟的错误。如果适用,您也可以参阅 如何排查与 Lambda 集成的 API Gateway 请求中的高延迟问题? 如何在 API Gateway 中解决边缘优化的 API 端点中的延迟问题? 指南。

意图: 此警报可以检测阶段中资源和方法的 API Gateway 请求何时具有高延迟。

统计数据: p90

建议阈值: 2500.0

阈值理由: 建议阈值并不适用于所有 API 工作负载。但是,您可以将其用作阈值的起点。然后,您可以根据工作负载以及 API 的可接受延迟、性能和 SLA 要求选择不同的阈值。如果 API 通常可以接受较高的延迟,则可以设置更高的阈值以降低告警的敏感度。但是,如果预计 API 能够提供近乎实时的响应,请设置较低的阈值。您还可以分析历史数据以确定应用程序工作负载的预期基准延迟,然后相应地调整阈值。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

尺寸: ApilD、Stage

警报描述: 此警报会检测阶段中的高延迟。确定 IntegrationLatency 指标值以检查 API 后端延迟。如果这两个指标基本一致,则 API 后端是导致延迟更高的来源,您应该调查其中是否存在性能问题。另外,请考虑启用 CloudWatch Logs 并检查是否存在任何可能导致高延迟的错误。此外,可以考虑启用详细的 CloudWatch 指标,以便按路由查看此指标,并缩小延迟来源的范围。如果适用,您也可以参阅 如何排查与 Lambda 集成的 API Gateway 请求中的高延迟问题? 指南。

意图: 此警报可以检测阶段中的 API Gateway 请求何时具有高延迟。如果您已启用详细的 CloudWatch 指标,并且每个路由的延迟性能要求不同,我们建议您创建备用警报,以便对每个路由的延迟进行更精细的监控。

统计数据: p90

建议阈值: 2500.0

阈值理由: 建议阈值并不适用于所有 API 工作负载。但是,您可以将其用作阈值的起点。然后,您可以根据工作负载以及 API 的可接受延迟、性能和 SLA 要求选择不同的阈值。如果 API 通常可以接受较高的延迟,则可以设置更高的阈值以降低其敏感度。但是,如果 API 预期会提供近乎实时的响应,请设置较低的阈值。您还可以分析历史数据以确定应用程序工作负载的预期基准延迟,然后相应地调整阈值。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

维度: ApiId、Stage、Resource、Method

警报描述: 此警报会检测阶段中路由的高延迟。确定 IntegrationLatency 指标值以检查 API 后端延迟。如果这两个指标基本一致,则 API 后端是导致延迟更高的来源,您应该调查其中是否存在性能问题。另外,请考虑启用 CloudWatch Logs 并检查是否存在任何可能导致高延迟的错误。如果适用,您也可以参阅 如何排查与 Lambda 集成的 API Gateway 请求中的高延迟问题? 指南。

意图: 此警报用于检测阶段中路由的 API Gateway 请求何时具有高延迟。

统计数据: p90

建议阈值: 2500.0

阈值理由: 建议阈值并不适用于所有 API 工作负载。但是,您可以将其用作阈值的起点。然后,您可以根据工作负载以及 API 的可接受延迟、性能和 SLA 要求选择不同的阈值。如果 API 通常可以接受较高的延迟,则可以设置更高的阈值以降低告警的敏感度。但是,如果预计 API 能够提供近乎实时的响应,请设置较低的阈值。您还可以分析历史数据以确定应用程序工作负载的预期基准延迟,然后相应地调整阈值。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

尺寸: ApilD、Stage

警报描述: 此警报会检测高客户端错误率。这可能表明授权或客户端请求参数存在问题。这也可能意味着路由已被删除,或者客户端正在请求一个 API 中不存在的资源。请考虑启用 CloudWatch Logs 并检查是否存在任何可能导致 4xx 错误的错误。此外,可以考虑启用详细的 CloudWatch 指标,以便按路由查看此指标,帮助您缩小错误来源的范围。超出配置的节流限制也可能导致错误。如果响应和日志报告的 429 错误率很高且出人意料,请按照 本指南 排查此问题。

意图: 此警报可以检测 API Gateway 请求的高客户端错误率。

统计数据: 平均值

建议阈值: 0.05

阈值理由: 建议阈值会检测何时总请求数中超过 5% 的请求会收到 4xx 错误。但是,您可以调整阈值以适应请求的流量以及可接受的错误率。您还可以分析历史数据以确定应用程序工作负载的可接受错误率,然后相应地调整阈值。需要对经常发生的 4xx 错误发出警报。但是,将阈值设置得非常低可能会导致警报过于敏感。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

尺寸: ApilD、Stage

警报描述: 此警报有助于检测高客户端错误率。这可能表明 API 后端、网络或 API 网关与后端 API 之间的集成存在问题。本 文档 可以帮助您排查 5xx 错误的原因。

意图: 此警报可以检测 API Gateway 请求的高服务器端错误率。

统计数据: 平均值

建议阈值: 0.05

阈值理由: 建议阈值会检测何时总请求数中超过 5% 的请求会收到 5xx 错误。但是,您可以调整阈值以适应请求的流量以及可接受的错误率。您还可以分析历史数据以确定应用程序工作负载的可接受错误率,然后相应地调整阈值。需要对经常发生的 5xx 错误发出警报。但是,将阈值设置得非常低可能会导致警报过于敏感。

时间段: 60

要发出警报的数据点数 :3

评估期: 3

比较运算符: GREATER_THAN_THRESHOLD

MessageCount

尺寸: ApilD、Stage

警报描述: 此警报有助于检测 WebSocket API 阶段的低流量。这可能表示客户端调用 API 时存在问题(例如使用不正确的端点),或者后端向客户端发送消息时存在问题。这也可能表明 API 的配置或权限存在问题,导致客户端无法访问它。

意图: 此警报可检测 WebSocket API 阶段的意外低流量。如果您的 API 在正常条件下收到并发送数量可预测且一致的消息,我们建议您创建此警报。如果您已启用详细的 CloudWatch 指标,并且可以预测每个路由的正常流量,最好为此创建备用警报,以便对每个路由的流量下降进行更精细的监控。对于预计流量不稳定的 API,不建议使用此警报。

统计数据: SampleCount

建议阈值: 取决于您的情况

阈值理由: 根据历史数据分析设置阈值,以确定您的 API 的预期基准消息计数是多少。将阈值设置为非常高的值,可能会导致警报在正常流量和预期较低流量的时间段过于敏感。相反,将其设置为非常低的值可能会导致警报错过流量异常小的下降。

时间段: 60

要发出警报的数据点数 :10

评估期: 10

比较运算符: LESS_THAN_THRESHOLD

MessageCount

维度: Apild、Stage、Route

警报描述: 此警报有助于检测阶段中 WebSocket API 路由的低流量。这可能表示客户端调用 API 时存在问题(例如使用不正确的端点),或者后端向客户端发送消息时存在问题。这也可能表明 API 的配置或权限存在问题,导致客户端无法访问它。

意图: 此警报可检测阶段中 WebSocket API 路由的意外低流量。如果您的 API 在正常条件下收到并发送数量可预测且一致的消息,我们建议您创建此警报。对于预计流量不稳定的 API,不建议使用此警报。

统计数据: SampleCount

建议阈值: 取决于您的情况

阈值理由: 根据历史数据分析设置阈值,以确定您的 API 的预期基准消息计数是多少。将阈值设置为非常高的值,可能会导致警报在正常流量和预期较低流量的时间段过于敏感。相反,将其设置为非常低的值可能会导致警报错过流量异常小的下降。

时间段: 60

要发出警报的数据点数 :10

评估期: 10

比较运算符: LESS_THAN_THRESHOLD

ClientError

尺寸: ApilD、Stage

警报描述: 此警报会检测高客户端错误率。这可能表示授权或消息参数存在问题。这也可能意味着路由已被删除,或者客户端正在请求一个 API 中不存在的资源。请考虑启用 CloudWatch Logs 并检查是否存在任何可能导致 4xx 错误的错误。此外,可以考虑启用详细的 CloudWatch 指标,以便按路由查看此指标,帮助您缩小错误来源的范围。超出配置的节流限制也可能导致错误。如果响应和日志报告的 429 错误率很高且出人意料,请按照 本指南 排查此问题。

意图: 此警报可以检测 WebSocket API Gateway 消息的高客户端错误率。

统计数据: 平均值

建议阈值: 0.05

阈值理由: 建议阈值会检测何时总请求数中超过 5% 的请求会收到 4xx 错误。您可以调整阈值以适应请求的流量以及可接受的错误率。您还可以分析历史数据以确定应用程序工作负载的可接受错误率,然后相应地调整阈值。需要对经常发生的 4xx 错误发出警报。但是,将阈值设置得非常低可能会导致警报过于敏感。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

ExecutionError

尺寸: ApilD、Stage

警报描述: 此警报有助于检测高执行错误率。这可能是由于您的集成出现 5xx 错误、权限问题或其他阻碍成功调用集成的因素(例如集成受限制或遭删除)所致。请考虑为您的 API 启用 CloudWatch Logs,并检查日志以了解错误的类型和原因。此外,可以考虑启用详细的 CloudWatch 指标,以便按路由查看此指标,帮助您缩小错误来源的范围。本 文档 可以帮助您排查任何连接错误的原因。

意图: 此警报可以检测 WebSocket API Gateway 消息的高执行错误率。

统计数据: 平均值

建议阈值: 0.05

阈值理由: 建议阈值会检测何时总请求数中超过 5% 的请求会收到执行错误。您可以调整阈值以适应请求的流量以及可接受的错误率。您可以分析历史数据以确定应用程序工作负载的可接受错误率,然后相应地调整阈值。需要对经常发生的执行错误发出警报。但是,将阈值设置得非常低可能会导致警报过于敏感。

时间段: 60

要发出警报的数据点数 :3

评估期: 3

比较运算符: GREATER_THAN_THRESHOLD

Amazon EC2 Auto Scaling

维度: AutoScalingGroupName

警报描述: 此警报有助于检测组中的容量何时低于工作负载所需的容量。要排查问题,请检查您的扩展活动是否存在启动失败,并确认所需的容量配置是否正确。

意图: 此警报可以检测由于启动失败或暂停而导致的自动扩缩组中的低可用性。

统计数据: 平均值

建议阈值: 取决于您的情况

阈值理由: 阈值应为运行工作负载所需的最低容量。在大多数情况下,您可以将其设置为与 GroupDesiredCapicity 指标相匹配。

时间段: 60

要发出警报的数据点数 :10

评估期: 10

比较运算符: LESS_THAN_THRESHOLD

Amazon CloudFront

维度: DistributionId、Region=Global

警报描述: 此警报会监控来自您的原始服务器的 5xx 错误响应百分比,帮助您检测 CloudFront 服务是否存在问题。有关帮助您了解服务器问题的信息,请参阅 对来自源的错误响应进行故障排除 。此外, 开启其他指标 可获取详细的错误指标。

意图: 此警报用于检测处理来自原始服务器的请求时出现的问题,或者 CloudFront 与原始服务器之间的通信问题。

统计数据: 平均值

建议阈值: 取决于您的情况

阈值理由: 此警报的建议阈值在很大程度上取决于对 5xx 响应的容忍度。您可以分析历史数据和趋势,然后相应地设置阈值。由于 5xx 错误可能由暂时性问题引起,我们建议您将阈值设置为大于 0 的值,这样警报就不会过于敏感。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

OriginLatency

维度: DistributionId、Region=Global

警报描述: 此警报有助于监控原始服务器的响应时间是否过长。如果服务器响应时间过长,则可能会导致超时。如果您持续遇到高 OriginLatency 值的问题,请参阅 查找并修复原始服务器上来自应用程序的延迟响应

意图: 此警报用于检测原始服务器响应时间过长的问题。

统计数据: p90

建议阈值: 取决于您的情况

阈值理由: 您应计算原始响应超时大约 80% 的值,并将结果用作阈值。如果此指标持续接近源响应超时值,则您可能会开始遇到 504 错误。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

FunctionValidationErrors

维度: DistributionId、FunctionName、Region=Global

警报描述: 此警报可帮助您监控 CloudFront Functions 中的验证错误,以便您可以采取措施解决它们。分析 CloudWatch 函数日志并查看函数代码,找出问题的根本原因并予以解决。要了解 CloudFront Functions 的常见配置错误,请参阅 边缘函数的限制

意图: 此警报用于检测 CloudFront Functions 中的验证错误。

统计数据: Sum

建议阈值: 0.0

阈值理由: 值大于 0 表示验证错误。我们建议将阈值设置为 0,因为验证错误意味着 CloudFront Functions 交回给 CloudFront 时出现问题。例如,CloudFront 需要 HTTP 主机标头才能处理请求。没有什么可以阻止用户删除其 CloudFront Functions 代码中的主机标头。但是,当 CloudFront 返回响应并且主机标头丢失时,CloudFront 会引发验证错误。

时间段: 60

要发出警报的数据点数 :2

评估期: 2

比较运算符: GREATER_THAN_THRESHOLD

FunctionExecutionErrors

维度: DistributionId、FunctionName、Region=Global

警报描述: 此警报可帮助您监控 CloudFront Functions 中的执行错误,以便您可以采取措施解决它们。分析 CloudWatch 函数日志并查看函数代码,找出问题的根本原因并予以解决。

意图: 此警报用于检测 CloudFront Functions 中的执行错误。

统计数据: Sum

建议阈值: 0.0

阈值理由: 我们建议将阈值设置为 0,因为执行错误表示运行时系统代码有问题。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

FunctionThrottles

维度: DistributionId、FunctionName、Region=Global

警报描述: 此警报可帮助您监控您的 CloudFront 函数是否受到限制。如果您的函数受到限制,则意味着其执行时间太长。为避免函数限制,请考虑优化函数代码。

意图: 此警报可以检测您的 CloudFront 函数何时会受到限制,以便您可以作出反应并解决问题,从而提供流畅的客户体验。

统计数据: Sum

建议阈值: 0.0

阈值理由: 我们建议将阈值设置为 0,以便更快地解决函数限制。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

Amazon Cognito

维度: UserPool、UserPoolClient

警报描述: 此警报会监控受限请求的数量。如果用户持续受到限制,则应通过请求增加服务限额来提高限制。要了解如何请求增加限额,请参阅 Amazon Cognito 中的限额 。要主动执行操作,请考虑跟踪 使用限额

意图: 此警报有助于监控受限注册请求的发生情况。这可以帮助您了解何时该执行操作来缓解注册体验的恶化。持续的限制请求会带来较差的用户注册体验。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 预置良好的用户群体不应遇到跨越多个数据点的任何限制。因此,预期工作负载的典型阈值应为 0。对于具有频繁突发的不规则工作负载,您可以分析历史数据以确定应用程序工作负载的可接受限制,然后可以相应地调整阈值。应重试受限请求,最大限度地减少对应用程序的影响。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

SignInThrottles

维度: UserPool、UserPoolClient

警报描述: 此警报会监控受限用户身份验证请求的计数。如果用户持续受到限制,您可能需要通过请求增加服务限额来提高限制。要了解如何请求增加限额,请参阅 Amazon Cognito 中的限额 。要主动执行操作,请考虑跟踪 使用限额

意图: 此警报有助于监控受限登录请求的发生情况。这可以帮助您了解何时该执行操作来缓解登录体验的恶化。持续的限制请求会带来糟糕的用户身份验证体验。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 预置良好的用户群体不应遇到跨越多个数据点的任何限制。因此,预期工作负载的典型阈值应为 0。对于具有频繁突发的不规则工作负载,您可以分析历史数据以确定应用程序工作负载的可接受限制,然后可以相应地调整阈值。应重试受限请求,最大限度地减少对应用程序的影响。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

TokenRefreshTrott

维度: UserPool、UserPoolClient

警报描述: 您可以设置阈值以适应请求的流量,并为令牌刷新请求匹配可接受限制。限制用于保护您的系统不会收到过多请求。但是,请务必监控您的正常流量是否也预置不足。您可以分析历史数据以确定应用程序工作负载的可接受限制,然后可以将警报阈值调整为高于可接受限制级别。受限请求应由应用程序/服务重试,因为它们是暂时性的。因此,非常低的阈值可能会导致警报过于敏感。

意图: 此警报有助于监控受限令牌刷新请求的发生情况。这可以帮助您了解何时该执行操作来缓解任何潜在问题,从而确保流畅的用户体验以及身份验证系统的正常运行和可靠性。持续的限制请求会带来糟糕的用户身份验证体验。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 也可以设置/调整阈值,以适应请求的流量以及令牌刷新请求的可接受限制。限制是为了保护您的系统不会收到过多请求,不过,请务必监控您的正常流量是否也预置不足,并查看是否此情况是否造成了影响。还可以分析历史数据以了解应用程序工作负载的可接受限制,然后可以将阈值调整为高于一般可接受限制级别。受限请求应由应用程序/服务重试,因为它们是暂时性的。因此,非常低的阈值可能会导致警报过于敏感。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

FederationThrottles

维度: UserPool、UserPoolClient、IdentityProvider

警报描述: 此警报会监控受限身份联合验证请求的计数。如果您持续受到限制,则表示您需要通过请求增加服务限额来提高限制。要了解如何请求增加限额,请参阅 Amazon Cognito 中的限额

意图: 此警报有助于监控受限身份联合验证请求的发生情况。这可以帮助您主动应对性能瓶颈或配置错误,并确保您的用户获得流畅的身份验证体验。持续的限制请求会带来糟糕的用户身份验证体验。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 您可以设置阈值以适应请求的流量,并为身份联合验证请求匹配可接受限制。限制用于保护您的系统不会收到过多请求。但是,请务必监控您的正常流量是否也预置不足。您可以分析历史数据以确定应用程序工作负载的可接受限制,然后将阈值调整为高于可接受限制级别的值。受限请求应由应用程序/服务重试,因为它们是暂时性的。因此,非常低的阈值可能会导致警报过于敏感。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

Container Insights

我们建议为发送到 CloudWatch Container Insights 的以下 Amazon EKS 指标设置最佳实践警报。

维度: ClusterName

警报描述: 此警报有助于检测 EKS 集群的 Worker 节点中的高 CPU 利用率。如果利用率一直很高,则可能表明需要将 Worker 节点替换为具有更高 CPU 的实例,或者需要横向扩展系统。

意图: 此警报有助于监控 EKS 集群中 Worker 节点的 CPU 利用率,这样系统性能就不会降低。

统计数据: Maximum

建议阈值: 80.0

阈值理由: 建议将阈值设置为小于或等于 80%,以便有足够的时间在系统开始受到影响之前调试问题。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

node_filesystem_utilization

维度: ClusterName

警报描述: 此警报有助于检测 EKS 集群的 Worker 节点中的高文件系统利用率。如果利用率一直很高,则可能需要更新 Worker 节点以拥有更大的磁盘卷,或者可能需要横向扩展。

意图: 此警报有助于监控 EKS 集群中 Worker 节点的文件系统利用率。如果利用率达到 100%,则可能导致应用程序故障、磁盘 I/O 瓶颈、容器组(pod)驱逐或节点完全无响应。

统计数据: Maximum

建议阈值: 取决于您的情况

阈值理由: 如果有足够的磁盘压力(这意味着磁盘将满),则节点将被标记为运行状况不佳,容器组(pod)将被驱逐出节点。当可用文件系统低于 kubelet 上设置的驱逐阈值时,有磁盘压力的节点上的容器组(pod)将被驱逐。设置警报阈值,以便您在节点被驱逐出集群之前有足够的时间作出反应。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

node_memory_utilization

维度: ClusterName

警报描述: 此警报有助于检测 EKS 集群的 Worker 节点中的高内存利用率。如果利用率一直很高,则可能表明需要扩展容器组(pod)副本的数量或优化您的应用程序。

意图: 此警报有助于监控 EKS 集群中 Worker 节点的内存利用率,这样系统性能就不会降低。

统计数据: Maximum

建议阈值: 80.0

阈值理由: 建议将阈值设置为小于或等于 80%,以便有足够的时间在系统开始受到影响之前调试问题。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

pod_cpu_utilization_over_pod_limit

维度: ClusterName、Namespace、Service

警报描述: 此警报有助于检测 EKS 集群的容器组(pod)中的高 CPU 利用率。如果利用率一直很高,则可能表明需要增加受影响容器组(pod)的 CPU 限制。

意图: 此警报有助于监控 EKS 集群中属于 Kubernetes 服务的容器组(pod)的 CPU 利用率,以便您可以快速识别服务的容器组(pod)占用的 CPU 是否高于预期。

统计数据: Maximum

建议阈值: 80.0

阈值理由: 建议将阈值设置为小于或等于 80%,以便有足够的时间在系统开始受到影响之前调试问题。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

pod_memory_utilization_over_pod_limit

维度: ClusterName、Namespace、Service

警报描述: 此警报有助于检测 EKS 集群的容器组(pod)中的高内存利用率。如果利用率一直很高,则可能表明需要增加受影响容器组(pod)的内存限制。

意图: 此警报有助于监控 EKS 集群中容器组(pod)的内存利用率,这样系统性能就不会降低。

统计数据: Maximum

建议阈值: 80.0

阈值理由: 建议将阈值设置为小于或等于 80%,以便有足够的时间在系统开始受到影响之前调试问题。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

Amazon DynamoDB

维度: None

警报描述: 此警报会检测账户的读取容量是否将达到其预置限制。如果发生这种情况,您可以提高读取容量利用率的账户限额。您可以使用 服务限额 查看读取容量单位的当前限额,并请求增加限额。

意图: 此警报可以检测账户的读取容量利用率是否接近其预置读取容量利用率。如果利用率达到最大限制,DynamoDB 会开始限制读取请求。

统计数据: Maximum

建议阈值: 80.0

阈值理由: 将阈值设置为 80%,这样就可以在阈值达到最大容量之前执行操作(例如提高账户限制),以避免限制。

时间段: 300

要发出警报的数据点数 :2

评估期: 2

比较运算符: GREATER_THAN_THRESHOLD

AccountProvisionedWriteCapacityUtilization

维度: None

警报描述: 此警报会检测账户的写入容量是否将达到其预置限制。如果发生这种情况,您可以提高写入容量利用率的账户限额。您可以使用 服务限额 查看写入容量单位的当前限额,并请求增加限额。

意图: 此警报可以检测账户的写入容量利用率是否接近其预置写入容量利用率。如果利用率达到最大限制,DynamoDB 会开始限制写入请求。

统计数据: Maximum

建议阈值: 80.0

阈值理由: 将阈值设置为 80%,这样就可以在阈值达到最大容量之前执行操作(例如提高账户限制),以避免限制。

时间段: 300

要发出警报的数据点数 :2

评估期: 2

比较运算符: GREATER_THAN_THRESHOLD

AgeOfOldestUnreplicatedRecord

维度: TableName、DelegatedOperation

警报描述: 此警报会检测复制到 Kinesis 数据流过程中的延迟。在正常运行情况下, AgeOfOldestUnreplicatedRecord 应该只有几毫秒。根据由客户控制的配置选项造成的失败复制尝试次数,此数量会增加。例如,可能导致复制尝试失败的客户控制配置包括:预置不足的 Kinesis 数据流容量导致过度限制,或者手动更新 Kinesis 数据流的访问策略会阻止 DynamoDB 向数据流添加数据。为将此指标保持在尽可能低的水平,您需要确保预置合适的 Kinesis 数据流容量,并确保未更改 DynamoDB 的权限。

意图: 此警报可以监控失败复制尝试次数,以及由此导致的复制到 Kinesis 数据流过程中的延迟。

统计数据: Maximum

建议阈值: 取决于您的情况

阈值理由: 根据以毫秒为单位的所需复制延迟设置阈值。此值取决于您的工作负载要求和预期性能。

时间段: 300

要发出警报的数据点数 :3

评估期: 3

比较运算符: GREATER_THAN_THRESHOLD

FailedToReplicateRecordCount

维度: TableName、DelegatedOperation

警报描述: 此警报会检测 DynamoDB 无法复制到 Kinesis 数据流的记录数。某些大于 34KB 的项目可能会扩增,以更改大于 Kinesis Data Streams 1MB 项目大小限制的数据记录。当大于 34KB 的项目包含大量布尔值或空属性值时,就会出现此扩增现象。布尔值和空属性值在 DynamoDB 中存储为 1 个字节,但在使用标准 JSON 进行 Kinesis Data Streams 复制时,最多可扩展到 5 个字节。DynamoDB 无法将此类更改记录复制到 Kinesis 数据流中。DynamoDB 跳过这些更改数据记录,并自动继续复制后续记录。

意图: 此警报可以监控由于 Kinesis 数据流的项目大小限制,DynamoDB 无法复制到 Kinesis 数据流的记录数。

统计数据: Sum

建议阈值: 0.0

阈值理由: 将阈值设置为 0,可检测 DynamoDB 未能复制的任何记录。

时间段: 60

要发出警报的数据点数 :1

评估期: 1

比较运算符: GREATER_THAN_THRESHOLD

ReadThrottleEvents

维度: TableName

警报描述: 此警报可检测 DynamoDB 表是否有大量读取请求受到限制。要解决此问题,请参阅 解决 Amazon DynamoDB 中的限制问题

意图: 此警报可以检测对 DynamoDB 表的读取请求的持续限制。持续限制读取请求会对您的工作负载读取操作产生负面影响,并降低系统的整体效率。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 根据 DynamoDB 表的预期读取流量设置阈值,同时考虑可接受的限制级别。请务必监控您的预置是否不足并且不会导致持续的限制。您还可以分析历史数据以确定应用程序工作负载的可接受限制级别,然后将警报阈值调整为高于一般限制级别。受限请求应由应用程序/服务重试,因为它们是暂时性的。因此,阈值过低可能会导致警报过于敏感,从而导致不必要的状态转换。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

ReadThrottleEvents

维度 :TableName、GlobalSecondaryIndexName

警报描述: 此警报可检测 DynamoDB 表的全局二级索引是否有大量读取请求受到限制。要解决此问题,请参阅 解决 Amazon DynamoDB 中的限制问题

意图: 此警报可以检测对 DynamoDB 表的全局二级索引读取请求的持续限制。持续限制读取请求会对您的工作负载读取操作产生负面影响,并降低系统的整体效率。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 根据 DynamoDB 表的预期读取流量设置阈值,同时考虑可接受的限制级别。请务必监控您的预置是否不足并且不会导致持续的限制。您还可以分析历史数据以确定应用程序工作负载的可接受限制级别,然后将阈值调整为高于一般可接受限制级别。受限请求应由应用程序/服务重试,因为它们是暂时性的。因此,阈值过低可能会导致警报过于敏感,从而导致不必要的状态转换。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

ReplicationLatency

维度: TableName、ReceivingRegion

警报描述: 此警报会检测全局表某个区域中的副本是否滞后于源区域。如果 AWS 区域降级,并且您在该区域有一个副本表,则延迟可能会增加。在这种情况下,可以临时将应用程序的读取和写入活动重定向到不同的 AWS 区域。如果您使用的是 2017.11.29(旧版)的全局表,则应验证每个副本表的写入容量单位(WCU)是否相同。您也可以确保遵循 Best practices and requirements for managing capacity 中的建议。

意图: 此警报可以检测一个区域中的副本表是否落后于从另一个区域复制更改。这可能会导致您的副本与其他副本不同。了解每个 AWS 区域的复制延迟,并在该复制延迟持续增加时发出提醒会很有帮助。表的复制仅适用于全局表。

统计数据: 平均值

建议阈值: 取决于您的情况

阈值理由: 此警报的建议阈值在很大程度上取决于您的用例。超过 3 分钟的复制延迟通常都需要调查。查看复制延迟的临界程度和要求并分析历史趋势,然后相应地选择阈值。

时间段: 60

要发出警报的数据点数 :15

评估期: 15

比较运算符: GREATER_THAN_THRESHOLD

SuccessfulRequestLatency

维度: TableName、Operation

警报描述: 此警报会检测 DynamoDB 表操作的高延迟(由警报中 Operation 的维度值表示)。请参阅 此问题排查文档 ,了解如何排查 Amazon DynamoDB 中的延迟问题。

意图: 此警报可以检测 DynamoDB 表操作的高延迟。操作的较高延迟会对系统的整体效率产生负面影响。

统计数据: 平均值

建议阈值: 取决于您的情况

阈值理由: DynamoDB 会为单例操作(例如 getItem、PutiTem 等)提供平均个位数毫秒延迟。但是,您可以根据工作负载中涉及的操作类型和表的可接受延迟容差来设置阈值。您可以分析此指标的历史数据以确定表操作的一般延迟,然后将阈值设置为代表操作的临界延迟的数字。

时间段: 60

要发出警报的数据点数 :10

评估期: 10

比较运算符: GREATER_THAN_THRESHOLD

SystemErrors

维度: TableName

警报描述: 此警报会检测 DynamoDB 表请求的持续大量系统错误。如果您持续收到 5xx 错误,请打开 AWS 服务运行状况控制面板 ,以检查服务是否存在操作问题。如果 DynamoDB 持续存在内部服务问题,您可以使用此警报来获取通知,它可以帮助您弄清楚您的客户端应用程序面临的问题。有关更多信息,请参阅 DynamoDB 错误处理

意图: 此警报可以检测 DynamoDB 表请求的持续系统错误。系统错误表示 DynamoDB 中的内部服务错误,有助于您弄清楚客户端遇到的问题。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 根据预期流量设置阈值,同时考虑系统错误的可接受级别。您还可以分析历史数据以确定应用程序工作负载的可接受错误计数,然后相应地调整阈值。系统错误应由应用程序/服务重试,因为它们是暂时性的。因此,阈值过低可能会导致警报过于敏感,从而导致不必要的状态转换。

时间段: 60

要发出警报的数据点数 :15

评估期: 15

比较运算符: GREATER_THAN_THRESHOLD

ThrottledPutRecordCount

维度: TableName、DelegatedOperation

警报描述: 此警报会检测在将更改数据捕获复制到 Kinesis 的过程中,您的 Kinesis 数据流限制的记录。出现此限制的原因是 Kinesis 数据流容量不足。如果遇到过多和定期的限制,则可能需要按照观察到的表写入吞吐量成比例增加 Kinesis 流分片数量。要了解有关如何确定 Kinesis 数据流的大小的详细信息,请参阅 确定 Kinesis Data Streams 的初始大小

意图: 此警报可以监控由于 Kinesis 数据流容量不足而受到 Kinesis 数据流限制的记录数量。

统计数据: Maximum

建议阈值: 取决于您的情况

阈值理由: 异常使用高峰期间可能会遇到一些限制,但受限记录应保持在尽可能低的水平,以避免较高的复制延迟(DynamoDB 重试将受限记录发送到 Kinesis 数据流)。将阈值设置为一个数字,这样可以帮助您发现常规过度限制。您还可以分析此指标的历史数据,以确定应用程序工作负载的可接受限制速率。根据您的用例将阈值调整为应用程序可以容忍的值。

时间段: 60

要发出警报的数据点数 :10

评估期: 10

比较运算符: GREATER_THAN_THRESHOLD

UserErrors

维度: None

警报描述: 此警报会检测 DynamoDB 表请求的持续大量用户错误。您可以在问题时间范围内查看客户端应用程序日志,了解请求无效的原因。您可以检查 HTTP 状态码 400 ,查看您收到的错误类型并执行相应操作。您可能必须修复应用程序逻辑才能创建有效的请求。

意图: 此警报可以检测 DynamoDB 表请求的持续用户错误。所请求操作的用户错误表示客户端在生成无效请求并且正在失败。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 将阈值设置为 0 可检测任何客户端错误。或者,如果要避免因错误数量非常少而触发警报,可以将其设置为更高的值。基于您的用例和请求的流量来决定。

时间段: 60

要发出警报的数据点数 :10

评估期: 10

比较运算符: GREATER_THAN_THRESHOLD

WriteThrottleEvents

维度: TableName

警报描述: 此警报可检测 DynamoDB 表是否有大量写入请求受到限制。要解决此问题,请参阅 解决 Amazon DynamoDB 中的限制问题

意图: 此警报可以检测 DynamoDB 表的写入请求的持续限制。持续限制写入请求会对您的工作负载写入操作产生负面影响,并降低系统的整体效率。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 根据 DynamoDB 表的预期写入流量设置阈值,同时考虑可接受的限制级别。请务必监控您的预置是否不足并且不会导致持续的限制。您还可以分析历史数据以确定应用程序工作负载的可接受限制级别,然后将阈值调整为高于一般可接受限制级别的值。受限请求应由应用程序/服务重试,因为它们是暂时性的。因此,阈值过低可能会导致警报过于敏感,从而导致不必要的状态转换。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

WriteThrottleEvents

维度 :TableName、GlobalSecondaryIndexName

警报描述: 此警报可检测 DynamoDB 表的全局二级索引是否有大量写入请求受到限制。要解决此问题,请参阅 解决 Amazon DynamoDB 中的限制问题

意图: 此警报可以检测对 DynamoDB 表全局二级索引的写入请求的持续限制。持续限制写入请求会对您的工作负载写入操作产生负面影响,并降低系统的整体效率。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 根据 DynamoDB 表的预期写入流量设置阈值,同时考虑可接受的限制级别。请务必监控您的预置是否不足并且不会导致持续的限制。您还可以分析历史数据以确定应用程序工作负载的可接受限制级别,然后将阈值调整为高于一般可接受限制级别的值。受限请求应由应用程序/服务重试,因为它们是暂时性的。因此,值过低可能会导致警报过于敏感,从而导致不必要的状态转换。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

Amazon EC2

维度: InstanceId

警报描述: 此警报有助于监控 EC2 实例的 CPU 利用率。根据应用程序的不同,持续的高利用率级别可能是正常的。但是,如果性能下降,并且应用程序不受磁盘 I/O、内存或网络资源的限制,则达到极限的 CPU 可能表示存在资源瓶颈或应用程序性能问题。高 CPU 利用率可能表示需要升级到 CPU 密集型实例。如果启用了详细监控,则可以将时间段更改为 60 秒而不是 300 秒。有关更多信息,请参阅 对实例启用或禁用详细监控

意图: 此警报用于检测高 CPU 利用率。

统计数据: 平均值

建议阈值: 80.0

阈值理由: 通常,您可以将 CPU 利用率的阈值设置为 70-80%。但是,您可以根据可接受性能级别和工作负载特征来调整此值。对于某些系统,持续的高 CPU 利用率可能是正常现象,并不表示存在问题,而对于某些系统,此情况应引起注意。分析历史 CPU 利用率数据以确定使用情况,弄清您系统的可接受 CPU 利用率,并相应地设置阈值。

时间段: 300

要发出警报的数据点数 :3

评估期: 3

比较运算符: GREATER_THAN_THRESHOLD

StatusCheckFailed

维度: InstanceId

警报描述: 此警报有助于监控系统状态检查和实例状态检查。如果任一类型的状态检查失败,则此警报应处于“ALARM”状态。

意图: 此警报用于检测实例的根本问题,包括系统状态检查失败和实例状态检查失败。

统计数据: Maximum

建议阈值: 1.0

阈值理由: 当状态检查失败时,此指标的值为 1。设置阈值后,每当状态检查失败时,警报都将处于“ALARM”状态。

时间段: 300

要发出警报的数据点数 :2

评估期: 2

比较运算符: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Amazon ElastiCache

维度: CacheClusterId、CacheNodeId

警报描述: 此警报有助于监控整个 ElastiCache 实例的 CPU 利用率,包括数据库引擎进程和实例上运行的其他进程。AWSElasticache 支持两种引擎类型:Memcached 和 Redis。当您在 Memcached 节点上达到高 CPU 利用率时,应考虑纵向扩展实例类型或添加新的缓存节点。对于 Redis,如果您的主要工作负载来自读取请求,则应考虑向缓存集群添加更多只读副本。如果您的主要工作负载来自写入请求,则要在集群模式下运行时,应考虑添加更多分片以将工作负载分配到更多主节点;而要非集群模式下运行 Redis 时,应考虑纵向扩展实例类型。

意图: 此警报用于检测 ElastiCache 主机的高 CPU 利用率。这对全面了解整个实例(包括非引擎进程)的 CPU 使用情况很有用。

统计数据: 平均值

建议阈值: 取决于您的情况

阈值理由: 将阈值设置为反映应用程序的临界 CPU 利用率级别的百分比。对于 Memcached,引擎最多可以使用 num_threads 个核心。对于 Redis,引擎主要是单线程的,但如果有额外核心,也可以使用它们来加速 I/O。在大多数情况下,您可以将阈值设置为可用 CPU 的 90% 左右。因为 Redis 是单线程的,实际阈值应计算为节点总容量的一小部分。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

CurrConnections

维度: CacheClusterId、CacheNodeId

警报描述: 此警报可检测高连接计数,这可能表示负载过重或存在性能问题。 CurrConnections 的持续增加可能会导致 65000 个可用连接耗尽。这可能表明应用程序端的连接关闭不当,并且在服务器端未断开。您应该考虑使用连接池或空闲连接超时来限制与集群建立的连接数量,或者对于 Redis,可以考虑在集群上调整 tcp-keepalive ,以检测和终止潜在失效对端。

意图: 此警报有助于您识别可能影响 ElastiCache 集群性能和稳定性的高连接计数。

统计数据: 平均值

建议阈值: 取决于您的情况

阈值理由: 此警报的建议阈值在很大程度上取决于集群的可接受连接范围。查看 ElastiCache 集群的容量和预期工作负载,分析常规使用期间的历史连接计数以建立基准,然后相应地选择阈值。请记住,每个节点最多可以支持 65000 个并发连接。

时间段: 60

要发出警报的数据点数 :10

评估期: 10

比较运算符: GREATER_THAN_THRESHOLD

DatabaseMemoryUsagePercentage

维度: CacheClusterId

警报描述: 此警报有助于监控集群的内存利用率。当 DatabaseMemoryUsagePercentage 达到 100% 时,将触发 Redis maxmemory 策略,并且可能会根据所选策略进行驱逐。如果缓存中没有符合驱逐策略的对象,则写入操作将失败。有些工作负载期望或依赖驱逐,如果不是这样,您需要增加集群的内存容量。您可以通过添加更多主节点来横向扩展集群,也可以使用更大的节点类型对其纵向扩展。有关详细信息,请参阅 ElastiCache for Redis 集群的扩缩

意图: 此警报用于检测集群的高内存利用率,以便在写入集群时避免失败。如果您的应用程序预计不会遭遇驱逐,则了解何时需要纵向扩展集群会很有用。

统计数据: 平均值

建议阈值: 取决于您的情况

阈值理由: 根据应用程序的内存要求和 ElastiCache 集群的内存容量,您应将阈值设置为反映集群内存使用量临界水平的百分比。您可以使用历史内存使用数据,作为可接受内存使用量阈值的参考。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

EngineCPUUtilization

维度: CacheClusterId

警报描述: 此警报有助于监控 ElastiCache 实例中 Redis 引擎线程的 CPU 利用率。引擎 CPU 占用率高的常见原因包括:消耗高 CPU 的长时间运行的命令、大量请求、短时间内新的客户端连接请求增加,以及缓存没有足够的内存来容纳新数据时的高驱逐率。您应该考虑通过添加更多节点或纵向扩展实例类型来实现 ElastiCache for Redis 集群的扩缩

意图: 此警报用于检测 Redis 引擎线程的高 CPU 利用率。它在要监控数据库引擎本身的 CPU 利用率时很有用。

统计数据: 平均值

建议阈值: 90.0

阈值理由: 将阈值设置为反映应用程序的临界引擎 CPU 利用率级别的百分比。您可以使用应用程序和预期工作负载对集群进行基准测试,关联 EngineCPUUtilization 和性能作为参考,然后相应地设置阈值。在大多数情况下,您可以将阈值设置为可用 CPU 的 90% 左右。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

ReplicationLag

维度: CacheClusterId

警报描述: 此警报有助于监控您的 ElastiCache 集群的复制运行状况。高复制滞后意味着主节点或副本无法跟上复制的步伐。如果您的写入活动过高,可以考虑通过添加更多主节点来横向扩展集群,或者使用更大的节点类型纵向扩展集群。有关详细信息,请参阅 ElastiCache for Redis 集群的扩缩 。如果您的只读副本因读取请求的数量而过载,可以考虑添加更多只读副本。

意图: 此警报用于检测主节点上的数据更新与其同步到副本节点之间的延迟。它有助于确保只读副本集群节点的数据一致性。

统计数据: 平均值

建议阈值: 取决于您的情况

阈值理由: 根据应用程序的要求和复制滞后的潜在影响来设置阈值。您应该考虑应用程序的预期写入速率和网络条件,以确定可接受的复制滞后。

时间段: 60

要发出警报的数据点数 :15

评估期: 15

比较运算符: GREATER_THAN_THRESHOLD

Amazon EC2 ( AWS/ElasticGPUs )

维度: InstanceId、EGPUId

警报描述: 此警报有助于检测实例与 Elastic Graphics 加速器之间的连接故障。Elastic Graphics 使用实例网络将 OpenGL 命令发送到远程附加的显卡。此外,运行带有 Elastic Graphics 加速器的 OpenGL 应用程序的桌面通常使用远程访问技术来访问。确定性能问题是与 OpenGL 渲染相关还是与桌面远程访问技术相关,这一点非常重要。要了解有关该问题的更多信息,请参阅 调查应用程序性能问题

意图: 此警报用于检测从实例到 Elastic Graphics 加速器的连接问题。

统计数据: Maximum

建议阈值: 0.0

阈值理由: 阈值为 1 表示连接已失败。

时间段: 300

要发出警报的数据点数 :3

评估期: 3

比较运算符: GREATER_THAN_THRESHOLD

GPUHealthCheckFailed

维度: InstanceId、EGPUId

警报描述: 此警报有助于您了解 Elastic Graphics 加速器的状态何时不正常。如果加速器运行状况不佳,请参阅 解决不正常状态问题 中的问题排查步骤。

意图: 此警报用于检测 Elastic Graphics 加速器是否运行状况不佳。

统计数据: Maximum

建议阈值: 0.0

阈值理由: 阈值为 1 表示状态检查失败。

时间段: 300

要发出警报的数据点数 :3

评估期: 3

比较运算符: GREATER_THAN_THRESHOLD

Amazon ECS

维度: ClusterName

警报描述: 此警报有助于您检测 ECS 集群的高 CPU 预留。高 CPU 预留可能表示集群将耗尽为任务注册的 CPU。要排查问题,您可以添加更多容量、扩展集群,也可以设置自动扩缩。

意图: 该警报用于检测集群上任务预留的 CPU 单元总数是否达到为集群注册的 CPU 单位总数。这有助于您了解何时纵向扩展集群。达到集群的 CPU 单位总数可能会导致任务的 CPU 耗尽。如果您开启了 EC2 容量提供商托管式扩展,或者您已将 Fargate 关联到容量提供商,则不建议设置此警报。

统计数据: 平均值

建议阈值: 90.0

阈值理由: 将 CPU 预留阈值设置为 90%。或者,您可以基于集群特征选择较小的值。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

CPU 利用率

维度: ClusterName、ServiceName

警报描述: 此警报有助于您检测 ECS 服务的高 CPU 利用率。如果没有正在进行的 ECS 部署,则达到极限的 CPU 利用率可能表示存在资源瓶颈或应用程序性能问题。要排查问题,可以提高 CPU 限制。

意图: 此警报用于检测 ECS 服务的高 CPU 利用率。持续的高 CPU 利用率可能表示存在资源瓶颈或应用程序性能问题。

统计数据: 平均值

建议阈值: 90.0

阈值理由: CPU 利用率的服务指标可能超过 100% 的利用率。但是,我们建议您监控高 CPU 利用率的指标,避免影响其他服务。将阈值设置为大约 90-95%。我们建议您更新任务定义以反映实际使用量,以防其他服务将来出现问题。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

MemoryReservation

维度: ClusterName

警报描述: 此警报有助于您检测 ECS 集群的高内存预留。高内存预留可能表示集群存在资源瓶颈。要排查问题,请分析服务任务的性能,查看是否可以优化任务的内存利用率。此外,您可以注册更多内存或设置自动扩缩。

意图: 该警报用于检测集群上任务预留的存储单元总数是否达到为集群注册的存储单元总数。这有助于您了解何时纵向扩展集群。达到集群的存储单元总数可能会导致集群无法启动新任务。如果您开启了 EC2 容量提供商托管式扩展,或者您已将 Fargate 关联到容量提供商,则不建议设置此警报。

统计数据: 平均值

建议阈值: 90.0

阈值理由: 将内存预留阈值设置为 90%。您可以基于集群特征将其调整为较小的值。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

HTTPCode_Target_5XX_Count

维度: ClusterName、ServiceName

警报描述: 此警报有助于您检测 ECS 服务的服务器端高错误计数。这可能表示存在导致服务器无法处理请求的错误。要排查问题,请检查您的应用程序日志。

意图: 此警报用于检测 ECS 服务的服务器端高错误计数。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 计算约占平均流量的 5% 的值,并使用该值作为阈值的起点。您可以使用 RequestCount 指标确定平均流量。您还可以分析历史数据以确定应用程序工作负载的可接受错误率,然后相应地调整阈值。需要对经常发生的 5XX 错误发出警报。但是,将阈值设置得非常低可能会导致警报过于敏感。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

TargetResponseTime

维度: ClusterName、ServiceName

警报描述: 此警报有助于您检测 ECS 服务请求的长目标响应时间。这可能表示存在导致服务无法及时处理请求的错误。要排查问题,请检查 CPUUtilization 指标以查看服务是否耗尽了 CPU,或者检查您的服务所依赖的其他下游服务的 CPU 利用率。

意图: 此警报用于检测 ECS 服务请求的长目标响应时间。

统计数据: 平均值

建议阈值: 取决于您的情况

阈值理由: 此警报的建议阈值在很大程度上取决于您的用例。查看服务的目标响应时间的临界程度和要求,并分析此指标的历史行为以确定合理的阈值级别。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

Amazon EFS

维度: FileSystemId

警报描述: 此警报有助于确保工作负载保持在文件系统可用的 I/O 限制范围内。如果指标持续达到其 I/O 限制,可以考虑将应用程序移至使用最大 I/O 性能作为模式的文件系统。要排查问题,请检查连接到文件系统的客户端和限制文件系统之客户端的应用程序。

意图: 此警报用于检测文件系统接近通用性能模式的 I/O 限制的情况。持续的高 I/O 百分比可能表明文件系统无法在 I/O 请求方面进行足够的扩展,并且文件系统可能成为使用该文件系统之应用程序的资源瓶颈。

统计数据: 平均值

建议阈值: 100.0

阈值理由: 当文件系统达到其 I/O 限制时,它对读取和写入请求的响应速度可能会变慢。因此,建议监控该指标,以免影响使用文件系统的应用程序。阈值可以设置为 100% 左右。但是,可根据文件系统特征将此值调整为较低的值。

时间段: 60

要发出警报的数据点数 :15

评估期: 15

比较运算符: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

BurstCreditBalance

维度: FileSystemId

警报描述: 此警报有助于确保文件系统使用量有可用的突增积分余额。当没有可用的突增积分时,由于吞吐量低,应用程序对文件系统的访问将受到限制。如果指标持续降至 0,可以考虑将吞吐量模式更改为 Elastic 或预置吞吐量模式

意图: 此警报用于检测文件系统的低突增积分余额。持续的低突增积分余额可能表明吞吐量降低和 I/O 延迟增加。

统计数据: 平均值

建议阈值: 0.0

阈值理由: 当文件系统耗尽突增积分时,即使基准吞吐率较低,EFS 仍会继续向所有文件系统提供 1MiBps 的计量吞吐量。但是,建议监控指标是否存在低突增积分余额,避免文件系统成为应用程序的资源瓶颈。阈值可以设置为 0 字节左右。

时间段: 60

要发出警报的数据点数 :15

评估期: 15

比较运算符: LESS_THAN_OR_EQUAL_TO_THRESHOLD

Amazon Kinesis Data Streams

维度 :StreamName

警报描述: 此警报可以检测迭代器的最大寿命是否过高。对于实时数据处理应用程序,可以根据延迟容差配置数据留存。这通常只需几分钟就能完成。对于处理历史数据的应用程序,可以使用此指标来监控追赶速度。阻止数据丢失的快速解决方案是在排查问题时延长保留期。您还可以增加在消费端应用程序中处理记录的工作程序数量。逐渐增长迭代器寿命最常见的原因是没有足够的物理资源,或者记录处理逻辑没有随着流吞吐量的增大而相应扩展。有关更多详细信息,请参阅 链接

意图: 此警报用于检测流中的数据是否会因为保存时间过长或记录处理速度太慢而过期。它可以帮助您在达到 100% 的流保留时间后避免数据丢失。

统计数据: Maximum

建议阈值: 取决于您的情况

阈值理由: 此警报的建议阈值在很大程度上取决于流的保留期以及记录的处理延迟容差。查看您的需求并分析历史趋势,然后将阈值设置为表示临界处理延迟的毫秒数。如果迭代器的寿命超过了保留期的 50%(默认值为 24 小时,可配置为最高 365 天),则存在由于记录过期造成数据丢失的风险。您可以监控该指标,确保您的任何分片都不会达到此限制。

时间段: 60

要发出警报的数据点数 :15

评估期: 15

比较运算符: GREATER_THAN_THRESHOLD

GetRecords.Success

维度 :StreamName

警报描述: 每当您的消费端成功从您的流中读取数据时,此指标就会增加。当它引发异常时, GetRecords 不会返回任何数据。最常见的例外情况是 ProvisionedThroughputExceededException ,由于流的请求速率太高,或者因为给定秒钟的可用吞吐量已经得到满足。降低请求的频率或大小。有关更多信息,请参阅《Amazon Kinesis Data Streams 开发人员指南》中的 Streams Limits Error Retries and Exponential Backoff in AWS

意图: 此警报可以检测消费端从流中检索记录是否失败。通过为此指标设置警报,您可以主动检测数据消耗方面的任何问题,例如错误率增加或检索成功率下降。这让您可以及时执行操作来解决潜在问题,并保持数据处理管道的顺畅运行。

统计数据: 平均值

建议阈值: 取决于您的情况

阈值理由: 根据从流中检索记录的重要性,基于应用程序对失败记录的容忍度来设置阈值。阈值应为成功操作的相应百分比。您可以使用历史 GetRecords 指标数据作为可接受失败率的参考。设置阈值时还应考虑重试,因为可以重试失败记录。这有助于防止暂时性峰值触发不必要的提醒。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: LESS_THAN_THRESHOLD

PutRecord.Success

维度 :StreamName

警报描述: 此警报会检测失败的 PutRecord 操作的数量何时超过阈值。调查数据生成器日志,弄清楚失败的根本原因。最常见的原因是导致 ProvisionedThroughputExceededException 的分片的预置吞吐量不足。之所以发生这种情况,是因为流的请求速率太高,或者尝试摄取到分片中的吞吐量太高。降低请求的频率或大小。有关更多信息,请参阅 Streams Limits Error Retries and Exponential Backoff in AWS

意图: 此警报可以检测向流中摄取记录是否失败。它有助于您识别向流写入数据时存在的问题。通过为此指标设置警报,您可以主动检测生成器在向流发布数据时存在的任何问题,例如错误率增加或成功发布的记录减少。这让您可以及时执行操作来解决潜在问题,并保持数据摄取过程的可靠运行。

统计数据: 平均值

建议阈值: 取决于您的情况

阈值理由: 根据对服务进行数据摄取和处理的重要性,基于应用程序对失败记录的容忍度来设置阈值。阈值应为成功操作的相应百分比。您可以使用历史 PutRecord 指标数据作为可接受失败率的参考。设置阈值时还应考虑重试,因为可以重试失败记录。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: LESS_THAN_THRESHOLD

PutRecords.FailedRecords

维度 :StreamName

警报描述: 此警报会检测失败的 PutRecords 的数量何时超过阈值。Kinesis Data Streams 会尝试处理每个 PutRecords 请求中的所有记录,但是单个记录失败并不会停止对后续记录的处理。这些失败的主要原因是超过了流或单个分片的吞吐量。常见的原因是流量激增和网络延迟,这会导致记录不均匀地到达流。您必须检测处理不成功的记录并在后续调用中重试它们。有关更多详细信息,请参阅 Handling Failures When Using PutRecords

意图: 当使用批处理操作将记录放入流时,此警报可以检测持续失败。通过为此指标设置警报,您可以主动检测失败记录的增加,从而能够及时执行操作来解决潜在问题,并确保数据摄取过程顺畅可靠。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 将阈值设置为失败记录数,以反映应用程序对失败记录的容忍度。您可以使用历史数据作为可接受失败值的参考。设置阈值时还应考虑重试,因为可以在后续 PutRecords 调用中重试失败记录。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

ReadProvisionedThroughputExceeded

维度 :StreamName

警报描述: 此警报会跟踪导致读取吞吐能力限制的记录数。如果您发现自己持续受到限制,则应考虑向流中添加更多分片以增加预置读取吞吐量。如果有多个消费端应用程序在流中运行,并且它们共享 GetRecords 限制,我们建议您通过增强型扇出功能注册新的消费端应用程序。如果添加更多分片不会降低限制的数量,则可能有一个“热”分片被读取的次数超过了其他分片。启用增强监控,确定“热”分片,然后将其拆分。

意图: 此警报可以检测消费端在超过预置的读取吞吐量(由您拥有的分片数量决定)时是否受到限制。在这种情况下,您将无法从流中读取内容,并且流可以开始备份。

统计数据: 平均值

建议阈值: 取决于您的情况

阈值理由: 通常可以重试受限请求,因此将阈值设置为 0 会使警报过于敏感。但是,持续的限制可能会影响从流中进行读取,因此应该会触发警报。根据应用程序的限制请求和重试配置,将阈值设置为百分比。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

SubscribeToShardEvent.MillisBehindLatest

维度: StreamName、ConsumerName

警报描述: 此警报会检测应用程序中的记录处理延迟何时超过阈值。诸如对下游应用程序的 API 操作失败之类的暂时性问题可能会导致指标突然增加。您应该调查它们是否持续发生。一个常见的原因是,由于物理资源不足,或者记录处理逻辑没有随着流吞吐量的增加而扩展,导致消费端处理记录的速度不够快。在关键路径中阻止调用通常是导致记录处理速度减慢的原因。您可以通过增加分片的数量来提高并行度。您还应确认底层处理节点在需求高峰期间有足够的物理资源。

意图: 此警报可以检测流分片事件订阅的延迟。这表明存在处理延迟,可以帮助识别消费端应用程序性能或流的整体运行状况的潜在问题。当处理延迟变得严重时,您应该调查并解决任何瓶颈或消费端应用程序效率低下的问题,以确保实时数据处理并最大限度地减少数据积压。

统计数据: 平均值

建议阈值: 取决于您的情况

阈值理由: 此警报的建议阈值在很大程度上取决于您的应用程序可以容忍的延迟。查看应用程序的要求并分析历史趋势,然后相应地选择阈值。当 SubscribeToShard 调用成功后,您的消费端将开始通过持续连接接收 SubscribeToShardEvent 事件,最长可持续 5 分钟,之后如果您想继续接收记录,需要再次调用 SubscribetoShard 来续订订阅。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

WriteProvisionedThroughputExceeded

维度 :StreamName

警报描述: 此警报会检测导致写入吞吐能力限制的记录数何时达到阈值。当您的生成器超过预置写入吞吐量(由您拥有的分片数量决定)时,它们就会受到限制,您将无法将记录放入流中。为了解决持续限制的问题,您应该考虑向流中添加分片。这会提高您的预置写入吞吐量并防止未来发生限制。在摄取记录时,还应考虑分区键的选择。首选随机分区键,因为它会尽可能将记录均匀地分布在流的分片上。

意图: 此警报可以检测您的生成器是否因为流或分片的限制而在写入记录时被拒。如果您的数据流处于预置模式,则设置此警报有助于您在数据流达到限制时主动执行操作,让您可以优化预置容量或执行相应扩展操作,以免数据丢失并保持数据处理的顺畅运行。

统计数据: 平均值

建议阈值: 取决于您的情况

阈值理由: 通常可以重试受限请求,因此将阈值设置为 0 会使警报过于敏感。但是,持续的限制可能会影响写入流的操作,因此您应该设置警报阈值来检测此类限制。根据应用程序的限制请求和重试配置,将阈值设置为百分比。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

Lambda

维度: FunctionName

警报描述: 此警报会检测高错误计数。错误包括代码引发的异常和 Lambda 运行时系统引发的异常。您可以检查与函数相关的日志来诊断问题。

意图: 此警报有助于检测函数调用中的高错误计数。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 将阈值设置为大于 0 的数字。确切的值可取决于对您应用程序中的错误的容忍度。了解函数正在处理之调用的临界程度。对于某些应用程序,任何错误都可能是不可接受的,而某些应用程序可能允许一定的错误幅度。

时间段: 60

要发出警报的数据点数 :3

评估期: 3

比较运算符: GREATER_THAN_THRESHOLD

维度: FunctionName

警报描述: 此警报会检测大量受限调用请求。限制在无并发可用于纵向扩展时发生。有多种方法可解决此问题。1) 向此区域的 AWS Support 请求增加并发。2) 确定函数中的性能问题,以提高处理速度,从而提高吞吐量。3) 增加函数的批处理大小,以便每次函数调用都能处理更多消息。

意图: 此警报有助于检测针对 Lambda 函数的大量受限调用请求。请务必了解请求是否由于限制而持续被拒,以及您是否需要提高 Lambda 函数性能或并发能力以避免持续的限制。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 将阈值设置为大于 0 的数字。阈值的确切值可取决于应用程序的容忍度。根据函数的使用和扩展要求设置阈值。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Duration

维度: FunctionName

警报描述: 此警报会检测 Lambda 函数处理事件的长持续时间。持续时间长可能是因为函数代码的变化使函数的执行时间更长,或者函数的依赖项需要更长的时间。

意图: 此警报可以检测 Lambda 函数的长运行持续时间。运行时系统持续时间长表示函数的调用时间较长,如果 Lambda 处理的事件数量更多,还会影响调用的并发能力。请务必了解 Lambda 函数的执行时间是否持续比预期的要长。

统计数据: p90

建议阈值: 取决于您的情况

阈值理由: 持续时间阈值取决于您的应用程序和工作负载以及您的性能要求。对于高性能要求,可以将阈值设置为更短的时间,以查看函数是否符合预期。您还可以分析持续时间指标的历史数据,查看所花费的时间是否与函数的预期性能相符,然后将阈值设置为比历史平均值更长的时间。确保将阈值设置为低于配置的函数超时。

时间段: 60

要发出警报的数据点数 :15

评估期: 15

比较运算符: GREATER_THAN_THRESHOLD

ConcurrentExecutions

维度: FunctionName

警报描述: 此警报有助于监控函数的并发是否接近账户的区域级并发限制。如果函数达到并发限制,它就会开始受到限制。您可以执行下列操作来避免限制。1) 向此区域的 AWS Support 请求增加并发。2) 确定函数中的性能问题,以提高处理速度,从而提高吞吐量。3) 增加函数的批处理大小,以便每次函数调用都能处理更多消息。

意图: 此警报可以主动检测函数的并发是否接近账户的区域级并发限额,以便您可以视情况采取行动。如果函数达到账户的区域级并发限额,则该函数将受到限制。

统计数据: Maximum

建议阈值: 取决于您的情况

阈值理由: 将阈值设置成为区域中账户设置的并发限额的 90% 左右。默认情况下,您的账户针对区域内所有函数的并发限额为 1000。不过,您可以查看账户的限额,因为可以联系 AWS Support 来增加限额。

时间段: 60

要发出警报的数据点数 :10

评估期: 10

比较运算符: GREATER_THAN_THRESHOLD

Lambda Insights

我们建议为以下 Lambda Insights 指标设置最佳实践警报。

维度: function_name

警报描述: 此警报用于检测 Lambda 函数的内存利用率是否接近配置的限制。要排查问题,您可以尝试 1) 优化您的代码。2) 通过准确估算内存需求来正确调整内存分配的大小。您可以参考 Lambda Power Tuning 了解相同内容。3) 使用连接池。有关 RDS 数据库的连接池的信息,请参阅 Using Amazon RDS Proxy with Lambda 。4) 您也可以考虑设计函数,以免两次调用之间在内存中存储大量数据。

意图: 此警报用于检测 Lambda 函数的内存利用率是否接近配置的限制。

统计数据: 平均值

阈值建议: 90.0

阈值理由: 将阈值设置为 90%,以便在内存利用率超过分配内存的 90% 时收到提醒。如果您担心工作负载的内存利用率,则可以将此阈值调整为较低的值。您也可以查看此指标的历史数据并相应地设置阈值。

时间段: 60

要发出警报的数据点数 :10

评估期: 10

比较运算符: GREATER_THAN_THRESHOLD

Amazon VPC ( AWS/NATGateway )

维度: NatGatewayId

警报描述: 此警报有助于检测 NAT 网关何时无法为新连接分配端口。要解决此问题,请参阅 解决 NAT 网关上的端口分配错误

意图: 此警报用于检测 NAT 网关是否无法分配源端口。

统计数据: Sum

建议阈值: 0.0

阈值理由: 如果 ErrorPortAllocation 的值大于 0,则意味着通过 NatGateway 打开了太多与单个热门目标的并发连接。

时间段: 60

要发出警报的数据点数 :15

评估期: 15

比较运算符: GREATER_THAN_THRESHOLD

PacketsDropCount

维度: NatGatewayId

警报描述: 此警报有助于检测 NAT 网关何时丢弃数据包。这可能是因为 NAT 网关存在问题,因此请检查 AWS 服务运行状况控制面板 ,了解区域中的 AWS NAT 网关的状态。这可以帮助您弄清楚与使用 NAT 网关的流量相关的网络问题。

意图: 此警报用于检测 NAT 网关是否正丢弃数据包。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 您应计算 NAT 网关上总流量 0.01% 的值,并将该结果用作阈值。使用 NAT 网关上流量的历史数据来确定阈值。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

AWS 私有链接 ( AWS/PrivateLinkEndpoints )

维度: VPC Id、VPC Endpoint Id、Endpoint Type、Subnet Id、Service Name

警报描述: 此警报通过监控端点丢弃的数据包数量,帮助检测端点或端点服务是否运行状况不佳。请注意,到达 VPC 端点的大小超过 8500 字节的数据包将被丢弃。要进行问题排查,请参阅 接口 VPC 端点和端点服务之间的连接问题

意图: 此警报用于检测端点或端点服务是否运行状况不佳。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 根据用例设置阈值。如果您想了解端点或端点服务的运行状况不佳状态,应将阈值设置得较低,以便有机会在出现大量数据丢失之前修复问题。您可以使用历史数据来了解对丢弃数据包的容忍度,并相应地设置阈值。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

AWS 私有链接 ( AWS/PrivateLinkServices )

维度: Service Id、Load Balancer Arn、Az

警报描述: 此警报有助于您根据发送到端点之重置数据包的数量来检测端点服务的运行状况不佳目标。当您使用服务的消费端调试连接错误时,可以验证服务是否正在使用 rstPacketsSent 指标重置连接,或者网络路径上是否有其他操作会失败。

意图: 此警报用于检测端点服务运行状况不佳的目标。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 该阈值取决于用例。如果您的用例可以容忍运行状况不佳目标,则可以将阈值设置得较高。如果用例无法容忍运行状况不佳目标,则可以将阈值设置得非常低。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

Amazon Route 53 Public Data Plane

维度: HealthCheckId

警报描述: 此警报有助于根据运行状况检查程序检测运行状况不佳的端点。要了解导致运行状况不佳状态的失败的原因,请使用 Route 53 运行状况检查控制台中的“运行状况检查程序”选项卡,查看每个区域的状态以及上次运行状况检查的失败情况。“状态”选项卡还显示端点被报告为运行状况不佳的原因。请参阅 问题排查步骤

意图: 此警报使用 Route53 运行状况检查程序来检测运状况不佳的端点。

统计数据: 平均值

建议阈值: 1.0

阈值理由: 当端点运行正常时,其状态报告为 1。所有小于 1 的情况都表示运行状况不佳。

时间段: 60

要发出警报的数据点数 :3

评估期: 3

比较运算符: LESS_THAN_THRESHOLD

Amazon S3

维度: BucketName、FilterId

警报描述: 此警报可帮助我们报告为响应客户端请求而发出的 4xx 错误状态代码的总数。例如,403 错误代码可能表示 IAM policy 不正确,404 错误代码可能表示客户端应用程序操作不当。临时 启用 S3 服务器访问日志记录 将帮助您使用 HTTP 状态和错误代码字段查明问题的根源。要了解有关错误代码的更多信息,请参阅 Error Responses

意图: 此告警可用于为典型的 4xx 错误率创建基准,以便您可以调查可能表明存在设置问题的任何异常。

统计数据: 平均值

建议阈值: 0.05

阈值理由: 建议阈值旨在检测是否总请求数中超过 5% 的请求会收到 4XX 错误。应针对频繁发生的 4XX 错误设置告警。但是,将阈值设置得非常低可能会导致告警过于敏感。您还可以调整阈值以适应请求的负载,同时考虑可接受的 4XX 错误级别。您还可以分析历史数据以确定应用程序工作负载的可接受错误率,然后相应地调整阈值。

时间段: 60

要发出警报的数据点数 :15

评估期: 15

比较运算符: GREATER_THAN_THRESHOLD

4xxErrors

维度: AccessPointName、DataSourceARN

警报描述: 此警报可帮助我们报告为响应客户端请求而发出的 4xx 错误状态代码的总数。临时 启用 S3 服务器访问日志记录 将帮助您使用 HTTP 状态和错误代码字段查明问题的根源。

意图: 此告警可用于为典型的 4xx 错误率创建基准,以便您可以调查可能表明存在设置问题的任何异常。

统计数据: 平均值

建议阈值: 0.05

阈值理由: 我们建议设置阈值,以检测是否总请求数中超过 5% 的请求会收到 4xx 错误。应针对频繁发生的 4XX 错误设置告警。但是,将阈值设置得非常低可能会导致告警过于敏感。您还可以调整阈值以适应请求的负载,同时考虑可接受的 4XX 错误级别。您还可以分析历史数据以确定应用程序工作负载的可接受错误率,然后相应地调整阈值。

时间段: 60

要发出警报的数据点数 :15

评估期: 15

比较运算符: GREATER_THAN_THRESHOLD

5xxErrors

维度: BucketName、FilterId

警报描述: 此警报有助于您检测高客户端错误数。此类错误表明客户端发出了服务器无法完成的请求。这可以帮助您弄清楚您的应用程序因为 S3 而面临的问题。有关帮助您高效处理或减少错误的更多信息,请参阅 优化性能设计模式 。错误也可能是由 S3 的问题所致,请查看 AWS 服务运行状况控制面板 ,了解区域中的 Amazon S3 的状态。

意图: 此警报有助于检测应用程序是否因 5xx 错误而遇到问题。

统计数据: 平均值

建议阈值: 0.05

阈值理由: 我们建议设置阈值,以检测是否总请求数中超过 5% 的请求会收到 5XX 错误。但是,您可以调整阈值以适应请求的流量以及可接受的错误率。您还可以分析历史数据以确定应用程序工作负载的可接受错误率,然后相应地调整阈值。

时间段: 60

要发出警报的数据点数 :15

评估期: 15

比较运算符: GREATER_THAN_THRESHOLD

5xxErrors

维度: AccessPointName、DataSourceARN

警报描述: 此警报有助于检测高客户端错误数。此类错误表明客户端发出了服务器无法完成的请求。此类错误也可能是由 S3 的问题所致,请查看 AWS 服务运行状况控制面板 ,了解区域中的 Amazon S3 的状态。这可以帮助您弄清楚您的应用程序因为 S3 而面临的问题。有关帮助您高效处理或减少此类错误的信息,请参阅 优化性能设计模式

意图: 此警报有助于检测应用程序是否因 5xx 错误而遇到问题。

统计数据: 平均值

建议阈值: 0.05

阈值理由: 我们建议设置阈值,以检测是否总请求数中超过 5% 的请求会收到 5XX 错误。但是,您可以调整阈值以适应请求的流量以及可接受的错误率。您还可以分析历史数据以确定应用程序工作负载的可接受错误率,然后相应地调整阈值。

时间段: 60

要发出警报的数据点数 :15

评估期: 15

比较运算符: GREATER_THAN_THRESHOLD

OperationsFailedReplication

维度: SourceBucket、DestinationBucket、RuleId

警报描述: 此警报有助于了解复制失败。此指标会跟踪使用 S3 CRR 或 S3 SRR 复制的新对象的状态,还会跟踪使用 S3 批量复制复制的现有对象。有关更多详细信息,请参阅 对复制进行问题排查

意图: 此警报用于检测是否存在失败的复制操作。

统计数据: Maximum

建议阈值: 0.0

阈值理由: 对于成功的操作,此指标会发出值 0;当一分钟内没有执行任何复制操作时,此指标不发出任何值。当指标发出的值大于 0 时,复制操作将失败。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

LambdaResponse4xx

维度: AccessPointName、DataSourceARN

警报描述: 此警报有助于您检测和诊断 S3 对象 Lambda 调用中的失败(500 秒)。此类错误可能是由负责响应您请求的 Lambda 函数中的错误或配置错误所致。调查与对象 Lambda 接入点关联的 Lambda 函数的 CloudWatch 日志流,可以帮助您根据 S3 对象 Lambda 的响应查明问题的根源。

意图: 此警报用于检测 WriteGetObjectResponse 调用的 4xx 客户端错误。

统计数据: 平均值

建议阈值: 0.05

阈值理由: 我们建议设置阈值,以检测是否总请求数中超过 5% 的请求会收到 4xx 错误。应针对频繁发生的 4XX 错误设置告警。但是,将阈值设置得非常低可能会导致告警过于敏感。您还可以调整阈值以适应请求的负载,同时考虑可接受的 4XX 错误级别。您还可以分析历史数据以确定应用程序工作负载的可接受错误率,然后相应地调整阈值。

时间段: 60

要发出警报的数据点数 :15

评估期: 15

比较运算符: GREATER_THAN_THRESHOLD

Amazon SNS

维度: TopicName

警报描述: 此警报可以检测何时发布的 SNS 消息数量过低。要排查问题,请检查发布者发送的流量减少的原因。

意图: 此警报有助于您主动监控和检测通知发布的显著下降。这可以帮助您识别应用程序或业务流程的潜在问题,以便您可以执行适当的操作来维护预期的通知流。如果您希望系统处理的流量最低,则应创建此警报。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 发布的消息数量应与应用程序的预期已发布消息数量一致。您还可以分析历史数据、趋势和流量,以确定合适的阈值。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: LESS_THAN_THRESHOLD

NumberOfNotificationsDelivered

维度: TopicName

警报描述: 此警报可以检测何时传送的 SNS 消息数量过低。这可能是由于端点意外取消订阅或导致消息出现延迟的 SNS 事件所致。

意图: 此警报有助于您检测传送的消息量的下降。如果您希望系统处理的流量最低,则应创建此警报。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 传送的消息数量应与预期生成的消息数量和消费端数量相符。您还可以分析历史数据、趋势和流量,以确定合适的阈值。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: LESS_THAN_THRESHOLD

NumberOfNotificationsFailed

维度: TopicName

警报描述: 此警报可以检测何时传送失败的 SNS 消息数量过高。要排查失败通知的问题,请启用日志记录功能,并将日志记录到 CloudWatch Logs 中。检查日志可以帮助您确定面向哪些订阅用户的通知失败了,以及这些通知返回的状态码。

意图: 此警报有助于您主动发现通知传送方面的问题,并执行适当的操作来解决这些问题。

统计数据: Sum

建议阈值: 取决于您的情况

阈值理由: 此警报的建议阈值在很大程度上取决于失败通知的影响。查看提供给最终用户的 SLA、通知的容错能力和临界程度,并分析历史数据,然后相应地选择阈值。对于只有 SQS、Lambda 或 Firehose 订阅的主题,失败的通知数量应为 0。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

NumberOfNotificationsFilteredOut-InvalidAttributes

维度: TopicName

警报描述: 此警报有助于监控和解决发布者或订阅用户遇到的潜在问题。检查发布者是否在发布具有无效属性的消息,或者是否对订阅用户应用了不当筛选条件。您还可以分析 CloudWatch Logs,以帮助确定问题的根本原因。

意图: 此警报用于检测已发布的消息是否无效,或者是否对订阅用户应用了不当筛选条件。

统计数据: Sum

建议阈值: 0.0

阈值理由: 无效属性几乎总是发布者出错导致的。我们建议将阈值设置为 0,因为在运行正常的系统中,预计不会出现无效属性。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

NumberOfNotificationsFilteredOut-InvalidMessageBody

维度: TopicName

警报描述: 此警报有助于监控和解决发布者或订阅用户遇到的潜在问题。检查发布者是否在发布具有无效消息正文的消息,或者是否对订阅用户应用了不当筛选条件。您还可以分析 CloudWatch Logs,以帮助确定问题的根本原因。

意图: 此警报用于检测已发布的消息是否无效,或者是否对订阅用户应用了不当筛选条件。

统计数据: Sum

建议阈值: 0.0

阈值理由: 无效消息正文几乎总是发布者出错导致的。我们建议将阈值设置为 0,因为在运行正常的系统中,预计不会出现无效消息正文。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

NumberOfNotificationsRedrivenToDlq

维度: TopicName

警报描述: 此警报有助于监控要移至死信队列的消息数量。

意图: 此警报用于检测要移至死信队列的消息。我们建议您在将 SNS 与 SQS、Lambda 或 Firehose 结合使用时创建此警报。

统计数据: Sum

建议阈值: 0.0

阈值理由: 在任何订阅用户类型的运行正常的系统中,不应将消息移至死信队列。如果有任何消息进入该队列,我们建议向您发送通知,以便您可以识别根本原因并解决问题,并有可能重新驱动死信队列中的消息以防止数据丢失。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

NumberOfNotificationsFailedToRedriveToDlq

维度: TopicName

警报描述: 此警报有助于监控无法移至死信队列的消息。检查您的死信队列是否存在,并检查其配置是否正确。此外,请验证 SNS 是否有权访问死信队列。要了解更多信息,请参阅 死信队列文档

意图: 此警报用于检测无法移至死信队列的消息。

统计数据: Sum

建议阈值: 0.0

阈值理由: 如果无法将消息移至死信队列,则几乎总会出错。建议阈值为 0,这意味着在配置队列后,所有处理失败的消息都必须能够到达死信队列。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

SMSMonthToDateSpentUSD

维度: TopicName

警报描述: 此警报有助于监控您的账户中是否有足够的限额让 SNS 能够传送消息。如果达到了限额,SNS 将无法传送 SMS 消息。有关设置您的每月 SMS 支出限额的信息,或有关向 AWS 请求提高支出限额的信息,请参阅 设置发送 SMS 消息的首选项

意图: 此警报用于检测您的账户中是否有足够的限额来成功传送 SMS 消息。

统计数据: Maximum

建议阈值: 取决于您的情况

阈值理由: 根据账户的限额(账户支出限额)设置阈值。选择一个阈值,该阈值会尽早告知您已达到限额,以便您有时间请求增加限额。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

SMSSuccessRate

维度: TopicName

警报描述: 此警报有助于监控 SMS 消息传送的失败率。您可以设置 Cloudwatch Logs 以了解失败的性质并据此执行操作。

意图: 此警报用于检测 SMS 消息传送失败。

统计数据: 平均值

建议阈值: 取决于您的情况

阈值理由: 根据您对 SMS 消息传送失败的容忍度设置警报阈值。

时间段: 60

要发出警报的数据点数 :5

评估期: 5

比较运算符: GREATER_THAN_THRESHOLD

Amazon SQS

维度: QueueName

警报描述: 此警报会监控队列中最早消息的期限。您可以使用此警报来监控您的消费端是否以所需速度处理 SQS 消息。考虑增加消费端数量或消费端吞吐量以缩短消息期限。此指标可以与 ApproximateNumberOfMessagesVisible 结合使用,以确定队列积压的大小以及消息的处理速度。为防止消息在处理之前被删除,请考虑将死信队列配置为放弃潜在的毒丸消息。

意图: 此警报用于检测 queueName 队列中最早消息的期限是否过长。长期限可能表示消息处理速度不够快,或者有一些毒丸消息卡在队列中无法处理。

统计数据: Maximum

建议阈值: 取决于您的情况

阈值理由: 此警报的建议阈值在很大程度上取决于预期的消息处理时间。您可以使用历史数据计算平均消息处理时间,然后将阈值设置为比队列消费端的预期最大 SQS 消息处理时间多 50%。

时间段: 60

要发出警报的数据点数 :15

评估期: 15

比较运算符: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

ApproximateNumberOfMessagesNotVisible

维度: QueueName

警报描述: 此警报有助于检测与 QueueName 有关的大量传输中消息。要排查问题,请检查 消息积压减少

意图: 此警报用于检测队列中大量的传输中消息。如果消费端没有在可见性超时期限内删除消息,则在轮询队列时,消息会重新出现在队列中。对于 FIFO 队列,最多可以有 20000 条传输中消息。如果您达到此限额,SQS 将不会返回任何错误消息。FIFO 队列会浏览前 2 万条消息以确定可用的消息组。这意味着,如果您在单个消息组中积压了消息,则在成功使用积压的消息之前,您无法使用其他消息组中稍后发送到该队列的消息。

统计数据: 平均值

建议阈值: 取决于您的情况

阈值理由: 此警报的建议阈值在很大程度上取决于预期的传输中消息数量。您可以使用历史数据来计算传输中消息的预期最大数量,并将阈值设置为超过该值的 50%。如果队列的消费端正在处理消息但没有从队列中删除消息,则此数量将突然增加。

时间段: 60

要发出警报的数据点数 :15

评估期: 15

比较运算符: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

ApproximateNumberOfMessagesVisible

维度: QueueName

警报描述: 此警报会监控消息队列的积压是否大于预期,这表明消费端的速度太慢或消费端数量不足。如果此警报进入“ALARM”状态,可以考虑增加消费端数量或加快消费端的速度。

意图: 此警报用于检测活动队列的消息计数是否过高,消费端是否处理消息缓慢,或者是否没有足够的消费端来处理消息。

统计数据: 平均值

建议阈值: 取决于您的情况

阈值理由: 可见消息的数量异常高,表明消费端处理消息的速度未达到预期。设置此阈值时,应考虑历史数据。

时间段: 60

要发出警报的数据点数 :15

评估期: 15

比较运算符: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

NumberOfMessagesSent

维度: QueueName

警报描述: 此警报有助于检测生成器是否没有就 QueueName 发送任何消息。要排查问题,请检查生成器未发送消息的原因。

意图: 此警报用于检测生成器何时停止发送消息。

统计数据: Sum

建议阈值: 0.0

阈值理由: 如果发送的消息数量为 0,则生成器不会发送任何消息。如果此队列的 TPS 较低,请相应地增加 EvaluationPeriods 的数量。

时间段: 60

要发出警报的数据点数 :15

评估期: 15

比较运算符: LESS_THAN_OR_EQUAL_TO_THRESHOLD

AWS VPN

维度: VpnId

警报描述: 此警报有助于您了解一条或多条隧道的状态是否为“DOWN”。有关问题排查,请参阅 如何排查与 Amazon VPC 的 VPN 隧道连接故障?

意图: 此警报用于检测此 VPN 的至少一条隧道是否处于“DOWN”状态,以便您可以排查受影响 VPN 的问题。对于仅配置了单条隧道的网络,此警报将始终处于“ALARM”状态。

统计数据: Minimum

建议阈值: 1.0

阈值理由: 值小于 1 表示至少有一条隧道处于“DOWN”状态。

时间段: 300

要发出警报的数据点数 :3

评估期: 3

比较运算符: LESS_THAN_THRESHOLD

TunnelState

维度: TunnelIpAddress

警报描述: 此警报有助于您了解此隧道的状态是否为“DOWN”。有关问题排查,请参阅 如何排查与 Amazon VPC 的 VPN 隧道连接故障?

意图: 此警报用于检测隧道是否处于“DOWN”状态,以便您可以排查受影响 VPN 的问题。对于仅配置了单条隧道的网络,此警报将始终处于“ALARM”状态。

统计数据: Minimum

建议阈值: 1.0

阈值理由: 值小于 1 表示隧道处于“DOWN”状态。

时间段: 300