用途
Amazon CloudWatch 为 AWS 资源与应用程序提供监控与可观测性。它收集指标、日志和事件，使你能够监控、排查和优化 AWS 环境。本技能围绕 CloudWatch 的核心概念、常见操作模式、CLI 参考、最佳实践与故障排查展开，适用于设置监控、创建告警、使用 Insights 查询日志、配置仪表盘等场景。
核心概念
指标（Metrics）：发布到 CloudWatch 的按时间排序的数据点。关键组成部分包括：
- Namespace：指标的容器（如 AWS/Lambda）
- Metric name：测量项名称（如 Invocations）
- Dimensions：用于过滤的名称-值对（如 FunctionName=MyFunc）
- Statistics：聚合方式（Sum、Average、Min、Max、SampleCount、pN）
日志（Logs）：来自 AWS 服务和应用程序的日志数据。
- Log groups：日志流的集合
- Log streams：来自同一来源的日志事件序列
- Log events：带时间戳和消息的单条日志条目
告警（Alarms）：基于指标阈值的自动化操作。
- 状态：OK、ALARM、INSUFFICIENT_DATA
- 操作：SNS 通知、Lambda 函数、Auto Scaling、EC2 操作、Systems Manager OpsItems
- 类型：metric（含指标数学、异常检测、Metrics Insights）、composite、log（按计划执行 Logs Insights 查询，对查询结果进行 M-out-of-N 评估）
- 静音规则（Mute rules）：按计划窗口静音操作，同时告警继续评估
主要能力与常见模式
创建指标告警：可通过 AWS CLI 的 aws cloudwatch put-metric-alarm 或 boto3 的 put_metric_alarm 创建，例如为 EC2 设置 CPU 利用率告警，指定指标名、命名空间、统计方式、周期、阈值、比较运算符、评估周期、维度以及告警/恢复操作。
Lambda 错误率告警：使用指标数学（metrics 数组中的 Expression，如 errors/invocations*100）计算错误率并设置阈值。
使用 Insights 查询日志：通过 aws logs start-query 启动查询，再用 aws logs get-query-results 获取结果；也可用 boto3 的 start_query 与 get_query_results 轮询直到状态为 Complete。查询语句支持 fields、filter、sort、limit 等。
创建指标过滤器：通过 aws logs put-metric-filter 从日志模式中提取指标，例如统计 ERROR 出现次数。
创建日志告警：通过 aws cloudwatch put-log-alarm 直接对 Logs Insights 查询设置告警，无需指标过滤器。CloudWatch 会创建并管理底层的计划查询。ScheduledQueryRoleARN 角色必须信任 logs.amazonaws.com，并允许对日志组 ARN 执行 logs:StartQuery 和 logs:GetQueryResults，以及对 "Resource": "*" 执行 logs:StopQuery 和 logs:DescribeLogGroups（这两项不支持资源级权限）。日志告警默认不出现在 describe-alarms 结果中，需加 --alarm-types LogAlarm。
发布自定义指标：通过 boto3 的 put_metric_data 发布，可指定命名空间、指标名、值、单位和维度。
创建仪表盘：编写 dashboard.json（包含 metric 和 log 类型 widget），再用 aws cloudwatch put-dashboard 上传。
CLI 参考（部分）
指标命令：put-metric-data（发布自定义指标）、get-metric-data（获取指标值）、get-metric-statistics（获取聚合统计）、list-metrics（列出可用指标）。
告警命令：put-metric-alarm、put-log-alarm、describe-alarms、describe-alarm-contributors、put-alarm-mute-rule、list-alarm-mute-rules、delete-alarm-mute-rule、set-alarm-state、delete-alarms。
日志命令：create-log-group、put-log-events、filter-log-events、start-query、put-metric-filter、put-retention-policy。
最佳实践
指标：合理使用维度（过多会导致指标爆炸）；发布前先聚合、批量发布自定义指标；仅在需要时使用高分辨率（1 秒）指标；为自定义指标设置有意义的单位。
告警：复杂条件使用复合告警；设置合适的评估周期以避免抖动；包含 OK 操作以跟踪恢复；动态阈值使用异常检测；基于查询的条件优先使用日志告警而非指标过滤器加指标告警，稀疏错误设置 --treat-missing-data notBreaching，检测日志停止到达则设为 breaching；错开日志告警计划（每账户并发计划查询执行上限为 100）；为新资源同时创建的告警设置 --warm-up-configuration（1-2880 分钟）以避免指标发布前的噪声；每日/每周批处理或备份告警使用 --evaluation-window WallClockWindow={Timezone=...}，Auto Scaling 保持默认滑动窗口；维护时使用静音规则而非 disable-alarm-actions，且 enable-alarm-actions 不会解除已激活的静音规则。
日志：设置保留策略，不要永久保留日志；使用结构化日志（JSON）以便查询；为关键事件创建指标过滤器；使用 Contributor Insights 进行 Top-N 分析。
成本优化：删除未使用的仪表盘；降低非关键日志的保留期；除非必要避免高分辨率指标；使用日志订阅过滤器而非轮询。
故障排查
指标缺失：原因可能是服务尚未发布（等待 1-5 分钟）、命名空间/维度错误、未启用详细监控（EC2）。可用 aws cloudwatch list-metrics 按命名空间和维度排查。
告警卡在 INSUFFICIENT_DATA：原因可能是指标未发布、维度不匹配、评估周期过短、预热期仍生效（除非 OnlyStartEvaluatingAfterWarmUpPeriodEnds=true，否则数据填满窗口后会提前结束）；日志告警可能是刚创建/更新（查询、计划或日志组变更会重置状态）、计划查询角色缺少权限（EvaluationState = EVALUATION_ERROR，见 StateReason）或摄取延迟（用 EndTimeOffset 将窗口后移）。可用 get-metric-statistics 检查指标是否有数据，或用 describe-alarms --alarm-types LogAlarm 查看评估状态与原因。
日志事件未出现：原因可能是缺少 IAM 权限、CloudWatch Logs agent 未运行、日志组不存在。可用 aws logs describe-log-streams 检查日志流。
CloudWatch 成本过高：可用 get-metric-statistics 查询 AWS/Logs 命名空间的 IncomingBytes 指标检查 PutLogEvents 用量。
适用场景与限制
适用于 AWS 环境下的监控、告警、日志查询、自定义指标发布与仪表盘构建。使用日志告警时需注意计划查询角色权限配置与并发上限；部分命令（如 describe-alarms 对日志告警）需显式指定类型。具体收费、价格与平台细节暂未提供。