AWS CloudWatch：日志、指标与告警

FreeGuideOnline 最新 2026-07-01

bash sudo yum install -y amazon-cloudwatch-agent


2. 创建 Agent 配置向导（交互式或手写 JSON 文件），指定要采集的日志文件路径、日志组和日志流名称：
```json
{
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/application/*.log",
            "log_group_name": "/production/app-logs",
            "log_stream_name": "{instance_id}"
          }
        ]
      }
    }
  }
}
  1. 启动 Agent 并确保开机自启： 
    sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json -s

Agent 会将日志数据高效压缩并加密后提交至 CloudWatch Logs，并自动重试失败投递。

无服务器与容器场景的自动集成

如果使用 AWS 原生计算服务，集成 CloudWatch Logs 几乎无需额外配置：

  • AWS Lambda：自动将 console.log 或打印到标准输出/标准错误的内容发送到日志组 /aws/lambda/<函数名>，无需任何代码更改。
  • Amazon ECS：在任务定义中指定 awslogs 日志驱动，并将日志路由到任意日志组。只需授予任务执行角色相应的 logs:CreateLogStream 和 logs:PutLogEvents 权限。
  • Amazon EKS / Kubernetes：通过 Fluent Bit 或 Fluentd 插件将容器日志中继到 CloudWatch Logs，集群可统一使用一个 Helm chart 快速部署。
  • AWS Elastic Beanstalk：平台默认将 Web 应用日志发送到 CloudWatch Logs，并支持自定义路径。

从其他 AWS 服务流式传输

CloudWatch Logs 还能直接接收来自 CloudTrail、VPC Flow Logs、Route 53 DNS 查询日志等服务的日志数据。在对应服务控制台中启用日志记录，选择目标日志组即可完成全部设置。

使用 CloudWatch Logs Insights 高效查询

面对海量日志，手动翻页找线索不现实。CloudWatch Logs Insights 提供交互式、专为日志优化的查询引擎，支持自定义时间范围、过滤以及聚合分析。

基本查询语法示例：

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 100

更高级的分析可以利用 stats 和 parse 命令：

fields @timestamp, @message
| parse @message '[*] *' as level, msg
| filter level = 'ERROR'
| stats count() by bin(1h)

这能在几秒内统计出每小时错误数量趋势。Insights 的查询历史会自动保存，您还可以将常用查询保存为“已保存查询”，供团队复用。

性能与成本提示：
查询以扫描的日志数据量为计费基础，建议先缩小时间窗口，并尽可能使用 filter 减少全文扫描范围。

从日志中提取指标并设置告警

CloudWatch 并非只是“日志的仓库”，其真正威力在于将文本日志转化为可触达的运维信号。

创建指标筛选器

在目标日志组中选择指标筛选器，定义匹配模式。假设日志格式为：

[2025-03-18 10:12:34] ERROR PaymentTimeout occurred for user 12345

您可以设置模式 "ERROR PaymentTimeout"，系统会把包含该字符串的每条日志记作一个数据点。您可以为此指标命名（如 PaymentTimeoutErrors），并指定默认值 0（当该模式未匹配到时）。

基于指标创建告警

当指标就绪后，直接在 CloudWatch 告警中引用它。例如，若在任意 5 分钟内出现超过 3 次 PaymentTimeoutErrors 则触发告警。告警动作可配置为发送 Amazon SNS 通知、触发 Auto Scaling 或执行 Lambda 函数。这样，日志中的异常立即转化为可行动的告警，缩短平均修复时间（MTTR）。

日志保留、订阅与导出

设置合理的保留策略

每个日志组独立设置保留期。生产环境核心日志建议保留至少 30 天以应对问题回溯，审计类日志根据合规要求通常需保留 365 天或以上。对于开发/测试环境，设置较短的保留期（如 7 天）能有效控制成本。

实时处理日志流：订阅过滤器

通过“订阅筛选器”，可以将实时日志交付给 Lambda 函数、Kinesis Data Streams/Kinesis Data Firehose 或直接发送到 OpenSearch Service。

典型用例：

  • 实时入侵检测：订阅 CloudTrail 日志，Lambda 函数检查高危操作并立即通知。
  • 集中式日志分析：用 Kinesis Firehose 将多个账户的日志流聚合到 S3 或 OpenSearch 集群中统一查询。

批量导出到 S3

对于需要长期归档或离线分析的日志，可以将其一次性导出到 Amazon S3。此功能适合已完成即时查询且极少访问的冷数据，成本远低于保持在线。

整理与访问控制的最佳实践

  • 日志组命名规范
    采用分层命名，如 /<环境>/<服务>/<组件>，比如 /production/payment-service/api-logs。清晰的命名在配置 IAM 权限和跨团队协作时至关重要。

  • 精细化 IAM 权限
    遵循最小权限原则，允许开发人员对特定日志组执行 logs:DescribeLogStreams、logs:GetLogEvents 和 logs:FilterLogEvents，禁止其修改保留策略或删除日志组。

    示例策略：

    {
    "Effect": "Allow",
    "Action": [
        "logs:DescribeLogStreams",
        "logs:GetLogEvents",
        "logs:FilterLogEvents"
    ],
    "Resource": "arn:aws:logs:us-east-1:123456789012:log-group:/production/*"
}