AWS CLI 实战使用 aws cloudwatch describe-alarm-history 查询告警完整历史【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli导读aws cloudwatch describe-alarm-history是 AWS CLI 中用于检索 Amazon CloudWatch 告警Alarm历史记录的专用命令。它能够按告警名称、历史类型、时间范围等条件查询每一次状态变更、配置更新与告警动作是排查“告警为什么触发/恢复”、审计告警行为、回放监控事件的核心工具。本文以当前仓库 describe-alarm-history.rst 为骨架结合仓库内 CloudWatch 服务模型 service-2.json 与分页配置 paginators-1.json完整讲解该命令的参数、输出结构与实战用法读完即可上手查询并解读任意告警的历史轨迹。命令概览与最简用法原示例文档给出的最典型用法是按告警名称查询并过滤出“状态更新”类型的历史记录aws cloudwatch describe-alarm-history --alarm-name myalarm --history-item-type StateUpdate命令执行后返回 JSON 格式的AlarmHistoryItems数组每个元素对应一条历史记录。原示例输出如下{ AlarmHistoryItems: [ { Timestamp: 2014-04-09T18:59:06.442Z, HistoryItemType: StateUpdate, AlarmName: myalarm, HistoryData: {\version\:\1.0\,\oldState\:{\stateValue\:\ALARM\,\stateReason\:\testing purposes\},\newState\:{\stateValue\:\OK\,\stateReason\:\Threshold Crossed: 2 datapoints were not greater than the threshold (70.0). The most recent datapoints: [38.958, 40.292].\,\stateReasonData\:{\version\:\1.0\,\queryDate\:\2014-04-09T18:59:06.4190000\,\startDate\:\2014-04-09T18:44:00.0000000\,\statistic\:\Average\,\period\:300,\recentDatapoints\:[38.958,40.292],\threshold\:70.0}}}, HistorySummary: Alarm updated from ALARM to OK }, { Timestamp: 2014-04-09T18:59:05.805Z, HistoryItemType: StateUpdate, AlarmName: myalarm, HistoryData: {\version\:\1.0\,\oldState\:{\stateValue\:\OK\,\stateReason\:\Threshold Crossed: 2 datapoints were not greater than the threshold (70.0). The most recent datapoints: [38.839999999999996, 39.714].\,\stateReasonData\:{\version\:\1.0\,\queryDate\:\2014-03-11T22:45:41.5690000\,\startDate\:\2014-03-11T22:30:00.0000000\,\statistic\:\Average\,\period\:300,\recentDatapoints\:[38.839999999999996,39.714],\threshold\:70.0}},\newState\:{\stateValue\:\ALARM\,\stateReason\:\testing purposes\}}, HistorySummary: Alarm updated from OK to ALARM } ] }从输出可见每条记录包含了时间戳、历史类型、告警名称、摘要HistorySummary以及一个 JSON 字符串形式的结构化数据HistoryData。下文将逐项拆解。请求参数详解含取值与默认行为该命令的输入结构DescribeAlarmHistoryInput定义在 service-2.json全部为可选参数可按需组合参数说明取值/默认行为--alarm-name要查询的告警名称字符串。省略时返回所有指标告警metric alarms的历史在传入AlarmTypes的情况下也返回所有复合告警composite alarms的历史--history-item-type要检索的历史记录类型枚举值见下文“历史类型”一节--start-date检索历史记录的起始时间时间戳如2014-04-09T00:00:00Z--end-date检索历史记录的结束时间时间戳--max-records单次返回的最大历史记录条数整数同时作为分页时的每页大小limit key--next-token上一页返回的令牌用于翻页由上一次调用返回的NextToken--scan-by返回顺序TimestampDescending最新在前或TimestampAscending最旧在前--alarm-types指定返回指标告警、复合告警还是日志告警列表。省略时只返回指标告警--alarm-contributor-id按特定告警贡献者contributor的唯一标识过滤与告警贡献者如异常检测贡献者相关的场景使用关键默认行为来自服务模型文档未指定告警名称时返回“所有指标告警”或配合AlarmTypes“所有复合告警”的历史未指定AlarmTypes时只返回指标告警CloudWatch 会一直保留告警的历史记录即使告警本身已被删除——这意味着你可以在告警删除后依然审计其历史行为。历史类型HistoryItemType与告警类型AlarmTypes--history-item-type的合法枚举值定义在 service-2.json枚举值含义ConfigurationUpdate告警配置发生更新如阈值、周期、SNS 动作变更StateUpdate告警状态发生变化如 OK → ALARM、ALARM → OK即原示例中使用的最常见类型Action告警触发了配置的动作如发送 SNS 通知AlarmContributorStateUpdate告警贡献者状态更新AlarmContributorAction告警贡献者动作相关记录--alarm-types则用于限定告警类别指标告警 / 复合告警 / 日志告警其 shape 定义在 service-2.json。两者配合即可精确圈定查询范围。时间范围与排序控制实际排查问题时通常需要缩小时间窗口# 查询指定告警在某个时间窗口内的所有状态变更最新记录在前 aws cloudwatch describe-alarm-history \ --alarm-name myalarm \ --history-item-type StateUpdate \ --start-date 2026-09-01T00:00:00Z \ --end-date 2026-09-15T00:00:00Z \ --scan-by TimestampDescending--start-date/--end-date用于过滤日期范围适合回放某段时间的监控事件--scan-by控制返回顺序枚举值为TimestampDescending默认方向最新在前与TimestampAscending最旧在前定义于 service-2.json。按时间正序TimestampAscending读取时可以逐条还原告警从 OK → ALARM → OK 的完整生命周期。分页MaxRecords 与 NextToken当告警历史记录较多时一次请求无法返回全部数据。该命令的分页配置位于仓库 paginators-1.jsonDescribeAlarmHistory: { input_token: NextToken, output_token: NextToken, limit_key: MaxRecords, result_key: AlarmHistoryItems }即请求参数--max-records控制每页条数--next-token传入上一页返回的NextToken获取下一页翻页数据存放在响应中的AlarmHistoryItems。手动翻页示例# 第一页每页最多 50 条 aws cloudwatch describe-alarm-history \ --alarm-name myalarm \ --max-records 50 # 第二页把上一页响应中的 NextToken 传入 aws cloudwatch describe-alarm-history \ --alarm-name myalarm \ --max-records 50 \ --next-token PASTE_NEXT_TOKEN_HERE更推荐直接使用 CLI 内建分页机制让工具自动翻页并汇总全部结果aws cloudwatch describe-alarm-history \ --alarm-name myalarm \ --history-item-type StateUpdate \ --max-items 100 \ --output json说明--max-items是 AWS CLI 通用分页参数对应服务端MaxRecords配合--starting-token可继续拉取后续页两者与仓库分页配置中的limit_key、input_token一一对应。输出结构逐字段解读每个历史记录元素对应AlarmHistoryItem结构成员定义于 service-2.json字段含义AlarmName告警名称AlarmType告警类型指标告警 / 复合告警AlarmContributorId与该条记录关联的告警贡献者唯一标识如适用AlarmContributorAttributes描述告警贡献者在事件发生时特征属性的映射Timestamp该条历史记录的时间戳HistoryItemType历史记录类型StateUpdate / ConfigurationUpdate / Action 等HistorySummary文本形式的摘要如“Alarm updated from ALARM to OK”适合快速浏览HistoryData关于告警的 JSON 格式数据注意它是字符串需要二次解析响应顶层还包含NextToken用于判断是否还有更多数据见上文分页部分。深入解读 HistoryData还原状态变更现场HistoryData是字符串化的 JSON是整条记录里信息密度最高的部分。以原示例第一条为例展开后结构如下{ version: 1.0, oldState: { stateValue: ALARM, stateReason: testing purposes }, newState: { stateValue: OK, stateReason: Threshold Crossed: 2 datapoints were not greater than the threshold (70.0). The most recent datapoints: [38.958, 40.292]., stateReasonData: { version: 1.0, queryDate: 2014-04-09T18:59:06.4190000, startDate: 2014-04-09T18:44:00.0000000, statistic: Average, period: 300, recentDatapoints: [38.958, 40.292], threshold: 70.0 } } }分析要点oldState/newState分别记录状态变更前后的状态值OK / ALARM / INSUFFICIENT_DATA与变更原因直接回答“从什么状态变成了什么状态、为什么”newState.stateReason自然语言描述如示例中明确写到“2 个数据点未超过阈值 70.0最近数据点为 [38.958, 40.292]”一眼即可定位是恢复数据回落到阈值以下而非配置变更stateReasonData机器可读的判据快照包含统计类型statisticAverage、评估周期period300 秒、最近数据点recentDatapoints与阈值threshold70.0。这些数据可以用来复核“告警判定是否准确”例如确认恢复时刻最近两个数据点确实低于阈值第二条记录展示了反向变更OK → ALARMoldState携带阈值跨越原因、newState携带 “testing purposes”说明这是一次人工测试触发的状态置位对应set-alarm-state命令的典型场景参见仓库 set-alarm-state.rst。在 shell 中可借助 jq 直接提取可读信息aws cloudwatch describe-alarm-history --alarm-name myalarm \ --query AlarmHistoryItems[].{Time:Timestamp, Summary:HistorySummary} \ --output table权限要求与注意事项根据服务模型文档查询告警历史需要cloudwatch:DescribeAlarmHistory权限若要返回复合告警composite alarm的信息该权限必须作用域为*即不能收窄到特定资源否则无法读取复合告警的历史告警历史会在告警删除后继续保留这既是优点可审计也意味着历史记录可能随时间持续累积配合--max-records与时间范围过滤能有效控制数据量。实战场景用历史记录做告警体检综合上面的能力可以组合出几类高频用法1. 排查“告警为什么误报/漏报”aws cloudwatch describe-alarm-history \ --alarm-name HighCPUAlarm \ --history-item-type StateUpdate \ --start-date 2026-09-13T00:00:00Z \ --end-date 2026-09-14T00:00:00Z \ --scan-by TimestampAscending按时间正序回放状态变迁结合每条HistoryData里的recentDatapoints、threshold、period复核当时的判定依据判断是数据突刺、阈值设置不当还是统计周期过短。2. 审计告警动作是否生效aws cloudwatch describe-alarm-history \ --alarm-name HighCPUAlarm \ --history-item-type Action只拉取Action类型记录核对每次状态变更后配置的 SNS/自动伸缩动作是否被正确触发。3. 区分人工操作与真实事件HistoryData中stateReason为 “testing purposes” 的记录通常来自set-alarm-state命令见仓库 set-alarm-state.rst或控制台测试与真实的阈值跨越记录stateReason 为 “Threshold Crossed: ...” 格式区分开避免把测试流量当成线上故障。4. 多条件组合做全量审计aws cloudwatch describe-alarm-history \ --alarm-types MetricAlarm \ --history-item-type ConfigurationUpdate \ --max-items 200不指定--alarm-name配合--alarm-types与--history-item-type ConfigurationUpdate可审计账号下所有指标告警的配置变更轨迹——这正是服务模型文档描述的“未指定告警名称时返回所有指标告警历史”的用法。结语aws cloudwatch describe-alarm-history是 CloudWatch 告警体系的“黑匣子记录仪”通过--alarm-name、--history-item-type、--start-date/--end-date、--scan-by的组合过滤配合--max-records与NextToken分页可以完整还原每一次状态切换、配置变更与动作触发的现场数据。建议将它与仓库中的 describe-alarms.rst查看告警当前状态、put-metric-alarm.rst创建/修改告警、set-alarm-state.rst手动置位测试配合使用即可在告警的“创建 — 变更 — 触发 — 恢复 — 删除”全生命周期内拥有完整的可审计记录。【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
AWS CLI 实战使用 aws cloudwatch describe-alarm-history 查询告警完整历史【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli导读aws cloudwatch describe-alarm-history是 AWS CLI 中用于检索 Amazon CloudWatch 告警Alarm历史记录的专用命令。它能够按告警名称、历史类型、时间范围等条件查询每一次状态变更、配置更新与告警动作是排查“告警为什么触发/恢复”、审计告警行为、回放监控事件的核心工具。本文以当前仓库 describe-alarm-history.rst 为骨架结合仓库内 CloudWatch 服务模型 service-2.json 与分页配置 paginators-1.json完整讲解该命令的参数、输出结构与实战用法读完即可上手查询并解读任意告警的历史轨迹。命令概览与最简用法原示例文档给出的最典型用法是按告警名称查询并过滤出“状态更新”类型的历史记录aws cloudwatch describe-alarm-history --alarm-name myalarm --history-item-type StateUpdate命令执行后返回 JSON 格式的AlarmHistoryItems数组每个元素对应一条历史记录。原示例输出如下{ AlarmHistoryItems: [ { Timestamp: 2014-04-09T18:59:06.442Z, HistoryItemType: StateUpdate, AlarmName: myalarm, HistoryData: {\version\:\1.0\,\oldState\:{\stateValue\:\ALARM\,\stateReason\:\testing purposes\},\newState\:{\stateValue\:\OK\,\stateReason\:\Threshold Crossed: 2 datapoints were not greater than the threshold (70.0). The most recent datapoints: [38.958, 40.292].\,\stateReasonData\:{\version\:\1.0\,\queryDate\:\2014-04-09T18:59:06.4190000\,\startDate\:\2014-04-09T18:44:00.0000000\,\statistic\:\Average\,\period\:300,\recentDatapoints\:[38.958,40.292],\threshold\:70.0}}}, HistorySummary: Alarm updated from ALARM to OK }, { Timestamp: 2014-04-09T18:59:05.805Z, HistoryItemType: StateUpdate, AlarmName: myalarm, HistoryData: {\version\:\1.0\,\oldState\:{\stateValue\:\OK\,\stateReason\:\Threshold Crossed: 2 datapoints were not greater than the threshold (70.0). The most recent datapoints: [38.839999999999996, 39.714].\,\stateReasonData\:{\version\:\1.0\,\queryDate\:\2014-03-11T22:45:41.5690000\,\startDate\:\2014-03-11T22:30:00.0000000\,\statistic\:\Average\,\period\:300,\recentDatapoints\:[38.839999999999996,39.714],\threshold\:70.0}},\newState\:{\stateValue\:\ALARM\,\stateReason\:\testing purposes\}}, HistorySummary: Alarm updated from OK to ALARM } ] }从输出可见每条记录包含了时间戳、历史类型、告警名称、摘要HistorySummary以及一个 JSON 字符串形式的结构化数据HistoryData。下文将逐项拆解。请求参数详解含取值与默认行为该命令的输入结构DescribeAlarmHistoryInput定义在 service-2.json全部为可选参数可按需组合参数说明取值/默认行为--alarm-name要查询的告警名称字符串。省略时返回所有指标告警metric alarms的历史在传入AlarmTypes的情况下也返回所有复合告警composite alarms的历史--history-item-type要检索的历史记录类型枚举值见下文“历史类型”一节--start-date检索历史记录的起始时间时间戳如2014-04-09T00:00:00Z--end-date检索历史记录的结束时间时间戳--max-records单次返回的最大历史记录条数整数同时作为分页时的每页大小limit key--next-token上一页返回的令牌用于翻页由上一次调用返回的NextToken--scan-by返回顺序TimestampDescending最新在前或TimestampAscending最旧在前--alarm-types指定返回指标告警、复合告警还是日志告警列表。省略时只返回指标告警--alarm-contributor-id按特定告警贡献者contributor的唯一标识过滤与告警贡献者如异常检测贡献者相关的场景使用关键默认行为来自服务模型文档未指定告警名称时返回“所有指标告警”或配合AlarmTypes“所有复合告警”的历史未指定AlarmTypes时只返回指标告警CloudWatch 会一直保留告警的历史记录即使告警本身已被删除——这意味着你可以在告警删除后依然审计其历史行为。历史类型HistoryItemType与告警类型AlarmTypes--history-item-type的合法枚举值定义在 service-2.json枚举值含义ConfigurationUpdate告警配置发生更新如阈值、周期、SNS 动作变更StateUpdate告警状态发生变化如 OK → ALARM、ALARM → OK即原示例中使用的最常见类型Action告警触发了配置的动作如发送 SNS 通知AlarmContributorStateUpdate告警贡献者状态更新AlarmContributorAction告警贡献者动作相关记录--alarm-types则用于限定告警类别指标告警 / 复合告警 / 日志告警其 shape 定义在 service-2.json。两者配合即可精确圈定查询范围。时间范围与排序控制实际排查问题时通常需要缩小时间窗口# 查询指定告警在某个时间窗口内的所有状态变更最新记录在前 aws cloudwatch describe-alarm-history \ --alarm-name myalarm \ --history-item-type StateUpdate \ --start-date 2026-09-01T00:00:00Z \ --end-date 2026-09-15T00:00:00Z \ --scan-by TimestampDescending--start-date/--end-date用于过滤日期范围适合回放某段时间的监控事件--scan-by控制返回顺序枚举值为TimestampDescending默认方向最新在前与TimestampAscending最旧在前定义于 service-2.json。按时间正序TimestampAscending读取时可以逐条还原告警从 OK → ALARM → OK 的完整生命周期。分页MaxRecords 与 NextToken当告警历史记录较多时一次请求无法返回全部数据。该命令的分页配置位于仓库 paginators-1.jsonDescribeAlarmHistory: { input_token: NextToken, output_token: NextToken, limit_key: MaxRecords, result_key: AlarmHistoryItems }即请求参数--max-records控制每页条数--next-token传入上一页返回的NextToken获取下一页翻页数据存放在响应中的AlarmHistoryItems。手动翻页示例# 第一页每页最多 50 条 aws cloudwatch describe-alarm-history \ --alarm-name myalarm \ --max-records 50 # 第二页把上一页响应中的 NextToken 传入 aws cloudwatch describe-alarm-history \ --alarm-name myalarm \ --max-records 50 \ --next-token PASTE_NEXT_TOKEN_HERE更推荐直接使用 CLI 内建分页机制让工具自动翻页并汇总全部结果aws cloudwatch describe-alarm-history \ --alarm-name myalarm \ --history-item-type StateUpdate \ --max-items 100 \ --output json说明--max-items是 AWS CLI 通用分页参数对应服务端MaxRecords配合--starting-token可继续拉取后续页两者与仓库分页配置中的limit_key、input_token一一对应。输出结构逐字段解读每个历史记录元素对应AlarmHistoryItem结构成员定义于 service-2.json字段含义AlarmName告警名称AlarmType告警类型指标告警 / 复合告警AlarmContributorId与该条记录关联的告警贡献者唯一标识如适用AlarmContributorAttributes描述告警贡献者在事件发生时特征属性的映射Timestamp该条历史记录的时间戳HistoryItemType历史记录类型StateUpdate / ConfigurationUpdate / Action 等HistorySummary文本形式的摘要如“Alarm updated from ALARM to OK”适合快速浏览HistoryData关于告警的 JSON 格式数据注意它是字符串需要二次解析响应顶层还包含NextToken用于判断是否还有更多数据见上文分页部分。深入解读 HistoryData还原状态变更现场HistoryData是字符串化的 JSON是整条记录里信息密度最高的部分。以原示例第一条为例展开后结构如下{ version: 1.0, oldState: { stateValue: ALARM, stateReason: testing purposes }, newState: { stateValue: OK, stateReason: Threshold Crossed: 2 datapoints were not greater than the threshold (70.0). The most recent datapoints: [38.958, 40.292]., stateReasonData: { version: 1.0, queryDate: 2014-04-09T18:59:06.4190000, startDate: 2014-04-09T18:44:00.0000000, statistic: Average, period: 300, recentDatapoints: [38.958, 40.292], threshold: 70.0 } } }分析要点oldState/newState分别记录状态变更前后的状态值OK / ALARM / INSUFFICIENT_DATA与变更原因直接回答“从什么状态变成了什么状态、为什么”newState.stateReason自然语言描述如示例中明确写到“2 个数据点未超过阈值 70.0最近数据点为 [38.958, 40.292]”一眼即可定位是恢复数据回落到阈值以下而非配置变更stateReasonData机器可读的判据快照包含统计类型statisticAverage、评估周期period300 秒、最近数据点recentDatapoints与阈值threshold70.0。这些数据可以用来复核“告警判定是否准确”例如确认恢复时刻最近两个数据点确实低于阈值第二条记录展示了反向变更OK → ALARMoldState携带阈值跨越原因、newState携带 “testing purposes”说明这是一次人工测试触发的状态置位对应set-alarm-state命令的典型场景参见仓库 set-alarm-state.rst。在 shell 中可借助 jq 直接提取可读信息aws cloudwatch describe-alarm-history --alarm-name myalarm \ --query AlarmHistoryItems[].{Time:Timestamp, Summary:HistorySummary} \ --output table权限要求与注意事项根据服务模型文档查询告警历史需要cloudwatch:DescribeAlarmHistory权限若要返回复合告警composite alarm的信息该权限必须作用域为*即不能收窄到特定资源否则无法读取复合告警的历史告警历史会在告警删除后继续保留这既是优点可审计也意味着历史记录可能随时间持续累积配合--max-records与时间范围过滤能有效控制数据量。实战场景用历史记录做告警体检综合上面的能力可以组合出几类高频用法1. 排查“告警为什么误报/漏报”aws cloudwatch describe-alarm-history \ --alarm-name HighCPUAlarm \ --history-item-type StateUpdate \ --start-date 2026-09-13T00:00:00Z \ --end-date 2026-09-14T00:00:00Z \ --scan-by TimestampAscending按时间正序回放状态变迁结合每条HistoryData里的recentDatapoints、threshold、period复核当时的判定依据判断是数据突刺、阈值设置不当还是统计周期过短。2. 审计告警动作是否生效aws cloudwatch describe-alarm-history \ --alarm-name HighCPUAlarm \ --history-item-type Action只拉取Action类型记录核对每次状态变更后配置的 SNS/自动伸缩动作是否被正确触发。3. 区分人工操作与真实事件HistoryData中stateReason为 “testing purposes” 的记录通常来自set-alarm-state命令见仓库 set-alarm-state.rst或控制台测试与真实的阈值跨越记录stateReason 为 “Threshold Crossed: ...” 格式区分开避免把测试流量当成线上故障。4. 多条件组合做全量审计aws cloudwatch describe-alarm-history \ --alarm-types MetricAlarm \ --history-item-type ConfigurationUpdate \ --max-items 200不指定--alarm-name配合--alarm-types与--history-item-type ConfigurationUpdate可审计账号下所有指标告警的配置变更轨迹——这正是服务模型文档描述的“未指定告警名称时返回所有指标告警历史”的用法。结语aws cloudwatch describe-alarm-history是 CloudWatch 告警体系的“黑匣子记录仪”通过--alarm-name、--history-item-type、--start-date/--end-date、--scan-by的组合过滤配合--max-records与NextToken分页可以完整还原每一次状态切换、配置变更与动作触发的现场数据。建议将它与仓库中的 describe-alarms.rst查看告警当前状态、put-metric-alarm.rst创建/修改告警、set-alarm-state.rst手动置位测试配合使用即可在告警的“创建 — 变更 — 触发 — 恢复 — 删除”全生命周期内拥有完整的可审计记录。【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
