请求协助排查CloudWatch日志流无数据的异常问题

我之前也踩过类似的坑——明明CloudWatch日志代理的日志全是INFO级别的正常输出，控制台里的日志流却空空如也。给你整理几个关键的排查方向，按顺序试下来大概率能解决：

• 盯紧配置文件的细节，别放过时间格式这个坑
  先打开/etc/awslogs/awslogs.conf，找到/var/log/syslog对应的配置段，重点核对这几个点：

  • 文件路径：确认file = /var/log/syslog没错，并且awslogs用户有读取权限——可以用sudo -u awslogs cat /var/log/syslog测试，读不了的话要调整文件权限或者给用户加权限。
  • 日志组/流名称：log_group_name和log_stream_name要和你在控制台找的完全一致，尤其是用了{instance_id}或{hostname}变量的话，要确认实例的实际ID/主机名和控制台显示的匹配。
  • 时间格式是重灾区：Ubuntu默认syslog的时间格式是%b %d %H:%M:%S（比如Oct 12 14:30:00），如果配置里的datetime_format和这个不匹配，代理会默默跳过所有日志条目，而且不会报错！一定要确保这个参数和syslog的实际格式完全对应。

• 验证代理的真实运行状态，别光看日志
  用systemctl status awslogs检查服务是不是稳定运行，有没有频繁重启的记录。另外直接用AWS CLI在实例上查日志流状态：

  aws logs describe-log-streams --log-group-name 你的日志组名称
  

  看目标日志流的lastIngestionTime有没有更新——如果这个时间是最近的，说明数据已经发上去了，大概率是CloudWatch控制台的缓存问题，刷新页面或者等个几分钟再看；如果时间一直没动，说明代理根本没发送数据。

• 再确认下IAM角色的信任关系
  虽然你说策略在其他实例上正常，但还是要检查这个实例绑定的IAM角色的信任策略，确保允许EC2服务扮演它。信任策略应该包含：

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": "ec2.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
      }
    ]
  }
  

  要是信任关系被改了，就算权限策略没问题，代理也拿不到发送日志的权限。

• 手动触发测试日志，验证全链路
  手动往syslog里写一条测试内容：

  echo "TEST CloudWatch Logs $(date)" | sudo tee -a /var/log/syslog
  

  过个2-3分钟，先看代理日志里有没有Successfully delivered 1 log events之类的成功提示，再用CLI查日志事件：

  aws logs get-log-events --log-group-name 你的日志组名称 --log-stream-name 你的日志流名称
  

  如果CLI能拿到测试日志但控制台看不到，就是控制台缓存的问题；如果CLI也拿不到，那就是代理没把数据发出去，回到前面的配置和权限排查。

• 私有子网的话，检查VPC端点配置
  如果实例在没有公网访问的私有子网里，有没有配置CloudWatch Logs的VPC端点？没配置的话，代理没法把数据传到AWS，但有些版本的代理不会在日志里报错，只会显示INFO。可以用nc -zv logs.你的区域.amazonaws.com 443测试连通性，连不上的话就是网络问题，得配置VPC端点或者给实例加NAT网关。

内容的提问来源于stack exchange，提问作者Michal