拓冰网站定制 
AWS CLI 实战指南使用 cloudwatch put-metric-alarm 创建与更新 CloudWatch 指标告警【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli本文围绕 AWS CLI 中cloudwatch put-metric-alarm命令展开结合当前仓库 awscli/examples/cloudwatch/put-metric-alarm.rst 中的官方示例讲解如何基于静态阈值创建 EC2 CPU 利用率告警、通过 SNS 触发邮件通知、以及如何为单条指标指定多个维度。读完本文你将能够独立编写可复用的 put-metric-alarm 命令并理解各参数在底层 API 中的约束与取值来源。命令定位PutMetricAlarm 在 CloudWatch 告警体系中的作用put-metric-alarm对应 CloudWatch API 中的PutMetricAlarm操作。从 awscli/botocore/data/cloudwatch/2010-08-01/service-2.json 的模型定义PutMetricAlarm见第 673 行起可以看出它承担两类职责创建告警为指定指标、指标数学表达式、异常检测模型、Metrics Insights 查询或 PromQL 查询创建一条新的告警更新告警如果同名告警已存在直接以新配置覆盖。值得注意的是该操作对告警初始状态的定义普通指标告警创建后告警状态会立即被置为INSUFFICIENT_DATA随后系统开始评估并根据数据将其调整为实际状态基于 PromQL 的告警则初始置为OK。理解这一点有助于排查刚创建告警为何看不到 ALARM 状态的疑问。官方文档中给出的两个示例正是这个命令最典型的两种用法CPU 利用率超过 70% 时发送 SNS 邮件通知为指标指定多个维度Name/Value 对。下面分别深入拆解。示例一CPU 利用率超过 70% 时发送 SNS 邮件通知原文档给出如下完整命令put-metric-alarm.rst 第 5 行aws cloudwatch put-metric-alarm \ --alarm-name cpu-mon \ --alarm-description Alarm when CPU exceeds 70 percent \ --metric-name CPUUtilization \ --namespace AWS/EC2 \ --statistic Average \ --period 300 \ --threshold 70 \ --comparison-operator GreaterThanThreshold \ --dimensions NameInstanceId,Valuei-12345678 \ --evaluation-periods 2 \ --alarm-actions arn:aws:sns:us-east-1:111122223333:MyTopic \ --unit Percent该命令成功执行后不会输出任何 JSON 结果直接返回命令行提示符。如果已存在名为cpu-mon的告警这条命令会以新参数将其整体覆盖——这也是put-metric-alarm作为创建或更新二合一操作的核心语义。逐参数说明与底层取值约束结合 service-2.json 中PutMetricAlarmInput第 4272 行起的成员定义逐项说明上述参数--alarm-name必填参数告警名称在同一 Region 内必须唯一只允许 UTF-8 字符且不能包含 ASCII 控制字符模型定义。--alarm-description告警描述纯说明性内容。--metric-name/--namespace分别指定指标名如CPUUtilization与命名空间如AWS/EC2。API 要求每次PutMetricAlarm必须且只能三选一提供MetricName、提供Metrics数组指标数学表达式或提供EvaluationCriteria。--statistic聚合统计量。模型中的Statistic枚举第 4805 行起固定为SampleCount、Average、Sum、Minimum、Maximum五选一若需分位数统计如p90必须改用--extended-statistic两者不能同时指定。--period每次评估指标的数据周期秒。合法值为 10、20、30 以及 60 的任意倍数。仅当指标通过PutMetricData以StorageResolution1亚分钟分辨率存储时才应使用 10/20/30否则告警会频繁落入INSUFFICIENT_DATA状态指定 10/20/30 还会使该告警成为高分辨率告警计费更高。同时存在硬性约束Period × EvaluationPeriods不得超过 604800 秒7 天且当Period小于 3600 秒1 小时时总评估周期不得超过 86400 秒1 天。--threshold静态阈值告警的阈值即统计量与之比较的基准值。--comparison-operator比较运算符作为第一操作数的是指标统计值。ComparisonOperator枚举第 1214 行起共 7 个取值GreaterThanOrEqualToThreshold、GreaterThanThreshold、LessThanThreshold、LessThanOrEqualToThreshold以及仅用于异常检测模型告警的LessThanLowerOrGreaterThanUpperThreshold、LessThanLowerThreshold、GreaterThanUpperThreshold。示例中的GreaterThanThreshold即严格大于阈值。--evaluation-periods需要多少个周期的数据点与阈值比较。若希望连续 N 个数据点越界才触发此值就是 N若配置M out of N告警此值是 N。--alarm-actions告警进入ALARM状态时执行的动作每个动作以 ARN 表示。SNS 通知的 ARN 形如arn:aws:sns:region:account-id:topic-name即示例用法。同一参数位置还支持 EC2 自动化动作如arn:aws:automate:region:ec2:stop、Auto Scaling 策略、Lambda 函数、SSM OpsItem 等对应地还有--ok-actions进入OK状态时执行与--insufficient-data-actions进入INSUFFICIENT_DATA状态时执行两组同类参数AlarmActions 定义。--unit统计量的度量单位。StandardUnit枚举第 4727 行起包含Seconds、Bytes、Percent、Count、Count/Second、None等 28 个取值示例使用Percent。需要特别留意模型的建议若某指标被以多种单位发布而你又未指定--unit告警行为不可预期若指定了未发布的错误单位告警会卡在INSUFFICIENT_DATA。因此官方建议通常省略--unit仅在确认需要时显式指定。底层语义创建即置 INSUFFICIENT_DATA文档明确该命令在成功时直接返回。结合 service-2.json 中PutMetricAlarm的操作说明第 673 行起创建告警后普通指标告警的状态被立即设为INSUFFICIENT_DATA随后才按评估周期逐步进入OK或ALARM。这意味着示例中--evaluation-periods 2配合--period 300的含义是以 5 分钟为周期、连续 2 个周期的 CPU 平均值Average都大于 70% 时告警进入 ALARM 并触发 SNS 邮件从而有效避免瞬时抖动的误报。示例二为同一指标指定多个维度原文档第二个示例演示了多维度指标的写法put-metric-alarm.rst 第 13 行aws cloudwatch put-metric-alarm \ --alarm-name Default_Test_Alarm3 \ --alarm-description The default example alarm \ --namespace CW EXAMPLE METRICS \ --metric-name Default_Test \ --statistic Average \ --period 60 \ --evaluation-periods 3 \ --threshold 50 \ --comparison-operator GreaterThanOrEqualToThreshold \ --dimensions Namekey1,Valuevalue1 Namekey2,Valuevalue2这里的语法要点正是 CLI 的 shorthand 语法规则每个维度是一个Name/Value对写作Namekey1,Valuevalue1多个维度之间以空格分隔直接并列传入同一个--dimensions参数该写法与仓库中其他 CloudWatch 示例保持一致例如 get-metric-statistics.rst 中的--dimensions NameInstanceID,Valuei-abcdef NameInstanceType,Valuem1.small以及 describe-alarms-for-metric.rst 中的单维度写法可以交叉印证语法的通用性。从 API 模型看Dimensions是MetricName所对应指标的维度过滤条件Dimensions 定义告警只会基于与所有维度键值完全匹配的数据点进行评估。同时该示例也补充了第一个示例未覆盖的运算符GreaterThanOrEqualToThreshold大于等于阈值在 CPU 告警中同样常用。进阶参数让告警更精准除两个示例涉及的参数外PutMetricAlarmInput还定义了若干高频进阶参数可在此一并掌握--actions-enabled布尔值是否在告警状态变化时执行动作默认TRUE。--datapoints-to-alarm配合--evaluation-periods实现M out of N告警——N 个周期内只要有 M 个数据点越界即触发不必连续。--treat-missing-data缺失数据点的处理策略合法值为breaching、notBreaching、ignore、missing默认missing。注意两条特例评估AWS/DynamoDB命名空间指标的告警总是按ignore处理该参数不适用于 PromQL 告警。--evaluate-low-sample-count-percentile仅用于分位数告警取值evaluate或ignore控制数据点过少时是否仍然评估。--metrics指标数学表达式告警的查询数组使用该参数时不能再同时指定Namespace、MetricName、Dimensions、Period、Unit、Statistic、ExtendedStatistic。--tags创建告警时附加标签最多 50 个需要同时具备cloudwatch:PutMetricAlarm与cloudwatch:TagResource权限更新已有告警时该参数会被忽略。--evaluation-window评估窗口类型滑动窗口或固定时钟窗口省略时默认滑动窗口。--evaluation-criteria/--evaluation-interval面向 PromQL 告警的评估条件与评估频率10、20、30 或 60 的倍数二者与MetricName/Metrics模式互斥。这些参数共同构成一条完整告警的可调面建议在实际创建前用aws cloudwatch put-metric-alarm --generate-cli-skeleton生成完整 JSON 骨架再按需填充避免漏参。验证与配套操作告警创建完成后可通过仓库中的配套示例命令验证# 查看与某指标关联的所有告警 aws cloudwatch describe-alarms-for-metric \ --metric-name CPUUtilization --namespace AWS/EC2 \ --dimensions NameInstanceId,Valuei-12345678 # 查询该指标的历史统计值确认阈值设置是否合理 aws cloudwatch get-metric-statistics \ --metric-name CPUUtilization --namespace AWS/EC2 \ --start-time 2026-09-14T00:00:00Z --end-time 2026-09-15T00:00:00Z \ --period 300 --statistics Average \ --dimensions NameInstanceId,Valuei-12345678对应示例分别见 describe-alarms-for-metric.rst 与 get-metric-statistics.rst。此外CloudWatch 告警动作会写入 SNS 主题若邮件未如期到达可从 SNS 主题的投递状态与 CloudWatch 告警状态历史describe-alarm-history两个方向排查。小结cloudwatch put-metric-alarm是 AWS CLI 中管理静态阈值告警的核心命令。本文基于官方示例拆解了两个最常用场景——SNS 邮件告警与多维度指标告警并结合 service-2.json 中PutMetricAlarmInput的完整模型澄清了Period × EvaluationPeriods的时间窗约束、Statistic与ExtendedStatistic的互斥关系、--unit的省略建议以及 M out of N、缺失数据处理等进阶能力。掌握这些细节后无论是从零创建监控告警还是维护已有告警都能避免最常见的建了不生效与频繁误报两类问题。【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AWS CLI 实战指南：使用 cloudwatch put-metric-alarm 创建与更新 CloudWatch 指标告警
AWS CLI 实战指南使用 cloudwatch put-metric-alarm 创建与更新 CloudWatch 指标告警【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli本文围绕 AWS CLI 中cloudwatch put-metric-alarm命令展开结合当前仓库 awscli/examples/cloudwatch/put-metric-alarm.rst 中的官方示例讲解如何基于静态阈值创建 EC2 CPU 利用率告警、通过 SNS 触发邮件通知、以及如何为单条指标指定多个维度。读完本文你将能够独立编写可复用的 put-metric-alarm 命令并理解各参数在底层 API 中的约束与取值来源。命令定位PutMetricAlarm 在 CloudWatch 告警体系中的作用put-metric-alarm对应 CloudWatch API 中的PutMetricAlarm操作。从 awscli/botocore/data/cloudwatch/2010-08-01/service-2.json 的模型定义PutMetricAlarm见第 673 行起可以看出它承担两类职责创建告警为指定指标、指标数学表达式、异常检测模型、Metrics Insights 查询或 PromQL 查询创建一条新的告警更新告警如果同名告警已存在直接以新配置覆盖。值得注意的是该操作对告警初始状态的定义普通指标告警创建后告警状态会立即被置为INSUFFICIENT_DATA随后系统开始评估并根据数据将其调整为实际状态基于 PromQL 的告警则初始置为OK。理解这一点有助于排查刚创建告警为何看不到 ALARM 状态的疑问。官方文档中给出的两个示例正是这个命令最典型的两种用法CPU 利用率超过 70% 时发送 SNS 邮件通知为指标指定多个维度Name/Value 对。下面分别深入拆解。示例一CPU 利用率超过 70% 时发送 SNS 邮件通知原文档给出如下完整命令put-metric-alarm.rst 第 5 行aws cloudwatch put-metric-alarm \ --alarm-name cpu-mon \ --alarm-description Alarm when CPU exceeds 70 percent \ --metric-name CPUUtilization \ --namespace AWS/EC2 \ --statistic Average \ --period 300 \ --threshold 70 \ --comparison-operator GreaterThanThreshold \ --dimensions NameInstanceId,Valuei-12345678 \ --evaluation-periods 2 \ --alarm-actions arn:aws:sns:us-east-1:111122223333:MyTopic \ --unit Percent该命令成功执行后不会输出任何 JSON 结果直接返回命令行提示符。如果已存在名为cpu-mon的告警这条命令会以新参数将其整体覆盖——这也是put-metric-alarm作为创建或更新二合一操作的核心语义。逐参数说明与底层取值约束结合 service-2.json 中PutMetricAlarmInput第 4272 行起的成员定义逐项说明上述参数--alarm-name必填参数告警名称在同一 Region 内必须唯一只允许 UTF-8 字符且不能包含 ASCII 控制字符模型定义。--alarm-description告警描述纯说明性内容。--metric-name/--namespace分别指定指标名如CPUUtilization与命名空间如AWS/EC2。API 要求每次PutMetricAlarm必须且只能三选一提供MetricName、提供Metrics数组指标数学表达式或提供EvaluationCriteria。--statistic聚合统计量。模型中的Statistic枚举第 4805 行起固定为SampleCount、Average、Sum、Minimum、Maximum五选一若需分位数统计如p90必须改用--extended-statistic两者不能同时指定。--period每次评估指标的数据周期秒。合法值为 10、20、30 以及 60 的任意倍数。仅当指标通过PutMetricData以StorageResolution1亚分钟分辨率存储时才应使用 10/20/30否则告警会频繁落入INSUFFICIENT_DATA状态指定 10/20/30 还会使该告警成为高分辨率告警计费更高。同时存在硬性约束Period × EvaluationPeriods不得超过 604800 秒7 天且当Period小于 3600 秒1 小时时总评估周期不得超过 86400 秒1 天。--threshold静态阈值告警的阈值即统计量与之比较的基准值。--comparison-operator比较运算符作为第一操作数的是指标统计值。ComparisonOperator枚举第 1214 行起共 7 个取值GreaterThanOrEqualToThreshold、GreaterThanThreshold、LessThanThreshold、LessThanOrEqualToThreshold以及仅用于异常检测模型告警的LessThanLowerOrGreaterThanUpperThreshold、LessThanLowerThreshold、GreaterThanUpperThreshold。示例中的GreaterThanThreshold即严格大于阈值。--evaluation-periods需要多少个周期的数据点与阈值比较。若希望连续 N 个数据点越界才触发此值就是 N若配置M out of N告警此值是 N。--alarm-actions告警进入ALARM状态时执行的动作每个动作以 ARN 表示。SNS 通知的 ARN 形如arn:aws:sns:region:account-id:topic-name即示例用法。同一参数位置还支持 EC2 自动化动作如arn:aws:automate:region:ec2:stop、Auto Scaling 策略、Lambda 函数、SSM OpsItem 等对应地还有--ok-actions进入OK状态时执行与--insufficient-data-actions进入INSUFFICIENT_DATA状态时执行两组同类参数AlarmActions 定义。--unit统计量的度量单位。StandardUnit枚举第 4727 行起包含Seconds、Bytes、Percent、Count、Count/Second、None等 28 个取值示例使用Percent。需要特别留意模型的建议若某指标被以多种单位发布而你又未指定--unit告警行为不可预期若指定了未发布的错误单位告警会卡在INSUFFICIENT_DATA。因此官方建议通常省略--unit仅在确认需要时显式指定。底层语义创建即置 INSUFFICIENT_DATA文档明确该命令在成功时直接返回。结合 service-2.json 中PutMetricAlarm的操作说明第 673 行起创建告警后普通指标告警的状态被立即设为INSUFFICIENT_DATA随后才按评估周期逐步进入OK或ALARM。这意味着示例中--evaluation-periods 2配合--period 300的含义是以 5 分钟为周期、连续 2 个周期的 CPU 平均值Average都大于 70% 时告警进入 ALARM 并触发 SNS 邮件从而有效避免瞬时抖动的误报。示例二为同一指标指定多个维度原文档第二个示例演示了多维度指标的写法put-metric-alarm.rst 第 13 行aws cloudwatch put-metric-alarm \ --alarm-name Default_Test_Alarm3 \ --alarm-description The default example alarm \ --namespace CW EXAMPLE METRICS \ --metric-name Default_Test \ --statistic Average \ --period 60 \ --evaluation-periods 3 \ --threshold 50 \ --comparison-operator GreaterThanOrEqualToThreshold \ --dimensions Namekey1,Valuevalue1 Namekey2,Valuevalue2这里的语法要点正是 CLI 的 shorthand 语法规则每个维度是一个Name/Value对写作Namekey1,Valuevalue1多个维度之间以空格分隔直接并列传入同一个--dimensions参数该写法与仓库中其他 CloudWatch 示例保持一致例如 get-metric-statistics.rst 中的--dimensions NameInstanceID,Valuei-abcdef NameInstanceType,Valuem1.small以及 describe-alarms-for-metric.rst 中的单维度写法可以交叉印证语法的通用性。从 API 模型看Dimensions是MetricName所对应指标的维度过滤条件Dimensions 定义告警只会基于与所有维度键值完全匹配的数据点进行评估。同时该示例也补充了第一个示例未覆盖的运算符GreaterThanOrEqualToThreshold大于等于阈值在 CPU 告警中同样常用。进阶参数让告警更精准除两个示例涉及的参数外PutMetricAlarmInput还定义了若干高频进阶参数可在此一并掌握--actions-enabled布尔值是否在告警状态变化时执行动作默认TRUE。--datapoints-to-alarm配合--evaluation-periods实现M out of N告警——N 个周期内只要有 M 个数据点越界即触发不必连续。--treat-missing-data缺失数据点的处理策略合法值为breaching、notBreaching、ignore、missing默认missing。注意两条特例评估AWS/DynamoDB命名空间指标的告警总是按ignore处理该参数不适用于 PromQL 告警。--evaluate-low-sample-count-percentile仅用于分位数告警取值evaluate或ignore控制数据点过少时是否仍然评估。--metrics指标数学表达式告警的查询数组使用该参数时不能再同时指定Namespace、MetricName、Dimensions、Period、Unit、Statistic、ExtendedStatistic。--tags创建告警时附加标签最多 50 个需要同时具备cloudwatch:PutMetricAlarm与cloudwatch:TagResource权限更新已有告警时该参数会被忽略。--evaluation-window评估窗口类型滑动窗口或固定时钟窗口省略时默认滑动窗口。--evaluation-criteria/--evaluation-interval面向 PromQL 告警的评估条件与评估频率10、20、30 或 60 的倍数二者与MetricName/Metrics模式互斥。这些参数共同构成一条完整告警的可调面建议在实际创建前用aws cloudwatch put-metric-alarm --generate-cli-skeleton生成完整 JSON 骨架再按需填充避免漏参。验证与配套操作告警创建完成后可通过仓库中的配套示例命令验证# 查看与某指标关联的所有告警 aws cloudwatch describe-alarms-for-metric \ --metric-name CPUUtilization --namespace AWS/EC2 \ --dimensions NameInstanceId,Valuei-12345678 # 查询该指标的历史统计值确认阈值设置是否合理 aws cloudwatch get-metric-statistics \ --metric-name CPUUtilization --namespace AWS/EC2 \ --start-time 2026-09-14T00:00:00Z --end-time 2026-09-15T00:00:00Z \ --period 300 --statistics Average \ --dimensions NameInstanceId,Valuei-12345678对应示例分别见 describe-alarms-for-metric.rst 与 get-metric-statistics.rst。此外CloudWatch 告警动作会写入 SNS 主题若邮件未如期到达可从 SNS 主题的投递状态与 CloudWatch 告警状态历史describe-alarm-history两个方向排查。小结cloudwatch put-metric-alarm是 AWS CLI 中管理静态阈值告警的核心命令。本文基于官方示例拆解了两个最常用场景——SNS 邮件告警与多维度指标告警并结合 service-2.json 中PutMetricAlarmInput的完整模型澄清了Period × EvaluationPeriods的时间窗约束、Statistic与ExtendedStatistic的互斥关系、--unit的省略建议以及 M out of N、缺失数据处理等进阶能力。掌握这些细节后无论是从零创建监控告警还是维护已有告警都能避免最常见的建了不生效与频繁误报两类问题。【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考